Creare un nuovo utente su Windows Server 2019 e 2022

Su Windows Server 2019 e 2022 creare un nuovo utente non significa solo “aggiungere un account”. La scelta giusta dipende da dove deve vivere l’identità: account locale sul server, account di dominio in Active Directory, oppure utente che serve soltanto per un servizio, un task schedulato o l’accesso remoto limitato. Se questa distinzione non è chiara all’inizio, ci si ritrova spesso con privilegi più alti del necessario o con account che funzionano solo in parte.

La regola pratica è semplice: se l’utente deve operare su un solo server, usa un account locale; se deve autenticarsi su più macchine, usa Active Directory. In entrambi i casi, conviene partire da un profilo minimo, assegnare i permessi per gruppi e verificare subito il comportamento effettivo con un accesso di prova. È il modo più rapido per evitare sorprese dopo il provisioning.

Utente locale o utente di dominio: la scelta che cambia tutto

Un account locale esiste solo sul singolo server. È utile per manutenzione, accessi di emergenza, task specifici o ambienti isolati. Un account di dominio, invece, viene gestito in Active Directory e può essere usato su più host, con policy centralizzate, scadenze password, gruppi e auditing più ordinati.

Se stai amministrando un server membro di dominio, non creare account locali “per comodità” quando l’utente deve accedere con continuità. Nel tempo diventa difficile tracciare chi fa cosa, e la revoca dell’accesso si complica. Se invece il server è standalone o il dominio non è disponibile, l’account locale resta la via più lineare.

Per un nuovo account conviene decidere subito tre cose: nome logico, appartenenza ai gruppi e scopo operativo. Un utente nominato bene e messo nel gruppo giusto è più facile da gestire di un account creato in fretta e poi “aggiustato” con permessi diretti sparsi.

Creare un utente locale da GUI su Windows Server 2019/2022

Il percorso più rapido passa dalla console di gestione utenti locali. Su server con interfaccia grafica apri Computer Management oppure il pannello dedicato Local Users and Groups. Su molti server l’accesso è disponibile solo se la versione installata include la GUI completa; su installazioni Server Core la procedura va fatta da PowerShell o da strumenti remoti.

Passi operativi:

1. Apri Server Manager oppure Computer Management.
2. Vai in Local Users and Groups e poi in Users.
3. Fai clic destro e scegli New User.
4. Compila User name, Full name e, se serve, Description.
5. Imposta una password temporanea robusta.
6. Decidi se spuntare User must change password at next logon in base al processo aziendale.
7. Valuta Password never expires solo se hai una ragione precisa e una governance separata.
8. Crea l’account e verifica che compaia nell’elenco utenti locali.

Per ambienti amministrati bene, il punto più delicato non è la creazione in sé ma la policy password. Se l’utente è temporaneo, meglio forzare il cambio al primo accesso. Se è un account di servizio, non usare lo stesso schema degli utenti interattivi: in quel caso servono valutazioni diverse su scadenza, rotazione e diritti minimi.

Un controllo rapido dopo la creazione è utile per evitare errori banali sul nome o sul profilo. Da PowerShell puoi elencare gli utenti locali con:

Get-LocalUser | Select-Object Name, Enabled, LastLogon

Se l’utente compare, l’account è stato creato correttamente. Se non compare, il problema è quasi sempre un errore di contesto, di permessi o di piattaforma: ad esempio Server Core senza gli strumenti grafici, oppure sessione senza privilegi amministrativi.

Creare un utente locale da PowerShell

Su Windows Server la via PowerShell è la più pulita quando vuoi replicabilità, automazione o accesso remoto. È anche la scelta migliore su Server Core. Il vantaggio è evidente: il comando è ripetibile, documentabile e più facile da inserire in una procedura standard.

Esempio base per creare un utente locale:

$Password = Read-Host -AsSecureString
New-LocalUser -Name "mrossi" -Password $Password -FullName "Mario Rossi" -Description "Utente operativo"

