For users in Control Compliance Suite (CCS) to be able to run unattended jobs without having to store their passwords in CCS's Directory server, controlled delegation must be implemented.
Control Compliance Suite (CCS) affords two ways to run unattended (user is not logged into the console) scheduled jobs. The first is to store the password of each scheduled job creator inside of CCS's directory server. This can be done from the HOME\Preferences menu inside of the CCS console while logged in as that specific user. The second option is to use Controlled Delegation. This article addresses Controlled delegation only.
Note: If you use constrained delegation (below) and choose not to store passwords with CCS, then you need to give the application server's service account the "Act as part of the operating system privilege" in the local (or GPO) machine security policy. This privilege is required by S4U to impersonate an account. If you choose to store the passwords inside of CCS, then this privilege is not required for the service account.
PREREQUISITE WORK IN ACTIVE DIRECTORY:
A prerequisite to utilizing CCS is for the service account to be trusted for delegation inside of Active Directory. Without this trust in place, controlled delegation can also not be utilized. Best practice is to use Constrained Delegation (for any authentication protocol), and constrain the delegation for ldap and the SPNs for the Directory Server Service (DSS). Although unconstrained can be used....which involves Trusting the account for All Kerberos. If unconstrained delegation is set then skip to the "Setting Up Controlled Delegation in the CCS Console" section below.
How to turn on Constrained Delegation using the Active Directory Users and Computers utility (Windows 2003 native domain level mode):
With a domain admin account, launch the AD Users and Computers utility and navigate to the Directory Server's Service Account Properties. Select the Delegation tab. Note: The delegation tab will not appear if the account SPN had not been set up. Also verify both the long, and short name SPN entries for the account are correct. The service account for the Directory Server and Application server may or may not be the same account.
Select the radial button for "Trust this user for delegation to specified services only".
Choose the sub-radial button "Use any authentication protocol".
Click the ADD button at the bottom of the dialogue box, and on the Add Services screen, use the Users and Computers button to enter the hostname of the Directory Server service machine. Find and select the LDAP service (port 3890 by default) listed on that machine.
Again while on the delegation tab, click the ADD button, enter the Directory Server Service's service account (the account that this service is running under) and then find and select the Symantec.CSM.DSS SPN entry for the Directory Server's host machine. NOTE: This requires that this SPN has been previously created as per CCS 11 pre-requisites.
For more information on SPNs please reference the Control Compliance Suite Planning and Deployment Guide.
Again while on the delegation tab, check the box to "Expand" the view. This should display two entries for LDAP (one long and one FQDN entry) and the two similar entries for the DSS SPN ....for a total of four entries.
Once all four entries are listed for the services, SAVE the change.
SETTING UP CONTROLLED DELEGATION IN THE CCS CONSOLE:
Controlled delegation allows the service account's authority to run a scheduled job, even when that job is not created by the service account but by a regular user inside of CCS. This setting is available inside of the SETTINGS\SYSTEM TOPOLOGY\MAP VIEW when editing the settings of the application server object.
WARNING: It is a requirement for success that no jobs run or launch during the following procedure. Cancel or reschedule any jobs that might launch during the setting change. A controlled restart of services must be accomplished prior to any jobs launching.
While logged in with the CCS Administrator account and in the Map View (mentioned above), right click on the application server object and select Edit Settings. In the left-side panel of the resulting Edit Settings dialogue, choose Basic underneath the Application Server section.
On this screen:
1. select the "Use controlled Delegation of Security Rights" radial button.
2. Save the setting...the dialogue box closes and the map view screen is again seen.
3. Pull down the "Infrastructure Tasks" menu and select Sync Configuration
4. Close the CCS Console and then using the Services.msc utility, restart all the various Symantec CCS services...first on the Directory Server and then on the Application Server machine(s), in that order. It is important that the services are restarted in a normal way (i.e. processes were allowed to stop on their own) so that changes made in the CCS console will be written from RAM cache and will take affect on the restart.
NOTE: Using Task Manager to end processes for CCS services (during this procedure) is not recommended as it will not allow setting changes to be written to file. The application server and Directory server are normally on the same machine in CCS version 11 unless an upgrade was performed from a previous version where these two services were distributed. If both are on the same server, a server reboot can be performed instead of a restart of all the services. Alternately the Directory Server should be rebooted prior to the Application server.
5. Test to confirm that a user in CCS can create and run an unattended scheduled job even though their Active Directory (AD) password has not been stored in CCS. IMPORTANT NOTE: If the scheduled job was created prior to the change to Controlled Delegation, have the user who created the job edit that job and reschedule it. This will cause the job to be re-saved and should cause it to then use Controlled Delegation going forward.
Over-All Note on GPOs:
Group Policy Object (GPO) settings can affect whether functions in CCS work correctly. During the CCS 11 install a local group called "CCS Service Accounts" is created on the Application Server machine. This group is then inserted into certain Local Security policy privileges in order to assure that the service account has the correct privileges, especially if the service account is not a local administrator account on the Application Server. If your GPO removes the CCS Service Accounts group from these privileges, certain functionality, such as Controlled Delegation, may not work.
The privileges in the Local Security Policy that the "CCS Service Accounts" group should have are:
Log On As a Service
Impersonate a client after authentication
Replace a process level token
Allow log on locally (NOTE: The service account should have been added to this privilege directly by the installer so the group membership may not be required. However the service account must have this privilege.)
Control Compliance Suite
Imported Document ID: TECH213570
Subscribing will provide email updates when this Article is updated. Login is required.