Re: idmap_ad partially stopped working after upgrading Samba from 3.4.3 to 3.6.3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 16 May 2012 16:50, Javier Conti <javier.conti@xxxxxxxxx> wrote:
> On 16 May 2012 13:19, Michael Adam <obnox@xxxxxxxxx> wrote:
>> Hi Javier,
>>
>> Javier Conti wrote:
>>> On 15 May 2012 23:29, Michael Adam <obnox@xxxxxxxxx> 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
>>

Dear list,

just for the record, I joined the machine to a test domain and assigned
a gidNumber to the "Domain Users" group (and obviously to the group
for Unix admins), using the latest configuration suggested by Michael,
which is:

[global]
    workgroup = TESTDOMAIN
    realm = TESTDOMAIN.LOCAL
    netbios name = myhostname

    log level = 10

    security = ADS
    preferred master = no

    idmap config * : backend = tdb
    idmap config * : range = 1000000-2000000

    idmap config TESTDOMAIN : backend = ad
    idmap config TESTDOMAIN : range = 1000-50000
    idmap config TESTDOMAIN : schema mode = rfc2307

    idmap cache time = 120
    idmap negative cache time = 1

    winbind use default domain = yes
    winbind nss info = rfc2307
    winbind offline logon = yes
    winbind refresh tickets = yes
    winbind expand groups = 4
    winbind nested groups = yes
    winbind enum users = yes
    winbind enum groups = yes
    winbind separator = +
    template homedir = /home/%D/%U
    template shell = /bin/bash
    usershare allow guests = No

    kerberos method         = secrets and keytab
    dedicated keytab file   = /etc/krb5.keytab

It somewhat works, but with a major problem: the primary group
for Unix users is now "Domain Users":

  # id myuser
  uid=10106(myuser) gid=49999(domain users) groups=49999(domain
users),10000(unixgroup),1000001(BUILTIN+users)

If I remove the gidNumber attribute from the "Domain Users" group in AD,
"myuser" is no longer visible and nothing works.

Here are a few commands that show that almost everything seems to work:

Here I see the primary Unix group as 49999 (domain users):
  # wbinfo -i myuser
  myuser:*:10106:49999:Javier myuseri:/home/myuser:/bin/bash

But getent gives the correct Unix group (unixgroup):
# getent passwd |grep myuser
myuser:*:10106:10000:Javier myuseri:/home/myuser:/bin/bash

Everything seems to resolve correctly:

  # wbinfo -n myuser
  S-1-5-21-1271568242-3690326264-3970561814-3798 SID_USER (1)

  # wbinfo -s S-1-5-21-1271568242-3690326264-3970561814-3798
  TESTCOMPANY+myuser 1

  # wbinfo -n unixgroup
  S-1-5-21-1271568242-3690326264-3970561814-3799 SID_DOM_GROUP (2)

  # wbinfo -Y S-1-5-21-1271568242-3690326264-3970561814-3799
  10000

Getent correctly returns the entry for unixgroup:
  # getent group unixgroup
  unixgroup:x:10000:

But group enumeration doesn't work, although configured, while
users enumeration works (see above):
  # getent group |grep unixgroup
  #

All groups for myuser are seen:
  # wbinfo -r myuser
  49999
  10000
  1000001

This is how the user is configured, with gidNumber correctly
configured to 10000 (unixadmins):

# net -k ads search uid=myuser
Got 1 replies

objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: myuser
c: CH
givenName: myuser
distinguishedName: CN=myuser,OU=Osif,OU=Users,OU=Corner,DC=testcompany,DC=local
instanceType: 4
whenCreated: 20120518091558.0Z
whenChanged: 20120530055946.0Z
displayName: myuser
uSNCreated: 6655624
memberOf: CN=GPS_TFS_Dynacos_Readers,OU=Gruppi_servizi,DC=testcompany,DC=local
memberOf: CN=Domain Users,CN=Users,DC=testcompany,DC=local
uSNChanged: 6789328
co: Switzerland
department: 18515
company: Company
name: myuser
objectGUID: e7b50b07-06e4-48c5-853b-d6cc5ee60dcd
userAccountmyuserrol: 512
codePage: 0
countryCode: 756
pwdLastSet: 129818061585636892
primaryGroupID: 3799
objectSid: S-1-5-21-1271568242-3690326264-3970561814-3798
accountExpires: 9223372036854775807
sAMAccountName: myuser
sAMAccountType: 805306368
userPrincipalName: myuser@testcompany.local
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=testcompany,DC=local
dSCorePropagationData: 16010101000000.0Z
lastLogonTimestamp: 129828279843633898
uid: myuser
uidNumber: 10106
gidNumber: 10000
gecos: myname mylastname
unixHomeDirectory: /home/myuser
loginShell: /bin/bash


I'd be glad to have any kind of suggestion on what to check or how
to troubleshoot the issue.

Thanks, Javier
-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba



[Index of Archives]     [Info Cyrus]     [LARTC]     [Bugtraq]     [Netfilter]     [RAID]     [Trinity TED Users]     [Yosemite News]
  Powered by Linux