[Samba] Problems with Member server in a Samba AD Domain
spindles7
spindles7-2 at yahoo.co.uk
Mon Mar 28 10:34:25 UTC 2016
On Mon, 28 Mar 2016 11:14:17 +0100, Rowland penny <rpenny at samba.org> wrote:
>On 28/03/16 10:42, spindles7 wrote:
>> On Mon, 28 Mar 2016 09:27:54 +0100, Rowland penny <rpenny at samba.org> wrote:
>> Many thanks Rowland. See inline comments on your comments!
>>
>>> 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
>>>>>> administrator:*:10000:10000:Administrator:/home/Administrator:/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:
>>>>>>
>>>>>> [global]
>>>>>>
>>>>>> 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
>>>>>> accounts/groups
>>>>>> 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
>>>>>>
>>>>>> [users]
>>>>>> 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
>>>>>> MICROLYNX\administrator:*:0:100::/srv/users/administrator:/bin/bash
>>>>>> MICROLYNX\krbtgt:*:3000041:100::/srv/users/krbtgt:/bin/bash
>>>>>> MICROLYNX\guest:*:3000007:100::/srv/users/guest:/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,
>>>>>>
>>>>>> spindles7
>>>>> 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.
>>>>>
>>>>> Rowland
>>>> 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
>>> attributes.
>>> 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'
>> thanks - yes the getfacl basically now agrees with what I see from a Windows client on the Security tab.
>>
>>>> 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.
>> That explains it. But having set UID on users in AD the member server now displays it correctly eg
>> root at debian-m1:~# wbinfo -n test1
>> S-1-5-21-477877664-3821138561-3089784001-1113 SID_USER (1)
>> root at debian-m1:~# wbinfo -S=S-1-5-21-477877664-3821138561-3089784001-1113
>> 10003
>>
>> the same commandson the DC gives:
>> root at debian-dc1:~# wbinfo -n test1
>> S-1-5-21-477877664-3821138561-3089784001-1113 SID_USER (1)
>> root at debian-dc1:~# wbinfo -S S-1-5-21-477877664-3821138561-3089784001-1113
>> 3000049
>>
>> So why is the DC ignoring the UID set in AD? Does it matter?
>>
>
>This is probably because the user has an object created in idmap.ldb or
>the winbind cache, try running 'net cache flush' on the DC, if this
>cures it ok. If it doesn't, open '/var/lib/samba/private/idmap.ldb with
>ldbedit:
>
>ldbedit -e nano -H /var/lib/samba/private/idmap.ldb
>
>find the SIDs that you do not want to have the '3000000' numbers and
>delete the entire object, close and save the file. This should fix it.
>
>If you are just using the DC for authentication, you could just ignore it.
>
>Rowland
Thanks - net cache flush fixed it.
Happy now.
spindles7
More information about the samba
mailing list