Ciao ragazzi,

In questo primo blog volevo fare una panoramica sul processo di autenticazione tramite RODC e spiegare cosa sono le Password Replication Policy.

Di seguito i concetti chiave dei RODC:

  • nella configurazione standard, ogni qualvolta un utente tenta di autenticarsi al dominio, i RODC effettuano un forward della richiesta verso un writable DC. Pertanto affinchè l’autenticazione vada a buon fine, è necessario che la connettività di rete verso un writable DC sia sempre attiva. Per ovviare al problema della connettività, è possibile configurare il caching delle credenziali tramite le “Password Replication Policy”.
  • la “Password Replication Policy” è una feature tramite la quale è possibile salvare nella cache dei RODC, le credenziali di utenti precedentemente verificate verso un writable DC . Questa funzionalità consente agli utenti di effettuare logon al dominio anche quando la connettività di rete è assente. Di default, nessun utente è abilitato al caching. La configurazione delle PRP può essere fatta a livello di dominio (quindi impattare tutti i RODC) o a livello locale su ogni singono RODC. A livello di dominio sono definiti 2 gruppi che consentono o negano il caching su tutti i RODC e sono:
  • Allowed RODC Password Replication Group
  • Denied RODC Password Replication Group

Di seguito un esempio per comprendere meglio le PRP definite localmente su un RODC.

Supponiamo di avere 2 RODC: RODC1 e RODC2 (situati in 2 site diversi) e 1 writable domain controller WDC1 connesso agli altri 2 RODC tramite WAN.

Sul RODC1 è abilitato il caching per il gruppo di dominio RemoteUser ma non sul RODC2.

Bob è un utente appartenente al gruppo RemoteUser.

Quando Bob tenta di autenticarsi al dominio tramite RODC1, il DC controlla se nella propria cache ha memorizzate le credenziali dell’utente. In caso positivo, procede con l’autenticazione senza interrogare WDC1. In questa situazione Bob riesce ad effettuare il logon anche se il link tra RODC1 e WDC1 risulta down. In caso negativo (RODC1 non ha in cache le credenziali di Bob) se il link tra il RODC1 e WDC1 risulta down, Bob non è in grado di autenticarsi al dominio. Se il link è attivo, RODC1 interroga il WDC1, e dopo aver verificato le credenziali di Bob, le salva in cache. Nel caso in cui Bob non fosse abilitato al caching, sarebbe comunque in grado di effettuare logon al dominio (quando il link verso WDC1 è attivo) solo che le credenziali non verrebbero salvate.

Lo stesso ragionamento vale anche per i computer accout. Infatti al fine di consentire ad un utente di loggarsi al dominio anche a fronte di un down della rete, è necessario che anche il computer account utilizzato abbia le credenziali nella cache. Se così non fosse, Bob non sarebbe in grado di autenticarsi. Pertanto anche i computer account devono essere inseriti nel gruppo RemoteUser. Supponiamo che Bob utilizzi il client WKS1. Se WKS1 è inserito nel gruppo RemoteUser (gruppo ablitato al caching su RODC1), e Bob tenta di autenticarsi al dominio, anche l’account di WKS1 viene salvato nelle cache. Così, a seguito di un failure del network, Bob è in grado di accedere al dominio utilizzando WKS1. Nel caso in cui Bob tentasse di effettuare il login usando però WKS2, le cui credenziali non sono nella cache di RODC1, l’autenticazione fallirebbe.

Inoltre, nel caso in cui  Bob tenti di effettuare il logon al dominio tramite RODC2, è necessario che il link tra RODC2 e WDC1 sia attivo in quanto RODC2 non conosce la password di Bob. Se questo risultasse down, Bob non potrebbe effettuare il logon finchè la connettività tra RODC2 e WDC1 non è ripristinata.

Sui RODC è possibile sapere quali sono le credenziali in cache, consultando la voce “Accounts whose passwords are stored on this Read-Only Domain Controller”:

image

image

clip_image001

N.B: non c’è modo di eliminare le password cached sui RODC.

E’ possibile anche verificare quali account sono stati autenticati tramite un particolare RODC consultando invece la voce “Accounts that have been authenticated to this Read-Only Domain Controller”:

clip_image002

Questi sono gli account che il RODC ha verificato verso un WDC ma non ha salvato in cache.

Inoltre è possibile utilizzare la funzionalità Prepopulate Password al fine di consentire il primo logon (password non in cache) di un utente tramite un particolare RODC anche a fronte di un down della connettività verso il writable DC. Come già detto, è necessario che anche il client utilizzato dall’utente o abbia già l’accunt nella cache o sia stato effettuato anche per questo il password prepopulation. Riassumendo il “Prepopulate Password” consente agli utenti che non hanno nella cache del RODC le credenziali salvate, di riuscire ad autenticarsi al dominio anche a fronte di un down della rete. La differenza sostanziale rispetto agli utenti che sono solamente abilitati al caching, è che questi la prima volta che effettuano logon al dominio tramite il RODC richiedono la verifica delle credenziali verso un WDC.

Di seguito una serie di link ad articoli di technet che spiegano nel dettaglio le funzionalità dei RODC.

http://technet.microsoft.com/en-us/library/cc753470(WS.10).aspx#BKMK_pre

http://technet.microsoft.com/en-us/library/cc730883(WS.10).aspx

http://blogs.technet.com/b/askds/archive/2008/01/18/understanding-read-only-domain-controller-authentication.aspx

http://technet.microsoft.com/en-us/library/cc771744(WS.10).aspx

http://technet.microsoft.com/en-us/library/cc754956(WS.10).aspx

Ciao e alla prossima!

Francesco Castano
Support Engineer
Microsoft Enterprise Platform Support