Concerning Windows Domain security

I'm sure you're all familiar with how Windows Domains work - but I do wonder this...

What measures do you reasonably take to prevent people from gaining domain administrator access?

On the one hand, it *seems* secure (Microsoft would say), that Domain Admin access is not "automatically" obtained by someone with local admin access. But in practice they would be able to achieve it:

- Installing a keylogger, and reporting a problem with the machine or their account - admin logs in - they immediately have the password
- Some programs that use distributed update services (like virus scanners especially) - sometimes require domain admin accounts - even more often, they're granted more privileges than they really need. Backup services too. A user with local admin rights can steal these services' credentials and launch processes with these rights.

So there are numerous moderately easy ways to obtain domain admin rights, if you get local admin rights. These can be mitigated by strict policy controls, for example:

- Keep all domain controllers and workstations used by admins for user management under lock & key
- Instruct sysadmins never to log on to other places using a domain admin account
- Never log on using a normal account in these secure boxes
- Give all sysadmin staff normal accounts with no extra access for day-to-day usage.

However, this is very inconvenient for the sysadmin who must physically move to different machine to do any user administration.

Also, one common approach is to keep the users and machines in different domains (or different parts of AD (not sure how AD works exactly)) so that in principle at least, gaining domain admin of the workstations domain won't give you access to the user base (although it's still very serious, as one could potentially install a keylogger in every workstation remotely)

---

Basically, what I'm saying is, how do you make it difficult for someone to get domain admin access?

- Prevent them from getting local admin rights (Difficult on standard Intel hardware) + Some users (i.e. developers) REQUIRE local admin rights in order to be able to do work.
- Prevent them from escalating local admin to higher privilege levels through use of secure separation facilities?
- Use something else? Third party products (Hardware / software) ?

Slarty

Well for one, don't run any software that could be exploited and used for privilege escalation (I will refrain from the obvious jokes. :P).
The method I used was in addition to security policies, I had it configured to log domain authentication for all users, and once I had that logged, I just watched the logs on a regular basis. No doubt someone might have broken in and done damage overnight, but the next morning I'd have seen who did it and when, and at least come up with a list of potential entry points (ie: Software X on Box Y). The logs were secured thanks to extra logging facilities that piped the logs to a *nix box. At the time I had to homebrew my software to do this, but then NTSyslog was brought to my attention.

The key thing is to trust the software you are going to give local admin, and if you don't, don't give it local admin. That may sound like it will make life difficult, and it might, but honestly you need to weigh the two difficulties of: How much extra work is this now, and how much extra work will it be if someone gets into the domain admin account and I end up with a worst-case-scenario hack. Most times the extra administration pays for itself. :)

Keylogger eh?! Well, if an admin-equiv has to log into the PC locally you are screwed aren't you?!

Yeah, we too watch our logs although they are still on the host itself and not on a central server so if the host is compromised they could remove the log entries.

We do watch all attempted login activity by admin-equiv accounts AND will soon be watching login activity by same accounts watching for baseline variations. Admittedly it's a bit time consuming but ya gotta watch activity by admin accounts.

One other way is that we inventory all installed programs and periodically review for banned applications to watch for packet sniffers, password crackers, keyloggers, etc.

Some other thoughts on this topic... centralized log server not on domain of course, implement tigher local PC controls (group policy, no admin rights, etc), and desktop HIPS. And if budget allows 2 factor authentication maybe using RSA SecureID.

I hope others post their tips/measures here...could use some new ideas.

We just made sure that noone except domain admins had local admin rights, there is no reason they need local admin. Our GPO's made sure noone could do too much. There was no reason for any of the employees to install anything that we didnt approve so they didnt need to install at all, we would just install things ourselves. As for PC problems, in typical, we would just remote connect to them using windows remote admin tool and do our work.

edit: We also had the funding to be able to have 2 people that just watched network traffic all day everyday scouring logs and looking for computers that didnt belong on the network, using different tools we could quickly track down what people were using and where making punishment swift and known company wide. Fear/word of mouth calmed things down alot

Why people need local admin rights:

Developers - a lot of development scenarios require local admin rights, especially with Microsoft tools. Any use of Visual Studio.NET for development of web applications _absolutely requires_ local admin rights (YES, I did check this thoroughly)

Clearly developing system-level stuff also needs admin rights, as well as any development that involves changing MS IIS settings (only on development servers only).

I can see how a lot of non development-oriented apps can make do without local admin. But development usually requires it.

In any case it's trivial to obtain local admin rights with physical access.

