Fedora DS Support

[Andrew Bartlett]

On Fri, 2009-08-07 at 00:26 -0400, Endi Sukma Dewata wrote:
> Hi Andrew,
> 
> ----- "Andrew Bartlett" <abartlet at samba.org> wrote:
> 
> > We also need to consider if Samba should instead just implement it's own
> > distributed RID allocator, using a schema compatible with the one used
> > by Microsoft.
> 
> Is this what you are referring to? http://support.microsoft.com/kb/305475
> 
> I've been considering this option too but am concerned that it's going to
> take more time than I have. Do you think the logic in the FDS's DNA plugin
> can be easily adapted to Samba? It seems that DNA plugin has an advantage
> that it doesn't rely on a single master to allocate the RID pools.

The DNA plugin was actually written *for* Samba (as well as for the
other things it is being used for), when I first joined Red Hat.  As far
as I'm aware, properly configured (ie, knowing to apply the prefix etc)
it should be fine.

...

> As you can see there is nothing that needs to know the SID before
> it's generated in the last step. One thing though, the nextRid
> attribute in the domain object will no longer be updated. Is this
> ok? I've checked the code and to my understanding this attribute
> is not used anywhere else.

I think skipping the nextRid should be fine.  I'm pretty sure it's a
relic of AD being an NT4 DC. 

As long a nothing else (and nothing comes to mind) uses the objectSID
before it is re-read from the DB, you should be fine.  

(we already expect objectGUID to behave that way)

> We could also add a parameter in smb.conf so you can select who
> will generate the SID: Samba itself or the backend.

Yes.  In particular, we need this to be set somewhere from the provision
script, so that when a 'fedora-ds' back-end is selected, this behaviour
strictly applies.

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.
-------------- 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/pipermail/samba-technical/attachments/20090807/f5c3104d/attachment.pgp>