How do I set Active Directory using LDAP as the User Repository in VigilEnt Policy Center (VPC)? (NETIQKB36726)

  • 7736726
  • 02-Feb-2007
  • 26-Sep-2007

Resolution

goal
How do I set Active Directory using LDAP as the User Repository in VigilEnt Policy Center (VPC)?

goal
How do I set the User Repository in VigilEnt Policy Center (VPC) to point to Active Directory?

goal
How do I locate the full DN of the binding account using native command line tools?

fact
VigilEnt Policy Center 3.x

fact
VigilEnt Policy Center 4.1

fact
VigilEnt Policy Center 2.1x

fact
VigilEnt Policy Center 4.0

fix

To set the User Repository in VigilEnt Policy Center (VPC) to point to Active Directory:

  1. Log into the VPC admin site with either the admin account or an account that has administrative privileges in VPC. 
  2. Select Administration | Options | Repository
  3. Select My users are in an LDAP server.
  4. In LDAP URL, point to your Active Directory server in the following format:    LDAP:// <server name> or  the IP address of the server and the LDAP TCP port.

    • The default LDAP TCP port is 389.
    • The default LDAP TCP Global Catalog port is 3268.
  5. The Search Base must be set.  Set the context of where your users reside. You can point the search base to a specific container. For example:

    • cn=Users,dc=domain,dc=com

    This sets the repository to the Users container and will only be able to see users that are in the default Users container. This will work if all the users are created and reside in this container. It is recommended that the Search Base be set to the root level or highest level in your directory structure.  You will be able to browse your whole directory structure and not be limited to one container. For example:

    • dc=domain,dc=com 

    To be able to set the search base for Active Directory you will need to have access to the Administrative tool Active Directory, Users and Computers. This tool will give you the ability to browse the directory structure. The root level will be on the top when you open the tool. The fully qualified domain name: Domain.com.

    When the search base or the binding account is supplied, you will have to do it in Distinguished Name (DN) format. The context lets you know where, specifically, an object resides in your directory structure. This will be done with attributes. Listed below are some common directory attributes:

    • CN=Common Name
    • OU=Organizational Unit
    • DC=Domain Class or Domain Component

  6. Supply the default location where users and groups are located.  These fields are optional.  The following are settings if you have default containers where users and groups are located:
    • Directory Base for New Users
    • Directory Base for New Groups

  7. The next options that are available are either doing an Anonymous Bind or a Direct Binding (DN Binding). The differences in the bindings are explained below:

    • Anonymous Binding - An anonymous bind is where you supply the configuration parameters to your LDAP server without doing a direct binding. In other words, not authenticated to the directory structure.  This will query just your LDAP server and return the results that it can. It is recommended that you do a direct binding to your directory structure. Some organizations may have anonymous binding turned off for security reasons.  If you can do an anonymous binding to the directory structure you will be limited on what objects you can see for browse.
    • Direct Binding - The desired configuration is to do a direct binding with an account that has the authority to browse the whole directory structure or the context of what the search base is set to. The ability to enumerate members of groups is also required..
        There isn't a standard on the directory permissions. Binding with a domain user in one directory may be able to browse the whole structure and binding as a admin account may be required in another. If the configuration is pointing to the global catalog server with multiple sites, an enterprise admin account for the binding is recommended. 

      If possible, the best scenario is to do the binding with an admin type account and if desired, can work down to an account with the minimal required permissions required to browse the directory structure. This will have to be done by making the changes and testing. When you use the option of Bind DN, you are doing a direct binding to the directory structure DN format.  The DN is the context of where an object resides in the directory structure.  This way, the context works and lets you know where the object is in a directory structure is to let you know where the object is going back up to the root level. For example:

      • cn=<display name>,cn=Users,ou=<parent directory>,dc=Test,dc=com  (for additional assistance in constructing this LDAP path, please see the Note below.)
      This example tells you where the account is in relationship to the root level.  Starting in the Users container and working itself up to the root level Test.com. The context of DN is always enumerated where the object resides going up to the root level. The user is test user and in this DN format it tells you where the object resides in the directory structure, enumerating from the object back to the root level. Note: LDAP is case sensitive.
    • Select the Advanced  tab to get the selections for attribute mappings. There are 3 templates available for selection that will fill all of the fields with the correct attributes for the chosen directory type: Default, Exchange, and Active Directory.  Once you select the template, it updates all of the fields for the attributes for the objects.  The settings can be manipulated once the desired settings have been supplied select update.
    • Supply the account for the Bind DN and the password for the account and click Update. You should see a message saying ?Information Updated?.
.


note

To locate the full DN of the binding account, it may be helpful to use native command line tools. 

To search for your binding account by sAMAccountName, you could use the command:

DSQUERY USER -samid (name you are looking for)
An example of this where the binding account has a sAMAccountName of policy would look like:

C:\>dsquery user -samid policy

The return of this account with the full DN looks like:

"CN=Policy,CN=Users,DC=BauerADM,DC=houston,DC=netiq,DC=local"


To search for your binding account by Name, use the command:

DSQUERY USER -name (The name you are looking for.)
An example of where the binding account has the name of policy:

 C:\>dsquery user -name policy

The return of this account with the full DN looks like:

"CN=Policy,CN=Users,DC=BauerADM,DC=houston,DC=netiq,DC=local"

You could then copy the LDAP path in between the quotes (do not copy the quotes) and paste that into the text box labeled Bind DN on the Repository tab of the VPC Admin site.

An example of what you copy between the quotes: CN=Policy,CN=Users,DC=BauerADM,DC=houston,DC=netiq,DC=local

Note:  For any account that contains a space in the BIND DN path, encapsulate the entire name in a double quotes (" , ").  

An example of an account containing space in the path: CN=Policy Admin,CN=Users Folder,DC=BauerADM,DC=houston,DC=netiq,DC=local  
 
How to enter this example into VPC: 
CN="Policy Admin",CN="Users Folder",DC=BauerADM,DC=houston,DC=netiq,DC=local



note
IMPORTANT NOTE: LDAPs are case sensitive. Remember to match your command strings to your environment.

Additional Information

Formerly known as NETIQKB36726