Inside SharePointIntegrazione di directory di SharePoint

Pav Cherny

Download codice disponibile in: SharePoint2008_09.exe(2,775 KB)

Indice

Servizio di gestione directory di SharePoint
Servizio di gestione directory personalizzato
SharePoint e ILM
Conclusioni

Microsoft Windows SharePoint Services (WSS) 3.0 e Microsoft Office SharePoint Server (MOSS) 2007 comprendono funzionalità di sincronizzazione di directory sotto forma di un Servizio di gestione directory che può effettuare il provisioning degli oggetti di gruppo e dei contatti abilitati alla posta per le risorse di SharePoint in Active Directory. Il provisioning di questi tipi di

oggetti destinatario per risorse di SharePoint® permette agli utenti di selezionare le raccolte, gli elenchi ed i gruppi di SharePoint direttamente dalla Rubrica di Microsoft® Outlook® durante l'invio di documenti e di altre informazioni.

Gli oggetti destinatario SharePoint forniscono anche un modo per controllare il trasferimento di messaggi e le conversioni del formato in un'organizzazione Exchange Server. Tra l'altro, è possibile impedire ai mittenti non autenticati, come gli spammer, di inviare messaggi alle raccolte di SharePoint impostando le restrizioni di consegna dei messaggi in Active Directory®.

Tuttavia, le capacità di gestione della directory SharePoint sono limitate e, nel momento della stesura del presente articolo, Exchange Server 2003 viene considerato il sistema di messaggistica sottostante. Per ora, se si utilizza Exchange Server 2007 o un sistema di messaggistica di terze parti, è necessario estendere o sostituire le funzionalità di gestione directory incorporate con una soluzione personalizzata per conseguire il livello di interoperabilità desiderato.

In questo articolo esaminerò brevemente le funzionalità di gestione directory di SharePoint e discuterò poi un approccio per superare i limiti esistenti. La mia premessa è che il Servizio di gestione directory incorporato soddisfa soltanto i requisiti basilari dell'utente. Gli ambienti con una varietà di piattaforme di sistemi di messaggistica e di directory necessitano di maggiore flessibilità e funzionalità. Sostituendo il componente incorporato con una soluzione personalizzata, potrete sincronizzare le informazioni destinatario SharePoint con qualsiasi soluzione di directory che fornisca delle funzionalità di importazione o API.

Per dimostrarlo, vi mostrerò come sincronizzare le informazioni destinatario SharePoint in maniera compatibile con Exchange Server 2007. Allo stesso modo, potrete utilizzare una soluzione personalizzata per sincronizzare le informazioni destinatario con IBM Lotus Notes o con altri sistemi.

Avrete inoltre la possibilità di centralizzare i processi di provisioning della directory basata su un servizio di metadirectory, come l'Identity Information Server, incluso nel Feature Pack 1 (FP1) di Microsoft Identity Lifecycle Manager (ILM) 2007. In particolare, vi mostrerò come integrare SharePoint con ILM 2007 per coordinare il provisioning degli oggetti di directory per le librerie di documenti SharePoint. Potete trovare gli strumenti, il codice sorgente e le istruzioni dettagliate per creare questa soluzione nel materiale di accompagnamento di questo articolo, disponibile nella sezione di Code Download del .com.

Servizio di gestione directory di SharePoint

A differenza di Exchange Server, che utilizza Active Directory per quasi tutte le informazioni sulla configurazione e di destinatario, SharePoint si basa sui database di configurazione e di contenuti. SharePoint deve quindi propagare le informazioni destinatario per le raccolte, gli elenchi ed i gruppi abilitati alla posta dai database a una directory. Dopotutto, i client di messaggistica prevedono di trovare le informazioni destinatario in una rubrica, che solitamente è generata dagli oggetti di directory.

Subito disponibile, a tale scopo SharePoint include un Servizio di gestione directory, che fa parte del servizio Web di integrazione posta elettronica (Share­point­EmailWS.asmx) che è possibile configurare in Amministrazione Centrale SharePoint 3.0, nella pagina Operazioni, sotto la voce Impostazioni posta elettronica in arrivo. Figura 1 mostra il funzionamento del Servizio di gestione directory incorporato.

