Strumento SPMigrateUsers per la modifica delle identità account in SharePoint 2010

Articolo originale pubblicato domenica 3 giugno 2012

A volte in SharePoint può essere necessario modificare l'identità di un account. Un esempio ideale è rappresentato dalle attestazioni SAML. In tutti i miei esempi uso l'indirizzo di posta elettronica come attestazione d'identità per gli utenti perché a) quasi tutti hanno un indirizzo di posta elettronica e b) quasi tutti capiscono cosa sia un indirizzo di posta elettronica. A volte però ho dei dubbi sull'uso dell'indirizzo di posta elettronica poiché gli utenti possono modificarlo e, in tal caso, perderebbero tutte le autorizzazioni. In realtà questo non è uno scenario frequente, altrimenti non userei affatto l'indirizzo di posta elettronica. Tuttavia raramente succede, e che si fa quando tutto quello che riguarda SharePoint è protetto mediante gli indirizzi di posta elettronica?

La soluzione è contenuta in un post di blog che in passato ho pubblicato in merito all'interfaccia IMigrateUserCallback:  https://blogs.msdn.com/b/sharepoint_it/archive/2011/03/09/migrazione-di-account-utente-dalle-attestazioni-di-windows-ad-attestazioni-saml.aspx. In tale post ho descritto come eseguire la migrazione delle identità usando questa interfaccia e ho fornito un esempio di come convertire un'identità basata sulle attestazioni Windows in un'identità basata su attestazioni SAML. Ho deciso di creare una piccola applicazione per Windows che consente di immettere le credenziali da modificare ed esegue automaticamente la modifica. Lo scopo di questa applicazione è di essere usata come uno strumento specifico per apportare queste modifiche. È tuttavia possibile usare il codice sorgente (che includo nel post) e modificarlo in modo da eseguire operazioni più creative, come leggere un elenco di utenti da un file o un database ed eseguire manualmente i confronti.

Questo strumento ha anche il vantaggio di poter essere usato per più scenari. Potete quindi usarlo non solo per convertire un indirizzo di posta elettronica in un altro, ma anche per convertire un nome di gruppo in un altro. Questo è un altro caso in cui spesso mi sento dire che dovrei usare i SID per i nomi di gruppo, ovvero le attestazioni di ruolo in SAML, poiché se si rinomina il gruppo, il SID resta lo stesso. Sebbene ciò sia vero, a) non mi capita spesso di riscontrare questa situazione, b) nessuno vuole dover digitare i nomi di gruppo SID e aggiungerli ai gruppi SharePoint e c) i SID non hanno alcun significato al di fuori dell'istanza locale di Active Directory, non appena passate a un servizio basato sul cloud come Azure, Google, Yahoo, Facebook e così via, il SID sarà inutile.

Un altro aspetto positivo di questo strumento è che non obbliga ad apportare le modifiche con un solo tipo di provider. Volete modificare un gruppo di Windows in un'attestazione di ruolo SAML? Potete farlo. Volete modificare un'attestazione d'identità SAML in un utente di appartenenza FBA? Potete farlo. Volete modificare un ruolo FBA in un gruppo AD? Potete fare anche questo. Ho provato praticamente qualsiasi combinazione di “utenti” e “gruppi” diversi tra vari provider e finora tutti possono essere convertiti senza problemi.

Lo strumento è molto facile da usare, eccone un'immagine:

Al primo avvio dell'applicazione viene caricato un elenco di tutte le applicazioni Web. Per ogni applicazione Web popola le due caselle combinate seguenti con un elenco di tutti i provider usati per tale applicazione Web. Se avete più provider SAML o FBA, ognuno verrà elencato nell'elenco a discesa. Scegliete semplicemente il provider da cui volete eseguire la migrazione e quello di destinazione. Nella sezione del valore di attestazione immettete il valore che volete migrare e il valore di destinazione della migrazione. Immettete il valore nei campi di modifica del valore di testo normale e fate clic sul pulsante dell'attestazione d'identità (a sinistra) o sul pulsante dell'attestazione di gruppo (a destra). La descrizione nel testo offre una spiegazione completa e il testo sui pulsante cambia in base al provider di identità usato.

Ad esempio, supponete di usare solo l'autenticazione SAML e di voler migrare l'indirizzo di posta elettronica “steve@contoso.com” in “stevep@contoso.com”. Scegliendo l'applicazione Web, il provider di autenticazione SAML viene selezionato per impostazione predefinita in ogni elenco a discesa. Nella sezione Before Values dovete quindi digitare “steve@contoso.com” nella casella di modifica Plain Text Value e fare clic sul pulsante ID Claim. In questo modo viene inserito il valore di attestazione codificato corretto nella casella di modifica Encoded Value. Digitate quindi “stevep@contoso.com” nella casella di modifica After Values Plain Text Value. Fate clic di nuovo sul pulsante ID Claim per inserire il valore corretto nella casella di modifica Encoded Value (NOTA: nella figura precedente il pulsante nella sezione After Values è “User” anziché “ID Claim” poiché in tale esempio si sta migrando da attestazioni SAML ad attestazioni Windows). Quando avete fornito tutti i valori, fate clic sul pulsante Migrate per completare il processo. Verrà visualizzata una finestra di messaggio in cui è indicato quando la migrazione è stata completata.

Nel processo di testing di questa soluzione per varie applicazioni Web e vari tipi di autenticazione diversi, ho riscontrato alcuni problemi che voglio segnalare qui nel caso che si ripresentino. In un caso ho ottenuto un messaggio di errore di accesso negato quando ho provato a migrare gli utenti da una specifica applicazione Web. Non sono mai riuscito a capire il motivo di questo errore, pertanto posso solo supporre che ci sia qualcosa di anomalo nell'app Web, ma non so cosa perché ha funzionato su tutte le altre app Web che ho provato nella farm.

La seconda considerazione è che in un caso la migrazione risultava completata correttamente ma non riuscivo ad accedere come l'utente migrato. Dopo alcune indagini ho scoperto che l'account che stavo migrando non veniva passato dalla funzione IMigrateUserCallback (si tratta di un problema di SharePoint, non di codifica dell'applicazione). Se si verifica questo problema, consiglio di usare il codice sorgente e Visual Studio per esaminare il debugger allo scopo di verificare che l'account che state migrando venga richiamato. Sfortunatamente un unico utente di appartenenza FBA è rimasto bloccato in un punto che non sono riuscito a identificare.

Un'ultima nota: non vi spaventate se eseguite la migrazione di un account da un valore a un altro, poi accedete come il nuovo utente e vedete le vecchie informazioni dell'account nel controllo Opzioni per nell'angolo in altro a destra della pagina. La funzione di migrazione modifica solo il nome dell'account. Se le altre informazioni utente vengono modificate, aggiornate i profili utente e le informazioni corrette verranno estese a tutte le raccolte siti durante la successiva sincronizzazione con il sistema dei profili.

Questo è tutto, spero possa esservi utile. Come dicevo, il codice sorgente completo è incluso, quindi usatelo e modificatelo come volete per il vostro scenario.

Questo è un post di blog localizzato. L'articolo originale è disponibile in The SPMigrateUsers Tool for Changing Account Identities in SharePoint 2010