Редагувати

Поділитися через


Microsoft Entra Connect Health Alert Catalog

Microsoft Entra Connect Health service send alerts indicate that your identity infrastructure isn't healthy. This article includes alerts titles, descriptions, and remediation steps for each alert.
Error, Warning, and Prewarning are three stages of alerts that are generated from Connect Health service. We highly recommend you take immediate actions on triggered alerts.
Microsoft Entra Connect Health alerts get resolved on a success condition. Microsoft Entra Connect Health Agents detect and report the success conditions to the service periodically. For a few alerts, the suppression is time-based. In other words, if the same error condition isn't observed within 72 hours from alert generation, the alert is automatically resolved.

General Alerts

Alert Name Description Remediation
Health service data isn't up to date The Health Agent(s) running on one or more servers isn't connected to the Health Service and the Health Service isn't receiving the latest data from this server. The last data processed by the Health Service is older than 2 Hours. Ensure that the health agents have outbound connectivity to the required service end points. Read More

Alerts for Microsoft Entra Connect (Sync)

Alert Name Description Remediation
Microsoft Entra Connect Sync Service isn't running Microsoft Entra ID Sync Windows service isn't running or couldn't start. As a result, objects won't synchronize with Microsoft Entra ID. Start Microsoft Entra ID Sync Services
  1. Click Start, click Run, type Services.msc, and then click OK.
  2. Locate the Microsoft Entra ID Sync service, and then check whether the service is started. If the service isn't started, right-click it, and then click Start.
