Re: LDAP Authentication for Single Sign On
- From: "Lee Flight" <lef@xxxxxxxxxxxxxxx>
- Date: Thu, 22 Mar 2007 12:30:48 -0000
Who Am I control is not is W2K3 SP2.
On access control, as Joe knows, ADAM is in a much better position as the
the Readers
role that is an inherited ACL in the tree is empty by default. To kick-off
projects folks
often nest the ADAM Users Role or windows domain principal Authenticated
Users into
the Readers role. Later they start to worry about security, what I usually
recommend is
to create an ad hoc role for the ADAM instance and add the account that is
being used
for the directory search to that role and then add an inherited ACL for that
role at the
appropriate point in the tree allow read to the set of properties that need
to be exposed to
that role. Using DSACLs to do this it's fairly straightforward to restrict
access for a Role to
a specific object class and/or attributes (of those classes) in the tree.
Lee Flight
"Joe Kaplan" <joseph.e.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:O$qkWC$aHHA.596@xxxxxxxxxxxxxxxxxxxxxxx
Speaking of Who Am I control, it will be in Windows Server soon. I know
it is in Longhorn. I'm not sure if it sneaks in with SP2 of 2003 server.
It is already in ADAM SP1.
Regarding the access control stuff, it is in there, but it is hard to use.
I think the main problem in AD is that by default, everyone has read
access to most stuff, so you end up having to remove this access first in
order to be able to apply more granular permissions, but then you run the
risk of breaking lots of stuff that assumed this access, so it is a hard
lever to pull. It can be done though.
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
--
"Michael Ströder" <michael@xxxxxxxxxxxx> wrote in message
news:5ca8d4-ju.ln1@xxxxxxxxxxxxxxxxxxx
Joe Kaplan wrote:
If the users would just type in their DN, then the search wouldn't be
necessary. :)
Yes.
It is a laziness
issue. Alternately, one might argue that the spec has usability issues.
SASL Bind is different though. A LDAP server maps the SASL user name to
a LDAP entry (bind DN for authorization). The application can then find
out with the "Who Am I?" extended operation which authz DN is in effect.
Well, the LDAP server has to support this off course.
BTW: Most Windows users even don't type in their login domain. So they
are not aware of the UPN either => there is also some magic needed to
map the user name to an AD account...
Of course, the DN makes a lousy log on name, so these types of solutions
become necessary, but I actually do think it is unfortunate because it
requires a service account and some app having fixed credentials.
It wouldn't that bad if AD would provide a more fine-grained access
control which attributes are readable by such a service account.
Ciao, Michael.
.
- References:
- Re: LDAP Authentication for Single Sign On
- From: Joe Kaplan
- Re: LDAP Authentication for Single Sign On
- From: Jeremy Revitch
- Re: LDAP Authentication for Single Sign On
- From: Joe Kaplan
- Re: LDAP Authentication for Single Sign On
- From: Michael Ströder
- Re: LDAP Authentication for Single Sign On
- From: Joe Kaplan
- Re: LDAP Authentication for Single Sign On
- From: Michael Ströder
- Re: LDAP Authentication for Single Sign On
- From: Joe Kaplan
- Re: LDAP Authentication for Single Sign On
- Prev by Date: Re: Security logging ldap Authentication in Active Directory
- Next by Date: Re: Blackberry SendAs Permissions
- Previous by thread: Re: LDAP Authentication for Single Sign On
- Next by thread: Re: LDAP Authentication for Single Sign On
- Index(es):
Relevant Pages
|
