Suggerisci traduzione
 
Altri utenti hanno suggerito:

progress indicator
Nessun altro suggerimento.
TechNet Magazine > Home > Tutti i numeri > 2008 > Dicembre >  Active Directory: autenticazione proxy informaz...
Visualizza contenuto:  affiancatoVisualizza contenuto: affiancato
Questo contenuto è stato tradotto mediante un sistema automatico e può essere modificato dai membri della community. Microsoft invita i membri a contribuire al miglioramento della traduzione facendo clic sul collegamento "Modifica" associato a ciascuna delle frasi seguenti.
Active Directory
Understanding Proxy Authentication in AD LDS
Ken St. Cyr
 
At a Glance:
  • Defining proxy authentication
  • Why proxy authentication is useful
  • Inside the proxy object
  • What happens during authenticationItem

As with any LDAP-enabled directory service, Microsoft Active Directory Lightweight Directory Services (AD LDS—formerly called ADAM) requires a user to bind before executing any LDAP operations against the directory. This bind can be done through a few different methods, including a simple LDAP bind, a Simple Authentication and Security Layer (SASL) bind, or even bind redirection. The bind could also be anonymous, in which case the user presents a null password. In this article, I am going to discuss and analyze one method specifically—bind redirection, otherwise known as proxy authentication.

What Is Proxy Authentication?
Proxy authentication allows a user to perform a simple bind to an AD LDS instance, while still maintaining an association to an Active Directory account. Two accounts are involved in the transaction. The first is a special object in AD LDS called a userProxy object. The second is the user's account in Active Directory.
The AD LDS userProxy object is a representation of the Active Directory account. The proxy object is tied to the Active Directory account through that account's security identifier (SID). There is no password stored on the actual proxy object itself.
When a user performs a simple bind to an LDS instance with a proxy object, the bind is redirected to Active Directory by passing the SID and password to a domain controller. The AD LDS server performs the authentication, and the entire process is invisible to the end user. This is illustrated in Figure 1, where Lucy is connecting to an AD LDS instance called "CN=AppDir,DC=contoso,DC=com" with her AD LDS user account.
Figure 1 Connecting with AD LDS (Click the image for a larger view)
For the authentication, Lucy is using a simple bind, and she supplies her distinguished name (DN) and password as she would during a normal LDAP bind. Although Lucy seemingly connects with her typical LDS user account, she is actually using a proxy object. The authentication to Active Directory is happening behind the scenes, and Lucy has no clue that she's actually using her Active Directory account to bind.

Benefits of Proxy Authentication
The power of proxy authentication lies in giving application developers access to a user object without giving them access to the Active Directory account. Consider what happens when a new directory-enabled application is being built and the application needs to store some data in Active Directory. The application can either use an existing attribute or create a new one.
The danger in using an existing unused attribute is that the attribute is likely there for another purpose. Even if it's unused now, it could be used in the future; if it's used for some different purpose, the Active Directory administrators would have to keep track of how it's being used. And what if the app developer needs more than one attribute?
With proxy authentication, a representation of the Active Directory user object exists in the AD LDS directory. An application-specific directory allows the application developer to modify the schema any way he'd like in the context of AD LDS. Attributes can be added, changed, or repurposed in any manner the developer chooses, and the Active Directory administrator doesn't have to worry about making multiple schema changes or keeping track of how attributes are used. If another application comes online and wants to use the same attribute, it's not a problem because it can be a separate AD LDS instance and won't have any attribute conflicts.
Proxy authentication can also be useful in situations that require the X.500 format. Active Directory does not use typical X.500 nomenclature for DNs. For example, a user object in Active Directory has the DN "CN=Lucy D. Smith,CN=Users,DC=contoso,DC=com". However, in AD LDS, the user's DN could be "CN=Lucy D. Smith,CN=Users,O=Contoso,C=US", which is compatible with X.500.
This is helpful when you're using a third-party LDAP client or trying to integrate with a third party directory that requires the X.500 format. In this way, LDS can be an intermediary directory between a third-party directory and Active Directory. Using proxy authentication, the service account that the third-party directory needs to use to bind to the LDS instance can be held in Active Directory instead of LDS itself.