Slarty

Slarty:

You are dead right.... Unless you are in a high security environment where you can control to the nth degree what programs may be run within it there are literally dozens of apps out there that require the user to be a local admin. Really they are simply badly written apps where the developer wrote it as admin with no knowledge of how to write it so that it could be run at a simple user level. While they can't get away with it in areas were competition for market share is rife they can, and do, in niche markets. I'm in one.... Non-profit... I see it all the time.... Apps the users need, and genuinely do help the organization, are written so they only run as local admin. There is either no competition against the chosen software or it is so bad that it pales to insignificance. On the bright side, social workers don't have "crackers" minds for the most part and those that are actually computer "savvy" stick out the first time myself or my staff talk to them. My staff are told to inform me if we encounter "talented" users so they can be watched.

In addition, regardless of the fact that csch claims he runs no software that can be exploited for admin rights (?), he is right in that all you can do is monitor carefully those users that are required to have local admin to run their apps. It doesn't mean they need their app on any box they go to, therefore they can be restricted to their own machine making monitoring easier.

Finally, as you clearly pointed out already, physical access + a little talent = owned box.

All points are true, however, if you have fat (notice i didn't say phat) pockets, then you can use a product such as SMS to login to the node with full admin rights yet without walking up to the box and entering credentials. This is how we get around the admin accounts being used locally.

I didn't say I run no local-admin requiring software.

Slarty/TS, this might shock you, but it is possible to run VS/VS.NET without admin privileges. In fact, there was an MSDN Article on how to go about doing it. Note that that is with VS.NET on XP/Win2K3, however I believe there were also a series of articles on how to achieve it on Win2K desktops with VS6.

It does largely depend on the type of development being done. When I was writing Java, C, or VB I could get away with doing it as a regular user by and large just fine. There were certain issues in writing servers, but those are worked around using simple programming techniques. Things like Interdev and its ASP interpreting engine do require local admin IIRC. The big issue a lot of places have is a lack of intercommunication between developers and network admins. I'm certain others like Juridian could speak to how desktop security is done in larger development houses than I personally had experience with.

The big problem alot of places have is that the IS/TS people setting up machines don't know squat about software development or the requirements of the software developers. It is easier to give the dev's administrator access on their machines than to learn how to twiddle the appropriate bits for a good level of security (much like driving nails with a sledgehammer).

The sad part is a good portion of the developers know squat about security or administering their own machines.

chsh: I didn't say it was impossible to run VS.NET without admin privileges, I said it was impossible to develop ASP.NET applications with it without admin privileges (on the dev server anyway).

As the common development model for ASP.NET is to use the local machine as a development server, this REQUIRES local admin rights.

I searched for some time and found no solution; VS.NET feels that it absolutely needs to reconfigure IIS every time you connect to the web server; this absolutely requires admin access.

Slarty

Therein lies the answer then slarty, setup one server box, setup DNS for it, and configure it as a vhost box. Then give file share access to each dev on this box locked to a directory with their domain accounts, and point IIS to those directories for the vhosting. Your devs can have local admin access so the software can do what it needs to to that one box, and they could access their results at the appropriate resolved URL. This is how we did all our development, for a few security reasons.

It can be done so as to present little difficulty to the developer, and should help ease your security concerns.

Slarty, although i agree that is easier to let developers have local admin access, it is possible that run without it. For example, i worked at a large bank here and NO developer has special access. Every test is done thru TEST servers, that were customized specially for make their job easier. However, i do agree that is harder than just let them test on their computers. But sometimes we need to sacrifice (in THEIR point of view) "productivity" to achieve security. It is not a easy balance to do.
On that bank, there is a few group of people that has local admin. However, they signed an agreement about installing things on their computers. Just summ up, they can be fire with they get caught installing "un authorized" software on their computers. And the bank has a special audit procedure to take care of that.
Just harderned local security and minimize possible local admin exposure we can:
1) assign local admin (when needed) to a domain user - not give local admin user password to the requester;
2) disable local admin account and monitor any attempt to re-enable it
3) Just one local admin per machine - it is easy to get to invader :)
4) config password on bios to avoid cd/floppy boot - it will dificult the usage of stand alone password crack tools
5) fire out any deviation of that policy

About ideas worked on that company, after some smart guys had been fired out ...

We require 15+ mixed character passwords for service accounts.

Domain Admin logons & above require a SecureID-type dongle.
Oh, and as expected, that dongle needs a PIN to work.

Could be better, but it's a start.

Rootoo