How can one explicitly trigger an a MFA prompt e.g. from a web service for Azure Active Directory or ADFS users?
An example scenario could be that after a user authenticates and starts a session with the web app, certain actions would be gated by a MFA verification.
I see there are workarounds that could establish similar behavior by using MFA for login and then having the software prompt for login, but SSO would prevent these prompts from always reaching the user:
Phone Sign-In (Microsoft accounts)
MFA as Primary Auth (ADFS)
The intent here is to trigger a MFA verification that is separate from auth.
The actions that require gating would need to be a resource that requires MFA. If the resource requires MFA and the user did not sign in with MFA, they will be prompted. This article appears to cover this use case:
Quickstart: Require MFA for specific apps with Azure Active Directory conditional access
To simplify the sign-in experience of your users, you might want to allow them to sign in to your cloud apps using a user name and a password. However, many environments have at least a few apps for which it is advisable to require a stronger form of account verification, such as multi-factor authentication (MFA). This might be, for example true, for access to your organization's email system or your HR apps. In Azure Active Directory (Azure AD), you can accomplish this goal with a conditional access policy.
Related
We noticed that, on Azure AD Joined devices on the internet, the browser requests to authenticate on web resources protected by Azure AD (e.g. authentication on office.com) do not pass through ADFS, despite the fact that we have federated authentication in Azure AD. Why this happen?
We also noticed that the MFA challenge is requested only once, on the very first user access to any Azure AD protected resource, despite the fact that we have not allowed MFA token caching (we unchecked the option: “Allow users to remember multi-factor authentication on devices they trust”). Why this happen?
Where are these behaviors documented?
NOTES:
In our tests, the PCs are on the internet (not on the internal network)
On the Azure AD sign-in logs, we see that, every time a user login to the Azure AD Joined PC, there is a Windows Sign-In event logged with source IP equal to the internal IP of the Load Balancer in front of ADFS. That authentication then goes through ADFS. As said, this event does not appear in the logs when the signed-in user then authenticate to a web page protected by Azure AD.
Our Conditional Access policy asks for MFA on every access with the single exclusion of "trusted networks" that, in our case, corresponds to the MFA option "Skip multi-factor authentication for requests from federated users on my intranet"
We are doing our tests on Chrome browser with the W10 Account extension installed for the current user (but no profile authenticated) and on Edge with the profile authenticated with the same user who did the windows sign-in. Same behavior.
If we repeat the tests on the same PC, with another account not having the W10 Account extension installed on Chrome, the behavior on Chrome is completely different: we go through the authentication in ADFS and the MFA challenge, exactly as we see on PC not Azure AD Joined.
Thank you
Its because the Azure AD joined devices have a PRT. See https://learn.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token for details. The PRT is a feature to provide an enhanced SSO experience. It is available regardless of whether user is federated or not.
The PRT is acquired during logon. This is what you see as a "Windows signin event" in the Azure AD signin logs. The PRT prevents the need for further AAD resource access to be redirected via AD FS.
Chrome with the Windows 10 account extension makes use of the PRT. Not having the extension forces the federated logon you've observed.
Thank you for your answer.
I have a few additional doubts about this.
Is there a way to force the MFA challenge every time when accessing specific cloud applications from a W10 Azure AD Joined device (with a PRT) by using Chrome W10 Account Extension or Edge with logged in profile? All our tests with Conditional Access Policies were unsuccessful: in the sign-in logs we always found the condition: "MFA requirement satisfied by claim in the token". I understand that the recommendation is to "Configure authentication session management with Conditional Access", but this solution cannot force the MFA challenge for every access to specific cloud applications.
I understand that the PRT is automatically renewed with a rolling window of X days. Here it is written that the lifetime of a PRT is 14 days. Here I read that the sign-in frequency for the rolling window is 90 days. So, what is the default number of days for the renewal of the PRT? And under which conditions (Azure AD settings) the user get an MFA challenge when the PRT is expired? Is the PRT renewed only at Windows Sign-In or also when authenticating through the browser on a Cloud application or in other conditions, maybe also automatically, without user intervention?
The SSO through PRT should be "applicable to the Registered owner of the device and not to any other user who signs in to that device". In our tests this is not true: other Azure AD users who signin to the Azure AD jojned device go in SSO without MFA. Why?
Thank you again
About my question "Is there a way to force the MFA challenge every time when accessing specific cloud applications from a W10 Azure AD Joined device (with a PRT) by using Chrome W10 Account Extension or Edge with logged in profile?"
My understanding is that the answer is NO. Can you please confirm?
I understand and totally agree on the need to minimize MFA challenges but not all the enterprises already moving to modern device management with the first devices in AAD Join & MDM have previously developed a fully comprehensive set of security policies for their devices. For sure, not all of them are ready to use WHfB. I know enterprises that - for some reasons - have excluded the MFA challenge for the MDM device enrollment actions: in these (bad) conditions, from any AAD joined devices, any AD user synched in Azure can access sensitive cloud applications which were protected by MFA when accessed from devices not joined to Azure AD.
IMHO, the documentation is not clear enough on that evidence that the PRT suppresses the MFA: I could see only this small paragraph describing the evidence that AAD Joned device with "adequate" browser conditions do not get MFA challenges. IMHO, this should be clearly highlighted in the documentation related to planning for device management in Azure AD.
About the question on "applicable to the Registered owner of the device and not to any other user who signs in to that device", let me clarify the context, already tested on different lab/prod environments.
Get an Azure AD Joined device registered in Azure AD by the AAD User X
Sign-in to Windows with User X. Open Edge with signed-in profile for User X, open office.com and authenticate: no MFA challenge. This is expected: SSO by PRT
Sign-in to Windows with another User Y in the same directory. Open Edge with signed-in profile for User Y, open office.com and authenticate: no MFA challenge. This is not expected according to this documentation ("[no MFA is] applicable to the Registered owner of the device and not to any other user who signs in to that device").
Thank you
I have included SSO (SAML) authorization in my existing application. But for me it was an unpleasant surprise to find that only 2 types of users can use the login through the providers I added (Okta, Azure AD):
Users who are located in the corporate directory of the provider (for example, I made an application on my account, there are no more
users. This means that any other user will not be able to use the
login form, because he is not a member of my tenant)
Third-party users of companies, whose administrators have added a
template of my application from the general list and connected their
users to it.
I expected other results, I need ANY user to be able to log in through these providers (regardless of whether he is in the corporate directory or has his own separate account that is not integrated into my application)
I thought about changing the SAML protocol to OIDC (OpenID Connect), but it seems to me that everything will work in the same way (at least Azure AD, because it seems there are no other options for working with it, except for corporate distribution)
Who had a similar experience, could you tell me what I should use among technologies and protocols so that ABSOLUTELY ANY user can log into my application through Okta / Azure AD / Google? Thanks!
Azure AD login fail screen
Okta login fail screen
You can use Azure AD OAuth2 flows and multitenant apps with MSA (personal account) support to allow any user from any domains and personal accounts to login into your application. Or you can switch to Azure AD B2C (which also relies on OAuth2) to connect different identity providers (Local Azure B2C, Azure AD, Facebook, Google, Amazon, Github, Linked in, Twitter, generics, etc) and allow all their users to login into your application.
Not sure how to go about the following scenario:
User logs in with SAML using in an Azure enterprise configured application.
User authenticated succesfully.
If user now logs out from Azure -> I can catch this event using the logout url.
However if the user is deleted / removed from the organisation the user is still logged in in my application.
I've implemented similar logic with Oauth and refresh tokens, didn't find an equivalent using SAML.
As of now there is no support in SAML for the user provisioning events performed by the Idp.
In Azure enterprise configured application there is feature for Automate user provisioning and deprovisioning to applications which ensure that the identities in your app and systems are kept up to date based on changes in the directory or your human resources system.
For more information you can refer this link
I'm in a pickle, lacking the experiences that would provide me with guidance in my project and am seeking pointers from those for whom have Azure AD, SSO and Federation experience.
I am building an employee self service system and using Azure AD for identity management. I would like the user to be able to sign in using their employee ID # and password, not their email address; there should also be an option for the user to register for online access using their employee ID # and other personal information - their Azure Identity already having been established by humane resources.
The sign in flow would take the user to the Microsoft login page which would in turn detect that the user needs to sign in via a custom login page and redirect them there. Once they are signed in, my server would transmit their identity to Azure AD and grant them access based on the Azure Application permissions.
I'm simply really confused about how to start setting this up, if it's even possible. I'm aware of XSS but isn't Federation and SSO with SAML2 secure?
Do I need to use a federation application as a middle-man such as Ping Identity?
Thanks for any help!
Using e.g. Ping as an IDP generally won't help because Azure AD is already an IDP.
Microsoft Azure AD login pages can't be accessed by API and can't be customised to the extent you want.
And you can only sign-in with an email address because it's designed for domain-joined corporate customers.
You can do a lot of what you require with Azure AD B2C and custom policies. That will allow you to sign-in with a user name (= employee id) and you can create workflows.
You could then federate Azure AD and Azure AD B2C.
Your other option is to use an IDP that does allow authentication via an API e.g. Auth0.
Then you could have a custom login page that authenticates as appropriate.
Using Ping ID and other similar products is the fastest way to utilize SSO.
I have 2 tenants:
One for my organization, where I manage users (A)
One that I manage the applications and permissions (B)
My webapp is on tenant A and I configured authentication on the portal using Azure AD on tenant B.
On tenant B I registered the application with only one permission which does not require admin consent: Windows Azure Active Directory > Sign in and read user profile.
When the user logs in he gets the following error:
AADSTS90093: This operation can only be performed by an administrator. Sign out and sign in as an administrator or contact one of your organization's administrators.
I believe that this error should not be raised, since the only permission required by the application doesn't required admin.
EDIT
This is the URL that I am redirected to when I try to access the application when I'm not logged in
https://login.microsoftonline.com/d6ac45af-3289-4f79-a826-27824e1c467d/oauth2/authorize?response_type=code+id_token&redirect_uri=https%3A%2F%2Ftechnipfmc-tools-app-test.azurewebsites.net%2F.auth%2Flogin%2Faad%2Fcallback&client_id=d340f0ed-5eb3-43e8-9a50-c449649f3ee1&scope=openid+profile+email&response_mode=form_post&nonce=1895ec0ffef64447bbb712bdae61c7fb_20170521070654&state=redir%3D%252F
EDIT 2
I found out a solution here:
As an administrator, you can also consent to an application's delegated permissions on behalf of all the users in your tenant. This will prevent the consent dialog from appearing for every user in the tenant. You can do this from the Azure portal from your application page. From the Settings blade for your application, click Required Permissions and click on the Grant Permissions button.
I don't know why had to do that since I'm only using permissions that don't require admin consent.
There are several potential problems with your setup:
Your authorization request is set to a specific tenant, the one with tenantId d6ac45af-3289-4f79-a826-27824e1c467d. Only users from that tenant will be able to log in. If this tenantId corresponds to the one for your organization, where you manage users (A), then disregard this point. Otherwise you should either replace this with the tenantId of that tenant or with common which will allow users from any tenant to sign in.
Your application is not multi-tenant. For testing purposes, I replaced the tenantId with common and wasn't able to use this with my test tenant due to the following error: AADSTS70001: Application with identifier 'd340f0ed-5eb3-43e8-9a50-c449649f3ee1' was not found in the directory <MY_TEST_TENANT>. This indicates that the application isn't configured as a multi-tenant application. This is something you must explicitly turn on.
Your organization's tenant (A) might have disabled the ability for regular users to consent to applications. If this capability is disabled, admin consent is always required for the application to be set up in the tenant. To test to see if this is the case, address points #1 (use /common/) and #2 above and try with any other tenant. If you are able to consent with that other tenant but not your organization's tenant, then you'll know that admin consent is required for your organization.
You should check out the How to sign in any Azure Active Directory (AD) user using the multi-tenant application pattern article as it explains all of the points above in more detail.
I think that error appears when you are passing "&prompt=admin_consent" in the Login URL.
Even though you are not requesting Admin permissions, if you pass that query string, it will try to show you a consent dialogue so that you can consent on behalf of the whole tenant, which is an operation that only an admin can do.