Question on current state of sec=krb5* integration in cifs.ko

[Holger Rauch-3]

Hi to everybody,

I came accross this link

http://fixunix.com/samba/140566-samba-mount-cifs-sec-krb5.html

while trying to use sec=krb5 or sec=krb5i in conjunction with
mount.cifs. On a Debian Lenny system (includes version 1.53 of
cifs.ko), this doesn't seem to work. This thread is quite old
(10/2007) and I'm wondering whether what's been said in there is still
valid.

"smbclient -L ... -k" or "smbclient ... -k" calls work without any
problems (provided that I run "kinit" in advance). In the interactive
smb shell, I can use e.g. mkdir and rmdir without any problem. So, my
Kerberos setup is working.

Installed kernel image on Debian Lenny is ("uname -r" output):

2.6.26-2-686-bigmem

What's the current status regarding sec=krb5 and sec=krb5i mount
options?

Thanks in advance for any info!

Kind regards,

     Holger
--
=========================================
Holger Rauch
Entwicklung Anwendungs-Software
Systemadministration UNIX

Tel.: +49 / 9131 / 877 - 141
Fax: +49 / 9131 / 877 - 266
Email: Holger.Rauch@...
=========================================


_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Q (Igor Mammedov)]

It works  on recent kernels and you will need a recent samba as well.
Search this list for words kerberos and cifs.upcall for details.

On Wed, Oct 21, 2009 at 11:00 PM, Holger Rauch <holger.rauch@...> wrote:

> Hi to everybody,
>
> I came accross this link
>
> http://fixunix.com/samba/140566-samba-mount-cifs-sec-krb5.html
>
> while trying to use sec=krb5 or sec=krb5i in conjunction with
> mount.cifs. On a Debian Lenny system (includes version 1.53 of
> cifs.ko), this doesn't seem to work. This thread is quite old
> (10/2007) and I'm wondering whether what's been said in there is still
> valid.
>
> "smbclient -L ... -k" or "smbclient ... -k" calls work without any
> problems (provided that I run "kinit" in advance). In the interactive
> smb shell, I can use e.g. mkdir and rmdir without any problem. So, my
> Kerberos setup is working.
>
> Installed kernel image on Debian Lenny is ("uname -r" output):
>
> 2.6.26-2-686-bigmem
>
> What's the current status regarding sec=krb5 and sec=krb5i mount
> options?
>
> Thanks in advance for any info!
>
> Kind regards,
>
>     Holger
> --
> =========================================
> Holger Rauch
> Entwicklung Anwendungs-Software
> Systemadministration UNIX
>
> Tel.: +49 / 9131 / 877 - 141
> Fax: +49 / 9131 / 877 - 266
> Email: Holger.Rauch@...
> =========================================
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkrfWkwACgkQbiVtWpZdKQLWuACfVGSnVVTDupx5PE8Fx5ov4MOm
> AKcAnjo4I2VhoXgcfBs7GLftXomCHMYd
> =JCCh
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> linux-cifs-client mailing list
> linux-cifs-client@...
> https://lists.samba.org/mailman/listinfo/linux-cifs-client
>
>

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Robert Euhus]

Hi,

Holger Rauch wrote:

> Hi to everybody,
>
> I came accross this link
>
> http://fixunix.com/samba/140566-samba-mount-cifs-sec-krb5.html
>
> while trying to use sec=krb5 or sec=krb5i in conjunction with
> mount.cifs. On a Debian Lenny system (includes version 1.53 of
> cifs.ko), this doesn't seem to work. This thread is quite old
> (10/2007) and I'm wondering whether what's been said in there is still
> valid.
>
> "smbclient -L ... -k" or "smbclient ... -k" calls work without any
> problems (provided that I run "kinit" in advance). In the interactive
> smb shell, I can use e.g. mkdir and rmdir without any problem. So, my
> Kerberos setup is working.
>
> Installed kernel image on Debian Lenny is ("uname -r" output):
>
> 2.6.26-2-686-bigmem
>
> What's the current status regarding sec=krb5 and sec=krb5i mount
> options?
>

It works here on Lenny, although you might have to install the keyutils
Package and add the following lines to /etc/request-key.conf :

create cifs.spnego * * /usr/sbin/cifs.upcall %k %d
create dns_resolver * * /usr/sbin/cifs.upcall %k

You might also want to have a look at a small (and not quite finished
yet) German HOWTO I wrote:

http://www.rrzn.uni-hannover.de/anl-linclient-ads.html

> Thanks in advance for any info!
>
> Kind regards,
>
>      Holger
> --
> =========================================
> Holger Rauch
> Entwicklung Anwendungs-Software
> Systemadministration UNIX
>
> Tel.: +49 / 9131 / 877 - 141
> Fax: +49 / 9131 / 877 - 266
> Email: Holger.Rauch@...
> =========================================
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> linux-cifs-client mailing list
> linux-cifs-client@...
> https://lists.samba.org/mailman/listinfo/linux-cifs-client

Yours,
Robert
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Holger Rauch-3]

Hi Robert,

Robert Euhus schrieb am Friday, den 23. October 2009:

> [...]
> It works here on Lenny, although you might have to install the keyutils
> Package and add the following lines to /etc/request-key.conf :
>
> create cifs.spnego * * /usr/sbin/cifs.upcall %k %d
> create dns_resolver * * /usr/sbin/cifs.upcall %k

I just tried that. Mount options in /etc/fstab are

noauto,sec=krb5i,iocharset=iso8859-15

When I issue the mount cmd, it asks me for a password. Is there any
way to get more debugging info from the mount.cifs cmd and the CIFS
VFS kernel module? (I was checking /var/log/syslog, /var/log/messages,
/var/log/daemon.log, but found nothing that could be helpful).

