newbie help - Active Directory Membership Provider

[SpaceMarine]

hello,

i am testing out forms-based authentication using the AD membership
provider. i have limited AD experience.

i have setup an AD connection street and AD membership provider in my
web.config. however, doing some simple tests in code-behind i cannot
validate user accounts like so:

Dim isValid As Boolean =
Membership.ValidateUser("(e-mail address removed)", "somePassword")
Response.Write("is valid user: " & isValid.ToString() & "<br/>")

....is there more to this than meets the eye? something i havent set
up?

my web.config:

<connectionStrings>
<add name="ADConnectionString" connectionString="LDAP://machineName/
OU=Our Org,DC=ourDomain,DC=com" />
</connectionStrings>

<membership defaultProvider="MembershipADProvider">
<providers>
<add
name="MembershipADProvider"
type="System.Web.Security.ActiveDirectoryMembershipProvider,
System.Web, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a"
connectionStringName="ADConnectionString"
connectionUsername="ourDomain\SomeAccount"
connectionPassword="somePassword"
enableSearchMethods="true" />
</providers>
</membership>


thanks!
sm

 

[SpaceMarine]

my web.config:

<connectionStrings>
        <add name="ADConnectionString" connectionString="LDAP://machineName/
OU=Our Org,DC=ourDomain,DC=com" />
</connectionStrings>

the only thing that immediately comes to my mind is that the
connection string is invalid. however, no errors are reported. if i
change the machineName to something else it throws an exception.

is there a good way for me to test the AD connection string? some
basic request i can render on screen?


thanks
sm

 

[Joe Kaplan]

I'm not sure about the troubleshooting procedures for the provider, but it
usually throws an exception if it isn't working properly.

Note that if you use the AD membership provider, there is no matching role
provider that works with that. Thus if you want to use the Windows token to
do validation, you must use an authentication mechanism that gets you a
Windows token. The AD membership provider is a forms auth implementation
and doesn't get a Windows token.

Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--

my web.config:

<connectionStrings>
<add name="ADConnectionString" connectionString="LDAP://machineName/
OU=Our Org,DC=ourDomain,DC=com" />
</connectionStrings>

the only thing that immediately comes to my mind is that the
connection string is invalid. however, no errors are reported. if i
change the machineName to something else it throws an exception.

is there a good way for me to test the AD connection string? some
basic request i can render on screen?


thanks
sm

 

[SpaceMarine]

Note that if you use the AD membership provider, there is no matching role
provider that works with that.

im not sure i understand -- it sounds like youre saying that if i
decide to use AD forms-based authentication, that i would be unable to
use *any* role provider? that cant be right. isnt the entire purpose
of abstract providers that it doesnt matter *which* provider is being
implemented? im expecting to be able to use the AD membership
provider, and a SQL role provider. (this makes sense, because while
the user-base is shared w/i an org, the roles are tailored & varied to
each particular application)

 Thus if you want to use the Windows token to
do validation, you must use an authentication mechanism that gets you a
Windows token.  The AD membership provider is a forms auth implementation
and doesn't get a Windows token.

im not sure yet which we will be using. if our app were for 100%
desktop users it would be simple. but i have to consider our VPN users
from remote, shared workstations -- those users may force a forms-
based authentication. if so, it would 100% have to authenticate
against an AD source since our org is very large and uses AD; i cant
be recreating every user in an app-specific database. roles yes, users
no.

this doesnt sound problematic does it?


thanks,
sm

 

[Joe Kaplan]

Basically, I was just trying to say that there is no role provider that
comes with ASP.NET that works with AD groups by default except for the
WindowsTokenRoleProvider, but that provider requires that you use
Windows/IIS for authentication instead of forms auth.

My co-author has an experimental LDAP-based role provider at codeplex (ADRP)
that works with the AD membership provider.

If you don't need the AD group for authorization, then you can use whatever
role provider you want.

I hope that clarifies what I was trying to say.

You can just use Basic authentication for the remote users combined with
SSL. There is no real need to use forms auth here. If you want to use
forms auth you can, but then you don't get the Windows token.

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--

Note that if you use the AD membership provider, there is no matching role
provider that works with that.

im not sure i understand -- it sounds like youre saying that if i
decide to use AD forms-based authentication, that i would be unable to
use *any* role provider? that cant be right. isnt the entire purpose
of abstract providers that it doesnt matter *which* provider is being
implemented? im expecting to be able to use the AD membership
provider, and a SQL role provider. (this makes sense, because while
the user-base is shared w/i an org, the roles are tailored & varied to
each particular application)

Thus if you want to use the Windows token to
do validation, you must use an authentication mechanism that gets you a
Windows token. The AD membership provider is a forms auth implementation
and doesn't get a Windows token.

im not sure yet which we will be using. if our app were for 100%
desktop users it would be simple. but i have to consider our VPN users
from remote, shared workstations -- those users may force a forms-
based authentication. if so, it would 100% have to authenticate
against an AD source since our org is very large and uses AD; i cant
be recreating every user in an app-specific database. roles yes, users
no.

this doesnt sound problematic does it?


thanks,
sm

 

[SpaceMarine]

Basically, I was just trying to say that there is no role provider that
comes with ASP.NET that works with AD groups by default except for the
WindowsTokenRoleProvider, but that provider requires that you use
Windows/IIS for authentication instead of forms auth.

...

If you don't need the AD group for authorization, then you can use whatever
role provider you want.

I hope that clarifies what I was trying to say.  

not sure yet! i guess what i'm trying to understand is whether one can
use *both* of these:

1) the user's AD group, which im getting automatically now from the
Integrated Windows Authentication's User object --
User.IsInRole("MyHighLevelGroup") -- as a rudimentary authororization
role. and then

2) another db-based membership provider, for my app-specific roles;
such as "ReadOnly", "SearchOnly", "FullAccess", etc..

...in this way I can do rudimentary filtering out based on AD group,
and perform more granular control w/i my app's custom roles, which i
can store in our app db.

make sense?


thanks,
sm

 

[SpaceMarine]

im not sure yet which we will be using. if our app were for 100%
desktop users it would be simple. but i have to consider our VPN users
from remote, shared workstations -- those users may force a forms-
based authentication. if so, it would 100% have to authenticate
against an AD source since our org is very large and uses AD; i cant
be recreating every user in an app-specific database. roles yes, users
no.

ok, after messing around some more i discovered using VPN is no
problem at all, and my web apps can continue to use Windows
authentication from the web.config. the server OS simply asks the
browser to popup a login box. after the user enters his credentials,
the app sees him as his Windows user.

no need for forms-based authentication. thweeet!


sm

thanks,
sm