Main Use Cases for IPAv2

As a result of the enrollment machine principal must be created and machine credentials provisioned to the machine

Machine credentials can be keytab and/or machine certificate.

Machine authentication

Machines coming on the network and requesting services within the IPA realm shall be authenticated against that realm

Machine authentication credentials shall be used to provide mutual authentication/trust, encryption, and SSO capabilities for the services and applications requesting resources and accessing other services within the same IPA realm

[1.6.2] Automatically renew and provision certificates before their expiration according to the centrally managed policy (Planned)

[1.7] Allow a machine to leave the realm, de-activating the identity from IPA and destroying/revoking any certificates/keytabs. (Planned)

[1.7.1] The task of de-activating a machine from a realm should not require access (physical or network) to that client machine (Planned)

[1.7.2] Allow machine to be de-activated from IPA realm through the IPA client software (Planned)

[1.7.3] Allow machine to be re-enrolled into the IPA realm. (Planned)

[1.8] Update LDAP schema to support machine identity and related policies (Planned - but only for identity part)

[1.9] Maintain the identity of the machine or virtual machine after an upgrade of the OS including a major upgrade for example from 4 to 5. (Planned)

2. Services Identity

[2.1] Services Identity and Credentials

[2.1.1] Allow different ways of defining services, the credentials they require for authentication and policies that control their operation:

[2.1.1.1] Specify services through IPA client. In this case the provisioning of the service should happen automatically (subject to policy validation on server) (low priority)

[2.1.1.2] Specify in the GUI or command line on the server side. In this case client side software should detect (not necessarily immediately and automatically) and download application (service) related policies and credentials.

[2.1.2] Automatically create/provision/renew/revoke the credentials required for the services and applications to function according to the policies defined for the services and machines

[2.1.2.1] default /etc Machine kerberos principals shall not be used for services by default (except for SSHD which will leverage machine kerberos principal) services should have it's own keytab

[2.1.2.2] In IPA v2 allow only Kerberos or PKI authentication for the services

[2.1.2.3] It should be possible to issue one certificate for each service running on the machine/VM

[2.2] Service Management

[2.2.1] Allow unique identification of services and applications

[2.2.2] Provide means to define and associate policies or groups of polices to a collection (group) of applications/services running on a machine or a group of machines. (NOT Planned)

[2.2.3] Implement an option to automatically create service principal and/or certs when a new service is setup (later than machine join)

[2.2.4] Should be easy to give the same service principal to multiple services on different machines (cluster use case)

[2.2.5] Service principals and/or service certs should be easily to generate and manage

The following service related work is currently planned:

Creating service via UI as in v1

Provisioning service keytab (ipa-getkeytab) - same as in v1

Provisioning certificates for services. Certs will be stored in the service record

The UI will be modified to be more user friendly as a part of the whole UI rework effort.

The services will be associated to the hosts they run on base on the host name which is a part of the kerberos principal

The following service related work is currently not planned:

Handling cluster use cases

Sharing of the kerberos principals between services

No policy management

3. Extensible (Plug-in) Architecture / Framework

[3.1] IPA should be built with an extensible framework that supports addition of multiple different features and capabilities as add-ons. It is implied that a feature can be represented by a collection of packages that by itself constitute plug-ins, modules and scripts of different nature.

[3.3.1] Features should be able to provide schema that is picked up by the GUI

[3.3.2] Existing entries should be dynamically updated with default values where required by the new Schema

[3.3.3] Features shall be able to be installed into IPA easily

[3.3.4] The GUI may be restarted to reflect new plug in UI elements

[3.3.5] It shall be possible to deploy feature elements (plug-ins) in an asymmetric fashion on different IPA servers. For example, a schema for a feature is deployed on all IPA replica instances but the UI plug-in and XML-RPC service will only run on a single IPA sever.

[3.4] Rework schema to support extensible architecture

[3.5] Plugins shall be self identifying

[3.6] It should be possible to list/activate/deactivate plugins from the GUI

