Share via

Step 7: Practice Managing Authentication

  • Article

Applies To: Windows Server 2008

Users (security principals) request directory data from the Active Directory Lightweight Directory Services (AD LDS) through directory-enabled applications, which in turn make requests to AD LDS using Lightweight Directory Access Protocol (LDAP). To grant these requests, AD LDS must first verify the users’ credentials or successfully authenticate (bind) users into the directory. The term "security principal" refers to any object that has a security identifier (SID) and that can be assigned permissions to directory objects.

You can bind to an AD LDS instance in the following ways:

  • As an AD LDS security principal (when the user account resides directly in AD LDS)

  • As a Windows security principal (when the user account resides on a local computer or in an Active Directory Domain Services (AD DS) domain)

  • Through an AD LDS proxy object

Managing AD LDS authentication includes the following tasks:

  • Set a password for an AD LDS security principal

  • Bind as an AD LDS security principal

  • Bind as a Windows security principal

  • Bind through an AD LDS proxy object

Set a password for an AD LDS security principal

You can set and modify passwords for AD LDS security principals:

  • Set or modify a password for an AD LDS security principal using the ADSI Edit snap-in

  • Set a password for an AD LDS security principal over an encrypted, non-SSL connection using Ldp.exe

You can also set and modify passwords for AD LDS security principals over a Secure Sockets Layer (SSL) connection. For more information about configuring LDAP over SSL, see Appendix A: Configuring LDAP over SSL Requirements for AD LDS.

Set or modify a password for an AD LDS security principal using the ADSI Edit snap-in

The AD LDS user for whom you set or modify a password must use the new password the next time that the user logs on.

Membership in the Administrators group of the AD LDS instance is the minimum required to complete these procedures. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (https://go.microsoft.com/fwlink/?LinkId=83477). By default, the security principal that you specify as the AD LDS administrator during AD LDS setup becomes a member of the Administrators group in the configuration partition.

To set or modify the password of an AD LDS user using ADSI Edit

  1. Click Start, point to Administrative Tools, and then click ADSI Edit.

  2. Connect and bind to the directory partition that contains the AD LDS user for whom you want to set or modify the password.

    For this exercise, connect and bind to the o=Microsoft,c=US application directory partition, as described in the procedure "To manage an AD LDS instance using ADSI Edit" in Step 3: Practice Using AD LDS Administration Tools.

  3. Browse to the directory object that represents the AD LDS user, and then right-click the directory object.

    For this exercise, right-click the user account CN=Mary North, which you created in procedure "To create an AD LDS user" in Step 4: Practice Managing AD LDS Organizational Units, Groups, and Users.

  4. Click Reset password, and then type a password for the user in New password and in Confirm password.

Set a password for an AD LDS security principal over an encrypted, non-SSL connection using Ldp.exe

The AD LDS user for whom you set or modify the password must use the new password the next time that the user logs on.

Membership in the Administrators group of the AD LDS instance is the minimum required to complete these procedures. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (https://go.microsoft.com/fwlink/?LinkId=83477). By default, the security principal that you specify as the AD LDS administrator during AD LDS setup becomes a member of the Administrators group in the configuration partition.

To set or modify the password of an AD LDS user using Ldp.exe over an encrypted, non-SSL connection

  1. Click Start, and then click Server Manager.

  2. In the console tree, double-click Roles, and then click Active Directory Lightweight Directory Services.

  3. In the details pane, under Advanced Tools, click Ldp.exe.

  4. On the Options menu, click Connection Options.

  5. In Option Name, click LDAP_OPT_SIGN, type 1 in Value, and then click Set.

  6. In Option Name, click LDAP_OPT_ENCRYPT, type 1 in Value, click Set, and then click Close.

  7. Connect and bind to the AD LDS instance that contains the AD LDS user for whom you want to set or modify the password. For more information about how to connect and bind to an AD LDS instance with Ldp.exe, see the procedure "To manage an AD LDS instance using Ldp.exe" in Step 3: Practice Using AD LDS Administration Tools.

  8. On the View menu, click Tree, leave BaseDN blank, and then click OK.

  9. Browse to the directory partition that contains the AD LDS user for whom you want to set a password.

    For this exercise, select the user account CN=Mary North that you created in the procedure "To create an AD LDS user" in Step 4: Practice Managing AD LDS Organizational Units, Groups, and Users.

  10. Right-click the AD LDS user, and then click Modify.

  11. In Attribute, type userpassword, and then, in Value, type the new password for the account.

  12. Click Enter, and then click Run. The details pane displays a message similar to the following:

    ***Call Modify...
ldap_modify_s(ld, 'CN=Mary North,O=Microsoft,C=US',[1] attrs);
Modified "CN=Mary North,O=Microsoft,C=US".

Bind as an AD LDS security principal

In this exercise, you bind to an AD LDS instance as an AD LDS security principal.

To bind as an AD LDS security principal

  1. Click Start, and then click Server Manager.

  2. In the console tree, double-click Roles, and then click Active Directory Lightweight Directory Services.

  3. In the details pane, under the Advanced Tools, click Ldp.exe.

  4. On the Connection menu, click Connect. Connect to an AD LDS instance as described in procedure "To manage an AD LDS instance using Ldp.exe" in Step 3: Practice Using AD LDS Administration Tools.

  5. On the Connection menu, click Bind.

  6. Under Bind type, select Simple Bind, type CN=Mary North,OU=AD LDS Users,O=Microsoft,C=US in the User field, along with the password that you just assigned to this account in the Password field, and then click OK.

    The details pane displays a message similar to the following:

    res = ldap_simple_bind_s(ld, 'CN=Mary North,OU=AD LDS Users,O=Microsoft,C=US', <unavailable>0; // v.3
Authenticated as: 'CN=Mary North,OU=AD LDS Users,O=Microsoft,C=US'.

Note

By default, new AD LDS users (such as Mary North) are granted Read access to the top-level container of a given directory partition, a permission which is inherited by all objects on the partition.

Bind as a Windows security principal

AD LDS allows the use of Windows security principals for authentication and access control. Windows users can be members of AD LDS groups.

By default, a Windows user binding to an AD LDS instance receives membership only in the AD LDS groups to which that user has been explicitly added as member.

In this exercise, you bind to an AD LDS instance as a Windows security principal using the ADSI Edit snap-in.

To bind as a Windows security principal

  1. Add the Windows security principal to the AD LDS default groups CN=Readers or CN=Administrators, following the general directions for adding members to groups as described in the procedure "To add or remove members to or from an AD LDS group" in Step 4: Practice Managing AD LDS Organizational Units, Groups, and Users.

Note

This step is necessary because, by default, Windows security principals with no access to directory data cannot bind to an AD LDS instance with ADSI Edit.

  1. Click Start, point to Administrative Tools, and then click ADSI Edit.

  2. On the Action menu, click Connect to. The Connection Settings dialog box appears.

  3. In Select or type a domain or server: (Server | Domain[:port], type the Domain Name System (DNS) name, NetBIOS name, or IP address of the computer on which the AD LDS instance is running, followed by a colon (:) and the LDAP communication port that the AD LDS instance to which you want to connect is using.

    In this exercise, AD LDS is running on the local computer; therefore, you can type localhost:389.

  4. Under Connection point, click Select or type a Distinguished Name or Naming Context, and then type o=Microsoft,c=US.

  5. Click Advanced, and then click Specify Credentials.

  6. Under Connect using these credentials, type the domain, user name, and password of your Windows principal, and then click OK.

  7. In the console tree of the ADSI Edit snap-in, double-click AD LDS Demo, and then double-click O=Microsoft,c=US. ADSI Edit now shows the application directory partition.

  8. In the console tree, click any container to view the objects in that container.

Bind through an AD LDS proxy object

In addition to binding as a Windows user or as an AD LDS user, you can also bind to an AD LDS instance by using AD LDS bind redirection. When you use bind redirection, AD LDS can accept and process bind requests to an AD LDS proxy object that contains as one of its attributes the SID from an AD DS security principal. With AD LDS, you can use bind redirection to provide AD DS users with access to both AD LDS data and AD DS data, using AD DS domain credentials for single sign-on (SSO). In addition, you can use AD LDS proxy objects to store user data that is specific to a particular application in AD LDS, while using AD DS to store more widely used directory data.

Important

Bind redirection enables a user to bind to AD LDS by means of a simple bind while still using AD DS credentials. Other types of binding with AD DS credentials work without requiring a proxy, but a simple bind does not. Proxy binding works only for a simple bind.

The AD LDS .ldf files, which you can import into the AD LDS schema during AD LDS setup, contain an object definition for the object userProxy, which you can use for bind redirection. This object contains attributes that include a distinguished name and a SID. By creating a userProxy object in AD LDS—specifying a distinguished name to be used for binding—and by using a valid SID from an AD DS user account, you can bind to AD LDS using bind redirection.

For the following exercises, it is assumed that you have already imported the optional user classes into the AD LDS schema as described in the procedure "To create a new AD LDS instance by using the Active Directory Lightweight Directory Services Setup Wizard" in Step 2: Practice Working with AD LDS Instances.

The tasks for binding to an AD LDS instance through a proxy object include the following:

  • Configure SSL requirements

  • Create an AD LDS proxy object

  • Bind through the proxy object

  • Test the bind through the proxy object

Configure SSL requirements

By default, binding to AD LDS with bind redirection requires an SSL connection. SSL requires the installation and use of certificates on the computer running AD LDS. For more information about configuring LDAP over SSL, see Appendix A: Configuring LDAP over SSL Requirements for AD LDS.

For the following exercises, you can, as an alternative, disable the requirement for SSL in your AD LDS test environment, as described in the following procedure.

Note

Disabling the requirement for SSL for bind redirection causes the password of a Windows security principal to be passed to the computer running AD LDS, without first being encrypted. Therefore, you should disable the SSL requirement only in a test environment.

Membership in the Administrators group of the AD LDS instance is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (https://go.microsoft.com/fwlink/?LinkId=83477). By default, the security principal that you specify as the AD LDS administrator during AD LDS setup becomes a member of the Administrators group in the configuration partition.

To disable the SSL requirement for bind redirection

  1. Click Start, point to Administrative Tools, and then click ADSI Edit.

  2. On the Action menu, click Connect to.

  3. In Select or type a domain or server: (Server | Domain[:port], type localhost:389.

  4. Under Connection point, click Select a well-known naming context, click Configuration, and then click OK.

  5. In the console tree, browse to the following container object in the configuration partition: CN=Directory Service,CN=Windows NT,CN=Services.

  6. Right-click CN=Directory Service, and then click Properties.

  7. In Attributes, click msDS-Other-Settings, and then click Edit.

  8. In Values, click RequireSecureProxyBind=1, and then click Remove.

  9. In Value to add, type RequireSecureProxyBind=0, click Add, and then click OK.

Create an AD LDS proxy object

You are now ready to create an AD LDS proxy object for your AD DS user.

Membership in the Administrators group of the AD LDS instance is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (https://go.microsoft.com/fwlink/?LinkId=83477). By default, the security principal that you specify as the AD LDS administrator during AD LDS setup becomes a member of the Administrators group in the configuration partition.

To create an AD LDS proxy object

  1. Click Start, and then click Server Manager.

  2. In the console tree, double-click Roles, and then click Active Directory Lightweight Directory Services.

  3. In the details pane, under the Advanced Tools, click Ldp.exe.

  4. Connect and bind to your AD LDS instance. For more information about connecting and binding to an AD LDS instance with Ldp.exe, see the procedure "To manage an AD LDS instance using Ldp.exe" in Step 3: Practice Using AD LDS Administration Tools.

  5. On the Ldp Browse menu, click Add child.

  6. In Dn, type cn=testproxy,o=microsoft,c=us as the distinguished name for the new userProxy object to be created in the O=Microsoft,C=US container.

  7. Under Edit Entry, type the following, and then click Enter:

    • In Attribute, type ObjectClass.

    • In Values, type userProxy.

  8. Again, under Edit Entry, type the following, and then click Enter:

    • In Attribute, type objectSID.

    • In Values, type the valid SID of a user in AD DS.

      To retrieve the SID of an AD DS user, type the following (as a single command) at a command prompt:

      dsquery user -samid <account> | dsget user -sid

      where <account> represents the user logon name whose SID you want to retrieve. In this command, the results of dsquery are piped to dsget.

Important

The AD DS user that you are creating the proxy object for must not a member of any AD LDS groups. You cannot successfully create proxy objects for Windows security principals that belong as members to AD LDS groups. However, after the proxy object for an AD DS user is created, the AD DS user can then be added to any AD LDS groups.

  1. Make sure that the Synchronous check box is selected.

  2. Click Run. This adds the userProxy object, with the attributes that you specified, to the AD LDS directory store.

    The details pane displays a message similar to the following:

    Added {cn=testproxy,o=microsoft,c=us}.

  3. To disconnect from your AD LDS instance, on the Connection menu, click Disconnect.

Bind through the proxy object

Now, you can bind to your AD LDS instance using the AD LDS proxy object and bind redirection.

To bind as an AD LDS proxy object through bind redirection

  1. On the Connection menu, click Connect, and then connect to your local AD LDS instance on a new connection (localhost:389).

  2. On the Options menu, click Connection Options.

  3. In Option Name, click LDAP_OPT_SIGN, type 1 in Value, and then click Set.

  4. In Option Name, click LDAP_OPT_ENCRYPT, type 1 in Value, click Set, and then click Close.

  5. To bind to your AD LDS instance, on the Connection menu, click Bind.

  6. Under Bind type, click Simple bind.

  7. In User, type cn=testproxy,o=Microsoft,c=us. This represents the proxy object that you created in the previous procedure.

  8. In Password, type the password that is associated with the AD DS user that you created the proxy object for, and then click OK.

    The details pane displays a message similar to the following:

    Authenticated as: "CN=testproxy,O=Microsoft,C=US'.

Test the bind through the proxy object

By default, a Windows security principal binding to an AD LDS instance receives membership only in the AD LDS groups to which that user has been explicitly added as member. When a user binds to an AD LDS instance through a proxy object, the user receives membership in the Users group on each naming context that is held by the AD LDS instance.

You can use this difference in group memberships to demonstrate the functional difference between binding to an AD LDS instance as a Windows user and binding to an AD LDS instance through a proxy object.

To test a bind to an AD LDS instance through a proxy object

  1. In the O=Microsoft,C=US directory partition, add the Users group as a member of the Readers group, following the general directions for adding members to groups as described in the procedure "To add or remove members to or from an AD LDS group" in Step 4: Practice Managing AD LDS Organizational Units, Groups, and Users.

  2. Using Ldp.exe, bind to your AD LDS instance as an AD DS user (other than the AD LDS administrator, which receives full access to all partitions by default).

  3. Attempt to read any object in the O=Microsoft,C=US directory partition.

    Your attempt should fail, because the AD DS user does not have access to the partition by default.

  4. Using Ldp.exe, bind to your AD LDS instance through the proxy object that you created, as described in the previous procedure.

  5. Attempt to read any object in the O=Microsoft,C=US directory partition.

    This time, your attempt should succeed. Binding to the AD LDS instance through the proxy object should enable you to read the partition successfully because users who bind to an AD LD instance through a proxy object automatically receive membership in the Users group and you added the Users group to the Readers group in step 1 of this procedure.