Windows Authentication question

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.

Nicole
Thu Mar 24 08:24:38 CST 2005

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


"Natan" <nvivo.misc@mandic.com.br> wrote in message
news:eMfLBcHMFHA.2468@tk2msftngp13.phx.gbl...
> 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.

Paul
Thu Mar 24 08:34:46 CST 2005

On Thu, 24 Mar 2005 10:42:56 -0300, Natan <nvivo.misc@mandic.com.br> wrote:

¤ 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)

Natan
Thu Mar 24 08:46:41 CST 2005

Nicole Calinoiu wrote:
> 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).

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.

Natan
Thu Mar 24 08:49:23 CST 2005

Paul Clement wrote:

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

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.

Nicole
Thu Mar 24 09:13:19 CST 2005

"Natan" <nvivo.misc@mandic.com.br> wrote in message
news:uA3vo$HMFHA.3960@TK2MSFTNGP12.phx.gbl...
<snip>
> About the reasons, first because we want the user to be able to login with
> his username when there is no windows authentication,

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.

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.


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

Natan
Thu Mar 24 09:24:32 CST 2005

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.

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

Yes, i will.

Valery
Thu Mar 24 11:03:18 CST 2005

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

Paul
Thu Mar 24 12:17:23 CST 2005

On Thu, 24 Mar 2005 12:24:32 -0300, Natan <nvivo.misc@mandic.com.br> wrote:

¤ 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)

Natan
Thu Mar 24 14:01:44 CST 2005

Paul Clement wrote:

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

??????????

Joe
Thu Mar 24 15:04:33 CST 2005

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.

"Natan" <nvivo.misc@mandic.com.br> wrote in message
news:u3BorvKMFHA.3196@TK2MSFTNGP10.phx.gbl...
> Paul Clement wrote:
>
>> Just remember that you will also need to consider password expiration
>> (password change) and account
>> lockouts.
>
> ??????????

Natan
Mon Mar 28 11:16:40 CST 2005

Joe Kaplan (MVP - ADSI) wrote:
> 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.

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.

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.