[Samba] Pam_mount not working with "sec=krb5"

[Ole Traupe]

Hi all, this is not really a Samba question, but related, and I hope
that some of you are using this and can tell me what I am doing wrong.

On a member server, I can mount my shares by hand specifying "-o
username=xxx,domain=yyy,password=zzz". But 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
to root:root instead of user:domain users. Nothing worked.

The krb5 key cache files are created in /tmp on user logon. Is this the
correct lookup directory, in the first place?

Kerberos as such is working correctly. Domain logons work, kinit as
well. This is on CentOS 6.7. Pam_mount was installed via the Nux Desktop
repo.

Best,
Ole



--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

[buhorojo]

On 02/11/15 12:54, Ole Traupe wrote:
> Hi all, this is not really a Samba question, but related, and I hope
> that some of you are using this and can tell me what I am doing wrong.
>
> On a member server, I can mount my shares by hand specifying "-o
> username=xxx,domain=yyy,password=zzz". But 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 to root:root instead of user:domain users. Nothing worked.
>
> The krb5 key cache files are created in /tmp on user logon. Is this
> the correct lookup directory, in the first place?
>
> Kerberos as such is working correctly. Domain logons work, kinit as
> well. This is on CentOS 6.7. Pam_mount was installed via the Nux
> Desktop repo.
>
> Best,
> Ole
>
>
>

Hi
You need multiuser.

Either use a key you already have:
mount -t cifs //yourserver/share /share -osec=krb5,
username=MACHINE$,multiuser

Or create an unprivileged domain user to mount the shares and add that
key to the keytab. Use the mutiuser switch to mount the share on behalf
of anyone who needs it:
mount -t cifs //yourserver/share /share -osec=krb5,
username=user4cifs,multiuser

We recommend the second method as the first way is easy to hack.
HTH

[Ole Traupe]

Thank you, I will try this! However, I am not sure I understand why it
is necessary and whether it works as intended. Why can't the user do it
with his own key file?

Also, if the user is not mounting his home share, but somebody else,
this _other_ user will be the owner of newly created files and folders,
right?

[buhorojo]

On 02/11/15 14:42, Ole Traupe wrote:
>
> Am 02.11.2015 um 13:12 schrieb buhorojo:
>> On 02/11/15 12:54, Ole Traupe wrote:

>> Why can't the user do it with his own key file?

Only root can perform mounts and anyway, cifs upcall looks for a key,
not a cache.

>
> Also, if the user is not mounting his home share, but somebody else,
> this _other_ user will be the owner of newly created files and
> folders, right

No. With multiuser, acl and permissions are respected. If the user would
normally be the owner of newly created files, then he will be also over
cifs.

One other thing, you need a recent version of cifs utils (we don't think
Centos has) and to make sure that you lose the -c at /etc/request-key.conf:
create cifs.spnego * * /usr/sbin/cifs.upcall -c %k

HTH

[Ole Traupe]

Am 02.11.2015 um 15:10 schrieb buhorojo:
> On 02/11/15 14:42, Ole Traupe wrote:
>>
>> Am 02.11.2015 um 13:12 schrieb buhorojo:
>>> On 02/11/15 12:54, Ole Traupe wrote:
>
>>> Why can't the user do it with his own key file?
> Only root can perform mounts and anyway,

Right, sorry.

> cifs upcall looks for a key, not a cache.

So you just _have_ to use the keytab. Has this changed? Here it seems
that cache was ok in the past (see the end of the longest cited log part
in the middle; but there was a different problem, obviously, with
ownership):
http://www.spinics.net/lists/linux-cifs/msg05290.html

>/Jan 25 17:55:12 goto cifs.upcall: find_krb5_cc: considering
/tmp/krb5cc_101125/
>/Jan 25 17:55:12 goto cifs.upcall: find_krb5_cc: /tmp/krb5cc_101125 is
owned by 101125, not 0/

I mean, putting the key in the keytab looks like a security risk to me.
Would be nice if you could use kerberos on the fly.

Unfortunately, I don't find such a detailed log in /var/log/messages.

>>
>> Also, if the user is not mounting his home share, but somebody else,
>> this _other_ user will be the owner of newly created files and
>> folders, right
> No. With multiuser, acl and permissions are respected. If the user
> would normally be the owner of newly created files, then he will be
> also over cifs.

Great, that sounds exactly as I would like it to be.

>
> One other thing, you need a recent version of cifs utils (we don't
> think Centos has)

Mine is cifs-utils.x86_64 4.8.1-20.el6

[Ole Traupe]

>>
>> One other thing, you need a recent version of cifs utils (we don't
>> think Centos has)
> Mine is cifs-utils.x86_64 4.8.1-20.el6
>

Ok, I at least need 5.3.

https://wiki.samba.org/index.php/LinuxCIFS_utils

[Ole Traupe]

Am 02.11.2015 um 15:10 schrieb buhorojo:

> On 02/11/15 14:42, Ole Traupe wrote:
>>
>> Am 02.11.2015 um 13:12 schrieb buhorojo:
>>> On 02/11/15 12:54, Ole Traupe wrote:
>
>>> Why can't the user do it with his own key file?
> Only root can perform mounts and anyway, cifs upcall looks for a key,
> not a cache.
>>
>> Also, if the user is not mounting his home share, but somebody else,
>> this _other_ user will be the owner of newly created files and
>> folders, right
> No. With multiuser, acl and permissions are respected. If the user
> would normally be the owner of newly created files, then he will be
> also over cifs.
>
> One other thing, you need a recent version of cifs utils (we don't
> think Centos has)

Can this be snatched from Fedora?

> and to make sure that you lose the -c at /etc/request-key.conf:
> create cifs.spnego * * /usr/sbin/cifs.upcall -c %k

Ok, I don't have this line at all. Will copy&paste it (without -c).

[Ole Traupe]

Am 02.11.2015 um 16:06 schrieb Ole Traupe:
>
>>>
>>> One other thing, you need a recent version of cifs utils (we don't
>>> think Centos has)
>> Mine is cifs-utils.x86_64 4.8.1-20.el6
>>
>
> Ok, I at least need 5.3.
>
> https://wiki.samba.org/index.php/LinuxCIFS_utils
>

I have found this src.rpm:
ftp://ftp.pbone.net/mirror/ftp5.gwdg.de/pub/opensuse/repositories/network%3A/samba%3A/TESTING/CentOS_6/src/cifs-utils-5.9-94.3.src.rpm

If it works, will it conflict with Samba 3.1 on CentOS 6?

I know that Samba 4 and cifs-utils 4.8 are incompatible:
https://bugzilla.redhat.com/show_bug.cgi?id=984727

But this is the other way around (cifs-utils 5.9).

[buhorojo]

On 02/11/15 15:51, Ole Traupe wrote:
>
>
> Am 02.11.2015 um 15:10 schrieb buhorojo:
>> On 02/11/15 14:42, Ole Traupe wrote:
>>>
>>> Am 02.11.2015 um 13:12 schrieb buhorojo:
>>>> On 02/11/15 12:54, Ole Traupe wrote:
>>
>>>> Why can't the user do it with his own key file?
>> Only root can perform mounts and anyway,
> Right, sorry.
>
>> cifs upcall looks for a key, not a cache.
> So you just _have_ to use the keytab. Has this changed? Here it seems
> that cache was ok in the past (see the end of the longest cited log
> part in the middle; but there was a different problem, obviously, with
> ownership):
> http://www.spinics.net/lists/linux-cifs/msg05290.html
>
>> /Jan 25 17:55:12 goto cifs.upcall: find_krb5_cc: considering
> /tmp/krb5cc_101125/
>> /Jan 25 17:55:12 goto cifs.upcall: find_krb5_cc: /tmp/krb5cc_101125 is
> owned by 101125, not 0/
>
> 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?

> Would be nice if you could use kerberos on the fly.

You _are_ using it on the fly.The tgt is obtained without any
interaction on the part of the user.

>
> Unfortunately, I don't find such a detailed log in /var/log/messages.
>
>>>
>>> Also, if the user is not mounting his home share, but somebody else,
>>> this _other_ user will be the owner of newly created files and
>>> folders, right
>> No. With multiuser, acl and permissions are respected. If the user
>> would normally be the owner of newly created files, then he will be
>> also over cifs.
> Great, that sounds exactly as I would like it to be.
>
>>
>> One other thing, you need a recent version of cifs utils (we don't
>> think Centos has)
> Mine is cifs-utils.x86_64 4.8.1-20.el6

