> > 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.
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 >
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? 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. 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 >>
On 04/11/15 13:36, mathias dufresne wrote:> 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.+1. Hence our advice to create a minimalist user solely for mounting the share. Although he must have a uidNumber, make sure that user cannot login. A good way to do that is to add loginShell: /bin/false to his Distinguished Name in AD. HTH> > 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 >>