[Samba] Nested OU’s fail to return user / group lookups

David Thompson david at digitaltransitions.ca
Wed Sep 7 23:52:49 UTC 2016


Hi all, 

 
I have a configuration for a samba file server that I’m trying to get properly implemented. The issue isn’t with the shares but is with the user and groups lookups. 
The server resides in a nested container such as: 

 
>> samdom.com 
         >> Users_And_Computers 
                  >> CA_LOCATION_ON 
                        >> Servers 
                        >> Desktops 
                        >> Laptops 
                        >> Users 

 
So the path is something like this: 
OU=Servers,OU=CA_LOCATION_ON,OU=Users_And_Computers,DC=samdom,DC=com 

 
The server is a debian 8.5 with all the latest patches and hand configured samba (4.4.5) as per the samba wiki instructions. 

 
I am currently only running winbind on the server for user and group lookups and I am able to see the users that are in all of the containers via the wbinfo -u command 
However, if I run getent passwd it returns lots of users but none in the sub OU’s in the domain.  

 
If I run an "id <username>" it is never able to find any of the users who are in the sub OU’s. 

 
Here is the output of my smb.conf file. I’m curious to know if there is something else I need to do in order to get samba looking in the sub OU’s or if its not possible to do that then I’d also like to know so I can stop bashing my head against my desk here.  

 
--------------------------------------------------------------------------------------------------------------------------------------- 
[global] 

 
       netbios name = MSCAPRDHOMDIR1 
       security = ADS 
       workgroup = SAMDOM  
       realm = SAMDOM.COM  

 
       log file = /var/log/samba/%m.log 
       log level = 1 

 
       # Default idmap config used for BUILTIN and local windows accounts/groups 
       idmap config *:backend = tdb 
       idmap config *:range = 2000-9999 

 
       # idmap config for domain SAMDOM 
       idmap config SAMDOM:backend = ad 
       idmap config SAMDOM:schema_mode = rfc2307 
       idmap config SAMDOM:range = 10000-99999 

 
       # Use settings from AD for login shell and home directory 
       winbind nss info = rfc2307 
       winbind enum users = yes 
       winbind enum groups = yes 
       winbind use default domain = yes 
       winbind nested groups = yes 

 
       # Use template settings for login shell and home directory 
       winbind nss info = template 
       template shell = /sbin/bash 
       template homedir = /home/%U 

 
       vfs objects = acl_xattr 
       map acl inherit = yes 
       store dos attributes = yes 

 
--------------------------------------------------------------------------------------------------------------------------------------- 

 
I’ve tried it with both the backend as “ad” and “rid” with the exact same results. I’m sure its something that I’m missing if its possible but I’m not sure what it is. 
When we do the same binding on a Mac OS X based computer, we can dictate where the computer goes into the container and it binds fine and I can lookup the users, so I would think looking up the sub OU’s is fine since it works on another OS, so it’s something I’m missing on the SAMBA configuration side. 

 
I should note that I can obtain kerberos tickets on the samba server side with kinit <username> of a user in the sub OU and it works perfectly fine and I can also destroy the ticket as well without issue. 

 
I have the standard nssswitch configured with winbind in the passwd and group section pointing to winbind. 

 
I also have a mix of users that have the unix attributes enabled and disabled in the sub contiainer and that also seems to make no difference in terms of having the wbinfo and getent passwd return any different results.  

 
Thank you very much in advance for any help / advise you can provide and if there are any links you can point me to I’d also be very appreciative as I’m a little lost / confused trying to figure out how to get this working properly. 

 

 

 
__ 

 

 
DT


More information about the samba mailing list