>> I mean, putting the key in the keytab looks like a security risk to me. > In what way does it appear any more of a risk than having the keys > which you have there already? Even if someone steals the keytab, > they're gonna be hard pressed to crack the key in the few hours before > the tgt expires. Do you have very sensitive data maybe?Ok. And maybe I misunderstood something: I thought the key would be valid indefinitely, while the ticket expires. But then there is the Ticket-Granting-Ticket (TGT). And if also the TGT expires after a few hours, for how long will a share mounted with "sec=krb5,multiuser" be accessible to the user? I am sorry for all these dummy questions, but I really find this matter hard to understand. Thank you very much for your help!>> Would be nice if you could use kerberos on the fly. > > You _are_ using it on the fly.The tgt is obtained without any > interaction on the part of the user. >> >> Unfortunately, I don't find such a detailed log in /var/log/messages. >> >>>> >>>> Also, if the user is not mounting his home share, but somebody >>>> else, this _other_ user will be the owner of newly created files >>>> and folders, right >>> No. With multiuser, acl and permissions are respected. If the user >>> would normally be the owner of newly created files, then he will be >>> also over cifs. >> Great, that sounds exactly as I would like it to be. >> >>> >>> One other thing, you need a recent version of cifs utils (we don't >>> think Centos has) >> Mine is cifs-utils.x86_64 4.8.1-20.el6 > We can confirm it works with 6.2. > HTHThanks. So migrating the server to CentOS 7 would be advised here if one is afraid of bad interactions of Samba 3.1 with later (and potentially buggy) experimental cifs-utils versions for CentOS 6.
On 03/11/15 10:56, Ole Traupe wrote:> >>> I mean, putting the key in the keytab looks like a security risk to me. >> In what way does it appear any more of a risk than having the keys >> which you have there already? Even if someone steals the keytab, >> they're gonna be hard pressed to crack the key in the few hours >> before the tgt expires. Do you have very sensitive data maybe? > > Ok. And maybe I misunderstood something: I thought the key would be > valid indefinitely, while the ticket expires. But then there is the > Ticket-Granting-Ticket (TGT). And if also the TGT expires after a few > hours, for how long will a share mounted with "sec=krb5,multiuser" be > accessible to the user?Hi The upcall will maintain the validity of the mount for as long as it is accessed, so maybe a better question would be how long a ticket does your kdc issue for a user. The latter will be the determining factor, not the upcall.> > I am sorry for all these dummy questions, but I really find this > matter hard to understand. > > Thank you very much for your help! > > >>> Would be nice if you could use kerberos on the fly. >> >> You _are_ using it on the fly.The tgt is obtained without any >> interaction on the part of the user. >>> >>> Unfortunately, I don't find such a detailed log in /var/log/messages. >>> >>>>> >>>>> Also, if the user is not mounting his home share, but somebody >>>>> else, this _other_ user will be the owner of newly created files >>>>> and folders, right >>>> No. With multiuser, acl and permissions are respected. If the user >>>> would normally be the owner of newly created files, then he will be >>>> also over cifs. >>> Great, that sounds exactly as I would like it to be. >>> >>>> >>>> One other thing, you need a recent version of cifs utils (we don't >>>> think Centos has) >>> Mine is cifs-utils.x86_64 4.8.1-20.el6 >> We can confirm it works with 6.2. >> HTH > > Thanks. So migrating the server to CentOS 7 would be advised here if > one is afraid of bad interactions of Samba 3.1 with later (and > potentially buggy) experimental cifs-utils versions for CentOS 6.We think that the only way with cifs on Centos is to get the source and build it. If the rest of it is working but the upcalls are not then keep with what you have, uninstall the cifs utils making sure the binaries have been removed and are not at a non-standard location, then make install. Good luck and HTH> > >
Am 03.11.2015 um 16:44 schrieb buhorojo:> On 03/11/15 10:56, Ole Traupe wrote: >> >>>> I mean, putting the key in the keytab looks like a security risk to >>>> me. >>> In what way does it appear any more of a risk than having the keys >>> which you have there already? Even if someone steals the keytab, >>> they're gonna be hard pressed to crack the key in the few hours >>> before the tgt expires. Do you have very sensitive data maybe? >> >> Ok. And maybe I misunderstood something: I thought the key would be >> valid indefinitely, while the ticket expires. But then there is the >> Ticket-Granting-Ticket (TGT). And if also the TGT expires after a few >> hours, for how long will a share mounted with "sec=krb5,multiuser" be >> accessible to the user? > Hi > The upcall will maintain the validity of the mount for as long as it > is accessed, so maybe a better question would be how long a ticket > does your kdc issue for a user. The latter will be the determining > factor, not the upcall.Up to 7 days if renewed within 24h, if I understand correctly (ticket_lifetime = 24h, renew_lifetime = 7d). Thanks for the clarification!> >> >> I am sorry for all these dummy questions, but I really find this >> matter hard to understand. >> >> Thank you very much for your help! >> >> >>>> Would be nice if you could use kerberos on the fly. >>> >>> You _are_ using it on the fly.The tgt is obtained without any >>> interaction on the part of the user. >>>> >>>> Unfortunately, I don't find such a detailed log in /var/log/messages. >>>> >>>>>> >>>>>> Also, if the user is not mounting his home share, but somebody >>>>>> else, this _other_ user will be the owner of newly created files >>>>>> and folders, right >>>>> No. With multiuser, acl and permissions are respected. If the user >>>>> would normally be the owner of newly created files, then he will >>>>> be also over cifs. >>>> Great, that sounds exactly as I would like it to be. >>>> >>>>> >>>>> One other thing, you need a recent version of cifs utils (we don't >>>>> think Centos has) >>>> Mine is cifs-utils.x86_64 4.8.1-20.el6 >>> We can confirm it works with 6.2. >>> HTH >> >> Thanks. So migrating the server to CentOS 7 would be advised here if >> one is afraid of bad interactions of Samba 3.1 with later (and >> potentially buggy) experimental cifs-utils versions for CentOS 6. > > We think that the only way with cifs on Centos is to get the source > and build it. If the rest of it is working but the upcalls are not > then keep with what you have, uninstall the cifs utils making sure the > binaries have been removed and are not at a non-standard location, > then make install.So there will be no conflict with other samba components such as in samba-common? And sorry for the typo, it is Samba 3.6.> > Good luck and HTHAgain, thank you very much!
2015-11-03 10:56 GMT+01:00 Ole Traupe <ole.traupe at tu-berlin.de>:> > I mean, putting the key in the keytab looks like a security risk to me. >>> >> In what way does it appear any more of a risk than having the keys which >> you have there already? Even if someone steals the keytab, they're gonna be >> hard pressed to crack the key in the few hours before the tgt expires. Do >> you have very sensitive data maybe? >> > > Ok. And maybe I misunderstood something: I thought the key would be valid > indefinitely, while the ticket expires.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.> But then there is the Ticket-Granting-Ticket (TGT). And if also the TGT > expires after a few hours, for how long will a share mounted with > "sec=krb5,multiuser" be accessible to the user? > > I am sorry for all these dummy questions, but I really find this matter > hard to understand. > > Thank you very much for your help! > > > Would be nice if you could use kerberos on the fly. >>> >> >> You _are_ using it on the fly.The tgt is obtained without any interaction >> on the part of the user. >> >>> >>> Unfortunately, I don't find such a detailed log in /var/log/messages. >>> >>> >>>>> Also, if the user is not mounting his home share, but somebody else, >>>>> this _other_ user will be the owner of newly created files and folders, >>>>> right >>>>> >>>> No. With multiuser, acl and permissions are respected. If the user >>>> would normally be the owner of newly created files, then he will be also >>>> over cifs. >>>> >>> Great, that sounds exactly as I would like it to be. >>> >>> >>>> One other thing, you need a recent version of cifs utils (we don't >>>> think Centos has) >>>> >>> Mine is cifs-utils.x86_64 4.8.1-20.el6 >>> >> We can confirm it works with 6.2. >> HTH >> > > Thanks. So migrating the server to CentOS 7 would be advised here if one > is afraid of bad interactions of Samba 3.1 with later (and potentially > buggy) experimental cifs-utils versions for CentOS 6. > > > > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba >
> > 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.