We can confirm it works with 6.2.
HTH

[Ole Traupe]

>> 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 something: I thought the key would be
valid indefinitely, while the ticket expires. But then there is the
Ticket-Granting-Ticket (TGT). And if also the TGT expires after a few
hours, for how long will a share mounted with "sec=krb5,multiuser" be
accessible to the user?

I am sorry for all these dummy questions, but I really find this matter
hard to understand.

Thank you very much for your help!

>> Would be nice if you could use kerberos on the fly.
>
> You _are_ using it on the fly.The tgt is obtained without any
> interaction on the part of the user.
>>
>> Unfortunately, I don't find such a detailed log in /var/log/messages.
>>
>>>>
>>>> Also, if the user is not mounting his home share, but somebody
>>>> else, this _other_ user will be the owner of newly created files
>>>> and folders, right
>>> No. With multiuser, acl and permissions are respected. If the user
>>> would normally be the owner of newly created files, then he will be
>>> also over cifs.
>> Great, that sounds exactly as I would like it to be.
>>
>>>
>>> One other thing, you need a recent version of cifs utils (we don't
>>> think Centos has)
>> Mine is cifs-utils.x86_64 4.8.1-20.el6
> We can confirm it works with 6.2.
> HTH

Thanks. So migrating the server to CentOS 7 would be advised here if one
is afraid of bad interactions of Samba 3.1 with later (and potentially
buggy) experimental cifs-utils versions for CentOS 6.

[buhorojo]

On 03/11/15 10:56, Ole Traupe wrote:
>
>>> 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 something: I thought the key would be
> valid indefinitely, while the ticket expires. But then there is the
> Ticket-Granting-Ticket (TGT). And if also the TGT expires after a few
> hours, for how long will a share mounted with "sec=krb5,multiuser" be
> accessible to the user?

Hi
The upcall will maintain the validity of the mount for as long as it is
accessed, so maybe a better question would be how long a ticket does
your kdc issue for a user. The latter will be the determining factor,
not the upcall.

>
> I am sorry for all these dummy questions, but I really find this
> matter hard to understand.
>
> Thank you very much for your help!
>
>
>>> Would be nice if you could use kerberos on the fly.
>>
>> You _are_ using it on the fly.The tgt is obtained without any
>> interaction on the part of the user.
>>>
>>> Unfortunately, I don't find such a detailed log in /var/log/messages.
>>>
>>>>>
>>>>> Also, if the user is not mounting his home share, but somebody
>>>>> else, this _other_ user will be the owner of newly created files
>>>>> and folders, right
>>>> No. With multiuser, acl and permissions are respected. If the user
>>>> would normally be the owner of newly created files, then he will be
>>>> also over cifs.
>>> Great, that sounds exactly as I would like it to be.
>>>
>>>>
>>>> One other thing, you need a recent version of cifs utils (we don't
>>>> think Centos has)
>>> Mine is cifs-utils.x86_64 4.8.1-20.el6
>> We can confirm it works with 6.2.
>> HTH
>
> Thanks. So migrating the server to CentOS 7 would be advised here if
> one is afraid of bad interactions of Samba 3.1 with later (and
> potentially buggy) experimental cifs-utils versions for CentOS 6.

We think that the only way with cifs on Centos is to get the source and
build it. If the rest of it is working but the upcalls are not then keep
with what you have, uninstall the cifs utils making sure the binaries
have been removed and are not at a non-standard location, then make install.

Good luck and HTH

[Ole Traupe]

Am 03.11.2015 um 16:44 schrieb buhorojo:
> On 03/11/15 10:56, Ole Traupe wrote:
>>
>>>> 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 something: I thought the key would be
>> valid indefinitely, while the ticket expires. But then there is the
>> Ticket-Granting-Ticket (TGT). And if also the TGT expires after a few
>> hours, for how long will a share mounted with "sec=krb5,multiuser" be
>> accessible to the user?
> Hi
> The upcall will maintain the validity of the mount for as long as it
> is accessed, so maybe a better question would be how long a ticket
> does your kdc issue for a user. The latter will be the determining
> factor, not the upcall.

