Gonzalo MarsilliUn accesso Microsoft Entra può aprire un'applicazione Windows in AWS senza chiedere all'utente una seconda password Active Directory. Il risultato è semplice. Il percorso che lo rende possibile non lo è.
Claim di identità, permessi IAM, fiducia dei certificati, dati di revoca, DNS, appartenenza al dominio e capacità della fleet devono concordare. Una soluzione corretta valida l'intero percorso e documenta gli errori che un semplice test di avvio non rileverebbe.
L'architettura consente l'avvio via browser di una sessione Windows Server unita al dominio tramite certificate-based authentication (CBA). Il modello di validazione controlla l'applicazione pubblicata, l'identità Windows risultante, il fallback con password e la disattivazione/riattivazione della CBA.
Perché usare l'autenticazione basata su certificato?
Volevamo verificare se un'organizzazione che usa Microsoft Entra ID e Active Directory può offrire un percorso più lineare verso applicazioni Windows pubblicate. Entra resta il punto di autenticazione primario, con MFA e criteri di accesso. La CBA elimina la richiesta aggiuntiva della password AD durante lo streaming.
Il modello è utile quando un'applicazione richiede ancora un'identità di dominio Windows, ma l'utente non dovrebbe gestire un secondo passaggio di accesso. Tra i possibili casi ci sono applicazioni gestionali, accesso controllato per collaboratori e applicazioni da mantenere vicine ai dati aziendali.
Passwordless non significa senza autenticazione. AWS descrive la CBA come un flusso basato su SAML in cui WorkSpaces Applications richiede un certificato utente e lo presenta tramite una smart card virtuale. L'identity provider autentica comunque l'utente per primo.
Per confrontare le piattaforme, consulta il nostro confronto tra AWS WorkSpaces, Azure Virtual Desktop e Citrix.
Che cosa deve dimostrare una soluzione completa?
Un'implementazione difendibile dovrebbe superare 11 test di accettazione prima di essere considerata riuscita. Una finestra applicativa aperta non è una prova sufficiente.
I controlli coprivano isolamento dell'account, autenticazione Entra, mapping SAML, join al dominio, fiducia della CA, due percorsi di revoca, avvio senza password AD, fallback, reversibilità della CBA e teardown controllato.
Il risultato principale è la continuità dell'identità. UPN e SID partono da Active Directory, vengono sincronizzati in Entra, attraversano l'asserzione SAML e tornano allo stesso utente Windows. Questa corrispondenza trasforma uno stream riuscito in un risultato di identità verificato.
Come funziona il percorso di identità e certificato?
Il design unisce due flussi: la federazione stabilisce chi può entrare nello stack AWS; la PKI consente a Windows di autenticare la stessa persona in Active Directory senza mostrare la richiesta della password.
- L'utente si autentica con Microsoft Entra ID.
- Entra invia un'asserzione SAML con NameID persistente, ruolo, UPN, ObjectSid e dominio AD.
- AWS STS crea la sessione federata. La trust policy consente
sts:AssumeRoleWithSAMLests:TagSession. - WorkSpaces Applications riserva capacità nella fleet unita al dominio.
- Il servizio richiede un certificato utente di breve durata ad AWS Private CA.
- Windows riceve il certificato tramite una smart card virtuale e lo associa all'identità AD prevista.
Il SID non è un dettaglio secondario. Nei prerequisiti CBA, AWS richiede che ObjectSid corrisponda al SID AD dell'utente indicato nel NameID SAML. La stessa guida richiede sts:TagSession e un punto di distribuzione CRL raggiungibile dalla fleet e dal domain controller.
Un approccio di implementazione in sei fasi
Un ambiente di prova sicuro dovrebbe rimanere isolato e volutamente contenuto. Dovrebbe usare un account AWS non produttivo dedicato, senza route o trust verso reti di clienti o di produzione.
L'implementazione ha seguito sei fasi:
- Fondazione: VPC dedicata, subnet applicative private, egress controllato, tag, budget e amministrazione tramite Systems Manager.
- Directory: un domain controller Windows usa e getta forniva AD DS, DNS, AD CS e l'agente Entra Cloud Sync.
- Identità ibrida: sincronizzare un utente standard in Entra e controllare UPN e SID on-premises in ogni passaggio.
- Federazione: un'applicazione enterprise Entra emetteva i claim SAML necessari. Il ruolo IAM autorizzava lo streaming e i session tag.
- PKI: usare la root enterprise AD CS per firmare una subordinate AWS Private CA di breve durata, quindi pubblicare la catena negli store enterprise Root e NTAuth.
- Application delivery: un'immagine Windows Server 2022 personalizzata, una fleet multi-session Always-On e uno stack in modalità applicazione distribuivano il programma di test.
Per la revoca, AWS Private CA scriveva la CRL in un'origine S3 privata. CloudFront esponeva solo il percorso HTTP non autenticato richiesto dai client PKI, mantenendo attivo S3 Block Public Access. È il modello descritto nella guida CRL di AWS Private CA.
Le prove dalla connessione alla revoca
La prima evidenza è la schermata di connessione. Mostra esplicitamente il percorso di certificate-based authentication. URL di streaming e chrome del browser sono rimossi dalla vista pubblicata.
La seconda evidenza è all'interno di Windows. La dimostrazione sanitizzata apre Notepad in modalità applicazione e verifica il token corrente. Utente e dominio sono sostituiti da <TEST-USER> e <LAB-DOMAIN>.
La terza evidenza riguarda la revoca. L'indirizzo CRL inserito nel certificato restituisce HTTP 200. Host pubblico, identificatore PCA, IP, request ID, ETag e timestamp non sono inclusi nel ritaglio.
Una validazione completa seleziona anche il fallback, autentica la stessa identità AD, disabilita la CBA e riabilita la funzione. In ogni stato deve tornare il comportamento atteso. Il test reversibile evita di scambiare un successo occasionale per un design gestibile.
Lezioni comuni di implementazione
I problemi più difficili appaiono ai confini tra i servizi. Quattro lezioni sono riutilizzabili:
- Controllare l'asserzione SAML emessa. Il portale può sembrare corretto mentre nome, valore o virgolette del claim non lo sono.
- Testare l'URL CRL reale del certificato. Pubblicare la CRL non prova che domain controller e fleet riescano a scaricarla.
- Verificare la capacità prima dell'identità. Una fleet Always-On senza sessioni disponibili può produrre errori simili a un guasto CBA.
- Separare disattivazione e riduzione dei costi. Disabilitare la CBA non elimina i costi ricorrenti di Private CA o NAT.
Per dimostrazioni intermittenti o pilot conservati, un modello operativo pilot-light con controlli può fermare domain controller e fleet, rimuovere NAT e Private CA sostituibili, e conservare foresta, immagine, stack, ancore di identità e distribuzione CRL. La promozione crea una nuova CA subordinate e ripete i test di accettazione.
Per quali scenari può essere utile?
Il modello è adatto alle organizzazioni che già considerano Entra il punto di autenticazione degli utenti, ma dipendono ancora da applicazioni Windows e identità AD. Può pubblicare un'applicazione controllata via browser o client mantenendo esecuzione, accesso ai dati e policy Windows nell'ambiente AWS.
Computer On Site progetta questo percorso di identità attorno al tenant Entra, ad Active Directory, alle applicazioni, ai controlli di rete e al modello operativo di ogni cliente.
Non è la risposta predefinita per ogni carico. Le applicazioni cloud native possono non avere bisogno di una sessione AD. Un desktop completo può essere più adatto a chi richiede uno spazio persistente. Periferiche, latenza, licenze e grafica vanno provate con utenti e dati reali.
I nostri servizi cloud workspace coprono questa valutazione più ampia: identità, applicazioni, rete, storage, sicurezza, esperienza utente, operazioni e costi.
Che cosa deve cambiare prima della produzione?
La configurazione minima di riferimento non è un blueprint di produzione. Un ambiente operativo dovrebbe usare almeno due domain controller in Availability Zone diverse, ruoli PKI di lunga durata separati, pubblicazione della revoca ridondata e monitorata, backup e ripristino approvati, confini amministrativi più rigidi e test di concorrenza e scaling.
Va definita anche la responsabilità operativa. Qualcuno deve possedere applicazione Entra, ruolo IAM, identità AD, ciclo di vita della CA, fallback, conservazione delle prove e risposta agli incidenti. Il design è completo solo quando queste responsabilità sono esplicite.
Domande frequenti
La CBA elimina tutte le password?
Elimina la richiesta della password AD dalla sessione WorkSpaces Applications. L'utente continua ad autenticarsi con l'identity provider SAML, come Microsoft Entra ID, secondo le policy di accesso e MFA dell'organizzazione.
L'applicazione Windows riceve ancora un'identità AD?
Sì. Il certificato di breve durata viene presentato tramite smart card virtuale e associato all'utente AD sincronizzato. La validazione deve controllare il token Windows risultante, non solo l'avvio dell'applicazione.
Perché l'accesso alla CRL fa parte dei test?
Windows deve poter controllare la validità della catena. AWS richiede che il punto di distribuzione CRL sia raggiungibile dal domain controller e dalla fleet. Un CDP errato o bloccato può interrompere la CBA anche con SAML corretto.
L'architettura di riferimento è pronta per la produzione?
Non così com'è. Una dimostrazione minima può usare un solo domain controller, un ruolo AD CS multifunzione e capacità limitata. La produzione richiede ridondanza, separazione dei ruoli, monitoraggio, security review, test di carico e rollback provato.
Trasforma un'idea di identità in un pilot verificato
Il valore della soluzione non è solo una finestra applicativa senza password AD. È un metodo ripetibile per verificare insieme identità, fiducia dei certificati, revoca, capacità, fallback e ripristino.
Computer On Site può progettare e validare un pilot AWS per applicazioni o desktop attorno a identità, software e requisiti operativi reali. Parlaci di un assessment AWS workspace.