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" <rg*****@mentor its.com> wrote in message
news:u2******** ********@tk2msf tngp13.phx.gbl. ..

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

[Richard Gutery]

Thaks SL, but the return value of 0 is actually returned by
GetObject("WinN T://"...) 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" <sylvain aei ca (fill the blanks, no spam please)>
wrote in message news:ua******** ********@TK2MSF TNGP14.phx.gbl. ..

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" <rg*****@mentor its.com> wrote in message
news:u2******** ********@tk2msf tngp13.phx.gbl. ..

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]

After some thinking, the IUSER_machine account is not necessarily the
account used to run your Active-X: the authentificatio n 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" <rg*****@mentor its.com> wrote in message
news:eV******** ********@tk2msf tngp13.phx.gbl. ..

Thaks SL, but the return value of 0 is actually returned by
GetObject("WinN T://"...) 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" <sylvain aei ca (fill the blanks, no spam please)>
wrote in message news:ua******** ********@TK2MSF TNGP14.phx.gbl. ..

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" <rg*****@mentor its.com> wrote in message
news:u2******** ********@tk2msf tngp13.phx.gbl. ..

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

[Richard Gutery]

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

RG
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)>
wrote in message news:O5******** ******@TK2MSFTN GP12.phx.gbl...

After some thinking, the IUSER_machine account is not necessarily the
account used to run your Active-X: the authentificatio n 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" <rg*****@mentor its.com> wrote in message
news:eV******** ********@tk2msf tngp13.phx.gbl. ..

Thaks SL, but the return value of 0 is actually returned by
GetObject("WinN T://"...) 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" <sylvain aei ca (fill the blanks, no spam please)>
wrote in message news:ua******** ********@TK2MSF TNGP14.phx.gbl. ..

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" <rg*****@mentor its.com> wrote in message
news:u2******** ********@tk2msf tngp13.phx.gbl. ..
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

[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" <sylvain aei ca (fill the blanks, no spam please)>
wrote in message news:O5******** ******@TK2MSFTN GP12.phx.gbl...

After some thinking, the IUSER_machine account is not necessarily the
account used to run your Active-X: the authentificatio n 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" <rg*****@mentor its.com> wrote in message
news:eV******** ********@tk2msf tngp13.phx.gbl. ..

Thaks SL, but the return value of 0 is actually returned by
GetObject("WinN T://"...) 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" <sylvain aei ca (fill the blanks, no spam please)>
wrote in message news:ua******** ********@TK2MSF TNGP14.phx.gbl. ..

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" <rg*****@mentor its.com> wrote in message
news:u2******** ********@tk2msf tngp13.phx.gbl. ..
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]

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" <rg*****@mentor its.com> wrote in message
news:uw******** ******@TK2MSFTN GP11.phx.gbl...

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" <sylvain aei ca (fill the blanks, no spam please)>
wrote in message news:O5******** ******@TK2MSFTN GP12.phx.gbl...

After some thinking, the IUSER_machine account is not necessarily the
account used to run your Active-X: the authentificatio n 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" <rg*****@mentor its.com> wrote in message
news:eV******** ********@tk2msf tngp13.phx.gbl. ..

Thaks SL, but the return value of 0 is actually returned by
GetObject("WinN T://"...) 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" <sylvain aei ca (fill the blanks, no spam please)>
wrote in message news:ua******** ********@TK2MSF TNGP14.phx.gbl. ..
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" <rg*****@mentor its.com> wrote in message
news:u2******** ********@tk2msf tngp13.phx.gbl. ..
>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
>componen t 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
>

[Richard Gutery]

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

RG

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)>
wrote in message news:OQ******** ******@TK2MSFTN GP11.phx.gbl...

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" <rg*****@mentor its.com> wrote in message
news:uw******** ******@TK2MSFTN GP11.phx.gbl...

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" <sylvain aei ca (fill the blanks, no spam please)>
wrote in message news:O5******** ******@TK2MSFTN GP12.phx.gbl...

After some thinking, the IUSER_machine account is not necessarily the
account used to run your Active-X: the authentificatio n 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" <rg*****@mentor its.com> wrote in message
news:eV******** ********@tk2msf tngp13.phx.gbl. ..
Thaks SL, but the return value of 0 is actually returned by
GetObject("WinN T://"...) 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" <sylvain aei ca (fill the blanks, no spam please)>
wrote in message news:ua******** ********@TK2MSF TNGP14.phx.gbl. ..
> 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" <rg*****@mentor its.com> wrote in message
> news:u2******** ********@tk2msf tngp13.phx.gbl. ..
>>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
>>compone nt 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
>>passwor d 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
>>
>
>