I have a rails application running on nginx + unicorn and I want that users can login in with their Active Directory crendentials. I've already implemented connecting to AD server and authenticating users, but they need to enter passwords.
Is it possible to somehow get this information on this setup? I've found some topics about this problems, but they don't quite explain how to solve this problem and most of the answers are for IIS sever.
I know that it propably can work only in Internet Explorer.
Signing in automatically is handled by the web server, not your application. Since you are using nginx, there are a couple of third party modules you can use, such as spnego-http-auth-nginx-module or nginx-mod-auth-kerb. IIS has support built-in, of course.
Once you've set up the web server, your application can retrieve the user's username from the REMOTE_USER environment variable. Internet Explorer will automatically log in; Firefox and Chrome will do so if they have been configured for the domain by the system administrator, but this is off by default.
Related
I'm trying to migrate from local NLTM authentication to Azure AD login for an on premise app. I have set up the connected service, but everytime the SignIn method is called:
The request is already authenticated and it's using my local PC name, so the O365 log in is never triggered. Debugging doesn't help as the User info and Request don't seem to exist outside of the AccountController. Does anyone know what is going on and how I can get it to load up the login instead?
If anyone else finds this, check and triple check your web config and project files for any lingering windows authentication variables. Failing that try creating a new project with authentication and then copy the content of the old project across bit by bit. It turned out for me to be something dodgy in the project, but even using a comparison tool afterwards showed no discernible differences.
Only thing I can think of is that the Authentication with Azure Active Directory Connected Services made changes that broke something, but using the auth option during project creation did it properly.
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 read through a ton of articles from MS on authentication through Azure AD. There are so many options and nothing I've read seems to solve my issue.
Here's the situation:
I have 3 different web applications (all ASP.NET MVC 5). They are all hosted internally in our network on the same server/IIS and use windows integrated authentication against our internal AD.
Let's call these applications App_A, App_B, and App_C.
App_A is located at appA.mydomain.com within our DNS
App_B is located at appB.mydomain.com within our DNS
App_C is located at appC.mydomain.com within our DNS
The use case is as such:
A user navigates to App_A does some work and is eventually redirected to App_B
The user does some work in App_B and is eventually redirected to App_C
The user does some work in App_C
When the user is on a domain-joined PC, they are never prompted to log in. Windows takes care of that for them through the integrated authentication.
Now, this is what happens when a user wants to do the same work on a non-domain device (such as an iPad) whether on VPN or connected to the internal WiFi:
When the user loads App_A they are prompted to log in and do so with their windows credentials
When they get to App_B, they are prompted again (different sub-domain)
And when they get to App_C, they are prompted again (different sub-domain)
Having to log in multiple times with the same Windows credentials is not the experience we want for our mobile users.
What we would like to have happen is have the mobile user log in one time when they hit App_A and not have to log in again when they hit App_B or App_C. As well, we would still like the users on domain-joined PCs not to have to log in at all as they are already authenticated to their machines.
Just for your information, we are also syncing our AD to Azure AD, so we have that to authenticate against if the solution requires it. I am looking for what I need to do to setup my MVC apps to allow this sort of authentication.
Any help you can provide with this would be GREATLY appreciated.
The scenario you describe should work by getting all apps to use Azure AD as shown in https://github.com/AzureADSamples/WebApp-OpenIDConnect-DotNet and by ensuring that they all skip the home realm discovery and go straight to your domain, as shown in http://www.cloudidentity.com/blog/2014/11/17/skipping-the-home-realm-discovery-page-in-azure-ad/
Scenario
User A can access all pages in MVC4 website except one. But user B can access all pages (no restriction).
What I had done so far?
Deployed website on IIS 7.5.
Enabled window authentication and disabled Anonymous authentication for hosted website on IIS.
Testing website.
Testing Results -
(1) When User B is logged on same system (development system) where the website is deployed, he can access the website without prompt dialog.
(2) But when same website is published on server (production system) with same settings, website still asks for credentials with pop up.
** Both of the development system and production system are in same domain (let's name it domain.com).
Question
Why is the same user in same domain is been asked for credentials by website?
As per my research for Window Authentication, I want to conclude following lines (also as reference for me) -
(1) Window Authentication (abbrev. WA) will always show prompt for verifying users if you had configured WA properly.
See anonymous authentication disabled and windows authentication enabled in below snapshot.
(2) Even if one set NTLM as top provider than Kerberos (in IIS), the IIS will still ask for Window credentials. Snapshot show how to do that.
(3) If you want to avoid showing prompt on browser for WA, follow steps-
(a) Open IE browser --> Internet Options --> Security tab.
(b) Add site to Local Intranet zone so that browser will send logged-in username and password to IIS.
Note - The above points universally apply to MVC and ASP.NET.
Answer to my question Why is the same user in same domain is been asked for credentials by website?
Because I had set anonymous authentication enabled along with Window authentication on development system. (Silly mistake).
I've created a basic MVC 3 website that's using Windows Azure's Access Control Service (ACS) to perform user authentication against an Active Directory Federated Service (ADFS) endpoint. I followed the "Add STS Reference" wizard and the site runs fine and authenticates users just perfectly in IE. However, when I use Chrome or Firefox it continually prompts for my credentials over and over again.
I found this post on technet that mentions the issue as it pertains to Firefox but there's no fix for Chrome mentioned, nor do I feel like the steps required to fix Firefox are practical in the real world (i.e. I can't expect end users to do this)
http://social.technet.microsoft.com/wiki/contents/articles/ad-fs-2-0-continuously-prompted-for-credentials-when-using-firefox-3-6-3.aspx
Has anybody else hit this snag? What am I doing wrong?
With some help from a Microsoft Rep (Adam Conkle) over on TechNet (scroll down to the comments), I finally have an answer to this problem.
Turns out, the ADFS website that performs authentication of users (this website gets setup in IIS during the installation of ADFS v2.0) is by default configured for Integrated Windows Authentication (IWA). IWA is configured in IIS to use Extended Protection for Authentication (EPA) and therein lies the problem. Apparently, most other browsers don't support EPA yet which is why Firefox & Chrome continually prompt for credentials in a loop.
Two options...
Keep using IWA but turn off EPA in IIS for the website (described here)
Turn off IWA in favor of Forms-based Authentication (described here)
I had the same issue, sort of. I had 1 person who was being prompted in Chrome and another that was not. On a hunch, I looked at the trusted sites. The person who was being challenged had the intranet site in their list of trusted sites. I removed it and tried again. This time they were not challenged.
Thought I would put that out there in case anyone else has this issue.