Questo approccio evita di scrivere la password in chiaro nella shell. Se il contesto è un’attività amministrativa standard, è la scelta corretta. Dopo la creazione puoi verificare con:

Get-LocalUser -Name "mrossi" | Format-List Name,Enabled,Description,PasswordLastSet

Se devi consentire l’accesso remoto tramite RDP, non assegnare privilegi amministrativi al singolo utente a meno che non sia strettamente necessario. Meglio aggiungerlo al gruppo locale corretto, per esempio Remote Desktop Users, e lasciare i privilegi elevati a gruppi di amministrazione separati.

Per aggiungere un utente a un gruppo locale:

Add-LocalGroupMember -Group "Remote Desktop Users" -Member "mrossi"

Se l’account deve accedere come amministratore locale, il gruppo da usare è Administrators, ma questa è una decisione da prendere con cautela. In pratica, ogni volta che assegni amministrazione locale, allarghi la superficie d’attacco e aumenti il rischio operativo. Se puoi, preferisci gruppi più specifici e privilegi delegati.

Creare un utente di dominio in Active Directory

Per un account di dominio la logica cambia: l’oggetto va creato in Active Directory Users and Computers oppure con PowerShell sul domain controller o da una workstation con RSAT. Qui il punto non è solo “creare un utente”, ma collocarlo nel contenitore o nell’OU corretta, così eredita policy, filtri e gruppi nel modo giusto.

Da interfaccia grafica il percorso tipico è:

1. Apri Active Directory Users and Computers.
2. Vai nell’OU corretta, non nel contenitore generico se hai una struttura organizzata.
3. Fai clic destro e scegli New > User.
4. Inserisci nome, UPN o sAMAccountName secondo la convenzione interna.
5. Imposta la password iniziale e le policy di cambio al primo accesso.
6. Verifica l’appartenenza ai gruppi di base prima di lasciare l’utente operativo.

Con PowerShell, un esempio minimo è questo:

New-ADUser -Name "Mario Rossi" -GivenName "Mario" -Surname "Rossi" -SamAccountName "mrossi" -UserPrincipalName "mrossi@contoso.local" -Path "OU=Utenti,DC=contoso,DC=local" -AccountPassword (Read-Host -AsSecureString) -Enabled $true

La parte più importante è il parametro -Path: se lo sbagli, l’account finisce nell’OU errata e eredita policy non previste. Non è un dettaglio estetico, è un errore che si riflette subito su login, password policy, deleghe e filtri di gruppo.

Dopo la creazione, controlla almeno questi punti:

• l’account è Enabled;
• l’OU è quella prevista;
• il nome UPN è coerente con il dominio;
• l’utente è nei gruppi corretti;
• l’eventuale scadenza password è quella attesa.

Permessi: meglio gruppi che assegnazioni dirette

La regola che fa risparmiare tempo nel lungo periodo è semplice: assegna permessi a gruppi, non a singoli utenti, salvo eccezioni temporanee e motivate. Su Windows Server questo vale per accesso RDP, condivisioni SMB, applicazioni legacy, cartelle di servizio e ruoli amministrativi.

Se un utente deve leggere o scrivere su una share, inseriscilo nel gruppo previsto dalla share stessa. Se deve amministrare un servizio, crea un gruppo dedicato, documenta il motivo e verifica i diritti effettivi sul sistema target. In questo modo, quando l’utente esce dal team o cambia ruolo, la revoca diventa un’operazione pulita e veloce.

Un errore classico è aggiungere l’utente direttamente a Administrators per “fare prima”. Funziona, ma lascia un debito tecnico che si paga in auditing, sicurezza e gestione delle emergenze. Se serve davvero un privilegio elevato, meglio usare un gruppo nominato in modo esplicito, con scopo e scadenza chiari.

Accesso remoto, RDP e primo login

Se l’account deve usare Desktop Remoto, non basta crearlo: il server deve consentire RDP, il firewall deve permettere il traffico e l’utente deve appartenere al gruppo corretto. Inoltre, la policy locale o di dominio può imporre restrizioni aggiuntive, soprattutto sui server esposti o hardenizzati.

