Article ID: 314294
Article Last Modified on 2/28/2007
APPLIES TO
- Microsoft Exchange 2000 Server Standard Edition
This article was previously published under Q314294
SYMPTOMS
You may not be able to mount Exchange 2000 information store databases. One or more of the following error messages may also be logged in the Application event log:
CAUSE
This issue may occur if the Manage Auditing and Security Log right (SeSecurityPrivilege) was removed for the Exchange Enterprise Servers domain local group on some or all of the domain controllers.
When the first Exchange computer is installed in a domain, or when Exchange Setup is run with the /domainprep switch, the Exchange Enterprise Servers group is given the SeSecurityPrivilege right.
If the SeSecurityPrivilege right is later removed, Exchange computers that use domain controllers in the domain stop working, but not immediately. When Kerberos security refresh intervals expire or Exchange services are restarted on particular servers, the issues become evident.
RESOLUTION
To resolve this issue, use the Policytest.exe utility to check the status of the SeSecurityPrivilege right on all of the domain controllers in a single domain. The Policytest.exe utility is included on the Exchange 2000 installation CD-ROM.
To determine whether or not Exchange 2000 Enterprise server has the SeSecurityPrivilege right on a domain controller:
- Log on to the domain controller as a domain administrator, and then start the Domain Controller Security Policy console. (By default, the Domain Controller Security Policy console is located on the Start menu in the Administrative Tools group.)
- Expand Security Settings, and then expand Local Policies. Expand User Rights Assignment, and then open the properties of Manage Auditing and Security Log.
You can grant the SeSecurityPrivilege right directly to Exchange 2000 Enterprise servers, or you can run Exchange 2000 Setup again with the /domainprep switch to grant the SeSecurityPrivilege right automatically.
If you run Setup.exe with the /domainprep switch, you do not interrupt service on existing Exchange computers. Another advantage of this method is that it checks and resets other default rights and group memberships that may also have been changed.
If the Exchange Enterprise Servers group was recently granted the SeSecurityPrivilege right, that change does not take effect until the security policy is refreshed on the domain controller. The time that it takes to refresh the security policy depends on domain topology and configuration. By default, policy replication to other domain controllers occurs within five minutes, and application of the policy change within another five minutes.
Even if a particular domain does not contain any Exchange computers, Exchange computers in other domains may use that domain’s domain controllers. If you want Exchange 2000 to be able to perform global catalog lookups and make Configuration container changes when Exchange uses these domain controllers, the follow these steps for the domain:
- From the Exchange 2000 installation CD-ROM, run the Setup program with the /domainprep switch (Setup.exe /domainprep). This configures the appropriate groups and rights for cross-domain Exchange communication.
- In Exchange System Administrator, create a Recipient Update Service for the domain. The Recipient Update Service for each domain is responsible for populating the Exchange Enterprise Servers domain local group with Exchange Domain Servers global groups from other domains. The Recipient Update Service is also responsible for other tasks.
MORE INFORMATION
The Exchange Enterprise Servers group is a domain local group. This group supports necessary cross-domain communication between Exchange computers and between Exchange and Active Directory. The membership of the Exchange Enterprise Servers group must include the Exchange Domain Servers global groups from each domain in which Exchange computers exist.
The SeSecurityPrivilege right is required to support various Exchange security functions, including the ability to report which Windows accounts are being used to gain access to mailboxes.
By default, after a domain is installed, the only account with SeSecurityPrivilege rights is the built-in Administrators group for each domain. If you reapply the Security.inf template to the domain, the SeSecurityPrivilege right is reset to its default. This is not the only way that the Exchange Enterprise Servers group might have its rights removed. Other security auditing and configuration tools may reset the policy. Active Directory administrators who are following general security recommendations may also remove the Exchange Enterprise Servers group.
If the SeSecurityPrivilege right is being reset repeatedly, and you cannot determine why this occurs, you can audit changes to domain controller security policy:
- On each domain controller, change the size and rollover settings for the Security log as much as necessary to support increased amounts of logging information.
WARNING: If you turn on the Shut down system immediately if unable to log security audits option in the Security Options section of the default domain controller's policy, the domain controller shuts down immediately if the Security log fills up.
- Start the Domain Controllers Security Policy console.
- Expand Local Policies, expand Audit Policy, and then turn on Success auditing for Directory Access and Policy Changes.
After you follow the preceding steps, event ID 608 (account added) messages and event ID 609 (account removed) messages are logged when policy changes are made to the domain controller. The category of these event ID 608 and event ID 609 messages is Policy. The source of these messages is Security. The event ID 608 messages is similar to:
TIP: In Event Viewer, right-click the Security Log object. Click View, and then search for the word "SeSecurityPrivilege" (without the quotation marks) in the Find dialog box.
Because the system itself makes the policy change, you cannot use Policy logging to determine which user account made the change. But Directory Service Access logging identifies the user account that made the change.
Typically, a change to the domain controller policy results in an immediate Directory Access event on the domain controller where the change is made, followed several minutes later by a Policy Change event. The second event occurs when the policy is actually refreshed and applied on the domain controller. As the policy replicates to other domain controllers, it is refreshed and applied after several minutes, and a Policy Change event is also logged on those servers.
After you find a change to the SeSecurityPrivilege settings, search back through the Security log for Directory Access events that contain a User field that contains a user other than the SYSTEM or a SERVERNAME$ account, for example:
The "Client User Name" field in the preceding event message identifies the user account that made the change. The "Object Name" field identifies the policy that was changed.
In the preceding example, the policy name in Active Directory is:
CN={6AC1786C-016F-11D2-945F-00C04fB984F9},CN=Policies,CN=System,DC=domain,DC=com
You can use the LDIFDE command to resolve policy names to a more friendly form, so that you can be sure that the event is actually related to the policy for which you are monitoring changes:
LDIFDE -F POLICIES.LDF -D "CN=POLICIES,CN=SYSTEM,DC=DOMAIN,DC=COM" -L DISPLAYNAME -R (OBJECTCLASS=GROUPPOLICYCONTAINER)
The Policies.ldf file identifies each policy and its friendly name in a format that is similar to:
dn: CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=domain,DC=com
changetype: add
displayName: Default Domain Policy
dn: CN={6AC1786C-016F-11D2-945F-00C04fB984F9},CN=Policies,CN=System,DC=domain,DC=com
changetype: add
displayName: Default Domain Controllers Policy
To prevent inadvertent denial of the SeSecurityPrivilege right to Exchange 2000 Enterprise servers, you can create a custom policy for domain controllers to implement the SeSecurityPrivilege right:
- Start the Active Directory Users and Computers Microsoft Management Console (MMC).
- Open the properties of the Domain Controllers container.
- Click the Group Policy tab, and then click New. Name the new policy (for example, "DOMAIN_NAME Auditing Rights").
- This step is optional. This step makes the policy load faster. Right-click the new policy, click Properties, and then disable the User Configuration.
- Click the new policy, and then click Edit. Expand Computer Configuration, expand Windows Settings, and then expand Security Settings. Expand Local Policies, expand User Rights Assignment, and then configure all of the accounts that require the SeSecurityPrivilege right.
IMPORTANT: All of the settings that you configure in this policy replace the same settings in other policies, instead of merging with them. Unconfigured options are still applied from other policies.
- Set the new policy to a higher priority than the default domain controller's policy. If you do not do so, the policy has no effect because the default policy configures the same setting.
Additional query words: RUS DC GC exch2kp2w
Keywords: kberrmsg kbprb KB314294
