Bug 10288 - smbclient GSSAPI fails to fall back to NTLMSSP when Kerberos fails.
smbclient GSSAPI fails to fall back to NTLMSSP when Kerberos fails.
Status: REOPENED
Product: Samba 4.1 and newer
Classification: Unclassified
Component: libsmbclient
4.2.2
All All
: P5 normal
: ---
Assigned To: Andreas Schneider
Samba QA Contact
:
Depends on:
Blocks: 10279
  Show dependency treegraph
 
Reported: 2013-11-22 12:33 UTC by David Woodhouse
Modified: 2016-03-02 12:28 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Woodhouse 2013-11-22 12:33:37 UTC
[dwmw2@shinybook ~]$ smbclient //amr.corp.intel.com/iss -k
ads_krb5_mk_req: smb_krb5_get_credentials failed for cifs/amr.corp.intel.com@GER.CORP.INTEL.COM (Server not found in Kerberos database)
cli_session_setup_kerberos: spnego_gen_krb5_negTokenInit failed: Server not found in Kerberos database
session setup failed: NT_STATUS_UNSUCCESSFUL

[dwmw2@shinybook ~]$ kvno -S cifs amr.corp.intel.com
cifs/orsamr204.amr.corp.intel.com@: kvno = 45

smbclient appears to insist on using a SPN based on the rôle address "AMR.CORP.INTEL.COM" instead of the reverse DNS of the machine it *actually* ended up talking to. This despite my having 'rdns=true' in /etc/krb5.conf to make Fedora 19's Kerberos actually work sensibly in the Windows environment where using reverse DNS is the only way to make *anything* ever work.
Comment 1 David Woodhouse 2014-09-22 19:52:20 UTC
Still broken in 4.1.9
Comment 2 David Woodhouse 2014-09-25 10:49:10 UTC
It's worse than I thought, in fact. I have GSS-NTLMSSP installed and if it's doing SPNEGO properly then it *should* have fallen back to NTLMSSP despite having the wrong SPN for Kerberos. But it doesn't do that *either*.

(Note that I mean GSS-NTLMSSP as a sub-mechanism within SPNEGO, which is entirely transparent to the caller; bug 10279 is a separate but equally frustrating issue).
Comment 3 Andreas Schneider 2014-11-11 10:05:53 UTC
I've tried to reproduce this with the v4-1-test branch. It is working for me.


-sh-4.2$ klist
Ticket cache: KEYRING:persistent:10001:10001
Default principal: joe1@DISCWORLD.SITE

Valid starting       Expires              Service principal
11/11/2014 11:05:01  11/11/2014 21:04:51  cifs/discworlddomain@DISCWORLD.SITE
        renew until 11/18/2014 11:04:50
11/11/2014 11:04:51  11/11/2014 21:04:51  krbtgt/DISCWORLD.SITE@DISCWORLD.SITE
        renew until 11/18/2014 11:04:50
-sh-4.2$ smbclient //discworlddomain/public -U DISCWORLD+joe1 -k
OS=[Windows Server 2008 R2 Enterprise 7601 Service Pack 1] Server=[Windows Server 2008 R2 Enterprise 6.1]
smb: \>
Comment 4 David Woodhouse 2014-11-12 11:22:25 UTC
For you, the 'cifs/domain' SPN appears to exist. For me, it doesn't., We have 'rdns=true' in /etc/krb5.conf because that's needed in our environment. If I connect to a specific server from the DFS rotation, Kerberos works. But not if I just try to use the DFS share name.

