Gestione remota: Windows Admin Center, PowerShell, JEA e SSH

Gestire un server che non hai davanti significa rispondere a due domande: su quale canale passa il comando (HTTPS verso un gateway, WinRM, SSH, RDP) e con quale identità viene eseguito all’altro capo. AZ-802 insiste sulla seconda. Le domande di questo dominio raramente chiedono «come si installa»: chiedono con quale account gira la sessione, fin dove arriva quell’account e che cosa succede al secondo salto.

Windows Admin Center: due prodotti diversi con lo stesso nome

La study guide dice «on-premises and in the Azure portal» perché sono due cose distinte, con requisiti che non si assomigliano.

Due dettagli che l’esame usa spesso. Primo: il regolamento Azure predefinito per WinRM apre la 5986 (HTTPS), quindi per il gateway serve una regola custom sulla 5985. Secondo: Windows Admin Center nel portale non funziona con Azure Bastion e non è un tunnel: la connessione deve arrivare direttamente all’IP della VM. Se la VM non ha IP pubblico, la VNet non ha ExpressRoute né VPN e la sicurezza non apre porte in ingresso da Internet, il canale che regge quei vincoli è Azure Bastion (RDP/SSH nel browser, su TLS 443 verso il servizio, nessun IP pubblico sulla VM), non Windows Admin Center.

Per raggiungere invece VM Azure senza IP pubblico da un gateway on-premises servono ExpressRoute, VPN site-to-site o point-to-site; quest’ultima si configura anche da Windows Admin Center con Azure Network Adapter.

Accesso al gateway e accesso al nodo non sono la stessa cosa

Sul gateway esistono gateway users (si collegano e gestiscono) e gateway administrators (cambiano chi accede e come si autentica); i local admin della macchina gateway sono sempre amministratori del servizio. C’è poi il gruppo Windows Admin Center CredSSP Administrators. Aggiungere Microsoft Entra ID è un livello in più, non sostitutivo: l’utente deve comunque avere un account Windows valido sul gateway.

Entrare nel gateway non dà però alcun diritto sui nodi: le credenziali passate (o quelle fornite con Manage as) devono essere amministrative sul server di destinazione. Due meccanismi spostano questo equilibrio:

• Single sign-on quando il gateway gira su Windows Server: richiede delega Kerberos, tipicamente resource-based, configurata sul nodo — Set-ADComputer -Identity (Get-ADComputer node01) -PrincipalsAllowedToDelegateToAccount (Get-ADComputer wac).
• Role-based access control sul nodo: si applica dal riquadro Overview > Settings > Role-based access control. Una configurazione DSC una tantum registra sul nodo un endpoint JEA chiamato Microsoft.Sme.PowerShell, che gira come amministratore locale temporaneo, e crea tre gruppi locali: Windows Admin Center Administrators, Windows Admin Center Hyper-V Administrators, Windows Admin Center Readers. È questa la strada per dare all’helpdesk servizi, eventi e certificati senza farlo local admin. Attenzione: l’applicazione riavvia WinRM, e l’RBAC non è supportato per la gestione dei cluster.

Il secondo salto (double hop)

Da ServerA apri una sessione remota su ServerB; lo script su ServerB legge \\ServerC\Data e prende access denied. Le credenziali usate per creare la sessione non vengono passate da B a C. Le opzioni, nell’ordine di preferenza della documentazione:

La RBCD si imposta con il parametro -PrincipalsAllowedToDelegateToAccount, che scrive l’attributo msDS-AllowedToActOnBehalfOfOtherIdentity sull’oggetto della risorsa: Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $ServerB. WinRM gira come account computer, quindi si delega al computer ServerB. Dopo il cambio, il KDC tiene in cache i dinieghi per 15 minuti: klist purge -li 0x3e7 su ServerB, oppure aspetta. Nota che né la RBCD né la delega classica coprono un secondo salto verso WinRM: vanno bene per SMB, WMI, log eventi.

JEA: l’identità conta più delle regole

Un endpoint JEA nasce da un file .pssc creato con New-PSSessionConfigurationFile -SessionType RestrictedRemoteServer, validato con Test-PSSessionConfigurationFile e registrato con Register-PSSessionConfiguration. RestrictedRemoteServer significa NoLanguage mode, nessun provider, nessun eseguibile esterno e solo otto cmdlet di base; tutto il resto arriva dalle role capability (.psrc) mappate in RoleDefinitions. Aggiungi TranscriptDirectory per l’audit.

La scelta che l’esame verifica è l’identità di esecuzione:

