Share via

Event ID 675 — Federation Service Auditing

  • Article

Applies To: Windows Server 2008 R2

The Federation Service uses auditing to record success and failure audits, such as audits that are written when tokens are created and received.

Event Details

Product: Windows Operating System
ID: 675
Source: Microsoft-Windows-ADFS
Version: 6.1
Symbolic Name: AuditPrivilegeNotHeld
Message: The AD FS auditing subsystem could not register itself with the system. The auditing privilege is not held.

The AD FS component will not be able to start unless it is granted the auditing privilege.

User Action
AD FS components that write audits must be configured to run as LocalSystem, NetworkService, or a domain principal that has explicitly been granted the "Generate Security Audits" privilege (SeAuditPrivilege).

If the failing component is the Federation Service, configure the application pool (ADFSAppPool) to run as an appropriate principal.

If the failing component is the AD FS Web Agent Authentication Service, configure the Windows NT service to run as an appropriate principal.

If the failing component is the AD FS Web Agent for claims-aware applications, configure the application pool for the protected application to run as an appropriate principal.

Resolve

Grant the Generate Security Audits privilege to AD FS components

Active Directory Federation Services (AD FS) components that write audits must be configured to run as LocalSystem, NetworkService, or a domain principal that has been granted the Generate Security Audits privilege (SeAuditPrivilege) explicitly.

To perform these procedures, you must be a member of the local Administrators group, or you must have been delegated the appropriate authority.

If you are using a domain principal as your service identity account, make sure that the appropriate domain principal is granted the Generate Security Audits privilege in Local Security Policy.

To grant a domain principal the Generate Security Audits privilege:

  1. Record the name of the account that is used as the domain principal before you start the Local Security Policy snap-in.
  2. After you identify this account, click Start, point to Administrative Tools, click Local Security Policy, and then double-click Local Policies.
  3. Double-click User Rights Assignment.
  4. In the details pane, right-click Generate Security Audits, and then click Properties.
  5. Add the appropriate domain principal account to this setting.

If the failing component is the Federation Service, configure the application pool (AD FS AppPool) to run as the appropriate principal.

To configure the Federation Service to run as LocalSystem, NetworkService, or a custom domain principal account:

  1. On a federation server, click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.
  2. In the console tree, click Application Pools.
  3. In the center pane, right-click AD FS AppPool, and then click Advanced Settings.
  4. In the Advanced Settings dialog box, under Process Model, click Identity, and then click the ... button.
  5. In the Application Pool Identity dialog box, do one of the following, depending on the type of account that you want to assign:
    • Click the menu under Built-in account, click either LocalSystem or NetworkService, and then click OK twice.
    • Click Custom account, and then click Set. In the Set Credentials dialog box, type the domain principal account name and password, and then click OK three times.

If the failing component is the AD FS Web Agent Authentication Service, configure this service to run as an appropriate principal.

To configure the AD FS Web Agent Authentication Service to run as LocalSystem, NetworkService, or a custom domain principal account:

  1. On the AD FS-enabled Web server, click Start, point to Administrative Tools, and then click Services.
  2. Right-click AD FS Web Agent Authentication Service, and then click Properties.
  3. On the Log On tab, do one of the following, depending on the type of account that you want to assign, and then click OK:
    • Click Local System account.
    • Click This account, and then type a specific service account name and password.

If the failing component is the Web agent for claims-aware applications, configure the application pool for the protected application to run as an appropriate principal.

To configure the claims-aware agent to run as LocalSystem, NetworkService, or a custom domain principal account:

  1. On the AD FS-enabled Web server, click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.
  2. In the console tree, click Application Pools.
  3. In the center pane, right-click the specific AppPool that this claims-aware application uses, and then click Advanced Settings.
  4. In the Advanced Settings dialog box, under Process Model, click Identity, and then click the … button.
  5. In the Application Pool Identity dialog box, do one of the following, depending on the type of account that you want to assign:
    • Click the menu under Built-in account, click either LocalSystem or NetworkService, and then click OK twice.
    • Click Custom account, and then click Set. In the Set Credentials dialog box, type the domain principal account name and password, and then click OK three times.

Verify

To verify that Active Directory Federation Services (AD FS) is working properly, attempt to access one or more federated applications from a client computer, and then check the Event Viewer logs on the federation server to make sure that AD FS is operational:

To perform these procedures, you must be a member of the local Administrators group, or you must have been delegated the appropriate authority.

To verify that Active Directory Federation Services (AD FS) is working properly:

  1. Log on to a federation server, and then open Event Viewer.

  2. Click Security, and then check to see if there are any Success or Failure audits that might indicate whether the client authentication or authorization request to the federated application was successful or not.

    If no security events are recorded, check to see whether all federation servers that participate in this federated partnership have been configured to record security audits. To do this, you have to manually configure the Local Security Policy and enable the event log for the federation servers, using the following steps.

    Note: You must apply each of these steps to all of the federation servers before you enable success or failure auditing in the Trust Policy properties of the Active Directory Federation Services snap-in. This will make it possible for the Federation Service to log either success or failure errors.

    1. Click Start, point to Administrative Tools, and then click Local Security Policy.
    2. Double-click Local Policies, and then click Audit Policy.
    3. In the details pane, double-click Audit object access.
    4. On the Audit object access Properties page, select either Success or Failure, or both, and then click OK.
    5. Close the Local Security Settings snap-in.
    6. At a command prompt, type gpupdate /force, and then press ENTER to immediately refresh the local policy.
    7. Repeat these steps on each of the federation servers in the partnership.
    8. Enable event logging for the federation server. Click Start, point to Administrative Tools, and then click Active Directory Federation Services.
    9. Right-click the Trust Policy node, and then click Properties.
    10. Scroll to the Event Log tab.
    11. Under Event log level, click to select and deselect the specific type of application event logs that you want to record, and then click OK.

You can also check the Application log on the AD FS-enabled Web server for more details.

To check the Application log:

  1. Log on to an AD FS-enabled Web server, and then open Event Viewer.
  2. Click Application, and then check to see whether the Web server displays any Information or Error events that were recorded by the federated application.

Federation Service Auditing

Active Directory Federation Services