Active Directory

Comprensione di autenticazione proxy in Active Directory Lightweight Directory Services

Ken St. Cyr

In un riepilogo delle:

• Definisce l'autenticazione proxy
• Perché è utile l'autenticazione proxy
• Nell'oggetto proxy
• Cosa succede durante authenticationItem

Contenuto

Che cos'è autenticazione proxy?
Vantaggi dell'autenticazione proxy
All'interno dell'oggetto proxy
Come È effettivamente eseguita l'autenticazione
Impostazione di un laboratorio di autenticazione proxy
Conclusione

Come con qualsiasi servizio di directory attivata LDAP, Microsoft Active Directory Lightweight Directory Services (Active Directory Lightweight Directory Services, in precedenza denominato ADAM) richiede un utente per l'associazione prima di eseguire operazioni con la directory LDAP. Questa associazione può essere eseguita tramite diversi metodi, quali un binding LDAP semplice, Simple Authentication e associazione SASL (Security Layer) o anche il reindirizzamento dell'associazione. L'associazione può inoltre essere anonimo, nel qual caso l'utente presenta una password null. In questo articolo è desidera discutere e analizzare un metodo in particolare, associare il reindirizzamento, altrimenti noto come autenticazione proxy.

Che cos'è autenticazione proxy?

L'autenticazione proxy consente a un utente eseguire un'associazione semplice a un'istanza di Active Directory Lightweight Directory Services, mantenendo comunque un'associazione a un account di Active Directory. Due account sono coinvolti nella transazione. Il primo è che un oggetto speciale in Active Directory Lightweight Directory Services denominata un oggetto userProxy. Il secondo è l'account dell'utente in Active Directory.

L'oggetto di Active Directory Lightweight Directory Services userProxy è una rappresentazione dell'account di Active Directory. L'oggetto proxy è legato all'account di Active Directory tramite identificatore di protezione l'account (SID). Non sono Nessuna password memorizzata per l'oggetto effettivo proxy stesso.

Quando un utente esegue un'associazione semplice a un'istanza di Directory Lightweight Directory Services con un oggetto proxy, l'associazione viene reindirizzato in Active Directory passando il SID e la password a un controller di dominio. Il server di Active Directory Lightweight Directory Services esegue l'autenticazione e l'intero processo risulta invisibile all'utente finale. Questa è illustrata nella Figura 1 , in cui Lucy è connessione a un'istanza di Active Directory Lightweight Directory Services denominata " CN = AppDir,DC = contoso, DC = com " con suo account utente di Active Directory Lightweight Directory Services.

Nella figura 1 connessione con Active Directory Lightweight Directory Services fare clic su Immagine per una visualizzazione ingrandita

Per l'autenticazione Lucy sta utilizzando un'associazione semplice e utente fornisce il nome distinto (DN) e la password come utente durante un'associazione LDAP normale. Anche se apparentemente Lucy si connette con il tipico account utente di Directory Lightweight Directory Services, utilizza in realtà un oggetto proxy. L'autenticazione in Active Directory accade dietro le quinte e Lucy non è nessuna indicazione che ha effettivamente dell'utilizzo proprio account di Active Directory per associare.

Vantaggi dell'autenticazione proxy

La potenza di autenticazione proxy risiede nella dando agli sviluppatori di applicazioni di accesso a un oggetto utente senza fornendo loro accesso all'account di Active Directory. Considerare ciò che si verifica quando viene creata una nuova applicazione attivato di directory e l'applicazione deve memorizzare alcuni dati in Active Directory. L'applicazione possibile utilizzare un attributo esistente o crearne uno nuovo.

Pericolo utilizzando un attributo esistente non utilizzato è l'attributo probabilmente esiste un altro scopo. Anche se si tratta di inutilizzati a questo punto, potrebbero essere utilizzata in futuro; se è utilizzata per alcune scopo diverso, Active Directory gli amministratori sarebbe necessario tenere traccia di come viene da utilizzata. E cosa succede se lo sviluppatore di applicazioni deve più di un attributo?

Con l'autenticazione proxy, una rappresentazione dell'oggetto utente Active Directory esista nella directory Active Directory Lightweight Directory Services. Una directory specifiche dell'applicazione consente allo sviluppatore dell'applicazione modificare lo schema in modo che desideri nel contesto di Active Directory Lightweight Directory Services. Attributi possono essere aggiunto, modificati o convertiti in alcun modo che lo sviluppatore sceglie e Active Directory amministratore non deve preoccuparsi modifiche dello schema più o tenere traccia di come gli attributi vengono utilizzati. Se un'altra applicazione viene portata in linea e desidera di utilizzare l'attributo stesso, non di un problema perché può essere un'istanza di Active Directory Lightweight Directory Services separata e non disporrà di eventuali conflitti di attributo.

L'autenticazione proxy può inoltre essere utile nelle situazioni che richiedono il formato di indirizzo X.500. Active Directory non utilizza tipica nomenclature X.500 per nomi distinti. Ad esempio, un oggetto utente in Active Directory ha il nome DISTINTO " CN = Lucy d Rossi, CN = Users, DC = contoso, DC = com ". Tuttavia, potrebbe essere DN dell'utente in Active Directory Lightweight Directory Services, " CN = Lucy d Rossi, CN = Users, O = Contoso, C = IT ", che è compatibile con X.500.

Ciò è utile quando si sta utilizzando un client LDAP di terze parti o tentativo di integrazione con una directory di terze parti che richiede il formato di indirizzo X.500. In questo modo, è possibile che Directory Lightweight Directory Services essere una directory intermedie tra una directory di terze parti e Active Directory. Utilizza l'autenticazione proxy, l'account di servizio nella directory di terze parti deve utilizzare per associare l'istanza di Directory Lightweight Directory Services può essere contenuto in Active Directory invece di Directory Lightweight Directory Services stesso.

All'interno dell'oggetto proxy

Finora È stato assegnato una breve panoramica del modo in cui l'oggetto proxy Directory Lightweight Directory Services è legato a account utente di Active Directory. Ora verrà controllare questo in maggiore dettaglio ed esaminare cosa è effettivamente succedendo dietro le quinte, inizia con la classe dell'oggetto.

In Windows Server 2008, la directory %SYSTEMROOT%\ADAM contiene due file LDF che rappresenta un oggetto proxy:

• UserProxy.LDF Microsoft
• UserProxyFull.LDF Microsoft

UserProxy.LDF Microsoft contiene la definizione per la classe userProxy semplice che contiene gli attributi di base e contiene la classe ausiliaria BindProxy msDS-ReplAuthenticationMode. UserProxyFull.LDF Microsoft contiene la BindProxy msDS-ReplAuthenticationMode classe ausiliaria nonché, ma pre-populates anche attributi utente aggiuntivi nell'attributo mayContain della classe. Di conseguenza, è necessario siano presenti le classi di attributi. In modo che quando si importano la classe userProxyFull, l'utente o inetOrgPerson classe deve essere importati prima. Utente e inetOrgPerson contengono l'attributo utilizza tale userProxyFull le definizioni di classe per gli attributi. La figura 2 Mostra le differenze tra la classe userProxy e la classe userProxyFull.

Nella figura 2 le classi userProxy e userProxyFull fare clic su Immagine per una visualizzazione ingrandita

Il fatto che entrambe le classi contengano BindProxy msDS-ReplAuthenticationMode come una classe ausiliaria è significativo. Una classe ausiliaria è un tipo di classe che può fornire dati aggiuntivi a una classe struttura. In Directory Lightweight Directory Services, ad esempio, la classe User è una classe struttura ereditata dalla classe utente organizzative, che significa che la classe utente dispone di tutti gli elementi che la classe Person organizzative dispone. Ma la classe di utenti è anche una classe ausiliaria denominata msDS-BindableObject, significa che l'utente contiene tutti gli attributi obbligatori e facoltativi di BindableObject msDS-ReplAuthenticationMode oltre agli attributi dalla classe utente organizzative. In questo caso, utilizzo Bindable­Object msDS-ReplAuthenticationMode come una classe ausiliaria rende la classe User associabile.