[3.7] It should be possible to resolve inter-plugin dependencies

[3.8] Need to provide a way for customers to define scripts to be run when certain actions are performed.

This work is core and planned.3.6 is deferred (if not dropped)

4. Kerberos

No work planned other than consulting.

[4.1] Kerberos Functionality

[4.1.1] Kerberos shall work and be easy to use - We are not going to do any modfications to KDC relative to v1.

[4.1.2] It shall be easy to configure Kerberos for the following: Current implementation of the services provides enough. We will consult other teams on how to kerberise their products.

[4.1.4] Allow Kerberos principals to be known by multiple aliases. For example, clients do not have to know a mail or web server's fully qualified domain name in order to authenticate. An alias or short name should be sufficient. Requires protocol changes and standards work - deferred.

[4.2] Kerberos Integration (might be deferred)

[4.2.1] Currently much of the Kerberos Service (KDC) configuration information is stored in files on the local file system. This makes replication problematic. Kerberos configuration shall be stored in the Directory so it can be replicated throughout the IPA infrastructure Requires changes to KDC. We are not planning to implement these changes in v2. It is big effort - deferred.

[4.2.2] Improve the DS schema to store Kerberos related information (user info & config info) Requires changes to KDC. We are not planning to implement these changes in v2. It is big effort - deferred.

5. Certificate and Registration Authority Integration

[5.1] Include a certificate authority and registration authority as part of default server installation and configuration

[5.1.1] No other Certificate system components will be included in this release

[5.1.2] No key escrow DRM

[5.1.3] No token management or token key smart card components

[5.1.4] No OCSP responder

[5.2] The included CA will automatically publish CRLs

[5.2.1] All certs issued will include the CRL location

[5.3] Certificate Authority will be used to issue the machine and service specific certs

[5.4] In this version, there will only be support for machine and service certificates. There will be no support for user certificates for authentication, signing, encryption

[5.5] It should be possible to store Certificates and key material in either flat files or an NSS database

Planned. Accomplished mostly by the CS team.No plans to support CRL checking by the client components that connect to the server using SSL (XML-RPC, audit). We are considering mechanism to dirstibute cert needed for this using DS and LDAP lookup.

6. Policy

THE WHOLE SECTION IS DROPPED.

[6.1] Policy management and definition

[6.1.1] Policy language should be declarative and analyzable.

[6.1.2] Policy should be stated once in a high-level, platform neutral way and then translated to platform specific controls.

[6.1.3] Policy language should be standards-based if at all possible.

[6.1.4] It may be acceptable to use an already existing, prevalent method of specifying policy.

[6.1.5] If an application already has policy definitions it may be possible to manage those definitions in IPA. Over time it is desired that these 3rd party policy definitions will be rewritten as described above.

[6.1.6] Allow the same centrally managed policy to be presented in different formats to different applications (policies might be stored in a generic format but then translated into different formats by application specific plug-ins or converters).

[6.1.7] IPA policy storage and management engines shall be extensible so that new policies can be dropped in, managed centrally and delivered through existing IPA channels to the requesting application.

[6.1.8] Policies (access control policies) shall (among others) include limiting of access to applications / tools to controlling the editing of configuration files or data.

[6.1.9] The policy types supported by the IPA system may include:

Sudoers files

SELinux policy files

[6.2] The policy management and policy delivery mechanisms shall be optimized to reduce:

[6.2.1] Number of long lived network connections (if any).

[6.2.2] Policy download network traffic (what to cache and how frequently to refresh).

[6.2.3] Number of client requests and round trips to determine which policies apply to the machine and need to be downloaded or refreshed.

[6.3] Policy enforcement

[6.3.1] Policy should be enforceable by applications that are not part of IPA (i.e., IPA Policy should serve as a platform).

[6.3.2] Policy decisions should be obtainable from a language-neutral source and if possible through standard interface.

[6.3.3] Policy controls should initially target machine policies but be capable of controlling service applications.

