We have an Asp.net webapplication in production running all these years. Now, the company is creating a new Domain and want the users from the new domain to have access to the Asp.Net web application. The server in which our application is hosted is still in the old domain and it is not going to be changed. The Infra team has given us new AD server name where the new domain resides and asking us to make our application to allow users from the new domain. As far as i know, we don't specify the AD server to authenticate in Web.Config except setting Authentication mode to Windows.
What we need is, we need to allow users from the existing domain and users from the new domain to have access to the application. Please let me know how to do this..Thanks in advance!
Regards,
Bala
You need a Kerberos cross-realm trust. One way should suffice.
Related
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 setup Active Directory in a VM and added some users into it. I used Windows 2008 core edition to setup the AD. Now to test my asp.net application, I created a sample page and configured in IIS. So when we call this page windows security window will be called and ask for username and passowrd.
My requirement is type the username and password which i specified inside AD. I provide username in the security window, something like:
test.ca/username
where test.ca is the domain name for AD. My problem is username is not getting accessed from VM and authentication fails and the username/pwd window prompts again.
Any one has suggestions?
Regards
Sangeetha
The machine running IIS must be joined to the Active Directory domain in order to use Integrated authentication with domain accounts.
If the machine running IIS cannot be joined to the domain, then you would need to use Forms authentication instead. Then, your ASP.NET application could, for example, validate the user's credentials against AD using the classes in the System.DirectoryServices namespace.
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.
We have an ASP.NET website set up using Active Directory as the Membership Provider. The site uses the Forms authentication mode and the .NET Login control. We recently merged with another company and now they also need access to the site, but they are of course on a different domain. Our IT people have set up the two Active Directories in a two-way trust.
I can log on to their domain using a test account from our network. But when I use the same DOMAIN\username + password combo on my website it does not work.
How can I make our site able to see users on the second domain? Is this not possible using the Login control? Or is there something else I'm missing?
I don't think it's possible to authenticate against a remote AD domain, via a trust with the built-in provider. You could setup a second provider which is configured to point at the other domain, and then add addition logic to your Login control to pick the right provider to authenticate against. I use a similar approach to support "pass-through" authentication of domain users while also support non-domain users with standard forms authentication.
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.