Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: Concerning Windows Domain security

  1. #1
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207

    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

  2. #2
    Senior Member
    Join Date
    Nov 2001
    Posts
    1,255
    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.
    Chris Shepherd
    The Nelson-Shepherd cutoff: The point at which you realise someone is an idiot while trying to help them.
    \"Well as far as the spelling, I speak fluently both your native languages. Do you even can try spell mine ?\" -- Failed Insult
    Is your whole family retarded, or did they just catch it from you?

  3. #3
    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.

  4. #4
    Senior Member Spyrus's Avatar
    Join Date
    Oct 2002
    Posts
    741
    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
    Duct tape.....A whole lot of Duct Tape
    Spyware/Adaware problem click
    here

  5. #5
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207
    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

  6. #6
    AO Ancient: Team Leader
    Join Date
    Oct 2002
    Posts
    5,197
    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.
    Don\'t SYN us.... We\'ll SYN you.....
    \"A nation that draws too broad a difference between its scholars and its warriors will have its thinking done by cowards, and its fighting done by fools.\" - Thucydides

  7. #7
    Master-Jedi-Pimps0r & Moderator thehorse13's Avatar
    Join Date
    Dec 2002
    Location
    Washington D.C. area
    Posts
    2,885
    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.
    Our scars have the power to remind us that our past was real. -- Hannibal Lecter.
    Talent is God given. Be humble. Fame is man-given. Be grateful. Conceit is self-given. Be careful. -- John Wooden

  8. #8
    Senior Member
    Join Date
    Nov 2001
    Posts
    1,255
    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.
    Chris Shepherd
    The Nelson-Shepherd cutoff: The point at which you realise someone is an idiot while trying to help them.
    \"Well as far as the spelling, I speak fluently both your native languages. Do you even can try spell mine ?\" -- Failed Insult
    Is your whole family retarded, or did they just catch it from you?

  9. #9
    Ninja Code Monkey
    Join Date
    Nov 2001
    Location
    Washington State
    Posts
    1,027
    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.
    "When I get a little money I buy books; and if any is left I buy food and clothes." - Erasmus
    "There is no programming language, no matter how structured, that will prevent programmers from writing bad programs." - L. Flon
    "Mischief my ass, you are an unethical moron." - chsh
    Blog of X

  10. #10
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207
    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •