Bug 1362272

Upstream ticket:
https://fedorahosted.org/freeipa/ticket/6208

this RFE may depend o/greatly benefit form Global Catalog RFE

The question is *where* to get that email information. We don't have
means so far to get it from SSSD via standard POSIX API we use. Since
there is no place to retrieve emails for AD users from, there is no
support for this.

Such support theoretically could be added but it will further complicate
slapi-nis code. We are in a process of refactoring the latter for other
means and will at some point be able to add such support after changing
how slapi-nis stores its database information. Current code is very
fragile in terms of adding new sources of information with unpredictable
latency (SSSD has D-Bus interface for extended attributes).

Adding this information would also require us to rethink access controls
to the compat tree. Right now information about POSIX attribute is
available without authentication because you'd get it from your POSIX
system without authentication anyway. Adding emails would mean a need to
change that. A change like this is not easy for existing deployments.

This work is currently not planned for RHEL 7.

As a customer, I can understand the technical challenges. In our use case in our corporate world our 77 linux engineering users need both SSSD/ssh login and LDAP auth login mapping equivaency so their web services act exactly like the linux hosts systems using SSSD. 

This is key to sharing same source including group mappings and RBAC all defined in IDM. Having IDM groups map to AD groups but an LDAP service cannot see the same poses barriers, poses strong operational issues trying to realize IDM as the go between  gateway for LINUX <--> AD identity.

Not being able to map and translate all user attributes and group memberships through LDAP -> IDM -> AD causes a real disconnect in group management on both planes.

Please note that Compat tree is not exposing any RBAC rules by itself. It is not supposed to be used for those use cases which go outside of serving an nsswitch support on legacy clients (systems that cannot use SSSD for identity and access control) and as such is limited to RFC2307 objectclasses and attributes for most.

If you need to expose RBAC information to web services, I strongly suggest looking into integrating IdM with an IdP system, like RH SSO (Keycloak upstream) and then using SAML2 or OpenID Connect to provide all required details to those web services via assertions given by the IdP. When SSSD is used as a backend to RH SSO, it provides both the details you need and applies RBAC rules you need.

Compat tree is simply a wrong place to apply these decisions.

The current Global Catalog work will help this to be possible. Deferring until that work is complete.

Closing this for now.

Still a very significant issue in our deployment where IDM is a Kerberos trusted domain/realm from AD. Email/Mail attribute exists in active directory today, but that attribute does not get passed through to IDM. So any regular application service can lookup users in IDM via LDAP but when the application wants to send the user mail (i.e. initial logon, password reset) it tries to send mail to the IDM domain, which has none. So instead of mailto://<user>@ActiveDirectory.com it sends to mailto://<user>@IDMDomain.com which never arrives anywhere.

There are ways to do lookups and alter MTA aliases in IDM might work-around but they are all hard to manage at scale, and break the basic model.

Ernie, as I said in comments 6 and 10, use of compat tree is not designed for what you are wanting to achieve. This is not going to change. If anything, compat tree support might disappear in future releases.