[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 851
  • Last Modified:

winNT GetObject error

Hi

My intranet site uses the following bit of ASP utilising the WinNT ADsPath to pick up the user requesting the page:

<%

sLogonUser = Request.ServerVariables("Logon_User")
sDomain = Mid(sLogonUser, 1, Instr(1, sLogonUser, "\") - 1)
strUserName = Mid(sLogonUser, Instr(1, sLogonUser, "\") + 1)

Set strUser = GetObject("WinNT://" & sDomain & "/" & strUserName & ",user")
strFullName = strUser.FullName

%>

This was working fine until a few changes (listed below) occurred on the network and now everyone receives this error:

Microsoft VBScript runtime (0x800A0046) Permission denied: 'GetObject'


Changes on the network around the same time as the error were:

Proxy un-installed (was located on same server as IIS) and latest security patches added
2 new domain controller servers added

Background:

Both IIS and Active Directory are located on win 2k servers.
All servers are on same domain.
IIS is set to integrated windows authentication.
Since the page hasn’t worked I’ve given “domain\users” administrator rights on both the IIS and AD servers and also full control on the wwwroot directory (overkill I know but trying to rule out everything) and still error occurs.
The only time this page works is when I access the page on the web server itself.

I've looked through the similar problems on this site, and I've tried all suggestions, but I'm still getting the same error. Any help would be much appreciated.
0
proltdman
Asked:
proltdman
  • 5
  • 5
  • 5
1 Solution
 
thunderchickenCommented:
You might try running that as a Domain Administrator

If you have that permission, give it a shot.
0
 
proltdmanAuthor Commented:

when you say "running that as a domain administrator" do you mean requesting the page logged on as a domain administrator? I am a domain administrator. The page will not work under any login except from the actual web server itself.
I need the page to work for all users as it's in an intranet environment - the point of the page is to pick up whether a user is within a certain AD group and depending on which group they belong to get passed to another section of the intranet. Sorry if I've mis-understood your meaning? thanks
0
 
thunderchickenCommented:
> The page will not work under any login except from the actual web server itself

Do you have a "trust" between the two servers?

Try to set up the page as Basic Authentication and log into the domain "DOMAIN/username"

0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
proltdmanAuthor Commented:
> Do you have a "trust" between the two servers?

I thought it was only if the servers were on different domains that you have to set up a "trust" within the "AD domains and trusts" - where do set up this trust between servers if they're on the same domain?

>Try to set up the page as Basic Authentication and log into the domain "DOMAIN/username"

If I set up the site using basic authentication this means that users will have to enter their credentials everytime they access the intranet doesn't it? I don't want them to have to do this.

Sorry, I'm don't want to sound like I'm throwing away all your ideas. I'm just confused as to how the script was working just fine until the proxy was un-installed or the domain controller servers were added and now it's not?
0
 
thunderchickenCommented:
> where do set up this trust between servers if they're on the same domain?

What OS are you running?  You can have local computer accounts and domain accounts.  Sounds like it's defaulting to the local computer account.

> I don't want them to have to do this.

It's just for testing to see what's going on.
0
 
deighcCommented:
I'd say that almost without doubt the addition of two new domain controllers is causing the problem.

You probably know about the dreaded "double hop" (or "delegation") issues when using NTLM authentication (ie. that the IIS machine is unable to pass on authentication credentials to any other machine on the network).

I'm guessing that, prior to the new domain controllers, the IIS machine was the primary domain controller. Now that you have new machines dealing with domain control it looks as if the IIS machine has to go to another phyiscal machine to authenticate the user. But by virtue of the "double hop" limitation the IIS machine is unable to pass on the user info for the user accessing the web app. And hence the error.

(Well, that's my theory anyway....)

And what's the answer? Hmmm, tricky. I think that Win2000 domains let you set up trust relationships between servers - but I'm not certain what this actually means (!!) and I've never done this so I can't help you out there.

I think you also need to specify each user account as "OK for delegation". This link might help with that (although the overall topic is different):

http://support.microsoft.com/default.aspx?scid=kb;EN-US;283201



0
 
thunderchickenCommented:
> I think that Win2000 domains let you set up trust relationships between servers - but I'm not certain what this actually means (!!) and I've never done this so I can't help you out there.


I had a similar problem with a Win2k domain about 4 years ago, I asked it on here, but can't seem to find it.  It has something that you have to "trust" one server to the domain to do this type of Active Directory stuff.
0
 
proltdmanAuthor Commented:
> You probably know about the dreaded "double hop" (or "delegation") issues when using NTLM authentication (ie. that the IIS machine is unable to pass on authentication credentials to any other machine on the network).

Yes, I've heard about it from reading some of these postings but I was hoping there was a way around it. It all makes sense what you're saying that's for sure. Although the IIS server wasn't the PDC before the other 2 DC's were added - it's always been our exchange server which is the PDC. But certainly the time that the error started occuring was around the time when the other 2 domain controllers were added...  I'll take a look at that link you sent - thanks deighc

> I had a similar problem with a Win2k domain about 4 years ago, I asked it on here, but can't seem to find it.  It has something that you have to "trust" one server to the domain to do this type of Active Directory stuff.

Thanks thunderchicken - I think I read that in one of the problems too - is it using the "Active Directory Domains and Trusts" tool on the server? As said before - thought that was if they were on different domains though? Sorry - once again I'm very confused - I've been working on this problem for a couple of weeks now!
0
 
deighcCommented:
> I had a similar problem with a Win2k domain about 4 years ago,
> I asked it on here, but can't seem to find it.

... and I had a similar problem about two years ago but it drew a total blank from EE contributors :-(

It's strange: delegation issues using NTLM (and also Digest) authentication are incredibly common but I've yet to find a clear, definitive and successful workaround for the problem.

I've found "workarounds" for specific problems like the one that I had (communicating with an Exchange server). But they're all hacks and seem like a very inelegant solutions in my opinion.

So - at the risk of discouraging proltdman - I have to say that the whole delegation problem really pours alot of cold water on the whole NTLM authentication thing for me (which is a pity because it's so good in many other ways). ASP.NET is much better suited to this sort of thing because it has native functionality for user impersonation. But with old skool ASP you have to jump thru hoops.

proltdman, if I find any links that might help you I'll be sure to post them here because I feel your pain...
0
 
deighcCommented:
Actually I should've pointed out that your problem is DEFINITELY the double hop because you can authenticate sucessfully when accessing your web app directly on the IIS machine.

And..

Here's a link that describes a similar situation to yours. Their solution is to set the user accounts as "trusted for delegation" (ie. same solution as the MSDN article I mentioned).

http://forums.aspfree.com/t23751/s.html

[I've never tried this so I can't vouch for it's effectiveness]
0
 
proltdmanAuthor Commented:
Thanks deighc - it's kind of good to know that it's not me being an idiot and missing something basic! I was thinking of moving the intranet to ASP.NET but didn't have the motivation before - now I have so I'd best get to it. I will leave this open for a bit longer to see if anyone else can come up with any miracle cures - is it possible to do that? (This is the first time I've posted a question). Thanks, Claire (aka proltdman)
0
 
thunderchickenCommented:
It's definately a Server problem, doesn't have to do with your code, so updating your code to .NET probably wont solve your problem.
0
 
deighcCommented:
I'm not sure I'd call it a "server problem".

It's more of a known limitation (MS clearly state that delegation thru IIS across servers is not possible with using either NTLM or Digest authencation).

The basic problem is that (for some arcane/complex/weird reason) IIS cannot pass the access token of the remote user on to other machines on the network. But it works OK if you work directly on the IIS machine because the access token comes directly from that machine (hence, your web app works when you use it directly on the IIS box).

But there are programmatic solutions to this issue. Basically, you need your web app to behave as if it's a certain user. Ideally this would just be the user account of the remote user (ie. the whole point of using NTLM auth in the first place). But ASP.NET will let you impersonate a user programmatically. The delegation issue is entirely limited to the weirdness of IIS and NTLM, so if your code "creates" the user that's accessing the resources then passing THIS user info onto other servers is no problem. There may be a way to do this in normal ASP too (using a COM object perhaps), so maybe you should so a little investigation into that first.

And it doesn't really need to be said. But...

If you do go down the ASP.NET path be sure to do plenty of research into it first so that you can be (reasonably) sure that it will solve your problem. Maybe these two articles on MSDN can get you started:

ASP.NET Impersonation

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsent7/html/vxconimpersonation.asp?frame=true

ASP.NET Delegation

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsent7/html/vxconaspnetdelegation.asp?frame=true
0
 
proltdmanAuthor Commented:
Thank you both very much for your help and time with this problem. I tried the "trusted for delegation" on my user account and the page worked which was a fantastic start! Then I read through all your links that you sent, deighc, which triggered my memory about the DCOM settings that you can change on a server to either "aonoymous", "delegate", "identify" or "impersonate" - it was set to identify, so I changed it to "impersonate" (Control panel, administration tools, component services, then right click on "my computer" - properties, then on the default properties tab make sure "enable DCOM on this computer" and use the "impersonate" default impersonation level) - and it works for every user now!  I can't tell you how ridiculously happy I am now! Thanks very much, Claire
0
 
deighcCommented:
Cool!

Now I have some hope of solving this problem the next time I encounter it.

Consider this page bookmarked for future reference....
0

Featured Post

Important Lessons on Recovering from Petya

In their most recent webinar, Skyport Systems explores ways to isolate and protect critical databases to keep the core of your company safe from harm.

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