From 711eb74169ba1d604961a51a34be30213a2b7173 Mon Sep 17 00:00:00 2001 From: Jakub Hrozek Date: Jul 09 2018 15:11:33 +0000 Subject: Add the Partial Attribute Set design page --- diff --git a/design_pages/index.rst b/design_pages/index.rst index b35c898..32335c0 100644 --- a/design_pages/index.rst +++ b/design_pages/index.rst @@ -27,6 +27,7 @@ Implemented in 1.16.x enhanced_nss_api attestation_report kdcinfo_improvements + posix_attrs_detection Implemented in 1.15.x --------------------- diff --git a/design_pages/posix_attrs_detection.rst b/design_pages/posix_attrs_detection.rst new file mode 100644 index 0000000..fa426e0 --- /dev/null +++ b/design_pages/posix_attrs_detection.rst @@ -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 `_ +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 +`_. + +The ``attributeSchema`` objects as well as all objectclasses +are exposed through a subtree called the `Schema Naming Context +`_ + +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 +`_ 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