Fedora DS Support

[Endi Sukma Dewata]

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.

> We don't currently handle this properly with either backend - the main
> thing we would need to do is check that nothing needs to know the SID
> chosen before the backend allocates it.

Here's a more complete simplified version of the method that generates the
SID for the new entry (see the comments):

static int samldb_fill_object(struct samldb_ctx *ac, const char *type)
{
    // find template based on entry type
    ac->type = type;
    ret = samldb_add_step(ac, samldb_search_template);

    // add attributes from the template
    ret = samldb_add_step(ac, samldb_apply_template);

    // find domain object, domain SID, and next RID of the target tree
    ac->check_dn = ac->req->op.add.message->dn;
    ret = samldb_add_step(ac, samldb_get_parent_domain);

    // generate random sAMAccountName if missing
    ret = samldb_add_step(ac, samldb_check_samAccountName);

    // generate sAMAccountType from userAccountControl/groupType
    ret = samldb_add_step(ac, samldb_check_samAccountType);

    // check entry SID
    ac->sid = samdb_result_dom_sid(ac, ac->msg, "objectSid");

    if ( ! ac->sid) { // no entry SID specified

        // generate entry SID from domain SID and (next RID + 1)
        ret = samldb_add_step(ac, samldb_new_sid);

    } else { // new entry contains SID

        // find domain object and next RID based on entry SID
        ret = samldb_add_step(ac, samldb_get_sid_domain);
    }

    // increment next RID in the domain object
    ret = samldb_add_step(ac, samldb_notice_sid);

    // add new entry to backend
    ret = samldb_add_step(ac, samldb_add_entry);

    return samldb_first_step(ac);
}

The only thing that the current code needs to do after generating
the new SID is incrementing the next RID in the domain object. If
we use DNA plugin we could skip all steps related to SID so the
method will become like this:

static int samldb_fill_object(struct samldb_ctx *ac, const char *type)
{
    // find template based on entry type
    ac->type = type;
    ret = samldb_add_step(ac, samldb_search_template);

    // add attributes from the template
    ret = samldb_add_step(ac, samldb_apply_template);

    // generate random sAMAccountName if missing
    ret = samldb_add_step(ac, samldb_check_samAccountName);

    // generate sAMAccountType from userAccountControl/groupType
    ret = samldb_add_step(ac, samldb_check_samAccountType);

    // add new entry to backend, DNA plugin will generate SID
    ret = samldb_add_step(ac, samldb_add_entry);

    return samldb_first_step(ac);
}

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.

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

What do you think? Thanks.

--
Endi S. Dewata