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