Inside the Proxy Object
So far I've given a brief overview of how the LDS proxy object is tied to the Active Directory user account. I'll now look at this in more detail and examine what's actually happening behind the scenes, starting with the object class.
In Windows Server 2008, the %SYSTEMROOT%\ADAM directory contains two LDF files that represent a proxy object:
  • MS-UserProxy.LDF
  • MS-UserProxyFull.LDF
MS-UserProxy.LDF holds the definition for the simple userProxy class, which has basic attributes and contains the msDS-BindProxy auxiliary class. MS-UserProxyFull.LDF contains the msDS-BindProxy auxiliary class as well, but it also pre-populates additional user attributes into the mayContain attribute of the class. Because of this, the attribute classes have to exist beforehand. So when importing the userProxyFull class, either the user or inetOrgPerson class needs to be imported first. Both user and inetOrgPerson contain the attribute class definitions for the attributes that userProxyFull uses. Figure 2 shows the differences between the userProxy class and the userProxyFull class.
Figure 2 The userProxy and userProxyFull classes (Click the image for a larger view)
The fact that both classes contain msDS-BindProxy as an auxiliary class is significant. An auxiliary class is a type of class that can provide additional data to a structural class. In LDS, for example, the User class is a structural class that is inherited from the Organizational-Person class, which means that the User class has everything that the Organizational-Person class has. But the User class also has an auxiliary class called msDS-BindableObject, which means User contains all of the mandatory and optional attributes of msDS-BindableObject in addition to the attributes from the Organizational-Person class. In this instance, using msDS-Bindable­Object as an auxiliary class makes the User class bindable.
Since the userProxy class has msDS-BindProxy as an auxiliary class (see Figure 3), it now also contains the entire mandatory and optional attribute set of msDS-BindProxy. The msDS-BindProxy auxiliary class is what turns an object into a proxy object. So even if you have a custom class, you can add the msDS-BindProxy auxiliary class and use your custom objects for proxy authentication.
Figure 3 Creating a proxy object (Click the image for a larger view)
If you were to examine the msDS-BindProxy class, you would notice that there is only one mandatory attribute defined—objectSID. This is the attribute that the SID of the Active Directory user account will be placed in to create the association between the proxy object in LDS and the user object in Active Directory. This attribute can only be populated when the object is created. It cannot be changed without deleting the object and recreating it.

