[Samba] Added RFC2307 --> Unable to convert SID (S-1-1-0)

[Rowland Penny]

On 05/06/15 13:42, Jonathan Hunter wrote:
> OK - the error messages have stopped now.
>
> I copied idmap.ldb from the 'good' DC to the 'bad' DC (rather than
> simply removing idmap.ldb from the bad DC when restarting samba, as I
> had been doing previously).
>
> Things seem to be working this way... although I am not sure why
> copying this file rather than letting samba recreate it itself, seems
> to have fixed it :(

If you delete idmap.ldb I am fairly sure that it will be created just as 
it was before. You need to copy idmap.ldb from the first DC to any other 
DC's otherwise the other DC's will use different xidNumbers

>
> That part is reproducible, at least. Removing idmap.ldb and restarting
> samba broke it again for me - and even stopping samba, copying
> idmap.ldb back over, and restarting samba didn't fix it until I also
> ran 'net cache flush' (no samba restart needed).
>
>
> To recap and aid my own sanity, then.. an overall summary (not
> including the glitch above) is I think as follows:
>
> - On a DC, winbind options in smb.conf do not work

It does work, just not like on a member server.

> - The only options for consistent ID mappings across DCs are to
> manually copy idmap.ldb files (not great if adding/changing users!) or
> to use rfc2307

Yes, and or use RFC2307 attributes in AD.

> - Using winbindd on my DCs, i.e. with 'winbind' specified in
> nsswitch.conf, appears to be working at the moment.
>
> I think that's how things are running at the moment.
>
> My smb.conf has no 'winbind' or 'idmap config' lines in it, and only
>          idmap_ldb:use rfc2307 = yes
>

That is how it should be.

> Still on my list to look at, at some level:
> - sssd had issues for me when using rfc2307 ('ldap_id_mapping =
> False'), it wouldn't start up

Strange, but without further info, this sounds like an sssd issue and 
will have to be asked on the sssd mailing list.

> - Weirdness with 'samba-tool ntacl sysvolreset'.. running sysvolcheck
> immediately after sysvolcheck doesn't always work (fails with 'raise
> ProvisioningError('%s ACL on GPO directory %s %s does not match
> expected value %s from GPO object' % (acl_type(direct_db_access),
> path, fsacl_sddl, acl))'
>
>
>

That is another problem, but you will need to ensure everything else is 
working correctly before it can be looked at, you never know, it may go 
away.

Rowland