Good good, that is what I like to hear. :o) You will want to buy copies
for all your friends too. :o)
The chapter may have been clear but it is was off on its examples as it
didn't take into account inherited and explicit ACEs. That radically changes
whether a delegation (or a denied delegation) will work or not. It still
isn't perfect, but IMO, much better. It is a balance of time vs what needs
to be done.
The example you give is one of the harder things to clean up and no, I
personally don't think it should be this hard, but then that is just my
opinion. One thing to remember about Exchange, is that some of its access
rights for reading attributes can be through Auth Users rights, especially
on GCs in a multi-domain environment, I have been bitten by this in the past
myself. Consider that permissions are granted to the Exchange Enterprise
Servers group which is a domain local group so reading on a GC in another
domain would be impacted unless there is some other access mechanism. An
alternative would be to convert those DLGs to UGs as previously mentioned by
Guido, again, MS PSS may have an issue with it so keep that in mind.
The easiest way to handle this is to use the new confidentiality bit
capability in SP1. The Exchange attributes shouldn't be Cat 1 attributes
(systemflags & 16 on their schema definition) so you should be able to lock
them up that way. However, you will want to regrant access back to Exchange.
Unfortunately, I am not aware of any tools MS has given to allow a good
granular way to grant access BACK to this attribute after it is locked down.
You will need to grant a CA to the attribute for the Exchange Servers global
group in each domain (or grant to the DLGs but convert to UGs) so you
maintain read across GCs in each domain. This will have to be done with
script because you can't do it via dsacls or the GUI. Also once set, the GUI
will have no clue how to display the permission so won't, DSACLS will
properly display it.
A word of note is that if you have MS Exchange PSS look at your AD, they
will probably have a small stroke if they figure out this was done as they
get testy when you muck with the visibility of Exchange attributes. However,
have the Exchange guy talk to a knowledgable AD PSS guy and things should
hopefully be ok though expect to hear lots of grumbles of unsupported. This
goes for any solution that does anything to any Exchange attribute. Oh one
further note, anyone who has full control or all control access rights to a
given object will still be able to see the attribute. The obvious one is
full control... Full control is... Well full control. You can't effectively
deny someone access to something they have full control to. The all control
access rights is a new one though that you have to watch out for.
If the confidential bit isn't an option. You are in for some fun. The fact
that it is auth users makes things very difficult because everyone that
accesses it is an auth user so you can't just actively deny auth users
access or else you impact admins and Exchange and everything else. You need
1. Invoke a passive deny which means stripping any (explicit or inherited)
access permissions granted and regrant the access permissions to Exchange
and any anyone else that needs access. It depends here how the access is
granted in the first place on what you need to do.
2. Remove any explicit grants and then set up inherited denies for auth
users and then explicit grants for Exchange and any other specific groups
that need access. The explicit grants will override the inherited denies.
For both of these, if the grant is handled through a property set, then you
can remove the attribute from the property set (and maybe some others
related to exchange you don't to be fully visable to everyone) and add them
to a different property set and only grant that to exchange and the admins
or whomever else it is that needs to see the info.
Overall, before I started doing anything with any of this I would really
look at everything and get a great overall plan for security. You need to
understand what it is exactly you want and all of the ways things are
currently delegated, it isn't unusual to find that there are multiple paths
someone has access to something in the directory (i.e. multiple ACEs).
I would love to see MS step up with a lockdown guide for AD and especially
for Exchange which included such things and removing all of the prop sets
that get stuffed into the pre-existing prop sets and placed into separate
prop sets and then properly security. AD came out before the security
awareness at MS changed the philosophy from enabled by default to disabled
by default. I far more like the ADAM idea of everything is locked down and
needs to be granted. In the lockdown guide I would love to see the stripping
of all of the ACEs out of the default SDs as well. Let us get to a point
where most permissions are handled through inheritance so if you need to
pick things off you can also do it with inheritance which is much easier to
hide an attribute
- 6.9K Views
- Last Post 12 October 2016
Good good, that is what I like to hear. :o) You will want to buy copies
If PoSh is timing out when accessing your child domain(s), using CSVDE or any other reporting tool isn’t going to help. I would find
out why access to your child domain is timing out and fix that.
Are you specifying a particular DC with the –Server parameter? Doing so might avoid the timeout problem if DC Locator is giving you
a DC that is unreachable.
From: Grillenmeier, Guido [mailto:guido.grillenmeier@xxxxxx]
Sent: Mon 9/5/2005 2:45 PM
Subject: RE: [ActiveDir] hide an attribute
ok, say i want to hide streetAddress from all users except DA's,EA's,amdAO's.
All auth users like DU's should NOT be able to see it in "Entire
Directory" or using "find" or even dsa.msc or any admin tools.
How would i do this?
The Delegation Wizard is no help.
Right clicking the entire domainDns object doesn't help because those
properities don't show up as a attrib of that object.
I don't want to muck with the property set because i just want the one
Do i have to modify the defaultSecurityDescriptor for the userClass
and then see where inheritance is for users/groups I don't want and
kill it there as well?
What about Exchange? Is it the Exchange Domain Servers global group i
should worry about or the Exchange Enterprise servers local group or
Which is it?Will hidding one attrib bring my email down or make it
flaky at best?
How would you go about just hidding the streetAddress ? Just as a
purely academic exercise...
That's the thing Rick, it isn't some simple easy thing to say how to do. The
simplest shortest answer is, it depends. It depends on how it is granted,
who has access to the objects and what types of access, etc. Part of that
depends is how things should be done overall and for the future, in the end
there are lots of ways to hide it and lots of ways you may have to defeat
trying to show it. Understanding the ways it could be granted and how it can
be hidden are necessary to properly do it.
In the end, no matter how it is done, there is a fair chance that PSS is not
going to be thrilled about it because it isn't standard and if it isn't
standard and documented the first recourse is to say it isn't supported.
If you think there is an easy way to do this, I wouldn't mind seeing what
your response would be. I guess the simplest that would effectively work
would be to block the LDAP port on all DCs and GCs. However I don't think
that accomplishes the true desired goal. :)
Tom Kern said:
" Say i use one of the custom attribute fields that Exchange creates and put
a value in there and hide it from Domain users.
what would break?
how would i go about hiding that?
just as an example...."
Hey, joe.... Just a suggestion. If someone asks you what time it is - don't
tell him how to build a frelling Rolex! :oD
I think all Tom wanted to know (though the background and technical detail
is good) was "How do I hide the FRELLING ATTRIBUTE? And, IF I DO, will it
So, Sparky, what have you got to say now?