Active Directory - prevent users from enumerating other AD users and groups?

In a Windows 2008 R2 Active Directory, is there a way to prevent domain users from enumerating information from AD? (for example, prevent them from searching/viewing AD Users and Groups)

Perhaps some limited user or AD group that we can set certain restrictions on?

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

OUs and objects have ACLs, just like files/folders. Righclick - properties - security.
But be aware that taking this ability might have side effects. I cannot tell which, it will depend on the programs that use your AD.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
VasAuthor Commented:
I created a users OU but when I right-click and go to Properties, I don't see a Security tab. IT shows tabs:  General, Managed By, COM+, Previous Versions

Can someone please elaborate on what we can try (I understand it would need testing) to place specific users in a special OU that we can set restrictions on (the restrictions would be to prevent the AD user from enumerating other users/groups in AD)

Thank you
You need to prepare the management console a little: select Active Directory users and computers, now in the menu "view", you can select "advanced features" and afterwards, there's your security tab.
Determine the Perfect Price for Your IT Services

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden with our free interactive tool and use it to determine the right price for your IT services. Download your free eBook now!

VasAuthor Commented:
looks like I actually need to be in ADSI Edit.

I assume I'd create a separate OU folder, place these users in that folder...

Then on the OU folder properties, under Security,  is it "SELF" or "Authenticated Users" that would need to be edited?

 I see for any user or group I go access advanced permissions and maye disable "LIST CONTENTS"?  That might work will have to test if they can still log into the app we're giving them access to.

Am I on the right track, and do you know what SELF is?

OU properties

Thanks again
No, ADSI-Edit is not needed. After adjusting the view, like I told you, you can use normal ADUC.
Both authenticated users and everyone need to be adjusted. Not "self".
By the way:why are you doing this, it should do no harm to see AD contents, that's why it works by default.
David Johnson, CD, MVPOwnerCommented:
use the confidentiality bit to hide AD data note not all fields support the confidentiality bit.
VasAuthor Commented:
Thanks, just waiting for our Sr. domain admin to play around with this and will follow up with any questions or let you know which method worked best.
VasAuthor Commented:
So far what we tried is creating a new sub OU folder, and on that folder under advanced permissions, for both the EVERYONE and AUTHENTICATED USERS I denied "List Contents" and "List Object", but unfortunately this AD user was still able to enumerate AD users.

I looked at the article suggested above for the alternate method:

but it says that "base schema attributes" cannot be made confidential and I'm pretty sure 'Name' is a base schema attribute right (?)

Any other ideas how I can accomplish hiding AD names for specific users in an OU?

Sorry, what are you doing? :)
You cannot deny things for everyone! That affects everyone, even domain admins... be careful.

I achieved just what you want right here: steps: rightclick OU, properties - security - add testuser - deny read. Now when testuser opens an mmc and adds the snapin ADUC, he cannot even see that OU.
VasAuthor Commented:
Hey McKnife,

Thanks and clearly I don't know what I'm doing haha (I only know enough to be dangerous)

So to clarify, I had only changed permissions on this sub-OU that I put those two AD users in (but sounds like that wasn't the correct method based on your reply)

I didn't do it your way though until just now, which was to specifically add the test username to the security list and then deny read on it (and not touch the other groups/users)

Unfortunately I don't have this working. There's a part of the app where if you want to change a setting it makes you login via your AD user, and if the user hits the 'Advanced button:


on the following screen, if they click 'Find Now' they can see all our AD users:


Hope that helps explain what I'm trying to restrict. I don't want them to see the other AD users.

Thanks again  :)
VasAuthor Commented:
I also found this which is exactly what you said to do McKnife.

Does it need some time to take effect maybe?
VasAuthor Commented:
Oh, maybe I need to be doing this at a MUCH higher level in AD?

