[Samba] idmap_ad partially stopped working after upgrading Samba from 3.4.3 to 3.6.3

[Michael Adam]

Hi Javier,

Javier Conti wrote:
> On 15 May 2012 23:29, Michael Adam <obnox at samba.org> wrote:
> > Hi Javier,
> >
> > Javier Conti wrote:
> >> Dear list,
> >>
> >> upgrading from SLES11 SP1 to SLES11 SP2, I upgraded Samba from 3.4.3
> >> to 3.6.3. I was successfully using idmap_ad to authenticate users but
> >> after the upgrade it stopped working and users are not seen by the OS.
> >> Obviously the users I want to see on the Linux server have all RFC2307
> >> attributes populated and are seen by all other SLES11 SP1 servers.
> >
> >
> >> Although I tried many changes to the config, according to some hints found
> >> on the web, this is what I was using with Samba 3.4.3:
> >>
> >>   [global]
> >>     workgroup = MYDOMAIN
> >>     realm = MYREALM
> >>     security = ADS
> >>
> >>     idmap backend = idmap_ad
> >>     idmap uid = 64000 - 64999
> >>     idmap gid = 64000 - 64999
> >>
> >>     idmap config MYDOMAIN : default = yes
> >>     idmap config MYDOMAIN : backend = ad
> >>     idmap config MYDOMAIN : range = 1000-50000
> >>     idmap config MYDOMAIN : schema_mode = rfc2307
> >>
> >>     winbind use default domain = yes
> >>     winbind nss info = rfc2307
> >>     winbind offline logon = yes
> >>     winbind refresh tickets = yes
> >>     [...]
> >>
> >> Any hints on what has changed with Samba 3.6.3 and/or what to
> >> change to adapt the configuration to 3.6.3 (if necessary)?
> >
> > Some comments:
> > The above config makes no real sense for me,
> > neither for 3.4 nor for 3.6:
> >
> > * The parameter "idmap config DOMAIN : default = yes/no"
> >  has been removed in samba 3.3. It only existed from
> >  3.0.25 to 3.2.
> >  (http://www.samba.org/samba/history/samba-3.3.0.html)
> >
> > * You are using the backend "ad" (or "idmap_ad" which is
> >  a deprecated synonym) both in "idmap config MYDOMAIN : backend"
> >  and in "idmap backend". Both with different ranges.
> >  This does not seem to make sense to me.
> >
> >  It is necessary to specify a writable backend for the
> >  catch all default idmap configuration, e.g. tdb or ldap.
> >
> >  In 3.6, the "idmap backend" has been replaced by
> >  "idmap config * : backend", etc.
> >
> > A valid config for 3.4 would be:
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > [global]
> >        workgroup = MYDOMAIN
> >
> >        idmap backend = tdb
> >        idmap uid = xxxxx-yyyyy
> >        idmap gid = xxxxx-yyyyy
> >
> >        idmap config MYDOMAIN : backend = ad
> >        idmap config MYDOMAIN : range = 1000-50000
> >        idmap config MYDOMAIN : schema mode = rfc2370
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > The corresponding for 3.6:
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > [global]
> >        workgroup = MYDOMAIN
> >
> >        idmap config * : backend = tdb
> >        idmap config * : range = xxxxx-yyyyy
> >
> >        idmap config MYDOMAIN : backend = ad
> >        idmap config MYDOMAIN : range = 1000-50000
> >        idmap config MYDOMAIN : schema mode = rfc2370
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Hi Michael,
> 
> thanks for your input. The latter is indeed the configuration I'm
> running lately.

Ok, so you _are_ running the default domain with the "tdb" idmap
backend. -- Good.

> > Could you please check with the more low level wbinfo commands
> > the results of the commands for id mapping:
> >
> > wbinfo -S S-1-5-21-828208052-1092558876-1846952604-22794
> > ==> should give a uid
> 
> That works and gives me 10106.
> 
> > wbinfo -Y S-1-5-21-828208052-1092558876-1846952604-22794
> > ==> should fail
> 
> That fails with WBC_ERR_DOMAIN_NOT_FOUND.
> 
> > wbinfo -S S-1-5-21-828208052-1092558876-1846952604-513
> > ==> should fail
> 
> That fails with WBC_ERR_DOMAIN_NOT_FOUND.
> 
> > wbinfo -Y S-1-5-21-828208052-1092558876-1846952604-513
> > ==> should give a gid
> 
> That fails with WBC_ERR_DOMAIN_NOT_FOUND.

Ok, the error messages seem to be bogus.
But from what you have written below, the behaviour is correct.

> I don't know if it's related to that, but in the RFC2307 fields of the 10106
> user I put as primary group 10000, which is not "Domain Users", but
> S-1-5-21-828208052-1092558876-1846952604-51 is actually
> "Domain Users". The group "Domain Users" has no RFC2307 gid
> attribute. We didn't populate it since it's not used at all in the Unix
> environment.

Ah! That explains the above results.

> If I get the SID of the user primary group (i.e. the one I see using id(1)
> on a 3.4.3 client) and then perform a sid-to-gid (wbinfo -Y) it works.

If you don't have a gid associated to the domain users group in AD,
but you configured the idmap backend "ad" for this domain, then
you should get no gid for this group out of winbindd: If the
older version 3.4 falls back to allocating one from the default
range, then this is a bug in 3.4, and 3.6 is correct.

The other thing is what is to be done with the primary gid field
from the ad unix schema extensions, can be a bug in samba.
I am personally not certain that it is a good idea to use this
at all. I'd rather suggest to use the primary group sid and
give it a mapping. Then you have the same view under windows
and under linux/samba.

To be perfectly clear: the gid you got with 3.4: Was this
the primary group id from the unix attributes or was that
a gid allocated by the default idmap-tdb configuration?

I need to find the time to do reproduce and analyze this.
So the more detailed info I can get out of you, the better! :-)

Cheers - Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba/attachments/20120516/6129bb18/attachment.pgp>