2 domains, 2 networks and authentication (IIS6/asp.net)

tgabe213

2[H]4U
Joined
Aug 27, 2007
Messages
3,684
We've recently acquired another bank. We have some hardware installed at their sites (routers) that are connected to the T1's that come back to our operations center. They run a different IP scheme than we do so there is no overlap with IP addresses.

I had built a pretty simple web application that gets used by our Investment services group, and general employees to add new referrals. The application looks to see who you are currently logged into the network as, and based on that, presents certain admin features to you, or keeps them disabled.

We have 2 investment people down at one of the new locations. They can access the server that is housing this application without a problem, except, they get prompted from credentials because I have anonymous authentication turned off. I can't remember why I had to turn this off, but it was required in order to get the actual user ID of the person connecting. I thought that entering userid@domain and their password would authenticate them for the application. It loads for a second, and then it re-prompts them with the authentication box again. They never get to see any of the application.

If I enable anonymous access, then the page instantly loads for them, but they aren't recognized as an admin (of course).

Any ideas? I believe it would be something in IIS that I should be changing, but I really have no idea. I don't know why it just keeps reprompting for credentials.

Thanks
 
You have to disable anonymous access in order to force the browser to pass NTLM credentials.

Since you have 2 seperate domains, I'm not sure you're going to be able to solve this issue without going to a forms/windows authentication hybrid.

You're easiest solution is would be to have those 2 users VPN into the domain or remote desktop to a machine that's in the domain.
 
Makes sense. Why doesn't the site accept the credentials that are being passed when they are prompted for a username and password? It just comes back with the prompt again.
 
Are the two people at the branch using machines that are on your original domain to connect in or are they using accounts/machines on the acquired company's domain?
 
Are the two people at the branch using machines that are on your original domain to connect in or are they using accounts/machines on the acquired company's domain?

Acquired companys domain. They will be on our domain in about 37 domains. None of the employees down there are using this system yet, so I just made a copy of the application, and disabled the security portion so the 'admin' functions are automatically enabled. Then only these 2 will have this URL. Both 'sites' will keep hitting the same database.

It's not best practice, but I have other things I need to work on when this will be temporary anyway.
 
so does the application server exist on their domain, or or your domain? I'm confused on that part, because in one post you say you made a "copy" of the application :confused:

if on your domain, you did setup a trust between the 2 forests, correct?

also, could try having them logon with domain/username, even though username@domain should work.
 
Makes sense. Why doesn't the site accept the credentials that are being passed when they are prompted for a username and password? It just comes back with the prompt again.

When you do NTLM auth in a browser, the browser authenticates against the client machines AD server, B, gets a token, and passes the token to the server. The server then verifies this token with its current AD server, A, and either accepts or rejects it. The username and password aren't sent to the web server.

If the client machine is on domain B, it authenticates against domain B. If B and A aren't talking correctly and with enough trust, passing crediantials for A to AD server B to get a token will fail. It could also fail when the server on A gets the token, asks its domain server to validate the token, (which may have been issued by B) which fails. There's a lot of stuff to go wrong.
 
Back
Top