Differenze tra accesso a una share di rete generica ed una share DFS in Windows

Ciao!

Oggi parleremo di come accedere ad una share DFS sia diverso dall’accedere ad una share “normale”. Esistono inoltre alcuni problemi che potrebbero emergere che vale la pena evidenziare.

Nella discussione userò la seguente nomenclatura per aiutarmi con gli esempi:

10.0.0.34 è il client Milano, membro del dominio black.int che si deve connettere alla share.

10.0.0.1 e 192.168.0.1 sono i Domain Controller e DNS server del dominio blue.int

10.0.0.7 è il file server Zurich, membro del dominio blue.int che ospita le share di rete.

BLUE\sg è l’utente,membro del dominio blue.int, che tenta di accedere alla share utilizzando un client membro del dominio black.int

Apertura di una share di rete generica

1) Il client deve connettersi a \\zurich.blue.int\public

2) Il client valuta la porzione della stringa corrispondente al server a cui connettersi, zurich.blue.int, ed effettua una query DNS per ottenerne l’indirizzo IP.

3) Una volta ottenuto l’indirizzo IP del file server, il client tenta due connessioni sulle porte TCP 139 o 445, e semplicemente verrà utilizzata quella per cui si ottiene una risposta più veloce. (Per ulteriori dettagli sui motivi dell’utilizzo di due porte differenti si può fare riferimento al seguente articolo http://blogs.technet.com/b/itasupport/archive/2011/12/23/smb-e-netbios-in-windows-2003.aspx)

4) Una volta stabilita la connessione TCP, client e server stabiliscono anche la sessione a livello SMB. La prima parte è la “Negotiate”, dove vengono definiti i parametri della connessione, il più importante dei quali è la scelta del “dialetto” SMB che verrà utilizzato per lo scambio dei dati. Verrà scelto il livello di SMB più “alto” che sia supportato sia da client che da server.

Riassumo brevemente in tabella le versioni di SMB supportate dai diversi sistemi operativi

(La lista completa dei dialetti è disponibile qui http://msdn.microsoft.com/en-us/library/ee441843(v=prot.10).aspx )

5) Il passo successivo è la autenticazione, gestita attraverso i comandi di “Session Setup”. Tramite la analisi di questi pacchetti è possibile identificare se stiamo utilizzando NTLM oppure Kerberos. NOTA BENE: se viene usato NTLM, la natura del protocollo stesso implica un tentativo di autenticazione anonima, un esplicito errore STATUS_MORE_PROCESSING_REQUIRED da parte del server che invita il client a fornire le sue credenziali, e un terzo pacchetto con le credenziali. Una sequenza del genere è quindi by design ed è quindi normale osservare un tale tipo di errore in una traccia di rete.

Esempio Kerberos

Esempio NTLM

6) Il terzo passo del session establishment SMB è la apertura della share virtuale IPC$ con un comando “Tree Connect”. Questo passo server a stabilire un canale virtuale di comunicazione tra client e server.

7) A questo punto siamo pronti per la vera e propria apertura della Share, che è una “Tree Connect” verso la share vera e propria che vogliamo aprire, in questo caso la share chiamata Public.

Apertura di una share DFS

1) Il client deve connettersi a \\blue.int\dfsnamespace

2) Il client valuta la porzione della stringa corrispondente al server a cui connettersi, blue.int, ed effettua una query DNS per ottenerne l’indirizzo IP. Tuttavia la query DNS restituirà l’indirizzo IP di un domain controller del dominio blue.int

3) Una volta ottenuto l’indirizzo IP del domain controller, il client non sa che non sta parlando con il vero Fileserver ma con un altro e quindi come da protocollo tenta due connessioni sulle porte TCP 139 o 445 (anche qui verrà utilizzata quella per cui si ottiene una risposta più veloce)

4) Una volta stabilita la connessione TCP, client e domain controller stabiliscono anche la sessione a livello SMB. La prima parte è sempre la “Negotiate”, vengono definiti i parametri della connessione, in particolare quale “dialetto” SMB verrà utilizzato per lo scambio dei dati e soprattutto il Domain Controller setta un flag nel pacchetto Negotiate Response, ad indicare che questa è una share DFS aware.

Dettaglio del pacchetto Negotiate Response:

5) Dopo la Negotiate, client e Domain Controller procedono alla fase di autenticazione tramite il “Session Setup”

