Securing new attributes for user objects

  • Thread starter Thread starter Scott Marquardt
  • Start date Start date
S

Scott Marquardt

We're wanting to extend the schema (no problem there) and I need to secure
the attribute at issue. Darned if I can find how to secure just one
attribute. Where did I miss this in the documentation?
 
wasREMOVEket5 said:
We're wanting to extend the schema (no problem there) and I need to secure
the attribute at issue. Darned if I can find how to secure just one
attribute. Where did I miss this in the documentation?
Click to expand...
You could do that with ADSIEdit by modifying the special permissions in
the DACL for the specific class in the Schema partition.

HTH
--
Cheers,
Marin Marinov
MCT,MCSE 2003,MCSE:Security 2003
-
This posting is provided "AS IS" with no warranties, and confers no
rights.
 
Modifying defaultSD in the schema will only affect newly created objects.
You should also tweak inheritable aces at the top of the domain hierarchy.
Securing selected attributes is tough. Download the ad delegation
whitepaper -- your problem is considered there. If you are running w2k,
beware of ACE explosion, when a single ACE may explode into several hundred
property-specific aces.

--
Dmitri Gavrilov
SDE, Active Directory Core

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
 
Dmitri Gavrilov [MSFT] opined thusly on May 5:
Modifying defaultSD in the schema will only affect newly created objects.
Click to expand...

Dang. That explains why, despite removing Authenticated Users just now (and
adding the group that'll be administering this attribute), the value in an
existing object's attribute is readable to everyone; no implicit deny.
You should also tweak inheritable aces at the top of the domain hierarchy.
Click to expand...

Good grief, how? For a single attribute?
Securing selected attributes is tough. Download the ad delegation
whitepaper -- your problem is considered there. If you are running w2k,
beware of ACE explosion, when a single ACE may explode into several hundred
property-specific aces.
Click to expand...

No delegation whites I found consider this. And yeah, I hear you on the
explosion issue. I've been fragged by that before.

Aside from still not being sure how to change the ACE of existing users,
then, for this attribute (I decided to use employeenumber, BTW, rather than
adding a new attribute; I tacked employeenumber on to Person) I'm also
wondering what properties I should enable for this attribute (indexing and
the like). Are you aware of any documentation on these properties?

Another thing I'm wondering (this never ends) is how to get the attribute
to show up as a usable column when searching the directory. I'd assume this
is related to indexing.

Thank you for your reply.
 
Scott Marquardt said:
Dmitri Gavrilov [MSFT] opined thusly on May 5:
Modifying defaultSD in the schema will only affect newly created
Click to expand...
objects.

Dang. That explains why, despite removing Authenticated Users just now (and
adding the group that'll be administering this attribute), the value in an
existing object's attribute is readable to everyone; no implicit deny.
You should also tweak inheritable aces at the top of the domain
Click to expand...
hierarchy.

Good grief, how? For a single attribute?
Securing selected attributes is tough. Download the ad delegation
whitepaper -- your problem is considered there. If you are running w2k,
beware of ACE explosion, when a single ACE may explode into several hundred
property-specific aces.
Click to expand...

No delegation whites I found consider this. And yeah, I hear you on the
explosion issue. I've been fragged by that before.
Click to expand...

Scott,

The book Inside Active Directory: A System Administrator's Guide by Sakari
Kouti, Mika Seitsonen explains how to configure permissions on single
attributes.
 
Inline...

--
Dmitri Gavrilov
SDE, Active Directory Core

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Scott Marquardt said:
Dmitri Gavrilov [MSFT] opined thusly on May 5:
Modifying defaultSD in the schema will only affect newly created
Click to expand...
objects.

Dang. That explains why, despite removing Authenticated Users just now (and
adding the group that'll be administering this attribute), the value in an
existing object's attribute is readable to everyone; no implicit deny.
You should also tweak inheritable aces at the top of the domain
Click to expand...
hierarchy.

Good grief, how? For a single attribute?
Securing selected attributes is tough. Download the ad delegation
whitepaper -- your problem is considered there. If you are running w2k,
beware of ACE explosion, when a single ACE may explode into several hundred
property-specific aces.
Click to expand...

No delegation whites I found consider this. And yeah, I hear you on the
explosion issue. I've been fragged by that before.
Click to expand...

Did you check the newly published (well, couple of months old) AD delegation
whitepaper? I am pretty sure they discuss it there.
Aside from still not being sure how to change the ACE of existing users,
then, for this attribute (I decided to use employeenumber, BTW, rather than
adding a new attribute; I tacked employeenumber on to Person) I'm also
wondering what properties I should enable for this attribute (indexing and
the like). Are you aware of any documentation on these properties?
Click to expand...

If you are planning to search using this attribute, then make it indexed.
Just like you'd do for a SQL table.
Another thing I'm wondering (this never ends) is how to get the attribute
to show up as a usable column when searching the directory. I'd assume this
is related to indexing.
Click to expand...

I do not believe it is related to indexing. But I am pretty sure it is
related to display specifiers and attribute filtering that is done by the
UI. Try searching the KB, if you don't find anything, let me know and I will
dig something up for you.
 
<snip>
Agreed, I must have misunderstood the question. Thanks for elaborating
further on this topic, Dmitri.

---
Cheers,
Marin Marinov
MCT,MCSE 2003,MCSE:Security 2003
-
This posting is provided "AS IS" with no warranties, and confers no
rights.
 
Dmitri Gavrilov [MSFT] opined thusly on May 5:
Modifying defaultSD in the schema will only affect newly created objects.
You should also tweak inheritable aces at the top of the domain hierarchy.
Securing selected attributes is tough. Download the ad delegation
whitepaper -- your problem is considered there.
Click to expand...

Danged if I'm having a hard time finding it. Is this it?

http://snipurl.com/677w
http://snipurl.com/6785

If so, the method for what I'm doing must be inferred from the material.
Looks like I have some studyin' to do. ;-)
 
Aha, that's the one. Rather large paper...

--
Dmitri Gavrilov
SDE, Active Directory Core

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Scott Marquardt said:
Dmitri Gavrilov [MSFT] opined thusly on May 5:
Modifying defaultSD in the schema will only affect newly created objects.
You should also tweak inheritable aces at the top of the domain hierarchy.
Securing selected attributes is tough. Download the ad delegation
whitepaper -- your problem is considered there.
Click to expand...

Danged if I'm having a hard time finding it. Is this it?

http://snipurl.com/677w
http://snipurl.com/6785

If so, the method for what I'm doing must be inferred from the material.
Looks like I have some studyin' to do. ;-)

--

Scott

Almost summer! http://snipurl.com/trebuchet
Click to expand...
 
Back
Top