From 3c4376c4d8dbd7c5db52df7442ec410dbfb06e62 Mon Sep 17 00:00:00 2001 From: Andrew Bartlett Date: Mon, 8 Nov 2010 12:13:32 +1100 Subject: [PATCH] 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 --- source4/dsdb/repl/drepl_partitions.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/source4/dsdb/repl/drepl_partitions.c b/source4/dsdb/repl/drepl_partitions.c index 70173fea013..d4511f62bc6 100644 --- 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)); -- 2.34.1