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 attrib hidden. 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 Auth users? 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... Thanks On 8/21/05, joe <[EMAIL PROTECTED]> wrote: > 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/ > 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/
