Need a technique to coerce sysadmins to log the reason for accessing a prod server

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.

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.

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