specifying password when using krb5

specifying password when using krb5

[Frank Loeffler]

[-- Attachment #1: Type: text/plain, Size: 4425 bytes --]

Hi,

after hours of debugging, I finally write to this list to see if I 
understood things. Let me first explain what I tried to do and I'll post 
my question towards the end.


What I want to do is mount a Windows-share via 'mount.cifs'. I can see 
stuff on that directory using smbclient, so login credentials ect. are 
ok:

# smbclient -A /etc/my-credentials -L \\\\share.name.org

        Sharename       Type      Comment
        ---------       ----      -------
   ... some content ...

# smbclient -A /etc/my-credentials //share.name.org/home
Try "help" to get a list of possible commands.
smb: \> ls
  .                                   D        0  Fri Jan 31 12:36:03 2014
  ..                                  D        0  Fri Jan 29 07:38:10 
2021
...
smb: \>

So far, so good. Now I want to mount:

# mount -t cifs '\\share.name.org\home' -o credentials=/etc/my-credentials /mnt/win
domain=MYDOMAIN
mount.cifs kernel mount options: 
ip=10.10.10.10,unc=\\share.name.org\home,user=me@myorg.org,domain=MYDOMAIN,pass=********
mount error(13): Permission denied

Looking at wireshark-captures of the smbclient-connect I see it using 
krb5, so let's do that too with cifs:

# mount -t cifs '\\share.name.org\home' -o credentials=/etc/my-credentials,sec=krb5 /mnt/win
domain=MYDOMAIN
mount.cifs kernel mount options: 
ip=10.10.10.10,unc=\\share.name.org\home,sec=krb5,user=me@myorg.org,domain=MYDOMAIN,pass=********
mount error(2): No such file or directory

Note, I do not have active krb5-tickets on this machine, I do not even have kinit installed.

Even more strange, trying without actually specifying a password:

# mount -v -t cifs '\\share.name.org\home' -o username=me@myorg.org,domain=MYDOMAIN,sec=krb5 /mnt/win
mount.cifs kernel mount options: ip=10.10.10.10,unc=\\share.name.org\home,sec=krb5,user=me@myorg.org,domain=MYDOMAIN,pass=********
mount error(2): No such file or directory

Shows the same: it does not even ask me for the password (but still 
shows 'pass=********' in the kernel mount options). This is strange, 
because the docs say:

       password=arg|pass=arg
              specifies the CIFS password. If this option is not given 
then the environment variable PASSWD is used. If the password is not 
specified  directly  or  indirectly via an argument to mount, mount.cifs 
will prompt for a password, unless the guest option is specified.

Trying without password and without sec=krb5 does indeed give me the 
expected prompt.

Digging deeper, into the source of mount.cifs, I find 
(cifs.upcall.c:582)

/*
 * Prepares AP-REQ data for mechToken and gets session key
 * Uses credentials from cache. It will not ask for password
 * you should receive credentials for yuor name manually using
 * kinit or whatever you wish.
*/

According to that source-code comment, sec=krb5 will ignore any password 
setting - it will not even ask for one. mount.cifs.c:918 shows similar 
intentions:

        if (!strncmp(value, "krb5", 4)) {
          parsed_info->is_krb5 = 1;
          parsed_info->got_password = 1;
        }

So, now my questions:

1. Is it intended that mount.cifs will not ask for a password when using 
sec=krb5 and will ignore any set password?
2. I don't want to setup krb5-tokens for users. All I want is 
authenticate using krb5 to get the smb-session and then forget about 
krb5. smbclient seems to be able to do this. I don't know how they do 
it, I suspect they create a temporary token, open the session, and then 
drop it again. Whatever smbclient does: couldn't mount.cifs do the same 
or something similar? This would make the 'password' setting meaningful 
for sec=krb5. This does not mean that existing tokens couldn't and 
shouldn't be used. It would just mean that users would not *have* to use 
an external mechanism for this.
3. For the moment (and only if my observations are correct): could the 
documentation be updated to reflect that "password" is ignored for 
"sec=krb5"? Users shouldn't need to dig inside the source code to find 
out things like that.
4. Currently, trying sec=krb5 without token cache files results in the 
rather obscure error "mount error(2): No such file or directory". Could 
this me changed into something that points users to the actual cause of 
the error?
5. Am I even remotely correct with any of this? :)

thanks, Frank


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: specifying password when using krb5

[Shyam Prasad N]

Hi Frank,

When sec=krb5 is used, the Linux cifs client ignores the password
supplied. You're right. This needs to be documented.
It relies on external utilities (like samba-winbind, sssd or manual
setup of krb5 client) to fetch the krb5 TGT needed for sec=krb5.
I don't know how smbclient does this. Might be worth checking.

If you're connecting to something like a Windows AD, you can setup
winbind to fetch the krb5 TGTs for the AD users.
Once configured, winbind will fetch the kerberos credentials on behalf
of the user during login.
Alternatively, you can setup a kerberos keytab file or credential
cache file yourself manually using kinit.

Regards,
Shyam

On Sat, Mar 27, 2021 at 5:09 PM Frank Loeffler
<frank.loeffler@uni-jena.de> wrote:
>
> Hi,
>
> after hours of debugging, I finally write to this list to see if I
> understood things. Let me first explain what I tried to do and I'll post
> my question towards the end.
>
>
> What I want to do is mount a Windows-share via 'mount.cifs'. I can see
> stuff on that directory using smbclient, so login credentials ect. are
> ok:
>
> # smbclient -A /etc/my-credentials -L \\\\share.name.org
>
>         Sharename       Type      Comment
>         ---------       ----      -------
>    ... some content ...
>
> # smbclient -A /etc/my-credentials //share.name.org/home
> Try "help" to get a list of possible commands.
> smb: \> ls
>   .                                   D        0  Fri Jan 31 12:36:03 2014
>   ..                                  D        0  Fri Jan 29 07:38:10
> 2021
> ...
> smb: \>
>
> So far, so good. Now I want to mount:
>
> # mount -t cifs '\\share.name.org\home' -o credentials=/etc/my-credentials /mnt/win
> domain=MYDOMAIN
> mount.cifs kernel mount options:
> ip=10.10.10.10,unc=\\share.name.org\home,user=me@myorg.org,domain=MYDOMAIN,pass=********
> mount error(13): Permission denied
>
> Looking at wireshark-captures of the smbclient-connect I see it using
> krb5, so let's do that too with cifs:
>
> # mount -t cifs '\\share.name.org\home' -o credentials=/etc/my-credentials,sec=krb5 /mnt/win
> domain=MYDOMAIN
> mount.cifs kernel mount options:
> ip=10.10.10.10,unc=\\share.name.org\home,sec=krb5,user=me@myorg.org,domain=MYDOMAIN,pass=********
> mount error(2): No such file or directory
>
> Note, I do not have active krb5-tickets on this machine, I do not even have kinit installed.
>
> Even more strange, trying without actually specifying a password:
>
> # mount -v -t cifs '\\share.name.org\home' -o username=me@myorg.org,domain=MYDOMAIN,sec=krb5 /mnt/win
> mount.cifs kernel mount options: ip=10.10.10.10,unc=\\share.name.org\home,sec=krb5,user=me@myorg.org,domain=MYDOMAIN,pass=********
> mount error(2): No such file or directory
>
> Shows the same: it does not even ask me for the password (but still
> shows 'pass=********' in the kernel mount options). This is strange,
> because the docs say:
>
>        password=arg|pass=arg
>               specifies the CIFS password. If this option is not given
> then the environment variable PASSWD is used. If the password is not
> specified  directly  or  indirectly via an argument to mount, mount.cifs
> will prompt for a password, unless the guest option is specified.
>
> Trying without password and without sec=krb5 does indeed give me the
> expected prompt.
>
> Digging deeper, into the source of mount.cifs, I find
> (cifs.upcall.c:582)
>
> /*
>  * Prepares AP-REQ data for mechToken and gets session key
>  * Uses credentials from cache. It will not ask for password
>  * you should receive credentials for yuor name manually using
>  * kinit or whatever you wish.
> */
>
> According to that source-code comment, sec=krb5 will ignore any password
> setting - it will not even ask for one. mount.cifs.c:918 shows similar
> intentions:
>
>         if (!strncmp(value, "krb5", 4)) {
>           parsed_info->is_krb5 = 1;
>           parsed_info->got_password = 1;
>         }
>
> So, now my questions:
>
> 1. Is it intended that mount.cifs will not ask for a password when using
> sec=krb5 and will ignore any set password?
> 2. I don't want to setup krb5-tokens for users. All I want is
> authenticate using krb5 to get the smb-session and then forget about
> krb5. smbclient seems to be able to do this. I don't know how they do
> it, I suspect they create a temporary token, open the session, and then
> drop it again. Whatever smbclient does: couldn't mount.cifs do the same
> or something similar? This would make the 'password' setting meaningful
> for sec=krb5. This does not mean that existing tokens couldn't and
> shouldn't be used. It would just mean that users would not *have* to use
> an external mechanism for this.
> 3. For the moment (and only if my observations are correct): could the
> documentation be updated to reflect that "password" is ignored for
> "sec=krb5"? Users shouldn't need to dig inside the source code to find
> out things like that.
> 4. Currently, trying sec=krb5 without token cache files results in the
> rather obscure error "mount error(2): No such file or directory". Could
> this me changed into something that points users to the actual cause of
> the error?
> 5. Am I even remotely correct with any of this? :)
>
> thanks, Frank
>


-- 
Regards,
Shyam

Re: specifying password when using krb5

[Aurélien Aptel]

Frank Loeffler <frank.loeffler@uni-jena.de> writes:
> 1. Is it intended that mount.cifs will not ask for a password when using 
> sec=krb5 and will ignore any set password?

As Shyam said, this seems to be the case.

> 2. I don't want to setup krb5-tokens for users. All I want is 
> authenticate using krb5 to get the smb-session and then forget about 
> krb5. smbclient seems to be able to do this. I don't know how they do 
> it, I suspect they create a temporary token, open the session, and then 
> drop it again. Whatever smbclient does: couldn't mount.cifs do the same 
> or something similar? This would make the 'password' setting meaningful 
> for sec=krb5. This does not mean that existing tokens couldn't and 
> shouldn't be used. It would just mean that users would not *have* to use 
> an external mechanism for this.

When you use a password you're actually not using krb5 (even in
smbclient), you're using NTLMSSP authentication.

> 3. For the moment (and only if my observations are correct): could the 
> documentation be updated to reflect that "password" is ignored for 
> "sec=krb5"? Users shouldn't need to dig inside the source code to find 
> out things like that.

That's a good point, I'll try to update the cifs-utils man page.

> 4. Currently, trying sec=krb5 without token cache files results in the 
> rather obscure error "mount error(2): No such file or directory". Could 
> this me changed into something that points users to the actual cause of 
> the error?

Sadly we don't have much to work with. Mounting is done with a single
system call mount() which can only return 1 error code from the list of errno
codes https://man7.org/linux/man-pages/man3/errno.3.html

The error printed is the generic description of those code stored in
your libc.

There is a new mount syscall API that allows returning errors _strings_
to userspace. I've sent experimental patches to make use of it but I
haven't received any feedback on it. Your post is a great example of why
we should merge it.

> 5. Am I even remotely correct with any of this? :)

I think you are :) thanks for reporting.

Cheers,
-- 
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München)

Re: specifying password when using krb5

[Frank Loeffler]

[-- Attachment #1: Type: text/plain, Size: 1692 bytes --]

Hi,

On Mon, Mar 29, 2021 at 06:25:49PM +0200, Aurélien Aptel wrote:
>When you use a password you're actually not using krb5 (even in
>smbclient), you're using NTLMSSP authentication.

As far as I understand, you (can) use a password to obtain a krb5-token, 
which is then used for sec=krb5. From a users point of view, you enter 
username and password and get access. Whether this is using krb5 and a 
token or some other mechanism is usually something a user doesn't even 
want to know about. What they know is a username/password combination 
and a share name on some remote machine.
If the mechanism happens to be krb5 (isn't that even the default on 
Windows shares?), you might need a temporary token, but I wonder if  
that "technicality" couldn't be made transparent to the user by default. 
This would make mounting Windows shares a lot less 'messy' to users.

>> 4. Currently, trying sec=krb5 without token cache files results in 
>> the
>> rather obscure error "mount error(2): No such file or directory". Could
>> this me changed into something that points users to the actual cause of
>> the error?
>
>Sadly we don't have much to work with. Mounting is done with a single
>system call mount() which can only return 1 error code from the list of errno
>codes https://man7.org/linux/man-pages/man3/errno.3.html

That is unfortunate. However, not even verbose mounting gave me any 
indication of what it was that is actually failing. Maybe, before 
returning ENOENT, cifs you print something else, possibly at least with
high verbosity/debugging enabled.

>I think you are :) thanks for reporting.

Thanks for your time responding. :)

Frank


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: specifying password when using krb5

[Aurélien Aptel]

Frank Loeffler <frank.loeffler@uni-jena.de> writes:
> As far as I understand, you (can) use a password to obtain a krb5-token, 
> which is then used for sec=krb5. From a users point of view, you enter 
> username and password and get access. Whether this is using krb5 and a 
> token or some other mechanism is usually something a user doesn't even 
> want to know about. What they know is a username/password combination 
> and a share name on some remote machine.
> If the mechanism happens to be krb5 (isn't that even the default on 
> Windows shares?), you might need a temporary token, but I wonder if  
> that "technicality" couldn't be made transparent to the user by default. 
> This would make mounting Windows shares a lot less 'messy' to users.

Yes, from the user point of view, both NTLM and KRB use
username/password pair. But in Linux, KRB is a complex system-wide
service separate from the kernel, cifs-utils or samba. It is its own
project and it requires a /etc/krb5.conf file, proper DNS settings,
kinit/klist/... tools etc.

All we can do from cifs-utils is expect those to already be in
place. Configuring KRB on-the-fly is out of the scope of cifs-utils.

> That is unfortunate. However, not even verbose mounting gave me any 
> indication of what it was that is actually failing. Maybe, before 
> returning ENOENT, cifs you print something else, possibly at least with
> high verbosity/debugging enabled.

Do you mean verbose by mounting with -v? If yes, as I said when the
mount.cifs program calls the mount() syscall, the kernel can only return
a single generic integer code. The mount program cannot tell you much
because it doesn't know much. When it mounts with KRB, it just passes
sec=krb5 to the kernel. The kernel tries to connect and later on call
back userspace (yes, kernel calls userspace, its called "upcalling")
program cifs.upcall, which is responsible for finding the krb
tickets. That program cannot print to your console, all its logging goes
to the syslog. That's why you cannot see much from the mount program.

You can read cifs.upcall logs in your system logs, probably with the
journalctl command.

If you actually want verbosity _from the kernel_ you need to do those
steps:

https://wiki.samba.org/index.php/Bug_Reporting#cifs.ko

You will then find more information after calling mount by looking at
the kernel log via the dmesg command.

Cheers,
-- 
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München)