Fedora DS Support

[Endi Sukma Dewata]

Andrew,

Just to give you an update, I'm still struggling to run the tests
on my VM. It seems that when I install too many things the VM will
start behaving strangely (inconsistent behavior). So I will try
creating a new VM with bigger memory & disk, hopefully it will solve
it.

> > To my understanding the SID is stored as binary in FDS. In order to
> > use the DNA plugin we need to split the SID into a static prefix and
> > a dynamically generated integer.

> Urgh.  You would have to start an invalid NDR structure as the prefix
> (because otherwise it will have the wrong number of sub-authorities).

That's right. DNA prefix will be just a series of bytes which doesn't
have to mean anything. But when it's combined with the generated value
it will produce a valid SID.

> > Are you suggesting we can store SID as string in FDS? That certainly
> > will eliminate the need to fix the DNA plugin, but we probably need
> > a different schema for Samba and FDS. Also would there be a big
> > performance impact?

> I don't think so.  I think it's the best approach - we could also
> rename to sambaSID.  

Ok, I'm studying Samba code now to see how this could be implemented.
Do you think a single change in the simple_ldap_map.c will be sufficient?
Are there any case where Samba would access the attribute in the backend
directly bypassing the mapping?

While we're on this subject, what do you think about making all attribute
mapping configurable? Currently the mapping is hardcoded in
simple_ldap_map.c. I just thought in some cases the Samba schema may
conflict with the schema that already exists in the LDAP server.

> BTW, when next submitting patches please check 'make quicktest', to
> ensure you don't break the normal LDB backend when fixing things for
> Fedora DS.  Also check the OpenLDAP backend if at all possible.

Yes, I will do that once I have a stable VM. Btw, thanks for the
correction, I saw it in the git log.

--
Endi S. Dewata