Discussion:
[Freeipa-users] Mount cifs share using kerberos
John Obaterspok
2015-01-08 09:01:50 UTC
Permalink
Hello,

I have a samba share on the freeipa 4.1 server that I want to mount from
another client that is part of the ipa domain
I've tried:
mount -t cifs //ipaserver.DOMAIN.LAN/share /mnt/point -o sec=krb5

Shouldn't I be able to do the mount this way?

-- john
Simo Sorce
2015-01-08 17:51:29 UTC
Permalink
On Thu, 8 Jan 2015 10:01:50 +0100
Post by John Obaterspok
Hello,
I have a samba share on the freeipa 4.1 server that I want to mount
from another client that is part of the ipa domain
mount -t cifs //ipaserver.DOMAIN.LAN/share /mnt/point -o sec=krb5
Shouldn't I be able to do the mount this way?
-- john
You should be able to, what's the error ?

Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
John Obaterspok
2015-01-08 21:29:00 UTC
Permalink
Hello,

I've tried to do the following on the client (and also on the ipaserver
itself) where I want to the the ipaserver share mounted.

[***@ipaserver mnt]# mount -t cifs //ipaserver.MY.LAN/TheShare -o sec=krb5
mountpoint
mount error(126): Required key not available
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

(root has an admin ticket aquired)

Any hints for a newbie?

-- john
Post by Simo Sorce
On Thu, 8 Jan 2015 10:01:50 +0100
Post by John Obaterspok
Hello,
I have a samba share on the freeipa 4.1 server that I want to mount
from another client that is part of the ipa domain
mount -t cifs //ipaserver.DOMAIN.LAN/share /mnt/point -o sec=krb5
Shouldn't I be able to do the mount this way?
-- john
You should be able to, what's the error ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York
Alexander Bokovoy
2015-01-09 09:11:23 UTC
Permalink
Post by John Obaterspok
Hello,
I've tried to do the following on the client (and also on the ipaserver
itself) where I want to the the ipaserver share mounted.
mountpoint
mount error(126): Required key not available
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
(root has an admin ticket aquired)
Any hints for a newbie?
Do you have proper configuration in request-key.conf(5)?

On Fedora 21 we have /etc/request-key.d/cifs.upcall.conf and
/etc/request-key.d/cifs.idmap.conf to allow kernel to properly fetch
Kerberos keys and map IDs of CIFS identities. These configurations are
part of cifs-utils package which also supplies mount.cifs.
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
John Obaterspok
2015-01-09 10:26:12 UTC
Permalink
Post by Alexander Bokovoy
Post by John Obaterspok
Hello,
I've tried to do the following on the client (and also on the ipaserver
itself) where I want to the the ipaserver share mounted.
mountpoint
mount error(126): Required key not available
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
(root has an admin ticket aquired)
Any hints for a newbie?
Do you have proper configuration in request-key.conf(5)?
I didn't know about those files, so if there are no defaults then I guess I
don't have a proper configuration.
Post by Alexander Bokovoy
On Fedora 21 we have /etc/request-key.d/cifs.upcall.conf and
/etc/request-key.d/cifs.idmap.conf to allow kernel to properly fetch
Kerberos keys and map IDs of CIFS identities. These configurations are
part of cifs-utils package which also supplies mount.cifs.
Thanks Alexander,

-- john
John Obaterspok
2015-01-09 16:38:31 UTC
Permalink
Post by Alexander Bokovoy
On Fedora 21 we have /etc/request-key.d/cifs.upcall.conf and
/etc/request-key.d/cifs.idmap.conf to allow kernel to properly fetch
Kerberos keys and map IDs of CIFS identities. These configurations are
part of cifs-utils package which also supplies mount.cifs.
I have no /etc/request-key.d/cifs.upcall.conf on my F21. Is it suppose to
be there?
This is what I have:

[***@ipaserver etc]# cat request-key.conf
###############################################################################
# .... snip ....
################################################################################

