Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We are a relatively small shop (as far as number of sysadmins) with a mix of RHEL, Solaris, Windows 2003 and Windows 2008 servers; about 200 servers in all.

For our administrator accounts (root in Linux and admnistrator in Windows), we have a password scheme that depends on the data center location and a couple of other documented properties of the server.

On Linux, our current practice is to create a shared non-privileged account where we could su to root. On Windows-based systems, we create an additional account with administrator privileges. Both of these accounts share the same password.

This has proven to be very inefficient. When somebody leaves our shop, we have to:

  1. Change the password scheme for the administrator accounts
  2. Generate a new administrator password for each and every server
  3. Come up with a new non-administrator account password
  4. Touch every server and change the passwords

I wanted to know if anyone in a similar environment can suggest a more sane way of managing these credentials. Some relevant information:

  • Although most of our servers are part of our AD domain, not all are.
  • We manage all our Linux servers with Puppet (key authentication was an option I thought of but it will only address the #3 concern from above).
  • We provision Linux severs with Cobbler.
  • About 10% of our hardware is dedicated to VMWare. In those cases, we use VMWare templates for server builds.

Any ideas or suggestions will be greatly appreciated. This is a problem that has been lingering for some time and I finally want to resolve it.

share|improve this question
add comment

3 Answers

up vote 10 down vote accepted
+50

A few suggestions I would have are:

  • Windows AD connected servers can have their local administrator passwords set through group policy by using either Group Policy Preferences (GPP) or a computer startup script. See http://social.technet.microsoft.com/Forums/en-US/winserverGP/thread/b1e94909-bb0b-4e10-83a0-cd7812dfe073/

  • Limit creation of local accounts on Windows servers unless required. Use AD accounts when possible.

  • Use LDAP for Linux computer to authenticate administrator accounts to AD. This simplifies account management somewhat. And when an admin leaved just disable in one place and no access, then you can clean up the Linux side at your leisure.

  • Use /etc/sudoers file for specific admin account on linux then the admins don't need the root password. This may be good in your instance because then they will rarely need the root password so it can be locked away. Updated

  • Keep root and local administrator passwords in a password safe not general knowledge. Some password safes have delegation and logging so you may not even need to reset a password if the person never had access to it.

  • Automate password reset process for root and admin accounts. Both Linux and Windows can be scripted to do this so it may save you some time and not make it so much of a burden.

Hope that helps.

share|improve this answer
    
My issue with LDAP is the one point of failure. I'd rather manage accounts via Puppet. And appreciate your suggestions. Thank you @Bernie! –  Beaming Mel-Bin Sep 16 '11 at 2:24
1  
@Beaming If you use Active Directory you can have more then one Domain Controller (no single point of failure) and then point to the DNS domain name e.g. domain.com to get all the domain controllers for an LDAP query. Or you can setup a A DNS record to point to specific DCs if you only want two or three to respond to LDAP like ldap.domain.com. I have'nt used Puppet but the key to easy user administration is haven't a single source where possible. It would be likely that Puppet could connect to a back-end LDAP server anyway if you preferred it that way. –  Bernie White Sep 16 '11 at 2:31
    
Agreed that AD is the way to go here. With 2+ domain controllers, the likelihood of AD completely going down is slim, but also, if it does, you likely have much bigger issues. Maintain local root accounts on your linux servers to be used as a last-resort if all else fails. –  EEAA Sep 17 '11 at 18:44
2  
@Bernie - regarding your 3rd point. When using sudo, no one ever needs to know the root password. By specifying "NOPASSWD" on a sudo entry, the user does not need to enter their own password. This has nothing to do with the root password. –  EEAA Sep 17 '11 at 18:46
    
@ErikA +1 Very true. Removed reference to NOPASSWD as it doesn't help answer the question/ –  Bernie White Sep 18 '11 at 8:17
show 2 more comments

You can try and see if FreeIPA works for you.

You can manage user access to hosts from a central location. As suggested by others, you can see if sudo works for you for root level access. Freeipa supports sudoers in LDAP, so you don't have to maintain it on each server or via puppet etc.

Freeipa supports Linux, Solaris and Windows clients. You may lose certain AD features and I'm not sure what other limitations a Windows client will have.

It has replication features, so you can avoid a SPOF. The backend is LDAP, so you can possibly reuse many tools that people use for LDAP, like backup scripts.

It supports host based access control, so you can say "user X can only login to Y servers".

It also offers AD synchronization. I'm not a Windows person, so I have no idea what that even means.

share|improve this answer
add comment

Don't use the standard Administrator account. On the Windows side of things, create a user account and an Admin account for each user who needs Admin access. You can use any tool to sync to UNIX.

If someone leaves, then you just need to delete their user and Admin accounts.

To secure the standard Administrator account, give it a really long and complex password, then make sure that any one person only has half. If they need to use the whole account, then they need to go find someone who has the other half.

That's about as secure as I can think of.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.