How the Authentication Is Actually Performed
To truly understand what's happening behind the scenes, we'll need to go a little bit deeper into how the authentication is performed. I'll walk through two network traces that will help show how proxy authentication works. The first trace is a network capture of a proxy user's simple bind from a Windows XP workstation to a Windows Server 2008 LDS instance. In this capture, Lucy binds with her proxy user object using LDP.EXE from her workstation.
Figure 4 shows the three packets in the capture that we need to examine. Packet 1 is the bind request from the workstation (10.0.0.107) to the Active Directory LDS server (10.0.0.201). The bind request contains Lucy's DN, "cn=lucy,cn=people,cn=appdir,dc=contoso,dc=com". Packet 2 is the response from the Active Directory LDS server to the workstation, indicating a successful bind. And packet 3 is the acknowledgment from the workstation to the Active Directory LDS server, indicating the acknowledgment of the bind response.
Figure 4 Bind request and response (Click the image for a larger view)
If you dig into the details of packet 1 (see Figure 5), you'll notice something shocking. The password that Lucy supplied (P@ssw0rd) is displayed in clear text in the capture. This is, in fact, one of the downfalls of using a simple LDAP bind for authentication. Unless the bind is wrapped in SSL encryption, the user's password will be advertised to anyone listening on the network.
Figure 5 Simple bind with SSL turned off (Click the image for a larger view)
Active Directory LDS does enable SSL by default, however. You have to go out of your way to turn it off, which is exactly what I did for this exercise in order to make the network trace readable. And I didn't bother to assign a certificate to the Active Directory LDS server, but in an actual implementation, you absolutely want to ensure that the Active Directory LDS server has a valid certificate that can be used for SSL.
The second trace is a network capture from the Active Directory LDS server to the domain controller (DC). This trace is a bit larger than the first one, so I'll break it up into chunks. The first 9 packets of this trace are shown in Figure 6.
Figure 6 AD LDS connecting to the domain controller (Click the image for a larger view)
The first packet should look familiar to you. This is in the incoming bind request from the workstation. Again, this packet contains Lucy's DN and password in clear text. Packets 2 through 9 show the AD LDS server (10.0.0.201) connecting to the domain controller (10.0.0.200). This consists of some address resolution protocol (ARP) messages followed by a remote procedure call (RPC) connection to the DC.
In Figure 7, packets 10 and 11 call a method named LsarLookupSids3, an RPC call that tells the DC to take a batch of SIDs and return their corresponding names. The AD LDS server makes the request in packet 10 and receives the response from the DC in packet 11.
Figure 7 Kerberos authentication attempt (Click the image for a larger view)
Then, after a brief TCP handshake to start the Kerberos session (packets 12–14), in packet 15 the AD LDS server attempts to get the authentication service ticket (AS-REQ) from the Key Distribution Center (KDC). In packet 16, the authentication service ticket request is denied because the DC is expecting some pre-authentication data that the AD LDS server didn't provide. In this case, the DC wants the timestamp so it can be used for identity verification. The Kerberos session ends and a reset is requested (packets 17–19).
Figure 8 shows the rest of the capture. Packets 20–22 establish a new Kerberos session and a new authentication service request is sent from the AD LDS server to the DC in packet 23. This new request contains the necessary pre-authentication data, indicated by the successful reply from the DC in packet 25. The AD LDS server now has the authentication service ticket and can place a request to the ticket granting service to authenticate Lucy's credentials.
Figure 8 Successful authentication (Click the image for a larger view)
The ticket granting service request and response are captured in packets 33 and 34. The receipt of the KRB_TGS_REP in packet 34 indicates that Lucy is successfully authenticated. Finally, in packet 38 the AD LDS server passes the bind response back to the workstation, letting Lucy know that she has successfully bound to the AD LDS instance. Although this process involves several steps, the total time for this entire transaction is only about 1/10th of a second.
What would happen if Lucy entered the wrong password? In our example, the authentication service request would fail at packet 25. The failure of the authentication service request would tell the AD LDS server that Lucy's credentials were bad. Instead of issuing a request to the ticket granting service, the AD LDS server would issue a bind response back to the workstation, stating that the credentials were invalid.
Here is a recap of what happened in the successful exchange:
  1. The workstation sends a bind request to the AD LDS server.
  2. The AD LDS server establishes a connection with the DC.
  3. The AD LDS server asks the DC to translate Lucy's SID into an identifier that it can use for authentication.
  4. The DC gives the AD LDS server Lucy's ID.
  5. The AD LDS server gets a ticket granting ticket (TGT) from the DC with Lucy's ID.
  6. The AD LDS server gets a session ticket to itself using Lucy's TGT.
  7. The AD LDS server sends a successful bind response back to the workstation.
This process shows that the connection from the workstation to the AD LDS server is a standard LDAP bind transaction. Then from the AD LDS server to the DC, Kerberos is used to securely authenticate the user.

Setting up a Proxy Authentication Lab
Now that you know how proxy authentication works, let's see how you can set this up in a lab environment. Note that for this exercise, I'll be disabling the requirement for SSL in proxy authentication. As I mentioned earlier, however, please remember that you should not disable this requirement in a real-life implementation.
Before you start, you will need a fully functional domain with a Windows Server 2008 member server and a workstation joined to it. The Windows Server 2008 member server will run AD LDS, and the workstation will be the client endpoint. The advantage in separating these computers is that you can take network captures of the interaction between them. To set up the lab, I'll walk you through the following steps:
  • Install AD LDS on the member server.
  • Disable the SSL requirement for proxy authentication.
  • Import the userProxy class into the AD LDS schema.
  • Create the proxy object and assign permissions to it.
  • Bind to the AD LDS directory with the proxy object.
