Verify publisher domain for AAD multi-tenant app on tenant migration - azure

We're moving an existing application registration from our corporate tenant (foo-corporate.com) to a new dedicated tenant (bar-app.com).
The process of moving the app registration requires to create a new app registration in the bar-app.com tenant.
According to this article, we need to verify the publisher domain (foo-corporate.com) in the new dedicated tenant (bar-app.com).
This is necessary, as the user will otherwise see unverified as the publisher on the consent screen (see #5 on screenshot) instead of the publisher (foo-corporate).
The process to verify the publisher involves hosting a microsoft-identity-association.json on https://foo-corporate.com/.well-known/ to verify the publisher.
Questions
Is there another way to verify the publisher foo-corporate.com for the new app registration in bar-app.com tenant? We're a large enterprise and our development team doesn't have access to the hosting of foo-corporate.com (public website), so we can't put the json file there. I assume this is the case for most larger enterprises.
In case there is no other option, do we need to host this file permanently or is it only needed for a first verification and can be removed afterward?
Update 1
The question is about publisher domain verification and not custom domain verification as the first answer to this questions assumed.
Sample Consent Screen

You can verify your domain in Azure AD by adding a custom domain. You can verify it using any of the methods here, which include creating DNS records or placing a file on the site. The file is only required while verifying the domain; It can be deleted after the status shows as verified.
Azure Portal -> Azure AD -> Custom Domains:
From this page:
New applications
When you register a new app, the publisher domain of your app may be
set to a default value. The value depends on where the app is
registered, particularly whether the app is registered in a tenant and
whether the tenant has tenant verified domains.
If there are tenant-verified domains, the app’s publisher domain will
default to the primary verified domain of the tenant. If there are no
tenant verified domains (which is the case when the application is not
registered in a tenant), the app’s publisher domain will be set to
null.
Adding a tenant verified domain gives you more verification options. Verification ensures non-repudiation which is essential for Microsoft to display an application's publisher to an end user.
Without placing a file on a website for the domain (I don't have a website), these are the options available to me:
The first is the domain I verified through DNS, the second is the onmicrosoft.com default domain. Using the onmicrosoft domain however will not suffice as it is an Available domain as opposed to a Verified one.

Related

Allow all domains when adding a new user to Azure B2C using the microsoft Graph API

I am creating user with gmail, Facebook and any business account with azure ad. It will not create a new account with this domain. It uses a its custom domain for create account that we created in azure costum domain .
The domain portion of the userPrincipalName property is invalid. You must use one of the verified domain names in your organization.
My login feature is independent of domain, so how can this be resolved?
The domain portion of the userPrincipalName property is invalid. You
must use one of the verified domain names in your organization.
You might get this type of error when you added your custom domain in Azure AD tenant, but you haven’t verified that domain yet. Would suggest you to please verified that custom domain in Azure AD by adding TXT records of your domain.
Please refer this Microsoft Document to know how to verified domain.
Coming to your next problem you can add your Gmail or Facebook users in Azure AD by sending them Invitation as well as a guest user.

Application ID URI Throwing Error in Azure AD App Registration using Terraform

I have a web app and corresponding app registration. Many months back in the "Expose an API" section in App Registration i was able to add the URI of my web app which was "https://app-coalsa-api.azurewebsites.net"
Right now when i try to do the same with another project with a similar kind of environment using Terraform, i get the error as attached in the screenshot.
Any idea if this error is coming because of the new Azure AD Provider and what shall ideally be in the "Expose an API" in app registration
Could it be that this app registration is configured as multi-tenanted?
It is a requirement for multi-tenant app registrations to have an App ID URI that uses one of the verified domains in the Azure AD tenant.
Because the azurewebsites.net is managed by Microsoft, it's not possible that it's a verified domain of your tenant, which could explain why the update fails.
See below:
For a multi-tenant application, it must be globally unique so Azure AD can find the application across all tenants.
Global uniqueness is enforced by requiring the App ID URI to have a host name that matches a verified domain of the Azure AD tenant.
From https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-convert-app-to-be-multi-tenant#update-registration-to-be-multi-tenant.
Looks like the answer is in error message itself. You can update the values inside Expose An API and possible values would be api://{object-IF-GUID} or https://{FQDN}.
Whenever any Azure AD app registration created it generates an object-Id and also linked who has triggered application id creation inside Azure AD.
you can update the values with any native azure services or any custom domain mapped to it but cant change or mapped to altogether new application otherwise it will result failure.
I have tried it and got the below error message:
{"error":{"code":"HostNameNotOnVerifiedDomain","message":"Values of identifierUris property must use a verified domain of the organization or its subdomain: 'https://{test-rohit-app-name}.azurewebsites.net'","details":[{"code":"HostNameNotOnVerifiedDomain","target":"identifierUris","message":"Values of identifierUris property must use a verified domain of the organization or its subdomain: 'https://{test-rohit-app-name}.azurewebsites.net'"}]
In your scenarios, accepted values are either {webappname}.azurewebsites.net or custom domain mapped to this web app.

Restrict azure app service Custom domain access to specific tenant

I am developing multitenant web application which is being hosted on azure app service.
It has 2 parts one is backend services which has pure APIs developed using .NET CORE and second is front end which consumes these APIs and is developed using Angular.
We are using Single instance , database per tenant concept where each user will have its own Database.
So there will be a catalog Db , which will hold information about each customer's tenant Id, tenant's Database connection string , customer Id etc.
We do not want to use Azure AD as of now, as our APIs are connecting to different ERPs to validate the user and data.
To achieve multitenancy, we are thinking of 2 ways
Unique Secret Id called TenantKey (for which we will be using some hashing function on TenanatId)
So every time they login, they need to enter this TenantKey along with UserId and password , so we authenticate this user based on that TenantKey and fetch DB connection string based on this.
We validate user by connecting to their own DB using Connection string fetched from CatalogDb.
Once we validate, we generate JWT token and this Connection string of Tenant's own Db is stored as Claim and will be used every time when user calls any API using this token.
This is working fine but
user has to remember and enter this TenanatKey along with UserId and password when they login everytime... which may not be user friendly...
As it is multitenant app, If another tenant gets to know the TenantKey they can access the info provided that they know the credentials(rare but possible)
Custom Domains
As Azure provides way to add custom domains to Azure App service through which we can identify the Tenant and Instead of TenatKey, we will be using this custom domain to find the Connection string in Catalog Db, create JWT token and store as Claim and use it
So question is , is there any way to secure these custom domains so only particular customer can access it? Like in their VPN?
I heard there is limit of 500 domains that can be added to an App service? will there be any way to extend if needed?
We will have load balancer going forward, will this customer domain have any effect on that?
Restrict your multi-tenant app to specific tenant
There are two steps to get started with tenant restrictions.
First, make sure that your clients can connect to the right
addresses.
Second, configure your proxy infrastructure.
To use tenant restrictions, your clients must be able to connect to the following Azure AD URLs to authenticate: login.microsoftonline.com, login.microsoft.com, and login.windows.net. Additionally, to access Office 365, your clients must also be able to connect to the fully qualified domain names (FQDNs), URLs, and IP addresses defined in Office 365 URLs and IP address ranges
For information on how to configure the proxy and the above process, refer here.
Output will be like this after configuring:
Restrict your multi-tenant app to specific users
If an app is secured with Azure AD, it's available to all users who authenticate successfully. But we will have the requirements to restrict access to specific users. This can traditionally be done within the application based on the roles.
Tenant admins and developers can restrict an app to a specific set of users or security groups in the tenant by also using this built-in Azure AD functionality.
Step 1
Log in to the Azure portal as a Global Administrator. In the top Azure bar search for the “Azure Active Directory”.
Step 2
From the properties left pane look for the “Enterprise applications” like below,
Step 3
Look for the AD application which you want, if you don’t find your application then select “All Applications” from the Application Type dropdown and use other filters also to find the application.
Step 4
Once you select the application, select “Properties” in the left menu and enable the “User assignment required” option to “Yes” and “Save” to update this configuration change.
Step 5
Make user assignments: Select “Users and groups” > Click “Add user”.
Step 6
It will direct you to the next page, where you may choose which users have access to the app services made available through this particular Azure AD app authentication.
Now, the user will be successfully authenticated when they attempt to log in to your Azure App Service with any legitimate AD user, but they will only be able to approve the application based on the configurations we just made.
For more information, refer here in Microsoft documentations.
I heard there is limit of 500 domains that can be added to an App service? will there be any way to extend if needed?
Yes, What you heard is correct!
You could try to contact Azure support to increase the limit:
Navigate to your subscription in the Azure Portal
Click on Usage + Quota
Click on Request increase
Select Other Request in the Quota Type field
Fill all other fields of the request

Getting error AADSTS50020 when trying to run Azure Tailspin sample application

I am making my first steps with Azure, trying to figure out how difficult it would be to spin up a mISV business where I would sell subscriptions to my app running in Azure (SaaS model).
To that end, I am trying to run the
Tailspin sample application
following instructions described
here.
To run the application, at least two Azure Active directories are needed. One AD belongs to the fictitious Tailspin software provider (in this case, me). The Tailspin Web application and the accompanying WebAPI are registered in this directory. Other AD belongs to a customer (in this case, again me). Customers sign up for the application.
I have a single Azure subscription, so I was forced to set things up like this:
I have registered Tailspin Web application and WebAPI in my Default AD. (I guess I could have created a specific AD for this purpose, but it was not strictly necessary.). The app and the API had to be created in this AD because they consume resources, and resources require a subscription. Putting the app and the API in a separate AD would require a separate Azure subscription.
I have marked both the Web app and the API as Multi-tenant (so that they can appear in other ADs after customer sign-up).
I have created another AD called TaiispinClient1 (the name is not important), with the idea to use it as a "customer" AD.
In TailspinClient1 AD I have created a guest user using one of my external email addresses. I could not create a regular AD user because creating regular users requires having a validated web domain and I did not want to go through validation at this point.
I have made sure that my guest user is every bit an admin user as the regular one:
In User Settings for the TailspinClient1 AD, "Users can register applications" is set to Yes (default)
In "Manage external collaboration settings", "Guest users permissions are limited" is set to No
My guest user has administrative directory roles (specifically, "Global administrator" and "Application administrator")
To resume, I ended up having two ADs in a single Azure subscription: the Default AD with the multi-tenant-enabled Tailspin app/API in it,
and the TailspinClient1 AD with an admin user (albeit external).
I am running the Tailspin application locally.
When I try to sign up to the application as the admin user from the TailspinClient1 AD, I am getting the following error message after I (successfully) authenticate myself:
AADSTS50020: User account <my TailspinClient1 admin user> from identity provider 'live.com' does not exist in tenant 'Default Directory' and cannot access the application <GUID of my Tailspin Web app> 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.
That message would have made sense had I forgotten to mark my Tailspin app/API as Multi-tenant, which I did not.
What am I missing here? Is this particular setup supported at all? Do I need to establish trust between those two ADs somehow?
Any help is appreciated.

How do I add users to tenant via the Graph API?

I've utilized the Partner Center REST API to provision tenants with orders/subscriptions. Now I want to start configuring the domains and users for the tenant I just created. My first step was to get a list of users using the Graph API https://msdn.microsoft.com/en-us/library/azure/ad/graph/api/users-operations as a test expecting to see the admin account. If I pass in the domain of the reseller account in the request URL, it shows me the reseller users. But when I put in the domain of the account I just provisioned, I get Invalid domain name in the request url. I'm using the resellers AD token to do this. I'm confused as it gives me the option to specify a domain, but I can only access my own.
What credentials am I supposed to be using here? I tried to use the user/pass that was generated for the admin account from the provision, but I get unauthorized_client when trying to get an AD token from the Graph API.
It is hard to directly address your issues here since they are a little broad, and I would need more specific details about the various tenants you are working with, how your app is provisioned, permissions your app has etc...
However I think there a few principals you can follow which may help you debug your issues.
All AAD Authentication happens within the context of a specific tenant. This means whenever you get an access token for a resource, the scope of that token is limited to the boundaries of the tenant.
To authenticate with a client application in the context of a tenant, you must have the app registered in the tenant you are trying to access (line of business application / single tenant) or you have to make the app multi-tenant, in which case your app should be able to function in the context of any tenant... if the right provisioning has occurred.
Every tenant where your app is trying to function must have a service principal for the application provisioned in the tenant. This service principal represents your application's identity in the context of that tenant, and acts as a place to store the permission your application has in the context of that tenant. Most normally, this service principal gets provisioned into a tenant after a user from that tenant has consented to use the app as a part of the login experience.
If you are trying to use user context (authorization code grant flow) to retrieve details about a tenant, you must ensure that that user is present in the directory you are trying to query. For example a user U can exist in their home tenant T1. If you try to query another tenant T2 using that user account, you will get any number of errors describing that the user account does not exist etc. You can remedy this by creating a guest account for U in T2, in which case there will be a brand new user object created in T2 which links to the original user object in T1. None the less, the user object should always be present in the tenant you are trying to query.
If you are trying to sign into an application with a user account that is in T1 and T2, you need to be sure to specify the tenant you want to actually get the token for. By default, if you use the common endpoint, you will get a token for the users home tenant. However, it is perfectly valid to get a token for the secondary tenant, as long as you specify that to our Token Service when making the request.
Finally the client application you use to make these requests needs to have the right permissions to the Graph API if you want to make specific calls to the Graph API. Every tenant needs to individually consent to the application in their tenant context in order to provision the correct permissions to their application.
With those principals in mind:
The error you are getting with "unauthorized_client" seems to be an issue with application provisioning in the secondary tenant. Please make sure to first login to the application with a user from the secondary tenant, and make sure that user has the correct permissions to consent to your app (a tenant admin is best here).
For the second issue with "Invalid domain name in the request url" please try using some hints here.
Specifically this:
By using the myOrganization alias. This alias is only available when using OAuth Authorization Code Grant type (3-legged) authentication; that is, when using a delegated permission scope. The alias is not case sensitive. It replaces the object ID or tenant domain in the URL. When the alias is used, Graph API derives the tenant from the claims presented in the token attached to the request. The following URL shows how to address the users resource collection of a tenant using this alias:
https://graph.windows.net/myorganization/users?api-version=1.6.
I hope this puts you on the correct path to resolve most of your issues.
There are issues with sandbox accounts and Azure. Access to the Azure Management Portal for the sandbox isn't straightforward and at this time does not work properly. I had to create a free Azure account with my hotmail account, then link AD from the new account to my sandbox AD to bypass the bug. When adding a new directory to the new Azure account, select "Use existing directory", sign out, then sign into the sandbox account you want to link it to. Then create your app from the new account.
After getting my app setup properly and new credentials, I had to enable pre-consent with the instructions listed at the end of: https://github.com/Microsoft/Partner-Center-Explorer
Lastly, I had to login to the Graph API with the customers ID, but with the resellers credentials.
The scenarios on the Partner Center SDK website include a section "Manage user accounts and assign licenses" under the "Manage customer accounts" section.
These samples include creating users and assigning licenses and a link to a console test app.
As an aside, a new version of the Partner Center SDK has just become available here. It was released on July 5th. While there is no official change history that I can find, I can see that it includes some new classes such as CustomerUser. You may find it easier to use that library rather than hitting the REST API (depending on how much work you've already done).

Resources