Solved

How do I efficiently manage local (workstation) Administrator accounts in a large network?

Posted on 2004-08-18
7
514 Views
Last Modified: 2013-12-04
I am an IT auditor and have a client that is currently using the same (local) Administrator password for ease of use of administration on all company desktops and laptops. Obviously this is a poor solution for security and accountability on the networks (see my last question: http://experts-exchange.com/Security/Win_Security/Q_21060579.html), so I've suggested that a "desktop admin" network group be created, that tech support individuals be added to this group, and that all desktops/laptops be configured to include this group in the local Admininstrator group on each desktop/workstation. The Admininistrator password should either: 1. be set the same for all desktops, known by only one person (who doesn't use it except in emergencies), and written down in a sealed envelope placed in a locked safe; 2. set differently for each desktop and stored in a database that logs access to the password for each machine and requires that password to be changed thereafter.

The client has agreed to do #1 above, but pointed out a conflict. What if a workstation (desktop/laptop) in need of tech support can't access the network because there is a problem with the network card/configuration or because the user is working remotely (users aren't admins on their own machines)? If the user is at the corp. office, I suppose the one person that does know the Admin password would have to log into that machine to make the necessary configuration changes. What if that person is out of town? That would require opening the sealed envelope in the safe, then subsequently changing the password on all hundreds of workstations and with a new password to be sealed in the safe. Also, if the user is working remotely out of town and can't access the corp. VPN, then how can tech support assist the user over the phone in resolving issues that may require Administrator priveleges, without divulging the password? I assume in this case the user would just have to return back to the corp. office for repairs (unless alternative #2 above is used, which is logistically complicated).

My question: is there a better alternative than #1 or #2 presented above? How can we resolve the conflicts pointed out by the client? What do all of you network admins out there do to resolve these issues?

Thanks in advance for the help.

Bemelee
0
Comment
Question by:bemelee
  • 3
  • 3
7 Comments
 
LVL 11

Expert Comment

by:Quetzal
ID: 11837727
Having administrative access to a desktop/laptop should only permit access to the local resources of the machine itself; access to network resources should be governed by the domain/AD and by firewalls.  

Create a "master" admin account for desktops/laptops that will only be used on those machines, secure it's password in the manner you have suggested (i.e. limited to a small trusted audience).  Create a "public" admin account for desktops/laptops that will only be created on those machines, the password to this account can be given out to people in situations where no other alternative will work.  The "master" admin account can change the "public" admin account password periodically.  

Users who acquire the "public" password could conceivably use it on other machines, but it presumes that they can gain access to the machines and they will only be able to affect that machine.

IMHO, the primary user of a laptop should be made a member of the local adminstrators group.  There are many issues that are mitigated by doing this.  Yes, they can do things to their laptop that could screw it up, but they are only going to hurt themselves.
0
 

Author Comment

by:bemelee
ID: 11837854
Quetzal, a few points to reply to your comment:

a. I agree that the easiest solution is to make the primary user an administrator on the local machine, but this company has decided that they will now do that. If this is the only realistic solution, then perhaps I will push harder for them to make the change.

b. If I understand you right, you are proposing a modified version of my alternative #1, with the following admin-level accounts in addition to the network-level "workstation-admin" group that is assigned to the local admins group on each workstation:
i. master-admin local account on every workstation, with the same password for every workstation, and the password is known by one IT person, sealed in a safe, NEVER known by another person (this account essentiall is THE Administrator account on each workstation, possibly renamed)
ii. public-admin local account on every workstation, with the same password for every workstation. Who should know this password? If only one person knows it, then I don't see any reason for a master-admin AND a public-admin account (unless they are different people...see d. below). And if only one person knows it, what happens if he isn't in when the user needs tech support? If multiple people in tech support know it, then this is hardly different than the way they are operating now, which is unacceptable because multiple people know the same password for an extended period of time, and this is exactly what we are trying to avoid.

c. Please keep in mind that ideally, the rules are: that no two people should EVER know the same password, except in an emergency situation, and these situations should be as limited as possible, and have a way of almost immediately changing the password after the emergency is resolved. The perfect solution would be a situation where no two people EVER know the same password, without exception, but this would probably require giving users local admin rights to their machines.

d. Your thoughts on multiple workstation admin accounts gave me an idea for a third alternative: create one admin account on every workstation for each tech support person. So if Bob, Bill, and John are all in tech support, then every workstation would have a bob-admin, bill-admin, and john-admin accounts. The bob-admin password would be the same on every workstation, and only Bob would ever know that password, unless he had to give it over the phone for tech support, in which case he would immediately change the password and propogate it out to all of the workstations on the domain. This seems to be more complicated than my database idea (alternative #2), so probably isn't worth it.

e. What is happening in the real world? (I know my company gives local admin rights to primary user of each workstation, so this isn't an issue for us.) I can't imagine that companies out there with hundreds or thousands of workstations are setting the same Administrator password on every machine, and then giving that out to a user over the phone for tech support. What are they doing instead, in cases where users don't have local admin rights? Not providing tech support requiring admin privileges over the phone? Unable to administer workstations that aren't connected to the network?

Bemelee
0
 
LVL 11

Accepted Solution

by:
Quetzal earned 250 total points
ID: 11839938
First, let me say that I don't have personal experience supporting thousands of workstations, but I believe that these issues are very similar to those I have encountered in smaller environments because the security issues are very similar.

Let's touch base on the idea of the workstation network admin group.  Presumably the membership of this group can change over time.  Therefore it seems to me that the best you can achieve with this group is the ability to do a domain logon to each workstation/laptop.  The rub comes when the issue facing the machine is that it can't see the domain.  In this situation, unless the support person trying to logon has done so before and has cached credentials, then a domain logon cannot happen.  Where a domain logon cannot happen, there must be a locally defined user name, with admin privileges that can logon to the machine.  If the machine is going to be serviced in the field by someone other than members of the admin group, they are going to need to know a user name/password that gives them access to the machine.  Presumably, once the machine is serviced and has visibility on the domain, someone in the admin group can login to the machine and change the local admin password to something new.  The only way to avoid a scenario in which an end user must know a local admin password is simply to say that either a admin person must travel to the machine or the machine must travel to the admin group; both situations are typcially going to be expensive or impractical or both.

Let's take this one step further.  Suppose every desktop/laptop were to be set up with a modem and pcAnywhere.  Then in situations where domain access is not available, someone in the admin group can use dialup access over pcAnywhere to login to the machine.  They will still need a local admin account, but they don't have to reveal information to the end user.  HOWEVER, there are still going to be cases where telephone access isn't available, doesn't work, the end user can't figure out how to set it up, the software does work....etc....and you are still going to be faced with the basic issue that, if the machine, is to be service in the field, the end user will need to know an admin account name and password.

A high-level executive traveling with their laptop getting ready to make an important presentation probably won't accept "gee, I think you're going to have to wait until we can see the laptop" as an answer.  If you agree with this basic analysis, then one must accept the premise that the desktop/laptop is going to have one or more local admin accounts with passwords that could become known to end users.

The idea of creating local admin accounts for individuals in the workstation admin group won't work.  If group membership changes, you now have accounts that need to be deleted and created.  The local admin accounts must be "generic".

The idea of creating local admin account/password that is unique to every desktop/workstation for purposes of end user manipulation has some attaction.  If the user must ever be given this information, it will only be useful for their particular machine and no other.  HOWEVER...there must always be one local admin account that can be used to gain control over the machine or else you could end up in a situation where you could lose access to information that was stored locally.  You can do this by creating a second unique name/psw that is used only the admin group.  But this creates a new issue....with thousands of machines, you will definitely need a database....and god help you if that database is ever lost or corrupted.  Not only that, but someone has to set up these accounts in the first place...they are going to know this information.

IMHO, it boils down to this.  It is virtually impossible and extremely impractical to think that you can create true secrecy within the admin ranks.  And I predict that if you attempt to do so, it will either result in added costs, signifcnat complexity, and the potential for a major FU to happen.  So I opt to observe the following:

1. Keep important and sensitive information on centrally-located servers whenever possible.  These servers should have controlled physical access.

2. Implement a multi-level admin scheme that delegates appropriate admin privileges on a "need to use" basis.  The higher level accounts have more privileges and must be known by fewer people and the these people must be more trusted.

3. Select your admins carefully and make sure that you have a well-defined policy that each admin must sign.  They need to understand that they bear significant legal and financial consequenses for possessing account info.

4. Limit the information that is stored on desktops and laptop.  Use Terminal Services or Citrix, webmail etc in order to access central servers from the field.  Implement offline files that will synchronize  with central servers.
0
Highfive Gives IT Their Time Back

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

 
LVL 11

Expert Comment

by:Quetzal
ID: 11839965
Here is the safest scheme possible for desktops and laptops in the field.  Implement TS/Citrix.  Allow no local data to be stored on the desktop/laptop...effectively they will all be dumb terminal devices to central servers.  If something happens that renders a desktop/laptop unusable, simply use a different device (implement a web interface to TS/Citrix and you can logon at any Internet cafe).  In this manner, everyone will have access to their desktop wherever they are, but administrative security will be centrally adminstered over centrally-located servers.
0
 

Author Comment

by:bemelee
ID: 11841964
Quetzal, excellent analysis! I agree with everything you said, and would like to point out one additional item that is of high importance for this particular client. Workstations are used to remotely connect to a mainframe with extremely sensitive information (through SSH sessions). This occurs on a regular basis over the LAN, and therefore even if all critical data is stored on servers instead of workstations, local admin rights are still very important to these workstations (since a backdoor or keystroke logger could be installed, and the mainframe admin credentials could be easily stolen).

My conclusion is that if users aren't given admin privs on their own workstations, there is NO SIMPLE SOLUTION to providing tech support to workstations that can't connect to the domain, and the best solution in cases where password sharing should be kept to an absolute minimum is probably a database used to store the unique password for each workstation.

[As a side note, I think it is silly not to give the primary user of laptops admin privs since he has physical control of the laptop and can therefore easily obtain those privs if he wants (e.g., boot on a CD or floppy disk to reset the admin password, execute a privilege escalation exploit, etc.).]

The risk that someone steals the mainframe admin logon credentials is such a critical threat that I will recommend to the client that they do one of the following: 1. give local users (of at leasthe laptops) admin privs, 2. implement the database solution, or 3. restrict mainframe access on a network level to a few source IP addresses/workstations on the LAN, then implement a more strict local admin scheme for those limited workstations. Do you agree?

Bemelee
0
 

Author Comment

by:bemelee
ID: 14004055
Sorry, I was waiting for confirmation from Quetzal, but since he doesn't seem to be replying I'll go ahead and accept his answer. Thanks Quetzal!

0

Featured Post

Highfive + Dolby Voice = No More Audio Complaints!

Poor audio quality is one of the top reasons people don’t use video conferencing. Get the crispest, clearest audio powered by Dolby Voice in every meeting. Highfive and Dolby Voice deliver the best video conferencing and audio experience for every meeting and every room.

Join & Write a Comment

Our Group Policy work started with Small Business Server in 2000. Microsoft gave us an excellent OU and GPO model in subsequent SBS editions that utilized WMI filters, OU linking, and VBS scripts. These are some of experiences plus our spending a lo…
OfficeMate Freezes on login or does not load after login credentials are input.
Excel styles will make formatting consistent and let you apply and change formatting faster. In this tutorial, you'll learn how to use Excel's built-in styles, how to modify styles, and how to create your own. You'll also learn how to use your custo…
This video demonstrates how to create an example email signature rule for a department in a company using CodeTwo Exchange Rules. The signature will be inserted beneath users' latest emails in conversations and will be displayed in users' Sent Items…

705 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

18 Experts available now in Live!

Get 1:1 Help Now