We previously used keyvault and connectionstring to access resources in azure. However it will generate many parameters needed. We want to simplify the process.
We wanted to use aad authentication.
Firstly, we tried certificate-based aad authentication https://learn.microsoft.com/en-us/azure/cosmos-db/sql/certificate-based-authentication first, it works. But the thing is, in keyvault the certificates are set auto-rotation, but in aad app, we can only manually upload new certificate each time (I know there are methods like VM extension or extra software can do auto renewal, but it's complicated. We just want change configs in azure portal and change service code to access.) In this situation, when certificates becomes more and more, it's not suitable to manually renew each cert in each aad app. I notice in some places it says setting tls/ssl settings which makes auto-renewal, but currently in azure portal, it just can manually upload certificates. Only in function app can do tls/ssl settings.
Secondly, then we notice another one as managed identity. It simply says azureServiceTokenProvider.GetAccessTokenAsync("https://management.azure.com/"); to get token. But the thing is, current login tenantid is microsoft.onmicrosoft.com, but the resources and the subscriptions are all in prdtrs01.onmicrosoft.com through torus account.
Even I try with string accessToken = azureServiceTokenProvider.GetAccessTokenAsync("https://management.azure.com/", prdtrs01tenantid) still does not work, saying AADSTS50020: User account '{EmailHidden}' from identity provider '...' does not exist in tenant 'PRDTRS01' and cannot access the application '...'. It seems just cannot get token from prdtrs01 tenantid.
Also, I tried to replace the aad app used in first method with the function app used in second method to do certificate-based authentication. However the function app does not have a clientid, just principalId and user managed identity's clientid. Both ids fail with ClientAssertionCertificate credential = new ClientAssertionCertificate(clientId, cert); in certificate-based authentication. It finally says "Client assertion contains an invalid signature. [Reason - The key was not found., Thumbprint of key used by client".
In all, I described several ways we tried, but all failed. Can anyone help?
Thanks
AADSTS50020: User account '{EmailHidden}' from identity provider
'...' does not exist in tenant 'PRDTRS01' and cannot access the
application
As per this first error , it means that the account you are using to access the application is not a part of the tenant that the application is hosted on.
Make the application as a Multi-Tenant Application :
You can convert the application to accept users from multiple tenants. In this way you can give access to users who are not in your tenant without having to add them to the tenant where the application is in.
Maybe account type is set to Accounts in this organizational directory only.
You may have to change it to Accounts in any organizational directory.
Go to Azure portal -> Azure Active Directory -> Manage -> App Registrations --> your app name -> Supported Account Types
(or)
Add the user to the tenant as guest :
You may need to add the user to the tenant that the application is hosted in. You can follow this document to add the user with your domain as a Guest User to the tenant. And grant access to the application for the said user.
However, if your authentication call is for specific tenant i.e., https://login.microsoftonline.com/yourtenantname or_id, users from other organizations won't be able to access the application and are required to be added as guests in the tenant specified in the request.
In your case, try to authenticate request like https://login.microsoftonline.com/organizations or https://login.microsoftonline.com/common
Related
I've been poking around MS Graph OAuth2 consent and access token for the enterprise Azure app that had been created along the way. Basically, I'm confused why when I delete the app, I'm still able to obtain the access token ?
When I decrypt and check the claims, it is referencing the name and object id of the deleted app, but it has no roles, and can't be used to access any resources, which makes sense. But still, I'm confused why is being issued for the app that doesn't exist any more ? For example, if I open the app and select to disable login for users, access token is no longer issued - but deleting the whole app does not behave in the same way.
While working with applications in Azure AD, you should be aware of few things like:
App Registrations is where you register an application and configure the details like API permissions, client secrets, client certificates, token claims, app roles etc....
Enterprise Applications are list of service principals that are associated with applications in App Registrations which defines who and what resources the application can access.
When an app is registered in Azure AD, it's corresponding service principal will be created with same name and same App ID in Enterprise Applications blade automatically.
Please note that, whatever changes you do to service principal will directly affect the registered application and vice versa.
I tried to reproduce the same in my environment and got the below results:
I have registered an application in Azure AD and granted permissions like this:
Go to Azure Active Directory -> App Registrations -> Your App -> API Permissions
I generated an access token using client credentials flow, and I can see the roles claim in decoded token like below:
Now, I deleted the Enterprise Application of same name and App ID like below:
Go to Azure Active Directory -> Enterprise Applications -> Your Application -> Properties -> Delete
After deleting that Enterprise App, I'm still able to generate the access token and can't find roles claim now like below:
As the service principal of the application is deleted, you cannot access the other resources which removes permissions from token.
Please note that,
If you delete the application in App Registration first instead of Enterprise App, it will automatically delete the associated service principal (Enterprise App) too along with it.
Then you cannot even generate the access token as it gives Unauthorized client - Application not found error. Unable to generate access tokens is similar to disabling login for users.
Reference:
Apps & service principals in Azure AD | Microsoft Docs
I try login to Azure AD web app and when i do it with user inside my tenant its ok,
but when login other user i get
AADSTS50020: User account '*******' from identity provider 'live.com' does not exist in tenant 'Default Directory' and cannot access the application 'a1eda862-65fb-4f90-8482-06151f5c7abc' 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.
Login Url :
https://login.microsoftonline.com/common/oauth2/authorize?client_id=a1eda862-65fb-4f90-8482-06151f5c7abc&response_type=id_token+code&redirect_uri=http://localhost:44302/&response_mode=form_post&scope=openid+profile&state=12345&nonce=7362CAEA-9CA5-4B43-9BA3-34D7C303EBA7&resource=https://management.azure.com/
Tenant settings
Few things to check -
Based on the error you shared, it seems you're logged in with some Microsoft account like live.com/hotmail etc. Are you doing that intentionally or just happened to be logged in and getting confused by that? If you do want to login with a Microsoft account other than a usual organizational account, then as the error says, you need to add that account to your AzureAD tenant as an external user.
AADSTS50020: User account '*******' from identity provider 'live.com' does not exist in tenant
For any other organizational user, i.e. user from a different AzureAD tenant than the one where this application is registered, you will first need to go through the consent process. You may have done it already or not.
More details on that process here - https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-devhowto-multi-tenant-overview#understanding-user-and-admin-consent
Issue:
You wanted to use a personal account within a multi-tenant application to get a token for the "https://management.core.windows.net" API
Scope:
We will focus on this issue and consider it as resolved once we provide you with the reason that Personal accounts cannot be used against a v1 multi-tenant application.
Alternatively, we will consider this case resolved if we confirm that the problem is caused by a third-party application or is by-design.
This agreed resolution statement describes the specific conditions where we will close this case. Please let me know if you do not agree with this scope.
Cause:
For multi-tenant applications in v1 you can only use an organizational account and not a personal one. That happens because for personal ones you will be logged authenticated by the “Live” endpoints and not by Azure endpoints, also because we are sending the user to the “common” endpoint and in there we do not know in which directory you want to sign in.
Resolution:
Having a multi-tenant application and sign-in users with personal and organizational accounts can be covered by the Azure AD V2 endpoints, nevertheless the v2 has some limitations right now and one of them is that you could only get a token for Microsoft Graph API and not for https://management.core.windows.net. We plan to implement all APIs that are available in v1 also in v2, but as for now cannot be used to acquire a token for such API.
I want to understand the difference between the SPN & UPN in Azure AD Context. My understanding is there are three way to establish identity in Azure AD
Users Key in their username and Password to establish Identity
An application using ClientId and Secret Key to establish Identity
An application using ClientId and Certificate to establish Identity
Is User/Password is called UPN & rest two are called SPN? Also is there any other way to establish identity?
In Azure AD, UPN is the User Principal Name. It is always in the format which looks like an email address. Essentially it has three parts. User account name, the separator (i.e. # symbol) and UPN suffix or domain name. Its primary purpose is to use during the authentication and represents user identity.
SPN is the Service Principal Name. The service principal object defines the policy and permissions for an application, providing the basis for a security principal to represent the application when accessing resources at run-time. App identity (service principal) is preferable to running the app under your own credentials (user identity) because:
You can assign permissions to the app identity that are different than your own permissions. Typically, these permissions are restricted to exactly what the app needs to do.
You do not have to change the app's credentials if your responsibilities change.
You can use a certificate to automate authentication when executing an unattended script.
You could create service principal with password or certificate as you shown.
Please click here for more about application and service principal objects in Azure Active Directory, and click here for how to use portal to create an Azure Active Directory application and service principal that can access resources. You could choose other ways (e.g. PowerShell/CLI) on the left navigation panel.
I am working with Azure AD through OAuth 2.0 protocol and also creating a Service/ Dameon application to handle the authentication process for Microsoft Graph SDK. For the service/daemon, I make a HttpWebRequest and pass along the client_id and client_secret to generate an access_token where I then can supply to the Microsoft Graph SDK.
I also have successfully created a corresponding service principal to the target tenant, in which an admin has granted permissions to the application using the authorization code grant flow. The application then shows in Overview -> Quick tasks -> Find an enterprise app, within the (portal.azure.com).
My question is there an approach where I can leverage the service/daemon approach while also allowing an admin from the target tenant to authorize the application, that would allow the target tenant to create a client_secret to pass which would be unique to that tenant?
Short answer is no. When an admin consents your multi-tenant app:
A Service Principal is created for it in their tenant
Permissions requested by the app are granted in that tenant
This means your app can now authenticate with its client credentials (id + secret) against their tenant as well. So the same keys work in all approved tenants.
What that means is your app is free to get an access token for any of them at any given time, no matter who is signed in. So it puts some responsibility to your app to keep data separated.
If you get an access token from https://login.microsoftonline.com/company.com/oauth2/token, the resulting token will contain that tenant's identifier. And APIs like the Microsoft Graph API will only give you data for that tenant with that token. So your app must make sure to only use a token that has a tenant id equal to the user's tenant id claim.
I would say that juunas' answer is 99% correct. The short answer is basically no, and the considerations he mentions are also solid.
But I believe that this would be technically possible under certain considerations. When the admin consents to your daemon service, a service principal is created in your customer's tenant. Service principals do allow addition of credentials that can be used as client secrets on a per-tenant basis. The thing is, there's not really a way to add a credential to a service principal programmatically from your app. You would have to get an administrator to run some script to add the new credential to their tenant's service principal.
Even if you went through all this, you would need to make sure that your service is also isolated on a customer/tenant basis. Security-wise, it's sort of pointless to create per-tenant client secrets if your singular daemon has access to all of the secrets.
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).