dsdb: Handle DB corner-case where PSO container doesn't exist

A 2003 AD DB with functional level set to >= 2008 was non-functional
due to the PSO checks.

We already check the functional level is >= 2008 before checking for the
PSO container. However, users could change their functional level
without ensuring their DB conforms to the corresponding base schema.

The objectclass DSDB module should prevent the PSO container from ever
being deleted. So the only way we should be able to hit this case is
through upgrading the functional level (but not the underlying schema
objects). If so, log a low-priority message and continue without errors.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=14008
RN: Previously, AD operations such as user authentication could fail
completely with the message 'Error 32 determining PSOs in system' logged
on the samba server. This problem would only affect a domain that was
created using a pre-2008 AD base schema and then had its functional
level manually raised to 2008 or greater. This issue has now been
resolved.

Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>

diff --git a/source4/dsdb/samdb/ldb_modules/operational.c b/source4/dsdb/samdb/ldb_modules/operational.c
index 8dad9517ced105c4259f9e140d52b4fa2b896922..86e43e124afc77d059f0f94d404d0e9e6cc864f0 100644 (file)
--- a/source4/dsdb/samdb/ldb_modules/operational.c
+++ b/source4/dsdb/samdb/ldb_modules/operational.c
@@ -994,6 +994,7 @@ static int get_pso_count(struct ldb_module *module, TALLOC_CTX *mem_ctx,
        struct ldb_result *res = NULL;
        struct ldb_context *ldb = ldb_module_get_ctx(module);
 
+       *pso_count = 0;
        domain_dn = ldb_get_default_basedn(ldb);
        psc_dn = ldb_dn_new_fmt(mem_ctx, ldb,
                                "CN=Password Settings Container,CN=System,%s",
@@ -1007,6 +1008,17 @@ static int get_pso_count(struct ldb_module *module, TALLOC_CTX *mem_ctx,
                                 LDB_SCOPE_ONELEVEL, attrs,
                                 DSDB_FLAG_NEXT_MODULE, parent,
                                 "(objectClass=msDS-PasswordSettings)");
+
+       /*
+        * Just ignore PSOs if the container doesn't exist. This is a weird
+        * corner-case where the AD DB was created from a pre-2008 base schema,
+        * and then the FL was manually upgraded.
+        */
+       if (ret == LDB_ERR_NO_SUCH_OBJECT) {
+               DBG_NOTICE("No Password Settings Container exists\n");
+               return LDB_SUCCESS;
+       }
+
        if (ret != LDB_SUCCESS) {
                return ret;
        }