Impersonating a user in x64

[CJM]

I use the following technique to impersonate a user in ASP, in order to
query active directory:

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

Although the article indicates that this technique is supported by IIS4 &
IIS5, I actually run it successfully on Windows Server 2003 (IIS6).

However, I've got a new development machine which is running XP Pro x64
Edition, and now this technique doesnt work ('Cannot create object'-type
error).

Is there a way to get this to work on this OS? If not, what is the best
alternative that works on Server 2003 and XP x64?

Thanks in advance...

Chris

 

[Anthony Jones]

I use the following technique to impersonate a user in ASP, in order to
query active directory:

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

Although the article indicates that this technique is supported by IIS4 &
IIS5, I actually run it successfully on Windows Server 2003 (IIS6).

However, I've got a new development machine which is running XP Pro x64
Edition, and now this technique doesnt work ('Cannot create object'-type
error).

Is there a way to get this to work on this OS? If not, what is the best
alternative that works on Server 2003 and XP x64?

Thanks in advance...

Chris

Is suspect the problem has nothing to do with the impersonation technique.
You are getting an error trying to instantiate the object.

Try it in a standalone VBScript file does that work?

You probably need to resolve permissions allowing IUSR to access the dll.

Anthony.

 

[David Wang [Msft]]

The VB ActiveX object is 32bit. The OS is 64bit. The different "bitness" are
incompatible if attempting to run them in the same process (which you need
to do in order to change the impersonation token).

Your choices are to either:
1. Configure IIS on XP64 to run in 32bit WOW64 compatibility mode.
adsutil set W3SVC/Enable32BitAppOnWin64 1
Changing bitness can obviously cause other failures if you have code running
on IIs that must be 64bit. Search my blog for "WOW64" or "64bit" for an
understanding of the issue
2. Recompile a 64bit version of the ActiveX object (probably have to do it
in C++ - there is no such thing as 64bit VB) and run everything as native
64bit.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//

 

[CJM]

The VB ActiveX object is 32bit. The OS is 64bit. The different "bitness"
are incompatible if attempting to run them in the same process (which you
need to do in order to change the impersonation token).

Your choices are to either:
1. Configure IIS on XP64 to run in 32bit WOW64 compatibility mode.
adsutil set W3SVC/Enable32BitAppOnWin64 1
Changing bitness can obviously cause other failures if you have code
running on IIs that must be 64bit. Search my blog for "WOW64" or "64bit"
for an understanding of the issue
2. Recompile a 64bit version of the ActiveX object (probably have to do it
in C++ - there is no such thing as 64bit VB) and run everything as native
64bit.

Thanks David...

Option 2 seems preferable... I do have a copy of C++ but unfortunately I
have zero knowledge of the language, so it would be very difficult for me to
do off my own back. Is there an equivalent KB article that provides the C++
code?

Option 1 is obviously a possibility. Switching to 32bit wont be a problem at
the moment, but you never know in the future. Plus we will be slowly
migrating to 64bit servers, and I might not have as much control over
these - these may need to run some 64bit code.

Is there an alternative to this whole impersonation technique?

Thanks

 

[David Wang [Msft]]

Impersonation approach is the only choice you have.

I don't know if ADSI has a syntax to allow you to pass username/password for
the ADSI call, but if it does, it can be an "alternative".

Otherwise, you have no choice since:
1. ADSI needs a valid user identity
2. ASP only executes code with an impersonated identity from authentication

This means that:
1. if you configure authentication in IIS, the remote user identity is used
to execute code - which may not have permissions to Active Directory - hence
you need to modify the user somehow, either via an object that temporarily
changes the Impersonation token, or if ADSI allows a username/password to be
passed.
2. if you do not configure authentication in IIS and just use anonymous,
then the configured anonymous user account is used to execute code - which
can be configured to have permissions to Active Directory. But there is no
user authentication.

In other words, with ASP, there is no such thing as:
1. Authenticate using a Windows user account
2. Run code using another user account
-> Unless you use a custom component to perform #2

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//

 

[Anthony Jones]

I use the following technique to impersonate a user in ASP, in order to
query active directory:

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

Although the article indicates that this technique is supported by IIS4 &
IIS5, I actually run it successfully on Windows Server 2003 (IIS6).

However, I've got a new development machine which is running XP Pro x64
Edition, and now this technique doesnt work ('Cannot create object'-type
error).

Is there a way to get this to work on this OS? If not, what is the best
alternative that works on Server 2003 and XP x64?

Thanks in advance...

Chris

Is this of any use to you:-

http://msdn.microsoft.com/library/d...s/adsi/adsi/iadsopendsobject_opendsobject.asp

 

[CJM]

Is this of any use to you:-

http://msdn.microsoft.com/library/d...s/adsi/adsi/iadsopendsobject_opendsobject.asp

TBH, I'm not sure! On the first pass, it looks like double-dutch... on the
second, it started to make a little sense. I'm not sure if it's a viable
alternative, but it certainly looks worth investigating.

Thanks

Chris