Here are the most frequently asked (technical) questions by people about Red Hat Enterprise Identity (IPA) from this past week at the Red Hat summit.

Question:  What is it?

Answer:  IPA is a domain controller for Linux/Unix environments. For the Linux/Unix world it does what Active Directory  does in the Windows world, but following open standards and by the means of open source software.  It is an identity management solution that integrates MIT Kerberos, LDAP via Red Hat Directory Server, DNS via Bind with an LDAP back end, and a Certificate Signing Authority (Dog Tag).  Its administration framework is a Python based server that runs inside Apache HTTPD.

Question:  We already do Kerberos and LDAP.  What does IPA provide beyond that?

Answer: Policy. Interfaces

First of all we have Host Based Access Control.  The example I gave was a rule that enforced that people in the consultants group could only sign in to hosts in the Staging server host group from workstations in the the Hotel hosts group. This is enforced by SSSD on the hosts.

Second. centralized Sudo.  This is a standard LDAP extension for nsswitch.  As a note, we have a Google Summer of Code project that is going to put support for Centralized Sudo into SSSD.  More on this later.

Third.  ACI based delegation.  Group delegations, which means that members of one group are able to modify attributes of another group.  Modification of the permissions for Self Service.  Role Based delegation.

Fourth: Certificate Management.  IPA has an integrated Certificate Server.

Also LDAP and Kerberos are usually not integrated that well, which  creates a management burden. The setup is usually very fragile and requires a lot of domain expertise. IPA is much more manageable and much more tolerant to the changes in personnel.

For interfaces, we have a  command line that provides management of all this functionality.  We also have a pretty nifty web interface, if I do say so myself.

Question: What about PAM services?

Answer: IPA is a central server that provides identity and authentication. The preferred client component is SSSD but it can be configured with other pam modules like pam_ldap and pam_krb5. With SSSD IPA can provide additional features like centrally managed host based access control. See the above policy answer for more info.

Question:  How does it integrate with Active Directory

Answer: We have winsync and pass-sync capabilities.  This involves installing plugins on the AD PDCs. Users are synchronized from AD to IPA, passwords both ways. Groups are not synchronized.

Question:  What about high availability?

Answer:  IPA has replication performed at the LDAP Directory Server level.

The next two questions address future capabilities:

Question:  We already have a centralized Kerberos Server, but we want the rest of the functionality.  How can we do that?

Answer:  We are working on Cross Realm Trusts.  It will be in a later version of FreeIPA.  This means that the KDC for the IPA  realm will accept requests from the TGT granted by the higher realms KDC.

Or you can migrate to IPA. There are a lot of strategies how things can be migrated. We have a chapter about this in the docs.  It is based on the following page:
http://obriend.fedorapeople.org/freeIPA2.0/Identity_and_Policy_Management_Guide/html-single/#chap-Enterprise_Identity_Management_Guide-Migrating_from_a_Directory_Server_to_IPA

It talks about Directory Server but the Kerberos would be similar from approach point of view.

Question: What about (insert two factor authorization mechanism here).

Answer:  Kerberos 1.8 has support for two factor authentication.   This is a relatively recent addition to the Kerberos libraries, and we are just now working on integrating it into the overall system.  We have a proof of concept of an external key store  working (Ubikey), but not yet ready for production.  We have a sub project getting way for people to provide their particular 2FA implementations: https://fedorahosted.org/AuthHub/