s4:dsdb/samdb/ldb_modules/objectclass.c - move LSA specific object checks into "objec...

LSA object classes are protected on both LDAP add and LDAP modify
operations, so I've refactored the previous check in the objectclass LDB
module only for LDAP adds in a new one in the objectclass_attrs LDB
module for both adds and modifies.
This is the result of the investigations done by Hongwei Sun and I in
the last months.
Interestingly these protection mechansim doesn't apply on LDAP deletes!

Signed-off-by: Andrew Bartlett <abartlet@samba.org>

diff --git a/source4/dsdb/samdb/ldb_modules/objectclass.c b/source4/dsdb/samdb/ldb_modules/objectclass.c
index b72b9bb8e7c9d2a8e21deebd67f795f8166aef7b..39f456dccae675d4797c525400fcf14a3c975bcb 100644 (file)
--- a/source4/dsdb/samdb/ldb_modules/objectclass.c
+++ b/source4/dsdb/samdb/ldb_modules/objectclass.c
@@ -565,37 +565,6 @@ static int objectclass_do_add(struct oc_context *ac)
                for (current = sorted; current; current = current->next) {
                        const char *objectclass_name = current->objectclass->lDAPDisplayName;
 
-                       /* LSA-specific objectclasses per default not
-                        * allowed to be created over LDAP, so we need
-                        * to tell if this connection is LDAP (ie
-                        * marked as untrusted), and if the client is
-                        * adding these particular objectClass values
-                        * we must reject */
-
-                       /* Hongwei Sun from Microsoft explians:
-                          The constraint in 3.1.1.5.2.2 MS-ADTS means that the TDO
-                          cannot be added through LDAP interface, instead it can only be
-                          created through LSA Policy API.  This is also explained in
-                          7.1.6.9.7 MS-ADTS as follows:
-
-                          "Despite being replicated normally between peer DCs in a domain,
-                          the process of creating or manipulating TDOs is specifically
-                          restricted to the LSA Policy APIs, as detailed in [MS-LSAD] section
-                          3.1.1.5. Unlike other objects in the DS, TDOs may not be created or
-                          manipulated by client machines over the LDAPv3 transport."
-                       */
-
-                       if (ldb_req_is_untrusted(ac->req) &&
-                           ((strcasecmp(objectclass_name, "secret") == 0) ||
-                            (strcasecmp(objectclass_name, "trustedDomain") == 0))) {
-                               ldb_asprintf_errstring(ldb,
-                                                      "objectclass: object class '%s' is LSA-specific, rejecting creation of '%s' over LDAP!",
-                                                      objectclass_name,
-                                                      ldb_dn_get_linearized(msg->dn));
-                               talloc_free(mem_ctx);
-                               return LDB_ERR_UNWILLING_TO_PERFORM;
-                       }
-
                        ret = ldb_msg_add_string(msg, "objectClass", objectclass_name);
                        if (ret != LDB_SUCCESS) {
                                ldb_set_errstring(ldb,

diff --git a/source4/dsdb/samdb/ldb_modules/objectclass_attrs.c b/source4/dsdb/samdb/ldb_modules/objectclass_attrs.c
index ba1f7abad1a1507120ba411a4625f25db3437606..e0efd4ccaf894d5f87e02a80cc6783daad1f0c7d 100644 (file)
--- a/source4/dsdb/samdb/ldb_modules/objectclass_attrs.c
+++ b/source4/dsdb/samdb/ldb_modules/objectclass_attrs.c
@@ -217,7 +217,7 @@ static int attr_handler2(struct oc_context *ac)
                return ldb_operr(ldb);
        }
 
-       /* We rely here on the preceding "objectclass" LDB module which did
+       /* We rely here on the preceeding "objectclass" LDB module which did
         * already fix up the objectclass list (inheritance, order...). */
        oc_element = ldb_msg_find_element(ac->search_res->message,
                                          "objectClass");
@@ -225,6 +225,34 @@ static int attr_handler2(struct oc_context *ac)
                return ldb_operr(ldb);
        }
 
+       /* LSA-specific object classes are not allowed to be created over LDAP,
+        * so we need to tell if this connection is internal (trusted) or not
+        * (untrusted).
+        *
+        * Hongwei Sun from Microsoft explains:
+        * The constraint in 3.1.1.5.2.2 MS-ADTS means that LSA objects cannot
+        * be added or modified through the LDAP interface, instead they can
+        * only be handled through LSA Policy API.  This is also explained in
+        * 7.1.6.9.7 MS-ADTS as follows:
+        * "Despite being replicated normally between peer DCs in a domain,
+        * the process of creating or manipulating TDOs is specifically
+        * restricted to the LSA Policy APIs, as detailed in [MS-LSAD] section
+        * 3.1.1.5. Unlike other objects in the DS, TDOs may not be created or
+        *  manipulated by client machines over the LDAPv3 transport."
+        */
+       if (ldb_req_is_untrusted(ac->req)) {
+               for (i = 0; i < oc_element->num_values; i++) {
+                       if ((strcmp((char *)oc_element->values[i].data,
+                                   "secret") == 0) ||
+                           (strcmp((char *)oc_element->values[i].data,
+                                   "trustedDomain") == 0)) {
+                               ldb_asprintf_errstring(ldb, "objectclass_attrs: LSA objectclasses (entry '%s') cannot be created or changed over LDAP!",
+                                                      ldb_dn_get_linearized(ac->search_res->message->dn));
+                               return LDB_ERR_UNWILLING_TO_PERFORM;
+                       }
+               }
+       }
+
        must_contain = dsdb_full_attribute_list(ac, ac->schema, oc_element,
                                                DSDB_SCHEMA_ALL_MUST);
        may_contain =  dsdb_full_attribute_list(ac, ac->schema, oc_element,