Import from Microsoft Entra ID failed The import operation from Microsoft Entra Connector has failed. Investigate the event log errors of import operation for further details.
Connection to Microsoft Entra ID failed due to authentication failure Connection to Microsoft Entra ID failed due to authentication failure. As a result objects won't be synchronized with Microsoft Entra ID. Investigate the event log errors for further details.
Export to Active Directory failed The export operation to Active Directory Connector has failed. Investigate the event log errors of export operation for further details.
Import from Active Directory failed Import from Active Directory failed. As a result, objects from some domains from this forest may not be imported.
  • Verify DC connectivity
  • Rerun import manually
  • Investigate event log errors of the import operation for further details.
  • Export to Microsoft Entra ID failed The export operation to Microsoft Entra Connector has failed. As a result, some objects may not be exported successfully to Microsoft Entra ID. Investigate the event log errors of export operation for further details.
    Password Hash Synchronization heartbeat was skipped in last 120 minutes Password Hash Synchronization has not connected with Microsoft Entra ID in the last 120 minutes. As a result, passwords won't be synchronized with Microsoft Entra ID. Restart Microsoft Entra ID Sync Services:
    Any synchronization operations that are currently running will be interrupted. You can choose to perform below steps when no synchronization operation is in progress.
    1. Click Start, click Run, type Services.msc, and then click OK.
    2. Locate Microsoft Entra ID Sync, right-click it, and then click Restart.
    High CPU Usage detected The percentage of CPU consumption crossed the recommended threshold on this server.
  • This could be a temporary spike in CPU consumption. Check the CPU usage trend from the Monitoring section.
  • Inspect the top processes consuming the highest CPU usage on the server.
    1. You may use the Task Manager or execute the following PowerShell Command:
      get-process | Sort-Object -Descending CPU | Select-Object -First 10
    2. If there are unexpected processes consuming high CPU usage, stop the processes using the following PowerShell command:
      stop-process -ProcessName [name of the process]
  • If the processes seen in the above list are the intended processes running on the server and the CPU consumption is continuously near the threshold, consider re-evaluating the deployment requirements of this server.
  • As a fail-safe option you may consider restarting the server.
  • High Memory Consumption Detected The percentage of memory consumption of the server is beyond the recommended threshold on this server. Inspect the top processes consuming the highest memory on the server. You may use the Task Manager or execute the following PowerShell Command:
    get-process | Sort-Object -Descending WS | Select-Object -First 10
    If there are unexpected processes consuming high memory, stop the processes using the following PowerShell command:
    stop-process -ProcessName [name of the process]
  • If the processes seen in the above list are the intended processes running on the server, consider re-evaluating the deployment requirements of this server.
  • As a failsafe option, you may consider restarting the server.
  • Password Hash Synchronization has stopped working Password Hash Synchronization has stopped. As a result passwords won't be synchronized with Microsoft Entra ID. Restart Microsoft Entra ID Sync Services:
    Any synchronization operations that are currently running will be interrupted. You can choose to perform below steps when no synchronization operation is in progress.
    1. Click Start, click Run, type Services.msc, and then click OK.
    2. Locate the Microsoft Entra ID Sync, right-click it, and then click Restart.

    Export to Microsoft Entra ID was Stopped. Accidental delete threshold was reached The export operation to Microsoft Entra ID has failed. There were more objects to be deleted than the configured threshold. As a result, no objects were exported.
  • The number of objects are marked for deletion are greater than the set threshold. Ensure this outcome is desired.
  • To allow the export to continue, perform the following steps:
    1. Disable Threshold by running Disable-ADSyncExportDeletionThreshold
    2. Start Synchronization Service Manager
    3. Run Export on Connector with type = Microsoft Entra ID
    4. After successfully exporting the objects, enable Threshold by running: Enable-ADSyncExportDeletionThreshold
  • Alerts for Active Directory Federation Services

    Alert Name Description Remediation
    Test Authentication Request (Synthetic Transaction) failed to obtain a token The test authentication requests (Synthetic Transactions) initiated from this server has failed to obtain a token after 5 retries. This may be caused due to transient network issues, AD DS Domain Controller availability or a mis-configured AD FS server. As a result, authentication requests processed by the federation service may fail. The agent uses the Local Computer Account context to obtain a token from the Federation Service. Ensure that the following steps are taken to validate the health of the server.
    1. Validate that there are no additional unresolved alerts for this or other AD FS servers in your farm.
    2. Validate that this condition isn't a transient failure by logging on with a test user from the AD FS login page available at https://{your_adfs_server_name}/adfs/ls/idpinitiatedsignon.aspx
    3. Go to https://testconnectivity.microsoft.com and choose the ‘Office 365’ tab. Perform the ‘Office 365 single sign-on Test’.
    4. Verify if your AD FS service name can be resolved from this server by executing the following command from a command prompt on this server. nslookup your_adfs_server_name

    If the service name can't be resolved, refer to the FAQ section for instructions of adding a HOST file entry of your AD FS service with the IP address of this server. This will allow the synthetic transaction module running on this server to request a token

    The proxy server can't reach the federation server This AD FS proxy server is unable to contact the AD FS service. As a result, authentication requests processed by this server will fail. Perform the following steps to validate the connectivity between this server and the AD FS service.
    1. Ensure that the firewall between this server and the AD FS service is configured accurately.
    2. Ensure that DNS resolution for the AD FS service name appropriately points to the AD FS service that resides within the corporate network. This can be achieved through a DNS server that serves this server in the perimeter network or through entries in the HOSTS files for the AD FS service name.
    3. Validate the network connectivity by opening up the browser on this server and accessing the federation metadata endpoint, which is at https://<your-adfs-service-name>/federationmetadata/2007-06/federationmetadata.xml
    The SSL Certificate is about to expire The TLS/SSL certificate used by the Federation servers is about to expire within 90 days. Once expired, any requests that require a valid TLS connection will fail. For example, for Microsoft 365 customers, mail clients won't be able to authenticate. Update the TLS/SSL certificate on each AD FS server.
    1. Obtain the TLS/SSL certificate with the following requirements.
      1. Enhanced Key Usage is at least Server Authentication.
      2. Certificate Subject or Subject Alternative Name (SAN) contains the DNS name of the Federation Service or appropriate wild card. For example: sso.contoso.com or *.contoso.com
    2. Install the new TLS/SSL certificate on each server in the local machine certificate store.
    3. Ensure that the AD FS Service Account has read access to the certificate's Private Key

    For AD FS 2.0 in Windows Server 2008R2:

    • Bind the new TLS/SSL certificate to the web site in IIS, which hosts the Federation Service. Note that you must perform this step on each Federation Server and Federation Server proxy.

    For AD FS in Windows Server 2012 R2 and later versions:

  • Refer to Managing SSL Certificates in AD FS and WAP
  • AD FS service isn't running on the server Active Directory Federation Service (Windows Service) isn't running on this server. Any requests targeted to this server will fail. To start the Active Directory Federation Service (Windows Service):
    1. Log on to the server as an administrator.
    2. Open services.msc
    3. Find "Active Directory Federation Services"
    4. Right-click and select "Start"
    DNS for the Federation Service may be misconfigured The DNS server could be configured to use a CNAME record for the AD FS farm name. It is recommended to use A or AAAA record for AD FS in order for the Windows Integrated Authentication to work seamlessly within your corporate network. Ensure that the DNS record type of the AD FS farm <Farm Name> isn't CNAME. Configure it to be an A or AAAA record.
    AD FS Auditing is disabled AD FS Auditing is disabled for the server. AD FS Usage section on the portal won't include data from this server. If AD FS Audits aren't enabled, follow these instructions:
    1. Grant the AD FS service account the "Generate security audits" right on the AD FS server.
    2. Open the local security policy on the server gpedit.msc.
    3. Navigate to "Computer Configuration\Windows Settings\Local Policies\User Rights Assignment"
    4. Add the AD FS Service Account to have the "Generate security audits" right.
    5. Run the following command from the command prompt:
      auditpol.exe /set /subcategory:"Application Generated" /failure:enable /success:enable
    6. Update Federation Service Properties to include Success and Failure Audits.
    7. In the AD FS console, choose "Edit Federation Service Properties"
    8. From "Federation Service Properties" dialogue box choose the Events tab and select "Success Audits" and "Failure Audits"

    After following these steps, AD FS Audit Events should be visible from the Event Viewer. To verify:

    1. Go to Event Viewer/ Windows Logs /Security.
    2. Select Filter Current Logs and select AD FS Auditing from the Event sources drop down. For an active AD FS server with AD FS auditing enabled, events should be visible for the above filtering.

    If you've followed these instructions before, but still seeing this alert, it is possible that a Group Policy Object is disabling AD FS auditing. The root cause can be one of the following:

    1. AD FS service account is being removed from having the right to Generate Security Audits.
    2. A custom script in Group Policy Object is disabling success and failure audits based on "Application Generated".
    3. AD FS configuration isn't enabled to generate Success/Failure audits.
    AD FS SSL certificate is self-signed You are currently using a self-signed certificate as the TLS/SSL certificate in your AD FS farm. As a result, mail client authentication for Microsoft 365 will fail

    Update the TLS/SSL certificate on each AD FS server.

    1. Obtain a publicly trusted TLS/SSL certificate with the following requirements.
    2. Certificate installation file contains its private key.
    3. Enhanced Key Usage is at least Server Authentication.
    4. Certificate Subject or Subject Alternative Name (SAN) contains the DNS name of the Federation Service or appropriate wild card. For example: sso.contoso.com or *.contoso.com

    Install the new TLS/SSL certificate on each server in the local machine certificate store.

      Ensure that the AD FS Service Account has read access to the certificate's Private Key.
      For AD FS 2.0 in Windows Server 2008R2:
    1. Bind the new TLS/SSL certificate to the web site in IIS, which hosts the Federation Service. Note that you must perform this step on each Federation Server and Federation Server proxy.

    2. For AD FS in Windows Server 2012 R2 or later versions:
    3. Refer to Managing SSL Certificates in AD FS and WAP
    The trust between the proxy server and federation server isn't valid The trust between the federation server proxy and the Federation Service couldn't be established or renewed. Update the Proxy Trust Certificate on the proxy server. Re-Run the Proxy Configuration Wizard.
    Extranet Lockout Protection Disabled for AD FS The Extranet Lockout Protection feature is DISABLED on your AD FS farm. This feature protects your users from brute force password attacks from the internet and prevents denial of service attacks against your users when AD DS account lockout policies are in effect. With this feature enabled, if the number of failed extranet login attempts for a user (login attempts made via WAP server and AD FS) exceed the 'ExtranetLockoutThreshold' then AD FS servers will stop processing further login attempts for ‘ExtranetObservationWindow' We highly recommend you enable this feature on your AD FS servers. Run the following command to enable AD FS Extranet Lockout Protection with default values.
    Set-AdfsProperties -EnableExtranetLockout $true

    If you've AD lockout policies configured for your users, ensure that the 'ExtranetLockoutThreshold' property is set to a value below your AD DS lockout threshold. This ensures that requests that have exceeded the threshold for AD FS are dropped and never validated against your AD DS servers.
    Invalid Service Principal Name (SPN) for the AD FS service account The Service Principal Name of the Federation Service account isn't registered or isn't unique. As a result, Windows Integrated Authentication from domain-joined clients may not be seamless. Use [SETSPN -L ServiceAccountName] to list the Service Principals.
    Use [SETSPN -X] to check for duplicate Service Principal Names.

    If SPN is duplicated for the AD FS service account, remove the SPN from the duplicated account using [SETSPN -d service/namehostname]

    If SPN isn't set, use [SETSPN -s {Desired-SPN} {domain_name}{service_account}] to set the desired SPN for the Federation Service Account.

    The Primary AD FS Token Decrypting certificate is about to expire The Primary AD FS Token Decrypting certificate is about to expire in less than 90 days. AD FS can't decrypt tokens from trusted claims providers. AD FS can't decrypt encrypted SSO cookies. The end users won't be able to authenticate to access resources. If Auto-certificate roll-over is enabled, AD FS manages the Token Decrypting Certificate.

    If you manage your certificate manually, follow the below instructions. Obtain a new Token Decrypting Certificate.

    1. Ensure that the Enhanced Key Usage (EKU) includes "Key Encipherment"
    2. Subject or Subject Alternative Name (SAN) do not have any restrictions.
    3. Note that your Federation Servers and Claims Provider partners need to be able to chain to a trusted root certification authority when validating your Token-Decrypting certificate.
    Decide how your Claims Provider partners will trust the new Token-Decrypting certificate
    1. Ask partners to pull the Federation Metadata after updating the certificate.
    2. Share the public key of the new certificate. (.cer file) with the partners. On the Claims Provider partner's AD FS server, launch AD FS Management from the Administrative Tools menu. Under Trust Relationships/Relying Party Trusts, select the trust that was created for you. Under Properties/Encryption click "Browse" to select the new Token-Decrypting certificate and click OK.
    Install the certificate in the local certificate store on each of your Federation Server.
    • Ensure that the certificate installation file has the Private Key of the certificate on each server.
    Ensure that the federation service account has access to the new certificate's private key. Add the new certificate to AD FS.
    1. Launch AD FS Management from the Administrative Tools menu
    2. Expand Service and select Certificates
    3. In the Actions pane, click Add Token-Decrypting Certificate
    4. You'll be presented with a list of certificates that are valid for Token-Decrypting. If you find that your new certificate isn't being presented in the list, you need to go back and make sure that the certificate is in the local computer personal store with a private key associated and the certificate has the Key Encipherment as Extended Key Usage.
    5. Select your new Token-Decrypting certificate and click OK.
    Set the new Token-Decrypting Certificate as Primary.
    1. With the Certificates node in AD FS Management selected, you should now see two certificates listed under Token-Decrypting: existing and the new certificate.
    2. Select your new Token-Decrypting certificate, right-click, and select Set as primary.
    3. Leave the old certificate as secondary for roll-over purposes. You should plan to remove the old certificate once you're confident it is no longer needed for roll-over, or when the certificate has expired.
    The Primary AD FS Token Signing certificate is about to expire The AD FS token signing certificate is about to expire within 90 days. AD FS can't issue signed tokens when this certificate isn't valid. Obtain a new Token Signing Certificate.
    1. Ensure that the Enhanced Key Usage (EKU) includes "Digital Signature"
    2. Subject or Subject Alternative Name (SAN) doesn't have any restrictions.
    3. Note that your Federation Servers, your Resource Partner Federation Servers and Relying Party Application servers need to be able to chain to a trusted root certificate authority when validating your Token-Signing certificate.
    Install the certificate in the local certificate store on each Federation Server.
    • Ensure that the certificate installation file has the Private Key of the certificate on each server.
    Ensure that the Federation Service Account has access to the new certificate's private key. Add the new certificate to AD FS.
    1. Launch AD FS Management from the Administrative Tools menu.
    2. Expand Service and select Certificates
    3. In the Actions pane, click Add Token-Signing Certificate...
    4. You'll be presented with a list of certificates that are valid for Token-Signing. If you find that your new certificate isn't being presented in the list, you need to go back and make sure that the certificate is in the local computer Personal store with private key associated and the certificate has the Digital Signature KU.
    5. Select your new Token-Signing certificate and click OK
    Inform all the Relying Parties about the change in Token Signing Certificate.
    1. Relying Parties that consume AD FS federation metadata, must pull the new Federation Metadata to start using the new certificate.
    2. Relying Parties that do NOT consume AD FS federation metadata must manually update the public key of the new Token Signing Certificate. Share the .cer file with the Relying Parties.
    3. Set the new Token-Signing Certificate as Primary.
      1. With the Certificates node in AD FS Management selected, you should now see two certificates listed under Token-Signing: existing and the new certificate.
      2. Select your new Token-Signing certificate, right-click, and select Set as primary
      3. Leave the old certificate as secondary for rollover purposes. You should plan to remove the old certificate once you're confident it is no longer needed for rollover, or when the certificate has expired. Note that current users' SSO sessions are signed. Current AD FS Proxy Trust relationships utilize tokens that are signed and encrypted using the old certificate.
    AD FS SSL certificate isn't found in the local certificate store The certificate with the thumbprint that is configured as the TLS/SSL certificate in the AD FS database was not found in the local certificate store. As a result, any authentication request over the TLS will fail. For example mail client authentication for Microsoft 365 will fail. Install the certificate with the configured thumbprint in the local certificate store.
    The SSL Certificate expired The TLS/SSL certificate for the AD FS service has expired. As a result, any authentication requests that require a valid TLS connection will fail. For example: mail client authentication won't be able to authenticate for Microsoft 365. Update the TLS/SSL certificate on each AD FS server.
    1. Obtain the TLS/SSL certificate with the following requirements.
    2. Enhanced Key Usage is at least Server Authentication.
    3. Certificate Subject or Subject Alternative Name (SAN) contains the DNS name of the Federation Service or appropriate wild card. For example: sso.contoso.com or *.contoso.com
    4. Install the new TLS/SSL certificate on each server in the local machine certificate store.
    5. Ensure that the AD FS Service Account has read access to the certificate's Private Key

    For AD FS 2.0 in Windows Server 2008R2:

    • Bind the new TLS/SSL certificate to the web site in IIS, which hosts the Federation Service. Note that you must perform this step on each Federation Server and Federation Server proxy.

    For AD FS in Windows Server 2012 R2 or later versions: Refer to: Managing SSL Certificates in AD FS and WAP

    The Required end points for Microsoft Entra ID (for Microsoft 365) aren't enabled The following set of end points required by the Exchange Online Services, Microsoft Entra ID, and Microsoft 365 aren't enabled for the federation service:
  • /adfs/services/trust/2005/usernamemixed
  • /adfs/ls/
  • Enable the required end points for the Microsoft Cloud Services on your federation service.
    For AD FS in Windows Server 2012R2 or later versions
  • Refer to: Managing SSL Certificates in AD FS and WAP
  • The Federation server was unable to connect to the AD FS Configuration Database The AD FS service account is experiencing issues while connecting to the AD FS configuration database. As a result, the AD FS service on this computer may not function as expected.
  • Ensure that the AD FS service account has access to the configuration database.
  • Ensure that the AD FS Configuration Database service is available and reachable.
  • Required SSL bindings are missing or not configured The TLS bindings required for this federation server to successfully perform authentication are misconfigured. As a result, AD FS can't process any incoming requests. For Windows Server 2012 R2
    Open an elevated admin command prompt and execute the following commands:
    1. To view the current TLS binding: Get-AdfsSslCertificate
    2. To add new bindings: netsh http add sslcert hostnameport=<federation service name>:443 certhash=AA11BB22CC33DD44EE55FF66AA77BB88CC99DD00 appid={00001111-aaaa-2222-bbbb-3333cccc4444} certstorename=MY
    The Primary AD FS Token Signing certificate has expired The AD FS Token Signing certificate has expired. AD FS can't issue signed tokens when this certificate isn't valid. If Auto-certificate rollover is enabled, AD FS will manage updating the Token Signing Certificate.

    If you manage your certificate manually, follow the below instructions.

    1. Obtain a new Token Signing Certificate.
      1. Ensure that the Enhanced Key Usage (EKU) includes "Digital Signature"
      2. Subject or Subject Alternative Name (SAN) doesn't have any restrictions.
      3. Remember that your Federation Servers, your Resource Partner Federation Servers and Relying Party Application servers need to be able to chain to a trusted root certificate authority when validating your Token-Signing certificate.
    2. Install the certificate in the local certificate store on each Federation Server.
      • Ensure that the certificate installation file has the Private Key of the certificate on each server.
    3. Ensure that the Federation Service Account has access to the new certificate's private key.
    4. Add the new certificate to AD FS.
      1. Launch AD FS Management from the Administrative Tools menu.
      2. Expand Service and select Certificates
      3. In the Actions pane, click Add Token-Signing Certificate...
      4. You'll be presented with a list of certificates that are valid for Token-Signing. If you find that your new certificate isn't being presented in the list, you need to go back and make sure that the certificate is in the local computer Personal store with private key associated and the certificate has the Digital Signature KU.
      5. Select your new Token-Signing certificate and click OK
    5. Inform all the Relying Parties about the change in Token Signing Certificate.
      1. Relying Parties that consume AD FS federation metadata, must pull the new Federation Metadata to start using the new certificate.
      2. Relying Parties that do NOT consume AD FS federation metadata must manually update the public key of the new Token Signing Certificate. Share the .cer file with the Relying Parties.
    6. Set the new Token-Signing Certificate as Primary.
      1. With the Certificates node in AD FS Management selected, you should now see two certificates listed under Token-Signing: existing and the new certificate.
      2. Select your new Token-Signing certificate, right-click, and select Set as primary
      3. Leave the old certificate as secondary for rollover purposes. You should plan to remove the old certificate once you're confident it is no longer needed for rollover, or when the certificate has expired. Remember that current users' SSO sessions are signed. Current AD FS Proxy Trust relationships utilize tokens that are signed and encrypted using the old certificate.
    Proxy server is dropping requests for congestion control This proxy server is currently dropping requests from the extranet due to a higher than normal latency between this proxy server and the federation server. As a result, certain portion of the authentication requests processed by the AD FS Proxy server can fail.
  • Verify if the network latency between the Federation Proxy Server and the Federation Servers falls within the acceptable range. Refer to the Monitoring Section for trending values of the "Token Request Latency." A latency greater than [1500 ms] should be considered as high latency. If high latency is observed, ensure the network between AD FS and AD FS Proxy servers doesn't have any connectivity issues.
  • Ensure Federation Servers aren't overloaded with authentication requests. Monitoring Section provides trending views for Token Requests per second, CPU utilization and Memory consumption.
  • If the above items have been verified and this issue is still seen, adjust the congestion avoidance setting on each of the Federation Proxy Servers as per the guidance from the related links.
  • The AD FS service account is denied access to one of the certificate's private key. The AD FS service account doesn't have access to the private key of one of the AD FS certificates on this computer. Ensure that the AD FS service account is provided access to the TLS, token signing, and token decryption certificates stored in the local computer certificate store.
    1. From Command Line type MMC.
    2. Go to File->Add/Remove Snap-In
    3. Select Certificates and click Add. -> Select Computer Account and click Next. -> Select Local Computer and click Finish. Click OK.

    Open Certificates(Local Computer)/Personal/Certificates.For all the certificates that are used by AD FS:
    1. Right-click the certificate.
    2. Select All Tasks -> Manage Private Keys.
    3. On the Security Tab under Group or user names ensure that the AD FS service account is present. If not select Add and add the AD FS service account.
    4. Select the AD FS service account and under "Permissions for <AD FS Service Account Name>" make sure Read permission is allowed (check mark).
    The AD FS SSL certificate doesn't have a private key AD FS TLS/SSL certificate was installed without a private key. As a result any authentication request over the SSL will fail. For example, mail client authentication for Microsoft 365 will fail. Update the TLS/SSL certificate on each AD FS server.
    1. Obtain a publicly trusted TLS/SSL certificate with the following requirements.
      1. Certificate installation file contains its private key.
      2. Enhanced Key Usage is at least Server Authentication.
      3. Certificate Subject or Subject Alternative Name (SAN) contains the DNS name of the Federation Service or appropriate wild card. For example: sso.contoso.com or *.contoso.com
    2. Install the new TLS/SSL certificate on each server in the local machine certificate store.
    3. Ensure that the AD FS Service Account has read access to the certificate's Private Key

    For AD FS 2.0 in Windows Server 2008R2:

    • Bind the new TLS/SSL certificate to the web site in IIS, which hosts the Federation Service. Note that you must perform this step on each Federation Server and Federation Server proxy.

    For AD FS in Windows Server 2012 R2 or later versions:

  • Refer to: Managing SSL Certificates in AD FS and WAP
  • The Primary AD FS Token Decrypting certificate has expired The Primary AD FS Token Decrypting certificate has expired. AD FS can't decrypt tokens from trusted claims providers. AD FS can't decrypt encrypted SSO cookies. The end users won't be able to authenticate to access resources.

    If Auto-certificate roll-over is enabled, AD FS manages the Token Decrypting Certificate.

    If you manage your certificate manually, follow the below instructions.

    1. Obtain a new Token Decrypting Certificate.
      • Ensure that the Enhanced Key Usage (EKU) includes "Key Encipherment".
      • Subject or Subject Alternative Name (SAN) do not have any restrictions.
      • Note that your Federation Servers and Claims Provider partners need to be able to chain to a trusted root certification authority when validating your Token-Decrypting certificate.
    2. Decide how your Claims Provider partners will trust the new Token-Decrypting certificate
      • Ask partners to pull the Federation Metadata after updating the certificate.
      • Share the public key of the new certificate. (.cer file) with the partners. On the Claims Provider partner's AD FS server, launch AD FS Management from the Administrative Tools menu. Under Trust Relationships/Relying Party Trusts, select the trust that was created for you. Under Properties/Encryption click "Browse" to select the new Token-Decrypting certificate and click OK.
    3. Install the certificate in the local certificate store on each of your Federation Server.
      • Ensure that the certificate installation file has the Private Key of the certificate on each server.
    4. Ensure that the federation service account has access to the new certificate's private key.
    5. Add the new certificate to AD FS.
      • Launch AD FS Management from the Administrative Tools menu
      • Expand Service and select Certificates
      • In the Actions pane, click Add Token-Decrypting Certificate
      • You'll be presented with a list of certificates that are valid for Token-Decrypting. If you find that your new certificate isn't being presented in the list, you need to go back and make sure that the certificate is in the local computer personal store with a private key associated and the certificate has the Key Encipherment as Extended Key Usage.
      • Select your new Token-Decrypting certificate and click OK.
    6. Set the new Token-Decrypting Certificate as Primary.
      • With the Certificates node in AD FS Management selected, you should now see two certificates listed under Token-Decrypting: existing and the new certificate.
      • Select your new Token-Decrypting certificate, right-click, and select Set as primary.
      • Leave the old certificate as secondary for roll-over purposes. You should plan to remove the old certificate once you're confident it is no longer needed for roll-over, or when the certificate has expired.

    Alerts for Active Directory Domain Services

    Alert Name Description Remediation
    Domain controller is unreachable via LDAP ping Domain Controller isn't reachable via LDAP Ping. This can be caused due to Network issues or machine issues. As a result, LDAP Pings will fail.
  • Examine alerts list for related alerts, such as: Domain Controller isn't advertising.
  • Ensure affected Domain Controller has sufficient disk space. Running out of space will stop the DC from advertising itself as an LDAP server.
  • Attempt to find the PDC: Run
    netdom query fsmo
    on the affected Domain Controller.
  • Ensure physical network is properly configured/connected.
  • Active Directory replication error encountered This domain controller is experiencing replication issues, which can be found by going to the Replication Status Dashboard. Replication errors may be due to improper configuration or other related issues. Untreated replication errors can lead to data inconsistency. See additional details for the names of the affected source and destination DCs. Navigate to Replication Status dashboard and look for the active errors on the affected DCs. Click on the error to open a blade with more details on how to remediate that particular error.
    Domain controller is unable to find a PDC A PDC isn't reachable through this domain controller. This will lead to impacted user logons, unapplied group policy changes, and system time synchronization failure.
  • Examine alerts list for related alerts that could be impacting your PDC, such as: Domain Controller isn't advertising.
  • Attempt to find the PDC: Run
    netdom query fsmo
    on the affected Domain Controller.
  • Ensure network is working properly.
  • Domain controller is unable to find a Global Catalog server A global catalog server isn't reachable from this domain controller. It will result in failed authentications attempted through this Domain Controller. Examine the alerts list for any Domain Controller isn't advertising alerts where the impacted server might be a GC. If there are no advertising alerts, check the SRV records for the GCs. You can check them by running:
    nltest /dnsgetdc: [ForestName] /gc
    It should list the DCs advertising as GCs. If the list is empty, check the DNS configuration to ensure that the GC has registered the SRV records. The DC is able to find them in DNS.
    For troubleshooting Global Catalogs, see Advertising as a Global Catalog Server.
    Domain controller unable to reach local sysvol share Sysvol contains important elements from Group Policy Objects and scripts to be distributed within DCs of a domain. The DC won't advertise itself as DC and Group Policies won't be applied. See How to troubleshoot missing sysvol and Netlogon shares
    Domain Controller time is out of sync The time on this Domain Controller is outside of the normal Time Skew range. As a result, Kerberos authentications will fail.
  • Restart Windows Time Service: Run
    net stop w32time
    then
    net start w32time
    on the affected Domain Controller.
  • Resync Time: Run
    w32tm /resync
    on the affected Domain Controller.
  • Domain controller isn't advertising This domain controller isn't properly advertising the roles it's capable of performing. This can be caused by problems with replication, DNS misconfiguration, critical services not running, or because of the server not being fully initialized. As a result, domain controllers, domain members, and other devices won't be able to locate this domain controller. Additionally, other domain controllers might not be able to replicate from this domain controller. Examine alerts list for other related alerts such as: Replication is broken. Domain controller time is out of sync. Netlogon service isn't running. DFSR and/or NTFRS services aren't running. Identify and troubleshoot related DNS problems: Logon to affected Domain controller. Open System Event Log. If events 5774, 5775 or 5781 are present, see Troubleshooting Domain Controller Locator DNS Records Registration Failure Identify and troubleshoot related Windows Time Service Issues: Ensure Windows Time service is running: Run 'net start w32time' on the affected Domain Controller. Restart Windows Time Service: Run 'net stop w32time' then 'net start w32time' on the affected Domain Controller.
    GPSVC service isn't running If the service is stopped or disabled, settings configured by the admin won't be applied and applications and components won't be manageable through Group Policy. Any components or applications that depend on the Group Policy component might not be functional if the service is disabled. Run
    net start gpsvc
    on the affected Domain Controller.
    DFSR and/or NTFRS services aren't running If both DFSR and NTFRS services are stopped, Domain Controllers won't be able to replicate sysvol data. sysvol Data will be out of consistency.
  • If using DFSR:
      Run 'net start dfsr' on the affected Domain Controller.
    1. If using NTFRS:
        Run 'net start ntfrs' on the affected Domain Controller.
  • Netlogon service isn't running Logon requests, registration, authentication, and locating of domain controllers will be unavailable on this DC. Run 'net start netlogon' on the affected Domain Controller
    W32Time service isn't running If Windows Time Service is stopped, date and time synchronization will be unavailable. If this service is disabled, any services that explicitly depend on it will fail to start. Run 'net start win32Time' on the affected Domain Controller
    ADWS service isn't running If Active Directory Web Services service is stopped or disabled, client applications, such as Active Directory PowerShell, won't be able to access or manage any directory service instances that are running locally on this server. Run 'net start adws' on the affected Domain Controller
    Root PDC isn't Syncing from NTP Server If you do not configure the PDC to synchronize time from an external or internal time source, the PDC emulator uses its internal clock and is itself the reliable time source for the forest. If time isn't accurate on the PDC itself, all computers will have incorrect time settings. On the affected Domain Controller, open a command prompt. Stop the Time service: net stop w32time
  • Configure the external time source:
    w32tm /config /manualpeerlist: time.windows.com /syncfromflags:manual /reliable:yes

    Note: Replace time.windows.com with the address of your desired external time source. Start the Time service:
    net start w32time
  • Domain controller is quarantined This Domain Controller isn't connected to any of the other working Domain Controllers. This may be caused due to improper configuration. As a result, this DC isn't being used and won't replicate from/to anyone. Enable inbound and outbound replication: Run 'repadmin /options ServerName -DISABLE_INBOUND_REPL' on the affected Domain Controller. Run 'repadmin /options ServerName -DISABLE_OUTBOUND_REPL' on the affected Domain Controller. Create a new replication connection to another Domain Controller:
    1. Open Active Directory Sites and Services: Start menu, point to Administrative Tools, then click Active Directory Sites and Services.
    2. In the console tree, expand Sites, and then expand the site, which this DC belongs to.
    3. Expand the Servers container to display the list of servers.
    4. Expand the server object for this DC.
    5. Right-click the NTDS Settings object, and click on New Active Directory Domain Services Connection...
    6. Select a Server from the list, and click Ok.
    How to remove orphaned domains from Active Directory.
    Outbound Replication is Disabled DCs with disabled Outbound Replication won't be able to distribute any changes originating within itself. To enable outbound replication on the affected Domain Controller, follow these steps: Click Start, click Run, type cmd and then click OK. Type the following text, and then press ENTER:
    repadmin /options -DISABLE_OUTBOUND_REPL
    Inbound Replication is Disabled DCs with disabled Inbound Replication won't have the latest information. This condition can lead to logon failures. To enable inbound replication on the affected Domain Controller, follow these steps: Click Start, click Run, type cmd and then click OK. Type the following text, and then press ENTER:
    repadmin /options -DISABLE_INBOUND_REPL
    LanmanServer service isn't running If this service is disabled, any services that explicitly depend on it will fail to start. Run 'net start LanManServer' on the affected Domain Controller.
    Kerberos Key Distribution Center service isn't running If KDC Service is stopped, users won't be able to authentication through this DC using the Kerberos v5 authentication protocol. Run 'net start kdc' on the affected Domain Controller.
    DNS service isn't running If DNS Service is stopped, computers and users using that server for DNS purposes will fail to find resources. Run 'net start dns' on the affected Domain Controller.
    DC had USN Rollback When USN rollbacks occur, modifications to objects and attributes aren't inbound replicated by destination domain controllers that have previously seen the USN. Because these destination domain controllers believe they are up to date, no replication errors are reported in Directory Service event logs or by monitoring and diagnostic tools. USN rollback may affect the replication of any object or attribute in any partition. The most frequently observed side effect is that user accounts and computer accounts that are created on the rollback domain controller do not exist on one or more replication partners. Or, the password updates that originated on the rollback domain controller do not exist on replication partners. There are two approaches to recover from a USN rollback:

    Remove the Domain Controller from the domain, following these steps:

    1. Remove Active Directory from the domain controller to force it to be a stand-alone server. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
      332199 Domain controllers do not demote gracefully when you use the Active Directory Installation Wizard to force demotion in Windows Server 2003 and in Windows 2000 Server.
    2. Shut down the demoted server.
    3. On a healthy domain controller, clean up the metadata of the demoted domain controller. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
      216498 How to remove data in Active Directory after an unsuccessful domain controller demotion
    4. If the incorrectly restored domain controller hosts operations master roles, transfer these roles to a healthy domain controller. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
      255504 Using Ntdsutil.exe to transfer or seize FSMO roles to a domain controller
    5. Restart the demoted server.
    6. If you're required to, install Active Directory on the stand-alone server again.
    7. If the domain controller was previously a global catalog, configure the domain controller to be a global catalog. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
      313994 How to create or move a global catalog in Windows 2000
    8. If the domain controller previously hosted operations master roles, transfer the operations master roles back to the domain controller. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
      255504 Using Ntdsutil.exe to transfer or seize FSMO roles to a domain controller Restore the system state of a good backup.

    Evaluate whether valid system state backups exist for this domain controller. If a valid system state backup was made before the rolled-back domain controller was incorrectly restored, and the backup contains recent changes that were made on the domain controller, restore the system state from the most recent backup.

    You can also use the snapshot as a source of a backup. Or you can set the database to give itself a new invocation ID using the procedure in the section "To restore a previous version of a virtual domain controller VHD without system state data backup" in this article

    Next steps