Panoramica di alto livello su Active Directory Lightweight Directory Services (AD LDS) (it-IT)

L'originale di questo articolo è consultabile al seguente uri : Active Directory Lightweight Directory Services (AD LDS) Overview
*
Utilizzando il ruolo di Windows Server ® 2008 Active Directory ® Lightweight Directory Services (AD LDS), precedentemente noto come Active Directory Application Mode (ADAM), è possibile fornire servizi di directory per le applicazioni basate sull'uso di directory senza incorrere nel sovraccarico di domini e foreste o forzare esigenze di un singolo schema in una foresta 

Nelle sezioni che seguono, approfondiremo il ruolo del server AD LDS, le sue caratteristiche e le considerazioni di hardware e software per la sua installazione.

Cosa è il ruolo server AD LDS?

AD LDS è un servizio directory Lightweight Directory Access Protocol (LDAP) che fornisce un supporto flessibile per applicazioni basate su directory, senza i prerequisiti che sono necessarie per servizi di dominio Active Directory (AD DS). AD LDS fornisce gran parte della stessa funzionalità di un AD DS, ma non richiede l’implementazione di domini o controller di dominio. È possibile eseguire più istanze di AD LDS contemporaneamente su un singolo computer, con uno schema gestito in modo indipendente per ogni istanza di AD LDS.

AD DS fornisce servizi di directory sia per il sistema operativo Microsoft ® Windows Server che per applicazioni basate sull'uso di directory. Per il sistema operativo del server, AD DS memorizza informazioni critiche sulla infrastruttura di rete, gli utenti e i gruppi, i servizi di rete e così via. In questo ruolo, AD DS deve rispettare un singolo schema nel corso di un'intera foresta.

Il ruolo server AD LDS, d'altra parte, fornisce servizi in modo specifico per applicazioni basate sull'uso di directory. AD LDS non richiede e non si basa su domini Active Directory o foreste. Tuttavia, in ambienti dove esiste AD DS, AD LDS può usare Active Directory per l'autenticazione delle entità di protezione di Windows.

Quando dovrei utilizzare il ruolo server AD LDS?

Le seguenti sezioni descrivono comuni soluzioni di directory aziendali con AD LDS.

Fornire un archivio della directory aziendale

AD LDS è una vera e propria soluzione di directory LDAP per le imprese. Tutte le applicazioni aziendali basate sull'uso di directory possono utilizzare AD LDS come loro archivio directory.

AD LDS può memorizzare dati di directory "privata", che sono rilevanti solo per l'applicazione, in un servizio di directory locale — possibilmente sullo stesso server dell'applicazione — senza richiedere alcuna configurazione aggiuntiva alla directory del sistema operativo server. Questi dati, rilevanti solo per l'applicazione e che non devono essere ampiamente replicati, vengono memorizzati unicamente nella directory AD LDS che è associata con l'applicazione. Questa soluzione riduce il traffico di replica in rete tra controller di dominio che servono il servizio di directory del sistema operativo. Tuttavia, se necessario, è possibile configurare questi dati per replicarli tra più istanze di AD LDS.

Applicazioni aziendali spesso devono archiviare i dati di personalizzazione che sono associati con gli utenti autenticati in Active Directory. L’archiviazione dei dati sulla personalizzazione in AD DS richiederebbe modifiche dello schema di Active Directory. In questo scenario, un'applicazione può utilizzare AD LDS per archiviare i dati specifici dell'applicazione, come la politica e le informazioni di gestione, mentre utilizza le entità di protezione dell'utente in Active Directory per l'autenticazione e per il controllo dell'accesso agli oggetti in AD LDS. Tale soluzione rende inutile per ogni directory di AD LDS avere un proprio database utenti. Di conseguenza, questa soluzione impedisce una proliferazione di user ID e password per gli utenti finali ogni volta una nuova applicazione basate sull'uso si  directory è stata introdotta in rete.

Fornire uno store di autenticazione per una rete extranet

Si consideri l'esempio di un'applicazione con portale Web che gestisce l’accesso di una rete extranet ad applicazioni e servizi aziendali esterne alla directory aziendale. Un altro esempio potrebbe essere un scenario in cui un provider offre servizi di dominio e archiviazione dati ai propri clienti mantenendo e aggiornando server web o dati dedicati ai clienti, con persone non clienti abilitate all’accesso a tali server.

