Hi guys. I've got working samba AD server. It is playing nicely with Windows 10 and also successfully authenticating Linux machines with SSSD. On the Windows machines I have our EMC storage smb mounted via group policy. Managing permissions for users and groups there, as you know, happens with right click, security etc.. As you may have already guessed the troubles come when my Linux machines, that access the storage via nfs mount, need to work with folders and files created from the Windows PCs. Linux doesn't "see" the actual user/group that owns given folder. It interprets it into numbers, some kind of UID that comes from the Windows machines. I'm quite sure that this is common and known issue, but I don't know what is the right way to deal with it, so any wisdom will be helpful. Thanks Z
On Sat, 28 Apr 2018 13:10:14 +0100 Zdravko Zdravkov via samba <samba at lists.samba.org> wrote:> Hi guys. > > I've got working samba AD server. It is playing nicely with Windows > 10 and also successfully authenticating Linux machines with SSSD.If you want help with sssd, sorry, but this isn't the place.> On the Windows machines I have our EMC storage smb mounted via group > policy. Managing permissions for users and groups there, as you know, > happens with right click, security etc.. > As you may have already guessed the troubles come when my Linux > machines, that access the storage via nfs mount, need to work with > folders and files created from the Windows PCs. Linux doesn't "see" > the actual user/group that owns given folder. It interprets it into > numbers, some kind of UID that comes from the Windows machines.For a Linux machine to know an AD user, then 'getent passwd username' must produce output e.g. getent passwd rowland rowland:*:10000:10000:Rowland Penny:/home/rowland:/bin/bash To get this to work, you need to configure several things. The correct packages need to be installed. Pamm, smb.conf and /etc/nsswitch.conf need to be configured correctly. Just how they need to be configured depends on what you are configuring, a DC or a Unix domain member.> I'm quite sure that this is common and known issue, but I don't know > what is the right way to deal with it.Yes it is and neither do I, well not until you give us more info ;-) smb.conf from the DC and any Unix domain members. What OS you are using ? How are the 'passwd' & 'group' lines set in /etc/nsswitch ? Rowland
So, so.. Server and clients are CentOS7. Server was configured using samba-tool domain provision. *smb.conf* from server [global]> netbios name = AD > realm = XXXXXX > server role = active directory domain controller > server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, > winbindd, ntp_signd, kcc, dnsupdate > workgroup = XXXX > idmap config XXXX:unix_nss_info = yes > log file = /var/log/samba/samba.log > log level = 3 > [netlogon] > path = /usr/local/samba/var/locks/sysvol/XXXXXX/scripts > read only = No > [sysvol] > path = /usr/local/samba/var/locks/sysvol > read only = No*sssd.conf* from client [sssd]> domains = xxxx > config_file_version = 2 > services = nss, pam > [domain/xxxx] > ad_domain = xxxx > krb5_realm = XXXX > realmd_tags = manages-system joined-with-samba > cache_credentials = True > id_provider = ad > krb5_store_password_if_offline = True > default_shell = /bin/bash > ldap_id_mapping = True > use_fully_qualified_names = False > fallback_homedir = /home/%u > access_provider = ad*nsswitch.conf* on client (part of it) passwd: files sss> shadow: files sss > group: files sssgetent passwd pj (for example) provides this: pj:*:1115001179:1115000513:xxxxxx:/home/pj:/bin/bash Cheers On Sat, Apr 28, 2018 at 1:36 PM, Rowland Penny <rpenny at samba.org> wrote:> On Sat, 28 Apr 2018 13:10:14 +0100 > Zdravko Zdravkov via samba <samba at lists.samba.org> wrote: > > > Hi guys. > > > > I've got working samba AD server. It is playing nicely with Windows > > 10 and also successfully authenticating Linux machines with SSSD. > > If you want help with sssd, sorry, but this isn't the place. > > > On the Windows machines I have our EMC storage smb mounted via group > > policy. Managing permissions for users and groups there, as you know, > > happens with right click, security etc.. > > As you may have already guessed the troubles come when my Linux > > machines, that access the storage via nfs mount, need to work with > > folders and files created from the Windows PCs. Linux doesn't "see" > > the actual user/group that owns given folder. It interprets it into > > numbers, some kind of UID that comes from the Windows machines. > > For a Linux machine to know an AD user, then 'getent passwd username' > must produce output e.g. getent passwd rowland > rowland:*:10000:10000:Rowland Penny:/home/rowland:/bin/bash > > To get this to work, you need to configure several things. The correct > packages need to be installed. > Pamm, smb.conf and /etc/nsswitch.conf need to be configured correctly. > Just how they need to be configured depends on what you are > configuring, a DC or a Unix domain member. > > > I'm quite sure that this is common and known issue, but I don't know > > what is the right way to deal with it. > > Yes it is and neither do I, well not until you give us more info ;-) > > smb.conf from the DC and any Unix domain members. > What OS you are using ? > How are the 'passwd' & 'group' lines set in /etc/nsswitch ? > > Rowland > >
Hi Zdravko,> I've got working samba AD server. It is playing nicely with Windows 10 and > also successfully authenticating Linux machines with SSSD. > On the Windows machines I have our EMC storage smb mounted via group > policy. Managing permissions for users and groups there, as you know, > happens with right click, security etc.. > As you may have already guessed the troubles come when my Linux machines, > that access the storage via nfs mount, need to work with folders and files > created from the Windows PCs. Linux doesn't "see" the actual user/group > that owns given folder. It interprets it into numbers, some kind of UID > that comes from the Windows machines.unless you definitly need NFS for some reasons you should go for a mount.cifs for share access. Having two different protocols is bound to have issues with ownership and ACLs. And if you really need POSIX support, you can still have it with Unix Extensions, although it will retrict you to SMB1 support, which is very chatty and not so fast. By the way, you can mount a CIFS share at session startup using pam-script module. Cheers, Denis> I'm quite sure that this is common and known issue, but I don't know what > is the right way to deal with it, so any wisdom will be helpful. > > Thanks > Z >-- Denis Cardon Tranquil IT Systems Les Espaces Jules Verne, bâtiment A 12 avenue Jules Verne 44230 Saint Sébastien sur Loire tel : +33 (0) 2.40.97.57.55 http://www.tranquil.it Samba install wiki for Frenchies : https://dev.tranquil.it WAPT, software deployment made easy : https://wapt.fr
Hi Denis. Since we have "tricky" people working on the Linux machines we prefer NFS because it's less hassle to mount and requires no credentials. Basically because of the users we tend to choose the easiest possible way for them to access the needed resources. I guess pam-script module mounting is exactly for this purpose, but I'll to research more since I'm not familiar with it. Thanks On Wed, May 2, 2018 at 9:00 AM, Denis Cardon <dcardon at tranquil.it> wrote:> Hi Zdravko, > > > I've got working samba AD server. It is playing nicely with Windows 10 and >> also successfully authenticating Linux machines with SSSD. >> On the Windows machines I have our EMC storage smb mounted via group >> policy. Managing permissions for users and groups there, as you know, >> happens with right click, security etc.. >> As you may have already guessed the troubles come when my Linux machines, >> that access the storage via nfs mount, need to work with folders and files >> created from the Windows PCs. Linux doesn't "see" the actual user/group >> that owns given folder. It interprets it into numbers, some kind of UID >> that comes from the Windows machines. >> > > unless you definitly need NFS for some reasons you should go for a > mount.cifs for share access. Having two different protocols is bound to > have issues with ownership and ACLs. And if you really need POSIX support, > you can still have it with Unix Extensions, although it will retrict you to > SMB1 support, which is very chatty and not so fast. > > By the way, you can mount a CIFS share at session startup using pam-script > module. > > Cheers, > > Denis > > > I'm quite sure that this is common and known issue, but I don't know what >> is the right way to deal with it, so any wisdom will be helpful. >> >> Thanks >> Z >> >> > -- > Denis Cardon > Tranquil IT Systems > Les Espaces Jules Verne, bâtiment A > 12 avenue Jules Verne > 44230 Saint Sébastien sur Loire > tel : +33 (0) 2.40.97.57.55 > http://www.tranquil.it > > Samba install wiki for Frenchies : https://dev.tranquil.it > WAPT, software deployment made easy : https://wapt.fr >