Handing Over Root Passwords to Clients and Contractors?

waa asks: "I have a client who's system I remotely administer. This particular machine has been up performing its various duties 'problem-free' for 4 months (since last kernel patch/fix). The client has, on-site, a consultant who pretends to know things he certainly does not know; Linux systems administration for one, and they now have requested the root password. Since it is their system, I'd imagine they have every right to the root account, however I know for sure that as soon as this is handed over, things will start to mysteriously malfunction, and I will get an emergency call to get them back in service (or worse, I will be blamed; ie: back-stabbed). I'd rather not have to troubleshoot and fix a completely preventable, and possibly complex problem. What are peoples' experiences regarding this situation? How have you handled it? Is some form of 'release from responsibility' contract in order? I need some advice soon" In situations like this, communication with the client is important. If you ever run into a situation like this, talking to the client and informing them of the potential problems is always a good idea. If any problems happen afterward. Start documenting them, and pass them back to the actual client if things start to become a problem. Anyone else care to weigh in?

Comments

tiered support

[gascsd]

Not sure about in private environments, but in academia-land, we (previous position) setup a tiered support level.

Tier 1: only we (comp supp group) have the root pw. for nt, we would also be the only ones with the local admin password

Tier 2: root password is shared. on nt, local admin password is shared, or they (customer) has the local admin password and we still have domain admin rights; all 9x machines and macs

Tier 3: we have no root/admin access at all.

Depending on the tier determined when we would get to them. If a grad student installs some software and hoses the machine, but it's tier 3, it may be a few weeks until we get to it. tier 1 machines we'd get to that day, or the next. tier 2 was generally in a few days.

Like I said ... that's in academia-land, where customers aren't paying (at least here). Tell your client, "if he fubars the machine, don't look at me" ... whether they go with that or not, who knows. doesn't hurt to ask

Well, here's one arragement I've seen (GM and EDS)

[Surak]

GM hires EDS to do all their sys admin stuff. They wrote it into the contract that GM doesn't have the root password, only EDS. However, some machines that are not EDS maintained only GM has the password. There may be other machines where GM and EDS share the password.

In any case, anytime only EDS has the password, these are the machines that get maintained in the most timely manner. Machines where EDS does not have the root password, or where the root password is shared don't get as much service. So it is to GM's advantage to have most of their machines be purely EDS managed, as those are the machines where the serivce level agreements are pretty much guaranteed.

How about logrotate, kerberos, CVS, groups

[QuietRiot]

I've been working as a student systems administrator for a computer lab at Cornell for the last 3 years on linux and NT systems. We've got lots of students with root access to some machines quite critical to the operation of the lab. We have had, on many occasions, situations where a lack of communication and multiple people working on the same project/server/whathaveyou, shall I say, stepped on eachother's toes. I'm not sure if we ever implemented any of these, but I've done some thinking about it! (especially after a day's worth of work on a config file gets blown away by a vi edit from another guy with root who doesn't know what he's doing....) Anyway, here's a few things you could do...

1) Set up a cron job to backup configuration files
You could either write a simple script to tar up /etc/* or whatever other files your clients might want to fowl up. Or you could use the logrotate program. It's a flexible solution to manage log files and could be used to tar up and compress periodically the files you'd like to backup should anything get messed up.

2) Use the "wheel" group
to allow only certain users to perform administrative functions on files you chown root.wheel. You could also do this for a "web" group (#chgrp -R web /home/www) or anything else to give access to certain files for certain people. Instead of "giving them root," ask them which users want to have control over which sets of specific files on the system, make groups for each set of files, and add the users to the group that need access. This would allow you to track down more easily who modified a certain file, since only a few people may have had access to it. (easier finger pointing basically). This is much better than knowing that a bunch of people could have done it, and getting blamed for it yourself.

3) Setup sudo
Edit /etc/sudoers

4) Use process accounting

5) Set up a simple kerberos5 installation
This allows you to give root [or any other administrative-type account function] access to certain users via a ".k5login" file. This allows you [root] to simply add users who are allowed root access [to kerberized services] by putting their principal [system user account name] in root's .k5login file. You needn't give them the root password. They can just login as themselves and they will be allowed to use their own tickets to access kerberized services that require a "root" principal. All access is logged so that backtracing who did what and when would be possible. Note: This may be an unnecessarially complex method to implement. It can however be used for a wide variety of services and is considered quite secure and flexible, particularly for large networks. It won't work for general file access, but if you can kerberize some of the services you'd like to administer, this would help immensely.

6) Tell them to make backups before they change anything or implement a CVS system
on all config files that anyone would want to changeCVSing config files would force documentation and allow you to revert to any previous incarnation of your system if something somehow "broke."

Hope this helps!