Questo problema è capitato ad un nostro cliente dopo aver aggiornato alcuni File Server a Windows 2008. I client Apple o Linux, dopo la migrazione del file server, non riescono ad usare kerberos per connettersi ad una share su Windows 2008/Vista mentre funziona con Windows2003/XP. Con Windows 2008/Vista vengono richieste le credenziali per autenticarsi in NTLM. 

Analizzando le due trace di rete prese durante l'accesso alla share su Windows 2003/XP e su Windows 2008/Vista si può vedere che l'accesso al file share Windows 2003/XP funziona senza errori. Nella trace presa su Windows 2003/XP è presente nella SPNEGO il principal: fileserver$@DOMAINAME.LOCAL che poi viene usato dal client Apple/Linux per instaurare la sessione. 

No.     Time                       Source                Destination           Protocol Info
15 2008-11-07 09:27:34.485849 192.168.2.244         10.62.1.99            SMB      Negotiate Protocol Response
    SMB (Server Message Block Protocol)
        SMB Header
        Negotiate Protocol Response (0x72)
        Security Blob: 606606062B0601050502A05C305AA030302E06092A864882...
            GSS-API Generic Security Service Application Program Interface
                OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation)
                SPNEGO
                    negTokenInit
                        mechTypes: 4 items
                            Item: 1.2.840.48018.1.2.2 (MS KRB5 - Microsoft Kerberos 5)
                            Item: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
                            Item: 1.2.840.113554.1.2.2.3 (KRB5 - Kerberos 5 - User to User)
                            Item: 1.3.6.1.4.1.311.2.2.10 (NTLMSSP - Microsoft NTLM Security Support Provider)
                        mechListMIC: 3024A0221B20737739303030667330312440504F50534F44...
                        principal: fileserver$@DOMAINAME.LOCAL

In Windows 2008/ Vista per design non è restituito questo valore e, infatti, nella trace troviamo principal: not_defined_in_RFC4178@please_ignore:

No.     Time                       Source                Destination           Protocol Info
31 2008-11-06 12:21:13.418875 192.168.2.247         10.62.1.99            SMB      Negotiate Protocol Response
        Security Blob: 606A06062B0601050502A060305EA030302E06092A864882...
            GSS-API Generic Security Service Application Program Interface
        OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation)
                SPNEGO
                    negTokenInit
                        mechTypes: 4 items
                            Item: 1.2.840.48018.1.2.2 (MS KRB5 - Microsoft Kerberos 5)
                            Item: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
                            Item: 1.2.840.113554.1.2.2.3 (KRB5 - Kerberos 5 - User to User)
                            Item: 1.3.6.1.4.1.311.2.2.10 (NTLMSSP - Microsoft NTLM Security Support Provider)
                       mechListMIC: 3028A0261B246E6F745F646566696E65645F696E5F524643...
                      
principal: not_defined_in_RFC4178@please_ignore

Questo campo non è definito nella RFC4178 e per questo non è indispensabile utilizzarlo e sopratutto è più sicuro non usarlo. La parte SMB di Apple/Linux dovrebbe essere in grado di gestire questa situazione.

Da una breve ricerca fatta in internet ho scoperto che questa condizione viene gestita dai client Apple e Linux:

* As such, in early versions of Windows SPNEGO, there were some "extra" fields added to the negTokenInit
* message which are being deprecated in Windows 2008 Server, and eventually service packs for older
* platforms. The most significant of these fields is the principal name - there is really no place in
* either standard which allows the return of a principal in negTokenInit messages. This is being corrected
* in Windows 2008 server by continuing to add the field, but instead of a "real" principal, it now contains
* "not_defined_in_RFC4178 at please_ignore".

*
* From a security standpoint, allowing the server to specify its service principal is a "bad idea" - So we
* need to handle this case. If the SPN is "not_defined_in_RFC4178 at please_ignore" then we will replace it
* with the host name. In the furture we may want to check for an empty SPN also.
*

* Make sure we didn't get an empty SPN.
*/

         if (((strncasecmp ((char *)rq.spn, "cifs/", sizeof(rq.spn))) == 0) ||
                 ((strncasecmp ((char *)rq.spn, WIN2008_SPN_PLEASE_IGNORE_REALM, sizeof(rq.spn))) == 0)) {
                 /* We need to add "cifs/ instance part" */
                 strlcpy((char *)rq.spn, "cifs/", sizeof(rq.spn));
                 /* Now the host name without a realm */

            Reference: http://www.opensource.apple.com/darwinsource/10.5/smb-344/lib/smb/ctx.c

Considerando che

    #define WIN2008_SPN_PLEASE_IGNORE_REALM "cifs/not_defined_in_RFC4178@please_ignore"Reference:

Reference: http://www.opensource.apple.com/darwinsource/10.5/smb-344/kernel/netsmb/smb_dev.h

Per risolvere questo problema bisogna aggiornare il cliente Apple/Linux. Questo problema può presentarsi anche con le NAS con sistema operativo Linux, in questo caso occorre aggiornare il firmware con l'ultima versione che gestisce la condizione descritta sopra.

Matteo Belloni
Support Escalation Engineer
Microsoft Enterprise Platforms Support