Wow. It has been a long time since I have thought about AD integration from a CM 3x/4x box. Which version are you running? I have integrated CM 4.x with MS AD (a while ago) and here is my recollection on things. First, you create a "Cisco Base" OU in your AD tree (e.g. ou=cisco,dc=mycompany,dc=priv). The service account you use to integrate CM with AD will need to have full permissions to this OU. This OU is used by the CM directory account to create custom user and application profiles, which are leveraged heavily by CM for custom Cisco attributes. This OU is where most of the action happens. However, there is a need for the directory account to modify certain user object attributes:
1. ciscoatGUID: A unique ID generated by the directory plugin and assigned to a user. It appears to be based on date and time of creation.
2. ciscoatProfileString: The full context for the Cisco user profile assigned to the User in question.
3. ciscoatProfile: Same as ciscoatProfileString, included for backward compatibility.
4. telephonenumber: AD user attribute that is used by CCMAdmin and Corporate Directory to search for phone numbers. (Read by directory account)
There are other attributes that are ready by the directory account, which may include a custom attribute that you used to uniquely identify the user objects to sync from (e.g. samAccountName, employeeID, etc.).
Now, as far as permissions. Here is what I can remember.
1. Root DSE. (Read All) (this is typical for authenticated accounts, which the CM directory account would fall into)
2. Cisco Base OU (e.g. ou=cisco,dc=mycompany,dc=priv): Full Control
3. User objects in the user search base that you want CM directory account to use for CM users (see below). You can assign custom permissions as follows:
- List Contents, Read All Properties, and Read Permissions on all user objects
- Read and Write permissions for the ciscoatUserProfile, ciscoatUserProfileString, and ciscoatGUID attributes. Each CM user will have these attributes. The CM directory account uses these attributes to "point" to the appropriate/related object in the Cisco Base OU
- Read and Write permission for the telephoneNumber user object attribute
4. If there are any OUs or user objects that you do not need require the CM application to access, simply Deny all permissions for the directory account.
If you have multiple CM clusters integrated with AD, then I recommend having different CM directory accounts and digger Cisco Base OUs (the CM version is a key factor here, it was one of the "features" added to 3.3.4 or .5 (if memory serves, which it may not...)). Also, I would use a group configuration (all CM directory service accounts in one group) to apply the custom permissions (common sense I suppose).
Hopefully I didn't jump the gun and go down the wrong road here!
HTH.
Regards,
Bill
Please remember to rate helpful posts.
