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 >
Hi Rowland.
As suggested I switched to winbind with rid backend, since I had free time
for tests today. This is what I've done for few min.
smb.conf from the testing pc
[global]
workgroup = XXXX
security = ads
realm = XXXX.X.XX
log file = /var/log/samba/%m.log
log level = 1
idmap config * : backend = tdb
idmap config * : range = 3000-7999
winbind nss info = rfc2307
winbind use default domain = yes
# winbind separator = +
template shell = /usr/bin/bash
template homedir = /home/%U
idmap config XXXX : backend = rid
idmap config XXXX : range = 10000-999999
passdb backend = tdbsam
with the current config I successfully join the domain, can list users and
groups with both the wbinfo command and getent passwd/group, but if I want
to *su testdomainuser* it goes to bash-4.2$, no home dir is created which
obviously means that I can't login with domain account.
My AD server config is untouched (yet)
Cheers
On Wed, May 2, 2018 at 9:34 AM, Zdravko Zdravkov <nirayah at gmail.com>
wrote:
> 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
>>
>
>
On Thu, 3 May 2018 18:08:20 +0100 Zdravko Zdravkov via samba <samba at lists.samba.org> wrote:> Hi Rowland. > > As suggested I switched to winbind with rid backend, since I had free > time for tests today. This is what I've done for few min. > > smb.conf from the testing pc > > [global] > workgroup = XXXX > security = ads > realm = XXXX.X.XX > > log file = /var/log/samba/%m.log > log level = 1 > > idmap config * : backend = tdb > idmap config * : range = 3000-7999 > > winbind use default domain = yes > template shell = /usr/bin/bash > template homedir = /home/%U > > idmap config XXXX : backend = rid > idmap config XXXX : range = 10000-999999 >The above should work> > with the current config I successfully join the domain, can list > users and groups with both the wbinfo command and getent > passwd/group, but if I want to *su testdomainuser* it goes to > bash-4.2$, no home dir is created which obviously means that I can't > login with domain account.You need to use pam_mkhomedir, you can do this on debian by adding this to /etc/pam.d/common-account: session required pam_mkhomedir.so skel=/etc/skel/ umask=0022 This will create the users homedir the first time the user logs in. I believe it is called something else on red hat, pam_oddjob ??> > My AD server config is untouched (yet)Good, you don't really want you users to log into the DC, but if you do, you just set it up in the same way as a Unix domain member. Rowland