[6.3.4] Policy enforcement decision shall be based at least on the following factors:

User identity

User role

System/Machine identity

Application/service requesting identity check

Resource/service/application being accessed

Time of day/date

Network location/topology (inside/outside firewall)

[6.4] Access Control

[6.4.1] Create mechanisms to deliver access control policies to the applications. The policies can be delivered in different ways:

[6.4.1.1] Directly via API. Application calls API to perform authorization checks. It is implementation specific whether it is an API that makes the application a direct client of the IPA server itself or a local API that allows application to connect to local IPA service (IPA client component) that abstracts the IPA server capabilities (provide early in the project cycle)

[6.4.1.2] Via application specific configuration files

[6.4.2] Following applications shall receive access control information (policies) from IPA system. The preferred channel (API vs. File) is application specific and shall be determined based on the application needs and capabilities. Applications are:

[6.6] Need meta group. Group which groups up groups of users, machines, services, hosts - We might not do this if it deems not the solution (Not a solution)

[6.7] The design of the IPA shall allow for other types of the authentication (2FA, 3FA etc.) be used. Vendors should be able to build their strong authentication solutions and integrate into the realm without conflicting with IPA. It should not only be allowed but allow vendors to provide password hiding capability – user never knows his password he just uses token or smart card. This means that these solutions should be able to inject themselves into the authentication sequence, intercept provided credential (OTP for example) and replay kerberos password (that it stores in its database) back to IPA as if user provided password. The impact on the already existing products shall be minimized (do not change interfaces, try to be compatible with what already exists). The alternative types of the authentication shall be allowed in the following scenarios:

Machine enrollment and keytab provisioning

User authentication into the box via PAM

User authentication via SSH

Apache authentication to Web site

This is a design requirement. The actual implementation will be deferred. (Was considered but no hooks will be implemented.)

[6.8] There should be a way to centrally control preventing user logging into the machine (server side enforcement). This would require buy in from Kerberos community and might be deferred. (Not possible)

[6.9] Implement centralized management of the roles for the needs of the different applications including but not limited to:

[7.3] IPA server must support clients and client configurations released in IPA v1 version. (Planned)

[7.4] IPA client shall be a provider of the IPA services to all applications and services running on the machine. (Planned)

[7.5] IPA client shall provide IPA services to the applications regardless whether the machine is connected to the IPA server (server is reachable) or machine is offline (server not reachable). There is no requirement for the applications to take advantage of the provided services. The applications until explicitly mentioned are not outside of the scope of the current PRD. (Planned)

[7.6] IPA must be capable of providing AAA functions to the following explicitly listed applications providing time allows to implement a corresponding plug-in (Planned)

[7.6.1] Enroll – make the machine a part of the IPA domain. During enrollemen the new certificates and keytab are provisioned. If enroll is run twice without the cleanup in between it should either: (Planned. Implementation details might be slightly different.)

[7.6.1.1] Return an error and ask the user to run the "Disconnect" operation first.

[7.6.1.2] Assume that this is a "rebuild" operation and cleanup and reprovision everything automatically.

[7.6.2] Disconnect – remove all the configuration related to the IPA realm. (Planned)

[7.7.2] IPA client software shall automatically discover IPA server configuration and topology. Client shall connect to the closest (best) server out of the list of available servers. Client shall always try to use the closest server it can detect. (Planned)

[7.7.3] IPA client shall automatically fail over to a different IPA server if its “preferred” IPA server is not available. (Planned)

[7.7.5] IPA client offline state shall not affect response time of the IPA client services to applications. (Planned)

[7.7.6] IPA client shall be capable of caching all necessary information about user that had logged in at least once to be able to provide them services offline. The cached information shall have an expiration limit. After the specified period of time the cached data shall be discarded. (Planned)

[7.7.7] Define and apply IPA centrally managed policies regarding offline entities. Create and enforce the policy for how long the user offline information is cached (90 days default) and what to do if time elapsed (discard). (NOT Planned.)

