[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.
Still broken in 4.1.9
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).
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: \>
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 ~]$
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?
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?
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.
Can you please provide a network trace from a Windows client which behaves correctly connecting to a DFS share in this case?
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.
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').
I wonder if this ends up being a duplicate of bug 10708? Or just closely related?
(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.
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.
(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.
(In reply to Stefan Metzmacher from comment #14) I think this all works as expected in current releases.