[dwoodhou@i7 ~]$ smbclient //amr.corp.intel.com/iss -k
ads_krb5_mk_req: smb_krb5_get_credentials failed for cifs/amr.corp.intel.com@AMR.CORP.INTEL.COM (Server not found in Kerberos database)
cli_session_setup_kerberos: spnego_gen_krb5_negTokenInit failed: Server not found in Kerberos database
session setup failed: NT_STATUS_UNSUCCESSFUL
[dwoodhou@i7 ~]$ smbclient //amr.corp.intel.com/iss -U GER\\dwoodhou 
Enter GER\dwoodhou's password: 
Domain=[AMR] OS=[Windows Server 2012 Datacenter 9200] Server=[Windows Server 2012 Datacenter 6.2]
smb: \> listconnect
0:	server=fmsisscorp05.amr.corp.intel.com, share=ISS
smb: \> ^C
[dwoodhou@i7 ~]$ smbclient //fmsisscorp05.amr.corp.intel.com/ISS -k
OS=[Windows Server 2003 R2 3790 Service Pack 2] Server=[Windows Server 2003 R2 5.2]
smb: \> ^C
[dwoodhou@i7 ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_500
Default principal: dwoodhou@GER.CORP.INTEL.COM

Valid starting     Expires            Service principal
12/11/14 11:11:45  12/11/14 21:11:45  krbtgt/GER.CORP.INTEL.COM@GER.CORP.INTEL.COM
	renew until 12/12/14 11:11:44
12/11/14 11:16:21  12/11/14 21:11:45  krbtgt/AMR.CORP.INTEL.COM@GER.CORP.INTEL.COM
	renew until 12/12/14 11:11:44
12/11/14 11:17:09  12/11/14 21:11:45  cifs/fmsisscorp05.amr.corp.intel.com@AMR.CORP.INTEL.COM
	renew until 12/12/14 11:11:44

[dwoodhou@i7 ~]$
Comment 5 David Woodhouse 2014-11-12 11:24:13 UTC
Besides, the whole point in GSS-NTLMSSP is that *when* Kerberos fails because it's so brittle, we should fall back to NTLM. This works for everything *else* (Evolution, Firefox, Chrome etc.) so why is Samba doing the wrong thing when it's trying GSSAPI authentication?
Comment 6 Andreas Schneider 2014-11-13 15:09:42 UTC
You enter a domain name and not a server. A domain can hold multiple DCs so how should we know to which DC you want to connect to?
Comment 7 David Woodhouse 2014-11-13 15:54:08 UTC
Does it matter which DC we connect to? That bit isn't going wrong, AFAICT. It looks like smbclient contacts a DC, does the appropriate dfsenum call, finds which file server(s) to connect to, and connects. Although as discussed in bug 10289 it doesn't correctly fall back to the second and subsequent file servers in the list, if it can't talk to the first.

The problem here is that *when* we talk to our chosen file server ('fmsisscorp05.amr.corp.intel.com' in the case of comment #4), we aren't obtaining a Kerberos ticket for the correct SPN.
Comment 8 Andreas Schneider 2014-12-05 09:11:17 UTC
Can you please provide a network trace from a Windows client which behaves correctly connecting to a DFS share in this case?
Comment 9 David Woodhouse 2014-12-05 10:12:11 UTC
Looking at 'klist' output on the Windows box after doing so (and failing to capture the trace because I was stupidly dumping the wrong interface), I think it's using GSS-NTLMSSP to connect to the GC. Then it gets a reference to the actual CIFS server to use and does manage to use Kerberos for that.

So I think the real issue here is that your GSSAPI authentication is trying only Kerberos, not doing SPNEGO properly and falling back to GSS-NTLMSSP. Fix that, and I think we're fine.
Comment 10 David Woodhouse 2015-06-18 09:41:53 UTC
Resetting NEEDINFO. I think this is fairly clear...

$ smbclient  -k //amr.corp.intel.com/iss -d99
 ...
cli_session_setup_spnego: using target hostname not SPNEGO principal
cli_session_setup_spnego: guessed server principal=cifs/amr.corp.intel.com@AMR.CORP.INTEL.COM
Doing kerberos session setup
ads_krb5_mk_req: smb_krb5_get_credentials failed for cifs/amr.corp.intel.com@AMR.CORP.INTEL.COM (Server not found in Kerberos database)
cli_session_setup_kerberos: spnego_gen_krb5_negTokenInit failed: Server not found in Kerberos database
samba_tevent: Schedule immediate event "tevent_req_trigger": 0x7f4498bb7eb0
samba_tevent: Run immediate event "tevent_req_trigger": 0x7f4498bb7eb0
SPNEGO login failed: Undetermined error
session setup failed: NT_STATUS_UNSUCCESSFUL


But SPNEGO shouldn't have given up when Kerberos failed. It should have fallen back to NTLMSSP, which *is* working (curl --negotiate works to authenticate to things which have broken reverse DNS, and when I 'kdestroy').
Comment 11 David Woodhouse 2015-06-18 09:47:05 UTC
I wonder if this ends up being a duplicate of bug 10708? Or just closely related?
Comment 12 Stefan Metzmacher 2016-03-02 10:42:11 UTC
(In reply to David Woodhouse from comment #10)

If you specify '-k' it means you WANT just kerberos and no fallback.

What we'll likely change in future versions is the behavior without
'-k' and still try kerberos with a fallback to NTLMSSP.
Comment 13 David Woodhouse 2016-03-02 11:30:36 UTC
OK, how do I specify that I want SPNEGO, not just Kerberos?

I have gss-ntlmssp installed, and SPNEGO will happily negotiate NTLMSSP internally if it needs to.
Comment 14 Stefan Metzmacher 2016-03-02 12:28:07 UTC
(In reply to David Woodhouse from comment #13)

Samba doesn't use the system 'gss-ntlmssp' via gssapi.

Currently it either use preselected handmade gss-krb5 OR our own
NTLMSSP, both within our own SPNEGO. But SPNEGO
doesn't do any real negotiation here.

Currently it's black or white, sorry.

I'm currently working on patches to do real negotiation.