Re: Authenticate Against localhost and AD
From: Joe Kaplan \(MVP - ADSI\) (joseph.e.kaplan_at_removethis.accenture.com)
Date: Mon, 28 Jun 2004 11:18:25 -0500
"Michal Januszczyk" <MichaJanuszczyk@discussions.microsoft.com> wrote in
> "Joe Kaplan (MVP - ADSI)" wrote:
> > ASPNET can definitely talking to Active Directory. However, you may
> > supply a domain controller name in your LDAP path as well as valid
> > credentials depending on what you are binding to. If you just want to
> > user names and passwords via a DirectoryEntry bind, this will work fine.
> > Make sure you use the LDAP provider though.
> currently i'm using the following code to talk to DC:
> string path = @"LDAP://CN=Users,DC=mydomain,DC=com";
> DirectoryEntry entry = new DirectoryEntry(path, domainAndUsername, pwd);
> DirectorySearcher search =null;
> // Bind to the native AdsObject to force authentication.
> Object obj = entry.NativeObject;
> What can I change here to make ASPNET account to connect (and talk) to AD
Just add the domain controller dns name to your LDAP path:
LDAP://yourdc.domain.com/rootDSE (or whatever DN you wish to use)
Also, you should ALWAYS specify AuthenticationTypes.Secure when specifying
credentials to ensure that they are not sent in clear text on the network.
Additionally, you may wish to add AuthenticationTypes.ServerBind if you
specify a specific DC name as that will give you a small performance boost.
> > For authenticating against local machine accounts, the WinNT provider is
> > well suited for this as it has all sorts of problems binding with
> > credentials in the same process. It would probably be better to call
> > LogonUser API to test the user's credentials (although you'll need high
> > privileges to call this API in Win2K). LogonUser can also validate
> > credentials.
> I cannot use LogonUser function since this would make the whole
application working as another user for fraction of time. If the application
would require to do something that the "curret account" cannot do, there
would be an error. This is quite low probable, but may happen. I might use
locking here, but i would have to enforce locking in many places in the
application (the app stimultaneously serves many users)
Actually, you can use LogonUser here in the same way that you are
authenticating to AD with a DirectoryEntry object. LogonUser will succeed
if the user's credentials are accepted in a similar way to the
DirectoryEntry bind. Whether or not you impersonate the returned token is
up to you, but it can definitely be used as an authentication mechanism.
I don't understand your comment about having the code running as a different
user and having to use locking and such as you would be using LogonUser here
as a replacement for the S.DS code. What is the difference in your mind?
> > Instead of doing this authentication in code, is it possible for you to
> > leverage IIS security to do this work for you?
> I can not do that since I'm using forms authentication.
> The application allows to use application-specific accounts
> (if somebody does not want to use windows accounts), local machine
> windows accounts (authentication code example has been provided),
> and domain-wide accounts, if the machine is conected into domain.
Understand this part. I figured you were using forms authentication, but I
thought I'd throw that out. I am often confused as to why people use Forms
authentication and make their lives so much harder when regular IIS
authentication might work fine. However, sometimes people have to use Forms
auth. for whatever reason.
> Thank You