Active Directory Secure Channel Deep Dive

In questi giorni ho avuto via mail alcune richieste circa il Secure Channel di Active Directory e quindi ho deciso di rispondere tramite un post riassuntivo, a beneficio quanti fossero interessati all’argomento, che comprende anche approfondimenti che avevo avuto modo di fare in passato con altri utenti del mio blog.

Funzionamento del Secure Channel

In Active Directory gli account computer hanno una password che il sistema utilizza per autenticarsi con il Domain Controller del dominio esattamente come accade per gli account utente, la differenza è che la password dell’account computer viene gestita in modo automatico dal client. Il Secure Channel fornisce un metodo di comunicazione crittografato tra client e controller di dominio.

Per proteggere il traffico di autenticazione da attacchi Man-in-the-Middle, replay e altri tipi di attacchi di rete, i computer basati su Windows creano un Secure Channel tramite NetLogon. Tale canale autentica gli account del computer, esegue l’autenticazione degli account utente quando un utente remoto si connette a una risorsa di rete e l’account utente esiste in un dominio trusted. Questa operazione viene chiamata autenticazione pass-through e consente a un computer basato su Windows che ha eseguito il join ad un dominio di avere accesso al database degli account utente nel proprio dominio e in tutti i domini trusted.

Quando un computer basato su Windows esegui il join ad un dominio, viene creato un account del computer. Dopo il join a dominio il dispositivo usa la password del suo account computer per creare un Secure Channel con il controller di dominio per il proprio dominio ogni volta che viene riavviato, il Secure Channel viene usato per eseguire operazioni come l’autenticazione NTLM pass through NTLM e il LSA SID/name Lookup.

Per impostazione predefinita i dispositivi che hanno eseguito il join al dominio modificano le password degli account del computer ogni 30 giorni e il servizio Netlogon la verifica se è necessarion rinnovare la password ogni 15 minuti, ma è possibile modificare tale impostazione, a riguardo si vedano le seguenti group policy:

In sintesi le group policy rilevanti per il funzionamento del servizio Netlogon sono le seguenti:

  • Computer Configuration\Administrative Templates\Control Panel\System\Net Logon\Set scavenge interval (default 15 minutes)
  • Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Domain member: Maximum machine account password age (default 30 days)
  • Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Domain member: Disable machine account password changes (default Disabled).

Si tenga presente che aumentando in modo significativo l’intervallo di modifica della password o disabilitando le modifiche alle password, un utente malintenzionato ha più tempo per intraprendere un attacco a forza bruta per ricavare la password degli account computer.

Le richieste inviate sul Secure Channel vengono autenticate e le informazioni riservate come le password vengono crittografate, ma l’integrità del Secure Channel non è controllata e non tutte le informazioni sono criptate. Se un sistema è impostato per crittografare o firmare i dati del Secure Channel, non è possibile stabilire un Secure Channel con un controller di dominio che non sia in grado di firmare o crittografare tutto il traffico di canale sicuro. Se invece il computer è configurato per crittografare o firmare i dati del Secure Channel quando possibile, il Secure Channel verrà stabilito, ma il livello di crittografia e firma sarà negoziato a riguardo di veda Domain member: Digitally sign secure channel data (when possible).

Le comunicazioni da e verso i computer in Active Directory sfruttano il Secure Channel come ad esempio la gestione dei criteri di gruppo, scendendo nel dettaglio esistono tre tipi di Secure Channel:

  • quello per le comunicazioni tra i clients e i domain controllers nel dominio;
  • quello per comunicazioni tra domain controllers dello stesso dominio;
  • quello per le comunicazioni tra domain controllers di un dominio sorgente e domain controllers di un dominio trusted.

Nel caso si sia interessati al flusso di funzionamento del Secure Channel è possibile fare riferimento al seguente articolo Detailed Concepts: Secure Channel Explained:

Verifica della funzionalità del Secure Channel

Mediante il cmdlet PowerShell Test-ComputerSecureChannel è possibile verificare che il Secure Channel tra il computer e il dominio funzioni correttamente controllando lo stato delle relazioni di trust, nel caso la verifica fallisca è possibile utilizzare il parametro Repair per ripristinare il Secure Channel. Di seguito alcuni esempi di comando:

Verifica del Secure Channel:

Test-ComputerSecureChannel

Verifica del Secure Channel con informazioni dettagliate:

Test-ComputerSecureChannel -Verbose

Ripristino del Secure Channel (per eseguire tale operazione è necessario essere membri del gruppo locale Administrators, ma non è necessario riavviare il sistema dopo l’esecuzione):

Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

