Transizione verso il cloud
Dopo aver allineato l'organizzazione verso l'interruzione della crescita del footprint di Active Directory, è possibile concentrarsi sullo spostamento dei carichi di lavoro locali esistenti in Microsoft Entra ID. Questo articolo descrive i vari flussi di lavoro di migrazione. È possibile eseguire i flussi di lavoro in questo articolo in base alle priorità e alle risorse.
Un flusso di lavoro di migrazione tipico prevede le fasi seguenti:
Scopri: scoprire cosa è attualmente presente nell'ambiente.
Pilota: distribuire nuove funzionalità cloud in un piccolo subset di utenti, applicazioni o dispositivi, a seconda del flusso di lavoro.
Scalabilità orizzontale: espandere il progetto pilota per completare la transizione di una funzionalità al cloud.
Eseguire il cutover (quando applicabile):arrestare l'uso del carico di lavoro locale precedente.
Utenti e gruppi
Abilita password self-service
È consigliabile un ambiente senza password. Fino ad allora, è possibile eseguire la migrazione dei flussi di lavoro self-service delle password dai sistemi locali a Microsoft Entra ID per semplificare l'ambiente. La reimpostazione della password self-service di Microsoft Entra consente agli utenti di cambiare o reimpostare la password, senza intervento dell'amministratore o dell'help desk.
Per abilitare le funzionalità self-service, scegliere i metodi di autenticazione appropriati per l'organizzazione. Dopo aver aggiornato i metodi di autenticazione, è possibile abilitare la funzionalità password self-service dell'utente per l'ambiente di autenticazione Microsoft Entra. Per indicazioni sulla distribuzione, vedere Considerazioni sulla distribuzione per la reimpostazione della password self-service di Microsoft Entra.
Altre considerazioni includono:
- Distribuire Microsoft Entra Password Protection in un subset di controller di dominio con modalità Audit per raccogliere informazioni sull'impatto dei criteri moderni.
- Abilitare gradualmente la registrazione combinata per la reimpostazione della password self-service e l'autenticazione a più fattori Microsoft Entra. Ad esempio, implementare in base all'area, alla filiale o al reparto per tutti gli utenti.
- Passare attraverso un ciclo di modifica della password per tutti gli utenti per scaricare password deboli. Al termine del ciclo, implementare l'ora di scadenza dei criteri.
- Cambiare la configurazione di Protezione password nei controller di dominio con la modalità impostata su Applicato. Per altre informazioni, vedere Abilitare la protezione password di Microsoft Entra locale.
Nota
- È consigliabile usare le comunicazioni degli utenti e l'evangelizzazione per una distribuzione senza problemi. Vedere Esempi di materiali di implementazione della reimpostazione della password self-service.
- Se si usa Microsoft Entra ID Protection, abilitare la reimpostazione della password come controllo nei criteri di Accesso condizionale per gli utenti contrassegnati come rischiosi.
Spostare la gestione dei gruppi
Per trasformare gruppi e liste di distribuzione:
Per i gruppi di sicurezza, usare la logica di business esistente che assegna gli utenti ai gruppi di sicurezza. Eseguire la migrazione della logica e della funzionalità a Microsoft Entra ID e ai gruppi di appartenenza dinamica.
Per le funzionalità del gruppo autogestito fornite da Microsoft Identity Manager, sostituire la funzionalità con la gestione dei gruppi self-service.
È possibile convertire le liste di distribuzione in gruppi di Microsoft 365 in Outlook. Questo approccio è un ottimo modo per offrire alle liste di distribuzione dell'organizzazione tutte le funzionalità e le funzionalità dei gruppi di Microsoft 365.
Aggiornare le liste di distribuzione ai gruppi di Microsoft 365 in Outlook e rimuovere le autorizzazioni del server Exchange locale.
Spostare il provisioning di utenti e gruppi nelle applicazioni
È possibile semplificare l'ambiente rimuovendo i flussi di provisioning delle applicazioni dai sistemi di gestione delle identità (IDM) locali, ad esempio Microsoft Identity Manager. In base all'individuazione dell'applicazione, classificare l'applicazione in base alle caratteristiche seguenti:
Applicazioni nell'ambiente che dispongono di un'integrazione del provisioning con la raccolta di applicazioni Microsoft Entra.
Applicazioni che non sono nella raccolta, ma supportano il protocollo SCIM 2.0. Queste applicazioni sono compatibili in modo nativo con il servizio di provisioning cloud Microsoft Entra.
Applicazioni locali con un connettore ECMA disponibile. Queste applicazioni possono essere integrate con il provisioning di applicazioni locali di Microsoft Entra.
Per altre informazioni, vedere Pianificare una distribuzione automatica del provisioning utenti per Microsoft Entra ID.
Passare al provisioning delle risorse umane nel cloud
È possibile ridurre il footprint locale spostando i flussi di lavoro di provisioning delle risorse umane da sistemi IDM locali, ad esempio Microsoft Identity Manager, a Microsoft Entra ID. Per il provisioning delle risorse umane cloud Microsoft Entra sono disponibili due tipi di account:
Per i nuovi dipendenti che usano esclusivamente applicazioni che usano Microsoft Entra ID, è possibile scegliere di effettuare il provisioning di account cloud-only. Questo provisioning consente di contenere il footprint di Active Directory.
Per i nuovi dipendenti che devono accedere alle applicazioni con dipendenza da Active Directory, è possibile effettuare il provisioning di account ibridi.
Il provisioning delle risorse umane cloud di Microsoft Entra può anche gestire gli account Active Directory per i dipendenti esistenti. Per altre informazioni, vedere Pianificare l'applicazione HR cloud per il provisioning di utenti di Microsoft Entra e Pianificare il progetto di distribuzione.
Sposta flussi di lavoro del ciclo di vita
Valutare i flussi di lavoro e i processi di persona che si unisce/persona che si sposta/persona che abbandona esistenti per l'applicabilità e la pertinenza per l'ambiente cloud Microsoft Entra. È quindi possibile semplificare questi flussi di lavoro e crearne di nuovi usando i flussi di lavoro del ciclo di vita.
Spostare la gestione delle identità esterne
Se l'organizzazione effettua il provisioning degli account in Active Directory o in altre directory locali per identità esterne, ad esempio fornitori, terzisti o consulenti, è possibile semplificare l'ambiente gestendo gli oggetti utente di terze parti in modo nativo nel cloud. Ecco alcune possibili motivazioni:
Per i nuovi utenti esterni, usare Microsoft Entra External ID, che arresta il footprint di Active Directory degli utenti.
Per gli account Active Directory esistenti di cui si effettua il provisioning per le identità esterne, è possibile rimuovere il sovraccarico di gestione delle credenziali locali (ad esempio, password) configurandoli per la collaborazione business-to-business (B2B). Seguire la procedura descritta in Invitare utenti interni alla Collaborazione B2B.
Usare la Gestione entitlement di Microsoft Entra per concedere l'accesso alle applicazioni e alle risorse. La maggior parte delle aziende dispone di sistemi e flussi di lavoro dedicati per questo scopo che è ora possibile uscire da strumenti locali.
Usare le verifiche degli accessi per rimuovere i diritti di accesso e/o le identità esterne non più necessarie.
Dispositivi
Spostare workstation non Windows
È possibile integrare workstation non Windows con Microsoft Entra ID per migliorare l'esperienza utente e sfruttare le funzionalità di sicurezza basate sul cloud, ad esempio l'Accesso condizionale.
Per macOS:
Registrare macOS in Microsoft Entra ID e registrarli/gestirli usando una soluzione di gestione dei dispositivi mobili.
Distribuire il plug-in Microsoft Enterprise SSO (Single Sign-On) per i dispositivi Apple.
Pianificare la distribuzione dell'accesso Single Sign-On della piattaforma per macOS 13.
Per Linux, è possibile accedere a una macchina virtuale Linux usando le credenziali di Microsoft Entra.
Sostituire altre versioni di Windows per le workstation
Se sono presenti i sistemi operativi seguenti nelle workstation, è consigliabile eseguire l'aggiornamento alle versioni più recenti per trarre vantaggio dalla gestione nativa del cloud (aggiunta a Microsoft Entra e gestione unificata degli endpoint):
Windows 7 o 8.x
Server Windows
Soluzione VDI
Questo progetto ha due iniziative principali:
Nuove distribuzioni: distribuire una soluzione VDI (Virtual Desktop Infrastructure) gestita dal cloud, ad esempio Windows 365 o Desktop virtuale Azure, che non richiede Active Directory locale.
Distribuzioni esistenti: se la distribuzione VDI esistente dipende da Active Directory, usare obiettivi aziendali e obiettivi per determinare se mantenere la soluzione o eseguirne la migrazione a Microsoft Entra ID.
Per altre informazioni, vedi:
Applicazioni
Per mantenere un ambiente sicuro, Microsoft Entra ID supporta protocolli di autenticazione moderni. Per eseguire la transizione dell'autenticazione dell'applicazione da Active Directory a Microsoft Entra ID, è necessario:
Determinare quali applicazioni possono eseguire la migrazione a Microsoft Entra ID senza alcuna modifica.
Determinare le applicazioni con un percorso di aggiornamento che consente di eseguire la migrazione con un aggiornamento.
Determinare le applicazioni che richiedono modifiche di codice sostitutive o significative per la migrazione.
Il risultato dell'iniziativa di individuazione delle applicazioni consiste nel creare un elenco con priorità per la migrazione del portfolio di applicazioni. L'elenco contiene applicazioni che:
Richiedere un aggiornamento o un aggiornamento al software ed è disponibile un percorso di aggiornamento.
Richiedere un aggiornamento o un aggiornamento al software, ma un percorso di aggiornamento non è disponibile.
Usando l'elenco, è possibile valutare ulteriormente le applicazioni che non hanno un percorso di aggiornamento esistente. Determinare se il valore aziendale garantisce l'aggiornamento del software o se deve essere ritirato. Se il software deve essere ritirato, decidere se è necessaria una sostituzione.
In base ai risultati, è possibile riprogettare gli aspetti della trasformazione da Active Directory a Microsoft Entra ID. Esistono approcci che è possibile usare per estendere Active Directory locale all'infrastruttura distribuita come servizio di Azure (IaaS) (lift-and-shift) per le applicazioni con protocolli di autenticazione non supportati. È consigliabile impostare un criterio che richiede un'eccezione per usare questo approccio.
Individuazione delle applicazioni
Dopo aver segmentato il portfolio di app, è possibile classificare in ordine di priorità la migrazione in base al valore aziendale e alla priorità aziendale. Puoi usare gli strumenti per creare o aggiornare l'inventario delle app.
Esistono tre modi principali per classificare le app:
App di autenticazione moderna: queste applicazioni usano protocolli di autenticazione moderni (ad esempio OIDC, OAuth2, SAML o WS-Federation), o che usano un servizio federativo come Active Directory Federation Services (AD FS).
Strumenti di gestione degli accessi Web (WAM): queste applicazioni usano intestazioni, cookie e tecniche simili per l'accesso SSO. Queste app richiedono in genere un provider di identità WAM, ad esempio Symantec SiteMinder.
App legacy: queste applicazioni usano protocolli legacy come Kerberos, LDAP, Radius, Desktop remoto e NTLM (scelta non consigliata).
Microsoft Entra ID può essere usato con ogni tipo di applicazione per offrire livelli di funzionalità che comportano diverse strategie di migrazione, complessità e compromessi. Alcune organizzazioni hanno un inventario delle applicazioni che è possibile usare come baseline di individuazione. (è comune che questo inventario non sia completo o aggiornato).
Per individuare le app di autenticazione moderne:
Se si usa AD FS, usare il report attività dell'applicazione AD FS.
Se si usa un provider di identità diverso, usare i log e la configurazione.
Gli strumenti seguenti consentono di individuare applicazioni che usano LDAP:
Event1644Reader: strumento di esempio per la raccolta di dati sulle query LDAP eseguite nei controller di dominio usando i log di progettazione dei campi.
Microsoft 365 Defender per identità: soluzione di sicurezza che usa una funzionalità di monitoraggio delle operazioni di accesso. (si noti che acquisisce le associazioni tramite LDAP, non LDAP sicuro).
PSLDAPQueryLogging: strumento GitHub per la creazione di report sulle query LDAP.
Eseguire la migrazione di AD FS o di altri servizi federativa
Quando si pianifica la migrazione a Microsoft Entra ID, è consigliabile eseguire prima la migrazione delle app che usano protocolli di autenticazione moderni (ad esempio SAML e OpenID Connect). È possibile riconfigurare queste app per l'autenticazione con Microsoft Entra ID tramite un connettore predefinito dalla raccolta di app di Azure o tramite registrazione in Microsoft Entra ID.
Dopo aver spostato le applicazioni SaaS federate in Microsoft Entra ID, è necessario eseguire alcuni passaggi per rimuovere le autorizzazioni del sistema federativo locale:
Spostare l’autenticazione dell'applicazione a Microsoft Entra ID
Eseguire la migrazione dalla federazione all'autenticazione cloud
Spostare l'accesso remoto alle applicazioni interne, se si usa Microsoft Entra Application Proxy
Importante
Se si usano altre funzionalità, verificare che tali servizi vengano spostati prima di rimuovere Active Directory Federation Services.
Spostare le app di autenticazione WAM
Questo progetto è incentrato sulla migrazione della funzionalità SSO dai sistemi WAM a Microsoft Entra ID. Per altre informazioni, vedere Eseguire la migrazione di applicazioni da Symantec SiteMinder a Microsoft Entra ID.
Definire una strategia di gestione del server applicazioni
In termini di gestione dell'infrastruttura, gli ambienti locali usano spesso una combinazione di oggetti Criteri di gruppo (GPO) e funzionalità di Microsoft Configuration Manager per segmentare i compiti di gestione. Ad esempio, i compiti possono essere segmentati nella gestione dei criteri di sicurezza, nella gestione degli aggiornamenti, nella gestione della configurazione e nel monitoraggio.
Active Directory è per gli ambienti IT locali e Microsoft Entra ID è per gli ambienti IT basati sul cloud. La parità di funzionalità uno-a-uno non è presente qui, quindi è possibile gestire i server applicazioni in diversi modi.
Ad esempio, Azure Arc consente di riunire molte delle funzionalità presenti in Active Directory in un'unica visualizzazione quando si usa Microsoft Entra ID per la gestione delle identità e degli accessi (IAM). È anche possibile usare Microsoft Entra Domain Service per i server aggiunti a un dominio in Microsoft Entra ID, soprattutto quando si desidera che tali server usino oggetti Criteri di gruppo per motivi aziendali o tecnici specifici.
Usare la tabella seguente per determinare gli strumenti basati su Azure che è possibile usare per sostituire l'ambiente locale:
| Area di gestione | Funzione (Active Directory) locale | Funzionalità equivalente di Microsoft Entra |
|---|---|---|
| Gestione dei criteri di sicurezza | Oggetto Criteri di gruppo, Microsoft Configuration Manager | Microsoft 365 Defender per il cloud |
| Gestione aggiornamenti | Microsoft Configuration Manager, Windows Server Update Services | Automazione di Azure - Gestione aggiornamenti |
| Gestione della configurazione | Oggetto Criteri di gruppo, Microsoft Configuration Manager | State Configuration di Automazione di Azure |
| Monitoraggio | System Center Operations Manager | Monitoraggio di Azure: Log Analytics |
Di seguito sono riportate altre informazioni che è possibile usare per la gestione del server applicazioni:
Azure Arc abilita le funzionalità di Azure per le macchine virtuali non di Azure. Ad esempio, è possibile usarlo per ottenere le funzionalità di Azure per Windows Server quando viene usato in locale o in Amazon Web Services, oppure eseguire l'autenticazione in computer Linux con SSH.
Gestire e proteggere l'ambiente di macchine virtuali di Azure.
Se è necessario attendere la migrazione o eseguire una migrazione parziale, è possibile usare oggetti Criteri di gruppo con Microsoft Entra Domain Services.
Se è necessaria la gestione dei server applicazioni con Microsoft Configuration Manager, non è possibile ottenere questo requisito usando Microsoft Entra Domain Services. Microsoft Configuration Manager non è supportato per l'esecuzione in un ambiente Microsoft Entra Domain Services. È invece necessario estendere l'istanza di Active Directory locale a un controller di dominio in esecuzione in una macchina virtuale di Azure. In alternativa, è necessario distribuire una nuova istanza di Active Directory in una rete virtuale IaaS di Azure.
Definire la strategia di migrazione per le applicazioni legacy
Le applicazioni legacy hanno dipendenze simili a quelle di Active Directory:
Autenticazione e autorizzazione utente: Kerberos, NTLM, associazione LDAP, ACL.
Accesso ai dati della directory: query LDAP, estensioni dello schema, lettura/scrittura di oggetti directory.
Gestione del server: come determinato dalla strategia di gestione del server.
Per ridurre o eliminare tali dipendenze, sono disponibili tre approcci principali.
Approccio 1
Nell'approccio più preferito si esegue la migrazione di progetti da applicazioni legacy a alternative SaaS che usano l'autenticazione moderna. Fare in modo che le alternative SaaS eseguano direttamente l'autenticazione a Microsoft Entra ID:
Distribuire Microsoft Entra Domain Services in una rete virtuale di Azure ed estendere lo schema per incorporare attributi aggiuntivi necessari per le applicazioni.
Trasferire in modalità lift-and-shift le app legacy alle macchine virtuali nella rete virtuale di Azure aggiunte a Microsoft Entra Domain Service.
Pubblicare app legacy nel cloud usando Microsoft Entra Application Proxy o un partner di accesso ibrido sicuro.
Quando le app legacy si ritirano attraverso l'attrito, alla fine rimuovere i Microsoft Entra Domain Service in esecuzione nella rete virtuale di Azure.
Nota
- Usare Microsoft Entra Domain Services se le dipendenze sono allineate agli scenari di distribuzione comuni per Microsoft Entra Domain Services.
- Per verificare se Microsoft Entra Domain Services è adatto, è possibile utilizzare strumenti come Azure Monitor VM Insights [https://learn.microsoft.com/azure/azure-monitor/vm/vminsights-overview].
- Verificare che le istanze di SQL Server possano essere migrate a un dominio differente. Se il servizio SQL è in esecuzione in macchine virtuali, usare queste indicazioni.
Approccio 2
Se il primo approccio non è possibile e un'applicazione ha una forte dipendenza da Active Directory, è possibile estendere Active Directory locale ad Azure IaaS.
È possibile riformare per supportare l'hosting serverless moderno, ad esempio usare la piattaforma distribuita come servizio (PaaS). In alternativa, è possibile aggiornare il codice per supportare l'autenticazione moderna. È anche possibile abilitare l'integrazione dell'app con Microsoft Entra ID direttamente. Informazioni su Microsoft Authentication Library in Microsoft Identity Platform.
Connettere una rete virtuale di Azure alla rete locale tramite la rete privata virtuale (VPN) o Azure ExpressRoute.
Distribuire nuovi controller di dominio per l'istanza di Active Directory locale come macchine virtuali nella rete virtuale di Azure.
Trasferire in modalità lift-and-shift le app legacy alle macchine virtuali nella rete virtuale di Azure aggiunte a un dominio.
Pubblicare app legacy nel cloud usando Microsoft Entra Application Proxy o un partner di accesso ibrido sicuro.
Infine, rimuovere completamente l'infrastruttura di Active Directory locale ed eseguire Active Directory nella rete virtuale di Azure.
Quando si ritirano le app legacy tramite attrito, rimuovere l'istanza di Active Directory in esecuzione nella rete virtuale di Azure.
Approccio 3
Se la prima migrazione non è possibile e un'applicazione ha una dipendenza forte da Active Directory, è possibile distribuire una nuova istanza di Active Directory in Azure IaaS. Lasciare le applicazioni legacy per il prossimo futuro o chiuderle quando si verifica l'opportunità.
Questo approccio consente di separare l'app dall'istanza di Active Directory esistente per ridurre la superficie di attacco. È consigliabile considerarla solo come ultima risorsa.
Distribuire una nuova istanza di Active Directory come macchine virtuali in una rete virtuale di Azure.
Trasferire in modalità lift-and-shift le app legacy alle macchine virtuali nella rete virtuale di Azure aggiunte a un dominio alla nuova istanza di Active Directory.
Pubblicare app legacy nel cloud usando Microsoft Entra Application Proxy o un partner di accesso ibrido sicuro.
Quando si ritirano le app legacy tramite attrito, rimuovere l'istanza di Active Directory in esecuzione nella rete virtuale di Azure.
Confronto tra strategie
| Strategia | Servizi di dominio Microsoft Entra | Estendere Active Directory a IaaS | Istanza di Active Directory indipendente in IaaS |
|---|---|---|---|
| Disaccoppiamento da Active Directory locale | Sì | No | Sì |
| Consenti estensioni dello schema | No | Sì | Sì |
| Controllo amministrativo completo | No | Sì | Sì |
| Potenziale riconfigurazione delle app necessarie (ad esempio, ACL o autorizzazione) | Sì | No | Sì |
Spostare l'autenticazione VPN
Questo progetto è incentrato sullo spostamento dell'autenticazione VPN in Microsoft Entra ID. È importante tenere presente che sono disponibili configurazioni diverse per le connessioni del gateway VPN. È necessario determinare la configurazione più adatta alle proprie esigenze. Per altre informazioni sulla progettazione di una soluzione, vedere Progettazione di gateway VPN.
Ecco i punti chiave sull'utilizzo di Microsoft Entra ID per l'autenticazione VPN:
Controllare se i provider VPN supportano l'autenticazione moderna. Ad esempio:
Per i dispositivi Windows 10, è consigliabile integrare il supporto di Microsoft Entra nel client VPN predefinito.
Dopo aver valutato questo scenario, è possibile implementare una soluzione per rimuovere la dipendenza con l'ambiente locale per l'autenticazione in VPN.
Spostare l'accesso remoto alle applicazioni interne
Per semplificare l'ambiente, è possibile usare Microsoft Entra Application Proxy o i partner di accesso ibrido sicuro per fornire l'accesso remoto. In questo modo è possibile rimuovere la dipendenza da soluzioni proxy inversa locali.
È importante ricordare che l'abilitazione dell'accesso remoto a un'applicazione tramite le tecnologie precedenti è un passaggio provvisorio. È necessario eseguire altre operazioni per separare completamente l'applicazione da Active Directory.
Microsoft Entra Domain Services consente di eseguire la migrazione dei server applicazioni al cloud IaaS e disaccoppiarsi da Active Directory, usando Microsoft Entra Application Proxy per abilitare l'accesso remoto. Per altre informazioni su questo scenario, vedere Implementare Microsoft Entra Application Proxy per Microsoft Entra Domain Services.