Poiché la classe userProxy ha BindProxy msDS-ReplAuthenticationMode come una classe ausiliaria (vedere nella Figura 3 ), ora inoltre contiene l'intero attributo obbligatori e facoltativi insieme di BindProxy msDS-ReplAuthenticationMode. La classe ausiliaria di BindProxy msDS-ReplAuthenticationMode è ciò che trasforma un oggetto in un oggetto proxy. Pertanto, anche se si dispone di una classe personalizzata, è possibile aggiungere la classe ausiliaria BindProxy msDS-ReplAuthenticationMode e utilizzare gli oggetti personalizzati per l'autenticazione proxy.

Nella figura 3 di creazione di un proxyobject fare clic su Immagine per una visualizzazione ingrandita

Se fosse necessario esaminare la classe BindProxy msDS-ReplAuthenticationMode, è necessario notare che sia solo un attributo obbligatorio definito, objectSID. Questo è l'attributo che verrà inserito il SID dell'account utente di Active Directory per creare l'associazione tra l'oggetto proxy nella directory Lightweight Directory Services e l'oggetto utente in Active Directory. Questo attributo può essere compilato quando viene creato l'oggetto. Non può essere modificato senza eliminare l'oggetto e si ricreano.

Come È effettivamente eseguita l'autenticazione

Per veramente capire cosa è succedendo dietro le quinte, è necessario passare un po'più approfondita alla modalità di esecuzione dell'autenticazione. È necessario scorrere due tracce di rete che consenta di visualizzare il funzionamento dell'autenticazione proxy. La prima traccia è un'acquisizione di rete di binding semplice un utente proxy da una workstation Windows XP a un'istanza di Windows Server 2008 LDS. In questa acquisizione, Lucy associa con relativo oggetto di utente proxy utilizzando LDP.exe dalla sua workstation.

Nella figura 4 pacchetti tre è illustrato in acquisizione che si desidera esaminare. Pacchetto 1 è la richiesta di associazione da workstation (10.0.0.107) al server di directory Active Directory Lightweight Directory Services (10.0.0.201). La richiesta di associazione contiene DN del Lucy, " cn = lucy, cn = utenti, cn = appdir, dc = contoso, dc = com ". Pacchetto 2 è la risposta dal server di directory Active Directory Lightweight Directory Services workstation, che indica un'associazione completata. E pacchetti 3 il riconoscimento dalla workstation al server di directory Active Directory Lightweight Directory Services, che indica il riconoscimento della risposta di associazione.

Nella figura 4 Bind richiesta e risposta fare clic su Immagine per una visualizzazione ingrandita

Se l'analisi nei dettagli del pacchetto 1 (vedere nella figura 5 ), si noterà che qualcosa terribile. La password che Lucy fornita (P@ssw0rd) viene visualizzata crittografata nell'acquisizione. Questo è, infatti, uno dei downfalls dell'utilizzo di un binding LDAP semplice per l'autenticazione. A meno che l'associazione viene incluso nella crittografia SSL, la password dell'utente verrà essere annunciata a tutti gli utenti in ascolto sulla rete.

Nella figura 5 associazione semplice con SSL disattivato fare clic su Immagine per una visualizzazione ingrandita

Active Directory Lightweight Directory Services directory attivare SSL per impostazione predefinita, tuttavia. È necessario passare di modo per disattivarlo, che è esattamente ciò che HO fatto per questo esercizio per rendere leggibile la traccia della rete. Ed non preoccuparsi per assegnare un certificato al server di directory Active Directory Lightweight Directory Services, ma in un'implementazione effettiva, si desidera assolutamente accertarsi che il server di directory Active Directory Lightweight Directory Services disponga di un certificato valido che può essere utilizzato per SSL.

La traccia seconda è un'acquisizione di rete dal server di directory Active Directory Lightweight Directory Services al controller di dominio (DC). L'analisi è un po'maggiore del primo elemento, pertanto È necessario suddividerla in blocchi. I pacchetti 9 prima di traccia sono illustrati nella Figura 6 .

Nella figura 6 la connessione di Active Directory Lightweight Directory Services a controller di dominio fare clic su Immagine per una visualizzazione ingrandita

Il primo pacchetto dovrebbe risultare familiare. Ciò avviene in associazione richiesta in arrivo dalla workstation. Anche in questo caso, questo pacchetto contiene DN e la password in testo non crittografato Dell'lucy. I pacchetti da 2 a 9 Mostra al server di Active Directory Lightweight Directory Services (10.0.0.201) collegarsi il controller di dominio (10.0.0.200). Questo consiste alcuni nei messaggi protocollo ARP (risoluzione indirizzo seguiti da una connessione di chiamata (RPC) RPC al controller di dominio.

