IIS 6.0 Bug?

Discussion in 'ASP .Net Security' started by Dominick Baier, Sep 13, 2006.

  1. Hi,

    which framework version are you using. Impersonation tokens are not always
    propagated to async operations.

    In 1.1 they are never propagated. In 2.0 you can control that via a config
    setting

    http://www.leastprivilege.com/WhatIsAspnetconfig.aspx

    ---
    Dominick Baier, DevelopMentor
    http://www.leastprivilege.com

    > Hi,
    >
    > I apologize for the extensive cross-posting but I'm getting desparate.
    >
    > We have a web page calling one or another web service. Both web
    > service communicate with Sharepoint 2003, and both temporarily change
    > impersonation using WindowsImpersonationContext class and then revert
    > back with WindowsImpersonationContext.Undo() to typically save
    > documents with the correct user name.
    >
    > Calling the web services synchronously works fine, but we need it to
    > work asynchronously (typically creating and saving a document before
    > the web services do some work on it).
    >
    > The problem is, instead of reverting to the original user,
    > WindowsImpersonationContext ends up as the user running the
    > Application
    > Pool
    > for the web page. I have been unable to find out anything why this
    > happens.
    > Furthermore, I created a new Application Pool for the web page,
    > thinking perhaps sharing the same pool was the problem, but before I
    > could attach it to the web page the problem appeared to solve itself,
    > for a short time.
    >
    > Doing some extensive testing I have concluded this:
    > WindowsImpersonationContext.Undo() works for a short time if a dummy
    > application pool (not used by anything) is STARTED
    > WindowsImpersonationContext.Undo() works for a short time if a dummy
    > application pool (not used by anything) is STOPPED
    > When it works, it seems to work as long as only one web service is
    > called,
    > and it stops working as soon as the other web service is called.
    > ????
    >
    > The only google result I could come up with related to this does not
    > have a solution or email address
    >
    > http://www.derkeiler.com/Newsgroups/microsoft.public.dotnet.security/2
    > 005-02/0223.html
    >
    > Any idea, suggestions or something to try is extremely welcome
    >
    > - Morten
    >
    Dominick Baier, Sep 13, 2006
    #1
    1. Advertising

  2. then i am not sure what your problem is...

    if you think it is not impersonation related - you have to tell me more about
    the problems you are seeing.

    ---
    Dominick Baier, DevelopMentor
    http://www.leastprivilege.com

    > We use .Net 2.0, and upon further studies, it is not connected to
    >
    > WindowsImpersonationContext since only one web service uses that.
    >
    > What configuration is required?
    >
    > We use an encrypted identity section
    >
    > <trust level="Full" originUrl=""/>
    > <identity configProtectionProvider="RsaProtectedConfigurationProv
    > ider">
    > <EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element"
    > xmlns="http://www.w3.org/2001/04/xmlenc#">
    > <EncryptionMethod
    > Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
    > <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
    > <EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#">
    > <EncryptionMethod
    > Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
    > <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
    > <KeyName>Rsa Key</KeyName>
    > </KeyInfo>
    > <CipherData>
    >
    > <CipherValue>IKGgtOuiQqSL6KZOurRXMNSJxNioerQcyGGS3Ng2y6Sg
    > snjZqWQMztRTALlkbaVQM3zsh4BSnACU4pN+s1tWHDV1EKSyfCM7m5R5G54vUvF+oqj9MV
    > tZ
    > 12QVhv2i2hun95oHNtgAgYJjVbzAudcKMTe/phWP61iXqTgxKKNc+xw=</CipherValue>
    >
    > </CipherData>
    > </EncryptedKey>
    > </KeyInfo>
    > <CipherData>
    >
    > <CipherValue>RrRnNXdcQQozeNEGPuinT9aaRT2M9RGgOBe1O9/u9IIAzOfl
    > IZRr2UN0jWfiGk+WduHx/kM3ZN2s05k3/gQMcwZhykXHRFLAcURapxzjBRqz2HBh2ad05Q
    > =
    > =</CipherValue>
    > </CipherData>
    > </EncryptedData>
    > </identity>
    > and
    >
    > <authentication mode="Windows"/>
    > <authorization>
    > <allow users="*"/>
    > </authorization>
    > - Morten
    >
    > On Wed, 13 Sep 2006 11:46:50 +0200, Dominick Baier
    >
    > <dbaier@pleasepleasenospam_leastprivilege.com> wrote:
    >
    >> Hi, which framework version are you using. Impersonation tokens are
    >> no
    >>

    > t
    >
    >> always propagated to async operations.
    >>
    >> In 1.1 they are never propagated. In 2.0 you can control that via a
    >>
    >> config setting
    >>
    >> http://www.leastprivilege.com/WhatIsAspnetconfig.aspx
    >>
    >> ---
    >> Dominick Baier, DevelopMentor
    >> http://www.leastprivilege.com
    >>> Hi,
    >>> I apologize for the extensive cross-posting but I'm getting desparat

    > e.
    >
    >>> We have a web page calling one or another web service. Both web
    >>> service communicate with Sharepoint 2003, and both temporarily
    >>> change
    >>>
    >>> impersonation using WindowsImpersonationContext class and then
    >>> revert
    >>>
    >>> back with WindowsImpersonationContext.Undo() to typically save
    >>> documents with the correct user name.
    >>> Calling the web services synchronously works fine, but we need it to
    >>> work asynchronously (typically creating and saving a document before
    >>> the web services do some work on it).
    >>> The problem is, instead of reverting to the original user,
    >>> WindowsImpersonationContext ends up as the user running the
    >>> Application
    >>> Pool
    >>> for the web page. I have been unable to find out anything why this
    >>> happens.
    >>> Furthermore, I created a new Application Pool for the web page,
    >>> thinking perhaps sharing the same pool was the problem, but before I
    >>> could attach it to the web page the problem appeared to solve
    >>> itself,
    >>> for a short time.
    >>> Doing some extensive testing I have concluded this:
    >>> WindowsImpersonationContext.Undo() works for a short time if a dummy
    >>> application pool (not used by anything) is STARTED
    >>> WindowsImpersonationContext.Undo() works for a short time if a dummy
    >>> application pool (not used by anything) is STOPPED
    >>> When it works, it seems to work as long as only one web service is
    >>> called,
    >>> and it stops working as soon as the other web service is called.
    >>> ????
    >>> The only google result I could come up with related to this does not
    >>> have a solution or email address
    >>> http://www.derkeiler.com/Newsgroups/microsoft.public.dotnet.security

    > /2
    >
    >>> 005-02/0223.html
    >>> Any idea, suggestions or something to try is extremely welcome
    >>> - Morten
    Dominick Baier, Sep 13, 2006
    #2
    1. Advertising

  3. Hi,

    I apologize for the extensive cross-posting but I'm getting desparate.

    We have a web page calling one or another web service. Both web service
    communicate with Sharepoint 2003, and both temporarily change impersonation
    using WindowsImpersonationContext class and then revert back with
    WindowsImpersonationContext.Undo() to typically save documents with the
    correct user name.

    Calling the web services synchronously works fine, but we need it to work
    asynchronously (typically creating and saving a document before the web
    services do some work on it).

    The problem is, instead of reverting to the original user,
    WindowsImpersonationContext ends up as the user running the Application
    Pool
    for the web page. I have been unable to find out anything why this
    happens.

    Furthermore, I created a new Application Pool for the web page, thinking
    perhaps sharing the same pool was the problem, but before I could attach it
    to the web page the problem appeared to solve itself, for a short time.

    Doing some extensive testing I have concluded this:
    WindowsImpersonationContext.Undo() works for a short time if a dummy
    application pool (not used by anything) is STARTED
    WindowsImpersonationContext.Undo() works for a short time if a dummy
    application pool (not used by anything) is STOPPED
    When it works, it seems to work as long as only one web service is called,
    and it stops working as soon as the other web service is called.

    ????

    The only google result I could come up with related to this does not have a
    solution or email address

    http://www.derkeiler.com/Newsgroups/microsoft.public.dotnet.security/2005-02/0223.html

    Any idea, suggestions or something to try is extremely welcome

    - Morten
    Morten Wennevik, Sep 13, 2006
    #3
  4. We use .Net 2.0, and upon further studies, it is not connected to
    WindowsImpersonationContext since only one web service uses that.

    What configuration is required?

    We use an encrypted identity section

    <trust level="Full" originUrl=""/>
    <identity configProtectionProvider="RsaProtectedConfigurationProvider">
    <EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element"
    xmlns="http://www.w3.org/2001/04/xmlenc#">
    <EncryptionMethod
    Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
    <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
    <EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#">
    <EncryptionMethod
    Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
    <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
    <KeyName>Rsa Key</KeyName>
    </KeyInfo>
    <CipherData>
    <CipherValue>IKGgtOuiQqSL6KZOurRXMNSJxNioerQcyGGS3Ng2y6SgsnjZqWQMztRTALlkbaVQM3zsh4BSnACU4pN+s1tWHDV1EKSyfCM7m5R5G54vUvF+oqj9MVtZ12QVhv2i2hun95oHNtgAgYJjVbzAudcKMTe/phWP61iXqTgxKKNc+xw=</CipherValue>
    </CipherData>
    </EncryptedKey>
    </KeyInfo>
    <CipherData>
    <CipherValue>RrRnNXdcQQozeNEGPuinT9aaRT2M9RGgOBe1O9/u9IIAzOflIZRr2UN0jWfiGk+WduHx/kM3ZN2s05k3/gQMcwZhykXHRFLAcURapxzjBRqz2HBh2ad05Q==</CipherValue>
    </CipherData>
    </EncryptedData>
    </identity>

    and

    <authentication mode="Windows"/>
    <authorization>
    <allow users="*"/>
    </authorization>


    - Morten

    On Wed, 13 Sep 2006 11:46:50 +0200, Dominick Baier
    <dbaier@pleasepleasenospam_leastprivilege.com> wrote:

    > Hi, which framework version are you using. Impersonation tokens are not
    > always propagated to async operations.
    >
    > In 1.1 they are never propagated. In 2.0 you can control that via a
    > config setting
    >
    > http://www.leastprivilege.com/WhatIsAspnetconfig.aspx
    >
    > ---
    > Dominick Baier, DevelopMentor
    > http://www.leastprivilege.com
    >
    >> Hi,
    >> I apologize for the extensive cross-posting but I'm getting desparate.
    >> We have a web page calling one or another web service. Both web
    >> service communicate with Sharepoint 2003, and both temporarily change
    >> impersonation using WindowsImpersonationContext class and then revert
    >> back with WindowsImpersonationContext.Undo() to typically save
    >> documents with the correct user name.
    >> Calling the web services synchronously works fine, but we need it to
    >> work asynchronously (typically creating and saving a document before
    >> the web services do some work on it).
    >> The problem is, instead of reverting to the original user,
    >> WindowsImpersonationContext ends up as the user running the
    >> Application
    >> Pool
    >> for the web page. I have been unable to find out anything why this
    >> happens.
    >> Furthermore, I created a new Application Pool for the web page,
    >> thinking perhaps sharing the same pool was the problem, but before I
    >> could attach it to the web page the problem appeared to solve itself,
    >> for a short time.
    >> Doing some extensive testing I have concluded this:
    >> WindowsImpersonationContext.Undo() works for a short time if a dummy
    >> application pool (not used by anything) is STARTED
    >> WindowsImpersonationContext.Undo() works for a short time if a dummy
    >> application pool (not used by anything) is STOPPED
    >> When it works, it seems to work as long as only one web service is
    >> called,
    >> and it stops working as soon as the other web service is called.
    >> ????
    >> The only google result I could come up with related to this does not
    >> have a solution or email address
    >> http://www.derkeiler.com/Newsgroups/microsoft.public.dotnet.security/2
    >> 005-02/0223.html
    >> Any idea, suggestions or something to try is extremely welcome
    >> - Morten
    >>

    >
    >




    --
    Happy Coding!
    Morten Wennevik [C# MVP]
    Morten Wennevik, Sep 13, 2006
    #4
  5. Well, the problem is that user running the web page does not always carry
    over to the web service. I'm not responsible for the web services, only
    the web page so I have misread the logs thinking
    WindowsImpersonationContext was to blame, but the other web service uses
    only <identity impersonate="true"/>.

    I discovered the links after sending the last mail. Going to try that.

    -Morten


    On Wed, 13 Sep 2006 12:11:14 +0200, Dominick Baier
    <dbaier@pleasepleasenospam_leastprivilege.com> wrote:

    > then i am not sure what your problem is...
    >
    > if you think it is not impersonation related - you have to tell me more
    > about the problems you are seeing.
    >
    > ---
    > Dominick Baier, DevelopMentor
    > http://www.leastprivilege.com
    >
    >> We use .Net 2.0, and upon further studies, it is not connected to
    >> WindowsImpersonationContext since only one web service uses that.
    >> What configuration is required?
    >> We use an encrypted identity section
    >> <trust level="Full" originUrl=""/>
    >> <identity configProtectionProvider="RsaProtectedConfigurationProv
    >> ider">
    >> <EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element"
    >> xmlns="http://www.w3.org/2001/04/xmlenc#">
    >> <EncryptionMethod
    >> Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
    >> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
    >> <EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#">
    >> <EncryptionMethod
    >> Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
    >> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
    >> <KeyName>Rsa Key</KeyName>
    >> </KeyInfo>
    >> <CipherData>
    >> <CipherValue>IKGgtOuiQqSL6KZOurRXMNSJxNioerQcyGGS3Ng2y6Sg
    >> snjZqWQMztRTALlkbaVQM3zsh4BSnACU4pN+s1tWHDV1EKSyfCM7m5R5G54vUvF+oqj9MV
    >> tZ
    >> 12QVhv2i2hun95oHNtgAgYJjVbzAudcKMTe/phWP61iXqTgxKKNc+xw=</CipherValue>
    >> </CipherData>
    >> </EncryptedKey>
    >> </KeyInfo>
    >> <CipherData>
    >> <CipherValue>RrRnNXdcQQozeNEGPuinT9aaRT2M9RGgOBe1O9/u9IIAzOfl
    >> IZRr2UN0jWfiGk+WduHx/kM3ZN2s05k3/gQMcwZhykXHRFLAcURapxzjBRqz2HBh2ad05Q
    >> =
    >> =</CipherValue>
    >> </CipherData>
    >> </EncryptedData>
    >> </identity>
    >> and
    >> <authentication mode="Windows"/>
    >> <authorization>
    >> <allow users="*"/>
    >> </authorization>
    >> - Morten
    >> On Wed, 13 Sep 2006 11:46:50 +0200, Dominick Baier
    >> <dbaier@pleasepleasenospam_leastprivilege.com> wrote:
    >>
    >>> Hi, which framework version are you using. Impersonation tokens are
    >>> no
    >>>

    >> t
    >>
    >>> always propagated to async operations.
    >>> In 1.1 they are never propagated. In 2.0 you can control that via a
    >>> config setting
    >>> http://www.leastprivilege.com/WhatIsAspnetconfig.aspx
    >>> ---
    >>> Dominick Baier, DevelopMentor
    >>> http://www.leastprivilege.com
    >>>> Hi,
    >>>> I apologize for the extensive cross-posting but I'm getting desparat

    >> e.
    >>
    >>>> We have a web page calling one or another web service. Both web
    >>>> service communicate with Sharepoint 2003, and both temporarily
    >>>> change
    >>>> impersonation using WindowsImpersonationContext class and then
    >>>> revert
    >>>> back with WindowsImpersonationContext.Undo() to typically save
    >>>> documents with the correct user name.
    >>>> Calling the web services synchronously works fine, but we need it to
    >>>> work asynchronously (typically creating and saving a document before
    >>>> the web services do some work on it).
    >>>> The problem is, instead of reverting to the original user,
    >>>> WindowsImpersonationContext ends up as the user running the
    >>>> Application
    >>>> Pool
    >>>> for the web page. I have been unable to find out anything why this
    >>>> happens.
    >>>> Furthermore, I created a new Application Pool for the web page,
    >>>> thinking perhaps sharing the same pool was the problem, but before I
    >>>> could attach it to the web page the problem appeared to solve
    >>>> itself,
    >>>> for a short time.
    >>>> Doing some extensive testing I have concluded this:
    >>>> WindowsImpersonationContext.Undo() works for a short time if a dummy
    >>>> application pool (not used by anything) is STARTED
    >>>> WindowsImpersonationContext.Undo() works for a short time if a dummy
    >>>> application pool (not used by anything) is STOPPED
    >>>> When it works, it seems to work as long as only one web service is
    >>>> called,
    >>>> and it stops working as soon as the other web service is called.
    >>>> ????
    >>>> The only google result I could come up with related to this does not
    >>>> have a solution or email address
    >>>> http://www.derkeiler.com/Newsgroups/microsoft.public.dotnet.security

    >> /2
    >>
    >>>> 005-02/0223.html
    >>>> Any idea, suggestions or something to try is extremely welcome
    >>>> - Morten

    >
    >




    --
    Happy Coding!
    Morten Wennevik [C# MVP]
    Morten Wennevik, Sep 13, 2006
    #5
  6. IT WORKS :D

    That was indeed the problem, identity tokens not carrying over during
    asynchronous calls. Wonderful, I swear I have grown lot of gray hairs
    over this problem. All our other asynchronous test worked fine, but none
    of them did impersonated in the original page. Creating new
    networkcredentials seems to create a proper token anyway.

    Thank you so much!
    Tusen, tusen takk!

    - Morten

    On Wed, 13 Sep 2006 12:11:14 +0200, Dominick Baier
    <dbaier@pleasepleasenospam_leastprivilege.com> wrote:

    > then i am not sure what your problem is...
    >
    > if you think it is not impersonation related - you have to tell me more
    > about the problems you are seeing.
    >
    > ---
    > Dominick Baier, DevelopMentor
    > http://www.leastprivilege.com
    >
    >> We use .Net 2.0, and upon further studies, it is not connected to
    >> WindowsImpersonationContext since only one web service uses that.
    >> What configuration is required?
    >> We use an encrypted identity section
    >> <trust level="Full" originUrl=""/>
    >> <identity configProtectionProvider="RsaProtectedConfigurationProv
    >> ider">
    >> <EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element"
    >> xmlns="http://www.w3.org/2001/04/xmlenc#">
    >> <EncryptionMethod
    >> Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
    >> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
    >> <EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#">
    >> <EncryptionMethod
    >> Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
    >> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
    >> <KeyName>Rsa Key</KeyName>
    >> </KeyInfo>
    >> <CipherData>
    >> <CipherValue>IKGgtOuiQqSL6KZOurRXMNSJxNioerQcyGGS3Ng2y6Sg
    >> snjZqWQMztRTALlkbaVQM3zsh4BSnACU4pN+s1tWHDV1EKSyfCM7m5R5G54vUvF+oqj9MV
    >> tZ
    >> 12QVhv2i2hun95oHNtgAgYJjVbzAudcKMTe/phWP61iXqTgxKKNc+xw=</CipherValue>
    >> </CipherData>
    >> </EncryptedKey>
    >> </KeyInfo>
    >> <CipherData>
    >> <CipherValue>RrRnNXdcQQozeNEGPuinT9aaRT2M9RGgOBe1O9/u9IIAzOfl
    >> IZRr2UN0jWfiGk+WduHx/kM3ZN2s05k3/gQMcwZhykXHRFLAcURapxzjBRqz2HBh2ad05Q
    >> =
    >> =</CipherValue>
    >> </CipherData>
    >> </EncryptedData>
    >> </identity>
    >> and
    >> <authentication mode="Windows"/>
    >> <authorization>
    >> <allow users="*"/>
    >> </authorization>
    >> - Morten
    >> On Wed, 13 Sep 2006 11:46:50 +0200, Dominick Baier
    >> <dbaier@pleasepleasenospam_leastprivilege.com> wrote:
    >>
    >>> Hi, which framework version are you using. Impersonation tokens are
    >>> no
    >>>

    >> t
    >>
    >>> always propagated to async operations.
    >>> In 1.1 they are never propagated. In 2.0 you can control that via a
    >>> config setting
    >>> http://www.leastprivilege.com/WhatIsAspnetconfig.aspx
    >>> ---
    >>> Dominick Baier, DevelopMentor
    >>> http://www.leastprivilege.com
    >>>> Hi,
    >>>> I apologize for the extensive cross-posting but I'm getting desparat

    >> e.
    >>
    >>>> We have a web page calling one or another web service. Both web
    >>>> service communicate with Sharepoint 2003, and both temporarily
    >>>> change
    >>>> impersonation using WindowsImpersonationContext class and then
    >>>> revert
    >>>> back with WindowsImpersonationContext.Undo() to typically save
    >>>> documents with the correct user name.
    >>>> Calling the web services synchronously works fine, but we need it to
    >>>> work asynchronously (typically creating and saving a document before
    >>>> the web services do some work on it).
    >>>> The problem is, instead of reverting to the original user,
    >>>> WindowsImpersonationContext ends up as the user running the
    >>>> Application
    >>>> Pool
    >>>> for the web page. I have been unable to find out anything why this
    >>>> happens.
    >>>> Furthermore, I created a new Application Pool for the web page,
    >>>> thinking perhaps sharing the same pool was the problem, but before I
    >>>> could attach it to the web page the problem appeared to solve
    >>>> itself,
    >>>> for a short time.
    >>>> Doing some extensive testing I have concluded this:
    >>>> WindowsImpersonationContext.Undo() works for a short time if a dummy
    >>>> application pool (not used by anything) is STARTED
    >>>> WindowsImpersonationContext.Undo() works for a short time if a dummy
    >>>> application pool (not used by anything) is STOPPED
    >>>> When it works, it seems to work as long as only one web service is
    >>>> called,
    >>>> and it stops working as soon as the other web service is called.
    >>>> ????
    >>>> The only google result I could come up with related to this does not
    >>>> have a solution or email address
    >>>> http://www.derkeiler.com/Newsgroups/microsoft.public.dotnet.security

    >> /2
    >>
    >>>> 005-02/0223.html
    >>>> Any idea, suggestions or something to try is extremely welcome
    >>>> - Morten

    >
    >




    --
    Happy Coding!
    Morten Wennevik [C# MVP]
    Morten Wennevik, Sep 13, 2006
    #6
    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. Grind Boy

    .NET IIS to IIS credentials problem...

    Grind Boy, Aug 13, 2003, in forum: ASP .Net
    Replies:
    4
    Views:
    2,444
    Grind Boy
    Aug 14, 2003
  2. Matthew Louden
    Replies:
    3
    Views:
    5,898
    Sherif ElMetainy
    Nov 7, 2003
  3. JMaelstrom

    IIS 6 vs IIS 5 ASP.NET Performance Issues

    JMaelstrom, Dec 9, 2003, in forum: ASP .Net
    Replies:
    2
    Views:
    4,661
    shan420
    Apr 30, 2010
  4. Hai Nguyen

    IIS 6.0 vs IIS 5.1

    Hai Nguyen, Feb 5, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    2,237
    Alvin Bruney [MVP]
    Mar 2, 2004
  5. Joe Kaplan \(MVP - ADSI\)

    Re: Accessing AD from IIS 6 vs IIS 5

    Joe Kaplan \(MVP - ADSI\), May 7, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    422
    Joe Kaplan \(MVP - ADSI\)
    May 7, 2004
Loading...

Share This Page