We have an MVC application that validates windows users by instantiating a principalcontext, locally and for domain users. However, this immediately fails when a connection to the domain cannot be made. Is there a way to leverage the capability of windows to still validate domain credentials when disconnected from the domain?
We see that in SSMS you can also use windows authentication after the server has lost access to the domain.
To be clear, the machine is joined to the domain but does not have access to the domain controller, i.e. a corporate laptop that is taken home.
Thanks for the help in advance.
The answer is in how Kerberos (and I believe NTLM is similar) works in that they use session tickets. So once authentication is successful against a domain controller, you have a "ticket" that proves you authenticated. When you authenticate to anything else that requires Windows authentication, the ticket is sent.
To take advantage of this, you must use the built-in Windows authentication. You cannot take a username and password and try to authenticate them that way.
If everyone who uses your website can use Windows authentication - then you can enable it for your whole site.
If you have a mixed audience - some who have a domain account and some that don't - it's a little trickier, but still doable. I've done it. You can look at the OWIN-MixedAuth project. I haven't used that specifically.
That project seems to use a separate button for the Windows authentication. When I did it, I made it seamless (it tries Windows auth and fails back to a login page). I did that by doing an AJAX request in the background to a page that requires Windows authentication, and if it succeeds, just forward on. If it fails, show the login fields.
All that said, I don't know it will work if the server cannot reach the domain. It will probably work for users who have already authenticated to the site before it lost connection to the domain, or if the site is hosted on the same computer that it is being accessed from. But it might not work if a user it has never seen before tries to login while there is no access to the domain. You will have to test.
But the benefit of using Windows authentication anyway is that you can make the login seamless. As long as the site is in your Trusted Sites (in the Windows Internet Options) then IE and Chrome will automatically send the user's credentials.
We have an ASP.NET/MVC website that's using FormsAuthentication. As is usual, when the user tries to access a page, and doesn't have a valid FormsAuthentication cookie, IIS redirects him to the login view. When the user does a HttpPost to the login controller, our controller action makes a call to our WebApi webservice, which validates username, password, and customerid against a Sql Server database. If the authentication passes, the controller action sets a FormsAuthentication cookie, and redirects to the page the user had asked for.
Now sales is making noises about "Single Sign-On", though I'm not clear exactly what they mean by that. From what I've read, in the Microsoft World this usually means accessing MS's Active Directory Federation Services.
At this point I have almost no idea how this would work, but before I dig into this too deeply, would it be possible to put the authentication code within the WebApi webservice, where we could choose to validate against the Sql Server database, or against whichever ADFS server was appropriate for the specified customer?
Our problem is that we have I don't know how many thousands of users, working for some hundreds of customers. Many customers will not have ADFS running, and those who do will each have their own ADFS server.
Most of what I see with respect to Single Sign-On seems to involve doing browser redirection to the ADFS server, then redirection back, and looks to be avoiding login at all, if you're already logged in. I don't think we can do that, in our case. We can't know which ADFS server to redirect to, until we hit the database.
So, the question - is it possible to do ADFS authentication entirely from C# code in our WebAPI web service?
(One possible complication - the website itself has zero access to any database. The sole configuration setting in its web.config is the base URL of the webservice. Whatever authentication happens has to happen in the webservice, not in the website.)
First of all, "Single Sign-On" (SSO) is not limited to ADFS. It simply means that you type your credentials only once, and then all systems you access automatically "recognize" you; all subsequent authorizations request are transparent. For instance, if you have several web sites using Windows Authentication in your company Intranet (same AD domain), you have SSO: you authenticate once when you log in to your computer, and then your web browser authenticates automatically to these web sites using NTLM or Kerberos. No ADFS in this case.
What ADFS (and "Federation" more generally) allows, is SSO accross security boundaries. In Windows world, a security zone is typically created by an Active Directory forest; everything within this forest is accessible using SSO provided by Windows authentication. But as soon as you leave this zone (SaaS application, web site in another company network), you need another authentication protocol to perform SSO, and these protocols are implemented in ADFS.
Then about your particular problem:
What you could do is instead of using FormsAuth, you use AdfsAuth. When a unknown user accesses a page, he would be redirected to ADFS for authentication (using browser redirects as you correctly mention). To know which ADFS server should authenticate your user, you need a way to differentiate them indeed: a list of IP range per customer? a different URL per customer? If you don't have something like this, then the only way is to show them a list of choices such as: "I work for CompanyA", "I work for CompanyB", "I work for CompanyC", "I don't work for any of these companies and want to authenticate using FormsAuth."
In this case, what your WebApi web service has to do is: if I know which ADFS server to use, redirect the user there. Otherwise authenticate the user as usual using the database.
When you use AdfsAuth for a customer, your database is useless. You can delete all credentials related to this customer.
do ADFS authentication entirely from C# code in our WebAPI
Well it's possible to "re-implement" ADFS in your service, but you won't get SSO if you do that. When you use federation, your redirect the user to the ADFS server of his company. This ADFS server is in the same domain as his computer, so the user gets SSO here. Once again, your users can't get SSO if you authenticate them yourself, because your users are not in the same security zone as your site.
When authenticating to multiple identity providers, it is typical redirect to your own STS. So, in this case, you would have www.yourapp.com redirecting to sts.yourapp.com, which redirects to sts.somecustomer.com.
The specific tools to enable such a dataflow is the home realm parameter (whr), and the AD FS Powershell API (to allow IDP maintenance).
Your RP-STS acts as the trust-point for the app, and manages selection of the appropriate IDP. One RP-STS, many IP-STS's. Each of your Customer's IP-STS gets set up as a Claims Provider Trust in AD FS.
As always, Vittorio has already covered the subject better than I could.
I inherited an existing .net web application. It is an external website that is used by external users and internal users. To login/authenticate internal users, it uses LDAP authentication. External users goes to a different DB.
My IT department wants to change the way internal users login. They do not want to allow an external server to be able to access the AD using LDAP. Is there a more secure method to access the AD from an external server? Or is that not recommended at all?
Also, is the design of the login flawed? Should internal and external users be logging in the same way? What is considered best practice for logging in users?
You could use ADFS (Active Directory Federation Services) for this.
This will require you to install an ADFS server inside of your network (so it can contact the AD).
The ADFS Server contains a web based STS (Security Token Service) to allow web pages to login using an AD account.
Basicly in a nutshell it will work as following:
Your user navigates to the external Web Application
The Web Application will redirect the user to the ADFS STS server.
ADFS STS Server will verify your credentials (either by using integrated security or a web based login box)
If the ADFS STS Server is happy abou the credentials it will then redirect the user back to the external Web Application with a login token as extra information. This token contains information about the user (can be configured). It is signed by the ADFS server (to ensure the information is authentic) and can optionally be encrypted.
The external web application extracts the token and tests the signature. If it is all correct the Web Application will grand the permissions that the user should have.
For information to set this up in an ASP.NET application you could refer to the following url:
http://blogs.msdn.com/b/alextch/archive/2011/06/27/building-a-test-claims-aware-asp-net-application-and-integrating-it-with-adfs-2-0-security-token-service-sts.aspx
Scenario:
https asp/asp.net website running of IIS 7.5 (windows server 2008)
IIS currently configured to allow anonymous authentication and forms authentication ,asp.net impersonation are disabled while windows authentication is not installed (I understand that windows authentication needs to installed for this.)
a single custom login page for both internal and external users
Requirment:
Internal users seamlessly login while capturing their LOGON name (window authentication)
External users (not on domain) should be prompted a manual login
Questions:
What approach can be used to implement this?
Looking for the IIS 7.5 and web.config settings
Approaches Found:
make 2 pages within 1 website, winlogin and weblogin(front page). Allow windows auth=true and anonymous auth=false on winlogin.aspx and vice versa on weblogin.aspx
user with a ip hits weblogin, if ip is known redirect to winlogin to capture logon and redirect to weblogin if the ip is unknown
have winlogin.aspx as the main page and redirect 401 errors to weblogin.aspx
This is how to configure IIS for integrated authentication.
http://netpl.blogspot.com/2012/06/iis-75-integrated-security-with-no.html
This will make your site available for intranet users WITHOUT the prompt for credentials.
Note that this also works for web users. A built-in web browser window is displayed as a result of HTTP 401. A user provides his/her credentials and is in.
If you rather want to show your custom web form as a result of 401 (unauthorized), you'd have to trick the browser a little:
http://www.codeproject.com/Articles/11202/Redirecting-to-custom-401-page-when-quot-Access-de
This way you can redirect an unauthorized response to a web form of your choice (for example, to show an asp.net login form).
Although the integrated authentication can be easily configured, prepare for a lot of experiments when setting up your mixed (integrated/forms) authentication. Things change with every version of IIS; also IIS7 behaves differently if a pool is in classic vs integrated mode.
Ok, I have looked around and could not find a solution to this problem. I have an ASP.NET web application that is using Windows Authentication.
I have a public web services that I use for an iPad App I have developed. For security reasons all of my Web Services requires a header with login information.
Right now, I have a separate database that I authenticate users from. Its a built in authentication for when my application is installed using Forms Authentication.
What I would like to do is when the user on the iPad logs into the system, it passes the Login and Password to the Web Service in the hearder... which it does now.
But, how can I Authenticate that User and Password against the Active Directory to make sure the user has access?
Thannks,
Cory
But, how can I Authenticate that User and Password against the Active
Directory to make sure the user has access?
That's straightforward in c#: Validate a username and password against Active Directory?
More AD tasks in c# (including authentication)
Right now, I have a separate database that I authenticate users from.
Its a built in authentication for when my application is installed
using Forms Authentication.
Based on this statement, it sounds like you have a database of credentials which duplicates credentials in AD? If that's the case, not sure that's a good idea.
And/or it also sounds like credentials which match those in AD are being passed around (possibly in plain text?) This might be a business requirement, but I would recommend that all communication is done over SSL and that the AD accounts belong to a domain setup specifically for this purpose that is not trusted (or only partially trusted) by the rest of the network.