[Samba] Problems with Member server in a Samba AD Domain
spindles7-2 at yahoo.co.uk
Mon Mar 28 08:52:31 UTC 2016
On Mon, 28 Mar 2016 00:29:53 +0100, spindles7 <spindles7-2 at yahoo.co.uk> 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
>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.
>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?
>On the DC the owner and group are shown thus:
>root at debian-dc1:~# ls -l /srv/users
>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
>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
>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?
>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. My
>/etc/nsswitch.conf is as follows:
># 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: files winbind
>group: files winbind
>hosts: files dns
>protocols: db files
>services: db files
>ethers: db files
>rpc: db files
>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
>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
>Let me know if you need more info. Once again many thanks for your help.
Now got it working - users can log in on Windows machines and their H drive is successfully connecting to their home folder on the
member server. Not sure exactly what I did, but I re-checked all the permissions on the share and folders and found that SYSTEM
didn't have Full Control - it had read/write etc but the top box wasn't ticked. Don't know whether that was the cause.
More information about the samba