Event ID 2521 — Auditing
Applies To: Windows Server 2008 R2
Active Directory Lightweight Directory Services (AD LDS) relies on the AuthZ Resource Manager to generate audit events.
|Product:||Windows Operating System|
|Message:||AD_TERM was unable to initialize auditing security system. It will run with auditing disabled. No security audits will be generated.
Correct the service account type and permissions
The error code that the operating system returned is included in the event text. The Active Directory Lightweight Directory Services (AD LDS) instance cannot generate audit events until the underlying issue is resolved.
The issue may be caused by a permissions problem with the service account that is used to connect to the domain. For example, if the error code reads "1326 Unknown user name or bad password" or "1314 A required privilege is not held by the client," the issue is related to the account that is configured to be used by the AD LDS instance.
To resolve this issue, configure the service account to use the Network Service account or a domain account. Ensure that the account that you use is granted the permission to generate security audits.
Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. Perform all steps on the computer that is logging the event to be resolved.
To correct the service account type:
- Open the Services snap-in. Click Start. Type services.msc, and then press ENTER.
- Locate the AD LDS instance name in the list of services, right-click it, and then click Properties.
- Select Log On, select This account, and then enter Network Service or the name of a domain user account that you want the AD LDS instance to use:
- If you are using Network Service, clear the Password and Confirm password boxes.
- If you are using a domain user account, type and then confirm the password for that account.
- Click OK to confirm the changes to the service account.
- If you are prompted to confirm that the account should be given the right to log on as a service and that a restart of the service is required, click OK.
- Restart the AD LDS instance. To restart the AD LDS instance, right-click the instance name, and then click Restart.
To ensure that the service account has permissions to generate security audits:
- Open Local Group Policy Editor. Click Start. Type gpedit.msc, and then press ENTER.
- In the console tree, expand the following: Computer Configuration, Windows Settings, Security Settings, and Local Policies and then, click User Rights Assignment.
- In the details pane, double-click Generate security audits.
- If the assigned service account is not listed in the Generate security audits Properties dialog box, click Add User or Group.
- If the service account is already listed, the permission is already set. Click Cancel.
- If you clicked Add User or Group, use Select Users, Computers, Service Accounts, or Groups to locate the service account. After you locate the service account, click OK twice to confirm the changes in the open dialog boxes, and then close Local Group Policy Editor.
To perform this procedure, you must have membership in the local Administrators group, or you must have been delegated the appropriate authority.
To ensure that Active Directory Lightweight Directory Services (AD LDS) audits are being logged:
- Open Event Viewer. To open Event Viewer, click Start. In Start Search, type eventvwr.msc, and then press ENTER. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue
- In the console tree, double-click Windows Logs, and then select the Security log.
- Perform an action that should result in an audited event. For example, if you enabled auditing of Everyone attempting to read the Configuration container, you might access that location with the LDP snap-in or the ADSI Edit snap-in.
- Confirm that the Security log receives an audited event. You may have to press F5 or click Refresh to see newly logged events.
For more information about auditing AD LDS, which was formerly known as Active Directory Application Mode (ADAM), see the following resources:
- Active Directory Application Mode: Frequently Asked Questions (http://go.microsoft.com/fwlink/?LinkId=92817)
- Administering an ADAM instance (http://go.microsoft.com/fwlink/?LinkId=92819)
- How Active Directory Application Mode Works (http://go.microsoft.com/fwlink/?LinkId=92814)