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. :) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Sunday, August 21, 2005 3:59 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] hide an attribute 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...." [RTK] 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 BREAK ANYTHING?" So, Sparky, what have you got to say now? Rick -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Sunday, August 21, 2005 12:37 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] hide an attribute 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 to either 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 do. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Kern Sent: Saturday, August 20, 2005 10:17 PM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] hide an attribute Well, i already have the 1st and 2nd editions. i'm pretty sure i'll buy the third. If you have anything to do with it, i'm sure it will be worth the wait. I always felt the security chapter in Inside Active Directory,2nd ed was the best and clearest description I ever read, btw. The way things appear to me in reference to hiding my atrrib, i can only see modifying the defaultSecurityDescriptor But then, what if its part of a property set that some other app like Exchange needs? What if something breaks? Should it be such a big deal to hide an attrib? As an example- 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.... Thanks On 8/20/05, joe <[EMAIL PROTECTED]> wrote: > It depends entirely on how the attribute acces is granted to auth > users. I have a great writeup of this in the up and coming Active > Directory 3rd Edition. I did a very major rework of the entire > security chapter. Not as much as I wanted, but given the time I had > quite decent I hope. So if you could hold off on this question until > about Christmas.... > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Tom Kern > Sent: Saturday, August 20, 2005 2:45 PM > To: activedirectory > Subject: [ActiveDir] hide an attribute > > For those of us still running windows 2000 AD, how would you hide an > attribute from auth users? > > Say you wanted to hide streetAddress or something simillar. > > How would you go about doing this? > > Thanks > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