Up to 7 days if renewed within 24h, if I understand correctly
(ticket_lifetime = 24h, renew_lifetime = 7d).

Thanks for the clarification!

So there will be no conflict with other samba components such as in
samba-common?

And sorry for the typo, it is Samba 3.6.


>
> Good luck and HTH

Again, thank you very much!

[buhorojo]

On 03/11/15 17:18, Ole Traupe wrote:
>
>
> Am 03.11.2015 um 16:44 schrieb buhorojo:
>> On 03/11/15 10:56, Ole Traupe wrote:
>>>
>>>>> 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 something: I thought the key would be
>>> valid indefinitely, while the ticket expires. But then there is the
>>> Ticket-Granting-Ticket (TGT). And if also the TGT expires after a
>>> few hours, for how long will a share mounted with
>>> "sec=krb5,multiuser" be accessible to the user?
>> Hi
>> The upcall will maintain the validity of the mount for as long as it
>> is accessed, so maybe a better question would be how long a ticket
>> does your kdc issue for a user. The latter will be the determining
>> factor, not the upcall.
>
> Up to 7 days if renewed within 24h, if I understand correctly
> (ticket_lifetime = 24h, renew_lifetime = 7d).
>
> Thanks for the clarification!

Sorry, we don't know what the renew_lifetime means. Ours last 8 hours,
after which the mount is inaccessible.

Hi
No problem. Thank _you_ for the thread. We've an ongoing coursework on
exactly this, except we have to automount it so most of the stuff we can
test hands on. A lot of it we covered last year and we'd forgotten.
Unfortunately although we have Fedora, opensuse and Ubuntu lab rigs, we
don't do Centos.

[mathias dufresne]

2015-11-03 10:56 GMT+01:00 Ole Traupe <ole.t...@tu-berlin.de>:

>
> 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 something: I thought the key would be valid
> indefinitely, while the ticket expires.

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.

[Ole Traupe]

As far as I understood what I have read: the ticket can be refreshed
within 24h, up to a max lifetime of 7d (with these settings).

[Ole Traupe]

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

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

[Ole Traupe]

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.

[buhorojo]

On 04/11/15 13:36, mathias dufresne wrote:
> 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.

+1. Hence our advice to create a minimalist user solely for mounting the
share. Although he must have a uidNumber, make sure that user cannot
login. A good way to do that is to add
loginShell: /bin/false
to his Distinguished Name in AD.
HTH

[mathias dufresne]

2015-11-04 13:58 GMT+01:00 Ole Traupe <ole.t...@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

[Ole Traupe]

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)

[Davor Vusir]

Very interesting thread! Thank you all for sharing your thoughts and knowledge.

Regards
Davor

-- Skickat från mobilusken! --


----- Ursprungligt meddelande -----
Från: "Ole Traupe" <ole.t...@tu-berlin.de>
Skickat: ‎2015-‎11-‎04 15:29
Till: "sa...@lists.samba.org" <sa...@lists.samba.org>
Ämne: Re: [Samba] Pam_mount not working with "sec=krb5"

[L.P.H. van Belle]

> 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-...@lists.samba.org] Namens Ole Traupe
> Verzonden: woensdag 4 november 2015 15:22
> Aan: sa...@lists.samba.org
> Onderwerp: Re: [Samba] Pam_mount not working with "sec=krb5"

[buhorojo]

On 04/11/15 16:50, L.P.H. van Belle wrote:
>> 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?

Only users in the realm or with trust will be able:
1. authenticate
2. use the resultant ticket to request access to the file server
Also remember that root is not in the realm;)

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

Are you sure you are accessing the nfs mounted share on the server and
not the share itself? If you are setting the acl from windows on the
parent directory, it will not translate correctly across nfs4 unless you
have set the acl yourself using the (highly intuitive) nfs4_setfacl. At
least several hours of trying later and failing before we went cifs
where the acls just work.
HTH

[L.P.H. van Belle]

