Security settings such as the CMS system account, CMS guest access, and cookie properties are configured in the SCA Security tab (Figure 18-18).
Figure 18-18. Security settings
CMS System Account
The CMS system account is the Windows account under which Content Management Server is run. This account is set up during the installation. It can be either a domain account or a local account. After the installation, the CMS system account can be modified using the SCA.
It is recommended that you create a dedicated Windows user account to be used as the CMS system account. The account should not be configured as a privileged Windows user, since it only requires limited access. If the CMS system account password is changed, CMS will not be able to write files to the cache folder and access the CMS database. Therefore, you need to set the password on the account to never expire. It is not recommended that you run CMS under any of the existing user accounts, because users change their passwords from time to time.
However, if the CMS system account credentials have been reset, you can change the system account information when you launch the SCA. Since the SCA is unable to launch, it will give an error message suggesting that you change the system account password (Figure 18-19). Click the Configure button to specify the correct password (Figure 18-20).
Figure 18-19. Message to change system account password
Figure 18-20. Update System Account Credentials dialog box
CMS uses the system account to connect to the Active Directory (AD) and to access protected resources. For Active Directory access, the system account needs to have sufficient permissions to enumerate and browse any domains, organizational units (OUs), containers, groups, and users that are from CMS-supported domains. It must have at least read permissions on these AD objects. For example, in order to be able to select a user or group from a listed domain to add to a CMS rights group, the CMS system account would need at least read rights in that domain.
As far as accessing resources is concerned, the CMS system account uses an impersonation process to carry out the tasks on behalf of the authenticated user as an agent. The CMS system account must have a "log on locally" right on the computer where CMS is installed. We will look into CMS authentication and authorization in Chapter 19.
If SQL Integrated Security is used, then the CMS system account must have read and write access to the CMS database hosted by SQL. The CMS system account must have the following database roles assigned to it on the CMS database: db_datareader and db_datawriter. Using an import function in site deployment also requires the db_ddladmin role.
The setting for the CMS system account is stored in the CMS database. To modify the CMS system account, in the SCA Security tab click Configure; in the Security Configuration window (Figure 18-21), in the MCMS System Account section, either manually enter the account name in the form <domain>\<user name>, or click the Browse button to select the domain and the account. If you are using a local account, enter the account name in the form <local computer>\<user name>. If you decide to browse to the account, you will be presented with a warning message that the CMS NT browser can take a while to present you with the list of users (Figure 18-22); just click OK; then select a domain from the Windows NT Domain list and an account from the Windows NT Users list (Figure 18-23).
Figure 18-21. Security Configuration window
Figure 18-22. NT Browser warning
Figure 18-23. Windows NT User Browser
The CMS system account must have a password. A blank password is not allowed. If you leave the password blank, the error message shown in Figure 18-24 will be displayed. After you have selected the account, type in the corresponding password and click OK. If the account credentials cannot be verified against the AD, the warning shown in Figure 18-25 will be displayed.
Figure 18-24. Blank password message
Figure 18-25. System account credentials warning
Guest access enables unauthenticated users to access the CMS site. Since all CMS access must be authenticated, a guest account is used to map anonymous users to a specified account. It can be either a domain account or a local account. In order for anonymous users to be able to view the CMS Web site, the guest account must be added to a subscribers rights group in the Site Manager, and then this rights group must be assigned to the channels and galleries that guest users are allowed to view.
NOTE: If the guest account is added to any other rights group but the subscribers group, the guest account is still only granted subscriber rights. If the guest account is enabled, guest user rights are added to all other user rights. For example, on a site with guest access enabled, a channel manager has full rights on the channels they are managing and guest rights on the rest of the site.
The SCA provides the ability to configure guest access. Guest access is enabled during the CMS installation. After the installation, it can be changed using the SCA. To change whether guest access is allowed, in the SCA Security tab, click Configure; in the Security Configuration window (Figure 18-21), in the Guest Visitors section, in the Allow Guests On Site drop-down list, choose Yes or No; then click OK.
The setting for the CMS guest account is stored in the CMS database. To modify the CMS guest account, in the SCA Security tab, click Configure; in the Security Configuration window (Figure 18-21), in the Guest Visitors section, either manually enter the account name in the form <domain>\<user name> or click the Browse button to select the domain and then the account. If you are using a local account, enter the account name in the form <local computer>\<user name>. No password is required for the guest account. Click OK to confirm the configuration change.
When a user is authenticated by CMS, the user is assigned a CMS authentication cookie. A user may be an explicitly authenticated user or a guest user. Depending on the CMS authentication configuration, the CMS authentication cookie is either a persistent cookie that is stored on the hard disk on the user's machine, or an in-memory cookie that is maintained in the browser on the client machine and is lost when the browser is closed. This cookie is attached to subsequent requests from the user's machine to the CMS server, which validates the request.
NOTE: We will look into CMS authentication configuration in different scenarios in detail in Chapters 19 and 20.
The Security tab (Figure 18-18) allows us to specify two cookie settings:
Viewing the CMS License
The SCA License tab (Figure 18-26) provides read-only information about the server license. The tab displays the following information:
Figure 18-26. License tab