Entra ID Hybrid Join with SecureAuth Cloud IDP

Follow
    Applies to:
  • SecureAuth Identity Platform
  • Legacy SecureAuth IdP
Deployment model:
  • Cloud
  • Hybrid
  • On Premises
  • Version Affected:  [insert version(s) here]

    Description:  

    Entra ID Hybrid Join takes a long time when Entra ID domain is federated with SecureAuth IDP in cloud only deployment as federated join fails and it has to wait for fallback_sync to perform Entra ID Hybrid Join.

     

    Cause:  

    Federated join is not supported with Cloud IDP deployments as there is a local logon attempt to the IDP server is made via windowstransport endpoint by the client. Since Cloud IDP is not a member of your AD domain, it cannot validate credentials to allow the local logon and throws 4776 and 4625 events (Unknown user name or bad password).

     

    Resolution:  

    You can add a new custom domain to your Entra ID tenant and keep it as managed. You can use existing managed custom domain if it is already present in your Entra ID tenant. You can also consider adding a child domain of apog.com, which will by default be federated, but you can use Graph API to convert that to a managed domain. Once you have the custom managed domain, set SCP to use the managed domain instead of your federated domain. You can use GPO or registry to update it for specific client(s), if you don't want to configure SCP at this point.
     
    With the above change, client will always perform sync join, and you won't run into the wstrust/windowstransport issue that occurs with federated join. The client machine won't wait for federated join to fail to fallback to sync join and the overall Hybrid Join process will be faster.

     

    Microsoft Documentation:  

    https://learn.microsoft.com/en-us/entra/identity/devices/how-to-hybrid-join

     

    SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

    Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

    0 out of 0 found this helpful

    Comments

    0 comments

    Please sign in to leave a comment.