Restrictions on invocationID?

[Andrew Bartlett]

On Sun, 2007-04-29 at 14:24 +0200, Stefan (metze) Metzmacher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Andrew Bartlett schrieb:
> > Metze:
> > 
> > I'm trying to implement the cn=configuration container against LDAP.
> > Currently, it doesn't work because we fix the invocationID *and*
> > objectGUID of the cn=NTDS Settings,cn=$COMPUTER... record to be a
> > 'fixed' random value (ie, not generated by the LDAP backend).  
> > 
> > OpenLDAP objects to us setting it's entryUUID values.  My questions is:
> > does the invocationID need to match the objectGUID on that entry?
> 
> Hi Andrew,
> 
> in the "load schema by default" patch I changed our way to handle this.
> 
> so the objectGUID will always be generated by the backend, and we don't
> need a special rule for it. And the invocationId will be set by the
> caller as it's currently.

So, in your patch it seems like we no longer support having a fixed
domain GUID (and therefore need to setup the DNS zone every time)?

> Normaly the first objectGUID and invocationId match on the first
> installed DC in a forest. On all other DC it doesn't match,
> because the new DC chooses its invocationID before the NTDS Settings
> object is created via DsAddEntry() on the other DC, the reply of
> DsAddEntry() returns then the objectGUID of the object.
> 
> So we should just remove all objectGUID: elements from our ldif files.
> Windows also doesn't allow a caller to specify the objectGUID and our
> repl_meta_data module also rejects it.

OK.  I'll handle it that way for the short term.

I've been looking over your patch, and I'm still not comfortable with
the schema changes.  We should be able to extend our schema, so while
the unixName stuff should go away, we must be able to load something
else...

'@'unixName doesn't seem quite right at all. 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20070429/e4354761/attachment.bin