Pro tips for Active Directory and IdentitiyIQ

[#1]

Hello,

Here is a list of best practices for AD to consider that can help you get ready for a smooth integration between your Active Directory and IdentityIQ.

1. Consistent naming conventions for all account types and groups (naming pertains primarily to samaccountname). Account names apply to:

   1. primary accounts

   2. secondary accounts (i.e. server or workstation admin linked to a human)

   3. service / shared / test accounts (not linked to a human)

   4. mailboxes

   5. distribution groups

   6. security groups

   7. contacts

2. CN values utilize samaccountname so that they do not need to be updated as the result of name changes.

3. employeeType attribute is populated to identify all potential account types: contractor, employee, service, admin, etc.

4. Primary accounts contain sufficient data to be easily correlated to the correct human identity

5. Secondary accounts (admin/privileged) store account ownership (who does this account belong to?) in an attribute so that they can be correlated to the correct human identity

6. Service accounts (non-human accounts) indicate ownership (if this ownership is not already stored elsewhere like a PAM system) so that the owner can be set in the service cube owner attribute

7. OUs are defined and organized to make finding accounts and groups easier

   1. Separate OU is defined for secondary accounts

   2. Separate OU is defined for service/shared accounts

   3. Separate OU is defined for disabled accounts

   4. Separate OU for accounts on Legal Hold w/restricted access

8. Group attributes are populated to facilitate various identity management use cases

   1. Groups have owners, descriptions and are stored in an appropriate OU

   2. Group names are consistent between business applications

   3. Birthright groups are easily distinguishable via naming convention or extended attribute

   4. Privileged groups are easily distinguishable via naming convention or extended attribute

   5. Dynamically assigned groups (groups that are auto-assigned based on identity data) are easily distinguishable via naming convention or extended attribute

9. If possible, remove nested groups in favor of a flattened structure (makes certifications easier) – This might be difficult to enforce due to a Microsoft recommendation to use Nested Groups to address a token bloat issue

10. Set expiration date (accountExpires) for non-Employee accounts (Contingent Worker, Vendor, etc…)

11. Consistent password policy for all primary accounts

    1. Strong password policy for secondary and service accounts (minimum 12 characters)

    2. Multi-Factor Authentication for secondary and service accounts

12. sAMAccountName, mail, and userPrincipalName attributes should be unique throughout the entire forest

[jason_raney]

This is great and thanks. What about adding best practices for AD schema items and best practices for Attribute Examples Names, Type, Properties for 'Account' and 'Group' objects?

Attribute Examples:

Account Object ( Native Object Type: User |  Identity Attribute: distinguishedName | Display Attribute: sAMAccountName )

name                       Description               Type       Properties

memberOf               Group Membership     group     Managed, Entitlement, Multi-Valued

Group Object ( Native Object Type: Group |  Identity Attribute: distinguishedName | Group Hierarchy Attribute: memberOf | Display Attribute: sAMAccountName )

name                      Description                                                                         Type       Properties

memberOf              Group Membership                                                               group     Entitlement, Multi-Valued, Indexed

managedBy            DN of the user that is assigned to manage this object.        string

member                  List of users that belong to the group.                                  string     Multi-Valued

[tp1]

I would be interested in best practices with respect to using multiple AD App definitions to align with a tiered AD delegation model where you would not want to use the same service account for all actions (i.e. end-user accounts provisioning/update using one service account and privileged accounts provisioning/update via a separate service account). This is necessary to limit exposure should an individual service account be compromised.