DNS Security

[imported_JFG]

I have w2k03 AD intergrated. Iv'e discovered that a generic user account that has local admin rights can install the 2003 adminpak tools on their machine and alter, Add & delete DNS records through the DNS console. How can I lock this down? And yes some users (developers) do require local admin rights.

Thanks

 

[dphantom]

Delete the adminpak from the workstation. If you use imaging, build an image and before finalizing sysprep, remove any exe/msi or other files you do not want the user to have.

Above is not pretty, but nothing else comes to mind right now if the user is a local admin.

 

[imported_JFG]

Yeah but they can always reinstall. I'm looking more to prevent a user that does install it can not get access to do anything to DNS

 

[Nothinman]

If you properly secure the DNS server they shouldn't be able to do anything.

 

[SlickRoenick]

You can deny them access in the DNS admin group that's built-in with AD

 

[nweaver]

local machine admin should not have domain admin rights, either something is messed up in the domain, or you need to redo the users as Domain Users and on each machine, add the Domain Users group to the local admins or the specific domain account who uses that machine.

 

[stash]

I'm looking more to prevent a user that does install it can not get access to do anything to DNS

Why are you letting users install the adminpak?

 

[Nothinman]

Why are you letting users install the adminpak?

There are lots of cases where users need local admin access, so it's not always something you can control easily. But even so, they shouldn't be able to do any damage with the admin tools if the DNS servers are setup properly.

 

[imported_JFG]

there is no policy in place that says they can't. As far as I know nobody has it (except for the handful of admins) & we will not install it for anyone, but can you ever trust the users?. Basically one user requested to have the Remote Desktops feature installed that comes with the adminpak. I found how to install certain utilities like WINS & DNS by themselves but not the remote desktops. I triec copying tsmmc.msc & mstsmmc.dll & registering the dll but I get an IE error when I connect a session.

While testing this I noticed that domain users could access & modify DNS records if they use the DNS console

 

[imported_JFG]

As far as I can see they are locked down properly. I don't have the same problem with WINS & DHCP which are on the same servers.

 

[LOFBenson]

Users need permission to edit DNS records in MSDNS. Somewhere in the DNS security settings (DNS -> server -> properties -> security) or in AD you are granting this permission. For instance you may have placed the local admin users or groups into a larger admin group that has permission.

 

[stash]

There are lots of cases where users need local admin access, so it's not always something you can control easily.

The only valid reason for giving standard users admin access is poorly written applications. And the majority of those can be worked around by using file/regmon and granted permissions where necessary, rather than giving blanket admin rights.

But even so, they shouldn't be able to do any damage with the admin tools if the DNS servers are setup properly.

They can't, but the point is, why give them the opportunity. If users are local admins and can install adminpak, they can install whatever the hell they want (or don't want). The only users who should (potentially) have the adminpak are well, admins. Delegation can then be used to control what an admin can do with those tools.

 

[Nothinman]

The only valid reason for giving standard users admin access is poorly written applications. And the majority of those can be worked around by using file/regmon and granted permissions where necessary, rather than giving blanket admin rights.

And in a lot of cases spending time to work out those rights isn't worth it, just giving user's admin access takes 2s and whenever they break something you just reimage the machine and move on.

They can't, but the point is, why give them the opportunity.

Because you can never guarantee client security 100%, someone could bring in a notebook from home or connect to your network via some other notebook's ad-hoc wifi. There is absolutely no excuse for not properly securing your servers.

