we have asp.net web application and we need to support "automatic login" using domain credential (windows principal) if users visit the website via intranet or we will prompt user to enter domain credential if visited through external network via HTTPS.
Problem is that this web server (windows server 2008) is a workgroup machine and it's in DMZ. I've been told to research on AD LDS + AD FS to make this happen within limited time, whether or not it is possible to support both domain credential SSO (both internal & external) and automatic sign-in for intranet domain users.
As I read related documentations and discussions in the forums, I understand that SSO is possible with this setup, however I cannot be certain and unable to find related materials mentioning about "automatic signing" intranet domain users with this environment.
Can anyone please advice if it is possible or if there are alternative approaches.
The main thing is that we want to avoid joining that existing web server to the domain.
Many thanks
ADFS will get you what you want. You'll need to modify the app to support claims (look up WIF - Windows Identity Framework). ADFS would be installed in your domain environment and then you'd configure the ASP.Net app as a relying party application in ADFS.
I don't think AD LDS will be of any use to you here.
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.
We have asp.net web application running on Domain A with working Windows Authentication.
Our customer now wants to authenticate users from Domain B to this website, but we are not allowed to have trust between Domain A and Domain B.
Windows Authentication is not required for the users from Domain B, but Windows Authentication for Domain A should still work.
Does anyone know if this is possible to do?
We are using .net framework 4.0.
what about creating restricted accounts in the domain A for these users?
what about creating local accounts on the server in domain A for these users?
or, you can use Active Directory Federation Services
I have a requirement to integrate an ASP.NET web application with active directory - basically they want to be able authenticate and authorize with AD.
I realise this is relatively simple, but what I want to know is how I can simulate the AD for developing and testing against. I don't have AD available to me (right now) and don't cherish the thought of setting it up even if I had hardware available to run it on.
What other options are available to me? I've seen ADAM mentioned in a couple of places but this doesn't seem to provide the federation services I need (and seems a little out dated). Would it be possible to use Azure for this? I want to keep costs (time-wise as well as money) to a minimum.
I have managed to set up an active directory environment suitable for development using a Microsoft Azure VM.
A brief summary of the steps I went through to get this working are below. Although it sounds scary setting up AD and ADFS, the windows server 2012 interface makes it incredibly easier, barring a few gotcha's I mention below - it takes a while for them to install as well.
Create a new azure windows server 2012 VM and add endpoints for http and https.
Install the AD role on the VM
Install the ADFS role on the VM
Create an ASP.NET MVC 4 app (on your dev machine) and verify it is working correctly.
Run the app through IIS (not IIS express - this just makes SSL etc easier).
Ensure the site has a https binding set up
Install the Identity and Access tool for VS2012
Right click your project to select the identity and access tool.
The path to the STS meta document will be https://<your VM url>/FederationMetadata/2007-06/FederationMetadata.xml (you may need to download this file manually if your certificates are self signed).
Back on your VM, in ADFS create a relying party trust for your application.
Run your MVC app again and you should be redirected to your VM for authentication and then back to your app again (but this time using https).
If you are using the default MVC template, in the top right corner assuming you have set up the claims correctly, you should see Hi, <user>#<domain>
The main articles that I followed to achieve this are as follows:
http://blogs.rondewit.com/post/MVC-2b-ADFS-20-Federated-Authentication.aspx
http://garymcallisteronline.blogspot.co.uk/2013/01/aspnet-mvc-4-adfs-20-and-3rd-party-sts.html
Below is a list of gotcha's that I hit (in no particular order).
When setting up the relying party trust enter the data manually and ensure you set the Relying part WS-Federation Passive protocol URL and the relying party trust identifiers correctly. The first is simply the https url that ADFS will redirect back to after authentication has completed - https://localhost for example. The second is an identifier used to identify the application that is trying to authenticate. One of the identifiers entered must match the realm attribute of the wsFederation node in your MVC 4 apps web.config.
When logging in the username should be of the form <domain>\<username>
I couldn't get Windows Authentication to work with any browser other than IE. For this set up to work with Chrome I had to change the order of the local authentication types in the web.config of the adfs/ls application so that forms authentication appeared first. To get to this, open up IIS manager on your VM, expand default web site/adfs/ls, right click ls and select explore.
At the time of writing I haven't been able to login with an AD user I created myself - I've probably just not set it up correctly. When setting this up initially, I'd suggest trying to connect with the admin user you created through the azure portal when you created the VM.
Once I finally managed to authenticate correctly AntiForgeryToken html helper started throwing an exception, talking about missing claims. Ensure that you have added a claim rule to your relying party trust, that sets either the name or name id claim. Then in Application_Start do the following: AntiForgeryConfig.UniqueClaimTypeIdentifier = ClaimTypes.Name; as explained here.
It is also worth noting that the Identity and Access tool allows you to setup authentication with Azure ACS and more noteworthy, a development STS. For my requirements, I need to be able to integrate with ADFS, but if you're just experimenting with claims based authentication, one of these may be a better option than the process that I have gone through above.
Consider ADFS and ws-federation.
Ws-federation is an enterprise sso protocol that gives you cross domain authentication/authorization in a sso manner. Adfs is a free implementation of the protocol that sits on top of the active directory. It is relatively easy to set up.
But having a client application that expects a ws-federation identity provider, you can substitute the provider with any compliant provider, your own or the identityserver which is another free implementation but can use a membership provider. The completely custom implementation on the other hand would give you a chance to set up and serve an
arbitrary identities.
The is a small learning curve for this approach but benetifs are:
cross domain sso
support for multiple browsers for free (kerberos/ntlm based ad authentication could be unsupported on some browsers)
works in an intranet and the internet
support for advanced scenarios like for example you can set up your cloud Office365 to authenticate against your local adfs
adfs 2.0 is free component dowloadable from msdn
We have an ASP.NET web application that we offer as a Service (it's hosted and it's accessible on the Web). We use Forms Authentication and our users have to enter a username/password to connect to our application. Some of our customers ask that we support single sign-on by authenticating users with their own Active Directory.
Our application has a different URL for each customer
www.ourapp.com/client1/
www.ourapp.com/client2/
www.ourapp.com/client3/
and each URL has its own web.config file (where asp.net settings can be specified and can vary for each customer).
What do I have to change in my ASP.NET application to support that?
What do I have to change on my Windows server configuration?
What will the customer have to do on his side to enable that?
Regards,
Check How To: Use Forms Authentication with Active Directory in ASP.NET 2.0 In short, you configure an ActiveDirectoryMembershipProvider to verify each username/password with the customer's AD. The customer must create an AD account for you that is allowed to perform the verification - which may be a problem with some customers. What's more, your code will handle the actual username/password used by users in their internal network, which can be an even bigger problem with customers.
A more secure solution is to use federation (using ADFS) or Claims Authentication using Windows Identity Foundation. In this case you "only" have to set trust relations between your domain and theirs.
We have an issue for our intranet site that is running in our local network.
In a nutshell, we have integrated Active Directory authentication with our application and what to use IIS integrated authentication to allow users to sign on without entering any credentials.
Assume the AD domain is "domain.name", and the server our application is hosted on is "server-name". We are running in Windows 2008 and the Integrated Authentication role is set up in IIS.
We have managed to make this work for http:||server-name/, however when we enter http:||server-name.domain.name/, users are prompted for their credentials in the standard way and if they cancel, a "401 Unauthorised" message is displayed.
The issue is, that it seems to authenticate when the machine name is accessed, but browsers do not pass over credentials when the fully qualified address is accessed.
Has anyone seen this before? Is there any advice they can shed on the situation? I ask as a programmer who has little experience with network setup and Active Directory.
Thanks
Have a look in IE settings. Tools > Internet Options > Security > Local Intranet > Custom Level. Scroll down to the very last setting "Automatic login only in Intranet zone". By default IE will only automatically pass along windows authenticated credentials to a site it considers "intranet".