Condividi tramite

Fase 5 della migrazione - Attività successive alla migrazione

  • Articolo

Usare le informazioni seguenti per la fase 5 della migrazione da AD RMS ad Azure Information Protection. Queste procedure illustrano i passaggi da 10 a 12 dalla migrazione da AD RMS ad Azure Information Protection.

Passaggio 10: Deprovisioning di AD RMS

Rimuovere il punto di Connessione servizio (SCP) da Active Directory per impedire ai computer di individuare l'infrastruttura Rights Management locale. Questa opzione è facoltativa per i client esistenti di cui è stata eseguita la migrazione a causa del reindirizzamento configurato nel Registro di sistema, ad esempio eseguendo lo script di migrazione. Tuttavia, la rimozione di SCP impedisce ai nuovi client e potenzialmente ai servizi e agli strumenti correlati a RMS di trovare SCP al termine della migrazione. A questo punto, tutte le connessioni computer devono passare al servizio Azure Rights Management.

Per rimuovere SCP, assicurarsi di aver eseguito l'accesso come amministratore dell'organizzazione di dominio e quindi seguire questa procedura:

  1. Nella console di Active Directory Rights Management Services fare clic con il pulsante destro del mouse sul cluster AD RMS e quindi scegliere Proprietà.

  2. Fare clic sulla scheda SCP .

  3. Selezionare la casella di controllo Cambia SCP .

  4. Selezionare Rimuovi SCP corrente e quindi fare clic su OK.

Monitorare ora i server AD RMS per l'attività. Ad esempio, controllare le richieste nel report Integrità sistema, la tabella ServiceRequest o controllare l'accesso utente al contenuto protetto.

Dopo aver verificato che i client RMS non comunicano più con questi server e che i client usano correttamente Azure Information Protection, è possibile rimuovere il ruolo del server AD RMS da questi server. Se si usano server dedicati, è consigliabile usare il passaggio con cautela prima di arrestare i server per un periodo di tempo. In questo modo è possibile assicurarsi che non siano presenti problemi segnalati che potrebbero richiedere il riavvio di questi server per la continuità del servizio durante l'analisi del motivo per cui i client non usano Azure Information Protection.

Dopo aver effettuato il deprovisioning dei server AD RMS, potrebbe essere necessario esaminare il modello e le etichette. Ad esempio, convertire i modelli in etichette, consolidarli in modo che gli utenti abbiano meno da scegliere o riconfigurarli. Questo sarebbe anche un buon momento per pubblicare i modelli predefiniti.

Per le etichette di riservatezza e il client di etichettatura unificata, usare il Portale di conformità di Microsoft Purview. Per altre informazioni, vedere la documentazione di Microsoft 365.

Importante

Al termine di questa migrazione, il cluster AD RMS non può essere usato con Azure Information Protection e l'opzione hold your own key (HYOK).

Configurazione aggiuntiva per i computer che eseguono Office 2010

Importante

Il supporto esteso di Office 2010 è terminato il 13 ottobre 2020. Per altre informazioni, vedere Versioni di Windows e Office legacy e AIP.

Se i client migrati eseguono Office 2010, gli utenti potrebbero riscontrare ritardi nell'apertura del contenuto protetto dopo il deprovisioning dei server AD RMS. In alternativa, gli utenti potrebbero visualizzare messaggi che non dispongono di credenziali per aprire il contenuto protetto. Per risolvere questi problemi, creare un reindirizzamento di rete per questi computer, che reindirizza il nome di dominio completo dell'URL AD RMS all'indirizzo IP locale del computer (127.0.0.1). A tale scopo, è possibile configurare il file host locale in ogni computer o tramite DNS.

  • Reindirizzamento tramite file host locali: aggiungere la riga seguente nel file hosts locale, sostituendo <AD RMS URL FQDN> con il valore per il cluster AD RMS, senza prefissi o pagine Web:

    127.0.0.1 <AD RMS URL FQDN>

  • Reindirizzamento tramite DNS: creare un nuovo record host (A) per il nome di dominio completo dell'URL di AD RMS, con l'indirizzo IP 127.0.0.1.

Passaggio 11: Completare le attività di migrazione client

Per i client di dispositivi mobili e i computer Mac: rimuovere i record SRV DNS creati durante la distribuzione dell'estensione del dispositivo mobile AD RMS.

Quando queste modifiche DNS sono state propagate, questi client individuano e iniziano automaticamente a usare il servizio Azure Rights Management. Tuttavia, i computer Mac che eseguono Office Mac memorizzano nella cache le informazioni da AD RMS. Per questi computer, questo processo può richiedere fino a 30 giorni.

Per forzare i computer Mac a eseguire immediatamente il processo di individuazione, nel keychain cercare "adal" ed eliminare tutte le voci ADAL. Eseguire quindi i comandi seguenti in questi computer:


rm -r ~/Library/Cache/MSRightsManagement

rm -r ~/Library/Caches/com.microsoft.RMS-XPCService

