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