search for: cruid

...ust ask. I use pam_mount with the following volume definition in the "/etc/security/pam_mount.conf.xml": <volume fstype="cifs" server="server" path="home/%(USER)" mountpoint="/home/%(USER)" sgrp="domain users" options="sec=krb5,cruid=%(USERUID),uid=%(USERUID),gid=someLiteralGroupID,nosuid,nodev" /> But this 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 //serve...

...mount with the following volume definition in the > "/etc/security/pam_mount.conf.xml": > <volume fstype="cifs" server="server" path="home/%(USER)" > mountpoint="/home/%(USER)" sgrp="domain users" > options="sec=krb5,cruid=%(USERUID),uid=%(USERUID),gid=someLiteralGroupID,nosuid,nodev" > /> > > But this 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 mo...

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

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

...t I did. But it fails even when mounting manually: > 1. Connect on the desktop using domain user "yvan.masson" (either > graphically / TTY / SSH). Kerberos ticket is properly created. > 2. Running "sudo mount -t cifs //ad.FOO.BAR.LOCAL/Echange /mnt -o > user=yvan.masson,cruid=yvan.masson,sec=krb5" fails with "Required key > not available". Offcourse, the user is not allowed to mount it. user=yvan.masson << You need to delegate the computer to do it for the user. > 3. Running "sudo mount -t cifs //foo-ad.FOO.BAR.LOCAL/Echange /mnt -o...

...as soon as I put "sec=krb5" in the mount options (and leaving out the password part), I get this error: # mount error(126): Required key not available I did an extensive web search and saw that many people have problems here. But I found no definite solution. I tried to specify 'cruid=%(USERID)' in the case of pam_mount, or 'cruid=12345' in the manual case (12345 being the literal uid of the user). I also tried getting rid of the strange file ending of the krb5 key cache, because in my case it is e.g. "krb5cc_12345_Zb1yLU". And I tried chowning the file...

...9;File System' Double click '/mnt' All the mounted shares are there and I can interact with them. If I run 'mount', I find these lines: adminuser at testdm12:~$ mount ................. //devstation.samdom.example.com/data on /mnt/test type cifs (rw,relatime,vers=3.1.1,sec=krb5,cruid=0,cache=strict,multiuser,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.1.141,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,noperm,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1) //devstation.samdom.example.com/Mtest1 on /mnt/testmount1 type cifs (rw...

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

...login. That is what I did. But it fails even when mounting manually: 1. Connect on the desktop using domain user "yvan.masson" (either graphically / TTY / SSH). Kerberos ticket is properly created. 2. Running "sudo mount -t cifs //ad.FOO.BAR.LOCAL/Echange /mnt -o user=yvan.masson,cruid=yvan.masson,sec=krb5" fails with "Required key not available". 3. Running "sudo mount -t cifs //foo-ad.FOO.BAR.LOCAL/Echange /mnt -o user=yvan.masson,cruid=yvan.masson,sec=krb5" works. This seems strange to me since "foo-ad" and "ad" refer to the same...

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

Le 10/03/2020 ? 10:37, Rowland penny via samba a ?crit?: > On 10/03/2020 09:18, Yvan Masson via samba wrote: >> If think I did not properly explain my setup, sorry for that: Samba >> here is not sharing anything. It is just used for joining a Windows >> domain, so that users can sit on a chair in front of this Debian >> computer, use their domain credentials in

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

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

...> in the mount options (and leaving out the password part), I get this > error: > > # mount error(126): Required key not available > > I did an extensive web search and saw that many people have problems > here. But I found no definite solution. I tried to specify > 'cruid=%(USERID)' in the case of pam_mount, or 'cruid=12345' in the > manual case (12345 being the literal uid of the user). I also tried > getting rid of the strange file ending of the krb5 key cache, because > in my case it is e.g. "krb5cc_12345_Zb1yLU". And I tried cho...

Could someone tell me what this return code means? This is mount.cifs version 4.8.1 on a centos 6.4 workstation joined to an AD domain, using automount with auto.cifs containing * -fstype=cifs,sec=krb5,user=&,uid=$UID,gid=$GID,cruid=$UID,noserverino ://server.address.edu/& When the machine is freshly booted, and for awhile afterwards, domain accounts can mount with no problem. But after some period of time, maybe day or so, the mount fails with the above error. Rebooting fixes it. Has anyone ever seen this before? I...

...t I did. But it fails even when mounting manually: > 1. Connect on the desktop using domain user "yvan.masson" (either > graphically / TTY / SSH). Kerberos ticket is properly created. > 2. Running "sudo mount -t cifs //ad.FOO.BAR.LOCAL/Echange /mnt -o > user=yvan.masson,cruid=yvan.masson,sec=krb5" fails with "Required key > not available". > 3. Running "sudo mount -t cifs //foo-ad.FOO.BAR.LOCAL/Echange /mnt -o > user=yvan.masson,cruid=yvan.masson,sec=krb5" works. > > This seems strange to me since "foo-ad" and "ad...

On 1/29/24 13:08, Rowland Penny via samba wrote: > On Mon, 29 Jan 2024 12:51:37 -0800 > Peter Carlson via samba<samba at lists.samba.org> wrote: > > >> Just did a quick test, the big T comes after setting permissions in >> windows >> >> root at fs1:/var/log# cd /data >> root at fs1:/data# mkdir -m 1777 test2 > No it doesn't, you are setting

...nd S4 server are CentOS 6, and the DC is running samba-4.1.11 from sernet. Autofs is getting it's maps from LDAP from the DC. This part works fine, automount -m shows: Mount point: /share source(s): instance type(s): sss map: auto.share public | -fstype=cifs,sec=krb5,user=$USER,cruid=$UID ://fileserver/public If a user attempts to access /share/public, it is mounted with their kerberos credentials...for a while. But eventually it stops working, and I get errors like this in the log: Sep 5 07:43:00 test kernel: CIFS VFS: Send error in SessSetup = -128 Sep 5 07:43:00 test...

...fails even when mounting manually: >> 1. Connect on the desktop using domain user "yvan.masson" (either >> graphically / TTY / SSH). Kerberos ticket is properly created. >> 2. Running "sudo mount -t cifs //ad.FOO.BAR.LOCAL/Echange /mnt -o >> user=yvan.masson,cruid=yvan.masson,sec=krb5" fails with "Required key >> not available". >> 3. Running "sudo mount -t cifs //foo-ad.FOO.BAR.LOCAL/Echange /mnt -o >> user=yvan.masson,cruid=yvan.masson,sec=krb5" works. >> >> This seems strange to me since "foo-a...

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