[Samba] winbind idmap_ad rfc2037 can't read UIdnumber

[Raphaël RIGNIER]

Le 05/07/2016 à 19:53, Raphaël RIGNIER a écrit :
> Le 05/07/2016 à 19:40, Rowland penny a écrit :
>> On 05/07/16 17:56, Raphaël RIGNIER wrote:
>>> The strange behavior is the different output between group object 
>>> and user object
>>>
>>> and
>>> net ads search -U administrator
>>> net ads search -P
>>>
>>> in Samba Wiki, primarygroupid refers to the one for User's "Unix 
>>> Attributes" tab. Which is in fact GidNumber. (I have made tests to 
>>> check this)
>>> The primaryGroupID attribute refers to Posix primary Group in user's 
>>> "member of" tab. Which is a conversion from SID. Both are different 
>>> numbers but points to same group.
>>> I find this quite confusing
>>
>> Sorry, but that doesn't answer the question, have you changed the 
>> users 'PrimaryGroupID' attribute
>>
>> If I do this:
>>
>> rowland at devstation:$ ldbsearch -H ldap://dc1 -b 
>> 'cn=Users,dc=samdom,dc=example,dc=com' -s sub 
>> '(&(objectclass=user)(samaccountname=rowland))' primaryGroupID -U 
>> Administrator
>> Password for [SAMDOM\Administrator]:
>> # record 1
>> dn: CN=Rowland Penny,CN=Users,DC=samdom,DC=example,DC=com
>> primaryGroupID: 513
>>
>> # returned 1 records
>> # 1 entries
>> # 0 referrals
>>
>> Which, as you can see, shows that my 'primaryGroupID' is set to 
>> '513', this is what it should be, this is the RID for 'Domain Users'
>>
>> So if you run the command (making obvious changes for your setup), 
>> what do you get ?
>>
>> To get winbind to return users when using the 'ad' backend, each user 
>> needs to have a 'uidNumber' containing a unique number inside the 
>> range set in smb.conf. You also need to give 'Domain Users' a 
>> 'gidNumber' attribute containing a number inside the range set in 
>> smb.conf, this number can be the same as a user, but must be unique 
>> amongst groups.
>>
>> From this, I hope you can see that the users 'primaryGroupID' 
>> attribute needs to contain the RID for 'Domain Users'.
>>
>> Rowland
>>
>>
> Sorry. Here is the result
>
> ldbsearch -H ldap://10.11.1.3 -b "OU=USERS,DC=ADDOMAIN,DC=com" -s sub 
> '(samaccountname=b.btstest)' primarygroupID -U administrator
> Password for [ADDOMAIN\rignier]:
> # record 1
> dn: CN=BTSTEST B,OU=info2,OU=USERS,DC=ADDOMAIN,DC=com
> primaryGroupID: 513
>
> # returned 1 records
> # 1 entries
> # 0 referrals
>
> My PrimaryGroupID is indeed 513. I have tried the 'info2' RID, without 
> more success so back to 513.
>
>
Hi !
finally this is somewhat resolved.
For any reason, Domain's computer group in my AD has no permission to 
query some attributes.
I have added the linux host computer account as member of  "pre windows 
2000" group, which is known to have access to all AD attributes 
readonly. Quik and dirty fix, but acceptable.

id b.btstest2 returns
uid=13239(b.btstest2) gid=9999(utilisa. du domaine) 
groupes=9999(utilisa. du domaine),10002(info2),2001(BUILTIN\users)

but my initial test user returns
id b.btstest
uid=13239(b.btstest2) gid=9999(utilisa. du domaine) 
groupes=9999(utilisa. du domaine),10002(info2),2002,2001(BUILTIN\users)
2002 gid has no mapping. I suspect previous unsuccessful test has 
miss-filled local database. Which one to reset ?

Now upgrading my file server and I will try NFSv4 home directory mounting.

Thank you.