Network List e Network Location Awareness (Windows non connesso ad alcuna rete)

Ciao a tutti!

Eccoci tornati con un nuovo appuntamento della rubrica "problemi impossibili".

Vi siete mai imbattuti in un problema del genere?

Client Windows 7 che ritiene di non essere collegato a nessuna rete, pur essendo connesso, in grado di navigare su internet, leggere la posta con Outlook, accedere a risorse di dominio..

image

Questo problema però causa intoppi ad alcune applicazioni, tra cui Lync 2010, che vanno a controllare l'informazione dal pannello di connettività delle reti, e che quindi non funzionano se Windows le avvisa di non essere connesso.

Un sintomo aggiuntivo lo vediamo dal pannello delle schede di rete, dove la NIC risulta "abilitata" ma non visualizza il nome della rete a cui è connessa.

image

Questo problema ci offre la possibilità di parlare dei servizi Network List e Network Location Awareness.
Il servizio NLA, ogni volta che percepisce cambiamenti nella connettività della scheda di rete, va a controllare in che tipo di rete ci troviamo (tra quelle identificate dal Network List), per poter assegnare il corretto profilo del Windows Firewall da applicare.
Non appena viene rilevata connessione di rete, viene fatta quindi una query LDAP per cercare di individuare un Domain Controller. Se questa query ha esito positivo, il servizio determina che ci troviamo nella rete del dominio aziendale e attiva il "Domain Profile" sul firewall.
Viceversa, verrà assegnato il "Public Profile" a meno che Windows non rilevi di essersi connesso ad una rete conosciuta che l'utente ha identificato come rete di casa o privata, e quindi attiverà il "Private Profile". I servizi mantengono uno storico, nel registro, di tutte le reti a cui si è connesso nella sua vita di sistema operativo. Provate a dare una occhiata sul vostro client, potrete trovare informazioni relative alle reti wireless che avete visitato nei vostri viaggi di lavoro :)

Nello specifico, la chiave di registro è HKLM\Software\Microsoft\WindowsNT\CurrentVersion\NetworkList

image

Ogni volta che ci connettiamo ad una nuova rete, succedono le seguenti cose:

  • Network list associa un profilo alla rete, creando un nuovo GUID ed una chiave sotto Profiles
  • Se la rete è di dominio, NLA crea una entry aggiuntiva sotto Cache/Intranet e Cache/IntranetForests aggiungendo informazioni relative a MAC address del gateway e nome del dominio della rete
  • A seconda che la rete sia di dominio oppure no, viene aggiunta una entry sotto Signatures/Managed o Signatures/Unmanaged con un riferimento al GUID del profile.

Ora, questa parte del registro è molto delicata. Cancellare una entry sotto Profiles o sotto la Cache non crea alcun problema (semplicemente, la prossima volta che ci colleghiamo alla stessa rete verrà ricreata una entry).
Ma effettuare altre operazioni come ad esempio backup e restore di questa porzione di registro può portare a diversi problemi, come appunto il problema impossibile descritto all'inizio dell'articolo. In quel caso, un software di terze parti che si occupa di mantenere uno storico delle reti connesse, andava a manipolare il registro tramite backup. Il risultato è un completo disastro sulle permissions. Guardiamo ad esempio la differenza tra un client con settings di default ed un client cui è stato fatto backup e restore (senza modificare chiave alcuna!)

Client pulito (berlin)

image

Client “rovinato” (paris)

image

Questo problema porta all'impossibilità per il servizio di andare a scrivere una entry nel registro, non riuscendo quindi ad aggiornare variabili interne e portando di conseguenza ad impostare il Windows Firewall come Public profile anche se siamo in dominio, e da questo mismatch il problema sul pannello di controllo del Network and Sharing Center.

La soluzione?

Ridare opportune permissions sulla chiave di registro HKLM\Software\Microsoft\WindowsNT\CurrentVersion\NetworkList (e suesottochiavi) per l'utenza Network Service (con cui gira il servizio NLA) e Local Service (con cui gira il servizio Network List)

Ulteriori informazioni

http://blogs.technet.com/b/networking/archive/2010/09/08/network-location-awareness-nla-and-how-it-relates-to-windows-firewall-profiles.aspx

Grazie a tutti e alla prossima!

Stefano Gagliardi
Sr. Support Engineer
Microsoft Enterprise Platform Support