Nella Figura 7 pacchetti 10 e 11 chiamare un metodo denominato LsarLookupSids3, una chiamata RPC che indica il controller di dominio per richiedere un batch di SID e restituire i nomi corrispondenti. Il server di Active Directory Lightweight Directory Services effettua la richiesta nel pacchetto 10 e riceve la risposta dal controller di dominio nel pacchetto 11.

Nella figura 7 tentare l'autenticazione Kerberos fare clic su Immagine per una visualizzazione ingrandita

Dopo un breve handshake TCP per avviare la sessione Kerberos (12–14 pacchetti), nel pacchetto 15 il server di Active Directory Lightweight Directory Services tenta quindi di ottenere il ticket di servizio di autenticazione (AS Approv) dal centro distribuzione chiavi (KDC). Nel pacchetto 16, la richiesta di ticket di servizio di autenticazione viene rifiutata perché il controller di dominio si aspetta alcuni preautenticazione dati che il server di Active Directory Lightweight Directory Services non fornire. In questo caso, il controller di dominio desidera il timestamp, quindi può essere utilizzato per la verifica dell'identità. La sessione Kerberos estremità e una reimpostazione è richiesto (17–19 pacchetti).

Nella figura 8 Visualizza i rimanenti dell'acquisizione. Pacchetti 20–22 stabilire una nuova sessione Kerberos e una nuova richiesta servizio di autenticazione viene inviata dal server Active Directory Lightweight Directory Services al controller di dominio nel pacchetto 23. Questa nuova richiesta contiene dati di preautenticazione necessari, indicati dalla risposta corretta di controller di dominio nel pacchetto 25. Il server di Active Directory Lightweight Directory Services ora è il ticket di servizio di autenticazione e possibile inserire una richiesta per il ticket di servizio di concessione per autenticare le credenziali del Lucy.

Nella figura 8 autenticazione completata fare clic su Immagine per una visualizzazione ingrandita

Il ticket di concessione richiesta e la risposta del servizio vengono identificati i pacchetti 33 e 34. Il carico di KRB_TGS_REP nel pacchetto 34 indica che Lucy è autenticata. Infine, nel pacchetto 38 il server di Active Directory Lightweight Directory Services invia la risposta associazione workstation, consentendo di Lucy sapere che utente è correttamente associato all'istanza di Active Directory Lightweight Directory Services. Sebbene questo processo prevede più passaggi, il tempo totale per l'intera transazione solo è di circa 1/dieci volte in cui di secondo.

Cosa potrebbe accadere se Lucy immesso una password errata? Nei nostro esempio, la richiesta di servizio di autenticazione necessario non al pacchetto 25. L'errore di richiesta del servizio di autenticazione necessario indicare il server di Active Directory Lightweight Directory Services che credenziali del Lucy erano danneggiate. Invece di emettere una richiesta per il ticket di servizio di concessione, il server di Active Directory Lightweight Directory Services si invia una risposta associazione workstation, che indica che le credenziali non sono validi.

Di seguito è un Ricapitolazione di dov nello scambio completato:

1. La workstation invia una richiesta di associazione al server di Active Directory Lightweight Directory Services.
2. Il server di Active Directory Lightweight Directory Services stabilisce una connessione con il controller di dominio.
3. Il server di Active Directory Lightweight Directory Services richiede controller di dominio per tradurre del Lucy SID in un identificatore che è possibile utilizzare per l'autenticazione.
4. Il controller di dominio consente ID. di Lucy server Active Directory Lightweight Directory Services
5. Il server di Active Directory Lightweight Directory Services ottiene un ticket di concessione ticket (TGT) dal controller di dominio con ID. Dell'lucy
6. Il server di Active Directory Lightweight Directory Services ottiene un ticket di sessione a se stessa utilizzando TGT. del Lucy
7. Il server di Active Directory Lightweight Directory Services invia una risposta corretta associazione nuovamente alla workstation.

Questo processo viene specificato che la connessione dalla workstation al server di Active Directory Lightweight Directory Services è una transazione di binding LDAP standard. Dal server di Active Directory Lightweight Directory Services al controller di dominio, quindi Kerberos viene utilizzato per autenticare in modo sicuro l'utente.

