Azure WebApp with Azure AD App returning `auth/login/aad/callback` permission - azure

After setting up a Azure Web App with Azure AD Authentication, the site is returning a 401 after authenticating.
This is the auth flow as I see it.
Go to https://mysite-$environment.azurewebsites.net/
Redirects to https://login.microsoftonline.com/
Authenticate using my credentials
Redirects to https://mysite-$environment.azurewebsites.net/.auth/login/aad/callback
Error You do not have permission to view this directory or page. HttpStatus 401.
Long version
I have 3 x Web Apps in Azure under the same Service Plan - 1 x website and 2 x APIs.
I would like these to use Azure AD for authentication.
So, I created an Azure AD App using Powershell.
$app = #{
DisplayName = "azad-$environment-mysite"
IdentifierUris = #(
"https://mysite-$environment.azurewebsites.net",
"https://mysite-api-$environment.azurewebsites.net",
"https://mysite-api-2-$environment.azurewebsites.net"
)
HomePage = "https://mysite-$environment.azurewebsites.net"
ReplyUrls = #(
"https://mysite-$environment.azurewebsites.net",
"https://mysite-api-$environment.azurewebsites.net",
"https://mysite-api-2-$environment.azurewebsites.net"
)
AvailableToOtherTenants = $false
}
New-AzureRmADApplication #app
Then using the ApplicationId returned, I have setup the Azure AD through the portal Web App > Authentication / Authorization blade.
This is similar scenario to question asked over at Azure AD server authentication, No permission to view directory question.

You have to register each app in the AAD and you can do it, more easily, via azure-portal.
When you have the web-app registered through the "Express" process everything should work as expected (OAuth2 flow). The problem may come with your API-app especially if you need to access with server-to-server.
Because the process is a little bit long to write here I wrote two posts:
Web API access through Azure Active Directory
API-APP server-to-server through Azure Active Directory
In the first post you can see the REST flow using POSTMAN.

Related

Unable to get access token. 'AADSTS500011: The resource principal named 'xxx' was not found in the tenant -tenantid

