Microsoft KB Archive/314294

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

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:

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 &quot;First Storage

Group\Mailbox Store(EXCHANGE1)&quot; 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)



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:
 * 1) 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.)
 * 2) 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:
 * 1) 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.
 * 2) 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:
 * 1) 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.
 * 1) Start the Domain Controllers Security Policy console.
 * 2) 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 &quot;SeSecurityPrivilege&quot; (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 &quot;Client User Name&quot; field in the preceding event message identifies the user account that made the change. The &quot;Object Name&quot; 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 &quot;CN=POLICIES,CN=SYSTEM,DC=DOMAIN,DC=COM&quot; -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:
 * 1) Start the Active Directory Users and Computers Microsoft Management Console (MMC).
 * 2) Open the properties of the Domain Controllers container.
 * 3) Click the Group Policy tab, and then click New. Name the new policy (for example, &quot;DOMAIN_NAME Auditing Rights&quot;).
 * 4) This step is optional. This step makes the policy load faster. Right-click the new policy, click Properties, and then disable the User Configuration.
 * 5) 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.
 * 1) 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

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.