Like I mentioned, kerberized smbclient sessions work as expected (i.e.
I'm *not* asked for a password; just as it's supposed to be). I do get
a valid Kerberos ticket for cifs, as shown in this output from "klist
-5f":

==========

Ticket cache: FILE:/tmp/krb5cc_0
Default principal: user@MYREALM

Valid starting     Expires            Service principal
10/23/09 12:31:13  10/24/09 04:31:13  krbtgt/MYREALM@MYREALM
         renew until 10/24/09 12:30:51, Flags: FRIAT
         10/23/09 12:40:42  10/24/09 04:31:13
cifs/sambaserver.mydomain@MYREALM
                                         renew until 10/24/09
12:30:51, Flags: FRAT

==========

I should perhaps also mention that my LDAP accounts were created using
Debian Lenny's ldapscripts package before I installed Samba and used
ldapsam:editposix. Samba's LDAP stuff was initialized using "net sam
provision"; as described in

http://wiki.samba.org/index.php/Ldapsam_Editposix

So, the Kerberos user named "user" doesn't have the
samba* attributes set in the LDAP database yet. But since that didn't
seem to matter for smbclient sessions, it also shouldn't matter for
mount.cifs, should it?

In addition, my Kerberos database is stored in the
same OpenLDAP database as the user accounts are, just below a
different ou. (But that shouldn't matter since smbclient works, so the
LDAP lookup itself shouldn't be the problem).

> You might also want to have a look at a small (and not quite finished
> yet) German HOWTO I wrote:
>
> http://www.rrzn.uni-hannover.de/anl-linclient-ads.html

Thanks for mentioning this, but I have MIT Kerberos installed on a
Debian Lenny machine acting as KDC. Nevertheless, still helpful for AD
integration.

The main difference compared to your setup is that my server is
actually a Samba server running on a Debian Lenny system and I'm
trying to mount a cifs fs on a Linux client (i.e. a Linux machine
pretending to be a Windows client). Do I need the winbindd also on the
client machine in such a scenario (your HOWTO suggests running in on the
client, but you are authenticating against a "real" AD on a Windows
server; I'm authenticating against OpenLDAP+MIT Kerberos+Samba on a Debian
Lenny system)?

(In case you need more info, I will of course try provide it).

Thanks in advance for any hints & kind regards,

       Holger
     

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Jeff Layton-3]

On Fri, 23 Oct 2009 13:12:14 +0200
Holger Rauch <holger.rauch@...> wrote:

> Hi Robert,
>
> Robert Euhus schrieb am Friday, den 23. October 2009:
>
> > [...]
> > It works here on Lenny, although you might have to install the keyutils
> > Package and add the following lines to /etc/request-key.conf :
> >
> > create cifs.spnego * * /usr/sbin/cifs.upcall %k %d
> > create dns_resolver * * /usr/sbin/cifs.upcall %k
>
> I just tried that. Mount options in /etc/fstab are
>
> noauto,sec=krb5i,iocharset=iso8859-15
>
> When I issue the mount cmd, it asks me for a password.

That probably means that you have a fairly old mount.cifs program. The
more recent ones don't prompt for a password when sec=krb5* is
specified. Try adding the "guest" option which will disable password
prompting.

> Is there any
> way to get more debugging info from the mount.cifs cmd and the CIFS
> VFS kernel module? (I was checking /var/log/syslog, /var/log/messages,
> /var/log/daemon.log, but found nothing that could be helpful).
>

Yes, see:

http://wiki.samba.org/index.php/LinuxCIFS_troubleshooting

> Like I mentioned, kerberized smbclient sessions work as expected (i.e.
> I'm *not* asked for a password; just as it's supposed to be). I do get
> a valid Kerberos ticket for cifs, as shown in this output from "klist
> -5f":
>
> ==========
>
> Ticket cache: FILE:/tmp/krb5cc_0
> Default principal: user@MYREALM
>
> Valid starting     Expires            Service principal
> 10/23/09 12:31:13  10/24/09 04:31:13  krbtgt/MYREALM@MYREALM
> renew until 10/24/09 12:30:51, Flags: FRIAT
> 10/23/09 12:40:42  10/24/09 04:31:13
> cifs/sambaserver.mydomain@MYREALM
> renew until 10/24/09
> 12:30:51, Flags: FRAT
>
> ==========
>
> I should perhaps also mention that my LDAP accounts were created using
> Debian Lenny's ldapscripts package before I installed Samba and used
> ldapsam:editposix. Samba's LDAP stuff was initialized using "net sam
> provision"; as described in
>
> http://wiki.samba.org/index.php/Ldapsam_Editposix
>
> So, the Kerberos user named "user" doesn't have the
> samba* attributes set in the LDAP database yet. But since that didn't
> seem to matter for smbclient sessions, it also shouldn't matter for
> mount.cifs, should it?
>
> In addition, my Kerberos database is stored in the
> same OpenLDAP database as the user accounts are, just below a
> different ou. (But that shouldn't matter since smbclient works, so the
> LDAP lookup itself shouldn't be the problem).
>
> > You might also want to have a look at a small (and not quite finished
> > yet) German HOWTO I wrote:
> >
> > http://www.rrzn.uni-hannover.de/anl-linclient-ads.html
>
> Thanks for mentioning this, but I have MIT Kerberos installed on a
> Debian Lenny machine acting as KDC. Nevertheless, still helpful for AD
> integration.
>
> The main difference compared to your setup is that my server is
> actually a Samba server running on a Debian Lenny system and I'm
> trying to mount a cifs fs on a Linux client (i.e. a Linux machine
> pretending to be a Windows client). Do I need the winbindd also on the
> client machine in such a scenario (your HOWTO suggests running in on the
> client, but you are authenticating against a "real" AD on a Windows
> server; I'm authenticating against OpenLDAP+MIT Kerberos+Samba on a Debian
> Lenny system)?
>
> (In case you need more info, I will of course try provide it).
>
> Thanks in advance for any hints & kind regards,
>
>        Holger
>      

--
Jeff Layton <jlayton@...>


_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Holger Rauch-3]