The first step is to install AD LDS on the Windows Server 2008 member server. In the Server Manager, you will find the option to install LDS in the "Add Roles" wizard. After the role is installed, a new option will appear in the Administrative Tools menu called Active Directory Lightweight Directory Services Setup Wizard. Use this wizard to create a new LDS instance.
When prompted for the name of the application partition, enter any DN you'd like. Remember that LDS supports X.500 naming, so you're not limited to using a "DC=" style name. In my examples, I used "cn=appdir,dc=contoso,dc=com", but I could have also used "cn=appdir,o=contoso,c=us".
After the AD LDS instance is installed, the next step is to disable the SSL requirement for proxy authentication. In the ADSI Edit snap-in (adsiedit.msc), you should connect to the configuration partition of the AD LDS instance using the administrator account you specified during the install. If you don't know the DN of the configuration partition, you can choose "Configuration" from the "Select a well known naming context" dropdown list in the connection settings dialog in ADSI Edit.
Browse to the container "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,CN={guid}" and bring up the properties dialog of the "CN=Directory Service" container. There is a multi-value string attribute in the attribute list called msDS-Other-Settings that lists multiple strings, each indicating a different setting for the AD LDS instance. Edit this attribute and change the string "RequireSecureProxyBind" to a value of 0.
The next step is to import the schema class definition for the userProxy class. You may have already imported it when prompted to do so in the AD LDS wizard. If so, you can skip this step. If you did not already import it, do so with the following LDIFDE.EXE command. Ensure that you specify the name of the AD LDS server and the correct port in the command:
C:\> ldifde –i -f c:\windows\adam\ms-userproxy.ldf –s
   server:port –k –j . –c 
   "cn=schema,cn=configuration,dc=X"
   #schemaNamingContext
Now that the object class has been imported, the proxy object can be created. I'll use LDP.EXE, but you could use another tool or some programmatic method. Using LDP, connect to your AD LDS instance and bind with your administrator credentials. Browse to the DN of your AD LDS instance and then choose the container in which you want to create the proxy object. Right-click on the container and choose Add Child from the dropdown list. In the Add dialog, you will need to enter the DN of the new proxy object in the DN field. For example, you can use "cn=lucy,cn=appdir,o=contoso,c=us".
You'll also need to create two attributes with this object. The first is objectClass, which indicates the kind of object being created. The value for this example should be userProxy. Put this information in the Edit Entry section of the dialog and click the Enter button.
The second attribute to add is objectSID, which contains the SID of the Active Directory user account with which this proxy object is associated. You can obtain this SID with a variety of methods, but I just connected to Active Directory in a separate LDP instance and copied the objectSID attribute from the user account there. After entering this information, the Add dialog should be similar to Figure 9. Finally, click the Run button to commit the change.
Figure 9 Creating a proxy object
In order to use the proxy object you just created, you'll need to give it some permissions. You can accomplish this easily by selecting the "CN=Readers" object under the "CN=Roles" container in LDP. Right-click and choose Modify from the dropdown list. Add an attribute called member and for the value, enter the DN of the userProxy object you created. Remember to click the Enter button before clicking Run. Now the userProxy object should be a member of the Readers group in the LDS instance.
Everything should be set up, so you can now test the proxy authentication. Open a new instance of LDP and connect to the AD LDS server. This time, however, when you bind to your instance, select Simple Bind and type in the DN of the proxy object in the user name field. For the password, enter the password of the Active Directory account you tied this proxy object to. Click OK and you should now be bound to the instance in read-only mode.
Spend some time taking network traces and trying out different bind methods. One exercise might be to turn SSL back on and take a capture of the LDAP bind process then. You could even purposely mistype a user name or password and see what happens to the authentication process.

Conclusion
Don't be alarmed over the difficulty of using proxy authentication. I took the approach of demonstrating this process with LDP and ADSI Edit because it gives you a better look behind the scenes. Because of that, the example I walked you through here illustrates proxy authentication from a very hands-on perspective.
In practice, the lengthy process of creating userProxy objects and manipulating them is usually codified through an identity management system or a custom-developed front end for creating accounts. I encourage you to build your own LDS lab and see for yourself how you can use proxy authentication for integrating your third-party directories and applications.

Ken St. Cyr is a consultant for Microsoft and has designed and implemented directory solutions based on Active Directory since its inception. He recently became one of the first to achieve the Microsoft Certified Master certification for Directory Services. Contact him at ken.stcyr@microsoft.com .

Active Directory
Comprensione di autenticazione proxy in Active Directory Lightweight Directory Services
Ken St. Cyr
 
Riepilogo:
  • Definisce l'autenticazione proxy
  • Perché è utile l'autenticazione proxy
  • Nell'oggetto proxy
  • Cosa succede durante authenticationItem

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 .

Page view tracker