Hi,
Joe, Thank You for pointing me in the right direction.
My apps now captures the user's password with a text box
and retrieves the user's username via their computer
network logon.

This work perfectly.
No impersonating.
No hardcoding of any user's password or username.

My trouble now is trying to delete a "contact" object.
According to [url]http://msdn.microsoft.com/library/default.asp?[/url]
url=/library/en-
us/vbcon/html/vbtskremovingactivedirectorynodes.asp

There is two methods by which I can achieve this.

The first method is using DeleteTree:

Dim entry As New DirectoryEntry(DN, Username,
txtPassword.Text)
entry.DeleteTree()

Which gives me System.UnauthorizedAccessException: Access
is denied.
I have tracked this down to something to do with username
ASPNET and the .NET configuration 1.1

The other method is to use Remove:
Dim entry As New DirectoryEntry(DN, Username,
txtPassword.Text)
Dim entryToRemove As DirectoryEntry
' Add code here to set entryToRemove to the entry you want
to remove.
entryToRemove.Path = DN
entryToRemove.Username = Username
entryToRemove.Password = txtPassword.Text
entry.Children.Remove(entryToRemove)

Which gives me: System.NullReferenceException: Object
reference not set to an instance of an object.

By the way, I know I have permission to create and delete
the particular contact object. This was tested a number of
times using MMC.

Could anyone please help point me in the right direction?

Thank You.
>-----Original Message-----
>In ASP.NET under Windows Integrated authentication, the
logged on user's
>token is the token for the current request
(impersonating) only when you
>have impersonation turned on in web.config (it is off by
default). You need
>to add the <identity impersonate="true"/> tag.
>
>However, just because you are impersonating does not
necessarily mean that
>you can make requests on the network using that
identity. Unless the token
>you have is a primary logon token (which won't be true
with Windows
>Integrated auth. as the password is not passed), then
impersonation with a
>network call such as ADSI/S.DS will not work unless you
have enabled
>delegation and the clients are binding via Kerberos like
I said before.
>
>Because of the complexity of getting this to work
reliably, we generally
>bypass the whole issue by using username and password for
all of our S.DS
>binds. This requires us to store a secret password
somewhere and is
>potentially less secure, but ends up being more robust.
When we need to act
>as the current user, we capture their credentials via the
web application UI
>and bind with those.
>
>Joe K.
>
>"Michael Ekegren" <"michael.ekegren[no-
spam]"@netcompany.com> wrote in
>message news:3F091669.95C06735@netcompany.com...
>> I have written other ADSI based COM+ components in vb6.
But due to
>performance
>> and stability of these components I have the feeling
that it would be a
>better
>> approach to wrap the ADSI like calls in .Net code using
c#.
>>
>> Speaking identity for the entire application pool
in .Net - if I switch to
>> another user for the identity of such, then other
applications might
>break.
>> Therefore I'm not interested in that solution. In ASP
when running
>> NT-authenticated users towards the webserver, that
identity was also
>executing
>> code (if you needed to impersonate, COM+ was the only
option) - but this
>is not
>> the case in .Net?
>>
>> Best regards
>> Michael
>>
>>
>>
>>
>> "Joe Kaplan (MVP - ADSI)" wrote:
>>
>> > This seems like it would be effective as well, but it
also seems like it
>> > would add a lot of complexity for someone trying to
deploy a web server
>> > control. What would be the real advantage of going
with a separate COM+
>> > component in this instance? I'm pretty naive about
COM+, so I'd like to
>> > hear your opinion.
>> >
>> > Joe K.
>> >
>> > "Willy Denoyette [MVP]" <willy.denoyette@skynet.be>
wrote in message
>> > news:uKk244zQDHA.2636@TK2MSFTNGP10.phx.gbl...
>> > >
>> > > "Joe Kaplan (MVP - ADSI)"
<joseph.e.kaplan@removethis.accenture.com>
>wrote
>> > in message
news:emcSJYlQDHA.560@TK2MSFTNGP10.phx.gbl...
>> > >
>> > > > Another option you might be able to do would be
to impersonate a
>> > specific
>> > > > user account via web.config by specifying a
username and password in
>the
>> > > > identity element. That still has you hardcoding
an account, but it
>may
>> > be
>> > > > your only solution.
>> > > >
>> > > A better solution would be to access the DS from a
server type COM+
>> > application running with fixed identity.
>> > >
>> > > Willy.
>> > >
>> > >
>>
>
>
>.
>