Integration runtime user being locked out continuously

Question

We are using the Self Hosted integration runtime with Azure Data Factory pipelines in Azure Synapse Analytics and the Integration Runtime user is constantly being locked out with Azure Active Directory.

Has anyone experienced this issue or have any insights on how we might best resolve. We are considering upgrading to Fabric or the On Premise Data Gateway to support this use case.

Additionally, we've already reviewed this troubleshooting guide but have not been able to identify the root cause: https://learn.microsoft.com/en-us/azure/data-factory/self-hosted-integration-runtime-troubleshoot-guide?tabs=data-factory

Answer 1

Hi **Jordan Berry
This behavior is typically caused by the Self-Hosted Integration Runtime repeatedly authenticating to Azure Active Directory with stale or invalid credentials. When this happens continuously, Azure AD lockout policies are triggered, even though pipelines may still appear to run.

In most cases, the root cause is cached or outdated credentials on the SHIR host. This often occurs after a service account password is rotated in Azure AD but not updated on the SHIR machine or in linked services. The Windows service running SHIR can keep retrying authentication in the background, resulting in repeated failed sign-ins and eventual account lockout.

Network or proxy instability is another common contributor. If the SHIR node cannot reliably reach Azure AD endpoints due to firewall rules, proxy misconfiguration, DNS issues, or intermittent TLS failures, the runtime retries authentication and each retry counts as a failed sign-in.

Azure AD Conditional Access or lockout policies can also play a role. Service accounts used by SHIR may unintentionally be subject to MFA or strict lockout rules, causing repeated authentication failures.

To confirm the cause, review Azure AD sign-in logs for the affected account. These typically show repeated failures from the SHIR machine’s IP or hostname. SHIR logs on the node usually align with the same timestamps.

A practical fix is to reset the service account password, update all linked services and SHIR configurations, and restart the Integration Runtime service. Using a service principal with certificate-based authentication greatly reduces lockout risk. Longer term, Microsoft Fabric or the On-Premises Data Gateway can help by reducing reliance on user-based Azure AD authentication in hybrid scenarios.

In short, this is almost always caused by repeated Azure AD authentication failures from the SHIR host rather than a Synapse or pipeline issue.

Answer 2

If the Integration Runtime user is being locked out continuously, it could be due to several reasons related to authentication or configuration issues. Here are some potential causes and resolutions:

1. Authentication Issues: Ensure that the credentials used for the Integration Runtime are correct and that there are no policies in place that might cause frequent lockouts, such as incorrect password attempts or expired credentials.
2. Service Account Configuration: If you're using a service account for the Integration Runtime, verify that the account has the necessary permissions and is not subject to lockout policies that are more stringent than expected.
3. Network Issues: Sometimes, network configurations or proxies can cause repeated authentication attempts that may lead to lockouts. Ensure that the network settings are correctly configured and that the Integration Runtime can communicate without issues.
4. Review Logs: Check the logs in Azure Active Directory to identify the source of the lockouts. This can provide insights into whether the lockouts are due to failed login attempts from the Integration Runtime or from other sources.
5. Upgrade Considerations: If you are considering upgrading to Fabric or using the On-Premise Data Gateway, evaluate whether these solutions might provide a more stable authentication method or better integration with Azure services.

Since you have already reviewed the troubleshooting guide, it may be beneficial to reach out to Azure support for more tailored assistance if the issue persists.

---

References:

• Troubleshoot self-hosted integration runtime