Hi Jeff,

first of all, thanks for your quick reply.

On Fri, 23 Oct 2009, Jeff Layton wrote:

> On Fri, 23 Oct 2009 13:12:14 +0200
> Holger Rauch <holger.rauch@...> wrote:
> > [...]
> > I just tried that. Mount options in /etc/fstab are
> >
> > noauto,sec=krb5i,iocharset=iso8859-15
> >
> > When I issue the mount cmd, it asks me for a password.
>
> That probably means that you have a fairly old mount.cifs program. The
> more recent ones don't prompt for a password when sec=krb5* is
> specified. Try adding the "guest" option which will disable password
> prompting.

Ok, I tried that (debugging output included as well; interestingly
enough, "mount.cifs -V" only outputs the help message, even if
mount.cifs is called with an absolute path). This happenend on a
Debian Lenny system having the shipped kernel version (uname -r):

2.6.26-2-686-bigmem

Since "mount.cifs -V" didn't come up with version info, I used
"apt-cache show smbfs" ("smbfs" is the Debian package mount.cifs is
contained in). It has the same version as the other Samba packages
shipped with Debian: 3.2.5

==============

pia:~# mount -t cifs //server/myuser
/cifs/user --verbose -o
sec=krb5i,user=myuser,guest,iocharset=iso8859-15
parsing options: rw,sec=krb5i,user=myuser,guest,iocharset=iso8859-15

mount.cifs kernel mount options
unc=//server\myuser,ip=ww.xx.yy.zz,ver=1,rw,sec=krb5i,user=myuser,guest,iocharset=iso8859-15

mount error 95 = Operation not supported
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)
pia:~# dmesg
[8046556.840192]  fs/cifs/cifsfs.c: Devname:
//prag-old.er.heitec.net/hrauch flags: 64
[8046556.847954]  fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid:
15 with uid: 0
[8046556.895920]  fs/cifs/connect.c: iocharset set to iso8859-15
[8046556.903932]  fs/cifs/connect.c: Username: myuser
[8046556.911928]  fs/cifs/connect.c: UNC:
\\server\myuser ip: ww.xx.yy.zz
[8046556.916743]  fs/cifs/connect.c: Socket created
[8046556.924050]  fs/cifs/connect.c: sndbuf 16384 rcvbuf 87380
rcvtimeo 0x7fffffff
[8046556.935312]  fs/cifs/connect.c: Existing smb sess not found
[8046556.935312]  fs/cifs/connect.c: Demultiplex PID: 6171
[8046556.946262]  fs/cifs/cifssmb.c: secFlags 0x1009
[8046556.950328]  fs/cifs/cifssmb.c: Kerberos only mechanism, enable
extended security
[8046556.957962]  fs/cifs/transport.c: For smb_command 114
[8046556.962692]  fs/cifs/transport.c: Sending smb of length 78
[8046556.968883]  fs/cifs/connect.c: rfc1002 length 0xbe
[8046556.974665]  fs/cifs/cifssmb.c: Dialect: 2
[8046556.978940]  fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348
0x1bb92
[8046556.989230]  fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0xbb92
[8046556.991772]  fs/cifs/asn1.c: OID len = 10 oid = 0x1 0x3 0x6 0x1
[8046556.998296]  fs/cifs/asn1.c: Need to call asn1_octets_decode()
function for cifs/server@MYREALM
[8046557.008389]  fs/cifs/cifssmb.c: Must sign - secFlags 0x1009
[8046557.015170]  CIFS VFS: signing required but server lacks support
[8046557.022305]  fs/cifs/cifssmb.c: negprot rc -95
[8046557.136096]  fs/cifs/connect.c: No session or bad tcon
[8046557.213439]  fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid
= 15) rc = -95
[8046557.221012]  CIFS VFS: cifs_mount failed w/return code = -95

==============

Do I need a more recent kernel? If so, which one would you recommend?

Thanks in advance for any hints & kind regards,

       Holger
       

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Jeff Layton-2]

On Fri, 23 Oct 2009 15:54:29 +0200
Holger Rauch <holger.rauch@...> wrote:

