Securing CA NSM Objects › How Security Management Works › How the Commit Process Works

How the Commit Process Works

The commit process puts that version of the policies you currently have defined into effect. It also generates the Decision Support Binary (DSB) files. Security Management requires that you execute the commit process during various phases of implementation. The commit process is typically required anytime after you make a change to your policies, that is, define, delete, or change a security access rule.

The commit process, when executed, performs the following tasks:

• Security Database Access--The first phase extracts the policies that you have defined in the Security Management Database. Therefore, that database must be online and active.
• Security Administration (or SDM daemon) Active--Another phase takes the policies extracted from the database and places them into effect on the designated server, where they are processed by the Security Management functions, which must already be running. If Security Management is not running, the commit process will detect this and issue an appropriate error message indicating that an attempt to place the new security policies into effect has failed.

To perform a commit process, issue the secadmin command with option c from the cautil command line, or select File, Commit from the menu bar in the Security Management GUI.

Note: For command syntax, examples, and additional information about warnings and commit customization, see the secadmin command in the online CA Reference.