[Samba] Samba AD: gidNumber?

Thu Oct 29 17:27:04 UTC 2015


On 29.10.2015 17:54, Rowland Penny wrote:
> On 29/10/15 16:21, Viktor Trojanovic wrote:
>>
>>
>> On 27.10.2015 16:16, Rowland Penny wrote:
>>> On 27/10/15 14:58, Viktor Trojanovic wrote:
>>>>
>>>>
>>>> On 27.10.2015 13:54, Rowland Penny wrote:
>>>>> [...]
>>>>>> Yes, I meant the administrator. I did your suggested change on my 
>>>>>> member server and restarted it. 'getent passwd administrator' is 
>>>>>> still not returning anything, though. Or is that the wrong way to 
>>>>>> check if it worked?
>>>>>>
>>>>>
>>>>> If you ran the same command on the DC, it will return something, 
>>>>> but on a member server it won't, because the range you set in 
>>>>> smb.conf is (if you followed the wiki, 10000-99999) above '0' and 
>>>>> anything that is outside the range is ignored. This is not a 
>>>>> problem, remember that Administrator is mapped to root on the 
>>>>> member server, so if you want to log into the member server, you 
>>>>> would so as root. From windows, Administrator becomes root and 
>>>>> carries out any changes etc as root.
>>>>>
>>>>> Rowland
>>>>>
>>>>>
>>>>
>>>> Ok, all understood, thank you. But how can I check if it worked 
>>>> with the users? I manually changed the Nisdomain and uidNumber for 
>>>> two users using ADUC (to 10001 and 10002, respectively), I 
>>>> restarted Samba (was this even necessary?), and getent passwd 
>>>> <username> will still not return anything.
>>>>
>>>> In other words, what is the quickest way to check if my member 
>>>> server setup worked out alright?
>>>
>>> OK, if you compiled samba yourself and you want to test getent on 
>>> the member server, see this that I posted earlier:
>>>
>>> https://lists.samba.org/archive/samba/2015-October/195319.html
>>>
>>> If you are using distro packages, the wiki pages should give you a 
>>> good idea of what you need.
>>>
>>> Rowland
>>>
>>>
>> So, I spent quite some time researching it all a bit more in depth 
>> but I get stuck at the same point, although I at least seem to have a 
>> better understanding of how things should be now.
>>
>> So, my smb.conf on the member server looks exactly like the one in 
>> the wiki, except that I also added ACL support as suggested on the 
>> wiki page "Shares with Windows ACLs". My filesystem is XFS and has 
>> ACL built-in.
>>
>> I do get proper results for wbinfo -u and wbinfo -g, but the id and 
>> getent commands just won't work. I'm trying it on users and groups 
>> that have a uidNumber or gidNumber defined, respectively.
>>
>> This is how my nsswitch.conf looks like:
>>
>> passwd: compat winbind
>> group: compat winbind
>> hosts:compat dns
>> networks: compat dns
>>
>> My Samba came from a package but I verified that libnss_winbind.so.2 
>> is properly linked.
>>
>> smbd, nmbd and winbindd are properly started with no errors in the 
>> logs, I'm joined to the AD, I can browse the member server from my 
>> windows machine being logged in as Administrator. But I still can't 
>> seem to change ACLs on any objects in the share from within Windows, 
>> I'm getting error messages "Error when applying security" (I'm 
>> translating freely from German).
>>
>> Do you have any idea what's going wrong here?
>>
>> Viktor
>
> OK, If I remember correctly, we are talking about a domain member 
> here, not a DC. If you are using the default smb.conf from here:
>
> https://wiki.samba.org/index.php/Setup_Samba_as_an_AD_Domain_Member
>
No. I'm using the smb.conf from 
https://wiki.samba.org/index.php/Setup_a_Samba_AD_Member_Server

> with the 'ad' setup from here:
>
> https://wiki.samba.org/index.php/Idmap_config_ad
>
Those lines are already implemented in the smb.conf retrieved from 
https://wiki.samba.org/index.php/Setup_a_Samba_AD_Member_Server
> with the acl support lines from here:
>
> https://wiki.samba.org/index.php/Shares_with_Windows_ACLs#ACL_support_on_domain_members 
>
>
Those exact 3 lines, yes.
> then getent should work, but they are a few caveats, the users must 
> have a uidNumber inside the range 10000-99999 and Domain Users (at 
> least) must have a gidNumber inside the same range. Any users or 
> groups outside this range will be ignored and *all* users will be 
> ignored if Domain Users either doesn't have a gidNumber or it is 
> outside the range.
>
The user I'm trying to return has a uidNumber of 10002, and Domain Users 
is set to gidNumber 10000. I have not set those attributes for other 
groups and did not expect them to show up with getent.

> Time must be synchronised between the machines, within 5 mins if 
> remember correctly.
Time is synced and well within 5 mins. Kerberos would fail otherwise and 
I am able to request k-tickets for any user without issues.
> The domain member must be joined to the domain (obviously)
Of course.
> The domain member must be using the DC has its DNS server
>
> /etc/resolv.conf
> search samdom.example.com
> nameserver 192.168.0.3 <-- this is the ip of the DC
>
My DC has a fixed IP and that's exactly how my resolv.conf looks like, 
no other lines.
> You only need this in /etc/krb5.conf
>
> [libdefaults]
>         default_realm = SAMDOM.EXAMPLE.COM
>         dns_lookup_realm = false
>         dns_lookup_kdc = true
>
That's exactly what I have. As mentioned, Kerberos seems to work properly.

> Ideally your domain member should have a fixed ip, but if you are 
> using dhcp, check that the ipaddress isn't 127.0.0.1 or even worse 
> 127.0.1.1. If you using Ubuntu with Network Manager, stop it using 
> dnsmasq.
>
See above.
> Check that pam is setup correctly, on debian you can do this by 
> running 'pam-auth-update'
>
I don't have pam setup since I don't need the users to log in to Linux. 
It is nowhere mentioned, neither on the wiki nor on the book that this 
is a prerequisite for getent to work.
> If everything seems correct, but 'getent passwd' doesn't return any 
> domain users, try 'getent passwd adomainuser', later samba versions 
> only return individual records.
>
I tried that, it doesn't return any values.
> Rowland
>
>
>
Do you see some issue with my config? Obviously, most of the things seem 
to work, it's just this bloody acl mapping..