[Samba] Pam_mount not working with "sec=krb5"

Wed Nov 4 15:50:15 UTC 2015

> However, I have two objections at first glance:
> a) if you remove AD access for an AD user, this user can't mount samba
> shares, because he won't get authenticated correctly (on the Samba file
> server sharing the homes), no?
Looks correct to me what your saying,
But how are you removing ad access from an AD user? 

> b) if you use NFS, and I tried that, and a user creates subfolders and
> files in his nfs-mounted home share, these subcontainers won't have the
> correctly inherited Windows ACLs (ergo problems with these shares when
> accessing them from Windows AD clients)
>
Strange, this works for me correct in the home folder. 

Test1 : login on a server with a NFS mounted homedir nsfV4 kerberos mounted.
If i create a folder from a ssh shell access, with a kerberos authenticated user. ( for me a user who does not type its password on ssh access ) 

And im also use-ing the setting : 
acl_xattr:ignore system acls = yes 
on the home folder share.

Getfacl test shows me :  
mkdir testing

getfacl testing/
# file: testing/
# owner: mytestuser
# group: domain\040users
user::rwx
group::r-x
other::---

This is what i see on the server where the homedrive is. 
# file: testing/
# owner: mytestuser
# group: domain\040users
user::rwx
user:root:rwx                   #effective:r-x
user: mytestuser:rwx                  #effective:r-x
group::---
group:root:---
group:BUILTIN\134administrators:rwx#effective:r-x
mask::r-x
other::---
default:user::rwx
default:user:root:rwx
default:user: mytestuser:rwx
default:group::---
default:group:root:---
default:group:BUILTIN\134administrators:rwx
default:mask::rwx
default:other::---

a folder created on the same server as the homedrive, gets the same result in getfacl. 

So, show the example where it goes wrong for you. 

Greetz, 

Louis

> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-bounces at lists.samba.org] Namens Ole Traupe
> Verzonden: woensdag 4 november 2015 15:22
> Aan: samba at lists.samba.org
> Onderwerp: Re: [Samba] Pam_mount not working with "sec=krb5"
> 
> 
> 
> Am 04.11.2015 um 14:49 schrieb mathias dufresne:
> > 2015-11-04 13:58 GMT+01:00 Ole Traupe <ole.traupe at tu-berlin.de>:
> >
> >> Mathias, thanks again! This sounds like a very reasonable approach. I
> know
> >> that with remote ssh and public key authentication you can set the
> limit to
> >> a single possible command. is this also possible with AD users?
> >>
> > I'm interested by the restriction to only one command for users. The
> only I
> > see that possible is to place that only command in place of the shell in
> > user declaration.
> >
> > Now to answer to question, AD from Linux systems point of view is a
> > database in which Linux systems can get users information to create
> system
> > users (using tools as winbind or sssd...). These tools generate system
> > users using information from AD.
> > The point here is there is no difference between system users (from
> > /etc/passwd) and system users (from AD). They both are system users,
> they
> > must react identically. Modulo the fact as they are AD users AD can give
> > them access to AD resources. But once you removed the access to AD
> > resources, system users are system users, coming from AD or not :)
> >
> >
> >> Unfortunately, I don't have 'multiuser' support in my current cifs-
> utils
> >> version 4.8. So I would end up with your designated user being the
> owner of
> >> all the files and folders created by my AD users. Because he is the one
> >> having mounted the resource.
> >
> > Unfortunately I can't help you more on that as I have no knowledge about
> > CIFS + Kerberos or NFS + Kerberos.
> > I spoke about NFS + Kerberos because it seems you want to mount users
> home
> > directories on Linux boxes when these home directories are hosted by
> > another Linux box. File sharing between Linux can be performed through
> NFS
> > and NFS also supports Kerberos.
> 
> Mathias, thank you for your extensive thoughts. I will have a thorough
> look at it!
> 
> However, I have two objections at first glance:
> a) if you remove AD access for an AD user, this user can't mount samba
> shares, because he won't get authenticated correctly (on the Samba file
> server sharing the homes), no?
> b) if you use NFS, and I tried that, and a user creates subfolders and
> files in his nfs-mounted home share, these subcontainers won't have the
> correctly inherited Windows ACLs (ergo problems with these shares when
> accessing them from Windows AD clients)
> 
> 
> >
> > As I said, I have no knowledge at all on that subject so I can't do more
> > than that...
> >
> > Best regards,
> >
> > mathias
> >
> >
> >
> >> Am 04.11.2015 um 13:36 schrieb mathias dufresne:
> >>
> >>> First please note the following is not really linked to your NFS
> question,
> >>> it's more related to automation, credentials everywhere and how to
> secure
> >>> them a little bit.
> >>>
> >>> The point dealing with keytab or credentials in general when used for
> >>> automation, as these credentials can potentially used by some
> attacker, is
> >>> to create dedicated user which can perform only what it is supposed to
> >>> perform.
> >>>
> >>> To say that differently, now I'm using Samba test platform and the
> keytab
> >>> I
> >>> use contains MY.DOMAIN\administrator credentials. This account is
> member
> >>> of
> >>> "domain admins" group so it can do almost everything and so using that
> >>> user
> >>> for automation is potentially dangerous. If someone get that keytab,
> it
> >>> can
> >>> authenticate against my test AD and perform everything he wants to.
> >>> I should create one user for (almost) each action which requires
> >>> credentials, creating users which can perform only one action, the
> action
> >>> they would perform.
> >>>
> >>> So in your case you need one user able to mount shares. Create a user
> >>> which
> >>> can do that and apply on that user restrictions for he can perform
> only
> >>> that. Then if some attacker get the keytab of that user, this attacker
> >>> will
> >>> be able to mount shares, nothing else.
> >>>
> >>> Having users passwords wandering everywhere is not a real issue
> finally,
> >>> when these users are well configured.
> >>>
> >>> 2015-11-04 12:33 GMT+01:00 Ole Traupe <ole.traupe at tu-berlin.de>:
> >>>
> >>>
> >>>> If by "key" you meant keytab then you were right. A keytab is a file
> >>>>> dedicated to contains credentials (https://kb.iu.edu/d/aumh or
> >>>>> http://web.mit.edu/Kerberos/krb5-1.12/doc/basic/keytab_def.html).
> >>>>>
> >>>>> Keytab are used when you want to automate actions which need
> >>>>> authentication. When some automated action requires credentials you
> >>>>> have to
> >>>>> provide these credentials so some where you will need a couple
> >>>>> user/password. Without keytab you would need a clear text password,
> or a
> >>>>> hashed one if it is possible. With a keytab you have encrypted
> >>>>> credentials
> >>>>> which not worst than clear text.
> >>>>>
> >>>>> Of course it is a security hole: someone can use that keytab to
> >>>>> authenticate. Today, next week... until contained credentials are
> valid.
> >>>>> The point, for me, is this hole does not comes from the keytab but
> from
> >>>>> automation which needs credentials stored somewhere.
> >>>>>
> >>>>> Mathias, thank you for making the purpose and functioning of the
> keytab
> >>>> clearer for me!
> >>>>
> >>>> I think it is possible to have automation without storing
> credentials.
> >>>> That is what kerberos authentication is for.
> >>>>
> >>>> Before compiling a more recent version of cifs-utils to get the
> >>>> 'multiuser' option, I tested this 'sec=krb5' option more thoroughly.
> If
> >>>> my
> >>>> observations were correct, it turns out: if you use it (together with
> >>>> 'cruid=12345'), you can't have 'username=user_xyz' as an option, too.
> You
> >>>> do either (username and) password-based authentication, or you use an
> >>>> existing kerberos cache for that. This was formerly acquired
> >>>> interactively
> >>>> via username/password, and that way you have something like a single
> >>>> sign-on.
> >>>>
> >>>> This is what works so far:
> >>>>
> >>>> 1. log in as the domain user 'userxyz' (id=12345) via ssh to a Linux
> >>>> member server -> the kerberos cache file is created in /tmp
> >>>> ("krb5cc_12345_afcdeb")
> >>>> 2. while the user is logged in (and the cache exists), use this
> command
> >>>> to
> >>>> mount his home share (as root):
> >>>> # mount.cifs //server/home/userxyz /home/userxyz -o
> >>>> sec=krb5,cruid=12345,uid=12345,gid=someGroupID
> >>>>
> >>>> So, users' krb5 cache files are actually used by the cifs mount
> upcall. I
> >>>> made sure that no other cache file was present, and I never put
> anything
> >>>> into keytab.
> >>>>
> >>>> What isn't working so far, is automating this mount via pam_mount.
> >>>> Pam_mount of cifs on this member server is working with explicit
> >>>> credentials, so far. But if I use 'sec=krb5,cruid=12345' I get the
> >>>> # mount error(126): Required key not available
> >>>> which is what I also get, when I try to mount without logging in as
> >>>> 'userxyz', first.
> >>>>
> >>>> Here is my volume definition from the
> '/etc/security/pam_mount.conf.xml'
> >>>> file:
> >>>>
> >>>> <volume fstype="cifs" server="server" path="home/userxyz"
> >>>> mountpoint="/home/userxyz"
> >>>> options="sec=krb5,cruid=12345,uid=12345,gid=someGroupID,nosuid,nodev"
> />
> >>>>
> >>>> I figure, that I have to adjust my pam configuration to perform
> kerberos
> >>>> authentication _before_ doing the pam_mount.
> >>>>
> >>>> I will report back with more results.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> To unsubscribe from this list go to the following URL and read the
> >>>> instructions:  https://lists.samba.org/mailman/options/samba
> >>>>
> >>>>
> >> --
> >> To unsubscribe from this list go to the following URL and read the
> >> instructions:  https://lists.samba.org/mailman/options/samba
> >>
> 
> 
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba