Fedora DS Support

[Endi Sukma Dewata]

Hello,

I'm trying to run Samba 4 using Fedora DS backend and found some issues:

1. Unsupported Attribute Syntaxes

Some attribute syntaxes used by Samba aren't supported by FDS, so they need to be mapped into something else. This is what I had to add into the schema-map-fedora-ds-1.0:

#Printable String as IA5 String
1.3.6.1.4.1.1466.115.121.1.44:1.3.6.1.4.1.1466.115.121.1.26
#UTC Time as Generalized Time
1.3.6.1.4.1.1466.115.121.1.53:1.3.6.1.4.1.1466.115.121.1.24
#DN with String as Directory String
1.2.840.113556.1.4.904:1.3.6.1.4.1.1466.115.121.1.15
#Presentation Address as Directory String
1.3.6.1.4.1.1466.115.121.1.43:1.3.6.1.4.1.1466.115.121.1.15

Are these mappings ok?

2. SID Generation on Replicated FDS 

Currently SID is generated by incrementing the nextRid attribute in the domain object. With multiple FDS masters this could lead to race conditions.

One solution is to use the DNA plugin in FDS (http://directory.fedoraproject.org/wiki/DNA_Plugin). So Samba will just add the new entry into FDS without SID, and the plugin will automatically generate a unique SID. This would require changing the code a little bit, see source4/dsdb/samldb/ldb_modules/samldb.c:

static int samldb_fill_object(struct samldb_ctx *ac, const char *type)
{
    ret = samldb_add_step(ac, samldb_get_parent_domain); // get domain SID and next RID
    ret = samldb_add_step(ac, samldb_new_sid); // object SID = domain SID + (next RID + 1)
    ret = samldb_add_step(ac, samldb_check_sid); // check for conflicting SID
    ret = samldb_add_step(ac, samldb_notice_sid); // increment next RID
}

Basically the above 4 lines will have to be skipped when running with FDS. Is this a reasonable approach? How is this problem being handled when using replicated OpenLDAP backend?

Thanks!

--
Endi S. Dewata