mount.cifs with sec=krb5 where kerberos principal is not the same as file server

[Andrew Baumann-2]

Hi all,

I'm trying to get mount.cifs to work with kerberos authentication (sec=krb5).
smbclient -k works, however mount.cifs reports:

$ /sbin/mount.cifs //fs.systems.inf.ethz.ch/sharename ./mnt -o sec=krb5
mount error(126): Required key not available
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)

The dmesg output is as follows:
[3460893.349868]  /build/buildd/linux-2.6.28/fs/cifs/cifsfs.c: Devname: //fs.systems.inf.ethz.ch/sharename flags: 64
[3460893.349874]  /build/buildd/linux-2.6.28/fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid: 147 with uid: 0
[3460893.349882]  /build/buildd/linux-2.6.28/fs/cifs/connect.c: Username: username
[3460893.349885]  /build/buildd/linux-2.6.28/fs/cifs/connect.c: UNC: \\fs.systems.inf.ethz.ch\sharename ip: 129.132.19.42
[3460893.349894]  /build/buildd/linux-2.6.28/fs/cifs/connect.c: Socket created
[3460893.350930]  /build/buildd/linux-2.6.28/fs/cifs/connect.c: sndbuf 16384 rcvbuf 87380 rcvtimeo 0x7fffffffffffffff
[3460893.350973]  /build/buildd/linux-2.6.28/fs/cifs/connect.c: Existing smb sess not found
[3460893.350979]  /build/buildd/linux-2.6.28/fs/cifs/cifssmb.c: secFlags 0x8
[3460893.350981]  /build/buildd/linux-2.6.28/fs/cifs/cifssmb.c: Kerberos only mechanism, enable extended security
[3460893.350985]  /build/buildd/linux-2.6.28/fs/cifs/transport.c: For smb_command 114
[3460893.350988]  /build/buildd/linux-2.6.28/fs/cifs/transport.c: Sending smb of length 78
[3460893.351004]  /build/buildd/linux-2.6.28/fs/cifs/connect.c: Demultiplex PID: 28499
[3460893.354098]  /build/buildd/linux-2.6.28/fs/cifs/connect.c: rfc1002 length 0xb7
[3460893.355167]  /build/buildd/linux-2.6.28/fs/cifs/cifssmb.c: Dialect: 2
[3460893.355173]  /build/buildd/linux-2.6.28/fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0x1bb92
[3460893.355176]  /build/buildd/linux-2.6.28/fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0xbb92
[3460893.355179]  /build/buildd/linux-2.6.28/fs/cifs/asn1.c: OID len = 10 oid = 0x1 0x3 0x6 0x1
[3460893.355182]  /build/buildd/linux-2.6.28/fs/cifs/asn1.c: Need to call asn1_octets_decode() function for cifs/fs-
srv1.inf.ethz.ch@...
[3460893.355185]  /build/buildd/linux-2.6.28/fs/cifs/cifssmb.c: Signing disabled
[3460893.355190]  /build/buildd/linux-2.6.28/fs/cifs/cifssmb.c: negprot rc 0
[3460893.355192]  /build/buildd/linux-2.6.28/fs/cifs/connect.c: Security Mode: 0x3 Capabilities: 0x8000f3fd TimeAdjust: -3600
[3460893.355196]  /build/buildd/linux-2.6.28/fs/cifs/sess.c: sess setup type 6
[3460893.355202]  /build/buildd/linux-2.6.28/fs/cifs/cifs_spnego.c: key description =
ver=0x2;host=fs.systems.inf.ethz.ch;ip4=129.132.19.42;sec=krb5;uid=0xc926;user=username
[3460893.410781]  /build/buildd/linux-2.6.28/fs/cifs/sess.c: ssetup freeing small buf ffff880114155dc0
[3460893.410786]  CIFS VFS: Send error in SessSetup = -126
[3460893.410796]  /build/buildd/linux-2.6.28/fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid = 147) rc = -126
[3460893.410799]  CIFS VFS: cifs_mount failed w/return code = -126

... from this, and looking at packet capture logs, it seems that the negotiate
response from the server specifies a principal of cifs/fs-srv1.inf.ethz.ch@...
however the cifs code persists in trying to get a kerberos ticket for the file
server host (fs.systems.inf.ethz.ch), which fails. smbclient gets this right and
presents the cached ticket for cifs/fs-srv1.inf.ethz.ch@....

