Windows Authentication question

  • Thread starter Thread starter Natan
  • Start date Start date
N

Natan

Hi.

We are creating an intranet here in ASP.NET and we decided that we are
going to use a kind of Forms Authentication but using the users in our
windows domain.

So, we are creating a default login form, but the user will use the name
and password he uses to login to his computer.

I would like to know 2 things:

1. How can I get a list of Windows users in my domain, so that I can
list them for administration purposes.

2. After getting username and password from the user, how can I check it
against my domain users to see if I should grant him access?

thanks.
 
If you'll be authenticating against Windows accounts, is there any
particular reason you don't want to use Windows integrated authentication?
It tends to be quite a bit more convenient for both users and developers
and, in general, there's little reason to avoid it unless you must support
users without Windows accounts (in which case it's generally "polite" to
support mixed authentication schemes so that Windows users can still use the
more convenient login mechanism).
 
¤ Hi.
¤
¤ We are creating an intranet here in ASP.NET and we decided that we are
¤ going to use a kind of Forms Authentication but using the users in our
¤ windows domain.
¤
¤ So, we are creating a default login form, but the user will use the name
¤ and password he uses to login to his computer.
¤
¤ I would like to know 2 things:
¤
¤ 1. How can I get a list of Windows users in my domain, so that I can
¤ list them for administration purposes.
¤
¤ 2. After getting username and password from the user, how can I check it
¤ against my domain users to see if I should grant him access?

If you're using domain validation, Forms Authentication isn't really appropriate. Forms
Authentication is primarily designed for credential verification against a different source, such as
a database, where you have full control over the authentication process.

I'd recommend you stick with Basic or Integrated Windows if you're authenticating against the
domain.


Paul
~~~~
Microsoft MVP (Visual Basic)
 
Nicole said:
If you'll be authenticating against Windows accounts, is there any
particular reason you don't want to use Windows integrated authentication?
It tends to be quite a bit more convenient for both users and developers
and, in general, there's little reason to avoid it unless you must support
users without Windows accounts (in which case it's generally "polite" to
support mixed authentication schemes so that Windows users can still use the
more convenient login mechanism).
Click to expand...

I solved it using System.DirectoryServices. =)

About the reasons, first because we want the user to be able to login
with his username when there is no windows authentication, second, we
don't want an user to have access to our intranet just because a
computer is turned on.

Thanks...

BTW: answering a post just to ask why someone is doing that is annoying.
Comments are welcome, but answer the question first then make your comment.
 
Paul said:
If you're using domain validation, Forms Authentication isn't really appropriate. Forms
Authentication is primarily designed for credential verification against a different source, such as
a database, where you have full control over the authentication process.

I'd recommend you stick with Basic or Integrated Windows if you're authenticating against the
domain.
Click to expand...

Sorry, i said Forms Authentication just because i'm going to use an html
form to get the username and password, but i have no intention to use
the buggy FormsAuthentication.

BTW, problem solved. thanks.
 
About the reasons, first because we want the user to be able to login with
his username when there is no windows authentication,
Click to expand...

That's still possible even if you use integrated Windows authentication. If
the browser doesn't pass the correct credentials (either because it's
configured not to pass the client user credentials or because the client
user isn't acceptable to the server), the user will be presented with a
logon dialog by the browser. In addition, if you are concerned about
supporting non-Windows clients, you could enable multiple authentication
modes (e.g.: Windows integrated and basic) in IIS.

second, we don't want an user to have access to our intranet just because
a computer is turned on.
Click to expand...

A couple of problems here:

1. The user presumably already has at least some access to your file,
database, e-mail, print, etc. servers. Is intranet access somehow an even
worse risk than accessing these other resources?

2. Users will likely be able to instruct their browsers to cache their
credentials even when logging in via an HTML form, so you won't be gaining
any real protection by using a forms-based approach.
 
Nicole said:
That's still possible even if you use integrated Windows authentication. If
Click to expand...

Yes, but i don't want to use it. I want just to check username and
password against Active Directory user base. My fault to put "windows
authentication" in the subject.
1. The user presumably already has at least some access to your file,
database, e-mail, print, etc. servers. Is intranet access somehow an even
worse risk than accessing these other resources?
Yes.

2. Users will likely be able to instruct their browsers to cache their
credentials even when logging in via an HTML form, so you won't be gaining
any real protection by using a forms-based approach.
Click to expand...

Yes, i will.
 
There are other reasons for not using Windows Integrated Authentication...
For example it could be need of accessing remote resources (when you can't
use Kerberos or aren't allowed to setup delegation).

-Valery.
http://www.harper.no/valery
 
¤ Nicole Calinoiu wrote:
¤
¤ > That's still possible even if you use integrated Windows authentication. If
¤
¤ Yes, but i don't want to use it. I want just to check username and
¤ password against Active Directory user base. My fault to put "windows
¤ authentication" in the subject.
¤

Just remember that you will also need to consider password expiration (password change) and account
lockouts.


Paul
~~~~
Microsoft MVP (Visual Basic)
 
What he's suggesting is that using an LDAP bind with S.DS for your
application authentication has a number of problems associated with it. For
example, you don't have an easy way to deal with accounts that are expired
or disabled, passwords that are expired, passwords that much be changed at
next logon or locked user accounts. They all produce the exact same failure
as a bad user name/password.

These may not be an issue for you, but you should keep them in mind. S.DS
may not scale very well under heavy load as well, but you may not have those
kinds of issues either. Just another thing to keep in mind.

I'm also wondering why you are dismissing ASP.NET forms authentication in
favor of a proprietary implementation, but you seem to be bent on that
course as well.

Joe K.
 
Joe said:
What he's suggesting is that using an LDAP bind with S.DS for your
application authentication has a number of problems associated with it. For
example, you don't have an easy way to deal with accounts that are expired
or disabled, passwords that are expired, passwords that much be changed at
next logon or locked user accounts. They all produce the exact same failure
as a bad user name/password.

These may not be an issue for you, but you should keep them in mind. S.DS
may not scale very well under heavy load as well, but you may not have those
kinds of issues either. Just another thing to keep in mind.
Click to expand...

Thanks for the information. I am not against windows authentication, but
that is not what I need right now. What I need is simple: check if an
username and password match in the active directory, and that's all.
That's a requirement and I must follow now, and changing it to forms
authentication or windows authentication or any other authentication in
the future is very simple.
I'm also wondering why you are dismissing ASP.NET forms authentication in
favor of a proprietary implementation, but you seem to be bent on that
course as well.
Click to expand...

Up to now I had some problems with Login and Logout. In many cases I
must handle all the cookies and session manually because
FormsAuthentication class doesn't work right.

But i don't want to talk about it now. Let's close the topic, problem
solved.

thanks.
 
Back
Top