When legacy systems connect to IPA they need UID/GID for the users they look up. When there is a trust relationship between IPA and AD there are no UIDs replicated to IPA so it is hard to provide anything to the legacy systems. To solve this problem we decided to create a new DS plugin.
This DS plugin will work similarly to the compat plugin.
- It will expose a tree but it will get it by quering SSSD using a getpwnam/getgrnam interface. It will create RFC2307 (not bis) objects. - Authentication would also go through SSSD via PAM-PASSTHRU from the directory server. - A special research should be conducted around handling of the TGT that is stored on the IPA server in this case. It is unclear what should be done with it. - The compat tree should also deal with user name normalizations and expose only short names however there should be a clear way to deal with collisions in this case. May be it should be a configuration option of the plugin that would define the precedence, i.e. whether IPA user wins over the AD user or vice verse. Colliding AD users might be a challenge too and might require special handling and logging. - Since group enumeration is needed by legacy clients e.g. to look up all groups a user is member of (initgroups()) it makes sense to enable enumeration for the AD lookups in SSSD on the server. The impact should be investigated.
Related SSSD ticket is https://fedorahosted.org/sssd/ticket/1881
There is an initial setup. There needs to be a working solution to get to the end state.
- Variants of the initial setup: - Variant 1 - There is an AD environment - Option 1: Single domain - Option 2: Multiple domains in trust relationships (can be deferred for now) - Option 3: Multiple disconnected domains (can be deferred for now) - Users must always authenticate against AD - There is no POSIX schema in AD - A solution that does RID based ID mapping is deployed - Company wants to remove this solution because of the cost or lack of functionality and make IPA manage the Linux/UNIX infrastructure - Company want to be able to share the same user identity (UID/GID) across his whole Linux/UNIX infrastructure - Company has systems that do not run latest version of SSSD that supports trusts - Company has a subset of users that access infrastructure (usually admins) - Company would expose more Linux infrastructure (services running on Linux) to broader set of users over time. - Company would prefer that older legacy systems could use Kerberos for authentication but would be OK if it is not possible use LDAP for legacy systems - Variant 2 - Company has an AD environment - Option 1: Single domain - Option 2: Multiple domains in trust relationships (can be deferred for now) - Option 3: Multiple disconnected domains (can be deferred for now) - Company wants the users to always authenticate against AD - Company uses POSIX schema in AD - Company uses a solution that leverages POSIX schema - Company wants to remove this solution because of the cost or lack of functionality and make IPA manage the Linux/UNIX infrastructure - Company wants to be able to share the same user identity (UID/GID) across his whole Linux/UNIX infrastructure - Company has systems that do not run latest version of SSSD that supports trusts - Company has a subset of users that access infrastructure (usually admins) - Company would expose more Linux infrastructure (services running on Linux) to broader set of users over time. - Option 1: For users that did not have POSIX the UID/GID will be set in AD when user is exposed to Linux infrastructure - Option 2: For users that did not have POSIX the UID/GID should be provided by the IPA based solution (they do not care how IPA would create it, either using SID mapping or current DNA based allocation or may be in some other way) - Company would prefer that older (legacy) systems could use Kerberos for authentication but would be OK if it is not possible use LDAP for legacy systems
End Game State: All requirements are satisfied, i.e. all systems are managed in IPA, users are authenticated against AD, UID/GID is consistent across the systems. Collapsed requirements based on variants 1 & 2:
- No POSIX -> SID generated POSIX attributes in IPA and PAM passthrough for legacy systems, Trusts for new(er) systems - POSIX -> POSIX is replicated to IPA and PAM passthrough for legacy systems, Trusts for new(er) systems but with server side lookup - The mixture of two.
Bumping priority, this is one of the target features of 3.3.
Rename "trusts" component to "Trusts" to achieve correct sorting.
Moving to next month bucket.
Moving open tickets to next month bucket.
FreeIPA configuration part pushed:
master: e95a7b1
I will leave the ticket open as tracker until we also fix the slapi-nis part.
slapi-nis configuration changed a bit:
master: 7ae58f0
New slapi-nis was released, this concludes this effort and ticket:
e57a9ae Add requires for slapi-nis and SSSD[[BR]]
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1002649
Metadata Update from @dpal: - Issue assigned to abbra - Issue set to the milestone: FreeIPA 3.3 - 2013/07
Login to comment on this ticket.