Red Hat Identity Management Id M Presented by

Red Hat Identity Management (Id. M) Presented by Rich O’Hare

History of Id. M 1. Fedora 9 - Free. IPA Project (2008) 2. Red Hat 6 - Optional IPA software 3. Red Hat 7 – Base component installed by default, rebranded Id. M

Primary Goals 1. Centralize identity management and policy management. 2. Linux-based and Linux-controlled domain. 3. Build on existing, native Linux applications and protocols.

Advantages • Id. M can serve as a bridge between Linux and Windows when used in concert with Cross-Realm Kerberos Authentication. • Windows and Linux cooperate in terms of identity, authentication and authorization.

Identity Management doesn’t make administrators do something new; it helps them do it better.

Replication

Integration with AD

Trust Components

Alternatives to Id. M • Samba Winbind • Dell Authentication Services Vintela Authentication Services (VAS) Quest Authentication Service • Centrify

Trust Environment Requirements • Supported Windows Platforms – Windows Server 2008 R 2 – Windows Server 2012 R 2 • Id. M needs it’s own Kerberos realm and DNS zones. • Id. M does not support DNS Views • Reliable time synchronization

Controlling AD User Access • • Windows users, access to Linux resources is controlled by AD group membership. However, Active Directory users cannot be added directly to a POSIX user group. Active Directory users get access in a daisy chain process. They are added to a group on the Active Directory side, then that group is added to an Id. M external group (meaning, a non-POSIX group), and then that external group is added to a local POSIX group as a member. The POSIX group can then be used for user/role management of Active Directory users.

Dogtag Certificate System Kerberos can use certificates along with keytabs for authentication, and some services require certificates for secure communication. Identity Management includes a certificate authority, through Dogtag Certificate System, with the server. This CA issues certificates to the server, replicas, and hosts and services within the Id. M domain. The CA can be a root CA or it can have its policies defined by another, external CA (so that it is subordinate to that CA). Whether the CA is a root or subordinate CA is determined when the Id. M server is set up.