ActiveDirectory authentication - more issues

[David Thielen]

Hi;

Ok, I have ActiveDirectory authentication working but have a couple of issues:
1) My username must be (e-mail address removed) - it does not take windward\dave
- why?
2) The authentication type is shown as forms - shouldn't it be NTLM?
3) Since I'm running from a computer on the domain and using IE, shouldn't
it handle this automatically?
4) I do not get a WindowsIdentity but instead a FormsIdentity. I need a
WindowsIdentity so I can do impersonation. How do I get that?
5) Context.User.IsInRole() returns false for groups I am a member of such as
"windward\\Domain Users" - why?

 

[Joe Kaplan \(MVP - ADSI\)]

I'm confused. Why do you want to use the AD membership provider if you
don't want forms authentication? It sounds like you just want Windows
authentication and this whole saga with the AD membership provider has been
a naught.

I still don't know why IsInRole wasn't working for you though. Dominick and
I both tried it and got the same results (the ones I expected).

Joe K.

 

[Dominick Baier [DevelopMentor]]

hi,

ok...

1) this can be mapped in web.config - both formats are supported. See in
visual studio help for all varations

e.g, attributeMapUsername="SAMAccountName"

uses only the username without domain

2) no -you are doing forms authentication. NTLM would be IIS authentication
and <authentication mode="Windows" /> would be set. Then you cannot use the
membership providers

3) no - see 2

4) see 2. You could maybe use Protocol Transition (only for domain accounts,
only on w2k3, only in w2k3 domains) to get a token or use the Win32 LogonUser
API (needs to store the password on the server - not recommended).

5) still no idea

have you ordered the book already?

 

[David Thielen]

Hi;

Ok, maybe I don't understand how we have to divide this up. We are creating
a commercial portal that we will ship to numerous customers. I was dividing
these customers into three categories:

1) All users in Active Directory, all users logged in to domain, all users
use IE - windows authentication.
2) All users in Active Directory, some users not logged in to domain and/or
some users do not use IE - Active Directory authentication.
3) Some/all users not in Active Directory - SqlExpress ASP forms
authentication.

But I had assumed that for category (2) above I could get their domain
credentials on the server side as the server does have their username &
password in order to authenticate them.

Am I off here somehow?????

 

[Joe Kaplan \(MVP - ADSI\)]

For 2), you can still use IWA. The users will get prompted for credentials.
They will need a browser that supports IWA though. You can also use Basic
authentication with SSL if you need to be firewall-friendly. Basic works
with any browser as well.

The advantage to all of these is that you are using built in features in
IIS, so this is all driven by configuration.

If this were my app and I was trying to make it flexible, I'd try to give
the customers the flexibilty to use the auth that works for them. Try to
make this as configuration-driven as possible and give them some scenarios
on how to make different approaches work.

Concentrate on making sure that the security context your app needs on the
back end is flexible and can be created through a variety of different
mechanisms. For example, if you just need a user name, you really just need
an IPrincipal/IIdentity in Context.User and you are all set. The customers
can configure that however they want. If you need roles, concentrating on
IPrincipal is still good. You might also look at the different role
provider options for membership.

Joe K.

 

[David Thielen]

The book arrived today (Amazon) - that's how I got the rest of it working.

--
thanks - dave
david_at_windward_dot_net
http://www.windwardreports.com

 

[Dominick Baier [DevelopMentor]]

ah - reading helps - good to know that some things stay true

 

[David Thielen]

Hi;

I believe you that it works this way. But I am curious as to why for this
one use case.

User is prompted (forms) for username & password. username/password are
authenticated via ActiveDirectory and IsInRole hits ActiveDirectory. This
means the user's username/password in ActiveDirectory were passed to AD and
verified in AD.

Why can't it at that point create a WindowsPrincipal/Identity? It has the
user and has authenticated them. It seems to me that it would be legit at
that point to issue the credentials. And this would then handle the case of a
domain user using firefox or oasis.

--
thanks - dave
david_at_windward_dot_net
http://www.windwardreports.com

 

[Dominick Baier [DevelopMentor]]

Because it is using a different protocol - as simple as that.

Only IWA results in a WindowsIdentity. FormsAuthentication results in a FormsIdentity.

In the case of the AD Provider, LDAP is used to verify credentials - IsInRole
does NOT hit the Active Directory - the roles are empty by default with the
AD provider - you have to stack a role provider on top of that - there is
no AD role provider - so often a combination for AD membership and AzMan
roles is used.

To create a WindowsIdentity you have to create a token - you could do that
yourself - you have username/password - but this has to be done on every
single request - so you would have to cache/store the credentials of the
user on the web server - nothing i would recommend.

so to cut a long story short -

you want an automatically generated WindowsIdentity - use IIS authentication
for all other auth methods you get a Forms/Generic Identity.

 

[David Thielen]

ok - thanks

--
thanks - dave
david_at_windward_dot_net
http://www.windwardreports.com