Roberto Massa
Nicola FerriniConsiderazioni sul ritorno all’operatività normale dopo lunghi periodi di telelavoro e problematiche relative al Secure Channel di Kerberos e all’Expired Machine Account Password
Il passato recente ha imposto, quasi senza dare il tempo di interrogarsi sulle scelte tecnologiche da adottare, modalità di lavoro che per molti non erano impensabili anche soltanto pochi mesi fa. Ci si è trovati a ridefinire le modalità di accesso alle infrastrutture informatiche aziendali e non solo.
In questo contesto di lavoro a distanza sono stati adottati scenari molto differenti; in alcuni casi sono state installate batterie di Remote Desktop Services esposti tramite un portale WEB, in altri casi i servizi RDP sono sati connessi direttamente in internet. Tuttavia la configurazione di collegamenti tramite con VPN sono probabilmente i più frequenti.
In alcuni casi, i dipendenti sono stati autorizzati a portare a casa i loro PC aziendali per continuare a lavorare in remoto.
In questo ultimo scenario è importante interrogarsi sul comportamento che avrà la postazione che rimane disconnessa dal dominio di appartenenza per più del tempo di validità dell’account macchina, ossia 30 giorni.
Molti di voi ci hanno chiesto cosa succederà al ritorno dei PC in azienda e se i loro PC saranno fuori dominio e l’utente dovrà aspettarsi devi problemi relativi al Secure Channel/Expired Machine Account Password. In particolare, se vedranno la schermata seguente quando avranno effettuato il primo logon:
Figura 1: La relazione con il dominio è stata persa dal PC client
La risposta è semplicemente NO.
Per comprendere meglio tutto il contesto è bene riprendere un momento alcuni concetti sul comportamento degli oggetti computer all’interno di un dominio.
Semplificando molto, un account computer è analogo ad un account utente. È soggetto ad una relazione di fiducia verso il dominio, può essere sottoposto all’applicazione di Group Policy ed è un oggetto che può avere espliciti permessi di accesso a determinate risorse.
L’account computer è caratterizzato dall’avere una password che ne permette l’autenticazione con il dominio ed esegue quindi un vero e proprio logon così come avviene per gli utenti.
Un carattere distintivo tra account computer ed account utente è la modalità con cui viene gestito il rinnovo della password che è parte integrante del processo di autenticazione.
L’utente dispone di una password la cui scadenza e validità è gestita dal Dominio, per cui, impostato il parametro che ne definisce la durata, è quest’ultimo che invalida la password imponendo all’utente il cambio.
La password dell’oggetto computer non è gestita dal Dominio, ma bensì dal computer stesso essendo quest’ultimo che inizia il processo di rinnovo quando la password raggiunge la sua scadenza; anche questo parametro (che di default è impostato a 30 giorni) è modificabile per mezzo di una GPO.
La Policy da impostare è Domain Member:Maximum Machine Password Age ed è reperibile nel ramo Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
Figura 2: Impostazione della GPO di Machine password Age
Possiamo quindi dire che la password dell’account computer all’interno di AD non scade mai e rimane valida finché non si verifica una di queste 3 condizioni:
- il client non ne inizia il rinnovo.
- si aggiunge un nuovo oggetto con lo stesso nome al dominio.
- l’account stesso viene manualmente cancellato o disabilitato.
Se la postazione viene quindi spenta e riaccesa anche dopo un lungo periodo di tempo, questa sarà sempre in grado di ricollegarsi al dominio in quanto il processo NETLOGON al primo riavvio si occuperà di rinegoziare una nuova password con il Dominio stesso.
Anche se il computer viene acceso normalmente, ma non entra in contatto con il dominio il comportamento è lo stesso, ossia il processo NETLOGON, non trovando disponibile il dominio cui è appartenente, non inizierà il processo di rinnovo della password.
Alla luce di questo comportamento risulta evidente che in uno scenario come quello descritto all’inizio, quando una postazione “rientra” in azienda questa riprenderà correttamente il proprio funzionamento.
In alcune realtà le prassi legate alla sicurezza dell’infrastruttura prevedono che vengano effettuate verifiche su AD mirate alla identificazione di oggetti definiti “Stale” o non più attivi, con successiva cancellazione o disabilitazione.
Oggetti di questo tipo siano essi Account Macchina, Utenti o Gruppi sono e rappresentano possibili falle nella sicurezza.
In uno scenario di questo tipo si potrebbe verificare che un oggetto macchina, solo temporaneamente inattivo, venga rimosso.
Una ulteriore criticità potrebbe essere legata proprio alla connessione VPN. Una errata configurazione o problemi legati alla connessione stessa potrebbero fare sì che il client “creda” di essere in contatto con il dominio ed inizi le procedure di aggiornamento della password, ma che queste non si completino correttamente lasciando di fatto l’account macchina in dominio non coerente con i valori del client.
È un caso poco frequente ma è corretto e necessario considerarlo come possibile.
Questo contesto si configura come un problema di “Secure Channel” nei confronti del quale è necessario ristabilire la relazione di trust con il dominio, altrimenti non sarà possibile accedere correttamente alle risorse disponibili.
Qui di seguito riportiamo due esempi: il primo utilizza PowerShell mentre il secondo utilizza i tool Active Directory Users and Computers e Active Directory Administrative Center
Reset del Secure Channel utilizzando PowerShell
|
1 2 3 |
$cred = Get-Credential Reset-ComputerMachinePassword -Credential $cred |
Reset del Secure Channel utilizzando ADUC (Active Directory Users and Computers) ed ADAC (Active Directory Administrative Center)
Figura 3: Reset del computer account in Active Directory Users and Computers
Figura 4: Reset dell’account completato
La stessa operazione è possibile effettuarla utilizzando la console Active Directory Administrative Center. Dopo aver selezionato il computer di cui volete eseguire il reset del Secure Channel selezionate “Reset Account” dalla colonna Tasks presente sulla destra della schermata, come mostrato in figura:
Figura 5: Reset Account dell’account computer effettuato dalla console Active Directory Administrative Center
Reset dell’account Macchina dal lato Client con “Network ID”
È necessario essere collegati con un utente con privilegi amministrativi sul client. Dalle proprietà del sistema scegliete il pulsante Netword ID… e seguite il wizard per effettuare il reset del Secure Channel.
Figura 6: Reset dell’account Macchina dal lato Client con “Network ID”
Figura 7: Scelta del tipo di network utilizzata
Figura 8: Il computer fa parte del dominio
Figura 9: Informazioni necessarie per effettuare il join al dominio
Figura 10: Inserimento delle credenziali necessarie al join e al reset del secure channel
Figura 11: Avviso relativo alla presenza di un account computer con lo stesso nome già presente in Active Directory
Figura 12: Scelta sull’aggiunta dell’utente al computer
Figura 13: Join al dominio completato, con relativo reset del secure channel di Kerberos
Terminata la procedura il cliente deve essere riavviato e sarà possibile ricominciare a riutilizzarlo.
Conclusioni
L’operatività delle infrastrutture di Directory sono di norma robuste e con un buon grado di resilienza alle diverse condizioni di impiego come dimostrato nella recente condizione di remotizzazione di molte attività.
In alcuni casi è necessario considerare alcune peculiarità di comportamento al fine di preventivare un ritorno alla normalità con il minimo disservizio possibile.
Riferimenti