• RunAsVirtualAccount = $true crea un account virtuale locale temporaneo (admin locale, o membro dei soli gruppi elencati in RunAsVirtualAccountGroups). Ottimo per amministrare la macchina locale, inutile fuori: non si autentica verso la rete.
• GroupManagedServiceAccount = 'Domain\MyJEAGMSA' dà un’identità di dominio: è l’unica scelta se la funzione deve scrivere su una share o chiamare un servizio web. Costo: tutti gli utenti condividono la stessa run-as identity, quindi l’attribuzione delle azioni dipende dai transcript.

Per cambiare qualunque proprietà — comprese le mappature utente/ruolo — bisogna fare unregister e poi register di nuovo.

SSH remoto su Windows Server

Il servizio è sshd (porta 22), da mettere su Automatic con Get-Service -Name sshd | Set-Service -StartupType Automatic. Le chiavi host stanno in C:\ProgramData\ssh, le chiavi utente si generano con ssh-keygen e si custodiscono con il servizio ssh-agent più ssh-add.

Il punto che fa sbagliare: dove va la chiave pubblica dipende dall’account.

• utente standard: C:\Users\<utente>\.ssh\authorized_keys;
• membro del gruppo Administrators: C:\ProgramData\ssh\administrators_authorized_keys, con ACL ereditarietà rimossa e accesso ai soli Administrators e SYSTEM (icacls.exe ... /inheritance:r /grant "Administrators:F" /grant "SYSTEM:F").

Altri due vincoli documentati: gli account Microsoft Entra ID non supportano l’autenticazione a chiave (funzionano account locali e di dominio), e OpenSSH per Windows non supporta AuthorizedKeysCommand / AuthorizedKeysCommandUser. Infine, una sessione aperta con chiave non ha credenziali associate e quindi non può autenticarsi verso la rete: il double hop da lì non si fa.

Desktop remoto e credenziali

Abilitare RDP è banale (impostazione di sistema o GPO, regola firewall, appartenenza a Remote Desktop Users, NLA attiva). Il tema d’esame è come proteggere le credenziali su connessioni dirette, senza Gateway né Connection Broker.

Sull’host serve la policy Remote host allows delegation of nonexportable credentials (registro: DisableRestrictedAdmin = 0 sotto HKLM\SYSTEM\CurrentControlSet\Control\Lsa). Sul client si impone con Restrict delegation of credentials to remote servers, scegliendo Require Remote Credential Guard oppure Restrict credential delegation (che preferisce RCG e ripiega su Restricted Admin — e in quel caso ignora lo switch /restrictedAdmin). Per una sessione singola basta mstsc.exe /remoteGuard. Remote Credential Guard richiede host aggiunto a un dominio Active Directory (non Entra join), niente fallback NTLM, client Remote Desktop classico, e solo connessioni dirette: niente RD Gateway, niente Connection Broker. Per l’helpdesk che si collega a macchine potenzialmente compromesse, Microsoft raccomanda invece Restricted Admin.

Trappole tipiche d’esame

• «Windows Admin Center nel portale Azure» non è un tunnel. Non lavora con Azure Bastion e pretende che il portale raggiunga un IP diretto della VM: se non hai IP pubblico, né VPN/ExpressRoute, né porte in ingresso, la risposta è un altro servizio (Bastion), non WAC.
• Owner o Contributor non bastano per connettersi. Servono a installare l’estensione; per aprire la sessione serve Windows Admin Center Administrator Login (più Reader) assegnato a sottoscrizione, resource group o risorsa — mai a management group.
• Accesso al gateway ≠ accesso al nodo. Mettere l’helpdesk fra i gateway users non gli dà niente su FS1: la strada senza local admin è applicare l’RBAC sul nodo e popolare i tre gruppi locali Windows Admin Center ….
• La RBCD si configura sulla risorsa finale, non sul server intermedio. Su ServerC, con -PrincipalsAllowedToDelegateToAccount puntato all’oggetto computer di ServerB. E se hai già provato e fallito, svuota la cache negativa del KDC.
• Virtual account o gMSA. Se la funzione JEA tocca solo la macchina locale va bene RunAsVirtualAccount; appena tocca una share di dominio serve GroupManagedServiceAccount. Aggiungere il gruppo giusto o allargare le role capability non risolve un problema di identità.
• Le chiavi degli amministratori non stanno nel profilo. Per un account che è membro di Administrators sul server, authorized_keys nel profilo viene ignorato: conta C:\ProgramData\ssh\administrators_authorized_keys, con le ACL ristrette.
• Remote Credential Guard non è Restricted Admin. RCG conserva l’identità dell’utente (SSO e multi-hop) ma vuole Kerberos e connessioni dirette; Restricted Admin protegge da un host compromesso ma ti fa arrivare alle altre risorse come l’host, e richiede di essere amministratore della macchina remota.