Ci sono poche cose più frustranti che sederti per collegarti in remoto al tuo PC, digitare le tue credenziali e sentirti dire, nel modo meno utile possibile, che “una restrizione dell’account utente (ad esempio, una restrizione per fascia oraria) ti impedisce di eseguire l’accesso”.

Una restrizione per fascia oraria? Questa macchina l’ho configurata io stesso.

È successo a me: bloccato fuori da una macchina Windows Server un’ora dopo averla migrata a un livello funzionale di dominio più recente. Dopo aver passato in rassegna la documentazione di Microsoft e i forum dei sysadmin, alla fine ho ricostruito cosa fosse andato storto, e non era affatto ciò che il messaggio di errore suggeriva.

Ecco ciò che nessuno ti dice subito: questo errore non è un singolo problema, è una categoria. La causa può essere qualsiasi cosa, da un account senza password a un percorso di autenticazione che ripiega silenziosamente su NTLM quando è consentito solo Kerberos. Una volta capito questo, sei già a metà strada per risolverlo.

Una restrizione dell'account utente impedisce l'accesso

Indice dei contenuti

Sintomo / Causa	Ambiente	Prima azione	Frequenza
Password vuota / assente sull’account locale	Autonomo / PC domestico	Soluzione 1 — Imposta una password	Comune
Account non presente nel diritto Consenti accesso RDP	Qualsiasi	Soluzione 2 — Verifica Assegnazione diritti utente	Comune
Account nel diritto Nega accesso RDP	Qualsiasi	Soluzione 2 — Rimuovi dal criterio di negazione	Comune
Connessione tramite IP, NTLM con restrizioni	Dominio	Soluzione 3 — Usa il nome host FQDN	Comune
Account bloccato	Qualsiasi	Soluzione 4 — Sblocca in ADUC / lusrmgr	Occasionale
Restrizione degli orari di accesso	Dominio	Soluzione 4 — Verifica Orari di accesso in ADUC	Occasionale
Account in Utenti protetti, Kerberos non funzionante	Dominio	Soluzione 5 — Ripara Kerberos o rimuovi dal gruppo	Amministrato/rafforzato
I registri eventi mostrano un errore di autenticazione	Qualsiasi	Soluzione 6 — Leggi il registro Sicurezza (evento 4625)	Diagnostico

La correzione necessaria dipende interamente dal tuo ambiente. Passa in rassegna queste domande prima di toccare qualsiasi cosa.

Puoi accedere in locale con lo stesso account? Se sì, e solo RDP fallisce, non si tratta di credenziali errate. Il problema è un’assegnazione dei diritti RDP, una restrizione dei criteri o un problema nel percorso di autenticazione. Controlla Visualizzatore eventi → Registri di Windows → Sicurezza sul computer di destinazione per l’ID evento 4625. Per gli ambienti di dominio, controlla anche i registri di sicurezza del controller di dominio, poiché alcuni errori di autenticazione sono visibili solo lì.

Un solo utente o tutti? Un singolo utente bloccato indica un’impostazione a livello di account. Tutti bloccati simultaneamente suggerisce una recente modifica dei criteri, un aggiornamento dei Criteri di gruppo o una modifica della configurazione lato server.

Computer standalone o aggiunto al dominio? Gli ambienti di dominio introducono criteri di gruppo di Active Directory, Kerberos, restrizioni NTLM e comportamento degli Utenti protetti. Se sei su un PC domestico standalone, probabilmente sono rilevanti solo i Fix 1, 2 e 4. Se sei in un dominio, potrebbero applicarsi tutti i Fix.

Ti stai connettendo tramite indirizzo IP o nome host? Questo conta più di quanto molti pensino. Connettersi tramite indirizzo IP in genere impedisce a Windows di usare Kerberos e forza il fallback a NTLM. Se NTLM è limitato nel tuo ambiente, quel fallback fallisce e ottieni proprio questo errore, anche se nulla nel tuo account è cambiato. Vedi Fix 3.

