samba - Mar 2016 - Problems with Member server in a Samba AD Domain

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.

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
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

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:

# /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.

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.
spindles7

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'
> 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 
authentication.
>   My
> /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

Rowland

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
>>>
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.
>
>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
>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
>
>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:
>
># /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.
>
>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.
>spindles7

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.

spindles7

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?
>
>>
>> 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 
>authentication.
>
>>   My
>> /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.
When you create a user in ADUC and allocate a drive letter to the share on the
Profile tab, ADUC automatically tries to create the
folder and set the correct permissions.   Which presumably is why the share
itself needs to be set up with the correct permssions to
allow this to happen?
>
>
>>
>> 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
Thanks - so this can safely be ignored...
>
>Rowland
Many thanks for your help.

spindles7