[SCM] Samba Shared Repository - branch master updated

Andrew Bartlett abartlet at samba.org
Tue Jan 25 05:10:03 MST 2011


The branch, master has been updated
       via  932911e s4:ldap.py - check the write protection on LSA objects
       via  3468f8d s4:dsdb/samdb/ldb_modules/objectclass.c - move LSA specific object checks into "objectclass_attrs" LDB module
      from  c9f4fad idl: add file_id idl.

http://gitweb.samba.org/?p=samba.git;a=shortlog;h=master


- Log -----------------------------------------------------------------
commit 932911e1e1c09caa51a5c7a574987cab6ecb16e4
Author: Matthias Dieter Wallnöfer <mdw at samba.org>
Date:   Mon Jan 17 13:52:00 2011 +0100

    s4:ldap.py - check the write protection on LSA objects
    
    Signed-off-by: Andrew Bartlett <abartlet at samba.org>
    
    Autobuild-User: Andrew Bartlett <abartlet at samba.org>
    Autobuild-Date: Tue Jan 25 13:09:41 CET 2011 on sn-devel-104

commit 3468f8de1e408389bd12f2d3f5294bd835431a05
Author: Matthias Dieter Wallnöfer <mdw at samba.org>
Date:   Tue Dec 21 12:24:30 2010 +0100

    s4:dsdb/samdb/ldb_modules/objectclass.c - move LSA specific object checks into "objectclass_attrs" LDB module
    
    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 at samba.org>

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

Summary of changes:
 source4/dsdb/samdb/ldb_modules/objectclass.c       |   31 -----------------
 source4/dsdb/samdb/ldb_modules/objectclass_attrs.c |   30 ++++++++++++++++-
 source4/dsdb/tests/python/ldap.py                  |   35 +++++++++++++++++---
 3 files changed, 59 insertions(+), 37 deletions(-)


Changeset truncated at 500 lines:

diff --git a/source4/dsdb/samdb/ldb_modules/objectclass.c b/source4/dsdb/samdb/ldb_modules/objectclass.c
index b72b9bb..39f456d 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 ba1f7ab..e0efd4c 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,
diff --git a/source4/dsdb/tests/python/ldap.py b/source4/dsdb/tests/python/ldap.py
index 6972ce3..902dfb7 100755
--- a/source4/dsdb/tests/python/ldap.py
+++ b/source4/dsdb/tests/python/ldap.py
@@ -39,7 +39,7 @@ from subunit.run import SubunitTestRunner
 import unittest
 
 from samba.ndr import ndr_pack, ndr_unpack
-from samba.dcerpc import security
+from samba.dcerpc import security, lsa
 from samba.tests import delete_force
 
 parser = optparse.OptionParser("ldap.py [options] <host>")
@@ -95,7 +95,7 @@ class BasicTests(unittest.TestCase):
         delete_force(self.ldb, "cn=ldaptestobject," + self.base_dn)
         delete_force(self.ldb, "description=xyz,cn=users," + self.base_dn)
         delete_force(self.ldb, "ou=testou,cn=users," + self.base_dn)
-        delete_force(self.ldb, "cn=testsecret,cn=system," + self.base_dn)
+        delete_force(self.ldb, "cn=Test Secret,cn=system," + self.base_dn)
 
     def test_objectclasses(self):
         """Test objectClass behaviour"""
@@ -104,7 +104,7 @@ class BasicTests(unittest.TestCase):
         # We cannot create LSA-specific objects (oc "secret" or "trustedDomain")
         try:
             self.ldb.add({
-                "dn": "cn=testsecret,cn=system," + self.base_dn,
+                "dn": "cn=Test Secret,cn=system," + self.base_dn,
                 "objectClass": "secret" })
             self.fail()
         except LdbError, (num, _):
@@ -369,14 +369,39 @@ class BasicTests(unittest.TestCase):
 
         try:
             self.ldb.add({
-                "dn": "cn=testsecret,cn=system," + self.base_dn,
+                "dn": "cn=Test Secret,cn=system," + self.base_dn,
                 "objectclass": "secret"})
             self.fail()
         except LdbError, (num, _):
             self.assertEquals(num, ERR_UNWILLING_TO_PERFORM)
 
         delete_force(self.ldb, "cn=ldaptestobject," + self.base_dn)
-        delete_force(self.ldb, "cn=testsecret,cn=system," + self.base_dn)
+        delete_force(self.ldb, "cn=Test Secret,cn=system," + self.base_dn)
+
+        # Create secret over LSA and try to change it
+
+        lsa_conn = lsa.lsarpc("ncacn_np:%s" % args[0], lp, creds)
+        lsa_handle = lsa_conn.OpenPolicy2(system_name="\\",
+                                          attr=lsa.ObjectAttribute(),
+                                          access_mask=security.SEC_FLAG_MAXIMUM_ALLOWED)
+        secret_name = lsa.String()
+        secret_name.string = "G$Test"
+        sec_handle = lsa_conn.CreateSecret(handle=lsa_handle,
+                                           name=secret_name,
+                                           access_mask=security.SEC_FLAG_MAXIMUM_ALLOWED)
+        lsa_conn.Close(lsa_handle)
+
+        m = Message()
+        m.dn = Dn(ldb, "cn=Test Secret,cn=system," + self.base_dn)
+        m["description"] = MessageElement("desc", FLAG_MOD_REPLACE,
+          "description")
+        try:
+            ldb.modify(m)
+            self.fail()
+        except LdbError, (num, _):
+            self.assertEquals(num, ERR_UNWILLING_TO_PERFORM)
+
+        delete_force(self.ldb, "cn=Test Secret,cn=system," + self.base_dn)
 
         try:
             self.ldb.add({


-- 
Samba Shared Repository


More information about the samba-cvs mailing list