General ASP & COM Question.

Discussion in 'ASP General' started by Richard Gutery, Jan 13, 2005.

  1. 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, Jan 13, 2005
    #1
    1. Advertising

  2. 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" <> wrote in message
    news:u2GVL0X%...
    >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, Jan 14, 2005
    #2
    1. Advertising

  3. 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" <sylvain aei ca (fill the blanks, no spam please)>
    wrote in message news:ua4k8Dg%...
    > 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" <> wrote in message
    > news:u2GVL0X%...
    >>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, Jan 14, 2005
    #3
  4. 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" <> wrote in message
    news:eVoXD3j%...
    > 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" <sylvain aei ca (fill the blanks, no spam please)>
    > wrote in message news:ua4k8Dg%...
    >> 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" <> wrote in message
    >> news:u2GVL0X%...
    >>>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, Jan 17, 2005
    #4
  5. 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:O5WECaE$...
    > 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" <> wrote in message
    > news:eVoXD3j%...
    >> 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" <sylvain aei ca (fill the blanks, no spam please)>
    >> wrote in message news:ua4k8Dg%...
    >>> 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" <> wrote in message
    >>> news:u2GVL0X%...
    >>>>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, Jan 18, 2005
    #5
  6. Re: General ASP & COM Question - ALL FIXED!

    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:O5WECaE$...
    > 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" <> wrote in message
    > news:eVoXD3j%...
    >> 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" <sylvain aei ca (fill the blanks, no spam please)>
    >> wrote in message news:ua4k8Dg%...
    >>> 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" <> wrote in message
    >>> news:u2GVL0X%...
    >>>>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, Jan 18, 2005
    #6
  7. Re: General ASP & COM Question - ALL FIXED!

    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" <> wrote in message
    news:uw2skcY$...
    > 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:O5WECaE$...
    >> 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" <> wrote in message
    >> news:eVoXD3j%...
    >>> 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" <sylvain aei ca (fill the blanks, no spam please)>
    >>> wrote in message news:ua4k8Dg%...
    >>>> 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" <> wrote in message
    >>>> news:u2GVL0X%...
    >>>>>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, Jan 18, 2005
    #7
  8. Re: General ASP & COM Question - ALL FIXED!

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

    RG

    "Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)>
    wrote in message news:OQRkuoZ$...
    > 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" <> wrote in message
    > news:uw2skcY$...
    >> 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:O5WECaE$...
    >>> 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" <> wrote in message
    >>> news:eVoXD3j%...
    >>>> 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" <sylvain aei ca (fill the blanks, no spam please)>
    >>>> wrote in message news:ua4k8Dg%...
    >>>>> 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" <> wrote in message
    >>>>> news:u2GVL0X%...
    >>>>>>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, Jan 19, 2005
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. David
    Replies:
    6
    Views:
    477
    David
    Feb 13, 2004
  2. Baldy
    Replies:
    1
    Views:
    388
    Lucas Tam
    Oct 17, 2004
  3. Replies:
    3
    Views:
    459
    Clint Hill
    Jul 25, 2005
  4. Replies:
    2
    Views:
    552
    Ranginald
    Apr 13, 2006
  5. Robin
    Replies:
    2
    Views:
    129
    richard
    Feb 23, 2011
Loading...

Share This Page