> Hi Jeff,
>
> first of all, thanks for your quick reply.
>
> On Fri, 23 Oct 2009, Jeff Layton wrote:
>
> > On Fri, 23 Oct 2009 13:12:14 +0200
> > Holger Rauch <holger.rauch@...> wrote:
> > > [...]
> > > I just tried that. Mount options in /etc/fstab are
> > >
> > > noauto,sec=krb5i,iocharset=iso8859-15
> > >
> > > When I issue the mount cmd, it asks me for a password.
> >
> > That probably means that you have a fairly old mount.cifs program. The
> > more recent ones don't prompt for a password when sec=krb5* is
> > specified. Try adding the "guest" option which will disable password
> > prompting.
>
> Ok, I tried that (debugging output included as well; interestingly
> enough, "mount.cifs -V" only outputs the help message, even if
> mount.cifs is called with an absolute path). This happenend on a
> Debian Lenny system having the shipped kernel version (uname -r):
>
> 2.6.26-2-686-bigmem
>
> Since "mount.cifs -V" didn't come up with version info, I used
> "apt-cache show smbfs" ("smbfs" is the Debian package mount.cifs is
> contained in). It has the same version as the other Samba packages
> shipped with Debian: 3.2.5
>
> ==============
>
> pia:~# mount -t cifs //server/myuser
> /cifs/user --verbose -o
> sec=krb5i,user=myuser,guest,iocharset=iso8859-15
> parsing options: rw,sec=krb5i,user=myuser,guest,iocharset=iso8859-15
>
> mount.cifs kernel mount options
> unc=//server\myuser,ip=ww.xx.yy.zz,ver=1,rw,sec=krb5i,user=myuser,guest,iocharset=iso8859-15
>
> mount error 95 = Operation not supported
> Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)
> pia:~# dmesg
> [8046556.840192]  fs/cifs/cifsfs.c: Devname:
> //prag-old.er.heitec.net/hrauch flags: 64
> [8046556.847954]  fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid:
> 15 with uid: 0
> [8046556.895920]  fs/cifs/connect.c: iocharset set to iso8859-15
> [8046556.903932]  fs/cifs/connect.c: Username: myuser
> [8046556.911928]  fs/cifs/connect.c: UNC:
> \\server\myuser ip: ww.xx.yy.zz
> [8046556.916743]  fs/cifs/connect.c: Socket created
> [8046556.924050]  fs/cifs/connect.c: sndbuf 16384 rcvbuf 87380
> rcvtimeo 0x7fffffff
> [8046556.935312]  fs/cifs/connect.c: Existing smb sess not found
> [8046556.935312]  fs/cifs/connect.c: Demultiplex PID: 6171
> [8046556.946262]  fs/cifs/cifssmb.c: secFlags 0x1009
> [8046556.950328]  fs/cifs/cifssmb.c: Kerberos only mechanism, enable
> extended security
> [8046556.957962]  fs/cifs/transport.c: For smb_command 114
> [8046556.962692]  fs/cifs/transport.c: Sending smb of length 78
> [8046556.968883]  fs/cifs/connect.c: rfc1002 length 0xbe
> [8046556.974665]  fs/cifs/cifssmb.c: Dialect: 2
> [8046556.978940]  fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348
> 0x1bb92
> [8046556.989230]  fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0xbb92
> [8046556.991772]  fs/cifs/asn1.c: OID len = 10 oid = 0x1 0x3 0x6 0x1
> [8046556.998296]  fs/cifs/asn1.c: Need to call asn1_octets_decode()
> function for cifs/server@MYREALM
> [8046557.008389]  fs/cifs/cifssmb.c: Must sign - secFlags 0x1009
> [8046557.015170]  CIFS VFS: signing required but server lacks support

I think this message explains the problem ^^^^

You've request krb5i, but your server doesn't support signing. You
might want to try sec=krb5 and see if that works.

> [8046557.022305]  fs/cifs/cifssmb.c: negprot rc -95
> [8046557.136096]  fs/cifs/connect.c: No session or bad tcon
> [8046557.213439]  fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid
> = 15) rc = -95
> [8046557.221012]  CIFS VFS: cifs_mount failed w/return code = -95
>
> ==============
>
> Do I need a more recent kernel? If so, which one would you recommend?
>
> Thanks in advance for any hints & kind regards,
>
>        Holger
>        

--
Jeff Layton <jlayton@...>
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Holger Rauch-3]

Hi Jeff,

thanks again for replying that quickly. I tried sec=krb5 and it indeed
worked (even in conjunction with autofs5). Strangely enough, it even
continued to work when the credentials cache was empty (having run
"kdestroy" deliberately in order to test Kerberos security).

I could add files even though there were no tickets left in the cache.
This shouldn't be the case, I think (at least that's how it works on
NFSv4; i.e. on NFSv4 I would get "permission denied" when tickets are
either expired or not present). Is CIFS different in this regard?

On Fri, 23 Oct 2009, Jeff Layton wrote:

> [...]
> > [8046557.008389]  fs/cifs/cifssmb.c: Must sign - secFlags 0x1009
> > [8046557.015170]  CIFS VFS: signing required but server lacks support
>
>
> I think this message explains the problem ^^^^
>
> You've request krb5i, but your server doesn't support signing. You
> might want to try sec=krb5 and see if that works.

What exactly is meant by "server" (Samba software, MIT Kerberos
software, etc.)? Do I need a more recent Samba, MIT Kerberos, anything
else?

Thanks again & kind regards,

       Holger


_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Jeff Layton-2]

On Fri, 23 Oct 2009 17:46:02 +0200
Holger Rauch <holger.rauch@...> wrote:

> Hi Jeff,
>
> thanks again for replying that quickly. I tried sec=krb5 and it indeed
> worked (even in conjunction with autofs5). Strangely enough, it even
> continued to work when the credentials cache was empty (having run
> "kdestroy" deliberately in order to test Kerberos security).
>
> I could add files even though there were no tickets left in the cache.
> This shouldn't be the case, I think (at least that's how it works on
> NFSv4; i.e. on NFSv4 I would get "permission denied" when tickets are
> either expired or not present). Is CIFS different in this regard?
>

Yes, much...

NFS (well, RPC actually) sends credentials with every call, so if you
destroy the creds, then the client and server will tend to pick up on
that fact rather quickly. With CIFS the credentials are just used to
establish a "session". After that, krb5 doesn't really come into play
very much (at least until you have to reconnect).

--
Jeff Layton <jlayton@...>


_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Volker Lendecke]

On Fri, Oct 23, 2009 at 11:55:12AM -0400, Jeff Layton wrote:
> Yes, much...
>
> NFS (well, RPC actually) sends credentials with every call, so if you
> destroy the creds, then the client and server will tend to pick up on
> that fact rather quickly. With CIFS the credentials are just used to
> establish a "session". After that, krb5 doesn't really come into play
> very much (at least until you have to reconnect).

