Overview AD Connector

The IDHub AD connector manages accounts and groups for your AD instance. In this AD connector guide you will learn about the supported features of the IDHub AD connector, configurations and schema, how to deploy the connector and more.

note

For more information about the Connector Health and it's status, Click here

Architecture

The connector's architecture is constructed in accordance with the diagram below. The connector architecture primarily consists of a connector application and a target system component. The native communication with the target system is handled by the target system by leveraging the SPI implementation of the Microsoft AD Specific connection. This architecture is implemented because it allows for rapid and straightforward connector deployment as well as precise versioning capabilities.

Features

• Account Management for Users
• Account - Group Management
• Password Management
• Multiple OU Based Search
• Group search from multiple DNs
• AD Sync
• Authentication Features
  • OAuth 2.0 Authentications
  • Multi-factor Authentication(MFA) Management
  • Single Sign On (SSO) Management

Below are the features in details.

Account Management for Users

This section describes the supported features of Microsoft AD Connector for Users management:

Operation	Supported
Create user	Yes
Update user	Yes
Fetch Account	Yes
Account Reconciliation	Yes
Add/Remove Entitlements for User Add/Remove Group Memberships	Yes

Account - Group Management

IDHub AD connector pulls all your security groups that is managed in your AD instance. IDHub pulls those groups as “Entitlements” which you can request access or revoke access for accounts from your IDHub tenant.

Password Management

IDHub AD connector provides you a feature to add a default password for user provisioning. For this you need to add the following under the schemaConfiguration → otherDefaultAttributes section of the account json file of the connector.

"otherDefaultAttributes":{
"userPassword": "Password@123"
} 

If you want that the "User must change password at next logon", then you need to add the pwdLastSet under the schemaConfiguration → otherDefaultAttributes section of the account json file of the connector, as shown below. This can be can additional security configuration, which ensures that even if the initial password is set to userPassword value, user will be asked to change it to their desired pass on logon after they enter initial password.

"otherDefaultAttributes":{
"userPassword": "Password@123"
"pwdLastSet" : "0"
}

pwdLastSet Explanation

This attribute can only be set as true or false.

• When set to true, the pwdLastSet attribute value is set to 0 and it selects the User must change password on logon
• When set to false, the pwdLastSet attribute value is set to -1 and sets this attribute to the current time, and it deselects the User must change password on logon

The default Static Value is false.

Multiple OU Based Search

IDHub AD connector has features so that you can add the search scope to account.json, so that it pulls from multiple OUs. For this you need to use SearchDNs

note

If there is no configuration provided in searchDNs, then default baseDN will be considered.

Search Scope Explanation

• Base (Search Scope = base): The search is limited to entries within BaseDN only.

• One Level (Search Scope = one): The search is limited to entries that are directly one level below the base DN. It does not include the base DN itself or any deeper sublevels.

Example:

If you search with the base DN as ou=Users,dc=example,dc=com and one-level scope, the server will return entries such as cn=John Doe,ou=Users,dc=example,dc=com. But it will NOT search ou=Admins,ou=Users,dc=example,dc=com

• Subtree (Search Scope = sub): The search includes the base DN and all entries at all levels beneath it. This is the most commonly used scope for broader searches.

Example:

If you search with the base DN dc=example,dc=com and subtree scope, the server will return all matching entries from any level below dc=example,dc=com, such as cn=John Doe,ou=Users,dc=example,dc=com, ou=Admins,ou=Users,dc=example,dc=com, etc.

Example Configuration

"schemaConfiguration": {
    "objectClass": [
        "user"
    ],
    "relationshipAttribute": "memberOf",
    "namingAttribute": "cn",
    "defaultBaseContainerDN": "OU=Users,OU=IDHub,DC=idhtest,DC=com",
    "searchDNs": [
        {
            "dn": "OU=Disabled_Users,OU=Users,OU=IDHub,DC=idhtest,DC=com",
            "scope": "sub"
        },
        {
            "dn": "OU=Employees,OU=Users,OU=IDHub,DC=idhtest,DC=com",
            "scope": "sub"
        }
    ]
}

