[Samba] Problems with Member server in a Samba AD Domain
rpenny at samba.org
Mon Mar 28 08:27:54 UTC 2016
See inline comments.
On 28/03/16 00:29, spindles7 wrote:
> On Sun, 27 Mar 2016 18:15:19 +0100, Rowland penny <rpenny at samba.org> wrote:
>> On 27/03/16 17:15, spindles7-2 at yahoo.co.uk wrote:
>>> I have set up a Samba Active Directory domain controller on a fresh
>>> install of Debian 8.3 (Jessie) using Samba 4.4.0 and everything works
>>> fine as far as I can tell. I had users' home folders with the H:
>>> drive letter connecting to the share on the DC and folder redirection
>>> for My Documents, Pictures etc.
>>> Then I decided to add a member server (also Debian Jessie) and put the
>>> users' home folders on that server. So I created a second OU with
>>> folder redirection of Documents, Pictures etc and mapped the H: drive
>>> to the users' shared folder on the member server. My problem is that
>>> whilst the users folders get created automatically and have the
>>> correct NTFS permissions (as seen from a Windows 7 machine) the user
>>> cannot access the folder on the member server - Access Denied.
>>> Permissions say Full Control for the user. It seems that the newly
>>> created users are not being recognised by the member server: getent
>>> passwd returns just the administrator and the user I created with home
>>> folder on the DC:
>>> # getent passwd
>>> test2:*:10001:10000:Test 2. user:/home/test2:/bin/sh
>>> The other user with home folder on the member server does not show up.
>>> So I moved the first user into the second OU and changed the H: drive
>>> mapping to be on the member server. That user can now access the
>>> home folder on the member server. Note though that the My Documents
>>> folder doesn't appear until the second login.
>>> Here's my smb.conf on the member server:
>>> netbios name = debian-m1
>>> security = ADS
>>> workgroup = MICROLYNX
>>> realm = MICROLYNX.LOCAL
>>> log file = /var/log/samba/%m.log
>>> log level = 1
>>> dedicated keytab file = /etc/krb5.keytab
>>> kerberos method = secrets and keytab
>>> winbind refresh tickets = yes
>>> winbind trusted domains only = no
>>> winbind use default domain = yes
>>> winbind enum users = yes
>>> winbind enum groups = yes
>>> # idmap config used for your domain.
>>> # Click on the following links for more information
>>> # on the available winbind idmap backends,
>>> # Choose the one that fits your requirements
>>> # then add the corresponding configuration.
>>> # Just adding the following three lines is not enough!!
>>> # - idmap config ad
>>> # Important: The ranges of the default (*) idmap config
>>> # and the domain(s) must not overlap!
>>> # Default idmap config used for BUILTIN and local
>>> idmap config *:backend = tdb
>>> idmap config *:range = 2000-9999
>>> # idmap config for domain MICROLYNX
>>> idmap config MICROLYNX:backend = ad
>>> idmap config MICROLYNX:schema_mode = rfc2307
>>> idmap config MICROLYNX:range = 10000-99999
>>> # Use settings from AD for login shell and home directory
>>> winbind nss info = rfc2307
>>> template homedir = /srv/users/%U
>>> template shell = /bin/bash
>>> vfs objects = acl_xattr
>>> map acl inherit = yes
>>> store dos attributes = yes
>>> path = /srv/users
>>> read only = No
>>> This is the output of getent passwd on the DC (debian-dc1):
>>> # getent passwd
>>> MICROLYNX\test3:*:3000052:100:Test 3. User:/srv/users/test3:/bin/bash
>>> MICROLYNX\test4:*:3000053:100:test 4. user:/srv/users/test4:/bin/bash
>>> MICROLYNX\test1:*:3000049:100:Test 1. User:/srv/users/test1:/bin/bash
>>> MICROLYNX\test2:*:3000013:100:Test 2. user:/srv/users/test2:/bin/bash
>>> So why are these additional users not being recognised by the member
>>> server (debian-m1)? Also the template homedir & shell lines in the
>>> smb.conf seem to be ignored (by debian-m1).
>>> Any help would be appreciated,
>> OK, I think your problems are all probably caused by the same thing, you
>> are using the winbind 'ad' backend on the domain member, but *you
>> haven't given any of your users 'uidNumber' attributes and you haven't
>> given 'Domain Users' a 'gidNumber' attribute*.
>> Two ways to fix this, use the 'rid' backend instead or give all yours
>> users a 'uidNumber' attribute and 'Domain Users' (at least) a
>> 'gidNumber' attribute, these attributes need to be inside the range you
>> set in smb.conf (in your case, 10000-99999)
>> If you do have these attributes in AD, have you set up PAM and
>> /etc/nsswitch.conf correctly.
> Thanks for that. You are right, or partially so. I had given user test2 Unix attributes using ADUC, and also Domain Users and
> Domain Admins. However, when you go back into ADUC Unix Attributes tab for Domain Users and Domain Admins I get the error:
> "Unwilling to Perform". When I dismiss that the correct settings are there.
Known problem that you can ignore.
> So now I've allocated uidNumbers to all users and getent passwd on the domain member server now lists all the users. However, the
> auto-crreated folders, whilst they show the correct permissions the user still gets "access denied" and the Drive letter is not
> connected at logon. On the other hand users with home folders on the DC work OK. So there's still something wrong. Do I still
> need to setup rid as the backend?
OK, If you use the 'ad' backend, you need to populate the RFC2307
If you use the 'rid' backend, you do not need to add anything to AD, but
you will need the 'template' lines in smb.conf on the domain member.
> On the DC the owner and group are shown thus:
> root at debian-dc1:~# ls -l /srv/users
> total 16
> drwxrwx---+ 2 root root 4096 Mar 27 23:30 test1
> drwxrwx---+ 4 MICROLYNX\denied rodc password replication group users 4096 Mar 27 14:47 test2
> On the Member server they are shown:
> root at debian-m1:~# ls -l /srv/users
> total 32
> drwxrwx---+ 2 administrator domain users 4096 Mar 24 23:42 test1
> drwxrwx---+ 2 administrator domain users 4096 Mar 27 14:48 test2
> drwxrwx---+ 2 administrator domain users 4096 Mar 27 14:45 test3
> drwxrwx---+ 2 administrator domain users 4096 Mar 27 14:45 test4
Two things here, it looks like you have given Administrator a uidNumber
and the '+' sign at the end of the Unix permissions shows that you also
have ACLs set, try running 'getfacl /srv/users'
> Also shouldn't the uidNumbers and gidNumbers be the same on both the DC and the member server? (the DC's range seems to be 30000
> upwards whereas the member server is as specified in ADUC.)
> The smb.conf on the DC has the line:
> idmap config MICROLYNX:range = 10000-99999
> or is that something different?
This is because idmap works differently on a DC to a domain member, on
the DC the mappings are stored in an .ldb file called idmap.ldb, whilst
on a domain member they are either stored in the users object in AD, or
they are computed from the users RID.
Adding the 'idmap config' lines to a DC smb.conf will have no affect,
the only way to change a users UID on a DC is to give the user a
uidNumber attribute in AD.
> I haven't setup PAM as I thought that was only needed if users need to log into the member server's console, which they don't.
You don't need to have winbind set up if you only use the DC for
> /etc/nsswitch.conf is as follows:
> # /etc/nsswitch.conf
> # Example configuration of GNU Name Service Switch functionality.
> # If you have the `glibc-doc-reference' and `info' packages installed, try:
> # `info libc "Name Service Switch"' for information about this file.
> #passwd: compat
> passwd: files winbind
> #group: compat
> group: files winbind
> shadow: compat
> gshadow: files
> hosts: files dns
> networks: files
> protocols: db files
> services: db files
> ethers: db files
> rpc: db files
> netgroup: nis
> and I had created the two symbolic links to libnss_winbind.so.2:
> root at debian-m1:~# ls -l /lib/i386-linux-gnu/libnss_winbind.so*
> lrwxrwxrwx 1 root root 39 Mar 21 19:24 /lib/i386-linux-gnu/libnss_winbind.so -> /lib/i386-linux-gnu/libnss_winbind.so.2
> lrwxrwxrwx 1 root root 40 Mar 21 19:26 /lib/i386-linux-gnu/libnss_winbind.so.2 -> /usr/local/samba/lib/libnss_winbind.so.2
> Users can connect to the \\debian-m1\users share but not to the own folder, so I assumed authentication is working without the need
> for PAM.
Do the users share exist on the DC, they will not be automatically
created unless you use something to do this.
> Incidentally the log-winbind-idmap logfile is full of errors like this:
> [2016/03/28 00:24:31.265357, 1] ../source3/winbindd/idmap_ad.c:523(idmap_ad_sids_to_unixids)
> Could not get unix ID for SID S-1-5-21-477877664-3821138561-3089784001-572
> [2016/03/28 00:24:31.265690, 1] ../source3/winbindd/idmap_ad.c:523(idmap_ad_sids_to_unixids)
> Could not get unix ID for SID S-1-5-21-477877664-3821138561-3089784001-520
> [2016/03/28 00:24:31.265916, 1] ../source3/winbindd/idmap_ad.c:523(idmap_ad_sids_to_unixids)
> Could not get unix ID for SID S-1-5-21-477877664-3821138561-3089784001-519
> [2016/03/28 00:24:31.266139, 1] ../source3/winbindd/idmap_ad.c:523(idmap_ad_sids_to_unixids)
> Could not get unix ID for SID S-1-5-21-477877664-3821138561-3089784001-518
There is a good reason why you cannot get a Unix ID for the SIDS shown,
there are no comparable Unix users or groups:
572 = Denied RODC Password Replication Group
520 = Group Policy Creator Owners
519 = Enterprise Admins
518 = Schema Admins
More information about the samba