Controllo che proprietà PasswordLastSet dell’oggetto account computer in Active Directory sia aggiornato:

Get-ADComputer -Properties PasswordlastSet -Identity $env:computername

In alternativa per ripristinare il Secure Channel è anche possibile utilizzare il cmdlet PowerShell Reset-ComputerMachinePassword (per eseguire tale operazione è necessario essere membri del gruppo locale Administrators, ma non è necessario riavviare il sistema dopo l’esecuzione):

Reset-ComputerMachinePassword -Credential (Get-Credential)

Una terza alternativa per ripristinare il Secure Channel è quella descritta nella KB 2771040 “The trust relationship between this workstation and the primary domain failed” error when you log in to Windows 7:

  1. Use a local administrator account to log on to the computer.
  2. Select Start, press and hold (or right-click) Computer > Properties.
  3. Select Change settings next to the computer name.
  4. On the Computer Name tab, select Change.
  5. Under the Member of heading, select Workgroup, type a workgroup name, and then select OK.
  6. When you are prompted to restart the computer, select OK.
  7. On the Computer Name tab, select Change again.
  8. Under the Member of heading, select Domain, and then type the domain name.
  9. Select OK, and then type the credentials of the user who has permissions in the domain.
  10. When you are prompted to restart the computer, select OK.
  11. Restart the computer.

Blocco del Secure Channel

Il sintomo principale del blocco del Secrure Channel è va visualizzazione dell’errore “The trust relationship between this workstation and the primary domain failed.” che si verifica quando per il computer non è più possibile stabilire una comunicazione sicura con il domain controller perché la password dell’account computer memorizzata nel computer non è impostata allo stesso valore memorizzato sul controller di dominio.

Nel computer la password dell’account computer è mantenuta nella chiave di registro dir HKLM\SECURITY\Policy\Secrets\$machine.ACC utilizzando il valore CurrVal per la password corrente e il valore OldVal per la password precedente a riguardo si veda il seguente articolo Use PowerShell to Decrypt LSA Secrets from the Registry

Next, we run the Enable-TSDuplicateToken function to gain access to HKLM:\SECURITY.

PS > Enable-TSDuplicateToken

Now let’s take a look at what we can find under the HKLM:\Security\Policy\Secrets key.

PS > dir HKLM:\SECURITY\Policy\Secrets

Varie sono le possibili cause che possono bloccare il Secure Channel, di seguito nel elencherò alcune:

  • Reset del computer account nello snap-in MMC Active Directory Users and Computers (dsa.msc) in quanto ciò comporta l’avvio di una richiesta di modifica della password dell’account computer, ma non viene replicata nel controller di dominio.
  • Esecuzione di System restore sul client.
  • Ripristino dell’immagine di un client.
  • Join a dominio di client utilizzando un nome computer già utilizzato da precedentemente da un client a dominio.
  • Ripristino di una macchina virtuale ad un istante precedente ad esempio tramite un checkpoint o uno snapshot.
  • Errori nella sincronizzazione nell’ora di sistema.
  • Errori di configurazione DNS
  • Errori di rete.

Approfondimenti

Di seguito riporto per completezza alcuni utili link dove trovare interessanti informazioni.

Machine Account Password Process (First published on TechNet on Feb 13, 2009) una serie di FAQ scritte da Ned Pyle (Principal Program Manager in the Windows Server engineering group at Microsoft) di cui riporto passaggi:

Question: If a workstation does not change its password, will it not be allowed to log onto the network?

Answer: Machine account passwords as such do not expire in Active Directory. They are exempted from the domain’s password policy. It is important to remember that machine account password changes are driven by the CLIENT (computer), and not the AD. As long as no one has disabled or deleted the computer account, nor tried to add a computer with the same name to the domain, (or some other destructive action), the computer will continue to work no matter how long it has been since its machine account password was initiated and changed.

So if a computer is turned off for three months nothing expires. When the computer starts up, it will notice that its password is older than 30 days and will initiate action to change it. The Netlogon service on the client computer is responsible for doing this. This is only applicable if the machine is turned off for such a long time.

If the machine was down for a long time, that scavenger thread will not run and the password will not get out of sync in the local store and Active Directory.

If the machine was unable to communicate with a domain controller, the client doesn’t try to change its password. For example, if it was a laptop running at home with no VPN for 4 months, the laptop would never change its own machine password.

 

Question: How do computers actually use passwords?