Note that fs-srv1 is really a different host from the file server, so I cannot
work around this problem by simply mounting with a different host name.

Here is the full negotiate response from the server (and I can send other
packet logs if useful):

NetBIOS Session Service
    Message Type: Session message
    Length: 179
SMB (Server Message Block Protocol)
    SMB Header
        Server Component: SMB
        [Response to: 4]
        [Time from request: 0.001272000 seconds]
        SMB Command: Negotiate Protocol (0x72)
        NT Status: STATUS_SUCCESS (0x00000000)
        Flags: 0x88
            1... .... = Request/Response: Message is a response to the client/redirector
            .0.. .... = Notify: Notify client only on open
            ..0. .... = Oplocks: OpLock not requested/granted
            ...0 .... = Canonicalized Pathnames: Pathnames are not canonicalized
            .... 1... = Case Sensitivity: Path names are caseless
            .... ..0. = Receive Buffer Posted: Receive buffer has not been posted
            .... ...0 = Lock and Read: Lock&Read, Write&Unlock are not supported
        Flags2: 0xc801
            1... .... .... .... = Unicode Strings: Strings are Unicode
            .1.. .... .... .... = Error Code Type: Error codes are NT error codes
            ..0. .... .... .... = Execute-only Reads: Don't permit reads if execute-only
            ...0 .... .... .... = Dfs: Don't resolve pathnames with Dfs
            .... 1... .... .... = Extended Security Negotiation: Extended security negotiation is supported
            .... .... .0.. .... = Long Names Used: Path names in request are not long file names
            .... .... .... .0.. = Security Signatures: Security signatures are not supported
            .... .... .... ..0. = Extended Attributes: Extended attributes are not supported
            .... .... .... ...1 = Long Names Allowed: Long file names are allowed in the response
        Process ID High: 0
        Signature: 0000000000000000
        Reserved: 0000
        Tree ID: 0
        Process ID: 28048
        User ID: 0
        Multiplex ID: 1
    Negotiate Protocol Response (0x72)
        Word Count (WCT): 17
        Dialect Index: 8, greater than LANMAN2.1
        Security Mode: 0x03
            .... ...1 = Mode: USER security mode
            .... ..1. = Password: ENCRYPTED password. Use challenge/response
            .... .0.. = Signatures: Security signatures NOT enabled
            .... 0... = Sig Req: Security signatures NOT required
        Max Mpx Count: 50
        Max VCs: 1
        Max Buffer Size: 16644
        Max Raw Buffer: 65536
        Session Key: 0x00001ed9
        Capabilities: 0x8000f3fd
            .... .... .... .... .... .... .... ...1 = Raw Mode: Read Raw and Write Raw are supported
            .... .... .... .... .... .... .... ..0. = MPX Mode: Read Mpx and Write Mpx are not supported
            .... .... .... .... .... .... .... .1.. = Unicode: Unicode strings are supported
            .... .... .... .... .... .... .... 1... = Large Files: Large files are supported
            .... .... .... .... .... .... ...1 .... = NT SMBs: NT SMBs are supported
            .... .... .... .... .... .... ..1. .... = RPC Remote APIs: RPC remote APIs are supported
            .... .... .... .... .... .... .1.. .... = NT Status Codes: NT status codes are supported
            .... .... .... .... .... .... 1... .... = Level 2 Oplocks: Level 2 oplocks are supported
            .... .... .... .... .... ...1 .... .... = Lock and Read: Lock and Read is supported
            .... .... .... .... .... ..1. .... .... = NT Find: NT Find is supported
            .... .... .... .... ...1 .... .... .... = Dfs: Dfs is supported
            .... .... .... .... ..1. .... .... .... = Infolevel Passthru: NT information level request passthrough is supported
            .... .... .... .... .1.. .... .... .... = Large ReadX: Large Read andX is supported
            .... .... .... .... 1... .... .... .... = Large WriteX: Large Write andX is supported
            .... .... 0... .... .... .... .... .... = UNIX: UNIX extensions are not supported
            .... ..0. .... .... .... .... .... .... = Reserved: Reserved
            ..0. .... .... .... .... .... .... .... = Bulk Transfer: Bulk Read and Bulk Write are not supported
            .0.. .... .... .... .... .... .... .... = Compressed Data: Compressed data transfer is not supported
            1... .... .... .... .... .... .... .... = Extended Security: Extended security exchanges are supported
        System Time: Oct 28, 2009 09:42:32.000000000
        Server Time Zone: -60 min from UTC
        Key Length: 0
        Byte Count (BCC): 110
        Server GUID: 66732D73727631000000000000000000
        Security Blob: 605C06062B0601050502A0523050A024302206092A864886...
            GSS-API Generic Security Service Application Program Interface
                OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation)
                SPNEGO
                    negTokenInit
                        mechTypes: 3 items
                            Item: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
                            Item: 1.2.840.48018.1.2.2 (MS KRB5 - Microsoft Kerberos 5)
                            Item: 1.3.6.1.4.1.311.2.2.10 (NTLMSSP - Microsoft NTLM Security Support Provider)
                        mechListMIC: 3026A0241B22636966732F66732D737276312E696E662E65...
                            principal: cifs/fs-srv1.inf.ethz.ch@...


