search for: somegroupid

...inux 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 exp...

...he 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. >> P...

...wouldn't work initially, I got the # mount error(126): Required key not available However, once the respective user had logged in, I could use these parameters for a manual mount as root: # mount.cifs //server/home/userxyz /home/userxyz -o sec=krb5,cruid=uid_of_userxyz,uid=uid_of_userxyz,gid=someGroupID In another attempt, I could also hard code the "cruid=12345" for pam_mount, and then log into the same machine twice. The second time the home share was mounted correctly So I figured, that PAM should do kerberos first. Therefore, I swapped these two lines in the "/etc/pam.d/pas...

..._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...

...gt; 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 mem...

...t;> ("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 v...

..._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...

...I got the > # mount error(126): Required key not available > > However, once the respective user had logged in, I could use these > parameters for a manual mount as root: > # mount.cifs //server/home/userxyz /home/userxyz -o > sec=krb5,cruid=uid_of_userxyz,uid=uid_of_userxyz,gid=someGroupID > > In another attempt, I could also hard code the "cruid=12345" for > pam_mount, and then log into the same machine twice. The second time > the home share was mounted correctly > > So I figured, that PAM should do kerberos first. Therefore, I swapped > these two...

>> 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

...>>> 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. > >>>> > >>&g...