General ASP & COM Question.

[Richard Gutery]

I have written a COM component who's purpose is to allow a user to change
his Windows (NT/AD) password via a web page. Now the component works fine
when I run it in VB 6, but not via the web page. The component also returns
an integer value that contains a return code from the Component (and the
appropriate Windows API). The result (using the ASP page) is Zero, which
indicates success. However the password doesn't change. (Zero = success, 100
= Invalid Domain, 101 = Invalid User, 102 = Invalid Password).

When using the component via VB or the LAN, we get correct results when
using bad Domains, Users and Passwords. So we are assured and confident that
the Component works as expected.

I suspected it had something to do with the IUSR account, so I added the
IUSR to the AD Domain Administrators group and the same result, ie return
result was Zero, which indicates apparent success - but the password didn't
change. So, I am at a bit of a loss as to why this doesn't work via an ASP
page.

As mentioned above, the component works fine via VB (both in the IDE and
Compiled), so we know that the code is all good and to make sure that I've
covered all the basis, I logged into AD with a normal user account and ran
the code. It worked fine. I realize that this is a security breach, but once
we have the component working via a browser, we'll tighten things up.

If anyone has any ideas, I would apprecicate pointers or some direction.

Thanks.

RG

 

[Sylvain Lafontaine]

First, you should make sure that your component is correctly loaded and
running properly. Using something like 0 as the proof that the component
has been correctly loaded and executed can be misleading. You should use
something else as the magic number, for example 22 or 43, to make sure that
this value is not some kind of artefact.

Second, the best way of debugging something is to use the old technic of
writing somewhere something about each step taken by your program.

S. L.

 

[Richard Gutery]

Thaks SL, but the return value of 0 is actually returned by
GetObject("WinNT://"...) which is part of the Active DS library. And yes, my
code is well documented and researched.

The question was, why doesn't this work in an ASP page?

As stated, it works fine when compiled in a VB project, but when the
component is used in an ASP page, it "Apparently" works, that is to say no
errors returned by Active DS lib. Also we use the following tools to
determine and track activity: Regmon, Handle, Listdlls and Process Explorer
(all by Sysinternals). These tools all indicate that the component is
loading properly, executing properly and returning correct results.

Agian, it works fine EXCEPT in an ASP page. In the ASP page, we get the same
return codes (see below) as we get on the LAN via VB (or compiled), but when
used in the ASP page, the password does not get changed.

Thanks...

RG

 

[Sylvain Lafontaine]

After some thinking, the IUSER_machine account is not necessarily the
account used to run your Active-X: the authentification process used to log
on the user and the isolation level for the application running under IIS
may change that. Under some conditions, the IWAM_machine account or the
real user account may be used; see for example:

http://support.microsoft.com/kb/319067/EN-US/

and:
http://support.microsoft.com/kb/248187/EN-US/

This may explain why adding the IUSER_machine account to the AD Domain
Administrators has been ineffective. You should try the same thing with
IWAM_machine or with the account used to log in.

S. L.

 

[Richard Gutery]

Thanks SL, I'll try that later (never thought of it...).

RG

 

[Richard Gutery]

Hi again SL.

I tried your suggestion for the IWAM account, no go.

You suggested using the 'Real User' account (which of course would be all
Domain Users) so I added the Users Local Account - no go.

So, I followed your link and found this one:
http://support.microsoft.com/kb/248187/EN-US/ which fixed everything up real
good, with a few minor problems - but I suspect it has to do with network
latency (i.e. Named Pipes thru RPC timeouts). That I can work on.

Thanks again for the direction.

RG

 

[Sylvain Lafontaine]

This is one of the main problem with Windows and IIS, it's very hard to know
what going on under the hood and error messages are often not informative at
all about what's really going wrong.

S. L.

 

[Richard Gutery]

Yeah! MS should have called the OS - "SHUTTERS".

RG