$ uname -a
Linux prak 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 19:25:34 UTC 2009 x86_64 GNU/Linux
$ /sbin/mount.cifs -V
mount.cifs version: 1.12-3.3.2
$ smbclient -V
Version 3.3.2
$ /usr/sbin/cifs.upcall -v
version: 1.2
$ grep cifs /etc/request-key.conf
create  cifs.spnego     *       *               /usr/sbin/cifs.upcall -c %k %d
create  dns_resolver    *       *               /usr/sbin/cifs.upcall -c %k

Cheers,
Andrew

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

[Jeff Layton-4]

On Wed, 28 Oct 2009 10:20:26 +0100
Andrew Baumann <andrewb@...> wrote:

> Hi all,
>
> I'm trying to get mount.cifs to work with kerberos authentication (sec=krb5).
> smbclient -k works, however mount.cifs reports:
>
> $ /sbin/mount.cifs //fs.systems.inf.ethz.ch/sharename ./mnt -o sec=krb5
> mount error(126): Required key not available
> Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)
>
> The dmesg output is as follows:
> [3460893.349868]  /build/buildd/linux-2.6.28/fs/cifs/cifsfs.c: Devname: //fs.systems.inf.ethz.ch/sharename flags: 64
> [3460893.349874]  /build/buildd/linux-2.6.28/fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid: 147 with uid: 0
> [3460893.349882]  /build/buildd/linux-2.6.28/fs/cifs/connect.c: Username: username
> [3460893.349885]  /build/buildd/linux-2.6.28/fs/cifs/connect.c: UNC: \\fs.systems.inf.ethz.ch\sharename ip: 129.132.19.42
> [3460893.349894]  /build/buildd/linux-2.6.28/fs/cifs/connect.c: Socket created
> [3460893.350930]  /build/buildd/linux-2.6.28/fs/cifs/connect.c: sndbuf 16384 rcvbuf 87380 rcvtimeo 0x7fffffffffffffff
> [3460893.350973]  /build/buildd/linux-2.6.28/fs/cifs/connect.c: Existing smb sess not found
> [3460893.350979]  /build/buildd/linux-2.6.28/fs/cifs/cifssmb.c: secFlags 0x8
> [3460893.350981]  /build/buildd/linux-2.6.28/fs/cifs/cifssmb.c: Kerberos only mechanism, enable extended security
> [3460893.350985]  /build/buildd/linux-2.6.28/fs/cifs/transport.c: For smb_command 114
> [3460893.350988]  /build/buildd/linux-2.6.28/fs/cifs/transport.c: Sending smb of length 78
> [3460893.351004]  /build/buildd/linux-2.6.28/fs/cifs/connect.c: Demultiplex PID: 28499
> [3460893.354098]  /build/buildd/linux-2.6.28/fs/cifs/connect.c: rfc1002 length 0xb7
> [3460893.355167]  /build/buildd/linux-2.6.28/fs/cifs/cifssmb.c: Dialect: 2
> [3460893.355173]  /build/buildd/linux-2.6.28/fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0x1bb92
> [3460893.355176]  /build/buildd/linux-2.6.28/fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0xbb92
> [3460893.355179]  /build/buildd/linux-2.6.28/fs/cifs/asn1.c: OID len = 10 oid = 0x1 0x3 0x6 0x1
> [3460893.355182]  /build/buildd/linux-2.6.28/fs/cifs/asn1.c: Need to call asn1_octets_decode() function for cifs/fs-
> srv1.inf.ethz.ch@...
> [3460893.355185]  /build/buildd/linux-2.6.28/fs/cifs/cifssmb.c: Signing disabled
> [3460893.355190]  /build/buildd/linux-2.6.28/fs/cifs/cifssmb.c: negprot rc 0
> [3460893.355192]  /build/buildd/linux-2.6.28/fs/cifs/connect.c: Security Mode: 0x3 Capabilities: 0x8000f3fd TimeAdjust: -3600
> [3460893.355196]  /build/buildd/linux-2.6.28/fs/cifs/sess.c: sess setup type 6
> [3460893.355202]  /build/buildd/linux-2.6.28/fs/cifs/cifs_spnego.c: key description =
> ver=0x2;host=fs.systems.inf.ethz.ch;ip4=129.132.19.42;sec=krb5;uid=0xc926;user=username
> [3460893.410781]  /build/buildd/linux-2.6.28/fs/cifs/sess.c: ssetup freeing small buf ffff880114155dc0
> [3460893.410786]  CIFS VFS: Send error in SessSetup = -126
> [3460893.410796]  /build/buildd/linux-2.6.28/fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid = 147) rc = -126
> [3460893.410799]  CIFS VFS: cifs_mount failed w/return code = -126
>
> ... from this, and looking at packet capture logs, it seems that the negotiate
> response from the server specifies a principal of cifs/fs-srv1.inf.ethz.ch@...
> however the cifs code persists in trying to get a kerberos ticket for the file
> server host (fs.systems.inf.ethz.ch), which fails. smbclient gets this right and
> presents the cached ticket for cifs/fs-srv1.inf.ethz.ch@....
>
> Note that  is really a different host from the file server, so I cannot
> work around this problem by simply mounting with a different host name.
>
> Here is the full negotiate response from the server (and I can send other
> packet logs if useful):
>
> NetBIOS Session Service
>     Message Type: Session message
>     Length: 179
> SMB (Server Message Block Protocol)
>     SMB Header
>         Server Component: SMB
>         [Response to: 4]
>         [Time from request: 0.001272000 seconds]
>         SMB Command: Negotiate Protocol (0x72)
>         NT Status: STATUS_SUCCESS (0x00000000)
>         Flags: 0x88
>             1... .... = Request/Response: Message is a response to the client/redirector
>             .0.. .... = Notify: Notify client only on open
>             ..0. .... = Oplocks: OpLock not requested/granted
>             ...0 .... = Canonicalized Pathnames: Pathnames are not canonicalized
>             .... 1... = Case Sensitivity: Path names are caseless
>             .... ..0. = Receive Buffer Posted: Receive buffer has not been posted
>             .... ...0 = Lock and Read: Lock&Read, Write&Unlock are not supported
>         Flags2: 0xc801
>             1... .... .... .... = Unicode Strings: Strings are Unicode
>             .1.. .... .... .... = Error Code Type: Error codes are NT error codes
>             ..0. .... .... .... = Execute-only Reads: Don't permit reads if execute-only
>             ...0 .... .... .... = Dfs: Don't resolve pathnames with Dfs
>             .... 1... .... .... = Extended Security Negotiation: Extended security negotiation is supported
>             .... .... .0.. .... = Long Names Used: Path names in request are not long file names
>             .... .... .... .0.. = Security Signatures: Security signatures are not supported
>             .... .... .... ..0. = Extended Attributes: Extended attributes are not supported
>             .... .... .... ...1 = Long Names Allowed: Long file names are allowed in the response
>         Process ID High: 0
>         Signature: 0000000000000000
>         Reserved: 0000
>         Tree ID: 0
>         Process ID: 28048
>         User ID: 0
>         Multiplex ID: 1
>     Negotiate Protocol Response (0x72)
>         Word Count (WCT): 17
>         Dialect Index: 8, greater than LANMAN2.1
>         Security Mode: 0x03
>             .... ...1 = Mode: USER security mode
>             .... ..1. = Password: ENCRYPTED password. Use challenge/response
>             .... .0.. = Signatures: Security signatures NOT enabled
>             .... 0... = Sig Req: Security signatures NOT required
>         Max Mpx Count: 50
>         Max VCs: 1
>         Max Buffer Size: 16644
>         Max Raw Buffer: 65536
>         Session Key: 0x00001ed9
>         Capabilities: 0x8000f3fd
>             .... .... .... .... .... .... .... ...1 = Raw Mode: Read Raw and Write Raw are supported
>             .... .... .... .... .... .... .... ..0. = MPX Mode: Read Mpx and Write Mpx are not supported
>             .... .... .... .... .... .... .... .1.. = Unicode: Unicode strings are supported
>             .... .... .... .... .... .... .... 1... = Large Files: Large files are supported
>             .... .... .... .... .... .... ...1 .... = NT SMBs: NT SMBs are supported
>             .... .... .... .... .... .... ..1. .... = RPC Remote APIs: RPC remote APIs are supported
>             .... .... .... .... .... .... .1.. .... = NT Status Codes: NT status codes are supported
>             .... .... .... .... .... .... 1... .... = Level 2 Oplocks: Level 2 oplocks are supported
>             .... .... .... .... .... ...1 .... .... = Lock and Read: Lock and Read is supported
>             .... .... .... .... .... ..1. .... .... = NT Find: NT Find is supported
>             .... .... .... .... ...1 .... .... .... = Dfs: Dfs is supported
>             .... .... .... .... ..1. .... .... .... = Infolevel Passthru: NT information level request passthrough is supported
>             .... .... .... .... .1.. .... .... .... = Large ReadX: Large Read andX is supported
>             .... .... .... .... 1... .... .... .... = Large WriteX: Large Write andX is supported
>             .... .... 0... .... .... .... .... .... = UNIX: UNIX extensions are not supported
>             .... ..0. .... .... .... .... .... .... = Reserved: Reserved
>             ..0. .... .... .... .... .... .... .... = Bulk Transfer: Bulk Read and Bulk Write are not supported
>             .0.. .... .... .... .... .... .... .... = Compressed Data: Compressed data transfer is not supported
>             1... .... .... .... .... .... .... .... = Extended Security: Extended security exchanges are supported
>         System Time: Oct 28, 2009 09:42:32.000000000
>         Server Time Zone: -60 min from UTC
>         Key Length: 0
>         Byte Count (BCC): 110
>         Server GUID: 66732D73727631000000000000000000
>         Security Blob: 605C06062B0601050502A0523050A024302206092A864886...
>             GSS-API Generic Security Service Application Program Interface
>                 OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation)
>                 SPNEGO
>                     negTokenInit
>                         mechTypes: 3 items
>                             Item: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
>                             Item: 1.2.840.48018.1.2.2 (MS KRB5 - Microsoft Kerberos 5)
>                             Item: 1.3.6.1.4.1.311.2.2.10 (NTLMSSP - Microsoft NTLM Security Support Provider)
>                         mechListMIC: 3026A0241B22636966732F66732D737276312E696E662E65...
>                             principal: cifs/fs-srv1.inf.ethz.ch@...
>
>

