XADM: Exchange 2000 Error Messages Are Generated Because of SeSecurityPrivilege Right and Policytest Issues

View products that this article applies to.

This article was previously published under Q314294

Expand all | Collapse all

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:

Event Type: Error
Event Source: MSExchangeDSAccess
Event Category: (3)
Event ID: 2102
Date: 1/1/2002
Time: 12:00:00 AM
User: N/A
Computer: EXCHANGE1
Description: Process MAD.EXE (PID=1088). All Domain Controller Servers in use are not responding:
dc1.company.com
dc2.company.com
dc3.company.com

Event Type: Error
Event Source: MSExchangeSA
Event Category: (1)
Event ID: 9004
Date: 1/1/2002
Time: 12:00:00 AM
User: N/A
Computer: EXCHANGE1
Description: The Metabase Update service failed to start, error '80040a01'.

Event Type: Error
Event Source: MSExchangeSA
Event Category: (1)
Event ID: 1005
Date: 1/1/2002
Time: 12:00:00 AM
User: N/A
Computer: EXCHANGE1
Description: Unexpected error An unknown error has occurred. ID no: 80040a01 Microsoft Exchange System Attendant occurred.

Event Type: Error
Event Source: MSExchangeMU
Event Category: (1)
Event ID: 1002
Date: 1/1/2002
Time: 12:00:00 AM
User: N/A
Computer: EXCHANGE1
Description: Metabase Update agent failed to start. Error code is 80040a01.

Event Type: Error
Event Source: MSExchangeIS
Event Category: (6)
Event ID: 9519
Date: 1/1/2002
Time: 12:00:00 AM
User: N/A
Computer: EXCHANGE1
Description: Error 0x80004005 starting database "First Storage
Group\Mailbox Store(EXCHANGE1)" on the Microsoft Exchange Information Store. Failed to configure MDB. The Microsoft Exchange Information Store service could not find the specified object. ID no:c1041722

Event Type: Error
Event Source: MSExchangeMU
Event Category: General
Event ID: 1029
Date: 1/1/2002
Time: 12:00:00 AM
User: N/A
Computer: EXCHANGE1
Description: Failed to replicate the security descriptor to the metabase. Users may not be able to read or write data to the metabase. Error code is 8000500d.

Event Type: Error
Event Source: MSExchangeSA
Event Category: RFR Interface
Event ID: 9074
Date: 1/1/2002
Time: 12:00:00 AM
User: N/A
Computer: EXCHANGE1
Description: The Directory Service Referral interface failed to service a client request. RFRI is returning the error code:[0x3f0].

Event Type: Error
Event Source: MSExchangeIS
Event Category: General
Event ID: 1121
Date: 1/1/2002
Time: 12:00:00 AM
User: N/A
Computer: EXCHANGE1
Description: Error 0x80004005 connecting to the Microsoft Active Directory.

Event Type: Error
Event Source: MSExchangeMTA
Event Category: Configuration
Event ID: 125
Date: 1/1/2002
Time: 12:00:00 AM
User: N/A
Computer: EXCHANGE1
Description: A fatal error occurred reading a value from the directory. No MTA name was found. Contact Microsoft Technical Support. [MTA MAIN BASE 1 12] (16)

Back to the top

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.

Back to the top

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.

Back to the top

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:

Event Type: Success Audit
Event Source: Security
Event Category: Policy Change
Event ID: 608
Date: 12/12/2001
Time: 4:32:20 PM
User: NT AUTHORITY\SYSTEM
Computer: DC1
Description: User Right Assigned:
User Right: SeSecurityPrivilege
Assigned To: DOMAIN\USER
Assigned By:
User Name: DC1$
Domain: DOMAIN
Logon ID: (0x0,0x3E7)

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:

Event Type: Success Audit
Event Source: Security
Event Category: Directory Service Access
Event ID: 565
Date: 12/12/2001
Time: 5:52:53 PM
User: DOMAIN\adam
Computer: DC1
Description: Object Open:
Object Server: DS
Object Type: groupPolicyContainer
Object Name: CN={6AC1786C-016F-11D2-945F-00C04fB984F9},CN=Policies,CN=System,DC=domain,DC=com
New Handle ID: 0
Operation ID: {0,63067624}
Process ID: 280
Primary User Name: DC1$
Primary Domain: DOMAIN
Primary Logon ID: (0x0,0x3E7)
Client User Name: adam
Client Domain: DOMAIN
Client Logon ID: (0x0,0x3C255DB)
Accesses Write Property
Privileges -
Properties:
Write Property %{00000000-0000-0000-0000-000000000000}
versionNumber

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.