È cambiato qualcosa di recente? Aggiornamenti dei Criteri di gruppo, patch del sistema operativo, aumenti del livello funzionale del dominio e hardening della sicurezza possono tutti interrompere RDP da un giorno all’altro senza alcun avviso visibile. Poni sempre questa domanda prima di assumere che il problema sia il tuo account.

Le correzioni 1–4 sono le più pertinenti qui. Queste non richiedono alcuna conoscenza di Active Directory o di dominio.

Inizia da qui, soprattutto su un PC di casa o una macchina autonoma.

Per impostazione predefinita, Windows blocca gli accessi remoti per gli account locali che non hanno una password. Si tratta di un criterio di sicurezza intenzionale e documentato: l’impostazione “Account: Limita l’uso delle password vuote degli account locali al solo accesso alla console” è abilitata per impostazione predefinita, il che significa che gli account senza password sono limitati agli accessi interattivi alla console. RDP è un accesso interattivo remoto e pertanto è bloccato.

Perché questo accade: Microsoft documenta questo comportamento nell’impostazione dei Criteri di sicurezza locali “Account: Limita l’uso delle password vuote per gli account locali al solo accesso alla console.” (Microsoft Learn)

Imposta una password: apri Gestione computer → Utenti e gruppi locali → Utenti → fai clic con il tasto destro sull’account → Imposta password. Se questo risolve il problema, hai finito.

Esiste una soluzione alternativa: puoi disattivare la restrizione per le password vuote tramite secpol.msc o la chiave del Registro di sistema LimitBlankPasswordUse. Considerala solo come ultima risorsa su qualsiasi macchina accessibile in rete.

Avviso: Disabilitare le restrizioni sulle password vuote indebolisce notevolmente la tua superficie di attacco. Impostare una password forte è sempre la soluzione corretta.

Questa è una delle cause più comuni e una delle più facili da trascurare.

Windows utilizza due impostazioni dei Criteri di gruppo complementari per controllare l’accesso RDP:

Consenti l’accesso tramite Servizi Desktop remoto — concede il diritto di connettersi.
Nega l’accesso tramite Servizi Desktop remoto — blocca il diritto di connettersi.

Il criterio Nega ha sempre la precedenza su Consenti, indipendentemente dall’appartenenza al gruppo. Questo è un comportamento documentato da Microsoft.

Dove trovarlo: Apri gpedit.msc → Configurazione computer → Impostazioni di Windows → Impostazioni di sicurezza → Criteri locali → Assegnazione diritti utente.

Controlla entrambi i criteri. Conferma che il tuo account, o un gruppo di cui fa parte, ad esempio Utenti Desktop remoto o Amministratori, compaia in Consenti. Conferma che non compaia in Nega. Se il tuo account non è presente in Consenti, l’accesso RDP è bloccato indipendentemente dalla tua password o dalle tue credenziali.

Sui computer del dominio: Questi diritti possono essere impostati a livello di dominio tramite Criteri di gruppo e possono avere la precedenza sulle impostazioni locali. Se le impostazioni locali sembrano corrette ma il problema persiste, verifica la presenza di GPO in conflitto utilizzando gpresult /h report.html sul computer di destinazione.

Questa singola modifica risolve più problemi di quanti dovrebbe.

Quando ti connetti utilizzando un indirizzo IP (per esempio, 192.168.1.100), Windows in genere non può usare l’autenticazione Kerberos e ricade invece su NTLM. Sui computer domestici autonomi questo spesso va bene. Sui computer uniti al dominio in cui NTLM è limitato o disabilitato, questo fallback fallisce in silenzio e ottieni l’errore di restrizione dell’account, anche se nulla è cambiato nel tuo account.

Usa invece il nome host del computer:

server.yourdomain.com ✔ Consigliato

192.168.1.100 ✘ Forza il fallback a NTLM

Usa anche credenziali nel formato UPN quando ti connetti a computer di dominio: user@domain.com invece di DOMAIN\user. Questo aiuta Windows a scegliere il percorso di autenticazione corretto ed evita un numero sorprendente di casi limite.