Answer: Each Windows-based computer maintains a machine account password history containing the current and previous passwords used for the account. When two computers attempt to authenticate with each other and a change to the current password is not yet received, Windows then relies on the previous password. If the sequence of password changes exceeds two changes, the computers involved may be unable to communicate, and you may receive error messages.

When a client determines that the machine account password needs to be changed, it would try to contact a domain controller for the domain of which it is a member of to change the password on the domain controller. If this operation succeeds then it would update machine account password locally.

The local copy of the machine password is stored under:

HKLM\SECURITY\Policy\Secrets\$machine.ACC

We store the current password and the previous password under CurrVal & OldVal Keys respectively.

In Active Directory, we store the password in unicodepwd and lmpwdHistory . We also store the timestamp in the pwdlastset attribute (the method to convert it into readable format is

  • Convert the value in the attribute from decimal to hex (using calc.exe)
  • Split the result into two equal parts (8 bits for each part)
  • Run nltest /time: rightsidehex leftsidehex

The resultant value is the date and time the password was set on this computer object in AD. The cases where in you could run into problems that the KB260575 describes would be:

If you use System Restore after the password change interval expired one time, and you restore the computer to a point before the password changes, the next password change may not occur when it is due. Instead, the operating system treats the restore as if the password was changed.

Now consider the scenario, when a machine is not connected to the network for a long period.

Machine Account Password Process (First published on TechNet on Feb 15, 2009) una versione antecedente della precedente serie di FAQ scritte da Ned Pyle (Principal Program Manager in the Windows Server engineering group at Microsoft) di cui riporto una precisazione fatta da Ned Pyle in un commento all’articolo:

  • The password change process will attempt to be initiated by the scavenger process – but it will not be completed (nor will the PC’s local registry be updated with a new password), because the PC cannot see/find a DC.
  • When those PCs come back to the office in xxx days (or get VPN connectivity or whatever), the scavenge thread of the local Netlogon process on the PC will wake up and attempt the domain password change process again (it’s been trying it while offline but failing to complete because it couldn’t reach a DC).

    • However, this time, since the PC will be able to find a DC, it will complete the local password change, the DC will update the pwd of the computer object in its copy of AD, then repl that out to other DCs, and all will be well.
    • This assumes:

      • The device is unable to communicate AT ALL with a DC while offline.
      • The device isn’t partially blocked/filtered in communicating to a DC once it gains corp-net connectivity (i.e. some ports are blocked via a firewall)
      • There aren’t any scripts running on-prem that delete/disable computer accts
      • AD replication is working

Secure Channel/Expired Machine Account Password Concerns – Revisited scritto da Michael Hildebrand (dipendente Microsoft) di cui riporto alcuni passaggi:

The password change process on your remote worker’s PCs will kick-off at some point after the MaximumPasswordAge interval is exceeded on the PC. However, in the ‘no AD connectivity’ situation, a DC won’t be discovered/reachable. The machine password change process ‘logic’ is such that if the client can’t connect to a DC, “the process” will shut itself down before the PC’s local registry is updated with a new password – nothing changes on the client.

 

When these PCs come back to the office in xxx days (or get full VPN connectivity to a DC or whatever), the password change process on the PC will “wake up” again and re-attempt the domain password change process. This time, assuming the PC will be able to find a DC, the process will complete its machine password change (and its corresponding registry update) – and then communicate that new value to the DC it found. This DC updates the password attribute of the computer object in its copy of AD, and then AD replication takes that new value out to other DCs. All will be well.

 

The netlogon process on the client has been trying this, every so often, while offline – but the process always bailed-out because it couldn’t find/reach a DC.

 

NOTE: There is one more BIG assumption here – that there aren’t any scripts/processes that run to delete/disable “stale” computer accounts in AD while these client devices are offline.

 

NOTE: The above scenario is “no connectivity to AD/DCs.” However, we have seen some issues in the past if there was ‘intermittent’ connectivity, and a DC is resolved/found, but something blocks unfettered communications to the DC (such as a firewall rule or some other connectivity issue). In that case, the client password change process may not bail-out. The local device’s registry may get updated with a new password – but the DC won’t be updated. This is rare, and not normal, but if it happens, you may be on the road to secure channel issues.

 

As an FYI, here’s the doc on ports needed for full communication to AD/DCs/clients https://support.microsoft.com/en-us/help/179442/how-to-configure-a-firewall-for-domains-and-trusts

 

The device password change process (which is performed by the netlogon service on the client) – is smart enough to bail-out if it can’t find/talk to a DC and it won’t change the local password.