Im 1000% sure.. :-)

The server names are ready different.
Like print1 and member1
I login with putty and test from my pc in my own home drive.
It is ready as the below getfacl shows.


> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-...@lists.samba.org] Namens buhorojo
> Verzonden: woensdag 4 november 2015 17:34

> Aan: sa...@lists.samba.org
> Onderwerp: Re: [Samba] Pam_mount not working with "sec=krb5"
>

[Ole Traupe]

Am 04.11.2015 um 17:33 schrieb buhorojo:
> On 04/11/15 16:50, L.P.H. van Belle wrote:
>>> 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?
> Only users in the realm or with trust will be able:
> 1. authenticate
> 2. use the resultant ticket to request access to the file server
> Also remember that root is not in the realm;)
>>
>>> 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 )
> Are you sure you are accessing the nfs mounted share on the server and
> not the share itself?

Yes.

> If you are setting the acl from windows on the parent directory, it
> will not translate correctly across nfs4 unless you have set the acl
> yourself using the (highly intuitive) nfs4_setfacl.

I will not start and try out the third permission system after Windows
ACLs and Unix permissions. Unless there would be a way to automate this.
But nevermind, I got my Samba pam_mount working. Will report in the next
mail.

> At least several hours of trying later and failing before we went cifs
> where the acls just work.
> HTH
>

Thanks for your effort. Yes, cifs works.

[Ole Traupe]

Oops, that one was clearly not directed to me. ;)

[Ole Traupe]

So finally here is the solution that works for me. If you have any
questions, just 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 //server/home/userxyz /home/userxyz -o

sec=krb5,cruid=uid_of_userxyz,uid=uid_of_userxyz,gid=someGroupID

In another attempt, I could also hard code the "cruid=12345" for
pam_mount, and then log into the same machine twice. The second time the
home share was mounted correctly

So I figured, that PAM should do kerberos first. Therefore, I swapped
these two lines in the "/etc/pam.d/password-auth" (this is the result):
session optional pam_krb5.so
session required pam_mount.so

Pam_mount can do password authentication, as well, but I don't need it.
So I commented this line out:
# auth required pam_mount.so

Now I was able to use this volume definition for pam_mount (but not the
one at the top):
<volume fstype="cifs" server="server" path="home/%(USER)"
mountpoint="/home/%(USER)" sgrp="domain users"
options="sec=krb5,cruid=12345,uid=%(USERUID),gid=someLiteralGroupID,nosuid,nodev"
/>

Interestingly, the %(USERUID) worked for the "uid=..." option, but not
for "cruid=...". I tested this many times. So I figured that somehow the
"cruid=..." use by pam_mount happens too early at a stage where this
request returns empty (or something else). To test this, I put the same
volume description _TWICE_ into the "/etc/security/pam_mount.conf.xml".
And voilà: pam_mount works!

So as a temporary solution I have a dummy mount in the
pam_mount.conf.xml to make sure that the %(USERUID) variable is set
correctly when it is needed:

<volume fstype="cifs" server="server" path="home/dummy"
mountpoint="/home/%(USER)" sgrp="domain users"
options="sec=krb5,cruid=%(USERUID),uid=%(USERUID),gid=someLiteralGroupID,nosuid,nodev"
/>
<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"
/>

It's not beautiful, but it seems to work fine.

Ole

[buhorojo]

On 04/11/15 17:55, L.P.H. van Belle wrote:
> Im 1000% sure.. :-)
>
> The server names are ready different.
> Like print1 and member1
> I login with putty and test from my pc in my own home drive.
> It is ready as the below getfacl shows.

Yes. Thanks. We tried all methods with nfs4 and could never get the acls
to map setting from windows. nfs3 was fine. cifs just works.

[buhorojo]

Hi
Hey, well done and thanks for posting.
Now, if you want real elegance and linux workstations that really
impress, add the autofs schema to AD and automount the folders on
demand. Then cluster it. Then document it. The decide that with cloud
redundancy now a reality, is this all worth it?
Thanks again. We have learned a great deal:)

[Ole Traupe]

Hey buhorojo,
thanks for keeping this knowledge back all the time and instead
belitteling me on this list.
Good Job.
Ole