samba - Jun 2015 - Added RFC2307 --> Unable to convert SID (S-1-1-0)

Hi Rowland,

On 5 June 2015 at 12:14, Rowland Penny <rowlandpenny at googlemail.com>
wrote:
> So I take it that when you provisioned the domain, you didn't use
> '--use-rfc2307'
Correct
> OK, you now have the same result, so it should work as if you had used
> '--use-rfc2307'
Yup - and indeed it works on the second DC.
> You have two problems here, well one possible and one definite, first you
> have turned off the dns server built into the samba AD DC, this is a
problem
> unless you are also running bind9.
Sorry yes, I am also running BIND9, this works fine for purposes of
this email thread (plenty of other issues I could talk about, but not
here & now! :) )
> The main problem is thinking that you set up an AD DC the same way as a
> Member Server, you cannot, all the winbind lines you added are doing
> nothing.
Thank you - I think this was the key to my confusion.

I had forgotten this, which was of course the whole reason I am
embarking on this sorry story in the first place :)
> You are also mixing up how an AD DC and a Member Server work, the DC uses
> idmap.ldb to store the mappings and a Member Server uses .tdb files
Thank you - again useful info and I didn't know this beforehand. (I
will try and add these to the wiki somewhere obvious, if I can!)
> If you give your users and groups a uidNumber or a gidNumber These should
be
> used on the DC instead of the xidNumber stored in idmap.ldb.
And this is I think the key. On the DC that is working, I am still
using sssd as per previous discussions, and *that* is why it works
fine. (I have set 'ldap_id_mapping = False' on that machine, now I
have added rfc2307)

On the DC that is not working, for some reason sssd won't play ball if
I set the above configuration line - I have no idea why, there are a
few hits on google for that error message - and because this wasn't
working and I couldn't resolve that immediately, I thought it would be
a good idea to use winbind instead.. which of course doesn't work on a
DC.

I'll try and reproduce the sssd/nsswitch.conf config from 'good DC'
to
'bad DC' and see how I get on, and will remove the winbind/idmap
lines, as you say they aren't doing anything.

Will update shortly.. :)

Thanks

J

-- 
"If we knew what it was we were doing, it would not be called
research, would it?"
      - Albert Einstein

On 5 June 2015 at 12:57, Jonathan Hunter <jmhunter1 at gmail.com> wrote:
> And this is I think the key. On the DC that is working, I am still
> using sssd as per previous discussions, and *that* is why it works
> fine. (I have set 'ldap_id_mapping = False' on that machine, now I
> have added rfc2307)
OK, I take some of this back... sssd was not running on the 'good' DC.
It won't start on there at all, yet things still work perfectly (!)

-- 
"If we knew what it was we were doing, it would not be called
research, would it?"
      - Albert Einstein

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 :(

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
- 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
- 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


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
- 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))'



-- 
"If we knew what it was we were doing, it would not be called
research, would it?"
      - Albert Einstein

On 05/06/15 13:57, Jonathan Hunter wrote:
> Hi Rowland,
>
> On 5 June 2015 at 12:14, Rowland Penny <rowlandpenny at
googlemail.com> wrote:
>
>> So I take it that when you provisioned the domain, you didn't use
>> '--use-rfc2307'
> Correct
>> OK, you now have the same result, so it should work as if you had used
>> '--use-rfc2307'
> Yup - and indeed it works on the second DC.
>
>> You have two problems here, well one possible and one definite, first
you
>> have turned off the dns server built into the samba AD DC, this is a
problem
>> unless you are also running bind9.
> Sorry yes, I am also running BIND9, this works fine for purposes of
> this email thread (plenty of other issues I could talk about, but not
> here & now! :) )
>
>> The main problem is thinking that you set up an AD DC the same way as a
>> Member Server, you cannot, all the winbind lines you added are doing
>> nothing.
> Thank you - I think this was the key to my confusion.
>
> I had forgotten this, which was of course the whole reason I am
> embarking on this sorry story in the first place :)
>
>> You are also mixing up how an AD DC and a Member Server work, the DC
uses
>> idmap.ldb to store the mappings and a Member Server uses .tdb files
> Thank you - again useful info and I didn't know this beforehand. (I
> will try and add these to the wiki somewhere obvious, if I can!)
>
>> If you give your users and groups a uidNumber or a gidNumber These
should be
>> used on the DC instead of the xidNumber stored in idmap.ldb.
> And this is I think the key. On the DC that is working, I am still
> using sssd as per previous discussions, and *that* is why it works
> fine. (I have set 'ldap_id_mapping = False' on that machine, now I
> have added rfc2307)
>
> On the DC that is not working, for some reason sssd won't play ball if
> I set the above configuration line - I have no idea why, there are a
> few hits on google for that error message - and because this wasn't
> working and I couldn't resolve that immediately, I thought it would be
> a good idea to use winbind instead.. which of course doesn't work on a
> DC.
>
> I'll try and reproduce the sssd/nsswitch.conf config from 'good
DC' to
> 'bad DC' and see how I get on, and will remove the winbind/idmap
> lines, as you say they aren't doing anything.
>
> Will update shortly.. :)
>
> Thanks
>
> J
>
Hi
Use either winbind or sssd, not a halfway house. With a mix of 
fileservers and dcs we'd strongly recommend the latter. Remove anything 
to do with idmap ldb and everything to do with winbind. put your rfc2307 
in the directory and use the minimal ad sssd.conf. That's it.

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