Hi Chris,
If the account being queried by the GetObject call is a domain
account, it's expected that the code could not work with integrated
windows authentication.
When we are using integrated auth, the authenticated user account's
logon type is NETWORK logon. This NETWORK logon session is used by
IIS to ship the ASP thread. It can access the resource on the IIS
machine without problem. However a NETWORK logon session cannot be
used to access resource on a 'third' machine(a 2-hop scenario). In
your case, it cannot access to your domain controller to query the
account info from AD.
To verify this point you can enable security auditting on your IIS
machine(in case it's a local account) or DC to track down it.
1) Go to administrative tools->Local Security Settings(Domain
Controller Security Settings)->Local Policies(Domain Plicies)->Audit
Policy, enable all kinds of failure audits.
2) Then open event viewer, clear and save as current Security log.
Browse to the problem virtual directory to reproduce the permission
denied error and then refresh security log to check if there is any
failure event appears.
If it is just a 2-hop scenario, a solution is to enable Kerberos
delegation but this isn't convenient enough due to every IE client
must enfore their integrated auth to Kerberos other than
NTLM(default). A more workable work around I think is wrapping the
code into a COM+ application and specify a domain account as its
running identity. Then you just call the COM+ component in your ASP
code. Or create a component to implment impersonation in ASP. Both
methods are explained in the following article:
How to impersonate a user from Active Server Pages
http://support.microsoft.com/?id=248187
Best regards,
WenJun Zhang
Microsoft Online Support
This posting is provided "AS IS" with no warranties, and confers no
rights.
Get Secure! -
www.microsoft.com/security >> Stay informed about: Permission denied: 'GetObject'