diff options
Diffstat (limited to 'source4/dsdb')
| -rw-r--r-- | source4/dsdb/samdb/ldb_modules/objectclass.c | 31 | ||||
| -rw-r--r-- | source4/dsdb/samdb/ldb_modules/objectclass_attrs.c | 30 |
2 files changed, 29 insertions, 32 deletions
diff --git a/source4/dsdb/samdb/ldb_modules/objectclass.c b/source4/dsdb/samdb/ldb_modules/objectclass.c index b72b9bb8e7..39f456dcca 100644 --- 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 ba1f7abad1..e0efd4ccaf 100644 --- 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, |