CIFS currently relies on you to specify the same hostname in the UNC as
the krb5 service principal that you need to mount.

The reason is that while CIFS doesn't currently do mutual krb5
authentication, eventually it should. The problem with trusting the
mechListMIC is that it makes the client susceptible to
man-in-the-middle attacks. An attacker could redirect traffic to a
server of his choosing (perhaps by spoofing DNS) and the client would
be none the wiser.

Now...when you say that fs-srv1 is a different host from the file
server, what exactly do you mean?

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

[Andrew Baumann-2]

Hi Jeff,

On Wednesday 28 October 2009 13.31:27 Jeff Layton wrote:
> The reason is that while CIFS doesn't currently do mutual krb5
> authentication, eventually it should. The problem with trusting the
> mechListMIC is that it makes the client susceptible to
> man-in-the-middle attacks. An attacker could redirect traffic to a
> server of his choosing (perhaps by spoofing DNS) and the client would
> be none the wiser.

Hm, I see. Do you happen to know if smbclient does this? In the interim,
perhaps it would be useful to have a mount option that could specify the
service principal explicitly.

> Now...when you say that fs-srv1 is a different host from the file
> server, what exactly do you mean?

I mean that it is a valid host with a different IP from the host with the
share, and it does not itself offer SMB service:

$ host fs.systems
fs.systems.inf.ethz.ch is an alias for fs-systems.inf.ethz.ch.
fs-systems.inf.ethz.ch has address 129.132.19.42
$ host fs-srv1
fs-srv1.ethz.ch is an alias for fs-srv1.inf.ethz.ch.
fs-srv1.inf.ethz.ch has address 129.132.19.5
$ telnet fs-srv1 microsoft-ds
Trying 129.132.19.5...
telnet: Unable to connect to remote host: Connection refused

