[Freeipa-users] external ad users in ldap directory is it possible in general?

[Alexander Bokovoy]

On Mon, 06 Jun 2016, Serge Krawczenko wrote:
>Hello,
>my apologies if the question is  asked too frequently
>
>While implementing an SSO in my environment, i have a need to integrate
>with existing AD Win2008R2.
>The systems i need to be included into SSO can only authorize via LDAP,
>many of them have been already configured and tested against FreeIPA and
>local users. Those systems are apache, jira, radius and so.
>
>However, how is it applicable for external users from windows AD?
>Trusted relations have been configured according to manual.
>
>As stated in FreeIPA 4.3 release notes,
>
>"AD users are now shown as members of IPA groups when external group is
>added to IPA group #4403"
>
>So i expect external users to be visible by ldapsearch etc on FreeIPA upon
>corresponding groups mapping. Well, no. Users are not visible.
>
>Please advise is this achievable at all or do i have some fundamental
>misunderstanding of the technology or is there some misconfiguration?
Yes, you have fundamental misunderstanding.

FreeIPA is not a meta-directory unlike other solutions that attempt
to integrate with Active Directory. Our approach is different and is
more effective, in our view.

FreeIPA presents itself as another Active Directory deployment to some
degree. Most features AD expects don't really work but authentication
and basic authorization works just fine. We rely on this to allow
pulling the data from AD DS (and GC) on request but we never store this
information in FreeIPA directory by itself.

SSSD on FreeIPA clients recognize situations when FreeIPA trusts AD and
ask FreeIPA masters for the information about AD users and groups. This
information then can be used by other applications which authenticate AD
users and check permissions based on the group membership -- in both AD
and FreeIPA.

LDAP directory server has a particular structure that is enforced
through the use of LDAP schema -- object classes define which attributes may
or may not exist in the objects stored in the LDAP directory. The schema
FreeIPA uses differs from the schema used in Active Directory. Not only
some fundamental object classes are different (including naming of
attributes), but also internal identifiers assigned to these
objectclass and attribute objects are different between FreeIPA and
Active Directory, even to the point that some are different even for
objects that are otherwise the same in their behavior. This is
fundamental difference of Active Directory LDAP store from traditional
UNIX LDAP stores.

FreeIPA doesn't store complete AD user/group objects in LDAP.  However,
a schema used by FreeIPA to represent objects' relationship, requires
that object do exist in the LDAP store and can be addressed by their
DNs. When 'external users and groups' are mentioned in the context of
FreeIPA forest trust to Active Directory, these are not real LDAP
objects but instead are references -- strings of data stored as part of
a so-called 'external group' LDAP object. This LDAP object is a real one
and can be included as a member into any other LDAP object in FreeIPA
that could have members (POSIX groups, permissions, etc.).

SSSD on FreeIPA clients are capable to resolve these special 'external
group' objects by taking the references (stored in a separate attribute)
and resolving them via a different mechanism than LDAP. Then they
combine resulted data together with IPA users/groups/etc objects and
present a combined result to the operating system.

As you can guess, it requires SSSD running on IPA client. And it
requires your application to use POSIX API to query users/groups and
their membership. For applications that don't do that, we have created a
number of integration modules -- for Apache you can read about them at
https://www.freeipa.org/page/Web_App_Authentication and related
resources from Jan P. (https://www.adelton.com). For more complex
software integration via SAML IdP or OpenID Connect and other mechanisms
is provided as well -- see https://ipsilon-project.org/

For those cases where you cannot really run recent SSSD that understands
IPA-AD trust, we have something else -- a special read-only virtual tree
called Schema Compatibility tree. This is a special plugin at FreeIPA
LDAP server that takes data of IPA users and presents them using an
older POSIX schema defined by RFC2307. We extended this plugin to allow
querying for AD users via SSSD on FreeIPA master. When a request of
special type (as performed by all POSIX LDAP clients -- nslcd, sssd,
nss_ldap, etc) comes in and this user/group is not found in IPA
database, a request is made to SSSD on the same FreeIPA master in an
attempt to lookup an Active Directory user or group.

This work requires a lot of coordination between FreeIPA, SSSD, and
slapi-nis project (which implements Schema Compatibility plugin). Very
recently (as of February-May 2016) we fixed a number of important bugs
in all three of those to allow full expansion of user group memberships
between IPA and AD. So this code, for example, is in the recent RHEL
7.2.4 or corresponding update of CentOS 7, but not in Fedora 23 (it is
in Fedora 24 though).

Instead of pointing your application directly to LDAP, we recommend
to use other means which are more efficient from a performance and
caching perspectives.

For example, for Jira, I'd recommend to use SAML 2.0 connector and
Ipsilon: https://marketplace.atlassian.com/plugins/com.resolution.atlasplugins.samlsso.Jira/server/overview
should be enough on Jira side.

For Apache -- use modules written by Jan P.

For RADIUS situation is worse but at least you can point FreeRADIUS to
both FreeIPA and AD DS at the same time.

If nothing works, then Schema Compatibility is a final stop. However,
because of the way it presents the data, all users there are present
only with RFC2307 schema and AD users are inserted on request, and these
requests are of special format as required for POSIX ID operations.
You can read more about it at
https://git.fedorahosted.org/cgit/slapi-nis.git/tree/doc/ipa/sch-ipa.txt
-- 
/ Alexander Bokovoy