proltdman
asked on
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("L
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.
My intranet site uses the following bit of ASP utilising the WinNT ADsPath to pick up the user requesting the page:
<%
sLogonUser = Request.ServerVariables("L
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.
ASKER
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
> 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"
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"
ASKER
> 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?
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?
> 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.
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.
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
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
> 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.
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.
ASKER
> 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!
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!
> 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...
> 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...
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]
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]
ASKER
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)
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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
Cool!
Now I have some hope of solving this problem the next time I encounter it.
Consider this page bookmarked for future reference....
Now I have some hope of solving this problem the next time I encounter it.
Consider this page bookmarked for future reference....
If you have that permission, give it a shot.