i am playing around with the azure free triel and followed this tutorial (http://haishibai.blogspot.de/2012/11/complete-walkthrough-setting-up-adfs-20.html) titled "Setting up a ADFS 2.0 Server on Windows Azure IaaS and Configuring it as an Identity Provider in Windows Azure ACS".
When it comes to starting the MVC Web Application i am confronted with the following in the browser:
An error occurred while processing your request. HTTP Error Code: 400
Message: ACS20000: An error occurred while processing a WS-Federation
sign-in request. Inner Message: ACS50001: Relying party with realm
'https://ACS-NAMESPACE.accesscontrol.windows.net/' was not found. Trace ID:
64827ce0-71d2-49bf-996c-aadf23779fc7 Timestamp: 2012-12-13 22:17:12Z
Where ACS-NAMESPACE is the name of my ACS namespace.
I can say that i followed the steps given in the tutorial correctly, as i went through it several times. However, i can not figure our what the problem with my realm specification is.
Note: When i am configuring google or windows live as identity providers in ACS and not ADFS everything works.
Thanks,
David
The realm should be the URL of your MVC Web Application not the ACS URL - see http://msdn.microsoft.com/en-us/library/windowsazure/gg185906.aspx#BKMK_1 for an explanation.
If the realm is not found on ACS it is probably incorrectly configured as a ServicePrincipal on the WAAD Management service using powershell.
Please check the following and make sure you are configuring the correct ACS Namespace (and not the WAAD Tenant Name):
See if it is listed correctly by using
Get-MsolServicePrincipal
To create another one use following cmds:
$replyUrl = New-MsolServicePrincipalAddresses -Address "https://ACSNAMESPACE.accesscontrol.windows.net/"
New-MsolServicePrincipal -ServicePrincipalNames #("https://ACSNAMESPACE.accesscontrol.windows
.net/") -DisplayName "ACSNAMESPACE Namespace" -Addresses $replyUrl
Related
Looking for some answer. First time using Azure AD for authentication on ASP.Net Core and we have registered the app on azure for both my local and Dev-Server. Its working running on my laptop but after deploying to Dev server and changing the Client ID Value, it keeps giving me this error
*SecurityTokenInvalidSignatureException: IDX10511: Signature validation failed. Keys tried: 'System.Text.StringBuilder'.
kid: 'System.String'.
Exceptions caught:
'System.Text.StringBuilder'.
token: 'System.IdentityModel.Tokens.Jwt.JwtSecurityToken'.
System.IdentityModel.Tokens.Jwt.JwtSecurityTokenHandler.ValidateSignature(string token, TokenValidationParameters validationParameters)
Exception: An error was encountered while handling the remote login.
Microsoft.AspNetCore.Authentication.RemoteAuthenticationHandler.HandleRequestAsync()*
Thank you in advance.
Danny
Thank you #User 45323833 posting your suggestion as an answer to help other community members.
" Solution from Microsoft: This problem caused due to your app registration:
May you have defined a scope from Graph API: User.Read User.ReadBasic.All Mail.Read
If a scope will be set from Graph API, the token can just be validated from Graph!
You can see that in jwt.io. If the aud is like "00000003-0000-0000-c000-000000000000" the token is from Graph.
To solve the problem please follow the below steps :
To protect our own custom API, you have to register an application to represent it on Azure AD and obtain an access_token/id_token for it.
Section - Expose an API: Create a new scope: name = access_as_user
Section - API permissions: Add a new permission for your registered application and your scope access_as_user
Section - Manifest: Change entry "accessTokenAcceptedVersion" from null to 2
Check the new token from azure with jwt.io. If the aud is equal the registered application id the token can be successfully validated."
For more information please refer this GitHub issue IDX10511: Signature validation failed. Keys tried: & Microsoft Documentation: Azure AD authentication with ASP.Net core web application
I have been following after this guide step by step:
https://github.com/Azure-Samples/active-directory-angularjs-singlepageapp-dotnet-webapi
The only thing that I didn't do (not sure if its related) is the following line:
"Also in the ToGoAPI project, open the file Controllers/ToGoListController.cs. In the [EnableCors...] attribute, enter the location of the To Do SPA client. By default it is https://localhost:44326. Make sure to omit the trailing slash.
"
The reason I didn't do it is simply because I can't find any [EnableCors...] in the code. I did try to enable CORS in a different way though. following this:
https://learn.microsoft.com/en-us/aspnet/web-api/overview/security/enabling-cross-origin-requests-in-web-api#enable-cors
Anyway, I get the following error:
"Error :invalid_resource
adal.js:973 Error description:AADSTS500011: The resource principal named https://yorecisraportsco.onmicrosoft.com/ToGoAPI was not found in the tenant named yorecisraportsco.onmicrosoft.com. 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.
Trace ID: 64213edc-4b12-4caa-aa4e-b9ec82bd3000
Correlation ID: 607d25c1-d915-46eb-ba48-67adb70ddab8
Timestamp: 2019-03-04 12:41:33Z"
I am not sure why this is happning as I followed the guide - configured everything in Azure like it said and also configured it in the code.
Hi I have a daemon application which will access Azure AD graph API.
I am trying to have certificate based authentication,Hence first creatinga self signed certificate.
I have followed this article
https://azure.microsoft.com/en-in/resources/samples/active-directory-dotnet-daemon-certificate-credential/
I am using windows 10 machine.
When I try to modify the manifest file of registered application of Azure AD I get below error
Failed to update application graphapi2. Error details: KeyValue cannot be null or empty Request ID: fea0789a-b8fd-4001-83c4-f74d67fb9812, Timestamp: 12/13/2018 11:56:08
Has any one faced this issue?How will I be able to create self signed certificate to azure ad registered applications.
I got it working by following this link :-github.com/Azure-Samples/active-directory-dotnetcore-daemon-v2 . While exporting the key choose the option ->Do not export private key->Base 64 encoded option.Later I uploaded the certificated in the app registrations preview and it works!! :)
This seems to be happening in the Azure Portal when using the "App registrations (preview)" rather than the normal "App registrations". If you try "App registrations" and edit the manifest there and add your KeyCredentials it seems to work fine.
I'm developing an API using VS 2017, which I'm testing using Postman. I've been following this blog post Getting started with Windows Azure AD Authentication using Postman. I finally got it to give me an access token and a refresh token. About 3 quarters of the way through the post I came across this:
resource : https://management.core.windows.net
which has to be put into Postman (I'm using the Windows app version of Postman). I wasn't sure what that was for, so I left it off. I eventually got an access token and a refresh token, but when I when to get more info for all subscriptions, I got errors saying that I had specified a valid resource. So, I thought what I'd have to do was start over again, but re-authenticating and getting a code from Azure. I did so, and put that into Postman, as the blog post instructs. However, issuing this POST results in this error:
"error": "unauthorized_client",
"error_description": "AADSTS70002: Error validating credentials. AADSTS65005: Invalid resource. The client has requested access to a resource which is not listed in the requested permissions in the client's application registration. Client app ID: d37abf69-42ce-4571-b146-f3422e73f041. Resource value from request: https://management.core.windows.net. Resource app ID: 797f4846-ba00-4fd7-ba43-dac1f8f63013. List of valid resources from app registration: 00000002-0000-0000-c000-000000000000.\r\nTrace ID: 9f028899-6d03-409e-8db4-4e9905000300\r\nCorrelation ID: ec253a1b-9fdc-495f-9310-6b40a42e5d93\r\nTimestamp: 2018-11-19 22:20:02Z",
"error_codes": [
70002,
65005
]
I don't understand why nor what I could have done wrong. I've prespecified the resource as the tutorial instructed, so what have I done wrong?
Looking at the error message, it seems you could have missed adding relevant permissions for "Windows Azure Service Management API" to your app registration.
Steps:
Go to Azure Portal > Azure AD > App registrations > Your app (with app id: d37abf69-42ce-4571-b146-f3422e73f041)
Go to Settings > Required permissions > Add > Select "Windows Azure Service Management API"
Select the relevant permission under Delegated permissions section. Click on select and then "Done". You should get a notification in portal that successfully added permissions. You should see Windows Azure Service Management API listed under required permissions as well.
After these steps, continue as per the blog post you've mentioned with Postman steps to get the access token again.
I found myself in the same situation when i was trying to setup Postman. Its not as complicated as most blogs make seem. I created a tutorial to try to make the process easy.
http://hazelnest.com/blog/blog/2018/11/17/azure-postman-configuration/
https://youtu.be/2bfgeBKRxl4
Hope this helps.
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