In the past, when it
came to password changes for all users, we had to log into each machine, and
manually change the password for each user. Not only was this time consuming,
but subject to human error such as incorrect passwords, which in turn could
cause an account to be locked out. In the past I have used NIS, but that was
deemed to be a security problem. I looked around a small expect script that
when run and supplied a username and password, would in turn run the passwd
program to generate a new password for the user. That was the first step, but
it needed to be surrounded by a lot more code in order to change passwords for
all the users and all of the systems. The first issue was to be able to go
through the entire password file and generate a new encrypted password for each
user. It was decided to come up with a master passwd file that contained all of
the users for any machine in the system. That is some users had accounts on all
of the machines, other users might only have an account on one or two master.
There is one system that contains that entire list of users, let’s call it
MasterServer. So the idea was to use the
password file from MasterServer, strip out the first column of that password
file and it will contain all of the users. Next generate the ascii of what is to
be associated with each user. In other words, the new password the user will
type in, not the encrypted password. The ascii type in word is generated from
the following website:
To run this program you
simply set the program length to 14 characters, set the password format to
“base64” and set the number of passwords to 88, then click generate. The
generated output is then associated with the column one entries from the passwd
file.
generate-file is a
script that merges the usernames with the ascii passwords in the following
format:
username:ascii-password
It must also not
generate any new passwords for users that are locked, daemons that don’t use
passwords, or for the user ‘root’. In the case of the root accounts, each
machine must have its own unique root password. The output of the generate-file
script is password-file, it will be fed into the password-change-program.
The heart of the password-change-program
is a small expect script, if expect is not installed, it must be installed
along with its dependencies. For a Solaris 10 installation, these packages were
installed. If the package’s name is indented, it is a requirement of its
previous package:
expect-5.45-sol10-sparc-local
coreutils-8.11-sol10-sparc-local
tcl-8.5.10-sol10-sparc-local
tk-8.5.10-sol10-sparc-local
render-0.8-sol10-sparc-local
xrender-0.8.3-sol10-sparc-local
zlib-1.2.5-sol10-sparc-local
gcc-3.4.6-sol10-sparc-local (and libgcc)
libiconv-1.14-sol10-sparc-local
libintl-3.4.0-sol10-sparc-local
gmp-4.2.1-sol10-sparc-local
All of these packages
were downloaded from www.sunfreeware.com.
That site is no longer around and has been replaced by unixpackages.com which
you have to pay to download from. You can always download the sources and
compile them yourself.
The password-change-program
takes as its input password-file and uses the system’s passwd program to
generate the encrypted passwords for all users. It is important to note that
while the machine one is using to generate the new passwords, that system would
have mixed results for someone attempting to log into it. It is impossible to
determine what state the system is in. It may have already generated the new
password for a particular user, before that user is notified, thus if he or she
attempts a login at that time they will be denied access. Fortunately the
program is being run on a management system that is primary used by the system
administrators to manage other machines and users have been notified that the
password change is in progress. The reason one would have mixed results is the
encrypted field in the /etc/shadow file is being manipulated, and depending
where in the process the password-change-program is, the user’s account may or
may not have been updated. Once the password-change-program completes, one has
a master list of encrypted passwords and new expiration dates.
The final piece of the
puzzle is a script called pullshadow. It must be pointed out that this entire
procedure must be executed by a user
that has access to all the machines the passwords are being updated on. Not
only does that user need access, but also needs the ability to log into all
remote machines without a password. This will be accomplished by using ssh and
no password secure access. To create the no password access, if it is not
already set up, perform the following steps:
Assuming the is being
created for user everywhere-user with remote access to remote-machine.
ssh-keygen -t rsa
That will generate a
key for user everywhere-user in the user’s home directory under .ssh
Now move that key to
the user’s home directory on the remote machine that the user must access.
cat ~everywhere-user/.ssh/id_rsa.pub
| \
ssh everywhere-user@remote-machine "cat >>
\
~everywhere-user/.ssh/authorized_keys"
The user will be
prompted for a password. After this initial setup, a password will no longer be
required. Now the pullshadow script will take advantage of this setup to
retrieve each shadow file from all remote machines and update that shadow
password file. Which machines are updated will be defined by a file named
hosts, located in the current working directory. The hosts file in the current
directory, is not to be confused with the /etc/hosts file. It has no bearing on
that file, it only the name of the remote host. pullshadow uses the contents of
host to determine which machines will be updated. pullshadow will copy the remote
/etc/shadow file to the local machine, update it, and then copy it back. All
users who were not locked out and that had a password will be updated. Each
root account on the remote machine will have a unique password as well.
