Re: ADAM - New users reading data - best practices
- From: "Joe Kaplan \(MVP - ADSI\)" <joseph.e.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sat, 27 May 2006 12:20:16 -0500
One thing worth pointing out is that in LDAP parlance, you don't really
"bind" to an object. You bind to the directory (or the connection to the
directory). You do searches and modification ops against objects in the
directory. ADSI and S.DS in .NET blur this distinction since they use an
object-based metaphor, but even they respect this. When you "bind" to an
object with ADSI, ADSI performs an LDAP bind operation on the LDAP
connection (assuming it hasn't already) and then does a base level search to
retrieve the object's attributes.
That said, you should be able to accomplish what you want. One thing to
consider is using the userPrincipalName as a unique identifier for your
users, as it can be used as a username for binding and doesn't require any
knowledge of of the directory structure for the user. If you carefully
enforce uniqueness, this should work well. You can then find the user via
their UPN if you need to read the user's attributes and should get an
unambiguous match.
The SELF security principal is a good thing to consider using for your
default ACLs in order to ensure that users have rights to read specific
attributes on their own objects. You might even consider creating a
property set to ACL these as a group. This will make management easier and
keep your ACLs smaller.
For common data that can be read by all users, consider using the
AUTHENTICATED USERS built-in security principal for your ACL entries. For
company-specific data, you would need to provision "per-company" groups and
use those groups to ACL the objects.
You also have the option of enforcing all the security in your busines logic
layer and using the "trusted subsystem" architecture to read data in the
directory, but that adds significant complexity to your code. In some
circumstances, the AD ACL model might not work for you, so that might be a
better option. However, from what you've described, it doesn't sound like
that will be a limiting factor, so I'd suggest the delegated approach that
you have been describing where ADAM enforces the security and the user's
security context is used for connecting to the directory.
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
--
"Adam" <adamtuliper@xxxxxxxxxxxxx> wrote in message
news:11158468-4A16-4D54-A1BB-B40877DCC282@xxxxxxxxxxxxxxxx
Sure, we host thousands of companies. Each company gets their own OU. A
user
is under that OU. For validation, a user is binding to their own dn. In
the
case of application error where it maps to the wrong dn, a user should not
be
able to read another user's data. However, all user's will need to share
read
access to a common section of data on another branch.
--
Adam Tuliper
http://www.secure-coding.com
"Al Mulnick" wrote:
This interests me.
Can you give the scenario that you would use such a setup for? Granting
access to a user to objects under that container? Would the same idea be
valid if the OU were something you custom created?
Al
"Adam" <adamtuliper@xxxxxxxxxxxxx> wrote in message
news:C71D04D7-BAD6-416F-9278-EBBA2AE9448F@xxxxxxxxxxxxxxxx
Trying to piece together some ADAM security here.
If you create a new user and this user should have access to read their
own
attributesa (possibly update only certain attributes) and anything
under
say... something like cn=CustomRoles, whats the best way to make sure
they
can bind, and not see other user's data but also see the custom roles?
Can
an
"Everyone" acl be set on the CustomRoles, and then the user would need
certain control on some of their attributes at their own dn?
--
Adam Tuliper
http://www.secure-coding.com
.
- Follow-Ups:
- References:
- Re: ADAM - New users reading data - best practices
- From: Al Mulnick
- Re: ADAM - New users reading data - best practices
- Prev by Date: Re: convert sha1 pwd hash to use with userpwd/unicodePwd
- Next by Date: Re: Cannot join domain.
- Previous by thread: Re: ADAM - New users reading data - best practices
- Next by thread: Re: ADAM - New users reading data - best practices
- Index(es):
Relevant Pages
|