Controlli utili:

1. Verifica che il servizio Remote Desktop sia abilitato sul server.
2. Controlla l’appartenenza a Remote Desktop Users o al gruppo amministrativo previsto.
3. Se il login fallisce, controlla Event Viewer nei log di sicurezza e in Applications and Services Logs.
4. Se c’è una GPO, verifica che non stia negando l’accesso interattivo o RDP.

Per una diagnosi rapida, il logon failure più utile da cercare è quello con codice di errore coerente con i diritti mancanti o con credenziali errate. In ambienti di dominio, l’evento non dice sempre tutto da solo, ma restringe molto il campo: account disabilitato, password scaduta, accesso negato da policy, o gruppo mancante.

Account di servizio: non trattarli come utenti normali

Quando l’account serve a un servizio, a un’applicazione o a un task schedulato, la priorità non è la comodità dell’operatore ma la stabilità e la rotazione controllata delle credenziali. Qui il rischio principale è lasciare privilegi inutili o password statiche che nessuno tocca per anni.

Per questi casi, conviene valutare account dedicati con scope limitato, password gestite secondo policy e accesso solo ai servizi necessari. Se possibile, preferisci identità gestite dal dominio e meccanismi moderni come gMSA nei contesti compatibili. Quando non è possibile, documenta con precisione dove l’account viene usato: servizio Windows, attività pianificata, accesso a share, applicazione web, script di integrazione.

Un controllo minimo da fare subito è verificare se l’account ha davvero i diritti richiesti e niente di più. Questo si controlla lato gruppo, ACL e, se necessario, con i log del servizio che lo utilizza. Se il servizio fallisce, la diagnosi corretta parte da lì, non dalla creazione dell’utente in sé.

Verifiche post-creazione che evitano il classico “l’utente esiste ma non entra”

Molti problemi emergono dopo la creazione, non durante. L’account esiste, ma il login fallisce per un dettaglio: password policy incompatibile, account disabilitato, gruppo mancante, OU sbagliata, restrizione GPO, ora del sistema fuori sync, oppure semplice typo nel nome utente.

Checklist rapida:

• l’utente è abilitato;
• la password è stata impostata correttamente;
• il nome usato per l’accesso coincide con quello creato;
• l’utente è nel gruppo giusto;
• la macchina o il dominio applicano una policy che ne blocca l’accesso;
• l’orario del server è allineato, se c’è Kerberos di mezzo.

Per il dominio, un comando utile è:

Get-ADUser mrossi -Properties Enabled,PasswordLastSet,MemberOf | Select-Object Name,Enabled,PasswordLastSet

Se l’obiettivo è un accesso interattivo, fai una prova di login effettiva invece di fermarti alla sola verifica oggettiva dell’oggetto AD. È il test che conferma davvero che permessi, policy e identità sono allineati.

Buone pratiche operative per non rifare il lavoro due volte

Su Windows Server la qualità della gestione utenti non dipende dalla singola creazione, ma dalla disciplina con cui si costruisce il ciclo di vita dell’account. Nome coerente, OU corretta, gruppi chiari, privilegi minimi, revisione periodica e disattivazione quando l’utente non serve più sono i punti che fanno davvero la differenza.

In pratica, conviene standardizzare almeno questi elementi:

• convenzione di naming per utenti e gruppi;
• template di permessi per ruoli ricorrenti;
• procedura di onboarding e offboarding;
• verifica periodica degli account inattivi;
• separazione tra account personale e account amministrativo.

Se devi operare spesso su più server, PowerShell e gruppi ben progettati ti fanno risparmiare più tempo di qualunque click ripetuto in GUI. Se invece l’ambiente è piccolo o l’attività è sporadica, la console grafica resta perfettamente valida, purché tu non perda di vista la governance dei privilegi.

In sintesi operativa: crea l’account nel posto giusto, assegnagli il minimo indispensabile, verifica il login reale e documenta il motivo dei privilegi. È la differenza tra una gestione ordinata e una collezione di eccezioni difficili da mantenere.