To elaborate on Lenny’s reply, and since there appears to be quite a bit of confusion on how Client Auto integrates with AD, let me try to outline the Client Auto to AD integration points.
Basically Client Auto integrates to AD in three ways, for authentication and discovery (done automatically) and for inventory (requires configuration). All AD integrations are actually optional, the system will work without any AD integration at all, but some functions (DSM Explorer authentication and security, Remote Control permissions, etc) may be severely impacted by not using AD. I routinely set up ITCA Domain Managers, Scalability Servers and Agents in my VM environment with no AD integration for testing/demos. We also have several clients (Managed Service Providers) whose Client Auto Domain manages Agents on completely unrelated Domains or no Domain at all. The Agent to SS, SS to DM and DM to EM communications are all handled by proprietary protocols which are not dependent on AD at all.
· Authentication:
o ITCA System Security automatically integrates with AD.
§ Each Enterprise or Domain Manager automatically integrates with the Windows Domain it’s server is a member of, and can query and authenticate with every directory (AD or LDAP) this Windows Domain has a trust relationship with.
§ This process has NOTHING AT ALL to do with the Directory Integration process. It is FULLY automatic. Immediately after installation, the Security Profiles dialog will show all the directories it is able to use for authentication.
§ ITCM Administrators can create Security Profiles within ITCM:
· Out of the box, there is a set of Security Profiles for each of the certificates which were installed with the product. These are not displayed unless the checkbox to display them is checked.
· Out of the box, there is one Security Profile created which has full rights to all aspects of the product, and the server’s Local ‘Administrators’ group is assigned to it. Since the product must be installed by an administrator, this ensures that the account used for the installation has full administrative rights immediately after installation.
o By default, a server which is in a Windows Domain will have ‘Domain Administrators’ in its local Administrators group, so all Domain Admins as well as the local Administrator account will have full rights to the ITCM Domain.
· New Security Profiles can be created, and assigned a specific set of rights and permissions within Client Auto. The Security Profile(s) can then have one or more Users or User Groups assigned to it/them. The users or user groups can be:
o Local users or groups created directly on the Client Auto server
o AD Users or Groups in the same directory as the Client Auto Server
o AD Users or Groups in Windows Domains the primary Domain has trust relationships with
o LDAP users or groups from any accessible LDAP directory
§ When a user starts the DSM Explorer or Reporter, or attempts to use the Client Auto CLI, first the logged on user will be checked to see if it matches (i.e. the user is assigned to or is a member of a group assigned to) any known Security Profile. If so, the user will be logged in using that Security Profile and will be granted the rights and permissions assigned to that Security Profile. If not, the user will be prompted to provide credentials, which will be authenticated with the directory, and checked against the Security Profiles in the same way.
§ Remote Control permissions can also be assigned to users and groups from the same list of directories.
o Software Delivery package creation. Not strictly an integration point since this is handled directly by Windows. In order to create a package using a REMOTE DSM Explorer, the logged on (windows) user must be able to upload the source to the SDLibrary share on the Client Auto Domain/Enterprise server. This is quite separate from the Security Profile rights and permissions described above, and it applies directly to the user which is logged on to Windows, not to any other credentials which might have been used to start the DSM Explorer.
o The Infrastructure Deployment Wizard and its DMSweep Command Line equivalent requires credentials to deliver the Agent to a target. This is not really an integration point, you are simply providing credentials which are used by the process to connect to an Admin share on the target and to run a Remote Procedure Call. These credentials may be local Admin accounts (on the target) or Domain Admin accounts.
· Discovery
o The infrastructure deployment wizard can extract a list of computer names to use as targets from any of the directories in the trust list as discussed above. You can select a whole Domain OR you can browse to a specific OU to extract a list of potential targets.
o Again this is automatic, when you use these options you are provided a list of all available directories to browse.
· Inventory
o This part requires actual configuration. In the Control Panel under Directory Integration, you can provide a list of directories to integrate and read-only credentials to access them.
o A scheduled Engine Job then accesses all of the configured directories, scanning them for information. What it is actually looking for is the OU membership of each computer and user account the Client Auto system knows about. When it finds a computer or user account it knows in a directory it is scanning, it adds the OU information to the computer or user data in the Client Auto database. This information can then be used in Client Auto queries to group or select computers/users by their OU membership.
o As far as I am aware, this is ALL this integration is used for. It is entirely optional. This integration is NOT required for any authentication purposes.
If anybody can add to this description please feel free to do so. This is all I can think of at the moment.
Steve McCormick, ITIL
CA Technologies
Principal Services Consultant
Stephen.McCormick@ca.com
<mailto:Stephen.McCormick@ca.com>