(I don't know the exact details of the file service setup here, but I can find
out more if it's helpful).

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

[Jeff Layton-4]

On Wed, 28 Oct 2009 13:49:58 +0100
Andrew Baumann <andrewb@...> wrote:

> Hi Jeff,
>
> On Wednesday 28 October 2009 13.31:27 Jeff Layton wrote:
> > The reason is that while CIFS doesn't currently do mutual krb5
> > authentication, eventually it should. The problem with trusting the
> > mechListMIC is that it makes the client susceptible to
> > man-in-the-middle attacks. An attacker could redirect traffic to a
> > server of his choosing (perhaps by spoofing DNS) and the client would
> > be none the wiser.
>
> Hm, I see. Do you happen to know if smbclient does this? In the interim,
> perhaps it would be useful to have a mount option that could specify the
> service principal explicitly.
>

I think that would be unwise -- why use kerberos at all if you're going
to water it down?

> > Now...when you say that fs-srv1 is a different host from the file
> > server, what exactly do you mean?
>
> I mean that it is a valid host with a different IP from the host with the
> share, and it does not itself offer SMB service:
>
> $ host fs.systems
> fs.systems.inf.ethz.ch is an alias for fs-systems.inf.ethz.ch.
> fs-systems.inf.ethz.ch has address 129.132.19.42
> $ host fs-srv1
> fs-srv1.ethz.ch is an alias for fs-srv1.inf.ethz.ch.
> fs-srv1.inf.ethz.ch has address 129.132.19.5
> $ telnet fs-srv1 microsoft-ds
> Trying 129.132.19.5...
> telnet: Unable to connect to remote host: Connection refused
>
> (I don't know the exact details of the file service setup here, but I can find
> out more if it's helpful).
>

By "valid host" do you mean that it's a separate machine entirely? Or
are you playing around with floating addresses in a clustered setup?

Either way, this appears to be a server misconfiguration. A properly
configured server should accept principals for all possible hostname
aliases. The fact that it's expecting a service principal for a
completely different host and not accepting a service principal for one
of its names looks broken to me.

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

[Jeff Layton-4]

On Wed, 28 Oct 2009 13:49:58 +0100
Andrew Baumann <andrewb@...> wrote:

> Hi Jeff,
>
> On Wednesday 28 October 2009 13.31:27 Jeff Layton wrote:
> > The reason is that while CIFS doesn't currently do mutual krb5
> > authentication, eventually it should. The problem with trusting the
> > mechListMIC is that it makes the client susceptible to
> > man-in-the-middle attacks. An attacker could redirect traffic to a
> > server of his choosing (perhaps by spoofing DNS) and the client would
> > be none the wiser.
>
> Hm, I see. Do you happen to know if smbclient does this? In the interim,
> perhaps it would be useful to have a mount option that could specify the
> service principal explicitly.
>

Actually...I'm not terribly opposed to adding a mount option for this.
If someone wants to do the legwork on it and propose a patch, I'll be
happy to help review it.

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

[Andrew Baumann-2]

Hi Jeff,

On Wednesday 28 October 2009 14.08:30 Jeff Layton wrote:
> By "valid host" do you mean that it's a separate machine entirely? Or
> are you playing around with floating addresses in a clustered setup?

As it was explained to me, this is a cluster setup where the cluster nodes
have multiple floating IP addresses (for different samba server instances), but
join the domain using their canonical host name.

> Either way, this appears to be a server misconfiguration. A properly
> configured server should accept principals for all possible hostname
> aliases. The fact that it's expecting a service principal for a
> completely different host and not accepting a service principal for one
> of its names looks broken to me.

Ok... I've reported that to the people who run the servers, but the upshot of
it seems to be that Windows and smbclient work in this case but mount.cifs
won't.

On Wednesday 28 October 2009 19.28:36 Jeff Layton wrote:
> Actually...I'm not terribly opposed to adding a mount option for this.
> If someone wants to do the legwork on it and propose a patch, I'll be
> happy to help review it.

I don't have the cycles to do this myself -- I'm just going to make do with
password auth. However, thanks for your help and explanations.

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