It's not *as* bad as it sounds security-wise, SMB signing
attempts to provide integrity, and the Samba extensions for
SMB encryption (Jeff: Hint...! :-)) would provide
confidentiality.

Volker


_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Q (Igor Mammedov)]

On Fri, Oct 23, 2009 at 6:19 PM, Jeff Layton <jlayton@...> wrote:

> On Fri, 23 Oct 2009 15:54:29 +0200
> Holger Rauch <holger.rauch@...> wrote:
>
>> Hi Jeff,
>>
>> first of all, thanks for your quick reply.
>>
>> On Fri, 23 Oct 2009, Jeff Layton wrote:
>>
>> > On Fri, 23 Oct 2009 13:12:14 +0200
>> > Holger Rauch <holger.rauch@...> wrote:
>> > > [...]
>> > > I just tried that. Mount options in /etc/fstab are
>> > >
>> > > noauto,sec=krb5i,iocharset=iso8859-15
>> > >
>> > > When I issue the mount cmd, it asks me for a password.
>> >
>> > That probably means that you have a fairly old mount.cifs program. The
>> > more recent ones don't prompt for a password when sec=krb5* is
>> > specified. Try adding the "guest" option which will disable password
>> > prompting.
>>
>> Ok, I tried that (debugging output included as well; interestingly
>> enough, "mount.cifs -V" only outputs the help message, even if
>> mount.cifs is called with an absolute path). This happenend on a
>> Debian Lenny system having the shipped kernel version (uname -r):
>>
>> 2.6.26-2-686-bigmem
>>
>> Since "mount.cifs -V" didn't come up with version info, I used
>> "apt-cache show smbfs" ("smbfs" is the Debian package mount.cifs is
>> contained in). It has the same version as the other Samba packages
>> shipped with Debian: 3.2.5
>>
>> ==============
>>
>> pia:~# mount -t cifs //server/myuser
>> /cifs/user --verbose -o
>> sec=krb5i,user=myuser,guest,iocharset=iso8859-15
>> parsing options: rw,sec=krb5i,user=myuser,guest,iocharset=iso8859-15
>>
>> mount.cifs kernel mount options
>> unc=//server\myuser,ip=ww.xx.yy.zz,ver=1,rw,sec=krb5i,user=myuser,guest,iocharset=iso8859-15
>>
>> mount error 95 = Operation not supported
>> Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)
>> pia:~# dmesg
>> [8046556.840192]  fs/cifs/cifsfs.c: Devname:
>> //prag-old.er.heitec.net/hrauch flags: 64
>> [8046556.847954]  fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid:
>> 15 with uid: 0
>> [8046556.895920]  fs/cifs/connect.c: iocharset set to iso8859-15
>> [8046556.903932]  fs/cifs/connect.c: Username: myuser
>> [8046556.911928]  fs/cifs/connect.c: UNC:
>> \\server\myuser ip: ww.xx.yy.zz
>> [8046556.916743]  fs/cifs/connect.c: Socket created
>> [8046556.924050]  fs/cifs/connect.c: sndbuf 16384 rcvbuf 87380
>> rcvtimeo 0x7fffffff
>> [8046556.935312]  fs/cifs/connect.c: Existing smb sess not found
>> [8046556.935312]  fs/cifs/connect.c: Demultiplex PID: 6171
>> [8046556.946262]  fs/cifs/cifssmb.c: secFlags 0x1009
>> [8046556.950328]  fs/cifs/cifssmb.c: Kerberos only mechanism, enable
>> extended security
>> [8046556.957962]  fs/cifs/transport.c: For smb_command 114
>> [8046556.962692]  fs/cifs/transport.c: Sending smb of length 78
>> [8046556.968883]  fs/cifs/connect.c: rfc1002 length 0xbe
>> [8046556.974665]  fs/cifs/cifssmb.c: Dialect: 2
>> [8046556.978940]  fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348
>> 0x1bb92
>> [8046556.989230]  fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0xbb92
>> [8046556.991772]  fs/cifs/asn1.c: OID len = 10 oid = 0x1 0x3 0x6 0x1
>> [8046556.998296]  fs/cifs/asn1.c: Need to call asn1_octets_decode()
>> function for cifs/server@MYREALM
>> [8046557.008389]  fs/cifs/cifssmb.c: Must sign - secFlags 0x1009
>> [8046557.015170]  CIFS VFS: signing required but server lacks support
>
>
> I think this message explains the problem ^^^^
>
> You've request krb5i, but your server doesn't support signing. You
> might want to try sec=krb5 and see if that works.

That there won't be much security left with sec=krb, because of
it would lack even signed cisf packets. And as far as I remember,
the client doesn't do mutual authentication of the server, so
the server may be faked by any machine registered in the ADS
domain.
Any ways, we can use current cifs only to authenticate client
on the server only, but there won't be much security in the sense
of transmitted data or checking if we speak with real server.

>> [8046557.022305]  fs/cifs/cifssmb.c: negprot rc -95
>> [8046557.136096]  fs/cifs/connect.c: No session or bad tcon
>> [8046557.213439]  fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid
>> = 15) rc = -95
>> [8046557.221012]  CIFS VFS: cifs_mount failed w/return code = -95
>>
>> ==============
>>
>> Do I need a more recent kernel? If so, which one would you recommend?
>>
>> Thanks in advance for any hints & kind regards,
>>
>>        Holger
>>
>
>
> --
> Jeff Layton <jlayton@...>
> _______________________________________________
> linux-cifs-client mailing list
> linux-cifs-client@...
> https://lists.samba.org/mailman/listinfo/linux-cifs-client
>

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Holger Rauch-3]