(this OU is under another OU, but I don't know if that really matters.  This is the OU folder those two test users are in that I've made the change)
Don't worry, you are almost there :)
You forgot that what you just did was for the OU itsellf, not for objects in it. To apply to objects in it as well: security - advanced - doubleclick the testuser entry and choose "applies to: this object and all descendant objects". I tested it with just what your screenshot shows - works, no users from that OU show up.
VasAuthor Commented:
Ok so almost there :)   but running into this now...

When I double click on that AD user, that checkbox you're referring to is grayed out  ("Apply these permissions to objects and/or containers within this container only", so I can't enable that.

On the previous screen (the security permissions screen, just before double clicking on the AD user), the checkbox "Include inheritable permissions from this object's parent" is not checked on (it was on but I disabled inheritance in hopes of resolving the above issue)
If something is grayed out, you are either not allowed to change it (you yourself haven't got the permission) or it's inheritance. Double check that or test with another OU, first.
VasAuthor Commented:
I was able to set those settings, but it's still letting me list the AD users for some reason.  Going to play with it some more tomorrow.
A deny trumps all other permissions granted. It has to work. I'd like to see a screenshot of that ACL of yours.
VasAuthor Commented:
The odd thing is that I think I may have had it working for about a minute initially... until I added the 2nd user into the security ACS of the OU, but I don't see why that would have affected anything. I didn't touch the security permissions for user1 after it was working  (I did later to further restrict it so that's why you see more than just read denied now but that hasn't fixed it. Before it was just read that was denied under special permissions, but then I disabled all the list permissions too so now it shows read denied instead of special permissions, just fyi)

Here's some screenshots, let me know if you need anything in more detail:



and here's that user able to list AD users:


When I went in to add the 2nd hypvconsole-user I didn't touch anything from the first user, I only added user2 and duplicated the same permissions on it. Then I tested user2 and it could list AD, and then I logged in as user1 (the one that I had working for a minute before) and that was now able to list AD users again.
You don't know what you are doing :)
You should Change the ACL of the OU that you don't want your users to see... not on the OU your test users themselves are in!
VasAuthor Commented:
Thanks McKnife  :)

If I don't want them to view any AD users, since we have users in different OUs under different parent level OUs...  is it safe then to add these 2 users to the security ACS on the entire AD domain object?


Just the user OUs. If you deny read on all Domain objects, they will not get GPO restrictions which cannot be intended.
David Johnson, CD, MVPOwnerCommented:
What you are trying to do is not feasible using active directory. If you deny access then the 'anonymous' user won't be able to login under any account a samaccount name has absolutely no security by itself and is easily guessed.  That is why we have passwords and items like login hours and allowing login only to specific computers.
I don't see a Connection to the user anonymous - what am I missing?
David Johnson, CD, MVPOwnerCommented:
an anonymous user is a user before they login i.e. a user without a name or password. When one logs in the computer asks AD does user abc exist, if not it immediately returns and you get the login error message. if it does exist it then does the password check if it matches then you get an access token if not you get the login error message. Prior to this the computer itself logs into the domain using its computername and password.
There is no connection to this, sorry.
She wants to keep some users from enumerating other user accounts. The process that you are talking about does not use these user accounts that she is dealing with.
David Johnson, CD, MVPOwnerCommented:
She will see the users that are in the same OU as the user making the inquiry.
The users will be able to logon. The users will not see any user which we prevent read Access to. Try and see.
VasAuthor Commented:
Hi McKnife,

Ok- so I need to restrict the user(s) from the OUs that contains the users I don't want them to see.  I understand that now, and I thought I'd have this working but hopefully you can spot what the issue is. I guess I must still be doing something wrong...

So here's the user, with DENY permissions on this OU below:


If this works then I'd expect that this user can see other users in AD, just not those under the above OU.

However, in testing it's still seeing the users from this OU folder:


I guess you are forgetting something. The inheritance.
Quoting myself from earlier: "You forgot that what you just did was for the OU itself, not for objects in it. To apply to objects in it as well: security - advanced - doubleclick the testuser entry and choose "applies to: this object and all descendant objects". I tested it with just what your screenshot shows - works, no users from that OU show up."
VasAuthor Commented:
Hmm, I do have it set that way, but under "Effective Permissions" I can see there that it's not registering this setting....




Going to punch something and be back in a few lol.
Let me guess: you did not notice that little checkbox "Apply these permissions to objects and/or containers within this container only"? Clear it.
To confirm: do the user objects themselves (just pick one for a test) wear these new permission settings? Do they live directly in WSPUsers or in another subcontainer?
VasAuthor Commented:
Ah my bad I guess I misunderstood the context of that checkbox.

The users live in multiple subcontainers under WSPUsers .  So unchecked the box to apply the permissions again to everything.

So I have good news and bad news...

The good news, is that right after saving that change and tested, I couldn't enumerate anything (I thought I would still see users outside that OU, but I got this...)


However, then I logged that test user, and logged it back into the app to test again and it was able to see everything again, so maybe the error was due to the permissions still propagating?

This is how the permissions look for one of the users that are enumerated:


It shows the hypvconsole-user1 with Deny read permissions, so I'm really perplexed at this point.
What app are you using? Since I might not have this "app", please simply use folder ACLs, so let's try and modify the ACL of a folder on c: and see if your test user can add an "invisible" account that way - he should not be able to enumerate, there.

About your described behavior: yes, perplexing indeed.
"maybe the error was due to the permissions still propagating?" - I don't think so, that will be quick. Maybe you run different DCs and your "app" now decided to ask another DC that has for some other reason not replicated those object ACL changes? That could be an explanation.

Off to the movies now, see you tomorrow.
VasAuthor Commented:
The app is the VMM client (SCVMM,  Virtual Machine Manager) for Hyper-V

I'm trying to think how I can replicate this outside of the app... the user remotes into the VM using a non-AD login.  It's the app that requires an AD login, so they login to the AD account to launch the app.

On the VM that this runs on, they are just a local user (non-AD)
Please follow my advice and try what I described now, the folder ACL.
VasAuthor Commented:
Hi McKnife,

But the user is logged into the machine on a local account.  So I wouldn't be able to test if the AD user can do anything with a folder on that machine.

The only purpose that machine is for is to run the 'Virtual Machine Manager' application. It's that application that requires logging in with an AD account to then access our SCVMM infrastructure of virtual machines, where I've limited them to just being able to view their own machine.

That app has no way to create folders or users locally or in any folder.

I don't doubt your initial instructions regarding the security ACLS on the OUs I don't want the user to have read access to. I'm thinking maybe it doesn't work in my scenario because the application, once logged into, possibly then runs under a completely different service account or something on the back end. That's just a guess but would explain why I can't restrict the AD users from enumerating an OU that I specifically denied them read access to.

I'll wait until tomorrow for any feedback from you before closing this out but I'll select your initial advice about this as the solution as it probably works in other circumstances and is the solution (just not for my case).

I really appreciate all the guidance you've provided here, you've gone well above and beyond on this. I wish I could give you closure and say that I got it working, but the workaround we're going to use is to log into the app for the user and have them take over the RDP session, this way we don't have to give them an AD login (the app asks for the AD password again when you get to the point of searching AD, so this will prevent them from doing this since they won't know the password)

Thanks again McKnife.
If you logon as a non-domain user, how should the restrictions that you set for the domain user hyperv-console1 apply?
VasAuthor Commented:
Hi McKnife,

It's the VMM application that requires an AD user.    The user first RDP's to a virtual machine (local login, not AD),  then launches the application at which point they are require to login with AD credentials.

It's through that application that AD can be enumerated.
Ok, if your workaround is fine with you, why not.
VasAuthor Commented:
Thanks for all the hard work in helping on this
You're welcome.
And don't forget: never set deny one group "everyone" - no matter where... :)
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Active Directory

From novice to tech pro — start learning today.