Hi,

I started off yesterday with what seemed like a simple requirement - for an
intranet ASP.Net (2.0) application using Windows authentication, use Active
Directory to get the Full Name and Email address for the logged in user.
This was my first time I'd looked into AD, having not needed to access it
before and our network is managed by a separate department - so was learning
from ground up.

In the end I got a prototype working, but it required a valid NT user name
password to be stored either in the code (to be passed into
DirectoryEntry()) or in web.config for impersonatation. Whilst the relevant
section of the web.config could be encrypted, I don't believe it's an ideal
solution, if only because our passwords change every 'n' days (SBOX
requirement). I read something about anonymous access for DirectoryEntry(),
however it would appear that our AD has not been configured to allow this,
nor can I get that changed. Googling on the web, I see this to be a fairly
common issue - however the solution (or workaround) of storing user details
in web.config just isn't workable for us.

I have another solution in my head, but it feels slightly over-engineered.
As my AD exposure is very limited, I was wondering what other people think
or if they've found another solution. Basically I'm thinking I could create
a windows service that ran under the NETWORK user, which handled calls to
AD. This windows service could be accessed by the website, using .Net
Remoting. This way, the NT user details are not being stored anywhere that
is not secure (i.e. website details in IIS admin and web service in relevant
MMC service property). If the NETWORK user does not have enough rights, I
believe I'll be able to release the windows service to our dept that managed
AD - they could install it onto a single server running under one of the
service accounts (which is not subject to the password change policy). What
do people think, does this seem like a workable solution, is there something
similar freely available?

Regards,

- Paul Hadfield.

You generally don't need to create a separate Windows service or COM+
component running under a different identity to do this. Generally, your
IIS 6 app pool will be running under the Network Service account and that
account will use the machine account when accessing the network. If the
machine is a domain member, it should be able to authenticate to AD and will
generally have permissions to query the directory to see the attributes you
want. To use the process account, you need to ensure you are NOT
impersonating. Note that you may need to give your DirectoryEntry
constructor a domain hint in the LDAP path like this:

LDAP://domain.com/rootDSE

instead of LDAP://rootDSE

It is also possible to impersonate the authenticated user and delegate their
credentials to AD to perform the query, but that generally requires you to
configure Kerberos delegation. This isn't on by default.

I wrote a whole chapter in my book (ch 8, see link in signature) that
discusses the various security aspects of doing LDAP programming, especially
in web apps, if you are curious.

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"Paul Hadfield" <nonone (AT) noone (DOT) com> wrote

You generally don't need to create a separate Windows service or COM+
component running under a different identity to do this. Generally, your
IIS 6 app pool will be running under the Network Service account and that
account will use the machine account when accessing the network. If the
machine is a domain member, it should be able to authenticate to AD and will
generally have permissions to query the directory to see the attributes you
want. To use the process account, you need to ensure you are NOT
impersonating. Note that you may need to give your DirectoryEntry
constructor a domain hint in the LDAP path like this:

LDAP://domain.com/rootDSE

instead of LDAP://rootDSE

It is also possible to impersonate the authenticated user and delegate their
credentials to AD to perform the query, but that generally requires you to
configure Kerberos delegation. This isn't on by default.

I wrote a whole chapter in my book (ch 8, see link in signature) that
discusses the various security aspects of doing LDAP programming, especially
in web apps, if you are curious.

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"Paul Hadfield" <nonone (AT) noone (DOT) com> wrote