About delegated authentication in Control Compliance Suite
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.
In CCS, user impersonation is supported in two ways. In the first method, you must provide user 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.
In the second method, you do not require to provide user credentials to CCS to schedule jobs, but you can use an Active Directory feature called delegated authentication. This feature lets the CCS Application Server Service and the Directory Support Service to directly impersonate the appropriate user, and access network resources securely without any knowledge of the user credentials. To configure the CCS Application for delegated authentication, in the Basic settings of the Application Server, select
Use controlled delegation of security rights
as the authentication type. In a default Active Directory environment, only the domain administrator has sufficient rights to configure delegation.You must configure delegation only if your existing deployment contains a standalone installation of the Directory Server.
Delegated authentication is of two types:
- Constrained delegated authentication:Constrained delegated authentication lets a trusted account present the delegated credentials to selected CCS services. Constrained delegated authentication is securer because it limits the scope of impersonation for the Application Server Service and the DSS. You can configure the service accounts for the Application Server Service and the Directory Support Service to operate with constrained delegated authentication in the distributed setup mode. Constrained delegated authentication is available in Windows Server 2003 functional level or higher.
- Unconstrained delegation: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. You can configure the service accounts for the Application Server Service and the Directory Support Service to operate with unconstrained delegation in distributed and single setup modes. 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.