Figura 1 Architettura del Servizio di gestione directory di SharePoint (fare clic sull'immagine per ingrandirla)

Quando si attiva una Web farm per la gestione directory e poi si assegna un indirizzo di posta elettronica ad una raccolta, ad un elenco o ad un gruppo per ricevere i messaggi, come se si utilizzasse EmailSettings.aspx, si chiama implicitamente il servizio Web di integrazione posta elettronica per effettuare il provisioning degli oggetti destinatario corrispondenti in Active Directory. Primo, SharePoint memorizza le informazioni di indirizzo di posta elettronica nel database dei contenuti. Secondo, SharePoint invia la richiesta di provisioning al servizio Web di integrazione posta elettronica utilizzando l'identità dell'account pool di applicazioni Web. Se la richiesta di provisioning fallisce, avrete le informazioni di indirizzo di posta elettronica nel database dei contenuti, ma senza gli oggetti destinatario corrispondenti in Active Directory.

Risorse aggiuntive

• Sito Web di Prodotti e tecnologie SharePoint
• TechCenter di Windows SharePoint Services
• Centro per sviluppatori Windows SharePoint Services
• Blog del team prodotti e tecnologie Microsoft SharePoint

È possibile che le richieste di provisioning non siano completate correttamente per vari motivi. Il più comune è l'assenza di autorizzazioni per l'accesso al metabase IIS. Poiché SharePointEmail­WS.asmx è progettato per essere un servizio Web per gli account pool applicazioni, questo servizio Web controlla il metabase IIS per vedere se il chiamante è un account pool applicazioni e, in caso contrario, nega l'accesso senza badare al sito SharePoint ed ai livelli di autorizzazione Active Directory.

SharePointEmailWS.asmx esegue questo controllo dell'accesso con l'identità del chiamante, comunque, perciò l'account pool applicazioni della chiamata richiederà l'accesso al metabase per verificare le proprie autorizzazioni all'accesso. Questo obbliga a concedere autorizzazioni elevate agli account pool applicazioni per avere una buona riuscita.

Ovviamente, le autorizzazioni elevate su un server Web generano rischi per la sicurezza. Ci sono modi migliori per controllare l'accesso a un servizio Web ASP.NET. Inoltre, SharePoint prevede di trovare il Servizio di gestione directory nel sito Amministrazione centrale, ma questo sito è disponibile solo temporaneamente in una Web farm bloccata per ridurre la superficie di attacco. Così se si desidera utilizzare il Servizio di gestione directory incorporato nell'ambiente di produzione SharePoint, è necessario accettare una configurazione con bassi livelli di protezione.

Gli ulteriori limiti esistenti testimoniano come il Servizio di gestione directory incorporato sia basato su un'architettura client/server strettamente connessa. Microsoft.SharePoint.dll utilizza direttamente System.DirectoryServices.dll, dunque non è possibile implementare la logica per personalizzare il processo di provisioning. Ad esempio, l'implementazione del servizio di gestione directory incorporata non scrive tutti gli attributi destinatario per supportare Exchange Server 2007 e non esiste alcuna opzione per personalizzare le regole di generazione degli attributi.

L'impossibilità di implementare la propria logica implica anche che non è possibile personalizzare il processo di provisioning, ad esempio, per implementare le approvazioni personalizzate. SharePoint supporta i processi di approvazione per i gruppi, ma questa funzionalità è basata sul sito Amministrazione centrale. Soltanto gli amministratori della farm SharePoint possono approvare le richieste in sospeso, ma non è necessariamente compito loro approvare i processi di provisioning di Active Directory.

Cosa forse anche più importante, non esistono processi di approvazione per le raccolte documenti e gli elenchi abilitati alla posta abilitata. Se si attiva la gestione directory, fondamentalmente si concede a tutti gli amministratori nella Web farm il diritto di creare in Active Directory gruppi e contatti abilitati alla posta elettronica. Né è possibile strutturare una gestione destinatario basata su unità organizzative (OU), perché tutti gli oggetti destinatario per Web farm sono collocati nella stessa OU.

Non è possibile spostare gli oggetti destinatario in un'altra OU perché il Servizio di gestione directory prevede di trovare gli oggetti destinatario nell'OU SharePoint ed è necessario concedere all'account pool di applicazioni dell'Amministrazione centrale SharePoint le autorizzazioni amministrative in Active Directory. Inoltre, non c'è modo di implementare la sincronizzazione bidirezionale tra SharePoint e Active Directory. Una modifica degli attributi oggetto in Active Directory non consente la propagazione delle modifiche anche nell'ambiente SharePoint.

Servizio di gestione directory personalizzato

Avendo stabilito che il Servizio di gestione directory incorporato lascia un po' di spazio per creare della flessibilità aggiuntiva, vengono analizzate alcune alternative. La buona notizia è che SharePoint permette di implementare il servizio di gestione directory. È necessario solo registrare il servizio Web come Servizio di gestione directory remoto nell'Amministrazione Centrale SharePoint 3.0, nella pagina Operazioni, sotto la voce Impostazioni posta elettronica in arrivo.

Per le istruzioni dettagliate sulla distribuzione e registrazione ad un servizio Web personalizzato, vedere il foglio di lavoro "Integrazione directory basata su un Servizio di gestione directory personalizzato .xps" nel materiale di accompagnamento. Inoltre, il servizio Web personalizzato illustra come effettuare il provisioning di oggetti destinatario compatibili con Exchange Server 2007 in Active Directory senza strumenti di gestione cmdlet o Exchange. Il relativo codice sorgente si trova nella cartella EmailIntegrationService. Figura 2 mostra l'architettura della soluzione.

Figura 2 Architettura del Servizio di gestione directory personalizzato (fare clic sull'immagine per ingrandirla)

L'interfaccia del servizio Web personalizzato deve aderire all'interfaccia di Servizio di gestione directory, come documentato nell'SDK di SharePoint. Ricercando "SharePointEmailWS" nel sito Web MSDN® (msdn.microsoft.com) è possibile trovare tutte le informazioni necessarie. È, inoltre, possibile consultare il file Service.cs nella cartella EmailIntegrationService\App_Code nel materiale di accompagnamento. Questo file implementa l'interfaccia di servizio Web richiesta, mentre il codice effettivo di provisioning per gli oggetti Active Directory si trova in SPRecipient.cs. Ad esempio, la funzione UpdateRecipientAttributes in SPRecipient.cs genera gli attributi di Exchange Server 2007 richiesti. SPRecipient.cs è il file di codice da sostituire se si vuole sviluppare il proprio servizio di gestione directory personalizzato.

Un servizio di gestione directory personalizzato è un ottimo strumento per risolvere richieste di autorizzazioni elevate ed integrare SharePoint con sistemi di messaggistica o directory di terze parti. Non è necessario controllare il metabase IIS per limitare l'accesso del servizio Web agli account pool applicazioni. È, invece, possibile aggiungere una sezione <authorization> al file web.config del servizio Web (per un esempio, vedere il materiale di accompagnamento).

Persistono, tuttavia, alcuni problemi poiché non sarà possibile controllare se e quando SharePoint chiama il Servizio di gestione directory. Inoltre, SharePoint non chiama il Servizio di gestione directory quando si elimina un elenco o una raccolta di documenti abilitata alla posta e quindi un oggetto destinatario non valido rimane in Active Directory. Che si utilizzi il Servizio di gestione directory incorporato o una soluzione personalizzata, non è possibile garantire che le informazioni destinatario in Active Directory siano compatibili con le risorse SharePoint.

SharePoint e ILM

Per conseguire un'integrazione di directory affidabile, sarebbe opportuno distribuire un pacchetto di gestione directory professionale, come ILM. Questo sistema si basa su un modello di sincronizzazione di directory basato sul pull-model (o su richiesta). Gli agenti di gestione estraggono le informazioni dalle origini connesse, le importano in una metadirectory comune e da questa le esportano ai sistemi connessi. I sistemi di origine solitamente non inseriscono le informazioni nella metadirectory. Estraendo le informazioni, si ottiene certamente coerenza all'interno di ogni ciclo di sincronizzazione.

Un altro vantaggio è che la gestione del ciclo di vita delle informazioni (ILM) contiene diversi agenti di gestione per supportare Active Directory, Lotus Notes ed una serie di altri sistemi forniti con il prodotto. È necessario solo implementare un agente di gestione personalizzato per SharePoint al fine di sincronizzare le informazioni SharePoint con un'altra piattaforma di directory supportata nell'ambiente.

È necessario implementare la logica per recuperare le informazioni desiderate da SharePoint, salvare le informazioni in un file di importazione e trasferire le informazioni importate nella metadirectory. Ma non è necessario implementare la logica per esportare tali informazioni dalla metadirectory in Active Directory o in un'altra piattaforma di directory. Figura 3 illustra come implementare la sincronizzazione da SharePoint a Active Directory utilizzando ILM. È anche possibile conseguire la sincronizzazione nella direzione inversa per effettuare il provisioning delle risorse SharePoint per gli oggetti directory, anche se ciò può sembrare inutile o facoltativo.

Figura 3 Integrazione di directory basata su Identity Lifecycle Manager (fare clic sull'immagine per ingrandirla)

Un buon punto di partenza per sviluppare un agente di gestione SharePoint è rappresentato dall'articolo di Alex Tcherniakhovski "Connessione di ILM 2007 agli elenchi SharePoint Services" su blogs.msdn.com/alextch/archive/2007/09/02/wsslistsandilm.aspx. Alex mostra come creare una soluzione di gestione directory basata su ILM, fondata su richieste di provisioning basate su Infopath® presentate ad una raccolta documenti. L'agente di gestione di Alex recupera tutte le richieste approvate dalla raccolta documenti e crea gli oggetti metadirectory corrispondenti che possono quindi essere esportati nelle directory connesse.

Per impostazione predefinita, SharePoint non genera richieste di provisioning basate su Infopath quando un elenco o un gruppo è abilitato alla posta. Questo si ottiene attraverso un servizio di gestione directory personalizzato, ma poi si verificano dei problemi di coerenza menzionati in precedenza perché SharePoint non chiama il servizio di gestione directory in ogni circostanza. Per questa motivo, consiglio di far recuperare all'agente di gestione le informazioni destinatario di SharePoint desiderate direttamente dagli elenchi e dai gruppi nella raccolta siti. Se sono necessari dei processi di approvazione, è possibile generare richieste di provisioning basate su InfoPath per le nuove risorse nell'agente di gestione ed in seguito elaborare tutte le richieste approvate.

Sono disponibili diverse opzioni per recuperare le informazioni di SharePoint. È possibile leggere le informazioni direttamente dai database del contenuto, utilizzare il modello a oggetti SharePoint o sfruttare i servizi Web di SharePoint.

Sconsigliamo l'accesso diretto ai database del contenuto perché le strutture di database potrebbero cambiare nelle versioni successive, il che interromperebbe la soluzione di gestione directory.

Anche l'utilizzo diretto del modello a oggetti SharePoint nell'agente di gestione risulta difficile perché il modello a oggetti vi richiederà di eseguire il codice localmente, inoltre l'installazione di ILM su un server Web in ogni farm SharePoint dell'ambiente può complicare l'infrastruttura di gestione della directory.

Si possono utilizzare i servizi Web di SharePoint, ma ciò crea un'altra difficoltà poiché le informazioni desiderate non sono facilmente accessibili attraverso i servizi Web di SharePoint, come le informazioni di indirizzo di posta elettronica per i gruppi SharePoint o l'Indirizzo visualizzato server posta elettronica in arrivo.

Dunque, la cosa migliore sembrerebbe implementare un servizio Web di SharePoint personalizzato che utilizzi il modello a oggetti SharePoint per recuperare le informazioni desiderate, inoltrandole al chiamante sotto forma di documento XML. Ora potete centralizzare la distribuzione di ILM ed integrare un numero qualsiasi di farm e raccolte di siti attraverso richieste singole del servizio Web SharePoint personalizzato, come illustrato nella Figura 3.

C'è un ultimo aspetto che vale la pena menzionare, ossia che l'integrazione di directory basate su ILM non elimina il bisogno di un servizio di gestione directory personalizzato. Questo servizio personalizzato non deve eseguire alcuna operazione perché ILM effettua il provisioning degli oggetti directory, tuttavia è necessario fornire un servizio personalizzato in modo da attivare la gestione di directory in Amministrazione centrale di SharePoint 3.0. Altrimenti, ad esempio, in primo luogo, non si può essere in grado di assegnare gli indirizzi di posta elettronica ai gruppi. La Figura 4 illustra l'architettura della soluzione risultante.

Figura 4 Integrazione di directory SharePoint basata su Web Service (fare clic sull'immagine per ingrandirla)

È possibile rendere fittizio il servizio di gestione directory personalizzato incluso nel materiale di accompagnamento, impostando il parametro OpMode nel file web.config (<add key="OpMode" value="dummy"/>). In questa configurazione, il servizio personalizzato restituisce sempre OPERAZIONE COMPLETATA in risposta alle chiamate di provisioning senza eseguire alcuna operazione.

Inoltre, il servizio personalizzato presenta un metodo ResolveUsers che l'agente di gestione SharePoint può chiamare per scomporre i nomi dell'account utente basati su NetBIOS in nomi distinti, che è un passaggio obbligatorio nel provisioning dei gruppi. (SharePoint offre informazioni sull'appartenenza al gruppo sotto forma di elenco di nomi di account utente basati su NetBIOS, ma Active Directory prevede dei nomi distinti). Ed ecco il risultato. Per ulteriori informazioni su come distribuire la soluzione risultante, vedere "Configurazione di integrazione directory basata su ILM 2007.xps" nel materiale di accompagnamento.

WSS 3.0 e MOSS 2007 comprendono un Servizio di gestione directory per integrare SharePoint con Exchange Server 2003 per la collaborazione multipiattaforma basata su messaggistica.

Tuttavia, ciò presenta anche dei limiti. Gli utenti devono sostituire il Servizio di gestione directory incorporato con una soluzione personalizzata. Inoltre, è possibile utilizzare anche una soluzione di gestione directory professionale, come ILM, per integrare SharePoint in un'infrastruttura di gestione directory. Ciò fornisce il maggiore livello di flessibilità e consente di assicurare la coerenza delle informazioni all'interno di un modello di sincronizzazione basato su pull.

Pav Cherny è un esperto del settore IT ed autore specializzato in tecnologie Microsoft per la collaborazione e le comunicazioni unificate. Le sue pubblicazioni includono white paper, manuali di prodotti e libri su amministrazione del sistema e operazioni IT. Pav è Presidente di Biblioso Corporation, un'azienda specializzata in servizi di localizzazione e documentazione gestita.