Help! Remote Server Administration Tools exposes DNS and AD details

sratakhin

Hello,

As many of you know, it's possible to administer AD and DNS servers (as well as many other features) by using Remote Server Administration Tools that can be installed on any Windows version.
For some reason, I thought that in order to be able to use it, a user has to have more privileges on a domain than a regular user, like being able to reset passwords, move users between OUs and so on. Well, this is not true.

Yesterday I was able to install the RSAT using a generic user account that has local administrator privileges. I then could see the DNS entries, user accounts (including information that only a few people should be able to see). In short, the tools allow accessing the same MMC snap-ins that are available when logged in on a domain controller. Of course, the access is read-only, but there is still too much information that better be inaccessible by regular users.

Is there a way to block the remote management? I have a few ideas, but not sure how to implement them:
1) Block MMC and certain snap-ins by using AppLocker and Software Restriction Policies. Easy to get around, as there probably other tools that can expose the AD information.
2) Block certain ports on DCs, so that MMC can only communicate with trusted computers. What ports should I block and won't it break the AD replication?
3) Just forget about it and hope that users are not savvy enough to do any harm.

I know that users shouldn't be local administrators, but this is a business requirement for some departments.
And in any case, once somebody has access to the computer, it's difficult to stop them from becoming a local admin. Been there, done that

Qord

I believe that, by default, all authenticated users have read access in ldap. The easiest thing to do is probably set up a gpo that blocks use of known/common ldap browsers, but even that won't fully do the trick. You could also set attributes to confidential, but that might cause more problems than it's worth. Plus that's a lot of work.

As far as ports go, I think 389 and 3268 would be the target ports for this. You should double-check that to be sure though.

sratakhin

Won't blocking these ports prevent users from being authenticated at all?

cyberguypr

You are looking at the wrong problem. If your users have access to that generic account and can install things then that is your issue. As you mentioned the read-only LDAP acess is per design and all kinds of things can break if you block the wrong thing. If users absolutely must be admins you can block RSAT via GPO but that doesn't address other LDAP browsers they could install.

Honestly, if there isn't a policy or specific requirement, I wouldn't bother with this.

crrussell3

Personally, I think you are making a mountain out of a mole hill. If your end users are savvy enough to know of, download and install the RSAT tools, then they will know of other built-in/downloaded/portable/cli apps out there. So trying to block the rsat tools is pointless and will most likely break more than it fixes.

Block RSAT. Let me drop to cli. Block that. Let me download any other portable or installed app out there, like Putty or a packet sniffer for instance. I would be more worried about users having admin access, being able to download exe/msi/zip/etc then rsat.

My question is why are you concerned about them seeing this information at all? There really isn't anything "classified" by default in a user object per say, unless you put it there and that is a whole other concern.

blargoe

I agree with everyone else... LDAP and DNS are going to be world readable, it needs to be this way by design.

Your real problem is that your users have access to install these apps in the first place. Hopefully, they don't have elevated rights on other systems as well.

RobertKaucher

sratakhin wrote: »

Yesterday I was able to install the RSAT using a generic user account that has local administrator privileges. I then could see the DNS entries, user accounts (including information that only a few people should be able to see). In short, the tools allow accessing the same MMC snap-ins that are available when logged in on a domain controller. Of course, the access is read-only, but there is still too much information that better be inaccessible by regular users.

Is there a way to block the remote management? I have a few ideas, but not sure how to implement them:
1) Block MMC and certain snap-ins by using AppLocker and Software Restriction Policies. Easy to get around, as there probably other tools that can expose the AD information.
2) Block certain ports on DCs, so that MMC can only communicate with trusted computers. What ports should I block and won't it break the AD replication?
3) Just forget about it and hope that users are not savvy enough to do any harm.

Being able to read from AD is a requirement for every aspect of AD. Nothing that you have that is confidential should be documented or encoded in AD. Knowing that a sensitive service account's name is SvcAcct-UltraSecret is next to completely useless. Any attacker capable of penetrating your network would be able to determine this sort of information quickly and easily. Without the ability to read from AD users would not be able to administer network shares, grant access to SharePoint sites, use the GAL in Outlook, etc.

Being able to enumerate DNS is also essential or users would not be able to even authenticate let alone find a resource on the network that they need access to.

To really evaluate this as a potential security issue ask yourself this:

What sort of harm is the user going to do with any of this information?

sratakhin

2 cyberguypr
The reason why we have some users running as local admins is that they use a few applications that don't work under regular user accounts.
It's really not that difficult to gain admin rights on a system that the user has physical access to, unless the hard drive is encrypted. Also, anyone can bring their own laptop, join it to the domain (our students have domain accounts) and then make the user a member of the Administrators group.

2 crrussell3:
That's exactly what I thought.

2 blargoe:
It's a business requirement that users should have access to admin accounts

2 RobertKaucher:
The user accounts have a unique number stored that is used to generate the user's password. Thus, savvy users can in theory try to impersonate other people, which... well, let's just say, could be used to access inappropriate content. If that person is then caught, somebody else will be punished.

So, if blocking access to this information is next to impossible, is there any way to restrict what fields in the user accounts properties can be seen by people who are not supposed to see them?

sratakhin

