This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(249.60000000000002, 16%, 34%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESD%3C/text%3E%3C/svg%3E)
We have a conditional access policy set up to require users logging into to our Azure DevOps application to to reauthenticate every day. This is done via a policy that targets the Azure DevOps Resource and sets the session sign-in frequency to one day.
The policy is set to "On" and in the Entra ID sign-in logs we can see that it is applied to users who try to access Azure DevOps. But the access is not actually blocked/reauthentication required on a daily basis. In other words, notwithstanding that the policy is applied, user sessions to Azure Devops persist for (far) longer than 24 hours.
What's also strange is that, in the sign-in logs, these accesses are shown as "Failed" with a message
The refresh token has expired or is invalid due to sign-in frequency checks by conditional access. The token was issued on {issueDate} and the maximum allowed lifetime for this request is {time}.
Which makes sense. Excepts that the logins DONT actually fail.
We have similar refresh policies set up for other apps and they appear to be working.
Any suggestions on what could be going on here?
A cloud-based identity and access management service for securing user authentication and resource access
It appears that ADO currently does not respect sign-in frequency, but that is expected to change soon:
https://github.com/MicrosoftDocs/azure-devops-docs/issues/13983
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(128, 8%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
Hi @Sam Davidoff , if you're still having issues, can you please send me an email at "azcommunity@microsoft.com" with subject "ATTN: James Hamil" and your subscription ID? I can open a free support ticket for you.
Best,
James
Thank you James. I apologize for not updating this thread, but based on feedback from other MSFT employees, it appears that ADO currently does not respect sign-in frequency, but that is expected to change soon:
https://github.com/MicrosoftDocs/azure-devops-docs/issues/13983
https://developercommunity.visualstudio.com/t/Conditional-Access-sign-in-frequency-not/10581533
The github issue in particular explains what is going on.
So I was curious about this and it appears there are scenarios where a CA policy is enforced with Dev Ops:https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/change-application-access-policies?view=azure-devops#cap-support-on-azure-devops As I mentioned before the block works from what I have seen using Azure Mgmt as the target app, but I wonder if there is something being missed here
Yes, that documentation would seem to suggest that CAP will work with Azure Devops, though I note that it does not specifically refer to sign-in frequency policies. (Note that other CA policies w/r/t DevOps, e.g. MFA, seem to work fine. For example, we have a CAP that requires FIDO2 for DevOps logins and that works as expected.) I'm curious if anyone else has either experienced this problem or has successfully been able to limit the persistence of DevOps sessions. It seems to me strange that there is no way to reduce the length of persistent sessions that give access to something as important as code....
Might be worth opening a ticket with Azure support!
Interesting. So I tried both things you recommended and neither block DevOps' persistence. I set a CAP for 1 day sign-in frequency targeting the Azure DevOps and Windows Azure Service Management API, and I set a separate policy that sets the same 1 day sign-in frequency but for a certain group of users regardless of app. The result is the same. In the sign-in logs, the sign-in is recorded as "Failed" with the same error message above, CAP shows that all both policies (app-specific and user-specific) were applied. And yet the DevOps session marches on undisturbed... Has anyway successfully used Conditional Access to increase the sign-in frequency for DevOps?
can you post pics of how the policies are set? In my experience, a block of Windows Azure Service Management API also blocks DevOps, so I would assume that means the CA policies to apply to all the various workloads under that umbrella.
Sure (and thank you for your help). Pics attached. Note that we have other policies that apply to DevOps (for example, phishing resistant auth) and those work fine. It's the session policies that seem to be getting ignored.
the user based one. Can you try it without specifying the apps? IOW, only scoped to some test users...and all apps
yes, it's not scoped to any apps. see the first screen above it is scoped to "All Cloud Apps"
Sorry, misunderstood, yes, that's already scoped to All Cloud Apps.
Hi yes, sorry ,missed your first pic
You really can't target DevOps alone.
You have to target the entre Azure mgmt API suite:
When you target the Windows Azure Service Management API application, policy is enforced for tokens issued to a set of services closely bound to the portal. This grouping includes the application IDs of:
Because the policy is applied to the Azure management portal and API, services, or clients with an Azure API service dependency, can indirectly be impacted. For example:
Note The Windows Azure Service Management API application applies to Azure PowerShell, which calls the Azure Resource Manager API. It does not apply to Microsoft Graph PowerShell, which calls the Microsoft Graph API Also: Session timeouts work best when targeting users, not apps per se ,but if you target the Azure Service API , I would think it will work for you , so I would test that out: