Microsoft Active Directory Server Connector
This section of the documentation contains technical specifications about the Microsoft Active Directory Server Connector that is implemented to link ASM Core and Microsoft Active Directory.
It describes the details of the third-party application, that is, Microsoft Active Directory including:
The name of the .NET assembly file
Connection methodology
The resource and link types that can be discovered on the application
The attributes of each resource and link types that can be imported into the ASM Core Configuration Management Database (CMDB)
For compatibility and version support details, refer to the ASM Connector Matrix.
You should familiarize yourself with the information in Installing Connectors before installing any connectors, and read the Integration topics for more information on how to configure them.
Use Case Scenario
Directory servers, such as Microsoft Active Directory Server, store information about an organization’s users in groups and organizational units. ASM Core person entities are defined as person records. These persons can act as Users, Analysts, or both. Organizations that use ASM Core may want to synchronize these sources to import users from directory servers into ASM Core as persons.
The table below presents an integration scenario based on the Microsoft Active Directory Server Connector.
Scenario | An organization maintains a list of all its employees in Microsoft Active Directory. The groups are configured in Active Directory based on the department to which an employee belongs. One such group in Active Directory is the Help Desk group. |
Goal | The organization intends to import all users classified under the Help Desk group into ASM Core as Analysts. |
Action | The Microsoft Active Directory Server Connector is installed, the source is created, the resource type mappings are set up, the Active Directory group is specified and the Active Directory users are imported into ASM Core as persons. |
Connector Description
The Microsoft Active Directory Server Connector is part of the base kit of ASM Core. As soon as ASM Core is installed, the connector is available for configuration and use from the Integration menu. Therefore, there is no need to install it separately.
This connector must be scheduled.
The table below provides a description of the Microsoft Active Directory Server Connector.
Information fields | Name |
Connector | LDAP AD <-> ASM Core |
Third-party application | Microsoft Active Directory |
Assembly | Infra.Connector.LDAP.NED.dll |
Connector class | ADConnector |
Configuration file | Infra.Connector.LDAP.AD.icnf |
Connection methodology | LDAP v3, by using Microsoft .NET System.DirectoryServices library |
Connection Parameters
The table below provides a description of the Microsoft Active Directory Server connection parameters.
Parameters | Description |
LDAP Server Path | The full LDAP path of the directory server, incorporating: Protocol, almost always LDAP:// For LDAP over SSL, do not use LDAPS://. Use LDAP:// and select the SSL checkbox. Server Portal number (optional) Defaults to 389 for non SSL, 636 for SSL. Root naming context Expanded examples: Server Bind LDAP://myldapserver.mydomain.com/dc=mydomain,dc=com Server-less Bind LDAP://dc=mydomain,dc=com Using custom port no 80389: LDAP://myldapserver.mydomain.com: 80389/dc=mydomain,dc=com |
User DN/ID | The Windows account that is used to connect to the Active Directory server, in the form: User principal name, that is, login@domain. For example, sk@demo.com. Flat domain name \ NT account name. For example, demo\sk. If not provided, the connector will use the credentials of the executing accounts, in this case, the web server and Integration service. Ensure that both these accounts have appropriate rights. |
Password | Provided |
Server Bind | Checkbox Select this option if the connection string provides a specific server for optimal performance. Do not select this option for server-less connection strings. |
SSL | Checkbox Indicates that communication should use SSL. |
Kerberos/NTLM | Checkbox Indicates that Kerberos/NTLM should be used to authenticate the connection. |
NT Domain Name | A value that is assigned to the NT domain name property of the imported person. This should be specified for multi-domain implementations to ensure the uniqueness of login IDs. |
Delete Disabled Person Records | Checkbox Selecting this option deletes person records in ASM Core if the corresponding records are disabled in the Active Directory. If any user records are reactivated on the Active Directory side, the matching person records will be restored in ASM Core during the next scheduled Active Directory scan. The disabled status in any Active Directory record is shown in the field userAccountControl. |
The Microsoft Active Directory Server Connector and other LDAP connectors permit users on one source to be members of groups on other sources, scheduled within the same integration schedule.
When a group member is found, their name is used to ascertain which source they belong to. Only sources with a defined root naming context are considered for selection. The user is associated with the source with the longest root naming context contained at the end of the user’s DN. See Root Naming Assessment for more details.
The Update Date field in the information section of the person record shows the date of the last update in the ASM database and not the last date the user had modified in Active Directory database.
Resolve Functionality
Find out more about additional information on Resolve Functionality
Active Directory allows specifying a manager value for every user. This section describes how the Resolve functionality handles this particular Active Directory Manager field:
Background | One Active Directory user possesses one Active Directory Manager |
Expected operation | In the context of the Microsoft Active Directory Server Connector, the Resolve capability allows the importation of both user and its manager, and also the creation of a link between them. If the manager cannot be found or imported or if it is not mapped, the Resolve functionality would resort to a default user-defined value for the Manager field in the ASM Core user record. |
The default Active Directory schema is a maximum of one manager user.
Miscellaneous
Although, it is possible to customize the Active Directory schema so that a unique user can have several managers, this aspect is not handled by the Resolve functionality.
Active Directory base mapping
Person records in ASM Core must be created with a minimum set of fields populated. In addition, users imported by the Microsoft Active Directory Server Connector that need to log in to ASM Core are typically authenticated by Integrated Security. For this to be successful, an additional number of fields needs to be populated with the correct information from Active Directory.
The table below lists the recommended base field mappings that administrators should configure for all person mappings from Active Directory. This base mapping ensures that these minimum requirements are met. The left-hand column values reflect the current field names as viewed in ASM Core.
ASM Core person field | Active Directory user field |
Login ID | Login ID |
NT Account Name | User NT Account Name |
FQDN | User Principal Name |
NT Domain Name | NT Domain Name |
Surname | Surname |
First Name | First Name |
Background | Description |
Email ID | |
Telephone | Telephone |
Job title | Job Title |
Root Certificate Installation for IIS
To install the root certificate for Internet Information Service (IIS), follow these steps:
Click Start > Run and type mmc.
Click File > Add/Remove Snap-in.
In the Add/Remove Snap-in window, click Add .
In the Add Standalone Snap-in dialog box, select Certificates from the list of Available Standalone snap-ins and then click Add .
In the Certificate Snap-in dialog box, select Computer Account and then click Next.
In the Select Computer dialog box, select Local Computer.
Select Finish.
Close the Add Standalone Snap-in dialog box and click OK in the Add/Remove Snap-in dialog box.
Right-click Trusted Root Certification Authorities and select All Tasks > Import .
Use the Browse button to find and select the root certificate that you intend to import.
Select Next. After the import process is over, click Finish. The root certificate is now installed. Ensure that the root certificate appears under Trusted Root Certification Authorities.
For the installation of the certificate, read Certificate Installation: Installing your IIS SSLcertificate in Microsoft IIS.
Resource Types
The Microsoft Active Directory Server Connector allows for exposure and importation of users and their properties as follows. It also allows for exposure and importation of Computer and Print Queue resources.
User
The table below lists the generic information on Microsoft Active Directory users.
Information fields | Description |
Mapped to | objectClass=user objectCategory=person |
Description | Represents a user stored within Microsoft Active Directory |
Must be received by Group | True |
Group Types
Groups are used to classify the Microsoft Active Directory users into different categories. For instance, one group for development, another group for documentation and so on. These groups can be of three types: Container, Group and OU (Organizational Unit) as given in the table below.
Group type | Object class |
Container | objectClass=container |
Group | objectClass=group |
OU | objectClass=organizationalunit |
When importing Active Directory users, the particular group from which you intend to import the users must be specified.
Schema
The schema is the list of attributes that are available for each individual Active Directory user, as listed in the table below.
Name | Data type | Mapped to property |
Object GUID | String | GUID |
Last Modified | dateTime |
|
Surname | String |
|
First Name | String | givenName |
Description | String | description |
Login ID | String | userID |
User NT Account Name | String | sAmAccountName |
NT Domain Name | String | Flat Domain Name connection parameter |
User Principal Name | String | userPrincipalName |
User Distinguished Name | String | dn |
String | ||
Full Address | String | streetAddress |
Address Line 1 | String | streetAddress (line #1) |
Address Line 2 | String | streetAddress (line #2) |
Address Line 3 | String | streetAddress (line #3) |
Telephone | String | telephoneNumber |
Fax | String | facsimileTelephoneNumber |
State | String | s |
Country | String | co |
Post/Zip Code | String | postalCode |
Job Title | String | title |
Manager | Resource Reference | manager |
Account Disabled | Boolean | userAccountControl > bit #2 |
City/Town/Suburb | String | I |
Location | String | location |
Cell | String | mobile |
Locality | String | l |
Department | String | department |
Office | String | physicalDeliveryOfficeName |
Company | String | company |
Computer
A Computer is a resource stored as objectclass=Computer on the Active Directory Server:
Date modified
Distinguished name
Name
DNS host name
Object GUID
OS
OS service pack
OS version
Print Queue
A Print Queue is a resource stored as objectclass=PrintQueue on the Active Directory Server:
Last modified
Name
Driver name
GUID
Port name
URL
Server name
Print Share name
Distinguished name
Printer name
Color
Link Types
No link types are defined for this connector.
More about Resolve Functionality
In relation to the Resolve functionality that leads to a user-defined default value, here are some examples of when such situations can occur. There are several reasons why the manager record might not be found:
They belong to a different domain and that domain is not configured —Active Directory integration supports cross-domain references assuming all referenced domains are configured.
They do not belong to a mapped group.
They are excluded by user-configured mapping.
Imports are regulated. So, the corresponding user records are not automatically created until a user intervenes through Federated CMDB Admin.
Root Naming Assessment
Can groups and users who are members of the groups belong to different domains?
Yes. There are several requirements for this to work:
All domains that the target users and groups belong to must have a corresponding directory server defined in ASM Core.
All domains involved are required to be a child domain to a common parent or have a parent-child relationship.
For each member of a group, ASM Core does not associate the user with the directory server whose root naming context is the longest trailing substring of the user’s distinguished name. In other words, the user is identified as being located on the directory server with the longest naming context that ends the user’s distinguished name.
Example of Root Naming Assessment
Assume that there are three directory servers configured:
LDAP://server1/dc=mydomain,dc=com
LDAP://server2/dc=sub1,dc=mydomain,dc=com
LDAP://server3/dc=sub2,dc=mydomain,dc=com
Against server 2, the following group is mapped:
Group1, DN: cn=Group1,dc=sub1,dc=mydomain,dc=com
This group has two members:
User1, DN: cn=User1,dc=sub1,dc=mydomain,dc=com
User2, DN: cn=User2,dc=sub2,dc=mydomain,dc=com
ASM Core associates User1 with server 2 because the server 2 root naming context is the longest naming context contained at the end of User1’s DN. Although the trailing part of server 3’s root naming context also concludes the user’s DN, it is not considered because not all of the naming context is included. Although all of server 1’s root naming context is found at the end of the user’s DN, server 2 is given preference because its root naming context is longer.
Similarly, User2 is associated with server 3 and not server 2 because there is no match, and not server 1 because server 3’s root naming context is longer.