I am trying to get the access token for the Azure function app. I have enabled managed identity for the function app(system assigned). but while fetching the token using the nuget Azure.Identity.
var tokenCredential = new DefaultAzureCredential();
var accessToken = await tokenCredential.GetTokenAsync(
new TokenRequestContext(scopes: new string[] { "https://xxx.azure-api.net/" + "/.default" }) { }
);
I am getting the error.
The resource principal named 'xxx.azure-api.net' was not found in
the tenant 123
but when run az cli to check the subscription details, the subscription indeed part of the tenant 123 only.
Here is what I have finally done.
I have registered an App in AD. and Exposed the API of that App.
I have assigned System Assigned Managed Identity to the Function.
In the local I am not able to request token because Azure CLI is not given consent.
After deploying the application in Function my Function app can request a token using its identity.
You need to register the application in azure ad and enable the access token. Once that is done the you need to provide RBAC access to your xxx.azurewebsites.net
Follow this article for the step by step documentation Microsoft Document Reference
Unfortunately, the error message is not really helpful. But adding a scope to the app registration solved the problem for me:
In Azure Portal navigate to App Registrations
Find your app, in the left side menu select Manage => Expose an API
Add a scope. I named mine api_access as this was where this error occurred.
In my case I then got an API URI (like api://client-id/scope_name) which I used in my Angular app. Error message was gone.
Also, make sure that in the Enterprise Application you have created, under Manage => Properties, "Assignment required" and "Visible to users" is turned on.

Obtaining an access token for MSI enabled web application

I have a Web API project hosted in Azure as web app with Managed Service identity enabled (so I don't need an app registration, right?):
Now I need to obtain a token to access my API so that I can use it in POSTMAN:
az login
az account get-access-token --resource "https://mytenant.onmicrosoft.com/d3a219e0-bbbf-496b-a4a4-b9ca485c5a52"
which gives me
Get Token request returned http error: 400
and server response:
{"error":"invalid_resource","error_description":"AADSTS50001: The
application named
https://mytenant.onmicrosoft.com/d3a219e0-bbbf-496b-a4a4-b9ca485c5a52
was not found in the tenant named
xxxxxxxx-xxxx-xxxx-af31-xxxxxxxxxx. This can happen if the
application has not been installed by the administrator of the tenant
or consented to by any user in the tenant. You might have sent your
authentication request to the wrong tenant.
I get the same error if I try to use object id 63d571cf-79bf-405d-8304-a31fb64cb953 instead of app id as part of resource uri.
What am I doing wrong?
What am I doing wrong?
az account get-access-token is used to get token to access the Azure resource. We could get more information from this document.
--resource
Azure resource endpoints. Default to Azure Resource Manager Use 'az cloud show' command for other Azure resources.
The resoure should be in the following endpoints. And default resource is https://management.azure.com/
"endpoints": {
"activeDirectory": "https://login.microsoftonline.com",
"activeDirectoryDataLakeResourceId": "https://datalake.azure.net/",
"activeDirectoryGraphResourceId": "https://graph.windows.net/",
"activeDirectoryResourceId": "https://management.core.windows.net/",
"batchResourceId": "https://batch.core.windows.net/",
"gallery": "https://gallery.azure.com/",
"management": "https://management.core.windows.net/",
"resourceManager": "https://management.azure.com/",
"sqlManagement": "https://management.core.windows.net:8443/",
"vmImageAliasDoc": "https://raw.githubusercontent.com/Azure/azure-rest-api-specs/master/arm-compute/quickstart-templates/aliases.json"
}
Based on my understanding, the command no relationship with your API access.
For more information about MSI and how to protect an API by using OAuth 2.0 with Azure Active Directory, please refer to this tutorial and this tutorial.
The resource URI does not contain your Application Id nor Object Id.
It is a separate identifier that you can find from the App Registration's Properties under App ID URI.
And since this is an MSI-generated service principal, there is no app. I think you have to register an app in this case.

Azure AD - Add app principal to a Group

I have an Azure AD app (AAD App1) which has user assignment enabled. So only, users from a particular group let's say "Group A" can access any resource (let's say an Azure Function API) protected by that Azure AD app.
Now I have another daemon Azure function job, which needs to make an authenticated call to the above mentioned Azure function API. Since this is a daemon job, I have generated another Azure AD app (AAD App2) for this.
Below is my code to get access tokens:
string resourceId = "id of app used to authenticate azure function"; // AAD app ID used by the Azure function for authentication
string clientId = "id of app registered for the daemon job";// AAD app ID of your console app
string clientSecret = "secret of app registered for the daemon job"; // Client secret of the AAD app registered for console app
string resourceUrl = "https://blahblah.azurewebsites.net/api/events";
string domain = "<mytenant>.onmicrosoft.com"; //Tenant domain
var accessToken = await TokenHelper.GetAppOnlyAccessToken(domain, resourceId, clientId, clientSecret);
Now when I try to generate access token to access the Azure function API, I get an invalid grant error as below:
AdalException:
{"error":"invalid_grant","error_description":"AADSTS50105: Application
'' is not assigned to a role for the application
''.\r\nTrace ID:
6df90cf440-c16d-480e-8daf-2349ddef3800\r\nCorrelation ID:
4c4bf7bf-2140-4e01-93e3-b85d1ddfc09d4d\r\nTimestamp: 2018-05-09
17:28:11Z","error_codes":[50105],"timestamp":"2018-05-09
17:28:11Z","trace_id":"690cf440-c16d-480e-8daf-2349ddef3800","correlation_id":"4c4bf7bf-2140-4e01-93ef3-b85d1dc09d4d"}:
Unknown error
I am able to properly generate AAD access tokens if I disable the user assignment.
I am trying to avoid creating a service account here. Is there anyway I can add an app principal to an Azure AD group or add it as a member of another Azure AD app?
Unfortunately, you cannot add an AAD application/service principal as a member of Azure AD group.
I have confirmed this issue in My Answer for another similar question [EDIT - now seems to be possible, see said answer]
You can also upvote this idea in our Feedback Forum. Azure AD Team will review it.
Hope this helps!

Authenticating Sharepoint 2013 on-premise with Azure AD

Our client has an Azure AD containing all users in his company located in multiple locations around the world. He would like his users to be able to sign into our SP app using their Microsoft Accounts which are on Azure AD.
Obviously, since Azure AD uses SAML 2.0, and SharePoint uses Ws-Fed (which is similar to SAML 1.1), we need to convert these claims from 2.0 to Ws-Fed (or SAML 1.1).
This used to be done using Azure's Azure Control Services, which is going to be deprecated at the end of the year (2018), so there's no point in developing a solution that uses it.
As such, we found a number of guides here and here which detail how a Claims Provider Trust can be created between Azure AD and ADFS, and a Relying Party Trust be set up between AD FS and SharePoint.
In theory this works in the following way:
User logs into his Microsoft Account which is on the Azure AD, and the SAML 2.0 token with claims is sent from Azure AD to AD FS
All claims are passed to AD FS, since we configured our rules in this way (as instructed here)
AD FS converts these from SAML 2.0 to Ws-Fed (or SAML 1.1)
AD FS maps the necessary claims to the UPN (as instructed here) and sends the result to SharePoint
We seem to be encountering an issue in the conversion step.
We have debugged the process using Fiddler, to see requests to and from the AD FS server. Azure AD claims are successfully sent to AD FS, but an error is encountered when AD FS is issue new claims (supposedly in Ws-Fed or SAML 1.1).
The following is the stack trace from AD FS:
Microsoft.IdentityServer.Web.RequestFailedException: MSIS7012: An error occurred while processing the request. Contact your administrator for details. ---> System.ServiceModel.FaultException: MSIS3127: The specified request failed.
at Microsoft.IdentityServer.Protocols.WSTrust.WSTrustClientManager.Issue(Message request, WCFResponseData responseData)
at Microsoft.IdentityServer.Protocols.WSTrust.WSTrustClient.Issue(RequestSecurityToken rst, WCFResponseData responseData)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.SubmitRequest(MSISRequestSecurityToken request)
--- End of inner exception stack trace ---
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.SubmitRequest(MSISRequestSecurityToken request)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.RequestBearerToken(MSISSignInRequestMessage signInRequest, SecurityTokenElement onBehalfOf, SecurityToken primaryAuthToken, String desiredTokenType, UInt32 lifetime, Uri& replyTo)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.RequestBearerToken(MSISSignInRequestMessage signInRequest, SecurityTokenElement onBehalfOf, SecurityToken primaryAuthToken, String desiredTokenType, MSISSession& session)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponseCoreWithSerializedToken(String signOnToken, WSFederationMessage incomingMessage)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponseForProtocolResponse(FederationPassiveContext federationPassiveContext)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponse(FederationPassiveContext federationPassiveContext, SecurityToken securityToken)
System.ServiceModel.FaultException: MSIS3127: The specified request failed.
at Microsoft.IdentityServer.Protocols.WSTrust.WSTrustClientManager.Issue(Message request, WCFResponseData responseData)
at Microsoft.IdentityServer.Protocols.WSTrust.WSTrustClient.Issue(RequestSecurityToken rst, WCFResponseData responseData)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.SubmitRequest(MSISRequestSecurityToken request)
We've also done internal testing, whereby we logged in to the SharePoint site using the the local AD, in order to make sure that the setup between AD FS and SharePoint is correct. This worked as expected, and SharePoint received the claims as configured in step 4.
Any help with the "conversion" process from SAML 2.0 to Ws-Fed (or SAML 1.1) would be greatly appreciated.
Help me Obi-Wan Kenobi, you're my only hope!
Set AD FS' PreventTokenReplays param to false
In our case, this is what had us stuck for days. There was no mention of this anywhere that we read, and we only found out about it after going to the AD FS server's event viewer and going through the logs.
Open up PowerShell, and add the AD FS snapin using the following:
Add-PSSnapin Microsoft.Adfs.PowerShell
Then, get your AD FS properties, using the following:
Get-adfsproperties
Check the value for the PreventTokenReplays param. If it's set to false, you should be good.  If it's set to true, then flip it to false using the following command:
Set-adfsproperties -PreventTokenReplays $false
Now, you'll need to restart your AD FS service. Just go to services.msc, find AD FS 2.0 Windows Service, right click it, and hit restart.
Configuration Overview
Create a new Azure AD tenant and namespace.
Add a WS-Federation identity provider.
Add SharePoint as a relying party application.
Create a rule group for claims-based authentication.
Configure the X.509 certificate.
Create a claim mapping.
Configure SharePoint for the new identity provider.
Set the permissions.
Verify the new provider
You can follow this blog for step by step process
https://www.sharepointcollabs.com/2017/03/using-microsoft-azure-active-directory.html

Azure AD token has already access to other app without permissions

We have 2 apps registered in Azure AD, let's call them WebApi1 and WebApi2.
WebApi1 needs to call WebApi2. A secret has been configured in WebApi1 in order to get a token. Here is the code I'm using to get the token and then make the call to WebApi2:
And here is how my WebApi2 is configured:
The thing that I don't understand is that I would expect WebApi2 to return a 401 exception since I have not set any permissions in Azure (via the App Registration portal) to WebApi1.
Yet, the call is made successfully and WebApi1 has access to WebApi2.
Why WebApi1 has access to WebApi2 without the use of permissions in Azure?
Your web api application should check access using the IsInRole() or the [Authorize] attribute. If your web api doesn't check access , by default the access token with no application roles(permission) could access to your web api .
Please refer to document Roles based access control in cloud applications using Azure AD . Since you are acquiring token with application identity (client credential flow) , please check the Assigning client applications to application roles of resource APIs section in the document .
Just another thing.
If you're working with Azure and roles, when setting the WindowsAzureActiveDirectoryBearerAuthenticationOptions, you'll need to set the right role type in order for IsInRole (or Authorize("YourRole")) to work.
app.UseWindowsAzureActiveDirectoryBearerAuthentication(
new WindowsAzureActiveDirectoryBearerAuthenticationOptions
{
TokenValidationParameters = new System.IdentityModel.Tokens.TokenValidationParameters
{
ValidateIssuer = false,
ValidAudience = ConfigurationManager.AppSettings["AzureAd:Audience"],
RoleClaimType = System.Security.Claims.ClaimTypes.Role
},
AuthenticationMode = Microsoft.Owin.Security.AuthenticationMode.Active,
Tenant = ConfigurationManager.AppSettings["AzureAd:Tenant"],
});

Resources