Eccezione: Microsoft ha documentato una funzionalità Kerberos su IP più recente per gli ambienti Windows Server, ma richiede una configurazione esplicita e non è abilitata per impostazione predefinita. (Microsoft Learn: Configurazione di Kerberos per l’indirizzo IP).

Windows restituisce lo stesso messaggio generico per diversi tipi distinti di restrizioni, il che è parte di ciò che rende questo errore così frustrante. I blocchi dell’account e le restrizioni dell’orario di accesso sono due dei rari casi in cui il messaggio di errore è letteralmente corretto.

Per gli account locali (autonomi o di dominio) Apri lusrmgr.msc → seleziona l’utente → verifica se Account is locked out è spuntato. Sbloccalo in tal caso.

Per gli account di dominio Apri Utenti e computer di Active Directory → trova l’utente → fai doppio clic → scheda Account. Seleziona Sblocca account e verifica le Ore di accesso.

Un amministratore di Windows Server 2016 ha descritto di essersi imbattuto proprio in questo ostacolo: la connessione al server non riusciva con il messaggio di restrizione dell’account, ma non erano state configurate intenzionalmente restrizioni di orario. La causa era un Criterio di gruppo che aveva applicato silenziosamente una restrizione di accesso dopo un aggiornamento dei criteri di dominio. L’ID evento 4625 nel Registro di sicurezza avrebbe mostrato il sottocodice specifico.

Evento 4625: La voce del registro di Sicurezza per un accesso non riuscito include un codice di sottostato che identifica il motivo esatto. Valori comuni: 0xC0000234 (account bloccato), 0xC000006F (accesso fuori dall’orario consentito), 0xC0000022 (accesso negato). Verifica questo prima di ipotizzare la causa.

Le correzioni 5 e 6 richiedono l’accesso ad Active Directory e familiarità con Kerberos e NTLM. Se utilizzi un PC domestico standalone, puoi saltare questa sezione.

Questa è la modalità di guasto che coglie di sorpresa gli amministratori esperti, spesso dopo un aggiornamento del dominio.

Il gruppo di sicurezza Protected Users di Active Directory impone regole di autenticazione più rigorose ai propri membri:

L’autenticazione NTLM è completamente bloccata.
È consentito solo Kerberos, e solo con crittografia AES.
I tipi di crittografia Kerberos RC4 e DES non sono consentiti.
Le credenziali non vengono memorizzate nella cache sul computer.

Sulla carta, si tratta di un’eccellente igiene della sicurezza. In pratica, interrompe l’accesso RDP negli ambienti che dipendevano silenziosamente da NTL, che è esattamente ciò che accade quando ci si connette tramite indirizzo IP, quando il DNS è configurato in modo errato o quando Kerberos non è stato completamente convalidato dopo un aggiornamento del dominio. All’utente viene visualizzato il messaggio generico di restrizione dell’account senza alcuna indicazione che Protected Users sia coinvolto.

Perché emerge dopo gli aggiornamenti del dominio: L’innalzamento del livello funzionale del dominio spesso consente un’applicazione più rigorosa dei criteri esistenti. Gli account che erano già in Protected Users ma in precedenza tolleravano i fallback NTLM potrebbero improvvisamente non riuscire. (Microsoft Learn: Gruppo di sicurezza Utenti protetti)

Prima di rimuovere qualcuno da Protected Users, prova questi passaggi nell’ordine:

Usa l’FQDN della macchina (server.domain.com), non un indirizzo IP.
Usa le credenziali UPN (user@domain.com).
Verifica che la risoluzione DNS funzioni correttamente dalla macchina che si connette.
Verifica la connettività con il controller di dominio e che il servizio Kerberos sia in esecuzione.

Se Kerberos funziona correttamente, il problema di solito scompare senza modifiche all’account. In caso contrario, puoi rimuovere l’account da Protected Users come misura temporanea:

powershell
$Cred = Get-Credential Remove-ADGroupMember -Identity "Protected Users" -Members YourAccountName -Credential $Cred