#OP TYPE DESCRIPTION CALLOUT INFO PROGRAM ARG1 ARG2 ARG3 ...
#====== ======= =============== ===============
===============================
create dns_resolver * * /sbin/key.dns_resolver %k
create user debug:* negate /bin/keyctl negate %k 30 %S
create user debug:* rejected /bin/keyctl reject %k 30 %c
%S
create user debug:* expired /bin/keyctl reject %k 30 %c
%S
create user debug:* revoked /bin/keyctl reject %k 30 %c
%S
create user debug:loop:* * |/bin/cat
create user debug:* *
/usr/share/keyutils/request-key-debug.sh %k %d %c %S
negate * * * /bin/keyctl negate %k 30 %S

[***@ipaserver etc]# ls request-key.d/
cifs.idmap.conf cifs.spnego.conf id_resolver.conf

[***@ipaserver etc]# cat request-key.d/cifs.idmap.conf
create cifs.idmap * * /usr/sbin/cifs.idmap %k

[***@ipaserver etc]# cat request-key.d/cifs.spnego.conf
create cifs.spnego * * /usr/sbin/cifs.upcall %k


-- john
Alexander Bokovoy
2015-01-09 17:12:01 UTC
Permalink
Post by John Obaterspok
Post by Alexander Bokovoy
On Fedora 21 we have /etc/request-key.d/cifs.upcall.conf and
/etc/request-key.d/cifs.idmap.conf to allow kernel to properly fetch
Kerberos keys and map IDs of CIFS identities. These configurations are
part of cifs-utils package which also supplies mount.cifs.
I have no /etc/request-key.d/cifs.upcall.conf on my F21. Is it suppose to
be there?
No, it was my fault, forgetting the actual name -- it is
Post by John Obaterspok
###############################################################################
# .... snip ....
################################################################################
#OP TYPE DESCRIPTION CALLOUT INFO PROGRAM ARG1 ARG2 ARG3 ...
#====== ======= =============== ===============
===============================
create dns_resolver * * /sbin/key.dns_resolver %k
create user debug:* negate /bin/keyctl negate %k 30 %S
create user debug:* rejected /bin/keyctl reject %k 30 %c
%S
create user debug:* expired /bin/keyctl reject %k 30 %c
%S
create user debug:* revoked /bin/keyctl reject %k 30 %c
%S
create user debug:loop:* * |/bin/cat
create user debug:* *
/usr/share/keyutils/request-key-debug.sh %k %d %c %S
negate * * * /bin/keyctl negate %k 30 %S
cifs.idmap.conf cifs.spnego.conf id_resolver.conf
create cifs.idmap * * /usr/sbin/cifs.idmap %k
create cifs.spnego * * /usr/sbin/cifs.upcall %k
So if you have all these configs right, can you add --verbose to
mount.cifs arguments _before_ -o options?

mount -t cifs //ipaserver.MY.LAN/TheShare --verbose -o sec=krb5

and you can enable debugging before mounting in /proc/fs/cifs/, see
https://wiki.samba.org/index.php/LinuxCIFS_troubleshooting
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
John Obaterspok
2015-01-09 21:52:35 UTC
Permalink
Post by Alexander Bokovoy
So if you have all these configs right, can you add --verbose to
mount.cifs arguments _before_ -o options?
mount -t cifs //ipaserver.MY.LAN/TheShare --verbose -o sec=krb5
and you can enable debugging before mounting in /proc/fs/cifs/, see
https://wiki.samba.org/index.php/LinuxCIFS_troubleshooting
--
[***@ipaserver ~]$ rpm -q cifs-utils
cifs-utils-6.4-2.fc21.x86_64

[***@ipaserver mnt]# su root
[***@ipaserver mnt]# kdestroy
[***@ipaserver mnt]# kinit admin
[***@ipaserver mnt]# klist
Ticket cache: KEYRING:persistent:1434400004:krb_ccache_As3C1bl
Default principal: ***@MY.LAN

