PREMESSA
Questo problema è abbastanza "vecchio" nel senso che l'ho incontrato circa un anno fa, solo che da allora non ho mai avuto 5 minuti di tempo (o meglio di voglia) per poter scrivere qualcosa al riguardo. C'è inoltre da notare che sul sito Microsoft si trovano i riferimenti a questo errore, ma i suggerimenti riportati (sicuramente validi in molte occasioni) non rispondevano esattamente alla situazione nella quale stavo operando. Aggiungo anche che il problema si è manifestato su un server di produzione dopo il passaggio del SP1 di Windows 2003.

PROBLEMA
Durante il riavvio della macchina, il servizio "Windows Time" (W32Time), il cui compito è quello di sincronizzare l'orologio della macchina con quello del domain controller, non si avvia in automatico e tentando l'avvio successivo può venir fuori uno dei due messaggi di errore:

 
    
 

SOLUZIONE
La prima cosa sul quale mi sono concentrato riguarda la spiegazione del messaggio di errore che riporta che il servizio ha "tentato" di fare un logon ma il "Network Logon Service" (per gli amici NETLOGON) non era avviato. Ora, se il messaggio fosse realistico, nemmeno l'administrator del dominio potrebbe entrare (se non forse usando le cached credentials) in quanto il servizio NETLOGON è proprio quello che effettua la validazione su Active Directory: infatti, controllando nell'elenco dei servizi, è venuto fuori che il NETLOGON era bello che avviato e tutto il resto funzionava alla perfezione.
Anche un eventuale problema sulle tempistiche di avvio non sembrava essere logico, dato che l'errore si presentava sia durante il riavvio della macchina sia facendo partire a mano il Windows Time.

Mi sono allora ricordato di una cosa un po' particolare (ma che si applicava bene al caso specifico in esame): i servizi hanno delle ACL (abbreviazione di Access Control List). Tutti sappiamo che su Windows possiamo assegnare permessi ai files/directory, alle chiavi di registro, alle stampanti: questi però sono alcuni degli esempi, dato che in Windows ogni "oggetto" (in senso lato) ha una propria ACL che stabilisce chi può usare ed in che modo quel determinato oggetto. Tra gli "oggetti" con ACL ci sono appunto i servizi: normalmente questi permessi non si "vedono" da interfaccia grafica se non usando una strada un po' tortuosa (in alternativa esiste un metodo facilissimo per vedere i permessi del servizio in formato SDDL - poi però si perde tempo a "interpretare" il formato SDDL che è al contempo elegante e complesso! ).

Ora, andando a guardare i permessi associati al servizio NETLOGON veniva fuori qualcosa di simile:

 
 

In pratica, secondo questa ACL, solo i membri del gruppo Administrators, l'utente INTERACTIVE; ovvero chi si logga sul server (console o RDP non fa differenza) e SYSTEM (ovviamente...) possono interagire in qualche modo con il servizio NETLOGON: quando dico "interagire" significa anche chiedere se il servizio è avviato o meno. Il servizio W32Time parte e gira con l'utente Local Service che non rientra in nessun modo nella lista di cui sopra:di conseguenza, quando il W32Time parte, non riuscendo a sapere se il NETLOGON è acceso o meno, si ferma e genera l'errore visto sopra.

Tanto per conferma, riporto la schermata di come dovrebbero essere i permessi del servizio NETLOGON in una installazione "pulita":

Come si può vedere, in questa ACL è presente il "gruppo" Authenticated Users che ha il diritto di Read (ovvero può leggere lo stato del controllo): ed è proprio grazie a questa riga/ACL che il W32Time riesce normalmente a interrogare lo stato del NETLOGON e quindi a partire.

La soluzione quindi è stata quella di rimettere i permessi sul servizio NETLOGON uguali a quelli di un setup "pulito".

COME VEDERE I PERMESSI ASSOCIATI AD UN SERVIZIO DA GUI
Ora, il punto che prima ho lasciato volutamente in sospeso è: ma come si fa a vedere i permessi associati ad un servizio da interfaccia grafica? Quello che sto per descrivere è il barbatrucco che uso io e che sfrutta esclusivamente tools presenti sul sistema operativo: non escludo quindi che a giro ci siano utility di terze parti e non escludo nemmeno che non esista un sistema "più" semplice per arrivare a questo risultato. 
Il punto di partenza è uno snap-in piuttosto trascurato di Windows: il Security Configuration and Analysis:questo tool è stato creato da Microsoft per poter velocemente applicare tutta una serie di impostazioni ad una macchina Windows partendo da un template precedentemente creato; volendo fare un paragone (forse un po' improprio) è come applicare una GPO "offline" - da notare però che le impostazioni qui contenute sono più numerose rispetto a quelle che potremmo trovare nella "local policy" (per gli amici, GPEDIT.msc). Non solo: oltre alla "configuration" questo tool consente di evidenziare le aree della macchina che differiscono da quanto specificato nel modello.
Per accedere a questo tool, è necessario aprire una Management Console vuota, aggiungere poi lo snap-in selezionato: a questo punto avremo una console simile a questa:

A questo punto si fa click-DX su Security Configuration and Analysis e si sceglie la voce Open Database, dato che il tool prevede di salvare le impostazioni in un file chiamato Security Database (estensione .sdb): se non esiste nessun database ne verrà creato uno con il nome specificato nella finestra di dialogo di apertura. Subito dopo, il tool chiederà a quale Template dovrà far riferimento per la configurazione: su tutte le macchine esistono già una serie di template predefiniti e tra questi utilizzo quello denominato Setup Security.inf che rappresenta l'insieme delle impostazioni applicate appunto durante l'installazione di Windows.
A questo punto il tool è "pronto" a fare l'analisi della macchina per riportare eventuali discordanze tra la configurazione attuale e quanto previsto nel modello: fare dunqie click DX e scegliere la voce Analyze computer now (verrà chiesto dove mettere il file di log dell'analisi - si può lasciare la postazione proposta).
Al termine dell'analisi verrà mostrata una struttura ad albero che per certi aspetti ricorda quella delle GPO:
Se ci si sposta nel ramo System Services, nel riquadro di destra (il Detail panel per dirla alla Microsoft) si popolerà con tutti i servizi installati sulla macchina: a questo punto basta fare doppio click sul servizio NETLOGON per mostrare una finestra dove il pulsante View Security permette di vedere come sono messi i permessi.
E per configurare i permessi? Il pulsante EDIT SECURITY non fa quello che a prima vista potrebbe suggerirci, ovvero cambiare le ACL; o meglio, le ACL vengono modificate, ma solo se si applica tutto il template scelto nella fase precedente (se avete fatto come suggerito avete usato il Setup Securiity.inf). 
La soluzione più carina è quella di crearsi un template "ad-hoc" contentene solo le impostazioni che volete "resettare": per creare un template è sufficiente usare un altro snap-in chiamato Security Templates (che fantasia, eh?): una volta creato il template personalizzato (dopo aver fatto le modifiche occhio a fare click-DX sul template -> SAVE!) , riaprite il Security Configuration and Analysis e gli dite di elaborare il vostro template. Solo che stavolta, dopo la fase Analyze scegliete la voce Configure your computer .
Vi assicuro che la procedura è più difficile a spiegarsi che a farsi.

Per i fanatici (come me) della riga di comando, c'è il fantastico tool SC che riporta i permessi in formato SDDL (ci saranno altri articoli su questo....): con SDSHOW si vedono i permessi, mentre con SDSET si configurano