Impostazione di un laboratorio di autenticazione proxy

Ora che si conosce come funziona l'autenticazione proxy, vediamo come è possibile impostare questa in un ambiente di laboratorio. Si noti che per questo esercizio, verrà da disattivare il fabbisogno per SSL nell'autenticazione proxy. È necessario tenere come già anticipato, presente che non deve disattivare questo requisito in un'implementazione reale.

Prima di iniziare, sarà necessario un dominio con un server membro di Windows Server 2008 e una workstation appartenenti a esso completamente funzionale. Il server membro Windows Server 2008 verrà eseguito Active Directory Lightweight Directory Services e la workstation è l'endpoint di client. Il vantaggio di separazione di tali computer è che è possibile eseguire esempi di rete dell'interazione tra di esse. Per impostare il laboratorio, verrà scorrere è la procedura seguente:

• Installare Active Directory Lightweight Directory Services sul server membro.
• Disattivare il requisito SSL per l'autenticazione proxy.
• Importare la classe userProxy lo schema di Active Directory Lightweight Directory Services.
• Creare l'oggetto proxy e assegnare autorizzazioni a esso.
• Associare la directory di Active Directory Lightweight Directory Services e l'oggetto proxy.

Il primo passaggio consiste nell'installare Active Directory Lightweight Directory Services sul server membro Windows Server 2008. In Server Manager si troverà l'opzione per installare Directory Lightweight Directory Services nella procedura guidata Aggiungi ruoli. Dopo il ruolo è installato, la nuova opzione verrà visualizzati nella menu Strumenti di amministrazione chiamato Lightweight Directory Services Installazione guidata Active Directory. Utilizzare questa procedura guidata per creare una nuova istanza di Directory Lightweight Directory Services.

Quando richiesto di specificare il nome della partizione di applicazione, immettere qualsiasi DN desiderato. Tenere presente che Directory Lightweight Directory Services supporta nomi X.500, pertanto non è limitato a utilizzando un " DC = " nome dello stile. Negli esempi, HO utilizzato " cn = appdir, dc = contoso, dc = com ", ma Impossibile sono utilizzate anche " cn = appdir, o = contoso, c = ci ".

Dopo aver installato l'istanza di Active Directory Lightweight Directory Services, il passaggio successivo consiste nel disabilitare il requisito SSL per l'autenticazione proxy. Snap-in L'ADSI Edit (adsiedit.msc), è necessario connettersi a partizione della configurazione dell'istanza di Active Directory Lightweight Directory Services utilizzando l'account dell'amministratore specificato durante l'installazione. Se non si conosce il nome DISTINTO della partizione di configurazione, è possibile scegliere "configurazione" dall'elenco a discesa "Selezionare un contesto dei nomi conosciuto" nella finestra di dialogo delle impostazioni di connessione in ADSI Edit.

Selezionare il contenitore " CN = Directory Service, CN = Windows NT, CN = Services, CN = Configuration, CN = {guid} " e la finestra di dialogo delle proprietà del " CN = Directory Service " contenitore. Attributo stringa multivalore nell'elenco di attributi denominato msDS-ReplAuthenticationMode altri-impostazioni contenente più stringhe, ciascuno che indica una diversa impostazione per l'istanza di Active Directory Lightweight Directory Services è presente. Modifica di questo attributo e modificare la stringa "RequireSecureProxyBind" a un valore pari a 0.

Il passaggio successivo consiste nell'importazione della definizione classe di schema per la classe userProxy. Si potrebbe avere già importato quando richiesto della procedura guidata di Active Directory Lightweight Directory Services. In questo caso, è possibile saltare questo passaggio. Se non è già importarla, procedere con il seguente comando LDIFDE.EXE. Assicurarsi di specificarne il nome del server Active Directory Lightweight Directory Services e la porta appropriata nel comando:

C:\> ldifde –i -f c:\windows\adam\ms-userproxy.ldf –s
   server:port –k –j . –c 
   "cn=schema,cn=configuration,dc=X"
   #schemaNamingContext