If users are local admins and can install adminpak, they can install whatever the hell they want (or don't want).

Yup and if your servers are setup properly it doesn't matter one bit what they have on their machines.

The only users who should (potentially) have the adminpak are well, admins. Delegation can then be used to control what an admin can do with those tools.

Making your security rely on who has what installed is just plain stupid and invites problems.

 

[stash]

And in a lot of cases spending time to work out those rights isn't worth it, just giving user's admin access takes 2s and whenever they break something you just reimage the machine and move on.

I'm glad whoever you work for has the time and money to burn on reimaging machines. This might be ok for a small office with a handful of machines, but on a larger network, (thousands of clients) this is horribly impractical.

There is absolutely no excuse for not properly securing your servers.

Agreed. I never said you couldn't secure the server so that people installing adminpak couldn't do things. My point is, there is also no excuse for not securing your workstations.

Making your security rely on who has what installed is just plain stupid and invites problems

Agreed, but you missed my last sentence. Delegation can be used to control who can do what on the servers.

 

[Nothinman]

I'm glad whoever you work for has the time and money to burn on reimaging machines. This might be ok for a small office with a handful of machines, but on a larger network, (thousands of clients) this is horribly impractical.

Generally it's a lot quicker to reimage a machine than it is to spend hours tracking down a problem. And I guess you could consider us a smaller company, but I wouldn't call ~1000 machines a handful.

My point is, there is also no excuse for not securing your workstations.

But your point is invalid because of all of the crappy 3rd party and internal applications that we don't have time to debug for people. Even lots of non-crappy apps do stupid things like putting config settings in the programs install directory, like SecureCRT.

 

[spyordie007]

I think we're starting to get off topic here.

I agree that users' privilages should be properly restricted on the client machines; however the most important issue here is that the DNS server(s) are not properly secured.

Can we at least agree that it's more important that your servers are properly secured than it is with your clients (even if by only a small margin)? That being the case lets focus on the lowest hanging fruit here.

That said in the DNS MSC ACLs can be configured on both the server as well as the zones. Just do a right-click and bring up properties for the relevent node(s).

BTW Stash, considering the number of users @ MSFT who have local admin privilages I would have figured you would sympathize with the OP more

 

[stash]

Generally it's a lot quicker to reimage a machine than it is to spend hours tracking down a problem. And I guess you could consider us a smaller company, but I wouldn't call ~1000 machines a handful.

After the applications that go into the base image, how often do you need to install apps for users? Figuring out what permissions an applications needs shouldn't take very long at all. Fire up reg/filemon, run the app and save the dumps to Excel. Sort on access denied.

1000 computers is more than a handful, but it is definitely on the small side. Tell the IT group of a company with a 100,000 computers that they should just reimage when their users running as admin fsck something up and let me know what they say.

TW Stash, considering the number of users @ MSFT who have local admin privilages I would have figured you would sympathize with the OP more

Yes there are quite a few at MS who run as admin, but I'm not one of them. Most of my colleagues that I work with every day don't run as admin either. We're all security consultants, so that may have something to do with it, but whatever

And of course with Vista being developed and tested, there is a growing number of people who are not running as admin within Microsoft.

 

[spyordie007]

And of course with Vista being developed and tested, there is a growing number of people who are not running as admin within Microsoft.

:thumbsup:

 

[Smilin]

Originally posted by: Nothinman

Why are you letting users install the adminpak?

There are lots of cases where users need local admin access, so it's not always something you can control easily. But even so, they shouldn't be able to do any damage with the admin tools if the DNS servers are setup properly.

Agreed, there is nothing wrong with installing the adminpak. It does mean your users have admin right to their own box. Something to be aware of but this is pretty common with developers.

If you set your AD up right they won't be able to edit DNS records. The common exception to this is DDNS where a client is allowed to alter it's own DDNS RR *only*.

 

[Nothinman]

After the applications that go into the base image, how often do you need to install apps for users?

Depends on the user in question. A lot of them work off the base image just fine, but some need more. I'm out of the loop now since I'm not on the Helpdesk any more, but with so many users using our Citrix servers for remote access I would guess that less of them need special installations otherwise our Citrix servers wouldn't be adequte since we're so strict about what goes on them.

Tell the IT group of a company with a 100,000 computers that they should just reimage when their users running as admin fsck something up and let me know what they say.

If you have the Helpdesk power it doesn't matter too much. Usually after one reload the user gets enough of a clue to not do whatever they did because of the inconvenience that the reload caused them =)

If you set your AD up right they won't be able to edit DNS records. The common exception to this is DDNS where a client is allowed to alter it's own DDNS RR *only*.

Yes and that's fine, if they want to screw up their own records that's fine since they'll only cause problems for themselves. And if you have auditing setup you will have a record of what they did so that when they call the Helpdesk you can point out what they did and tell them not to do it again.