Questi server e applicazioni portale che sono installati in una rete extranet hanno esigenze di autenticazione personalizzate. Essi richiedono un archivio di autenticazione per salvare le informazioni di autorizzazione per le identità cui forniscono il servizio. AD LDS è un buon candidato per questo store di autenticazione perché esso può ospitare oggetti utente che non sono entità di protezione di Windows ma che possono essere autenticati con una semplice connessione LDAP. In altre parole, i client Web possono essere serviti da applicazioni nel portale  eseguite su qualsiasi piattaforma mentre utilizzano AD LDS come un semplice store di autenticazione LDAP.

Se un'applicazione portale collocata in una rete extranet deve dare servizio ad identità di sicurezza AD DS interne che attualmente si trovano all'esterno del firewall aziendale, è possibile ancora utilizzare AD LDS come store di autenticazione con le credenziali dell'account aziendale di queste identità esposte istanze sulla rete extranet  di AD LDS, come illustrato nella figura seguente.

http://i.technet.microsoft.com/cc754361.0947f2cf-215f-4748-89f8-d1079eba4f37(en-us,WS.10).gif

È inoltre possibile distribuire AD LDS come store di autenticazione in una rete extranet con Active Directory Federation Services (ADFS). Questa configurazione consente a tecnologie Web single sign-on (SSO) di autenticare gli utenti in più applicazioni Web con un unico account utente. Per ulteriori informazioni, vedere la Panoramica di alto livello Active Directory Federation Services (http://go.microsoft.com/fwlink/?LinkId = 95311 ).

Consolidare i sistemi di identità

Si può avere uno scenario in cui una restrizione del modello di dati, ad esempio una visualizzazione di una singola partizione  LDAP o una vista di singola unità organizzativa (OU), sono imposte ad una applicazione enterprise basate sull'uso di directory che deve accedere ai dati associati agli utenti autenticati, alle applicazioni o alle risorse di rete su AD DS,  che si trovano in più foreste, domini o unità organizzative all'interno dell'azienda. Le informazioni di identità per questa applicazione basate sull'uso di directory devono essere consolidate da più foreste di Active Directory, domini e unità organizzative o da più sistemi di identità e da altre directory, ad esempio i database delle risorse umane, i database SAP, Elenchi telefonici e così via.

AD LDS offre una soluzione di consolidamento directory perché è possibile distribuirlo insieme a una metadirectory. Le metadirectory, ad esempio Microsoft Identity Integration Server (MIIS) o Microsoft Identity Integration Feature Pack (IIFP) — che è una versione gratuita e leggera di MIIS, consente di fornire alle applicazioni basate su directory una visione unificata di tutte le informazioni di identità nota circa gli utenti aziendali, le applicazioni e le risorse di rete mediante l'esecuzione di integrazione di identità, sincronizzazione delle directory, creazione e annullamento di utenze e sincronizzazione delle password tra Active Directory ed AD LDS di rete, come mostrato nell'illustrazione seguente.

http://i.technet.microsoft.com/cc754361.9d90a342-2f21-4546-94af-afb8fb603aab(en-us,WS.10).gif

Fornire un ambiente di sviluppo per Active Directory e AD LDS

Perché AD LDS utilizza lo stesso modello di programmazione e fornisce praticamente la stessa esperienza di amministrazione di AD DS, può essere un buon campo di prova per gli sviluppatori che stanno progettando e sperimentando varie applicazioni integrate in Active Directory. Ad esempio, se un'applicazione in fase di sviluppo richiede uno schema diverso dall'attuale sistema operativo server AD DS, lo sviluppatore dell'applicazione può utilizzare AD LDS per fornire all'applicazione uno schema su misura che si adatta alle esigenze aziendali, ai requisiti sui dati e ai processi di workflow, senza alterare la configurazione dell'Active Directory azienda. Gli sviluppatori possono lavorare con un'istanza di AD LDS senza la necessità di un setup complicato e di dover poi passare l'applicazione su AD DS. Gli sviluppatori possono volere una directory facile da programmare, senza requisiti complessi per l'installazione e senza necessità di supporto hardware durante il processo di sviluppo. Ciò può essere ottenuto attraverso AD LDS che può essere facilmente installato e disinstallato su qualsiasi computer Windows Server 2008. Questo permette un restore rapido a duno stato pulito durante il processo di test e sviluppo applicativo.

Fornire un archivio di configurazione per le applicazioni distribuite in Windows Server

Si può avere un'applicazione distribuita che richiede un archivio della configurazione con aggiornamento multimaster e funzionalità di replica per supportare i suoi componenti, ad esempio, un'applicazione firewall che accede a dati relativi alla rete e all’utilizzo delle porte, una filtro che accede a elenchi di indirizzi di posta elettronica, o un'applicazione workflow che accede ai dati e alle politiche aziendali. È possibile distribuire AD LDS come un archivio di configurazione leggero per tali applicazioni, come mostrato nell'illustrazione seguente.

http://i.technet.microsoft.com/cc754361.53412c5a-574a-4963-8e1f-0d3214c45385(en-us,WS.10).gif

In questo scenario, un'istanza di AD LDS che funge da archivio di configurazione dell'applicazione è impacchettata con un'applicazione distribuita. In questo modo, chi progetta una applicazione non si deve interessare circa la disponibilità di un servizio di directory prima dell'installazione dell'applicazione. Invece, si può includere AD LDS come parte del processo di installazione dell'applicazione, per garantire che l'applicazione abbia accesso a un servizio di directory immediatamente al momento dell'installazione. L'applicazione quindi configura e gestisce AD LDS interamente in proprio oppure parzialmente, in base all'esposizione dell'applicazione alla gestione di AD LDS e utilizza AD LDS per rispondere ai suoi vari requisiti di dati.

Migrazione di applicazioni legacy basate su directory

L'organizzazione può utilizzare una directory già esistente con nomenclatura x. 500 (O = <organization>, C = <country>) per servire le varie applicazioni legacy, ma si consiglia anche di migrare la sua directory aziendale in AD DS. In questo scenario, è possibile utilizzare AD LDS come soluzione provvisoria. È possibile installare AD LDS per supportare le applicazioni legacy che si basano su nomenclatura x. 500, sebbene sia possibile utilizzare AD DS in azienda per fornire un'infrastruttura di sicurezza condivisa. È possibile utilizzare metadirectory, come ad esempio MIIS, per sincronizzare automaticamente i dati in Active Directory e AD LDS per una migrazione senza soluzione di continuità. Nell'illustrazione seguente si descrive questa distribuzione di AD LDS.

http://i.technet.microsoft.com/cc754361.c99a82eb-35da-4523-9aaa-f65dee9a2560(en-us,WS.10).gif 

Funzionalità del ruolo AD LDS

È possibile utilizzare il ruolo AD LDS per creare più istanze AD LDS su un singolo computer. Ciascuna istanza viene eseguita come servizio separato nel proprio contesto di esecuzione. Il ruolo server AD LDS include le seguenti funzionalità per rendere più facile la creazione, configurazione e gestione delle istanze di AD LDS :

• Un wizard che guida l'utente attraverso il processo di creazione di un'istanza di AD LDS
• Strumenti da riga di comando per l'esecuzione automatica dell’ installazione e della rimozione delle istanze di AD LDS
• Snap-in Microsoft Management Console (MMC) per la configurazione e la gestione delle istanze di AD LDS, tra cui lo schema per ogni istanza
• Strumenti da riga di comando specifici di AD LDS per la gestione, il popolamento e la sincronizzazione delle istanze di AD LDS

Oltre a questi strumenti, è possibile utilizzare molti strumenti di Active Directory per amministrare le istanze di AD LDS.

Il sistema operativo Windows Server 2008 include le funzionalità aggiuntive di AD LDS nella tabella seguente.

Nel sistema operativo Windows Server 2008 R2, AD LDS include le seguenti nuove funzionalità (disponibili anche per AD DS in Windows Server 2008 R2) che aiutano a migliorare la gestibilità e il mantenimento :

• Recycle Bin di Active Directory : Migliora la capacità di conservare e recuperare gli oggetti Active Directory accidentalmente eliminati. Per ulteriori informazioni, vedere Novità in Active Directory: Recycle Bin di Active Directory(http://go.microsoft.com/fwlink/?LinkId = 141392  ).
• Active Directory PowerShell: fornisce script da riga di comando per amministrare, configurare e per la diagnostica, con un  vocabolario e una sintassi consistenti. Per ulteriori informazioni, vedere Novità in Active Directory: Active Directory PowerShell (http://technet.microsoft.com/en-us/library/dd378783.aspx ).
• Active Directory Web Services: offre un'interfaccia di servizio Web ai domini di Active Directory, alle istanze di AD LDS e alle istanze di connessione database di Active Directory. Per ulteriori informazioni, vedere Novità in Active Directory: servizi Web di Active Directory (http://technet.microsoft.com/en-us/library/dd391908.aspx ).

Considerazioni su hardware e software

Utilizzate i contatori delle prestazioni, testate in laboratorio, valutate i dati dell'hardware esistente in un ambiente di produzione e fate implementazioni pilota per determinare la capacità necessaria per il vostro server.

Nota: un insieme limitato di ruoli del server è disponibile per l'opzione di installazione Server Core di Windows Server 2008 e Windows Server 2008 per sistemi basati su Itanium.