17

My company requires that any time a user logs into a production server the reason that person logged in and the changes the user intends to make must be logged. My team wants to do this, but its easy to forget. I'd like to help them remember. I considered an motd, but want something a little stronger.

My first thought was to change the user's shell to a script that does something like

vim /logs/logindate.txt 
bash -l

Is there a better or more standard technique?

Note: The idea is that these users are sysadmins and would like to make the log entry without subverting the system- they just frequently forget to do so. So, if they can ctrl-c it, well...we're assuming they won't.

  • 6
    You're trying to find a technical solution to a workflow / procedural issue. IMHO, such an effort is doomed to failure, and the actual workflow / procedural issue should be addressed directly via non-technical means. – John Dec 10 '14 at 20:21
  • 11
    Thanks buddy. I'm trying to use technology to promote a behavioral change. I suppose I could just club them with a rock every time they forget, but I think HR prefers the technological approach. –  Dec 10 '14 at 20:26
  • 8
    @John Isn't part of the purpose of technology to implement and aid in workflows? – Michael Martinez Dec 10 '14 at 20:32
  • @BiggyDevOPs Well, John's right - if HR wants it to work, they'll have to let you use the rock. What you're proposing simply will not work, because the people required to use it will not want to use it, and will not get an value out of it. Last place I've been that used something like this ended up with entire Putty sessions pasted in as the reason/log/whatever mandatory "fill this out" field... and this was a major multinational corp that spend a lot of money and effort on the problem. – HopelessN00b Dec 10 '14 at 20:36
  • 1
    Disciplinary action, up to and including termination. – Michael Hampton Dec 10 '14 at 20:41
  • 4
    Yes, but the question wasn't "should you do it?" the question was, "can you do it?" One is a value judgement; one is a technical question worthy of this forum. I'm confident in my ability to manage my team. I could use the rock with great success, but so much blood. I like to be nice. I have good admins just forgetful ones. :) Looks like @aaron-copley is the man this time. Thanks everyone! –  Dec 10 '14 at 20:41
  • 1
    I get what they're trying to say. There's going to be a lot of "asdf" in the logs. But, you are turning "I forgot.. I'll log it next time." into an action that is deliberate and more actionable for HR. As much as we would like, we are not all the decision makers in our organization and can't tell HR to pound sand. – Aaron Copley Dec 10 '14 at 20:46
  • Have a look at this too: http://serverfault.com/questions/470755/log-all-commands-run-by-admins-on-production-servers/475134#475134 – fuero Dec 10 '14 at 22:24

5 Answers5

19

Look at pam_exec.so. You can run a script on login in the session interface of PAM's system-auth. The script runs as root before the user gets a shell, so it may not capture input with read? You can try, though, and use read to get a reason from the user and log it to syslog with a logger statement. (I've omitted below, but you can trap CTRL+C to prevent anyone from exiting without reason.) $PAM_USER will be set to the person logging in, so you can include that in the logger statement.

Example:

At the top of session in /etc/pam.d/system-auth:

session required pam_exec.so /usr/local/sbin/getreason

And /usr/local/sbin/getreason:

#!/bin/bash
read -p "Reason for logging into production: " reason
logger -t $(basename $0) "$PAM_USER logged in with reason: ${reason}"

Apologies if this doesn't work perfectly. I did not test it, but have recently done something similar. (It did not capture input.)

Edit: The more I think about this, the more I don't think it will work because of the stage in which it runs. The same getreason script should work after you replace $PAM_USER with $(logname), but it may need to be executed in /etc/profile. (Test for interactive shell, first.)

I'll leave both options up since it should at least get you thinking in the right direction if nothing else.

Aaron Copley
  • 12,345
  • 5
  • 46
  • 67
  • 1
    Thank you so much for this. It looks perfect. If nothing else I can write a little thing in C to capture the input. I'll implement this and let you know if it works. –  Dec 10 '14 at 20:36
  • 1
    @BiggyDevOPs: helpful suggestion: if you use a flat file to keep the log, put it in git or svn so that you have a history – Michael Martinez Dec 10 '14 at 23:59
7

The alternative is a privileged account management solution, where rather than giving administrators access with their own account, admin accounts are held in escrow by a third party and the mandatory procedures Have to be followed before administrators can access production systems http://en.m.wikipedia.org/wiki/Privileged_Identity_Management

HBruijn
  • 72,524
  • 21
  • 127
  • 192
0

Another way to accomplish this would be to have your centralized-logging facility (I'm thinking Logstash, but you can do this in other ways) take your auth.log on production systems, feed that into an app where people can log their justifications.

gWaldo
  • 11,887
  • 8
  • 41
  • 68
0

The way I've seen this implemented at customers who run HP Server Automation* is that they rely on the tool's innate logging with a combination of approval steps (I've been to several customers where there are no sudo or root privs except in Dev).

Approvals can be done via something like Remedy and Operations Orchestration, or administrative login inside SA, etc.

That all being said, outside of enterprise automation and management tools, @Aaron Copley's answer is an excellent choice.

* I am a senior HPSA, HPOO, and other aspects of the HP automation suite consultant

Community
  • 1
warren
  • 17,829
  • 23
  • 82
  • 134
0

While looking for a solution, I read Aaron Copley's answer and thought: "What if I change my user's shell?"

I did it successfully on my Ubuntu 14.04 machine:

# usermod -s /usr/bin/loginScript username

On your script you can capture the login's reason simply. Mine is like this:

#!/bin/bash
read -p "Tell me why you logged in:" reason
echo "You told me: $reason" >> /var/log/reasonLogin.log
/bin/bash

One thing you should note: the script is not run as root, so you may have to give the user some permissions to make this work.

William Monteiro
  • 9
  • 2