‘List Object Mode’ in Active Directory, a myth or future settings?
After long delay of being absent, I managed to fetch some time in order to pen down an article and share my thoughts about on of the features of Active Directory which has been always in total darkness for me. ‘List Object Mode’.
As long as I can remember, I’ve always had problem with the built-in concept of ‘Everything Visible in Active Directory for Authenticated Users’. It’s been a conflict for me during these times to convince myself about it. Sometimes I backed off and decided to stay behind and accept Active Directory as a Directory Service, but the other time I convinced myself why my domain users should see the objects of my AD domain?
Here I am not going to talk about the instruction and ‘How To’s in order to implement List Object Mode, there are thousands of instructions out there with hundreds of images written by people more lovely and stylish than me, instead, I want to focus on whether it is good or not to enable ‘List Object Mode’ in our forest and utilize it in an effective way.
Believe it or not, I can’t convince myself that ‘Authenticated Users’ should be able to see objects in my AD domain. The reason is simple, they all just users. I am not trying to offend, but to me, role of user accounts in AD domain is to login to computers and access resources based on security permissions provided, not to be able to browse through my network and see what I have in my OU’s. You are less likely to prohibit access for ‘Authenticated Users’ in your domain, unless you meet situations below:
YOU HAVE A LARGE NUMBER OF LOCAL ADMINS
This one is a big problem. I am aware. I know that we can’t blame Active Directory as long as we have local admin user account in our environment and honestly speaking I believe that we need to first reduce the number of local admins and then start working on other aspects of AD security. But you can’t always rely on this. There are many situations which we need to assign local administrator access to our users. These most common situations are:
- Organizational policies! Can’t really do anything about it.
- Managers! They just want full access on their PC. You want to mess with them, good, forget about your raise.
- Old applications. These applications are like electricity switches. They just work under most privilege accounts, or they don’t. Basic 0 or 1 logic.
- New lazy developers! These lovely people just code the program on their local PC’s with full access. Once it’s done, it’s done and they mean it, no more tests are needed according to their opinion.
So what happens when you have local admins? They are king of their PCs, they can install RSAT and with a valid user name and password AKA ‘Authenticated Users’ they can browse through the whole OU hierarchy. You are wise if you want to prohibit installing of MMC consoles using GPO, but head over to next section for that.
CURIOUS HELP DESK ADMINISTRATORS
This type of problem is not really common but they show themselves when you have a large number of Help Desk admins. Let’s say you have many sub OUs and each OU is delegated to its corresponding group. Sounds really normal, but you will come across this problem when you are planning to instruct them to correct their failures in their user input. Just to make an example and keep you informed, we do have a strict naming convention in our environment and because of that Helpdesk admins are not allowed to disobey the naming conventions and… You know what? Let me represent a dialogue between me and another Helpdesk Admin to clarify this a little bit:
- Mahdi: You know that your naming convention is not correct Adams! Will you correct them by the end of this week?
- Adams: Why is that?
- Mahdi: Mostly Disaplaynames. We need a combination of LastName + FirstName, your’s are FirstName + LastName.
- Adams: Take it easy, we know who is who. Not a big deal.
- Mahdi: I bet you do, but not me. Besides it gives a better view withing the AD which you are working too. Not to mentions it’s a policy.
- Adams: If that is a policy, Jack should correct them too!
No more explanation here...
SOCIAL ENGINEERING ATTACKS
We all are aware of it. What happens if someday, someone, somehow gain access to our AD (Authenticated User) and use those information in an offensive way? You may say why would you put sensitive data in a Directory Service like AD and please don’t blame me for not using confidential attributes. These things happens.
I guess these reasons are strong enough in order to convince anyone to agree on that with me. After all, Let’s say that I know that I am using a Directory application and according to nature of Directory Services, users should be able do browse through the content but let me give you an example which dates back to my childhood. I remember whenever my mom wanted to leave me at home to do the shopping etc, she used to hide our phonebook, why? Because apparently I was a super social person that time and I used to start dialing random numbers of that phone book and talk to them. You know what I feel now when I say I just don’t want our users be able to browse.
So although these type of problems may not appear in your organization because of size of your AD, intelligence of users or other reasons, for the rest of the people who wanted to have their AD objects hidden, Microsoft introduced List Object Mode. Actually it is better to say it was introduced in 2000 if I am not mistaken but they decided to hide that feature within ADSiEdit and that’s why if you want this back, you need to enable the lovely dSHeuristic attribute. If you want to learn about how to enable that, refer to See Also section. Just to keep in mind that dSHeuristic attribute is a binary attribute and has 3 digits which by enabling the first two, you will mess with ANR and the third one is the one which enables the List Object Mode. Picture below shows what I mean:
After enabling List Object Mode, what you have to do is to work with OU permissions in order to implement your desire visibility. Kelly Bush wrote a wonderful wiki with fully detailed steps and images in order to make it more comprehensible which you can find the link at the end of article. I need to mention that List Object Mode itself is a good thing and you can completely obtain your level of visibility within your OU structure, but believe me you have to work through a lot of inheritance removal and explicit permissions which will make the task a bit confusing and difficult to follow and if you are someone like me who has to answer your wife’s call under any circumstances, you will end of in a situation like”Wh..at are these? Whe..re am I? GOD look at these permissions!” no matter how much you write down your progression in order not to lose the track.
For those of people who has not read about what is List Object Mode so far, I really urge them to read but if you want to know a really fast understanding of how does it work, I should tell you that controlling the visibility of objects in your domain will be done by using two permissions:
- List Content: Related to child objects of a parent object.
- List Object: Related to the parent object it self.
It makes the thing a bit harder if you have super nested OU structure because for each OU, you have to remove the List Content permission, then for each child OU which you want to have visibility, you need to configure List Object and for the objects you don’t want them too see, remove List Object. Sounds complicated? Just read Kelly’s article, he does explain better, trust me.
So far so good and after 4 hours of messing with permissions and dealing with a headache, your OU structure is hidden but to appropriate users. So what is the problem? These is:
Once you remove List Object permissions within security descriptor of that OU, users under that OU will no longer be able to update Group Policy their Group Policy.
Why is that? Well I guess because if a user need to update his/her group policy, he/she should travel a hierarchy and read all GPOs which are linked to each parent in which he is residing in. That is when List Object permission comes into play and in case of absence, no GPO will be updated.
Let’s visualize the problem using an image:
Here we just have removed List Object permission to the Red OU, but the GPO won’t get updated. However I did not get disappointed and tried to work harder with permissions and especially SELF, but again no results were achieved.
Apart from all being said, this lovely List Object Mode, works correctly if our only concern is to hide data from users, but the problem as we mentioned is when you are updating the Group Policy Objects which they will fail. So you may ask, why do we work through our permission when it doesn’t work? The best answer I can give to you is that at least you can use this method for you built-in containers like System, Built-in, Users, Domain Controllers and etc.
So far I hade no problems with that. However I will update this article once I find the consequences of these tweaks but until then, I believe it is a good idea if we could change the mindset of Microsoft AD team and convince them to work on this problem.