Valid starting Expires Service principal
2015-01-09 22:40:37 2015-01-10 22:40:32 krbtgt/***@MY.LAN

[***@ipaserver mnt]#
[***@ipaserver mnt]# mount -t cifs //ipaserver.MY.LAN/TheShare --verbose
-o sec=krb5 mointpoint
mount.cifs kernel mount options:
ip=192.168.0.103,unc=\\ipaserver.MY.LAN\TheShare,sec=krb5,user=john,pass=********
mount error(126): Required key not available
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

[fre jan 9 22:40:15 2015] CIFS VFS: Send error in SessSetup = -126
[fre jan 9 22:40:15 2015] CIFS VFS: cifs_mount failed w/return code = -126
[fre jan 9 22:40:49 2015] CIFS VFS: Send error in SessSetup = -126
[fre jan 9 22:40:49 2015] CIFS VFS: cifs_mount failed w/return code = -126
[fre jan 9 22:42:30 2015] fs/cifs/cifsfs.c: Devname:
//ipaserver.MY.LAN/TheShare flags: 0
[fre jan 9 22:42:30 2015] fs/cifs/connect.c: Username: john
[fre jan 9 22:42:30 2015] fs/cifs/connect.c: file mode: 0x1ed dir mode:
0x1ed
[fre jan 9 22:42:30 2015] fs/cifs/connect.c: CIFS VFS: in cifs_mount as
Xid: 6 with uid: 0
[fre jan 9 22:42:30 2015] fs/cifs/connect.c: UNC:
\\ipaserver.MY.LAN\TheShare
[fre jan 9 22:42:30 2015] fs/cifs/connect.c: Socket created
[fre jan 9 22:42:30 2015] fs/cifs/connect.c: sndbuf 16384 rcvbuf 87380
rcvtimeo 0x1b58
[fre jan 9 22:42:30 2015] fs/cifs/fscache.c:
cifs_fscache_get_client_cookie: (0xffff88007a28dc00/0xffff8800736ee000)
[fre jan 9 22:42:30 2015] fs/cifs/connect.c: CIFS VFS: in cifs_get_smb_ses
as Xid: 7 with uid: 0
[fre jan 9 22:42:30 2015] fs/cifs/connect.c: Existing smb sess not found
[fre jan 9 22:42:30 2015] fs/cifs/cifssmb.c: Requesting extended security.
[fre jan 9 22:42:30 2015] fs/cifs/transport.c: For smb_command 114
[fre jan 9 22:42:30 2015] fs/cifs/transport.c: Sending smb: smb_len=78
[fre jan 9 22:42:30 2015] fs/cifs/connect.c: Demultiplex PID: 20875
[fre jan 9 22:42:30 2015] fs/cifs/connect.c: RFC1002 header 0xb5
[fre jan 9 22:42:30 2015] fs/cifs/misc.c: checkSMB Length: 0xb9,
smb_buf_length: 0xb5
[fre jan 9 22:42:30 2015] fs/cifs/transport.c: cifs_sync_mid_result:
cmd=114 mid=1 state=4
[fre jan 9 22:42:30 2015] fs/cifs/cifssmb.c: Dialect: 2
[fre jan 9 22:42:30 2015] fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348
0xbb92
[fre jan 9 22:42:30 2015] fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348
0x1bb92
[fre jan 9 22:42:30 2015] fs/cifs/asn1.c: OID len = 10 oid = 0x1 0x3 0x6
0x1
[fre jan 9 22:42:30 2015] fs/cifs/cifssmb.c: negprot rc 0
[fre jan 9 22:42:30 2015] fs/cifs/connect.c: Security Mode: 0x3
Capabilities: 0x8080f3fd TimeAdjust: -3600
[fre jan 9 22:42:30 2015] fs/cifs/sess.c: sess setup type 5
[fre jan 9 22:42:30 2015] fs/cifs/cifs_spnego.c: key description =
ver=0x2;host=ipaserver.MY.LAN;ip4=192.168.0.103;sec=krb5;uid=0x0;creduid=0x0;user=john;pid=0x5188
[fre jan 9 22:42:30 2015] CIFS VFS: Send error in SessSetup = -126
[fre jan 9 22:42:30 2015] fs/cifs/connect.c: CIFS VFS: leaving
cifs_get_smb_ses (xid = 7) rc = -126
[fre jan 9 22:42:30 2015] fs/cifs/fscache.c:
cifs_fscache_release_client_cookie: (0xffff88007a28dc00/0xffff8800736ee000)
[fre jan 9 22:42:30 2015] fs/cifs/connect.c: CIFS VFS: leaving cifs_mount
(xid = 6) rc = -126
[fre jan 9 22:42:30 2015] CIFS VFS: cifs_mount failed w/return code = -126

Is it okay that the verbose output says sec=krb5,user=john,pass=******** I
did su from john...

-- john
Gianluca Cecchi
2015-01-10 12:32:35 UTC
Permalink
To get the whole root environment you have to run
su - root
did you try with it?
John Obaterspok
2015-01-11 10:00:16 UTC
Permalink
Post by Gianluca Cecchi
To get the whole root environment you have to run
su - root
did you try with it?
ahh... that works fine Gianluca!

Final question, if I have a file on the share like:
[***@ipaserver mountpoint]$ ll test.txt
-rwxr-----. 1 root admins 12 11 jan 10.42 test.txt

Should I be able to access it if I aquire an admin ticket? Currently I get
Permission denied

[***@ipaserver mountpoint]$ id
uid=1434400004(john) gid=1434400004(john) grupper=1434400004(john)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

[***@ipaserver mountpoint]$ getfacl test.txt
# file: test.txt
# owner: root
# group: admins
user::rwx
group::r--
other::---

[***@ipaserver mountpoint]$ id admin
uid=1434400000(admin) gid=1434400000(admins) groups=1434400000(admins)

[***@ipaserver mountpoint]$ klist
Ticket cache: KEYRING:persistent:1434400004:krb_ccache_MVjxTqf
Default principal: ***@MY.LAN

Valid starting Expires Service principal
2015-01-11 10:43:52 2015-01-12 10:43:50 krbtgt/***@MY.LAN

[***@ipaserver mountpoint]$ cat test.txt
cat: test.txt: Permission denied
Jakub Hrozek
2015-01-11 15:33:23 UTC
Permalink
Post by John Obaterspok
Post by Gianluca Cecchi
To get the whole root environment you have to run
su - root
did you try with it?
ahh... that works fine Gianluca!
-rwxr-----. 1 root admins 12 11 jan 10.42 test.txt
Should I be able to access it if I aquire an admin ticket? Currently I get
Permission denied
uid=1434400004(john) gid=1434400004(john) grupper=1434400004(john)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
# file: test.txt
# owner: root
# group: admins
user::rwx
group::r--
other::---
uid=1434400000(admin) gid=1434400000(admins) groups=1434400000(admins)
Ticket cache: KEYRING:persistent:1434400004:krb_ccache_MVjxTqf
Valid starting Expires Service principal
cat: test.txt: Permission denied
Looks like your account needs to be in the 'admins' group in order to
access the file.

Acquiring the admin ticket doesn't switch the user ID nor add you to the
group..
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
John Obaterspok
2015-01-12 08:46:37 UTC
Permalink
Post by Jakub Hrozek
Post by John Obaterspok
Post by Gianluca Cecchi
To get the whole root environment you have to run
su - root
did you try with it?
ahh... that works fine Gianluca!
-rwxr-----. 1 root admins 12 11 jan 10.42 test.txt
Should I be able to access it if I aquire an admin ticket? Currently I
get
Post by John Obaterspok
Permission denied
uid=1434400004(john) gid=1434400004(john) grupper=1434400004(john)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
# file: test.txt
# owner: root
# group: admins
user::rwx
group::r--
other::---
uid=1434400000(admin) gid=1434400000(admins) groups=1434400000(admins)
Ticket cache: KEYRING:persistent:1434400004:krb_ccache_MVjxTqf
Valid starting Expires Service principal
cat: test.txt: Permission denied
Looks like your account needs to be in the 'admins' group in order to
access the file.
Acquiring the admin ticket doesn't switch the user ID nor add you to the
group..
I thought the krb5 mount option would allow ticked based access to the
file.
Is the purpose of the krb5 mount option just used during mounting of the
share? Otherwise I see no difference compared to not using krb5 mount
option!?

-- john
Alexander Bokovoy
2015-01-12 09:13:43 UTC
Permalink
This post might be inappropriate. Click to display it.
John Obaterspok
2015-01-14 21:16:46 UTC
Permalink
Post by Alexander Bokovoy
Post by John Obaterspok
Post by Jakub Hrozek
Post by John Obaterspok
Post by Gianluca Cecchi
To get the whole root environment you have to run
su - root
did you try with it?
ahh... that works fine Gianluca!
-rwxr-----. 1 root admins 12 11 jan 10.42 test.txt
Should I be able to access it if I aquire an admin ticket? Currently I
get
Post by John Obaterspok
Permission denied
uid=1434400004(john) gid=1434400004(john) grupper=1434400004(john)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
# file: test.txt
# owner: root
# group: admins
user::rwx
group::r--
other::---
uid=1434400000(admin) gid=1434400000(admins) groups=1434400000(admins)
Ticket cache: KEYRING:persistent:1434400004:krb_ccache_MVjxTqf
Valid starting Expires Service principal
cat: test.txt: Permission denied
Looks like your account needs to be in the 'admins' group in order to
access the file.
Acquiring the admin ticket doesn't switch the user ID nor add you to the
group..
I thought the krb5 mount option would allow ticked based access to the
file.
Is the purpose of the krb5 mount option just used during mounting of the
share? Otherwise I see no difference compared to not using krb5 mount
option!?
Its purpose is authentication. After you have been successfully
recognized by the server, both client and server need to map your
identity while authorizing your access to actual files.
In CIFS there are two types of access control which are applied at the
- ACLs per file or directory
- POSIX access control based on uid/gid of a process that accesses the
file or directory
Client-side checks in cifs.ko can be switched off by noperm option. In
this case server side will be doing actual access enforcement, using the
uid/gid mapped on the server side (based on the Kerberos principal),
unless CIFS Unix Extensions were negotiated between cifs.ko and the
server. In the latter case client will pass uid/gid of a client to the
server and server will do the actual check using them instead of
discovering them based on the authentication token.
In case where there is a common identity store in use with Kerberos, it
is often better to use cifs.ko option multiuser which will imply noperm
and server will be doing all the checks.
Simo also added that "You need to pass the 'multiuser' option at mount time
for that, the
default for cifs.ko is still to just use the mount credentials."

Well, I were actually using multiuser in the original test where I got
"permission denied" but there is something weird going on.

mount -t cifs //ipaserver.MY.LAN/Share -o sec=krb5,multiuser mountpoint (I
also tried -o sec=krb5,multiuser,cache=none)

Anyway, it works if I do the mount as root and then as user john gets the
admin ticket *before* going to the share. Then it doesn't matter if I do
kdestroy, I can still access a file that would require admin ticket.
If I remount the share and go to share as john without admin ticket I can't
access a file that would require admin ticket. If I get an admin ticket
then I'm still not able to access the file.

[***@ipaserver mountpoint]$ ll test.txt
-rwxr-----. 1 root admins 12 11 jan 10.42 test.txt

[***@ipaserver mountpoint]$ cat test.txt
Hello World

[***@ipaserver mountpoint]$ id john
uid=1434400004(john) gid=1434400004(john)
groups=1434400004(john),1434400010(mediafiles)

[***@ipaserver mountpoint]$ klist
Ticket cache: KEYRING:persistent:1434400004:krb_ccache_Ri45Eiw
Default principal: ***@MY.LAN

Valid starting Expires Service principal
2015-01-14 21:54:24 2015-01-15 21:53:57 cifs/***@MY.LAN
2015-01-14 21:53:59 2015-01-15 21:53:57 krbtgt/***@MY.LAN

[***@ipaserver mountpoint]$ kdestroy
[***@ipaserver mountpoint]$ klist
klist: Credentials cache keyring 'persistent:1434400004:krb_ccache_Ri45Eiw'
not found

[***@ipaserver mountpoint]$ cat test.txt
Hello World

[***@ipaserver mountpoint]$ klist
klist: Credentials cache keyring 'persistent:1434400004:krb_ccache_Ri45Eiw'
not found

-------------------------------------------------------------
---------- then remount share. john has non-admin ticket ----
-------------------------------------------------------------

[***@ipaserver mountpoint]$ id
uid=1434400004(john) gid=1434400004(john)
groups=1434400004(john),1434400010(mediafiles)
kontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[***@ipaserver mountpoint]$ klist
Ticket cache: KEYRING:persistent:1434400004:krb_ccache_RiwpwLT
Default principal: ***@MY.LAN

Valid starting Expires Service principal
2015-01-14 22:16:00 2015-01-15 22:15:55 cifs/***@MY.LAN
2015-01-14 22:15:58 2015-01-15 22:15:55 krbtgt/***@MY.LAN

[***@ipaserver mountpoint]$ ll test.txt
-rwxr-----. 1 root admins 12 11 jan 10.42 test.txt

[***@ipaserver mountpoint]$ cat test.txt
cat: test.txt: Permission denied

[***@ipaserver mountpoint]$ kinit admin
Password for ***@MY.LAN:

[***@ipaserver mountpoint]$ cat test.txt
cat: test.txt: Permission denied

[***@ipaserver mountpoint]$ klist
Ticket cache: KEYRING:persistent:1434400004:krb_ccache_H7RvRpA
Default principal: ***@MY.LAN

Valid starting Expires Service principal
2015-01-14 22:16:24 2015-01-15 22:16:22 krbtgt/***@MY.LAN





Any ideas?

-- john
Alexander Bokovoy
2015-01-14 21:49:49 UTC
Permalink
Post by John Obaterspok
Post by Alexander Bokovoy
Post by John Obaterspok
Post by Jakub Hrozek
Post by John Obaterspok
Post by Gianluca Cecchi
To get the whole root environment you have to run
su - root
did you try with it?
ahh... that works fine Gianluca!
-rwxr-----. 1 root admins 12 11 jan 10.42 test.txt
Should I be able to access it if I aquire an admin ticket? Currently I
get
Post by John Obaterspok
Permission denied
uid=1434400004(john) gid=1434400004(john) grupper=1434400004(john)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
# file: test.txt
# owner: root
# group: admins
user::rwx
group::r--
other::---
uid=1434400000(admin) gid=1434400000(admins) groups=1434400000(admins)
Ticket cache: KEYRING:persistent:1434400004:krb_ccache_MVjxTqf
Valid starting Expires Service principal
cat: test.txt: Permission denied
Looks like your account needs to be in the 'admins' group in order to
access the file.
Acquiring the admin ticket doesn't switch the user ID nor add you to the
group..
I thought the krb5 mount option would allow ticked based access to the
file.
Is the purpose of the krb5 mount option just used during mounting of the
share? Otherwise I see no difference compared to not using krb5 mount
option!?
Its purpose is authentication. After you have been successfully
recognized by the server, both client and server need to map your
identity while authorizing your access to actual files.
In CIFS there are two types of access control which are applied at the
- ACLs per file or directory
- POSIX access control based on uid/gid of a process that accesses the
file or directory
Client-side checks in cifs.ko can be switched off by noperm option. In
this case server side will be doing actual access enforcement, using the
uid/gid mapped on the server side (based on the Kerberos principal),
unless CIFS Unix Extensions were negotiated between cifs.ko and the
server. In the latter case client will pass uid/gid of a client to the
server and server will do the actual check using them instead of
discovering them based on the authentication token.
In case where there is a common identity store in use with Kerberos, it
is often better to use cifs.ko option multiuser which will imply noperm
and server will be doing all the checks.
Simo also added that "You need to pass the 'multiuser' option at mount time
for that, the
default for cifs.ko is still to just use the mount credentials."
Well, I were actually using multiuser in the original test where I got
"permission denied" but there is something weird going on.
Nothing weird (tl;dr).
Post by John Obaterspok
mount -t cifs //ipaserver.MY.LAN/Share -o sec=krb5,multiuser mountpoint (I
also tried -o sec=krb5,multiuser,cache=none)
Anyway, it works if I do the mount as root and then as user john gets the
admin ticket *before* going to the share. Then it doesn't matter if I do
kdestroy, I can still access a file that would require admin ticket.
If I remount the share and go to share as john without admin ticket I can't
access a file that would require admin ticket. If I get an admin ticket
then I'm still not able to access the file.
Kerberos authentication happens when you first access the share as a new
user -- cifs.ko will ask userspace to provide Kerberos credentials to
the kernel so that negotiation can happen. Once it is done, the
credentials are valid until the actual Kerberos ticket expires or until
session expires.

So when you access file as john while having admin ticket, you get admin
ticket used for multiuser access. Destroying ccache does not affect
already performed negotiation.

When you remount, previous credentials that cifs.ko used are cleaned,
thus cannot be used. If you try to access the mount point as 'john'
without Kerberos credentials, you'd be negotiating anonymous connection
which would only succeed if the share is allowed to connect to
anonymously (guest ok = yes).

However, you accessed the share with john Kerberos credentials. These
credentials were negotiated and will be valid until the connection is
dropped or ticket expires, whichever event comes first. In fact, cifs.ko
expires sessions periodically but I was unable to find exact expiration
time myself.
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
Simo Sorce
2015-01-13 18:15:42 UTC
Permalink
On Mon, 12 Jan 2015 09:46:37 +0100
Post by John Obaterspok
Post by Jakub Hrozek
2015-01-10 13:32 GMT+01:00 Gianluca Cecchi
Post by Gianluca Cecchi
To get the whole root environment you have to run
su - root
did you try with it?
ahh... that works fine Gianluca!
-rwxr-----. 1 root admins 12 11 jan 10.42 test.txt
Should I be able to access it if I aquire an admin ticket?
Currently I
get
Permission denied
uid=1434400004(john) gid=1434400004(john) grupper=1434400004(john)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
# file: test.txt
# owner: root
# group: admins
user::rwx
group::r--
other::---
uid=1434400000(admin) gid=1434400000(admins)
groups=1434400000(admins)
Ticket cache: KEYRING:persistent:1434400004:krb_ccache_MVjxTqf
Valid starting Expires Service principal
cat: test.txt: Permission denied
Looks like your account needs to be in the 'admins' group in order
to access the file.
Acquiring the admin ticket doesn't switch the user ID nor add you
to the group..
I thought the krb5 mount option would allow ticked based access to the
file.
Is the purpose of the krb5 mount option just used during mounting of
the share? Otherwise I see no difference compared to not using krb5
mount option!?
You need to pass the 'multiuser' option at mount time for that, the
default for cifs.ko is still to just use the mount credentials.

See mount.cifs manpage, search for 'multiuser'

Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
Simo Sorce
2015-01-09 20:49:30 UTC
Permalink
On Thu, 8 Jan 2015 22:29:00 +0100
Post by John Obaterspok
Hello,
I've tried to do the following on the client (and also on the
ipaserver itself) where I want to the the ipaserver share mounted.
sec=krb5 mountpoint
mount error(126): Required key not available
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
(root has an admin ticket aquired)
Any hints for a newbie?
What does klist say ?
and what version of cifs-utils ?

Simo.
Post by John Obaterspok
-- john
Post by Simo Sorce
On Thu, 8 Jan 2015 10:01:50 +0100
Post by John Obaterspok
Hello,
I have a samba share on the freeipa 4.1 server that I want to
mount from another client that is part of the ipa domain
mount -t cifs //ipaserver.DOMAIN.LAN/share /mnt/point -o sec=krb5
Shouldn't I be able to do the mount this way?
-- john
You should be able to, what's the error ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
Loading...