Su PowerShell Remoting: Questo approccio funziona quando PowerShell Remoting è disponibile. Si noti che PowerShell Remoting utilizza anche Kerberos quando disponibile e NTLM come fallback, quindi potrebbe incorrere nelle stesse restrizioni di autenticazione in ambienti completamente sottoposti a hardening. (Microsoft Learn: WinRM Security)

Avviso: Rimuovere un account da Protected Users indebolisce la postura di sicurezza dell’account. Trattalo come un passaggio diagnostico, non come una correzione permanente. La soluzione corretta consiste nell’assicurarsi che Kerberos funzioni correttamente nel proprio ambiente.

Esci e consenti all’autenticazione di aggiornarsi prima di riprovare RDP dopo qualsiasi modifica dell’appartenenza a un gruppo.

A questo punto, smetti di indovinare e inizia a leggere.

Sul computer di destinazione Visualizzatore eventi → Registri di Windows → Sicurezza. Filtra per ID evento 4625. Ogni voce include un motivo dell’errore e un codice Sub Status che identifica la causa esatta, in modo molto più preciso rispetto al messaggio di errore RDP stesso.

Per un tracciamento dell’autenticazione più approfondito, abilita anche: Registri applicazioni e servizi → Microsoft → Windows → Autenticazione.

Sui controller di dominio Alcuni errori di autenticazione, soprattutto quelli relativi a Kerberos, vengono registrati solo sul controller di dominio che ha elaborato la richiesta, non sul computer di destinazione. Controlla i log di Sicurezza sui tuoi DC quando i log locali del computer di destinazione non ti danno il quadro completo.

Una volta trovato il codice Sub Status nell’evento 4625, l’errore smette di essere vago e diventa un problema specifico e diagnosticabile. I codici comuni sono elencati nella nota di Fix 4 sopra.

Se visualizzi il codice di errore 0xC07, in particolare su macOS utilizzando Microsoft Remote Desktop, in genere compare insieme alla stessa categoria di problemi di autenticazione e restrizioni descritti in questo articolo. Segnalazioni della community suggeriscono che connettersi tramite nome host invece che tramite indirizzo IP lo risolve in molti casi, in linea con lo schema di fallback NTLM descritto nella Correzione 3.

Non esiste una documentazione Microsoft definitiva che mappi chiaramente 0xC07 a un’unica causa principale. Consideralo come un segnale che ti trovi nella giusta categoria di problema piuttosto che una diagnosi precisa. Le correzioni sopra si applicano.

Quando l’accesso RDP viene negato con il messaggio “user account restriction”, Windows sta facendo esattamente ciò che dovrebbe fare, solo senza dirti quale regola hai attivato.

Il percorso più rapido verso la risoluzione è:

Usa la matrice diagnostica in cima a questo articolo per individuare la causa più probabile.
Applica la correzione pertinente al tuo ambiente (home/standalone o dominio).
Controlla l’Evento con ID 4625 sul computer di destinazione se la causa è ancora poco chiara.
Per gli ambienti di dominio, controlla anche i log del controller di dominio e verifica che Kerberos funzioni correttamente prima di modificare le impostazioni dell’account.

Nella maggior parte dei casi si tratta di qualcosa di semplice. Anche quando non lo è, di solito è qualcosa di logico, solo nascosto dietro un messaggio poco utile.

Come risolvere la restrizione dell’account utente che impedisce di accedere

Diagnostica rapida

Parte 1: PC domestico & macchine standalone

Soluzione 1: L'account non ha una password

Soluzione 2: Verifica chi è autorizzato a connettersi tramite RDP

Soluzione 3: Interrompi la connessione tramite indirizzo IP

Correzione 4: Verifica i blocchi dell'account e le restrizioni orarie di accesso

Parte 2: Ambienti di dominio e aziendali

Soluzione 5: Il gruppo Utenti protetti

Soluzione 6: Leggi i log quando nient'altro ha senso

Che dire del codice di errore 0xC07?

Riepilogo