s4-dsdb Explain why we may not use the GC name in some situations.

This delicate balance caused us a bit of a puzzle when we could not work
out why an DC join failed with the new python scripts.

Andrew Bartlett

diff --git a/source4/dsdb/repl/drepl_partitions.c b/source4/dsdb/repl/drepl_partitions.c
index 70173fea01387a1b32b8ee1968a8b5766c1a1cdf..d4511f62bc65cda4f99bed0efd9333409bdb9ed0 100644 (file)
--- a/source4/dsdb/repl/drepl_partitions.c
+++ b/source4/dsdb/repl/drepl_partitions.c
@@ -141,6 +141,14 @@ NTSTATUS dreplsrv_get_target_principal(struct dreplsrv_service *s,
                return NT_STATUS_OK;
        }
 
+       /* All DCs have the GC/hostname/realm name, but if some of the
+        * preconditions are not satisfied, then we will fall back to
+        * the
+        * E3514235-4B06-11D1-AB04-00C04FC2DCD2/${NTDSGUID}/${DNSDOMAIN}
+        * name.  This means that if a AD server has a dnsHostName set
+        * on it's record, it must also have GC/hostname/realm
+        * servicePrincipalName */
+
        *target_principal = talloc_asprintf(mem_ctx, "GC/%s/%s",
                                            hostname,
                                            lpcfg_dnsdomain(s->task->lp_ctx));