samba - Nov 2015 - Pam_mount not working with "sec=krb5"

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