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

Javier Conti javier.conti at gmail.com
Wed May 16 08:50:29 MDT 2012


On 16 May 2012 13:19, Michael Adam <obnox at samba.org> wrote:
> 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.

In 3.4 I don't have a gid for "Domain Users". This has never been a
problem since the "Domain Users" group is not used at all on Unix
machines. If I perform a getent(1) on group "Domain Users" I get
nothing, if I perform a getent(1) on group unixgroup I get the expected
results.

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

In Samba 3.4 I had (for instance) "unixgroup" as primary group for
my user: that is simply done by setting the gidNumber attribute for
the group "unixgroup" according to the gidNumber of the user
"myuser".

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

It is the one from the gidNumber attribute in AD (thus common
to all servers across the datacenter)

> 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! :-)

All the info I provide must be masked according to my employer's
policies, and exported to the outside world (thus it may be a rather
cumbersome and time consuming task). However, I'd still prefer to
share the masked information to one person only (e.g. you) than
to write it on the mailing list, if it's ok for you.

Please tell me if you need further details.

Thanks, Javier

>
> Cheers - Michael
>


More information about the samba mailing list