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 AdminsThanks - so this can safely be ignored...> >RowlandMany thanks for your help. spindles7
Rowland penny
2016-Mar-28 10:14 UTC
[Samba] Problems with Member server in a Samba AD Domain
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
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. > >RowlandThanks - net cache flush fixed it. Happy now. spindles7