Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / Security / June 2004

Tip: Looking for answers? Try searching our database.

Authenticate Against localhost and AD

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Michał Januszczyk - 28 Jun 2004 12:30 GMT
Hello.

I've got the following problem:

There is a web application (ASP.NET), that needs to
authenticate users against local machine and Active Directory.
By default, the application works as ASPNET account (Win2000, XP).
When working on ASPNET account the apllication is able to do the following:

    string path = "WinNT://" + Environment.MachineName + ",computer";
    DirectoryEntry entry = new DirectoryEntry(path, username, pwd);
    try
    {
    //force authentication
    Object o = entry.NativeGuid;

    //authentication succeeded

    }
    catch(...)
    {
    //authentication failed
    }

Wnen run as ASPNET account, the code is able to work correctly.
However, when run as SYSTEM account, exception is thrown

I need to switch to system account, because I also need to authenticate
users in Acitive Directory, and ASPNET this time cannnot connect to AD,
whereas SYSTEM account can.

So, currently I can authenticate users either in local system (when run as
ASPNET) or in AD (when run as SYSTEM), bot not concurrently (i.e.
I can not do this without restarting the process)

                SYSTEM     ASPNET
LOCAL USERS      -           +
DOMAIN USES      +           -

Questions:
1. Is there any way to grant local ASPNET account ability to connect to AD ?
2. Is there any way to allow SYSTEM account to authenticate users against
  local machine. (The inability seems ridiculous...)
  (Note: I cannot temporarily use impersonation [SYSTEM is granted right to
   impersonate someone elese] to check credentials, since the application is
   a muliti user system and the fraction of time the app would work as somebody
   else (not system but e.g John.Smith ) would leed to errors. Ok, I might
   lock entire application functionality when somebody performs logon
   but this would be hugely ineffective and would require to redesign
   plenty of code. (The application is pretty complex))

Thanks for help
Michał
Joe Kaplan \(MVP - ADSI\) - 28 Jun 2004 15:21 GMT
A couple of things:

ASPNET can definitely talking to Active Directory.  However, you may need to
supply a domain controller name in your LDAP path as well as valid domain
credentials depending on what you are binding to.  If you just want to test
user names and passwords via a DirectoryEntry bind, this will work fine.
Make sure you use the LDAP provider though.

For authenticating against local machine accounts, the WinNT provider is not
well suited for this as it has all sorts of problems binding with different
credentials in the same process.  It would probably be better to call the
LogonUser API to test the user's credentials (although you'll need high
privileges to call this API in Win2K).  LogonUser can also validate domain
credentials.

Instead of doing this authentication in code, is it possible for you to
leverage IIS security to do this work for you?

Joe K.

"Michal Januszczyk" <MichaJanuszczyk@discussions.microsoft.com> wrote in
message news:C10D63AA-6F9B-471A-AB7B-65B2EDF8EB55@microsoft.com...
> Hello.
>
[quoted text clipped - 49 lines]
> Thanks for help
> Michal
Michał Januszczyk - 28 Jun 2004 16:05 GMT
"Joe Kaplan (MVP - ADSI)" wrote:
> ASPNET can definitely talking to Active Directory.  However, you may need to
> supply a domain controller name in your LDAP path as well as valid domain
> credentials depending on what you are binding to.  If you just want to test
> 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;
try
{
    // 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 ?

> For authenticating against local machine accounts, the WinNT provider is not
> well suited for this as it has all sorts of problems binding with different
> credentials in the same process.  It would probably be better to call the
> LogonUser API to test the user's credentials (although you'll need high
> privileges to call this API in Win2K).  LogonUser can also validate domain
> 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)

> 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.

Thank You
Michał
Joe Kaplan \(MVP - ADSI\) - 28 Jun 2004 17:18 GMT
Inline:

"Michal Januszczyk" <MichaJanuszczyk@discussions.microsoft.com> wrote in
message news:E3B5F91A-D5E6-43FB-B89A-4B24ECFFB738@microsoft.com...
> "Joe Kaplan (MVP - ADSI)" wrote:
> > ASPNET can definitely talking to Active Directory.  However, you may need to
[quoted text clipped - 16 lines]
>
> 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 not
> > well suited for this as it has all sorts of problems binding with different
[quoted text clipped - 4 lines]
>
> 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?
[quoted text clipped - 4 lines]
> 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
> Michal

HTH,

Joe K.

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.