Re: Securing workstations from IT guys

It sounds like you have generic domain admin accounts - I'd change that immediately, and create what are called 99 accounts. Normally a user would log in with user.name which provides them with the usual domain user privileges. If they require domain privileges for any reason, they need to log in with username99. This change in addition to detailed logging will create accountability and tracking that can be used to enforce policy.

As someone else has suggested, do not allow users to store sensitive documents locally. These documents should be stored on a separate server that requires authentication. Logging accesses to HR documents would clearly be a good idea to track changes and ownership.

---
Tremaine Lea
Network Security Consultant
Intrepid ACL
"Paranoia for hire"



On 25-Nov-07, at 11:24 AM, WALI wrote:

It's a catch 22 situation and I need to make our Windows Xp workstations appropriately secure. Secure from rogue Helpdesk personnel as well as network admins.
The HR guys are complaining that their 'offer' letters to prospective employees and some of the CVs that they recieve are finding their way into unwanted hands. I suspect both HR application vulnerability, for which I am undertaking some vulnerability analysis but I also need to protect the PCs that belong to Dept. of HR employees from rogue IT guys.

Here are the basics of what I intend to do:
1. Advise all HR users to shutdown their PC before they leave for the day.
2. Change all Local Admin passwords so that even IT helpdesk/other doesn't know them.
3. Advise HR guys to assign passwords to their excel/word files.
3. Do not create shares off c drive giving 'everyone' access.

But...because they are all connected to Windows 2003 domain, I still risk someone from domain admin group to be able to start C$/D$ share and browse into their c: drive, what should I do?

Also, it's easy to crack open xls/doc passwords, what else can be done?

Alternatively, Is there an auditing on PC that can be enabled to track/log incoming connections to C$ and pop up and alert whenever someone tries it out from a remote machine.

Pls advise!!



Relevant Pages

  • Re: Service accounts best practices
    ... > The only people who should have domain admin rights are the exact people ... > domain admin work and it should be a very small group. ... >>>Joe Richards Microsoft MVP Windows Server Directory Services ... >>>>Can someone point me to a guide to securing service accounts? ...
    (microsoft.public.win2000.security)
  • Re: Permissions to unlock Administrator account?
    ... Use delegation for everything else. ... The Administrator accounts should have a very long, complex, password, be ... domain admin, and one for general day to day use. ... leaving only the Administrator account there (I ...
    (microsoft.public.windows.server.active_directory)
  • Re: Changing the domain password policy
    ... You could try to look into your AD event logs and check for Successful logons for the domain admin account. ... While the biggest thing to do is make sure you know your environment and what service accounts are used where, eventually you'll find yourself stuck and you just need to make the change and deal with what breaks. ... Time has come to change the domain admin password. ...
    (Security-Basics)
  • Re: W2k3 - Recover from lost Domain Admin passwords
    ... I understand and agree with what you're saying about the domain accounts, ... has changed ALL Domain Admin and Enterprise Admin user account passwords ... (including the Recovery Administrator password) ... > your passwords are more easily compromised if you leave this whole open. ...
    (microsoft.public.windows.server.active_directory)
  • Re: W2k3 - Recover from lost Domain Admin passwords
    ... I understand and agree with what you're saying about the domain accounts, ... has changed ALL Domain Admin and Enterprise Admin user account passwords ... (including the Recovery Administrator password) ... > your passwords are more easily compromised if you leave this whole open. ...
    (microsoft.public.windows.server.security)