Dopo che la classe dell'oggetto è stata importata, è possibile creare l'oggetto proxy. È necessario utilizzare LDP.exe, ma è possibile utilizzare un altro strumento o un metodo a livello di programmazione. Utilizzo di LDP, connettersi l'istanza di Active Directory Lightweight Directory Services e associare con le credenziali di amministratore. Individuare il nome DISTINTO dell'istanza di Active Directory Lightweight Directory Services e quindi scegliere il contenitore in cui si desidera creare l'oggetto proxy. Fare clic con il pulsante destro del mouse sul contenitore, quindi scegliere Aggiungi figlio dall'elenco a discesa. Nella finestra di dialogo Aggiungi, sarà necessario immettere il nome DISTINTO dell'oggetto proxy nuovo nel campo Nome DISTINTO. Ad esempio, è possibile utilizzare " cn = lucy, cn = appdir, o = contoso, c = ci ".

È inoltre necessario creare due attributi con questo oggetto. Il primo è objectClass, che indica il tipo di oggetto da creare. Il valore per questo esempio deve essere userProxy. Inserire queste informazioni nella sezione Modifica voce della finestra di dialogo e scegliere il pulsante di invio.

L'attributo di secondo da aggiungere è objectSID che contiene il SID dell'account utente di Active Directory a cui è associato l'oggetto proxy. È possibile ottenere questo SID con un'ampia gamma di metodi, ma solo connessi ad Active Directory in un'istanza separata di LDP e copiato l'attributo objectSID esiste l'account utente. Dopo avere immesso queste informazioni, la finestra di dialogo Aggiungi dovrebbe essere simile a figura 9 . Infine, fare clic sul pulsante Esegui per eseguire il commit della modifica.

Nella Figura 9 di creazione di un oggetto proxy

Per utilizzare l'oggetto proxy che appena creato, sarà necessario assegnare alcune autorizzazioni. A questo scopo facilmente selezionando è il " CN = lettori " oggetto nel " CN = ruoli " contenitore in LDP. Fare clic con il pulsante destro del mouse e scegliere Modifica dall'elenco a discesa. Aggiungere un attributo denominato di membri e per il valore, immettere il nome DISTINTO dell'oggetto userProxy che è stato creato. Ricordarsi di fare clic sul pulsante Invio prima di fare clic su Esegui. A questo punto l'oggetto di userProxy deve essere un membro del gruppo lettori nell'istanza Directory Lightweight Directory Services.

Tutto deve essere impostato in modo che ora è possibile verificare l'autenticazione proxy. Aprire una nuova istanza di LDP e connettersi al server di Active Directory Lightweight Directory Services. Questa volta, tuttavia quando si associa l'istanza, selezionare binding semplice e il tipo di nome DISTINTO dell'oggetto proxy nel campo Nome utente. Per la password, immettere la password di Active Directory oggetto account legata questo proxy. Scegliere OK ed è ora deve essere associato all'istanza in modalità di sola lettura.

Dedicare alcuni tempo prendere le tracce di rete e provato a metodi di associazione diverse. Un esercizio potrebbe essere attiva SSL e richiedere quindi un'acquisizione del processo di binding LDAP. È possibile anche deliberatamente digitata un nome utente o una password e osservare ciò che accade per il processo di autenticazione.

Conclusione

Non essere alarmed tramite la difficoltà di utilizzare l'autenticazione proxy. Ha richiesto l'approccio di illustrare il processo con LDP e ADSI Edit poiché consente un aspetto migliore dietro le quinte. A causa di che, nell'esempio esaminato tramite viene illustrato l'autenticazione proxy da una prospettiva molto pratica.

In pratica, il lungo processo di creazione di oggetti userProxy e modifica le viene in genere codified tramite un sistema di gestione identità o un front-end di personalizzato sviluppato per la creazione di account. Consiglia di generare laboratorio di Directory Lightweight Directory Services e verificare per se stessi come è possibile utilizzare l'autenticazione proxy per l'integrazione delle directory di terze parti e alle applicazioni.

Ken ST Cyr è un consulente per Microsoft ha progettato e implementato soluzioni directory basate su Active Directory dall'inizio la disponibilità. Egli ultimi diventato uno dei primi a ottenere la certificazione Microsoft Certified master per i servizi di directory. Contattarlo in Ken.stcyr@Microsoft.com.