.. highlight:: none

Global Catalog Lookups in SSSD
==============================

Related tickets:

-  `RFE Use the Global Catalog in SSSD for the AD
   provider <https://pagure.io/SSSD/sssd/issue/1557>`__
-  `RFE sssd should support DNS
   sites <https://pagure.io/SSSD/sssd/issue/1032>`__

Problem Statement
~~~~~~~~~~~~~~~~~

Currently SSSD uses the standard LDAP interface of Active Directory to
lookup users and groups when joined to an Active Directory domain. But
the LDAP interface only offers information for users and groups of the
local domain and not from the whole forest. This information is
available in the Global Catalog of an Active Directory domain.

To make lookups of users and groups from the whole forest easier SSSD
should use the Global Catalog instead of the standard LDAP interface for
the lookups.

Additionally SSSD should provide an interface to allow other
applications to do Global Catalog lookups. Initially it is sufficient to
offer SID-to-Name and Name-to-SID lookups if SSSD is running on an IPA
server.

Overview view of the solution
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

General components
^^^^^^^^^^^^^^^^^^

Service discovery
'''''''''''''''''

#. DNS lookup for any AD DC
#. CLDAP query to find the site of the client
#. DNS lookup for a Global Catalog server from the local site, fall back
   to any Global catalog server

Authentication against the Global Catalog
'''''''''''''''''''''''''''''''''''''''''

GSSAPI with keytabs will be used for authentication.

If the SSSD client is joined to an AD the keytab is created during the
join process.

If SSSD is running on an IPA server with trust configured, the keytab
will be generated by samba. It has to be created and updated when trust
is established or the trust password is changed. Additionally there
should be a method to generate the keytab if it does not exist even if
there is no change in the trust state.

New NSS-Responder calls for SID-to-Name and Name-to-SID lookups
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Two new calls should be added to the NSS-Responder to give other
applications (the first user would be the FreeIPA directory server) a
simple interface for SID-to-Name and Name-to-SID lookups. It has to be
sorted out if and how those two new call will interact with lookup by
SID feature described in
`#1559 <https://pagure.io/SSSD/sssd/issue/1559>`__ "Use the
getpwnam()/getgrnam() interface as a gateway to resolve SID to Names".

Memory cache for the new lookups
''''''''''''''''''''''''''''''''

To speed up lookup the new calls should be able to use the memory cache.

Implementation details
~~~~~~~~~~~~~~~~~~~~~~

Since the Global Catalog is just an LDAP server running on a
non-standard port the general LDAP lookup code would not need much
change if any. But resolving the Global Catalog server would be a bit
different because before the actual DNS service record lookup the site
has to be determined.

I think it is sufficient to determine the site on startup and when SSSD
switches from offline to online.

To decode the blob returned by the CLDAP request libndr-nbt from the
samba4-libs package would be useful. Since libndr-krb5pac is already
used in the PAC responder I think it is ok to add this new dependency
here.

Environments with trusts
^^^^^^^^^^^^^^^^^^^^^^^^

In an environment with trust it must be possible to handle multiple open
connections to Global Catalogs of different forests.

According to
`http://technet.microsoft.com/en-us/library/cc772808%28v=ws.10%29.aspx <http://technet.microsoft.com/en-us/library/cc772808%28v=ws.10%29.aspx>`__
referrals are used during Kerberos requests to guide the client to the
right KDC. I have not found a similar document for LDAP requests to the
Global Catalog. I have to find out if it is possible to work with
referrals here, too or if it is needed to read the trusted domain
objects
(`http://msdn.microsoft.com/en-us/library/cc223754.aspx <http://msdn.microsoft.com/en-us/library/cc223754.aspx>`__)
from the Global Catalog.

New NSS responder calls
^^^^^^^^^^^^^^^^^^^^^^^

How to test
~~~~~~~~~~~

Since the Global Catalog lookups just replace the current lookup methods
SSSD should just behave as before (Regression testing).

Additionally the following changes might be visible on the user or admin
level.

AD provider
^^^^^^^^^^^

If the SSSD client is joined to a Windows domain which is part of a
forest, Global Catalog lookups should be able to resolve all users and
groups in the forest and not only the ones from the joined domain.

IPA provider running on a FreeIPA server
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

If the FreeIPA server is able to use SSSD for SID-to-Name and
Name-to-SID lookups running winbind on the FreeIPA server is not needed
anymore.

Author(s)
~~~~~~~~~

Sumit Bose <`sbose@redhat.com <mailto:sbose@redhat.com>`__>