I am attempting to wire up Azure AD to a test MVC site.
I have followed the steps in the blog posts by Rick Rainey here and by Rick Anderson here (which appear to essentially be the same).
When I run the project, and try to sign on, I receive an error page with the messages "Sorry, but we're having trouble signing you in.", "We received a bad request.", and "AADSTS50000: There was an error issuing a token.". I have searched the web for the last error message and found a couple of things but nothing that provided any detail.
Any suggestions as to what might be missing? Everything (such as the application, and database) appear to have been created and configured in Azure as expected / described.
I was able to get it working (with the help of Rick Anderson). The issue was that I was not (completely) following directions and was trying to use the wrong account. When I created a new directory, it pulled in the Azure AD account that I was logged in with. This wasn't a Microsoft account (as mentioned in the article) but it still didn't work. When I created a user in the directory, this user was able to logon.
Related
I am trying build up a Staging Environment for an ASP.NET MVC Web App, but am stumbling from problem to problem, the last one having been this one: HTTP 500.79 Error / System.UriFormatException when deploying ASP.NET App to Azure Web App
Currently I am getting a HTTP 403 - Forbidden, "You do not have permission to view this directory or page." error when trying to access the page.
Authentication-wise the App uses Azure Active Directory as Authentication Provider, which is working fine in local testing (using a Test-AAD) and in production. The local and productive apps are not using Azure Web Apps. I noticed on the Azure App Service page that there is a possibility to specify authentication right within Azure, but I don't really want / need to use that, as everything is specified within the app resp. configured in the web.config (ClientID, ClientSecret and Tenant). Anyway, when I tried filling in the Authentication on Azure directly it did not work either, so I removed it again.
What happens now is that the redirect to the Login page on login.microsoftonline.com works, and according to the AAD Admin the login attempt is being successful, or at least shows no pecularities. However, when being redirected back to my page, I get a generic 403, without any additional information that could help pin the problem down.
I did check all sorts of logs for further details, and the only pecularity I found is that for some very odd reason, all requests are made to a completely gibberish URL:
Requested URL / specified Reply URL: https:\\skillmanagementtest.azurewebsites.net
Actually requested URL according to logs: https:\\Skillmanagementtest:80
I have absolutely no clue where this URL originates from, however, "Skillmanagementtest" with that capitalization seems to be the name I specified for the Azure Web App:
Screenshot resource group items
The web.config is being transformed properly during the CI/CD pipeline and I double-checked the auth settings there (tenant, clientID, clientSecret), and I am really out of ideas what may be causing this problem.
One hint I found on other problems was to check the IIS logs, but when I attempted accessing the directory these logs were said to be placed in I was rejected access, even though I have owner permissions on the App Service...
UPDATE
After a long and weary process of trying stuff out and discussing we finally got the App up and running. Some observations we made which may be interesting for others with this or similar problems:
The role-based authorization did not work because we forgot to specify the App Roles in the App registration's manifest file, and then link the security groups to the application roles. Check here for more info: https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps
We had one API which is only visible within our company's domain. As an Azure Web App runs outside that domain, trying to access that API resulted in an internal server error. We still have to find a solution for this.
We had a situation where requests to the reply URL after authorization would be redirected from HTTPS to HTTP. We have solved this, but as five people were trying out stuff consecutively we don't know currently what the fix actually was. We may create another Azure Web App which may then reveal this part of the solution.
Check to ensure that what you have in your web.config and app settings matches what you have in the reply URLs for your app registration in the portal. There may be some reference somewhere where the reply URL does not match.
Are you using the openid sample? https://github.com/Azure-Samples/active-directory-dotnet-webapp-openidconnect
Also ensure that you are logging in with a user who has the right permissions under the tenant and to the app itself. My colleague and I made a short video that includes the right configurations that may be helpful for this use case. https://www.youtube.com/watch?v=MohaxN6fsDs
After a long and weary process of trying stuff out and discussing we finally got the App up and running. Some observations we made which may be interesting for others with this or similar problems:
The role-based authorization did not work because we forgot to specify the App Roles in the App registration's manifest file, and then link the security groups to the application roles. Check here for more info: https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps
We had one API which is only visible within our company's domain. As an Azure Web App runs outside that domain, trying to access that API resulted in an internal server error. We still have to find a solution for this.
We had a situation where requests to the reply URL after authorization would be redirected from HTTPS to HTTP. We have solved this, but as five people were trying out stuff consecutively we don't know currently what the fix actually was. We may create another Azure Web App which may then reveal this part of the solution.
I have spent a lot of time lately trying to link MS VSTS account with Dialogflow. Unfortunately all my attempts failed and I am unable to find out the reason for this.
What I have done so far is:
Went to registered new VSO application (https://app.vsaex.visualstudio.com/app/register), filling in the correct callback URI (https://oauth-redirect.googleusercontent.com/r/MY_PROJECT_ID) also defining the proper scopes.
Got back to Google's action console overview page (https://console.actions.google.com/project/MY_PROJECT_ID/overview/accounts) to fill in the details for the newly created application (authorize URL, token URL etc.) selecting Authentication Code grant type.
Went to Dialogflow to set the "sign in required" for the welcome intent.
Update the action and got the "It looks like your account is not linked yet" message in simulator, but after using the DEBUG URL to complete the process, I received "account linking failed" message for no obvious reason.
I have also tried the linking procedure with 2 other OAUTH providers and it was working flawlessly, but the MS implementation apparently is not standard.
I have been trying to implement the OAuth v2 for Microsoft Accounts for my website. Its currently in development stage and so am testing on localhost. The Website is an ASP.NET Core MVC 5 Application.
I have followed the tutorial here to implement OAuth for Twitter, Google and Facebook accounts. I found this to be quite simple with only a few small issues that I was able to solve with simple google searches.
However I have spent several days trying to understand what is happening when trying to use Microsoft Account authentication on my site.
I have watched the video here on registering an application in the Microsoft App Registration Portal. At around minute 6 in the video a short demo shows how to set up the App. You can see my App details in the following screen shot:
In the video at about 7.5 mins in, there is a small section explaining how to test the App by building a URL string.
On submitting the query string to the browser the page is redirected as expected to my App page as you can see here:
In this instance I was all ready signed into my Microsoft Outlook account. If I wasn't signed in I would be prompted to login to a Microsoft account. Logging in, in this case choosing my already signed in Outlook account causes the page to be redirected back to my site as seen in the following screen shot but because the site didn't send the request its not expecting a token sent back for login so nothing really happens. This is expected behaviour, at this point as I was only testing that the Apps end point was working as expected.
[
The next stage is to test the functionality from my website. This is where I always have issues. To activate the OAuth functionality for Microsoft Account login requires simply un-commenting a couple of lines of code within the Startup.Auth.cs file in my websites App_Start folder and passing in the Apps ClientKey and ClientSecret values as can bee seen in the following code snippet:
app.UseMicrosoftAccountAuthentication(
clientId: System.Configuration.ConfigurationManager.AppSettings["MicrosoftOAuthClientID"],
clientSecret: System.Configuration.ConfigurationManager.AppSettings["MicrosoftOAuthClientSecret"]);
This code basically adds a little button to the login page that allows you to choose Microsoft login as can be seen here:
[
When I click the Microsoft button I get the following error page:
And the query string returned contains the following:
https://login.live.com/err.srf?lc=2057#error=unauthorized_client&error_description=The+client+does+not+exist.+If+you+are+the+application+developer%2c+configure+a+new+application+through+the+application+management+site+at+https://apps.dev.microsoft.com/.&state=JMxMRuKaOiYWCQw_Uqkhv3gLQn3ULlkG2miM4ymcHhTK5niXVQl5n4L0a6VoWeEKmFM7T1ciU2oQAh26_Y0i2DMjdt6BOAtpjNeMaSpBq4wbCjva9lOuctOUIWwoFdTEGvxJ4M904lUsoudd9e9cYi6eiH3JF81HB5ouQSus2ddE1sVUQLw-YB1GjUL79y2muFaBFIOIOk75oCV2IxX4cFO2rJU04K9Se6gxu698WpzR8taUB2c6tK9u0dBisckhavf0IvKB9dWQq-IVwQgvaA
Anybody know why or what is happening????
Now I have read in several of my many searches while trying to understand whats happening when I try to test the App from my site rather than a URL directly in the browser that I should have
/signin-microsoft
appended to my Redirect URL in the App Portals configuration. I have Tested with my Redirect URL set like that and this does not work. I get a HTTP ERROR 500 sent back because the page signin-microsoft does not exist. So this is not my problem.
Please help if anyone has had the same issues and solved it.
EDIT: I should have mentioned that I was initially trying this using Local IISExpress but after reading some posts saying it can be done only on IIS so I published my site locally to IIS.
I am using azure AD authentication to authenticate a user in my MVC
application.And I published my application on azure and it is
working fine.
But, when I run my application locally then it Microsoft's login
page comes up and when I enter credentials and click on SignIn
button then it is giving "Sorry, but we’re having trouble signing
you in.We received a bad request."
But the same application is on azure and if I access it from there then it allow me to login.
To create this apllication I follwed link to add azure AD authentication
If you notice the error message, it clearly indicates that you have not configured https://localhost:44320 as one of the reply addresses.
Please go back to application configuration screen in your Azure AD and add https://localhost:44320 as additional reply address. That should take care of this problem.
Add the below to your Web.config. It must be the same port which you have added at the time of Application registration.
<add key="RedirectUri" value="https://localhost:44320/" />
I hit this, it has cost me a lot of time.
I would check firstly that you have the ability in Azure to access third party applications.
In Azure > Users & Groups > User Settings:
You see the first item (Users can allow apps to access their data) - without this checked I believe it wont work.
As you are running your application locally it is not published to Azure, this means that although it may be within the realms of your organisations network, Azure still views it as a third party application.
Be wary setting this to 'Yes'. I understand that there are ways to then create applications that allow you to behave as an Azure super user....
In case anyone else comes across this, here is what happened to me. I had been switching back and forth between environments within Visual Studio (Project >> Properties >> Debug >> Environment Variables). Well, the last time I switched it, I wrote "Develop" instead of "Development" to switch back. This caused .NET Core to grab the wrong appsettings which connected to the wrong AD which did not have my localhost setup on it. It took me an hour to catch what I had done wrong.
This may not be exactly what has happened to you, but do check to make sure you are picking up the Azure AD settings you are expecting if they are in your appsettings. It could be a good point to start at.
I am trying to run the sample Google Apps Script Service Account OAuth example taken from here:
https://github.com/googlesamples/apps-script-oauth2/blob/master/samples/GoogleServiceAccount.gs and keep getting a server timed-out error. I copied the exact code and just substituted in the private key, client email, and a user email. The example code looks to be current as there was an update to it on July 30th.
I have authorized https://www.googleapis.com/drive/v2/files through the admin console as well as https://accounts.google.com/o/oauth2/token and have listed these as scopes in the admin settings (and domain-wide delegation is enabled). I am using an admin account to run the script.
I keep getting the ubiquitious "Server Timed Out" error and nothing shows up in the Execution Logs.
What might be the problem? Any help would be appreciated. Thanks in advance.
Thanks, Gerardo, for pointing me in the right direction. It turned out that our organization manages permissions for the Google Developer's Console by Organizations (in the Google Admin console). Somehow a few accounts, including mine, were kicked out of the Organization that had permissions to access the Developer's Console. After adding myself back in, the sample worked without problems.