• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1195
  • Last Modified:

IIS6 - Local Domain Users Cannot Access Virtual Directory / Remote Domain Users Can

Hey eveyone,

I've got a boxed app called ReqLogic that installs, by default, under the default website on an IIS6 (W2k3) server in a W2k3 Forest / Domain called NewDomain.com.  Directory Security for the Virutal Directory on the site is "Integrated Windows Authentication."  The site itself is installed on 2 servers and inside and outside of the Default Web Site, and the results are the same.

Users in OldDomain.com can access this site...no problem...their Windows credentials are passed to the application and if they are a user, the Login screen takes those creds and passes them right in.  This is a older W2k Native Domain and the users actually cross into the new domain where the IIS6 server is to obtain the website.

***Problem - users that reside in the new domain with new W2k3 accounts in the W2k3 domain/forest can't access this Virtual Directory.  The webserver resides in the same domain as the user accounts, but we get the Event ID: 529 errors like Kerberos can't cross the domains.

Can anyone shed some light on this please.

Muchos Gracias!!!
Event ID: 529
Logon Failure:
                Reason:                  Unknown user name or bad password
                User Name:            
                Logon Type:            3
                Logon Process:      Kerberos
                Authentication Package:        Kerberos
                Workstation Name: -
                Caller User Name: -
                Caller Domain:       -
                Caller Logon ID:     -
                Caller Process ID:  -
                Transited Services:                -
                Source Network Address:
                Source Port:            2841

Open in new window

  • 6
  • 3
2 Solutions
This sounds like the application knows that it was installed in or is supposed to authenticate against oldDomain and has a reference in its configuration to that domain.

Do you have a central database that the application connects to that holds configuration information where this might be configured?  Based on your description of the problem, this does not appear to be normal IIS authentication.
Team-PSOAuthor Commented:
I've got a meeting tomorrow about it with my applications department...and I'll bring this up for sure.

I'll post back :o)

Thanks a lot,
Team-PSOAuthor Commented:
Hey again,

I made from progress with it.

There were multiple websites (virtual directories) under the default website and we used a JScript to seperate then users based on what DNS name they came from...based on that...they would be forwarded to the appropriate sub-site (virtual directory).

***Remember from before - everything is fine if the user accounts come from the older W2k domain to the newer W2k3 domain where the website and server reside...if the user account is in the newer domain with the website and server...it would not work before...UNTIL I forwarded the user to the IP and not the FQDN.

So...I've made a DNS "A" record for "rl-test.mydomain.int" that point to and when the user comes to it...the JS reads what URL they arrived from and forwards them.

***So the Question is - why do users that reside in the same domain/forest as the website and IIS server have problems accessing the site via FQDN and have to the IP of the server?

Remember - the site uses "Integrated Windows Authentication" only...no anonymous access to the virtual directory.

Thanks again
if( /http:\/\/rl-test\.mydomain\.int/i.test(location.href) ) 
     location.href = "";
     location.href = "http://cltps023.mydomain.int/ReQlogic";

Open in new window

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Team-PSOAuthor Commented:
Can the JavaScript zone be added to this question please?
Thanks a lot
Because the machines that are in the domain are probably just using the machine name and not the FQDN to access the server.  With the old machines/domains they would most likely need to use the full domain name to access the server where as machines in the same name will resolve it by default but the browser will still only pass the machine name unless they type in the full thing.
Team-PSOAuthor Commented:
Thanks for the quick reply...but I'm testing it on a workstation that is in the same domain as the website/server with and account that is also in the same domain.

I enter http://rl-na.mydomain.int and the JavaScript forwards me to http://cltps023.mydomain.int/reqlogic and it doesn't work.

If I enter http://rl-test.mydomain.int and the JavaScript forwards me to it works.
ok, I see what is happening in the examples you provide ... one server name redirects to an IP and works correctly the other is redirecting to a machine name.domain.int and it does not work.

So, is the name.domain.int supposed to work?  Is this the correct name of the server?    Does an NSLOOKUP actually resolve name.domain.int to the IP of that it is supposed to?

I see in the example you have that the directory name in the reference with the machine name is not the same case ... in IIS this SHOULD not matter but you might want to check this.
Team-PSOAuthor Commented:
Got with my Layer 1-2-3 guys...they might have something funny in the ISA proxy they've messed with.
Another user stated this used to happen with SharePoint when the ISA wasn't correctly configured.

NSLookup checks clean and the name.domain.int is supposed to work...as it works okay for users in the old domain.
RL-NA.mydomain.in is an Alias in DNS for the FQDN cltps023.mydomain.int

I'm pretty close now...I'll post back.

thanks a lot,
Team-PSOAuthor Commented:
Ahhh...I figured it out.

The new W2k3 domain has in the GPO for the Default Domain, in IE - checked off by default - Enable Integrated Windows Authentication in the Advanced tab of IE Tools.

The older W2k domain does not have that.  If you uncheck that...you can use FQDNs on the LAN.

That's all it was and the consultants were blamming IIS the whole time.

THanks a lot for your help cj_1969


Featured Post

Hire Technology Freelancers with Gigs

Work with freelancers specializing in everything from database administration to programming, who have proven themselves as experts in their field. Hire the best, collaborate easily, pay securely, and get projects done right.

  • 6
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now