rm -r ~/Library/Caches/Microsoft\ Rights\ Management\ Services

rm -r ~/Library/Containers/com.microsoft.RMS-XPCService

rm -r ~/Library/Containers/com.microsoft.RMSTestApp

rm ~/Library/Group\ Containers/UBF8T346G9.Office/DRM.plist

killall cfprefsd

Quando tutti i computer Windows esistenti sono stati migrati ad Azure Information Protection, non esiste alcun motivo per continuare a usare i controlli di onboarding e mantenere il gruppo AIPMigrated creato per il processo di migrazione.

Rimuovere prima i controlli di onboarding e quindi eliminare il gruppo AIPMigrated e qualsiasi metodo di distribuzione software creato per distribuire gli script di migrazione.

Per rimuovere i controlli di onboarding:

  1. In una sessione di PowerShell connettersi al servizio Azure Rights Management e, quando richiesto, specificare le credenziali di amministratore globale:

    Connect-AipService

  2. Eseguire il comando seguente e immettere Y per confermare:

    Set-AipServiceOnboardingControlPolicy -UseRmsUserLicense $False

    Si noti che questo comando rimuove qualsiasi imposizione delle licenze per il servizio di protezione di Azure Rights Management, in modo che tutti i computer possano proteggere documenti e messaggi di posta elettronica.

  3. Verificare che i controlli di onboarding non siano più impostati:

    Get-AipServiceOnboardingControlPolicy

    Nell'output la licenza dovrebbe mostrare False e non è visualizzato alcun GUID per SecurityGroupOjbectId

Infine, se si usa Office 2010 ed è stata abilitata l'attività Gestione modelli di Criteri diritti AD RMS (automatizzata) nella libreria utilità di pianificazione di Windows, disabilitare questa attività perché non viene usata dal client Azure Information Protection.

Questa attività è in genere abilitata tramite Criteri di gruppo e supporta una distribuzione di AD RMS. È possibile trovare questa attività nel percorso seguente: Microsoft>Windows>Active Directory Rights Management Services Client.

Importante

Il supporto esteso di Office 2010 è terminato il 13 ottobre 2020. Per altre informazioni, vedere Versioni di Windows e Office legacy e AIP.

Passaggio 12: Reimpostare la chiave del tenant di Azure Information Protection

Questo passaggio è necessario al termine della migrazione se la distribuzione di AD RMS usava la modalità di crittografia RMS 1 perché questa modalità usa una chiave a 1024 bit e SHA-1. Questa configurazione è considerata un livello di protezione inadeguato. Microsoft non approva l'uso di lunghezze di chiave inferiori, ad esempio chiavi RSA a 1024 bit e l'uso associato di protocolli che offrono livelli di protezione inadeguati, ad esempio SHA-1.

La reimpostazione della chiave comporta la protezione che usa la modalità di crittografia RMS 2, che comporta una chiave a 2048 bit e SHA-256.

Anche se la distribuzione di AD RMS usava la modalità crittografia 2, è comunque consigliabile eseguire questo passaggio perché una nuova chiave consente di proteggere il tenant da potenziali violazioni della sicurezza alla chiave AD RMS.

Quando si reimposta la chiave del tenant di Azure Information Protection (nota anche come "rollover della chiave"), la chiave attualmente attiva viene archiviata e Azure Information Protection inizia a usare una chiave diversa specificata. Questa chiave diversa può essere una nuova chiave creata in Azure Key Vault o la chiave predefinita creata automaticamente per il tenant.

Il passaggio da una chiave a un'altra non avviene immediatamente, ma in poche settimane. Poiché non è immediato, non attendere fino a quando non si sospetta una violazione della chiave originale, ma eseguire questo passaggio non appena la migrazione è stata completata.

Per reimpostare la chiave del tenant di Azure Information Protection:

  • Se la chiave del tenant è gestita da Microsoft: eseguire il cmdlet di PowerShell Set-AipServiceKeyProperties e specificare l'identificatore della chiave per la chiave creata automaticamente per il tenant. È possibile identificare il valore da specificare eseguendo il cmdlet Get-AipServiceKeys . La chiave creata automaticamente per il tenant ha la data di creazione meno recente, quindi è possibile identificarla usando il comando seguente:

    (Get-AipServiceKeys) | Sort-Object CreationTime | Select-Object -First 1

  • Se la chiave del tenant è gestita dall'utente (BYOK): in Azure Key Vault ripetere il processo di creazione della chiave per il tenant di Azure Information Protection e quindi eseguire di nuovo il cmdlet Use-AipServiceKeyVaultKey per specificare l'URI per questa nuova chiave.

Per altre informazioni sulla gestione della chiave del tenant di Azure Information Protection, vedere Operazioni per la chiave del tenant di Azure Information Protection.

Passaggi successivi

Dopo aver completato la migrazione, esaminare la roadmap per la distribuzione di AIP per la classificazione, l'etichettatura e la protezione per identificare eventuali altre attività di distribuzione che potrebbe essere necessario eseguire.