Hi Volker,

I looked at

http://wiki.samba.org/index.php/UNIX_Extensions

but I couldn't find anything about SMB encryption. Do you have any
good links concerning both SMB signing and encryption (configuring it,
smb.conf options, etc.)?

Are they both part of Samba 3.2.5 (shipped with Debian Lenny) or would
I need a more recent version of Samba?

Volker Lendecke schrieb am Friday, den 23. October 2009:

> [...]
> It's not *as* bad as it sounds security-wise, SMB signing
> attempts to provide integrity, and the Samba extensions for
> SMB encryption (Jeff: Hint...! :-)) would provide
> confidentiality.
>
> Volker

Thanks for enlightening me & kind regards,

       Holger


_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Jeff Layton-2]

On Fri, 23 Oct 2009 20:00:59 +0400
"Q (Igor Mammedov)" <qwerty0987654321@...> wrote:

> On Fri, Oct 23, 2009 at 6:19 PM, Jeff Layton <jlayton@...> wrote:
> > On Fri, 23 Oct 2009 15:54:29 +0200
> > Holger Rauch <holger.rauch@...> wrote:
> >
> >> Hi Jeff,
> >>
> >> first of all, thanks for your quick reply.
> >>
> >> On Fri, 23 Oct 2009, Jeff Layton wrote:
> >>
> >> > On Fri, 23 Oct 2009 13:12:14 +0200
> >> > Holger Rauch <holger.rauch@...> wrote:
> >> > > [...]
> >> > > I just tried that. Mount options in /etc/fstab are
> >> > >
> >> > > noauto,sec=krb5i,iocharset=iso8859-15
> >> > >
> >> > > When I issue the mount cmd, it asks me for a password.
> >> >
> >> > That probably means that you have a fairly old mount.cifs program. The
> >> > more recent ones don't prompt for a password when sec=krb5* is
> >> > specified. Try adding the "guest" option which will disable password
> >> > prompting.
> >>
> >> Ok, I tried that (debugging output included as well; interestingly
> >> enough, "mount.cifs -V" only outputs the help message, even if
> >> mount.cifs is called with an absolute path). This happenend on a
> >> Debian Lenny system having the shipped kernel version (uname -r):
> >>
> >> 2.6.26-2-686-bigmem
> >>
> >> Since "mount.cifs -V" didn't come up with version info, I used
> >> "apt-cache show smbfs" ("smbfs" is the Debian package mount.cifs is
> >> contained in). It has the same version as the other Samba packages
> >> shipped with Debian: 3.2.5
> >>
> >> ==============
> >>
> >> pia:~# mount -t cifs //server/myuser
> >> /cifs/user --verbose -o
> >> sec=krb5i,user=myuser,guest,iocharset=iso8859-15
> >> parsing options: rw,sec=krb5i,user=myuser,guest,iocharset=iso8859-15
> >>
> >> mount.cifs kernel mount options
> >> unc=//server\myuser,ip=ww.xx.yy.zz,ver=1,rw,sec=krb5i,user=myuser,guest,iocharset=iso8859-15
> >>
> >> mount error 95 = Operation not supported
> >> Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)
> >> pia:~# dmesg
> >> [8046556.840192]  fs/cifs/cifsfs.c: Devname:
> >> //prag-old.er.heitec.net/hrauch flags: 64
> >> [8046556.847954]  fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid:
> >> 15 with uid: 0
> >> [8046556.895920]  fs/cifs/connect.c: iocharset set to iso8859-15
> >> [8046556.903932]  fs/cifs/connect.c: Username: myuser
> >> [8046556.911928]  fs/cifs/connect.c: UNC:
> >> \\server\myuser ip: ww.xx.yy.zz
> >> [8046556.916743]  fs/cifs/connect.c: Socket created
> >> [8046556.924050]  fs/cifs/connect.c: sndbuf 16384 rcvbuf 87380
> >> rcvtimeo 0x7fffffff
> >> [8046556.935312]  fs/cifs/connect.c: Existing smb sess not found
> >> [8046556.935312]  fs/cifs/connect.c: Demultiplex PID: 6171
> >> [8046556.946262]  fs/cifs/cifssmb.c: secFlags 0x1009
> >> [8046556.950328]  fs/cifs/cifssmb.c: Kerberos only mechanism, enable
> >> extended security
> >> [8046556.957962]  fs/cifs/transport.c: For smb_command 114
> >> [8046556.962692]  fs/cifs/transport.c: Sending smb of length 78
> >> [8046556.968883]  fs/cifs/connect.c: rfc1002 length 0xbe
> >> [8046556.974665]  fs/cifs/cifssmb.c: Dialect: 2
> >> [8046556.978940]  fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348
> >> 0x1bb92
> >> [8046556.989230]  fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0xbb92
> >> [8046556.991772]  fs/cifs/asn1.c: OID len = 10 oid = 0x1 0x3 0x6 0x1
> >> [8046556.998296]  fs/cifs/asn1.c: Need to call asn1_octets_decode()
> >> function for cifs/server@MYREALM
> >> [8046557.008389]  fs/cifs/cifssmb.c: Must sign - secFlags 0x1009
> >> [8046557.015170]  CIFS VFS: signing required but server lacks support
> >
> >
> > I think this message explains the problem ^^^^
> >
> > You've request krb5i, but your server doesn't support signing. You
> > might want to try sec=krb5 and see if that works.
>
> That there won't be much security left with sec=krb, because of
> it would lack even signed cisf packets. And as far as I remember,
> the client doesn't do mutual authentication of the server, so
> the server may be faked by any machine registered in the ADS
> domain.
> Any ways, we can use current cifs only to authenticate client
> on the server only, but there won't be much security in the sense
> of transmitted data or checking if we speak with real server.
>

