Re: ADAM Permission Questions (Hiding the Existence of Objects)
- From: "Joe Richards [MVP]" <humorexpress@xxxxxxxxxxx>
- Date: Fri, 19 May 2006 10:50:02 -0400
Yeah he can try to ACL attribute definitions in the schema but who knows what that would break. I wouldn't trust anything using ADSI or other higher level APIs (anything ADSI or .NET and possibly not the JAVA stuff either) to not have issues.
Knowing the existence of an attribute isn't a security risk unless someone is silly in the naming of the attribute and gives out information in the actual attribute name itself.
Also I would try to design the security so it doesn't need the confidential flag. That is a hack put into place to help with the poor default ACLing in Active Directory, ADAM really shouldn't need it too awfully much if security is being done well. Nothing says you have to give out the reader role, build your own roles and specify explicitely what to allow people to see.
I completely agree with Lee on the LO stuff... The common scenario for that seems to be when folks are hosting multiple companies and don't want the other companies to be aware of it.
--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net
---O'Reilly Active Directory Third Edition now available---
http://www.joeware.net/win/ad3e.htm
Lee Flight wrote:
Hi.
if I understand the first requirement you want to hide the
attributeSchema object in the schema? Schema has Authenticated
Users Read inherit, I'm not sure how supported hiding schema
objects is...
on the hiding objects in a naming context you can use List object mode
as Christoffer points out which will do what you want but, in addition to a
performance overhead, LO can be a real pain to manage due to the
absence of inheritance and the fine-grained permission management.
Lee Flight
"Jeffrey Harris" <1Jeffrey1.1Harris1@xxxxxxxxxxxxxxxx> wrote in message news:A99F9C68-CF09-4A33-BD76-4AC1D9324179@xxxxxxxxxxxxxxxxI want to restrict access to OUs and attributes in ADAM; specifically, I want
to hide them in the directory.
I know how to configure restrictions on attributes in the Application
Directory using the searchflag confidentiality bit, but is there a way to
hide an attribute in the schema partition itself? I can restrict access to
the attribute configuration in the schema partition by placing access
controls on the attribute object itself, but I cannot determine how to
actually hide the existence of the attribute itself (in our environment,
these are application specific attributes which only a bind account for the
application should be accessing, so we do not want different application bind
accounts to be able to see these attributes). If attributes can be hidden
this way, will the inability of an account to see an attribute in the schema
cause problems accessing user objects in the directory, even if those same
accounts are prevented from accessing the values of the attributes by the
confidentiality bit?
Similarly, is there a way to hide specific objects in the directory tree
under a common leaf object without hiding all of them? If we have:
OU1 ---
OUa
OUb
OUc
Is there a way to hide the existence of OUa and OUb from a specific account
or group without hiding the existence of all of them by placing an access
control on OU1? We want a specific account to be able to see OU1 and OUc in
the directory tree, without seeing OUa and OUb. If we put the access control
on OU1, then the account cannot see OUc without changing the base dn to
OU=OUc. If we put the access controls on OUa and OUb, then the account can
still see that OUa and OUb exist.
Thanks.
--
Jeffrey Harris, MCSE W2K.
Please remove the '1's from the e-mail address before sending.
- References:
- Re: ADAM Permission Questions (Hiding the Existence of Objects)
- From: Lee Flight
- Re: ADAM Permission Questions (Hiding the Existence of Objects)
- Prev by Date: Re: Deny Domain Admins adding computers
- Next by Date: Re: ADAM Schema Update
- Previous by thread: Re: ADAM Permission Questions (Hiding the Existence of Objects)
- Next by thread: Re: Group Policy linked to Sites
- Index(es):
Relevant Pages
|
