I have 2 different use cases for AD within the same app:
Sign a user in and nothing else
Sign in and read group/role claims, remove deactivated users etc.
Both are unique by user account, but live in the same app. It's important to avoid admin consent for the first case.
How can this be achieved? 2 different AD app registrations like "MyApp Simple" and "MyApp Enterprise"? Or is there something better?
You can try two different app registrations or just set the logic within the app itself and apply it based on the roles. From what I understand you will have certain users that have the same permissions but have different user experiences depending on where they sign in from? If this is the case you can just enable or disable the group/role claims in the app itself depending on the permissions applied to the user. I was able to achieve something very similar following this guide and repository. Please see if it helps.
Related
I'm creating a set of hands-on lab users in my Azure AD for access to Azure Labs. We will reuse these user accounts (and reset the passwords after every lab session).
My challenge is that these users are being required to configure MFA. Which I THINK is called the Azure AD Interrupt Mode described here.
Is there a way to exclude these group of users from being required to set this up?
I think this can be disabled entirely by navigating to Azure AD - Default Directory - Properties - Manage Security Defaults (right at the bottom of the page) - Enable Security Defaults - set it to No.
If it's per user basis, then Navigate to Azure AD - All users - Per User MFA - this will list all the users and then you can select "n" number of them to either enable or disable MFA.
// Answering my own question and hope it helps someone.
The first and obvious step is to disable MFA. This is described in this link: https://learn.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-userstates
After this, however, you may still face the interrupt wizard as shared in the screenshot of the question above. This is due to Self-Service Password Reset (SSPR) being enabled. If SSPR is enabled, then MFA is still required for them to be able to do a password reset.
Solution 1: If you want SSPR enabled, then create a Conditional Access policy requiring MFA upon sign in.
This way, MFA is only triggered when user wants to do an SSPR.
For this lab user scenario, you will still have to set-up MFA one-time for each of the users (you may use the same contact details).
Extra note: I tried setting the MFA details by bulk using PowerShell. However, it is not possible to set an MSOL user object's StrongAuthenticationUserDetails property.
Solution 2: Disable SSPR or limit to selected users using AD groups
Don't include the lab users in the selected users group. Since SSPR is not allowed for these users, the extra MFA details won't be asked of these users anymore.
Drawback: The setting is to include user groups which should have SSPR. There's no option to exclude just the lab users.
Solution 2 works for me but may not work for everyone.
At the company I work for, we have our own Active Directory setup. We also have a number of external partners who each have their own Active Directory setups. We are trying to use Azure AD B2C to create a single location to sign on. Adding multiple identity providers is easy, but buttons show up for each provider and due to privacy concerns we can not allow our partners to know who else we partner with. We wish to ask for an email, and direct the user to the correct identity provider based on the domain of the email.
I know there are ways to do this, however all of the ones I have found so far are extremely convoluted. The requirements for this feel like they would be very common in many businesses, so the concept that the easiest ways to implement this require approximately a hundred steps doesn't seem right.
I'm aware of Home Realm Discovery, but like above all examples I see of it require immensely complex setups (custom policies with claims providers calling an azure function to query from a database to return the idP), we already have to setup the Identity Providers is there really no simple way to say "emails from parter1.com use this provider, emails from partner2.com use this one"? If not, could someone explain the lease complex way of achieving this?
See this sample which collects email and does the HRD based on domain name.
https://github.com/azure-ad-b2c/samples/tree/master/policies/home-realm-discovery-modern
You must use custom policy if you collect email in the B2C page.
If you collect email in the app, then you could use a User Flow with a domain_hint param. You don’t need to do any xml work, just pass a domain_hint parameter equal to the idp name in the portal.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/direct-signin#redirect-sign-in-to-a-social-provider
Our application (referred to as "XYZ_App" below) is a multi-tenant SaaS application. We are in the process of making it available for Microsoft AppSource as a multi-tenanted "Web app / API" (referred to as "AppSourceXYZ_App" below).
We started our OpenID Connect implementation with endpoints pointing to “common” as per stated in the documentation when multi-tenancy is desired/required.
In XYZ_App, we added information in the system to know what AAD instance each XYZ_App tenant is associated with (using the GUID Microsoft assigned to this AAD instance, we are NOT using the "rename-safe.onmicrosoft.com" representation).
When using the “common” endpoints, we had to manually validate the issuer from the JWT to make sure it was the expected one: a user could access XYZ_App requesting access to XYZ_App’s tenant associated with contoso.onmicrosoft.com, get directed to “login.microsoftonline.com/common” to authenticate and then decide to authenticate with a user from another AAD instance (referred to as "anotherAADInstance.onmicrosoft.com" below). In this scenario, even though a user could successfully authenticate on anotherAADInstance.onmicrosoft.com, XYZ_App’s redirect URI must make sure the JWT issuer is the one from contoso.onmicrosoft.com. I’ll refer to this setup as Scenario_1.
With that scenario in mind, we thought about NOT using “common” and customize the requests going to login.microsoftonline.com on the fly; attempting to “jail” requests to be forced to authenticate against a specific AAD instance. We would still need to perform our validation in the redirect URI to make sure the issuer is the appropriate one, but we thought this approach might make our lives easier. I’ll refer to this setup as Scenario_2.
Do you envision Scenario_2 is viable in the long run or is it too short-sighted ? Based on my current knowledge of OpenID Connect, one limitation I can see with Scenario_2 is that it would become problematic to support “broker accounts” into our app.
Explanation of “broker accounts”: in our industry, some external users are allowed access to the system. Let’s say I have a company called “BrokerCo” (with their own brokerco.onmicrosoft.com AAD instance) who has 2 employees: Broker1 and Broker2. BOTH anotherAADInstance and contoso hired Broker1 and Broker2 to get broker services to perform tasks in XYZ_App; requiring XYZApp to grant them access. What is the ideal way for authentication from an OpenID Connect standpoint ? If XYZ_App were to use “login.microsoftonline.com/common” for authentication (like in Scenario_1; as opposed to “jailed” access like in Scenario_2), Broker1 and Broker2 could authenticate with brokerco.onmicrosoft.com (no AAD "External users" for anotherAADInstance nor contoso), but they would then get to redirect URI with an issuer that is different than what XYZ_App’s anotherAADInstance and contoso tenants are configured for... I feel like I’m back to square 1...
Do you have suggestions or pointers to solve this issue ?
Background context:
While playing with OpenID Connect issuers, I got the following error message:
AADSTS50020: User account 'testuser#anotherAADInstance.onmicrosoft.com' from identity provider 'https://sts.windows.net/XXXXXXXX-fake-GUID-9bZZ-XXXXxxxxXXXX/' does not exist in tenant 'XYZ Publisher' and cannot access the application 'YYYYYYYY-fake0-GUID-YYYYyyyyYYYY' in that tenant. The account needs to be added as an external user in the tenant first. Sign out and sign in again with a different Azure Active Directory user account.
Thanks in advance !
Your question has multiple layers, trying to address most of them:
AppSource is about trial experiences for new users: this mean that any corporate account around the globe can potentially be an user of your SaaS application - or at least to the trial experience of your application, therefore the first thing you need to think when integrating with AppSource is how easy it has to be for a potential user to experience your app for the first time.
With that in mind, AppSource recommends that the trial of application is build on such a way that allows any user from any organization to sign-in, and therefore a multi-tenant approach for your application is the recommended setup for any application.
The single-tenant approach requires more control on your side, and for a trial experience - it means that the user cannot try your application right away because the operation you have to do on your single-tenant application is to add the user to an Azure Active Directory tenant as a guest user. This guest account will need then to wait receiving an email to accept the invitation to join to this tenant you are adding the user to then sign-in to your application.
Therefore your scenario 1 is the best scenario thinking on a trial experience in general, and also in general require less management (as you'd not need to create/ manage each individual account that needs to access your application as guest users of your Azure AD instance).
However some concerns you listed - that this scenario bringing are valid: Because you are accepting the common endpoint, you are saying basically that any user can sign-in to any tenant to your application, and this may not be desirable. In addition, the scenario you listed that a user can generate a token for any application is also valid, however, you can add additional checks to make this more secure and that any token generated by another authentication is blocked:
You can validate the 'audience' claim to guarantee that the token was issued to your application
You can eventually check the 'tid'/'iss' claims against of a list of tenant Ids in your database to see if that the user's organization is a valid organization in your application -- this would be valid for non-trial users/ organizations.
More information in this article.
About scenario '2' and broker accounts:
This scenario could be interpreted in two different ways:
Broker accounts are guest accounts of a customers' Azure AD tenant
Broker accounts are third party accounts but are not actually added as a user of anotherAADInstance or contoso AD
If your case is '1' then you're right: if your application needs to authenticate guest users that belong to another Azure AD tenant, then common endpoint could not be used directly.
If your case is '2' then what you'd need to do is to continue using the common endpoint and somewhat after the user is authenticated ask them to choose the company. I am describing this on generic terms without fully understanding this scenario. Perhaps this is not simple as you want the remote company to control this and not the user - so some additional complexities may need to be handled here.
A note is that if your scenario is scenario 1. - in theory - you can still use an hybrid approach, where you'd ask user to type the username inside the application and the company that they want to sign-in, then check if you need to validate the user against common or tenant-id endpoint, preparing the request and then sending a login_hint argument when authenticating. More information here
I'm currently trying to integrate with Azure AD using the admin consent flow.
I've set up an app in our domain, set a few permissions on it and am then navigating to the following link:
https://login.microsoftonline.com/mytestdomain.onmicrosoft.com/oauth2/authorize?client_id=12345678-1234-1234-1234-123456789012&response_type=code&redirect_uri=http://example.com/responsehandler&resource=12345678-1234-1234-1234-123456789012&prompt=admin_consent&state=12345
(Some of the values here have been swapped out for "example" values)
When I navigate there I get asked to sign in, which I do using a different test domain into which I want to import the app.
After signing in I'm shown a list of all the permissions that the app needs (which appear to be correct), I click accept but then I get the following error:
AADSTS90002: Requested tenant identifier '00000000-0000-0000-0000-000000000000' is not valid. Tenant identifiers may not be an empty GUID.
I'm not sure where this empty GUID is coming from and after some searching I can't find any reference to what might be causing it.
Daniel Camargo's comment above seems to have done the trick.
When I navigated to the login.microsoftonline.com link I was logging in with the user that created the domain.
If I log in with a test admin user that I created it works as I'd want.
I am not convinced that we had exactly the same problem, given that my case was involving a Cordova application, but I will share my scenario anyway:
I created a trial account for my proof of concept and for that I used my personal Microsoft account that I will call mypersonalaccount#outlook.com.
Thus, mypersonalaccount#outlook.com is now part of 2 directories: the outlook.com and my recently created mypersonalaccount.onmicrosoft.com.
When I was trying to authenticate in my Oauth2 application using mypersonalaccount#outlook.com I got that error. My humble guess is that the error is related to some sort of collision between the 2 accounts.
I later created a user1#mypersonalaccount.onmicrosoft.com and a guest account using my gmail account. Everything worked fine with these ones.
Was having the same problem, and the same after 1 week of work by the azure team, was solved.
My problem was being trying to log in to VSTS with AAD accounts.
I have a Asp.net MVC application that uses Azure AD and OpenID Connect OWIN middlewares to handle authentication. Everything works fine except for one thing : if a user is already logged-in on another Microsoft Application lets say a Office 365 account or maybe a live mail account, when trying to login it recives a page saying that it is not allowed to log into my app, which is correct, but some how I need to catch that situation in my code to allow the user to sign in with a different account. Is there a way of doing that? This is by design? I mean : the user have to log in only with a live/azure account at the time ? I couldn't find any documentation about this.
As of today there is typically one user at a time, but we will soon support for you a way to select a specific user instead of automatically signing you in with the most recent one.
One way you can work around this today is by injecting the parameter "prompt=login" in your sign in requests. You can do that in the RedirectToIdentityProvider notifications, similarly to what is showin in http://www.cloudidentity.com/blog/2014/11/17/skipping-the-home-realm-discovery-page-in-azure-ad/ for domain_hint. This will cause the sign in experience to always start with a fresh prompt even if the user is already signed in. The draw back is that you'll never get SSO this way. Hopefully our account switiching feature will become available soon, keep an eye on http://blogs.technet.com/b/ad/ for announcements