Key points about this configuration

1. The objectClass is set to "user" for all searches, ensuring that only account objects are returned.
2. You can adjust the DNs and add more search configurations as needed for your specific Active Directory structure.
3. The searchDNs array contains objects specifying where and how to search for accounts in the AD structure.
4. Each search configuration includes a DN & scope

Sub scope:

{
  "dn": "OU=Disabled_Users,OU=Users,OU=IDHub,DC=idhtest,DC=com",
  "scope": "sub"
}

This will search the entire subtree under the "Users", “Disabled Users”, “IDHub” organizational unit, including all nested OUs and objects.

Base scope:

{
  "defaultBaseContainerDN": "OU=Users,OU=IDHub,DC=idhtest,DC=com"
}

This will only search for the specific objects at the exact DN specified.

These examples demonstrate how to use different search scopes to control the depth and breadth of searches in IDHub Microsoft AD connector configuration. You can adjust the DNs and add more search configurations as needed for your specific Active Directory structure.

Group Search from multiple DNs

Similar to accounts (users) explained above, you can add search scopes to your groups or entitlements too, which you can add in the entitlements.json file.

Example Configuration

"schemaConfiguration": {
    "objectClass": [
        "group"
    ],
    "relationshipAttribute": "member",
    "namingAttribute": "cn",
    "defaultBaseContainerDN": "OU=Groups,OU=IDHub,DC=idhtest,DC=com",
    "searchDNs": [
        {
            "dn": "OU=Application_Groups,OU=Groups,OU=IDHub,DC=idhtest,DC=com",
            "scope": "sub"
        },
        {
            "dn": "OU=Security_Groups,OU=Groups,OU=IDHub,DC=idhtest,DC=com",
            "scope": "sub"
        }
    ]
}

Key points about this configuration

1. The objectClass is set to "group" for all searches, ensuring that only group objects are returned.
2. You can adjust the DNs and add more search configurations as needed for your specific Active Directory structure.
3. The searchDNs array contains objects specifying where and how to search for groups in the AD structure.
4. Each search configuration includes a DN & scope

Sub scope:

{
  "dn": "OU=Application_Groups,OU=Groups,OU=IDHub,DC=idhtest,DC=com",
  "scope": "sub"
}

This will search the entire subtree under the "Application_Groups", “Groups”, “IDHub” organizational unit, including all nested OUs for objects with the "Application_Groups", “Groups” and “IDHub” objectClass.

Base scope:

{
    "defaultBaseContainerDN": "OU=Groups,OU=IDHub,DC=idhtest,DC=com"
}

This will only search for the specific objects at the exact DN specified.

tip

Click here to learn more about the Search Scope

AD Sync Feature

The AD Sync feature of IDHub AD connector, determines whether synchronization action viz., running a PowerShell command to sync Active Directory user data to Entra ID, should be performed based on certain triggers (like user addition, updates, or deletions). For this you need to add the following in the account.json of the connector.

"adSync":{
"OnUpsert": false,
"OnDelete": false
}

Key points about this configuration

1. onUpsert: This controls whether the Entra Connect synchronization command should be executed when a user is either added to or updated in Active Directory. Setting this to true means the sync command will run on these changes. On false, this setting indicates that the sync command should not be triggered when a user is added to Active Directory (or updated).

2. onDelete: This controls whether the Entra Connect synchronization command should be executed when a user is deleted from Active Directory. Setting this to true ensures that deletions are synchronized to Entra ID. Setting this to false indicates that the sync command should not be triggered when a user is deleted from Active Directory.

info

Click here to learn more about Microsoft Entra Connect

Authentication Features

IDHub uses Keycloak to use its Authentication features. SAML based Single Sign-On and MFA Setup can be done with your Microsoft AD instance outside of Connector features.

Upcoming Features

• Provisioning and De-provisioning of the following
  • Exchange Mailboxes
  • Skype for Business Accounts
  • Active Directory Service Accounts (Managed Service Accounts/Group Managed Service Accounts)
  • Active Directory Contacts