Overnight some of our unattended SMTP mailboxes (used for sending email from code) have stopped working with error:
Authentication requirement Single-factor authentication
Status Failure
Continuous access evaluation No
Sign-in error code 53003
Failure reason Access has been blocked by Conditional Access policies. The access policy does not allow token issuance.
I am trying to simply remove these accounts from the MFA requirement (which I dont actually recall switching on for all users) but every screen I click on I receive an error stating that I need a Premium subscription to configure conditional access. What am I missing? Surely an access policy that we are not licenced to configure should not be getting applied?
Check if security defaults are disabled under
o365 Admin Center > Settings > Org Settings > Modern Authentication
Related
Azure AD Premium has the concept of Conditional Access Policies. When you change the sign-in frequency it doesn't affect the access token or refresh token lifetime.
Since the access token has a default lifetime of 1 hour, no matter what you set the sign-in frequency to in Azure, after 1 hour the refresh token will be used to fetch a new access token.
So setting a sign-in frequency in Azure AD premium has no effect on a default msal app.
And indeed I tested this by doing the following simple steps:
Download the msal angular sample that uses auth code flow with PKCE (https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/lib/msal-angular)
Add an Conditional Access Policy in Azure AD premium on the app registration for the app above
Make sure the policy is applied when the user signs in (e.g. by checking Sign Ins blade or what-if tool on Enterprise app).
Below is the conditional access policy:
Below tenant configuration shows that the user cannot select the "Stay signed in?" option when signing into any application in this tenant.
Below the relevant parts of the results of dsregcmd /status. I am aware the SSO status has an effect on Conditional Access Policies.
+----------------------------------------------------------------------+
| Device State |
+----------------------------------------------------------------------+
AzureAdJoined : NO
EnterpriseJoined : NO
DomainJoined : YES
DomainName : <redacted>
Device Name : <redacted>
+----------------------------------------------------------------------+
| User State |
+----------------------------------------------------------------------+
NgcSet : YES
NgcKeyId : <redacted>
CanReset : NO
WorkplaceJoined : YES
WorkAccountCount : 2
WamDefaultSet : NO
+----------------------------------------------------------------------+
| SSO State |
+----------------------------------------------------------------------+
AzureAdPrt : NO
AzureAdPrtAuthority : NO
EnterprisePrt : NO
EnterprisePrtAuthority : NO
I obtained the following response from Microsoft server team and I can confirm that it is accurate, albeit unintuitive:
Conditional access executes based on token audiences, and we don’t
execute it for id_tokens where the token audience is a public client.
That’s why the CA policy doesn’t kick in
The reason why CA doesn’t execute for id_token for public clients is
because CA is meant to protect data from the cloud, and having an
id_token from a public client doesn’t grant access to any data from
the cloud.
It’s about the data that could be accessed in their request.
They can try few other options:
They can change their policy to apply to “All apps”, then SIF (Sign In
Frequency) will kick in. E.g. They can try to set the policy on
Exchange Online, and request mail.read scope Another example: They can
try to set the policy for Sharepoint Online, and request files.read
scope
So, we will apply the conditional access policy if the conditions are
met, but only for tokens that could access data in the cloud.
I changed the conditional access policy to apply to "all apps" instead of just the app registration for the msal app. The MSAL app does correctly reject the refresh token and redirect after 1 hour. I did not try the other examples, but they also seem like valid workarounds given what would trigger the SIF to kick in.
I have enabled the Web Application Firewall in the Azure FrontDoor with the default policy with the detection mode.
In the logs generated by the WAF, we can see the firewall is marking the reply url set in AAD with action as Block.
I believe the firewall is detecting this as threat.
Since the url is required for the working of AD authentication, what can be done to ensure the security ?
Or this can be ignored ?
Go to your WAF policy of Front Door WAF policy and click Managed rules. Collapse all and click the related policy and change action to Allow. Then refresh the WAF in front door, it will apply.
You could custom rules for WAF with Azure Front Door and refer to the disable rule in app gateway to fix false positives.
You shouldn't need the reply URL to properly as it's really only required to get the access token. If you're getting the access token and you don't need access to the reply url, this shouldn't be something you need to worry about.
If you would like to get to the reply url for purposes of your application, you could unblock it, but there shouldn't be any security issues assuming you know that the reply url is secure.
Per the docs : https://learn.microsoft.com/en-us/azure/active-directory/develop/reply-url
A redirect URI, or reply URL, is the location that the authorization server will send the user to once the app has been successfully authorized, and granted an authorization code or access token. The code or token is contained in the redirect URI or reply token so it's important that you register the correct location as part of the app registration process.
I am using a daemon auth API and I am able to get /groups but if try and use /groups/GROUPID/planner/plans I get a UnknownError and the message says
401 - Unauthorized: Access is denied due to invalid credentials.
You do not have permission to view this directory or page using the credentials
that you supplied.
I have Group.Read.All, Directory.Read.All, Group.ReadWrite.All, Directory.ReadWrite.All permissions as per the documentation. And I am using the https://learn.microsoft.com/en-us/graph/auth-v2-service?context=graph%2Fapi%2F1.0&view=graph-rest-1.0 (Get access without a user
) steps to get my token. I have got my administrator to click the Grant access (they are all "Granted").
Only planner stuff seem to be the issue (I can get, create, delete groups, and everything else) I am using v1.0 of the API and I tried beta both didn't work.
I checked my access token on jwt and it has
"roles": [
"Group.Read.All",
"Directory.ReadWrite.All",
"Group.ReadWrite.All",
"Directory.Read.All"
],
Which I assume means they are all there.
You are using client credentials flow which uses application permission. But GET /groups/{group-id}/planner/plans api doesn't support application permission. It needs delegated permissions. See the difference here.
I am trying to use ADALJS(https://github.com/AzureAD/azure-activedirectory-library-for-js) to access Azure Active Directory. I am successfully able to perform the login however when I try to make a webapi call I get the following error
Error description:AADSTS65001: No permission to access user information is configured for 'clientid' application, or it is expired or revoked.
You can follow this sample to verify your application configuration : https://github.com/AzureADSamples/SinglePageApp-WebAPI-AngularJS-DotNet
You may be missing to enable Oauth2 implicit flow in the manifest.
We have an app that allows a user to connect to Salesforce and import data using OAUTH. Works fine for Dev edition users, but Enterprise edition users sometimes get a 401 Forbidden when the app makes a call to describe after they're successfully logged in.
I did manage to find this nugget in Saleforce's documentation for describeSObjects() that says:
Your client application must be logged in with sufficient access
rights to retrieve metadata about your organization’s data.
Does anybody know what exactly those sufficient access rights are? For Enterprise edition users, does the Salesforce admin need to grant specific permissions to the user, so that user can retrieve metadata?
Any help is much appreciated.
Needed to have full access permissions set on the Connected App.
The salesforce admin controls which users have access to which sobjects via the CRUD settings on the users profile.
Typically you'll want to call describeGlobal first, which'll give you info about which the sobjects the user has access to.
You shouldn't see a 401 from the SOAP API, as SOAP 1.1 requires errors to be returned with a 500 status code. So i'm guessing you're using the REST API, but 401 is Unauthorized, not Forbidden, if you're really getting a 401, it sounds like you might be using an expired access token. The response body should have more info on why you got an error response.