My intention was not to claim that using krb5 instead of krb5i was a
good idea...simply that he might want to try it to make sure that was
the only problem.

Obviously, fixing the server to support signing would be a better
long term solution.

--
Jeff Layton <jlayton@...>
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Holger Rauch-3]

Hi Jeff,


On Fri, 23 Oct 2009, Jeff Layton wrote:

> [...]
> Yes, much...
>
> NFS (well, RPC actually) sends credentials with every call, so if you
> destroy the creds, then the client and server will tend to pick up on
> that fact rather quickly. With CIFS the credentials are just used to
> establish a "session". After that, krb5 doesn't really come into play
> very much (at least until you have to reconnect).

Well, that surely explains the "kdestroy" thing, but the other
interesting question is what software is actually meant by "server"
in case the log message reads similar to "server doesn't support signing"?

Any details for me on this one?

Thanks & kind regards,

       Holger
       

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Q (Igor Mammedov)]

On Fri, Oct 23, 2009 at 8:24 PM, Jeff Layton <jlayton@...> wrote:

> On Fri, 23 Oct 2009 20:00:59 +0400
> "Q (Igor Mammedov)" <qwerty0987654321@...> wrote:
>
>> On Fri, Oct 23, 2009 at 6:19 PM, Jeff Layton <jlayton@...> wrote:
>> > On Fri, 23 Oct 2009 15:54:29 +0200
>> > Holger Rauch <holger.rauch@...> wrote:
>> >
>> >> Hi Jeff,
>> >>
>> >> first of all, thanks for your quick reply.
>> >>
>> >> On Fri, 23 Oct 2009, Jeff Layton wrote:
>> >>
>> >> > On Fri, 23 Oct 2009 13:12:14 +0200
>> >> > Holger Rauch <holger.rauch@...> wrote:
>> >> > > [...]
>> >> > > I just tried that. Mount options in /etc/fstab are
>> >> > >
>> >> > > noauto,sec=krb5i,iocharset=iso8859-15
>> >> > >
>> >> > > When I issue the mount cmd, it asks me for a password.
>> >> >
>> >> > That probably means that you have a fairly old mount.cifs program. The
>> >> > more recent ones don't prompt for a password when sec=krb5* is
>> >> > specified. Try adding the "guest" option which will disable password
>> >> > prompting.
>> >>
>> >> Ok, I tried that (debugging output included as well; interestingly
>> >> enough, "mount.cifs -V" only outputs the help message, even if
>> >> mount.cifs is called with an absolute path). This happenend on a
>> >> Debian Lenny system having the shipped kernel version (uname -r):
>> >>
>> >> 2.6.26-2-686-bigmem
>> >>
>> >> Since "mount.cifs -V" didn't come up with version info, I used
>> >> "apt-cache show smbfs" ("smbfs" is the Debian package mount.cifs is
>> >> contained in). It has the same version as the other Samba packages
>> >> shipped with Debian: 3.2.5
>> >>
>> >> ==============
>> >>
>> >> pia:~# mount -t cifs //server/myuser
>> >> /cifs/user --verbose -o
>> >> sec=krb5i,user=myuser,guest,iocharset=iso8859-15
>> >> parsing options: rw,sec=krb5i,user=myuser,guest,iocharset=iso8859-15
>> >>
>> >> mount.cifs kernel mount options
>> >> unc=//server\myuser,ip=ww.xx.yy.zz,ver=1,rw,sec=krb5i,user=myuser,guest,iocharset=iso8859-15
>> >>
>> >> mount error 95 = Operation not supported
>> >> Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)
>> >> pia:~# dmesg
>> >> [8046556.840192]  fs/cifs/cifsfs.c: Devname:
>> >> //prag-old.er.heitec.net/hrauch flags: 64
>> >> [8046556.847954]  fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid:
>> >> 15 with uid: 0
>> >> [8046556.895920]  fs/cifs/connect.c: iocharset set to iso8859-15
>> >> [8046556.903932]  fs/cifs/connect.c: Username: myuser
>> >> [8046556.911928]  fs/cifs/connect.c: UNC:
>> >> \\server\myuser ip: ww.xx.yy.zz
>> >> [8046556.916743]  fs/cifs/connect.c: Socket created
>> >> [8046556.924050]  fs/cifs/connect.c: sndbuf 16384 rcvbuf 87380
>> >> rcvtimeo 0x7fffffff
>> >> [8046556.935312]  fs/cifs/connect.c: Existing smb sess not found
>> >> [8046556.935312]  fs/cifs/connect.c: Demultiplex PID: 6171
>> >> [8046556.946262]  fs/cifs/cifssmb.c: secFlags 0x1009
>> >> [8046556.950328]  fs/cifs/cifssmb.c: Kerberos only mechanism, enable
>> >> extended security
>> >> [8046556.957962]  fs/cifs/transport.c: For smb_command 114
>> >> [8046556.962692]  fs/cifs/transport.c: Sending smb of length 78
>> >> [8046556.968883]  fs/cifs/connect.c: rfc1002 length 0xbe
>> >> [8046556.974665]  fs/cifs/cifssmb.c: Dialect: 2
>> >> [8046556.978940]  fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348
>> >> 0x1bb92
>> >> [8046556.989230]  fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0xbb92
>> >> [8046556.991772]  fs/cifs/asn1.c: OID len = 10 oid = 0x1 0x3 0x6 0x1
>> >> [8046556.998296]  fs/cifs/asn1.c: Need to call asn1_octets_decode()
>> >> function for cifs/server@MYREALM
>> >> [8046557.008389]  fs/cifs/cifssmb.c: Must sign - secFlags 0x1009
>> >> [8046557.015170]  CIFS VFS: signing required but server lacks support
>> >
>> >
>> > I think this message explains the problem ^^^^
>> >
>> > You've request krb5i, but your server doesn't support signing. You
>> > might want to try sec=krb5 and see if that works.
>>
>> That there won't be much security left with sec=krb, because of
>> it would lack even signed cisf packets. And as far as I remember,
>> the client doesn't do mutual authentication of the server, so
>> the server may be faked by any machine registered in the ADS
>> domain.
>> Any ways, we can use current cifs only to authenticate client
>> on the server only, but there won't be much security in the sense
>> of transmitted data or checking if we speak with real server.
>>
>
> My intention was not to claim that using krb5 instead of krb5i was a
> good idea...simply that he might want to try it to make sure that was
> the only problem.
>
> Obviously, fixing the server to support signing would be a better
> long term solution.

I'm Sorry if I was rude. Your solution to the problem is perfectly Ok.
I just complemented your answer with what security risks there are.

And implementing mutual authentication wasn't a simple thing when
I've looked at it. It will require to expand upcall protocol to do several
round-trips of SecurityBlob between KDC and cifs server.

>
> --
> Jeff Layton <jlayton@...>
>
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Jeff Layton-2]

On Fri, 23 Oct 2009 18:30:25 +0200
Holger Rauch <holger.rauch@...> wrote:

> Hi Jeff,
>
>
> On Fri, 23 Oct 2009, Jeff Layton wrote:
>
> > [...]
> > Yes, much...
> >
> > NFS (well, RPC actually) sends credentials with every call, so if you
> > destroy the creds, then the client and server will tend to pick up on
> > that fact rather quickly. With CIFS the credentials are just used to
> > establish a "session". After that, krb5 doesn't really come into play
> > very much (at least until you have to reconnect).
>
> Well, that surely explains the "kdestroy" thing, but the other
> interesting question is what software is actually meant by "server"
> in case the log message reads similar to "server doesn't support signing"?
>
> Any details for me on this one?
>

Sorry, it's a little difficult to be more specific...

It depends on what you're kind of server you're mounting here. If it's
windows, then you'll probably need to play with its settings. If you're
mounting samba, you probably need to set samba options to enable
signing. If something else...who knows?

--
Jeff Layton <jlayton@...>


_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Volker Lendecke]

On Fri, Oct 23, 2009 at 06:20:40PM +0200, Holger Rauch wrote:
> Hi Volker,
>
> I looked at
>
> http://wiki.samba.org/index.php/UNIX_Extensions
>
> but I couldn't find anything about SMB encryption. Do you have any
> good links concerning both SMB signing and encryption (configuring it,
> smb.conf options, etc.)?

For the server you would say "server signing = mandatory",
no idea about mount.cifs.

> Are they both part of Samba 3.2.5 (shipped with Debian Lenny) or would
> I need a more recent version of Samba?

Samba 3.2.5 server-side does both signing and encryption.
cifs.ko afaik only does signing, no encryption yet (this was
the "Hint" part of my last mail :-))

Volker


_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Holger Rauch-3]

Hi Volker,

Volker Lendecke schrieb am Friday, den 23. October 2009:

> [...]
> For the server you would say "server signing = mandatory",
> no idea about mount.cifs.

For mount.cifs, specifying sec=krb5i instead of sec=krb5 in my
automount map obviously worked. The file system was automounted as
expected.

Does "server signing = mandatory" also include encryption? I did a
"testparm - v | grep server" and additional option containing
"encryption" was shown, so I guess "server signing" includes both
signing *and* encryption, right?

Thanks for clarifying this & kind regards,

       Holger


_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Volker Lendecke]

On Mon, Oct 26, 2009 at 10:56:42AM +0100, Holger Rauch wrote:

> Hi Volker,
>
> Volker Lendecke schrieb am Friday, den 23. October 2009:
>
> > [...]
> > For the server you would say "server signing = mandatory",
> > no idea about mount.cifs.
>
> For mount.cifs, specifying sec=krb5i instead of sec=krb5 in my
> automount map obviously worked. The file system was automounted as
> expected.
>
> Does "server signing = mandatory" also include encryption? I did a
> "testparm - v | grep server" and additional option containing
> "encryption" was shown, so I guess "server signing" includes both
> signing *and* encryption, right?

No.

Volker
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Holger Rauch-3]

Hi Volker,

ok, did the same grep as below, but this time for "crypt". I now came
accross a parameter named

smb encrypt

Is that the right one (from the smb.conf man page it seems to be)?
Furthermore, "smb encrypt" seems to include *both* signing and
encryption, so one "smb encrypt" is set to mandatory, "server signing
= mandatory" should no longer be required, right?

Besides, why not rename "server signing" to "smb signing" for
consistency (would also make it easier to grep for it)?

Greetings,

          Holger

Volker Lendecke schrieb am Monday, den 26. October 2009:

> On Mon, Oct 26, 2009 at 10:56:42AM +0100, Holger Rauch wrote:
> > [...]
> > Does "server signing = mandatory" also include encryption? I did a
> > "testparm - v | grep server" and additional option containing
> > "encryption" was shown, so I guess "server signing" includes both
> > signing *and* encryption, right?
>
> No.
>
> Volker

--

=========================================
Holger Rauch
Entwicklung Anwendungs-Software
Systemadministration UNIX

Tel.: +49 / 9131 / 877 - 141
Fax: +49 / 9131 / 877 - 266
Email: Holger.Rauch@...
=========================================


_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client