I'm looking at building an site that authenticates users against AD of my company.
I've already created something that works internally, but I'd also like the users to be able to authenticate externally - from outside the network over the internet. using any pc or even mobiles. Obviously only people within the company should be able to access it.
I just need a few guidelines for what I'll need to bare in mind for such a project..
Use forms authentication
Use ADMembershipProvider
Host site on network with AD
How do I make it visible externally? what security implications are there? what needs to be done on the server?
There is no special requirements for the AD usage, normal security requirements apply - enforce HTTPS on the login page, for start.
I guess your server is in the DMZ, so just make sure it can see AD from there.
Related
I have a .NET web application, authentication is typically done through windows authentication. Normally it's placed on a local lan and is a member of a domain so users authenticate directly to AD. However I was told that I had to figure out to authenticate to the domain when the web server is on a perimeter network. I was told that adfs is the way to go. However I'm unsure of how to implement this. I read about the web application proxys but those would have the application on the lan. A relying trust sounds like what I want but it's not clear on technet how this works and how to integrate with anything other than a sharepoint site. I was told not to use something like a rodc because they don't want to extend the domain any further, which makes sense. Any suggestions on how to authenticate to active directory through adfs with the application being on the perimeter
There is a free and well known e-book on federated authentication from the Patterns & Practices group, Claims based identity and access control
https://msdn.microsoft.com/en-us/library/ff423674.aspx
The book covers all you need to set up federated applications, write federated clients and servers and much more. When you are done with reading, come back with more specific questions.
What is the best way to authorize access to sections of the external facing website based on internal(inside company network) or external(web) user.
Is IP Address sniffing the only way(dont really like it. :S). Can we use Active Directory to check for internal users at the same time not affecting web users?.
The website does not need authentication(we dont have a login screen).
(ASP.Net MVC3, .Net 4.0)
I'd suggest you think of it as two separate websites - an internal intranet and an external site. This gives you more flexibility in deployment, and reduces the risk that a problem on one site will affect the other. If you deploy your internal site to a server without an external IP then it will by default be restricted to only those users within your network.
Without using a login, then IP address detection is the easiest, but not foolproof way of achieving what you ask.
You could also deny anonymous access but allow integrated auth to the internal sections. That would mean only folks authenticated to your domain could access the site. anyone else would be denied & you wouldn't need to add any sort of login to the app.
Simon
Its not an original question. There is already a batch of articles describing this problem and solution for it. They all are dated back to times of .Net Framework 1.1 and IIS 6.0 and are not really helping with all the membership and role providers stuff we have nowadays. But lets get closer to the problem.
The problem is short.
You have an intranet site using Windows authentication and it works just fine. All you want is to give access to this site to users from their homes and to users who don`t have Windows based workstation.
Duplicate the whole site would be cumbersome because all the application except Login part would work well just if appropriate information would be saved in cookie on Login step.
You are welcome with any suggestions.
You don't say if internal users are authenticated or not, so, as it's an intranet I'm going to assume they are, via integrated authentication.
The simplest way would be to leave it as is, and turn on digest authentication if you are in a domain environment in addition to integrated authentication - this would prompt users not on the intranet with a username/password popup and they can login with their domain credentials.
If you don't have a domain - then how is it an intranet site? How are users authenticated? If you're in a workgroup scenario, where users have login details on their own box, and login details on the intranet server (in which case moving to AD would be better all round - no need to keep the passwords in sync, or deactivate user accounts in multiple places when people leave) then mixing Integrated authentication with Basic Authentication would do the same thing - however if you're going to use Basic Authentication then you will need to add an SSL certificate to the site to stop usernames and passswords being sniffed - Basic Authentication sends them in plain text.
Well, what you could consider is if you can use Active Directory, there is a provider to use the AD store for security, that would work for both.
HTH.
We have an application that is for both internal users and external customers. We would like to authenticate against AD for the internal users and against sql membership for the external customers. Has anyone taken a similar approach? Also what is the best way to authenicate against AD when in a DMZ? I would rather have a proxy of some sort that is in the dmz and handles authentication against the AD DCs on our internal network. Any suggestions?
TIA,
Kevin
We have a similar situation. Our Internal users go against AD the external guys against an ADAM store. Different than your database approach, but similar in that they have two user stores. Our authentication against AD occurs in the secure zone, the web servers in the DMZ make a webservice call into the secure zone for authentication. Don't know what you are rally looking for, but your approach sounds ok.
EDIT to answer comments:
The ADAM store is not synced with the database.
Basically there were two providers that the webservice was configured to use, one for each store. I fact, there were three for a period of time when users were migrated from the legacy system. To determine which store a user was in, the application simply asked the most common provider first (ADAM in our case) and if the user did not exist, it would move to the next provider.
The endpoint was the webservice, inside the firewall, running on a the middle tier server. That server did run IIS, so technically it was a webserver, but actually our middle tier server as it did not serve up any pages or host anything other than a few webservices.
So it sounds like you have 2 types of external users. Ones that are really internal users (in AD) and ones that are truely external (in DB). This is not very elegant, but you could ave 2 login screens, one for each. Don't publish the internal users external login screen to anyone but them, and publish the real external login screen to teh world. A little hacky but it would work. Otherwise, you login would process will need to identify the type of user.
I am in the process of writing an application that will need multiple forms of authentication.
The application will need to support authentication to Active Directory, but be able to fail back to a SQL Membership Provider if the user is not in Active Directory. We can handle the failing to the SQL Provider in code based on the username provided because the username will be a different format than the Active Directory username.
Is this even possible? What I mean is, can I use membership and use both ActiveDirectoryMembershipProvider and SqlMembershipProvider together or will I have to roll my own?
Another additional added complexity is that I would like to automatically authenticate my internal users based of Windows Authentication back to AD, but use Forms Authentication for users not on our internal network, or users that are using the SQL Provider.
These will most likely be separate servers, one internal, and the other external so I have a lot of planning to do to figure out the data replication, and how I will authenticate the AD users if they hit the outside server etc.
I am wondering what thoughts are out there as I start down this road. Is what I am wanting to do even possible without me rolling my own, or is there a way to mesh these together?
Thanks for the reply.
The reason I asked originally was because I was able to get this specific senerio working about 7 years ago using IIS to authenticate and then passing back the credentials to a Lotus Domino Server Web App. If the user was not authenticated via the Windows Authentication/ISS then Domino would handle the authentication. This was what I was looking to do here, but really couldn't think of a way to make it work in IIS.
As for the rest of your reply, I think you are on to the way that I will need to take. I have thought this through and tossed it around in my head a lot. The application will be somewhat different on the two servers anyway since there is going to be limited access to the data on the external server anyway. The fact that so much is going to be different already I may just treat these as two applications, thus negating the need to use two types of authentication in the same application anyway.
I am playing around with the idea already of writing my own authentication/login window for the external server, and if the user trys to log in with their AD credentials on the external server I will be able to detect that and redirect them to the internal server. If they are not on the local network or VPN'd in they will simply not get access. This part still has some thought process to go though so I am not sure.
As an additional thought - is there a way to pull just enough of AD into a SQL database to allow me to authenticate users to the SQL database from the external server using their AD credentials, without creating any security issues? I hope I am clearly typing what I am thinking....
Thanks again!
Tim
This is the way I've handled a similar situation based on this info:
Configured the application to use Forms authentication.
Set the LoginUrl to a page called WinLogin.aspx.
In WinLogin.aspx, use Request.ServerVariables["LOGON_USER"] to get the username then call FormsAuthentication.RedirectFromLoginPage( authorizedUserName, false ) to log them in. I guess you can manually check Active Directory as this point as well.
Create an html page that redirects to a page called Login.aspx
Login.aspx is your standard username/password login.
In IIS, Enable Integrated Authentication and Anonymous on the entire site, but deny anonymous access to WinLogin.aspx.
In IIS, set your 401 errors to the page created in step 3.
What basically happens is that when an unauthenicated user hits the site, they're redirected to WinLogin.aspx. Since anonymous is turned off, integrated security makes a check. If that passes, your custom code in WinLogin can run. If the integrated security check fails, a 401 error occurs. Your custom 401 page redirects to Login.aspx where the user can log in using their username and password with the SQL provider.
As far as I know, Web Applications are configured to use either Windows Authentication or Forms Authentication, but not both. Therefore, I do not believe it is possible to automatically authenticate internal users while requiring others to enter a username / password.
You could authenticate to Active Directory or a SQL user store via Forms authentication by using a custom provider. However, the AD users would still need to enter their username and password. Although I've never combined these two methods, I have used Forms authentication to authenticate against both sources at one time or another.
With that said, I think you may want to consider reducing the "flexibility" of your system. If you have an external facing server and an internal facing server, you could simply change the provider configuration on each copy of the application to go against a different source. Then, you could configure the internal one to use Windows (automatic) authentication and the external one to use Forms authentication.
IMHO, I believe that internal users should not be using the external server to access the application. If they are, they should have a user account stored in SQL, completely separated from their AD account. Basically, when someone accesses the application externally, they are acting as an external user, irregardless of their physical location.
Well, it is possible to use ActiveDirectoryMembershipProvider and SqlMembershipProvider, but this requires you design your log on page with your own code instead of the Login controls.
About the mix authentication (Windows and Forms), as far as I know only IIS 7 makes it easy and clean. See this post for details,
http://mvolo.com/blogs/serverside/archive/2008/02/11/IIS-7.0-Two_2D00_Level-Authentication-with-Forms-Authentication-and-Windows-Authentication.aspx