#69 Add the Partial Attribute Set design page
Merged a year ago by jhrozek. Opened a year ago by jhrozek.
SSSD/ jhrozek/docs pas  into  master

file modified
+1

@@ -27,6 +27,7 @@ 

     enhanced_nss_api

     attestation_report

     kdcinfo_improvements

+    posix_attrs_detection

  

  Implemented in 1.15.x

  ---------------------

@@ -0,0 +1,148 @@ 

+ .. highlight:: none

+ 

+ Detecting POSIX attributes in Global Catalog using the Partial Attribute Set

+ ============================================================================

+ 

+ Related ticket(s):

+ ------------------

+     https://pagure.io/SSSD/sssd/issue/3755

+ 

+ Problem statement

+ -----------------

+ In some environments with SSSD clients joined directly to an Active Directory

+ realm, replicating POSIX attributes such as ``uidNumber``, ``gidNumber`` or

+ ``unixHomeDirectory`` to the Global Catalog might provide a substantial

+ performance benefit. As an example, if the numerical IDs are replicated

+ to the Global Catalog, then the SSSD is able to locate the domain the ID

+ resides in without iterating over the other domains.

+ 

+ However, the POSIX attributes are not replicated by default, so the SSSD

+ must check whether the attributes are replicated or not. There was a

+ straightforward check in SSSD which just ran a lookup for any entry with

+ POSIX attributes since several versions ago. In large environments, though,

+ this check was very inefficient and causing a high load on the servers.

+ 

+ This design page describes a different method of detecting the POSIX

+ attributes by inspecting the AD schema instead.

+ 

+ Use cases

+ ---------

+ An SSSD client joined to an Active Directory domain directly. The AD domain

+ must be using POSIX attributes for user and group IDs, the changes in this

+ design page are irrelevant for domains that use ID mapping.

+ 

+ Overview of the solution

+ ------------------------

+ Instead of issuing a wide search for any object that contains the

+ ``uidNumber`` or ``gidNumber`` attribute, the SSSD will consult the

+ `Partial Attribute Set <https://social.technet.microsoft.com/wiki/contents/articles/23097.active-directory-attributes-in-the-partial-attribute-set.aspx>`_

+ which defines what attributes are replicated to the Global Catalog.

+ Which attributes are members of the Partial Attribute Set is described below.

+ 

+ In general terms, all attributes in the Active Directory schema

+ are represented by objects with the objectclass  `attributeSchema

+ <https://docs.microsoft.com/en-us/windows/desktop/AD/characteristics-of-attributes>`_.

+ 

+ The ``attributeSchema`` objects as well as all objectclasses

+ are exposed through a subtree called the `Schema Naming Context

+ <https://docs.microsoft.com/en-us/windows/desktop/ad/naming-contexts-and-partitions>`_

+ 

+ The Schema Naming Context is exposed typically at the

+ ``cn=schema,cn=configuration,$FOREST_BASE_DN`` subtree, but its location is most

+ portably read from the ``schemaNamingContext`` attribute of the rootDSE.

+ One important thing to note about the Schema Naming Context is that its

+ location is the same across all DCs in the forest.

+ 

+ Each attribute is represented as an object under the schema

+ subtree and whether the attribute is replicated into the Global

+ Catalog or not is denoted by the `isMemberOfPartialAttributeSet

+ <https://msdn.microsoft.com/en-us/library/cc221098.aspx>`_ attribute value.

+ 

+ This search in an example domain called ``win.trust.test`` might be issues with::

+ 

+     ldapsearch -LLL -Y GSSAPI \

+                -H ldap://dc.win.trust.test \

+                -b cn=schema,cn=configuration,dc=win,dc=trust,dc=test \

+                '(|(cn=uidNumber)(cn=gidNumber))' \

+                isMemberOfPartialAttributeSet

+ 

+ And the result, this time showing that neither attribute was replicated to the Global Catalog might look like::

+ 

+     dn: CN=GidNumber,CN=Schema,CN=Configuration,DC=win,DC=trust,DC=test

+     isMemberOfPartialAttributeSet: FALSE

+ 

+     dn: CN=UidNumber,CN=Schema,CN=Configuration,DC=win,DC=trust,DC=test

+     isMemberOfPartialAttributeSet: FALSE

+ 

+ As said earlier, the Schema Naming Context is the same across all domains in

+ the forest, so the search against a DC in a child domain would work as well

+ even though it's also based at ``CN=Configuration,DC=win,DC=trust,DC=test``::

+ 

+     ldapsearch -Y GSSAPI \

+                -H ldap://childdc.child.win.trust.test \

+                -b CN=Schema,CN=Configuration,DC=win,DC=trust,DC=test

+                '(|(cn=uidNumber)(cn=gidNumber))' \

+                isMemberOfPartialAttributeSet

+ 

+ 

+ Implementation details

+ ----------------------

+ First, the rootDSE parsing code must be extended to read the

+ ``schemaNamingContext`` attribute from the rootDSE object and store it in

+ the ``sdap_options`` structure.

+ 

+ The search itself will be issued in the subdomains provider. Placing the

+ search in the subdomains provider instead of the handlers or the searches

+ makes it possible to remove much of the previous code as the subdomains

+ provider request is guaranteed to be executed before any user or group

+ request except for cases where the subdomains provider is explicitly

+ disabled with ``subdomains_provider=none``, but in that case it makes

+ little sense to use the Global Catalog in the first place.

+ 

+ Because of the property of the schema partition being replicated to all

+ DCs in the forest, the search can always be run after the SSSD connects

+ to the joined domain which triggers reading the rootDSE.

+ 

+ If neither or only one of the attributes would be found, the Global Catalog

+ support will be disabled. The same would happen in the case that the check

+ fails with an error as the Global Catalog itself is not required for SSSD

+ to function at least in a degraded mode.

+ 

+ The search as described in the previous section would be issued using the

+ LDAP connection, in particular the connection to the joined domain. The

+ LDAP connection must be used because the ``isMemberOfPartialAttributeSet``

+ attribute is typically not replicated to the Global Catalog itself. 

+ 

+ The old request (``sdap_gc_posix_check_send``) can probably just be

+ completely removed.

+ 

+ Configuration changes

+ ---------------------

+ None.

+ 

+ How To Test

+ -----------

+ With an AD client that uses ID mapping, the request should not be ran

+ at all. The same is true if the Global Catalog support is explicitly

+ disabled by setting ``ad_enable_gc=false``.

+ 

+ With an AD client that uses POSIX attributes, the subdomains provider should include a search such as::

+ 

+     [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectclass=attributeSchema)(|(cn=uidNumber)(cn=gidNumber)))][cn=schema,cn=configuration,DC=win,DC=trust,DC=test]

+     [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn]

+     [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [isMemberOfPartialAttributeSet]

+ 

+ If this search does not match the ``uidNumber`` and ``gidNumber`` schema

+ objects or of the objects are not replicated to the global catalog, the

+ Global Catalog support would be disabled irrespective of the ``ad_enable_gc``

+ configuration option value.

+ 

+ How To Debug

+ ------------

+ The request is decorated with debug messages as usual.  In addition to

+ looking at the usual debug logs, ``netstat`` might be a handy tool to

+ check what port is SSSD connecting to.

+ 

+ Authors

+ -------

+  * Jakub Hrozek <jhrozek@redhat.com>

rebased onto 711eb74

a year ago

No comments, so I'm going to merge the design page since the code had been merged as well.

Pull-Request has been merged by jhrozek

a year ago