6) A questo punto, poichè il client è stato precedentemente informato che questa è una share DFS, viene inviato il comando Get DFS Referral. Il domain controller risponderà con la lista dei fileserver che sono responsabili di ospitare la share DFS richiesta. Non entro qui nel dettaglio del funzionamento del bilanciamento e ottimizzazione del DFS namespace: è importante solo notare che in base a tali algoritmi, al sito in cui si trova il client e ad altri parametri, il Domain Controller restituisce la lista dei referral nell’ordine di preferenza ideale per il client stesso.

7) A partire da questo momento, il client viene a sapere il nome del fileserver dove c’è la share finale. Procederà quindi ad aprirla nella stessa modalità descritta in precedenza:

- Query DNS
- TCP Connection establishment
- SMB Negotiate
- SMB Session Setup
- SMB Tree Connect

Problemi noti in accesso alle share quando il client non appartiene allo stesso dominio del server

1) se un client del dominio black.int tenta di accedere a \\zurich\public l’accesso potrebbe non avere successo se il client non è configurato per appendere il suffisso DNS del server blue.int.

Infatti, il client non saprà in grado di risolvere l’indirizzo IP di Zurich tramite una query DNS.

Soluzione: utilizzare l’FQDN completo \\zurich.blue.int\public per accedere alla share oppure fare in modo che il DHCP server che assegna l’indirizzo IP al client, fornisca tra le opzioni anche il suffisso DNS blue.int

2) Se il client appartiene ad un dominio diverso dal server, potrebbe non essere in grado, di default, di accedere a Share di tipo DFS come \\blue.int\dfsnamespace

Il problema si verifica se il client NON ha connettività verso i domain controller del proprio dominio. In questo scenario, poiché il client non riesce a contattare il domain controllerdel SUO dominio, la connessione Kerberos fallisce (le credenziali macchina sono infatti proprie del dominio del client e non riconosciute da quello del server). Non si passa a NTLM perché by design si passa da Kerberos a NTLM solo quando si riceve un messaggio di errore dal proprio DC.

Di conseguenza, quello che succede è che il client si collegherà inizialmente al Domain Controller di blue.int, ma non potendo autenticarsi non riuscirà mai a sapere che la share è di tipo DFS, quindi non invierà mai i messaggi di Get DFS Referral, e la procedura fallirà con un tentativo di Tree Connect alla share chiamata “dfsnamespace” ma come se fosse ospitata sul Domain Controller stesso! Poichè tale share non esiste, la procedura fallisce con il classico errore “Path not found”.

Per precisione, vi riporto anche la sequenza dei pacchetti scambiati in rete: possiamo apprezzare l’errore Kerberos e il tentativo di accedere alla share come se fosse localmente sul DC 192.168.0.1

Qualora invece il client fosse in Workgroup, il problema non si presenterebbe poiché non tenterebbe mai di utilizzare Kerberos ma andrebbe diretto su NTLM.

È bene inoltre specificare che NTLM funziona, ma si potrebbe ravvisare una certa lentezza in accesso poiché il client tenterà numerose volte di accedere fornendo ripetute volte le proprie credenziali macchina (che non verranno accettate). Solo dopo il timeout, NTLM comunicherà il fallimento all’utente chiedendogli di inserire credenziali adeguate tramite il classico popup di richiesta credenziali. Solo a quel punto verrà tentata una autenticazione NTLM con le credenziali del dominio di target, che verranno ovviamente accettate correttamente.

Soluzioni:

• Utilizzare l’indirizzo IP anzichè il network name per connettersi alla share DFS, ad esempio \\10.0.0.7\dfsnamespace
  Questo forzerà automaticamente l’uso di NTLM
• Utilizzare la chiave di registro BackConnectionHostNames per aggiungere il dominio blue.int a quelli “utilizzabili” per autenticazione NTLM come descritto nel seguente articolo http://support.microsoft.com/kb/926642
• Mappare la share con net use specificando le credenziali utente (Che verranno quindi utilizzate in luogo delle credenziali macchina e quindi permetteranno la connessione con successo). Il comando di esempio nel mio caso sarà net use \\blue.int\dfsnamespace /user:blue\sg
  Attenzione: per effettuare questo workaround con successo, la Policy “Network access: Do not allow storage of passwords and credentials for network authentication ” deve essere disabilitata come descritto in http://support.microsoft.com/kb/968264

Grazie a tutti e alla prossima!

Stefano Gagliardi
Support Engineer
Microsoft Enterprise Platform Support