[7.7.8] IPA client shall download and cache policies required for operation of the applications/services running on the box. If the box goes offline or IPA servers become unreachable the applications continue to function without disruptions.(NOT Planned)

[7.7.9] On reconnect to the IPA server, the IPA client shall resync/refresh/renew cached credentials, keytabs, certs and other downloaded entities (policies and configuration information for applications) based on the centrally defined and managed policies. (Partially - no policy or kerberos key refresh)

[7.7.10] For the system to automatically join IPA realm without re-prompting user when IPA server connection is restored the password shall be cached on the system. There shall be a policy to allow or disallow caching clear text password. (Similar functionality is planned but we do it differently. )

[7.7.11] In case of outage a lot of users will be trying to connect to IPA domain again, authenticate and download policies. This might cause a huge load on the server. Create a solution (may be just doc) to describe how to reduce the risk of overwhelming the server (have more servers...). (Considered in designs but no further action is planned so far)

[7.7.12] Reduce the amount of data to download or refresh. (Planned)

[7.7.13] IPA Client shall work correctly whether it is connected to the IPA server via local network or VPN. (Planned)

[7.8] Post installation, if required by enterprise policy, change the root password on a device to a pre-configured one found during the configuration phase (or possibly randomized). The device is now "owned" by the administrative domain. Check that the password is the same as the one centrally defined and if not reset. Log the event. (Deferred)

[7.9] IPA client shall automatically renew user TGT according to the centrally defined polices. This shall be done to avoid failures of the operations that take extensive period of time to run. (Deferred. Not included into the task breakdown. Only the machine TGT renewal is planned)

[7.10] On the client and server sides there should be a process that would monitor the system and restart components that has crashed. (Planned)

[7.11] Address following bugs: 442680, 454896 (clone of 445754) (Deferred. It is pretty much same as [7.9])

[7.12] IPA Client install shall have an option to enable pam_mkhomedir cfg. (Have not been evaluated but might be doable without requiring extra time)

[8.1.2] Create a way to migrate user passwords without affecting user experience. One of the ides it to use pam_krb5_migrate. (Planned)

[8.1.3] A standard IPA input format will be defined so if a customer wishes to migrate data from a directory that uses non-standard schema or layout they will need to export their data and map it into this input format. (Planned)

[8.2.3] Allow NIS information to be loaded into LDAP back end from the existing NIS configuration files (Dropped. Customer would have to deal with this part himself. Sample script are available in the nis plugin package in the documentation directory)

[8.2.4] Since passwords can't be migrated, provide a way for the self-service password reset. There should be a special procedure to migrate passwords. (Planned but done differently)

[8.3] Manage netgroups in IPA server. (Planned)

[8.3.1] Include netgroups response capabilities in IPA as part of NIS service. (Planned)

[8.3.2] Store netgroups information in LDAP back end. May not use the standard schema. (Planned)

[8.3.3] Allow netgroups information to be loaded into LDAP back end from the existing netgroups configuration files. (This will be accomplished using virtual directory product and thus not and IPA requirement)

[9.5] Allow centralized management of the filtering policies on per feed type per machine bases.

[9.6] Feed providers should be authenticatable

[9.7] The audit system shall define, manage, and enforce central policies related to the internal event feed (shall include but not limited to: events related to machine, service rename as well as change of other principals)

[9.8] Logs shall be consolidated in the central place(s)

[9.9] Future versions may require that Logs shall be signed to prevent tampering with them in transit.

[9.10] Log data should be archiveable. Those archives must be highly compressed and optionally encrypted.

From here the use case is same as the remote access use case above. Getting on the WLAN doesn't get them on the corporate network. It just gets corporate Internet access. They have to get onto the VPN to get corporate acccess.

[11.5.4] 802.1x based WLAN. This is where WLAN's are going and many corporations have them deployed.

End user connects to Wireless LAN which is secured with 802.1x and WPA