RE: [ActiveDir] hide an attribute
So if you have a mixed mode forest, what if you give perms directly to Global groups on Enterprise objects in AD and only use local groups for Domain local stuff? or are you just supposed to rely on Auth users or Everyone for stuff like that? What happens if your perms are checked against a GC? GC's don't know about members of LG or GG's. Do your perms ever get checked against a GC btw? If i have RO perms on the config nc in domA and they get rep'ed to domB, is there a chance a GC from domB would be checked for perms or is it always a local DC on port 389? Thanks. your explanation made sense. it helped a lot. -Original Message- From: Grillenmeier, Guido [mailto:[EMAIL PROTECTED] Sent: Mon 9/5/2005 2:45 PM To: ActiveDir@mail.activedir.org Cc: Subject: RE: [ActiveDir] hide an attribute winmail.dat
RE: [ActiveDir] hide an attribute
glad it helped. somemorecommentsinline /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kern, TomSent: Dienstag, 6. September 2005 15:27To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] hide an attribute So if you have a mixed mode forest, what if you give perms directly to Global groups on Enterprise objects in AD and only use local groups for Domain local stuff?[Guido Grillenmeier]that's fine or are you just supposed to rely on Auth users or Everyone for stuff like that?[Guido Grillenmeier]certainly not What happens if your perms are checked against a GC? GC's don't know about members of LG or GG's.[Guido Grillenmeier]ofcourse they know about members of LGs and GGs - but only of their own domain ;-) But that's not the point. Your membership in a global group is still valid when accessing data on a GCin a different domain = it's too much to explain the kerberos authentication process here in great detail, but you'd always first be authenticated against a DC of your proper domain giving you a ticket granting ticket etc. This is where you enter your username/PW to tell the system who you are - it will then validate you and see which groups you are in. Via the trust between the domains, that authentication is also valid against the GC of the other domain, but it will generatea service ticket valid for it's domain. This service ticket won't contain the DLGs of the other domains, but it will contain the GGs of your domain, the UGs of any domain AND it will add the DLGs of it's own domain to this service ticket. Checking the perms then is the authorization process, by which your previously generated kerberos ticket will be leveraged by the OS to check what permission you have on the resource you're trying to access. Do your perms ever get checked against a GC btw? [Guido Grillenmeier]yes, see above If i have RO perms on the config nc in domA and they get rep'ed to domB, is there a chance a GC from domB would be checked for perms or is it always a local DC on port 389?[Guido Grillenmeier]authentication will bea DC of your proper domain (domA)+ the GC of the trusted domain (domB). authorization will be done by the resource you're accessing, which would be the GC of domB in this case. Thanks. your explanation made sense. it helped a lot. -Original Message- From: Grillenmeier, Guido [mailto:[EMAIL PROTECTED] Sent: Mon 9/5/2005 2:45 PM To: ActiveDir@mail.activedir.org Cc: Subject: RE: [ActiveDir] hide an attribute
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 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: ActiveDir@mail.activedir.org 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: ActiveDir@mail.activedir.org 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
RE: [ActiveDir] hide an attribute
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/
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
RE: [ActiveDir] hide an attribute
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
[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/
