Control Compliance Suite (CCS) uses Microsoft Active Directory Lightweight Directory Services (ADLDS) to store assets, policies, and jobs data. Access control within CCS is enforced by ADLDS. When a user views assets, collects data, evaluates assets, or runs reports, the user identity is used by ADLDS to validate the access rights. During interactive console sessions, the user's identity is established interactively by the CCS Console or the CCS Web Console. The Application Server Service impersonates the user that scheduled the jobs to enforce access control during the non-interactive sessions. This is useful when CCS jobs are executed during the non-interactive sessions.
You must configure delegation only if your existing deployment contains a stand-alone installation of the Directory Server.
In CCS, user impersonation is supported in two ways. In the first method, a user can provide their credentials to CCS to schedule jobs. These credentials are stored in CCS using secure storage. The CCS architecture ensures that once a password is stored, only the Application Server can recover the password. When necessary, the Application Server Service can retrieve the password and authenticate to Kerberos directly as the user. Whenever you change the password, you must launch the CCS console and re-enter the new password. Until this is done, any job that you schedule fails to run.
CCS stores the user credentials to schedule jobs through the Home > User Preferences view of the CCS console.
By default, Use Control Compliance Suite to store the password option is selected as the authentication type in the Basic settings of the Application Server.
In the second method, the user does not provide credentials to CCS to schedule jobs. In the the Basic settings of the Application Server the user selects the option Use controlled delegation of security rights as the authentication type. In this case CCS uses an Active Directory feature called the constrained delegation. Delegation lets the CCS Application Server service and the DSS to directly impersonate the appropriate user without any knowledge of the user credentials. You must ensure that constrained delegation is configured for this method to work accurately.
You can configure the service accounts for the Directory Support Service (DSS) and the Application Server Service to operate with constrained delegation in the distributed setup mode. By default, CCS stores the user credentials to schedule jobs through the Home > User Preferences view of the CCS console. You must set up the constrained delegation if you do not want to configure CCS to store the user credentials. In constrained delegation, the scope of impersonation is limited to selected CCS services. Constrained delegation is more secure because it limits the scope of impersonation for the Application Server Service and the DSS. Constrained delegation is available in Windows Server 2003 functional level or higher.
In a default Active Directory environment, only the domain administrator has sufficient rights to configure delegation.
You can also configure the service accounts for the Directory Support Service (DSS) and the Application Server Service to operate with unconstrained delegation in distributed and single setup modes. Unconstrained delegation lets a trusted account present the delegated credentials to any service. In unconstrained delegation, the scope of impersonation is not limited to any particular CCS services. The Application Server Service can access all services after impersonating the user. Thus there is a risk that any application on the Application Server could potentially abuse impersonation capabilities. Unconstrained delegation is available in Windows 2000 functional level or higher.
Use of constrained delegation is a security best practice and is the recommended configuration for CCS. However, the CCS infrastructure supports either constrained or unconstrained delegation.