I found what I was looking for:
http://www.windowsitpro.com/article/active-directory/hiding-data-active-directory-142135
Hiding Active Directory Objects and Attributes

coty24

I wholeheartedly agree the the sole problem/issue is that regular users have admin rights. How about presenting the application(s) via RDP on a server you control and just add them to the necessary groups. They can RDP to the apps w/ username and password. Then you can take away admin rights yay!


"2 blargoe:
It's a business requirement that users should have access to admin accounts "

Looks like you are the only one that cares about security there.....

sratakhin

Well, it's slowly changing.

I thought about using RemoteApp for that particular application, but again, the problem is not just in existing users.
A standard user can add up to 10 computers to the domain, although this privilege can be taken away.
We also have some users that we cannot take administrative privileges from. It's just the way their contracts were negotiated with the local union.

Also, it's easy to reset the local admin password on any machine that the user has physical access to. Even with the BIOS password lock, all it takes is removing the hard drive and putting it in another computer. Unless the system drive is encrypted, it only takes 10 minutes. Then the user can add him/herself to the local admin group and have full access to whatever is stored in AD.

Btw, many years ago the students' Social Security Numbers were used as their IDs, and the old e-mail system stored this information in the registry. What a shame.

crrussell3

Also, it's easy to reset the local admin password on any machine that the user has physical access to. Even with the BIOS password lock, all it takes is removing the hard drive and putting it in another computer. Unless the system drive is encrypted, it only takes 10 minutes. Then the user can add him/herself to the local admin group and have full access to whatever is stored in AD.

Restricted groups could help solve this. If they remove the hard drive to manipulate it in another computer, as soon as they put it back in and started it up, Restricted groups would replace the local admin members with only those you allow.

Qord

LDAP stuff aside, if the "need" for admin accounts is just to run a few programs, a better idea might be to write a simple script that runs them as admin, put it through an obfuscator, and compile it so they can run it as an exe. Essentially it would just be a wrapper for the program that allows a normal user to run it as admin.

You could also use the /savecred switch in creating a shortcut for the programs in question, as this will save an admin user/pass, but if you're really worried about security this is probably not a good idea either.

RobertKaucher

sratakhin wrote: »

2 RobertKaucher:
The user accounts have a unique number stored that is used to generate the user's password. Thus, savvy users can in theory try to impersonate other people, which... well, let's just say, could be used to access inappropriate content. If that person is then caught, somebody else will be punished.

So, if blocking access to this information is next to impossible, is there any way to restrict what fields in the user accounts properties can be seen by people who are not supposed to see them?

Certain things can be blocked but this is not something that should be done without extensive testing. IMO it is generally best to leave AD alone but you could organize OUs in such a way that you could hide information about sensitive service accounts from regular users without causing huge problems.

Hiding Data in Active Directory

About7Narwhal

I may sound like an idiot here, so forgive me if I am way off base with this question, but why don't you just modify the servers to disallow access from those accounts? I assume those admin accounts belong to their own AD group, so just limit their access to the server. They are still local admins and can install what they want, but receive an access denied error when attempting to query the server. Ideally, you would have your IT admins in a different group then your application admins.

sratakhin

The thing is... Local admins can access the AD if they install the RSAT. I also thought that the only reason I'm able to access it is because I have some privileges in AD (not a domain admin though), until I tried to install the tools under a different user account.

Anyway, I'll try to make those applications work without having to grant users extra rights.

ptilsen

Just going to parrot everyone else in here and say this is by design, not a risk, and not worth trying to prevent. A user with the sophistication to install RSAT can probably figure out one of the myriad other mechanisms to get in, and you can only limit so much of this without breaking functionality.

As far as local admins (non-domain users) having access, consider this: Local admins have total, unfettered access to the systems on which they are admins. This means they can intercept hashes of any domain accounts on the system as well as impersonate the system account, which is a domain member. They can install a keylogger and capture domain user credentials, in turn gaining access to domain information (to which again, read-only access shouldn't be considered sensitive).

And on that note, it is all but impossible to prevent someone with physical access to an unencrypted computer from creating, enabling, or resetting the password of the local admin.

It boils down to trying to prevent tech-savvy users from accessing information they can get if they really want despite whatever controls you implement.

phoeneous

Sometimes the answer isn't technical. Hope you have an acceptable use policy in place.

crrussell3

@sratakhin Process Monitor will become your best friend for granting applications the permissions they need to run on a standard user account.

blargoe

sratakhin wrote: »

We also have some users that we cannot take administrative privileges from. It's just the way their contracts were negotiated with the local union.

Their union contract states they have to have admin rights?!?!?!?? Wow.

sratakhin

These are not the exact words. They have to have a freedom to do whatever they want. Of course, we have to fix their computers if they screw up.

RobertKaucher

sratakhin wrote: »

The user accounts have a unique number stored that is used to generate the user's password. Thus, savvy users can in theory try to impersonate other people, which... well, let's just say, could be used to access inappropriate content.

To be honest this is your issue right here. This is beyond silly. RSAT is not your problem, that practice is. This is like leaving unslated, unhashed passwords in a database. Just a matter of time.

Abdul201288

Just use Group Policy to block all the applications that you are using (block for regular users). I've blocked MMC-SNAP in, CMD. All the things that my family "try" to get.