Wednesday, April 23, 2008

Today we're going to look at a feature of Solaris' passwd command that has been around since Solaris 9 ( If you read this and you like the functionality, but are still using Solaris 8, check out this page regarding Sun Bug ID 6227256, which basically states that this functionality will never be back-ported to Solaris 8. I always thought it was strange that they considered this a Solaris 8 "bug" since the extra passwd functionality wasn't introduced until Solaris 9. I would have filed it under "feature-set enhancement," like the /dev/random patch, but I guess that's neither here nor there.

In any event, our post today is going to cover the difference between using the passwd command to lock user accounts, make them no-login (which can also be done if you set the user shell to a "nologin" shell) and, ultimately, reverse the process if necessary. Of course, all of this can be done manually if you like to edit the /etc/shadow file by hand. I'd advise against it. It has the potential to turn out very badly ;) This "added" functionality can also be used to make our script to remove old users network wide (and its Linux counterpart) a little more flexible. Sometimes it's good to have options other than just "locking" an account (or manually setting NP) if you need to keep an account around, but don't want the user logging in anymore.

Generally, if you look in a standard Solaris box's /etc/shadow file, in the password column, you'll either see a regular password entry (encrypted), like "557LIW.RqHi92," a locked password entry, like "*LK*" or a "No Password" password entry, like: NP (The fair equivalent of a no-login password on Solaris 9 and 10).

You can always check what kind of password you have by running:

host # passwd -suser1 PS

This shows that our logged in account "user1" has a password set (PS). You can look at all users' password settings by running "passwd -sa," but you need to be root to do so. LK will stand for "locked" and "NL" means "no-login."

Now, moving along, there may be plenty of reasons you need to have an account locked and not removed from your system (That's your business. I'll stay out of it ;) The one thing to remember about a "locked" account (*LK* in /etc/shadow) is that it is truly barred from any activity. Not only can the account not login to the machine, it also can't make use of other services like cron, etc. A user account that has "no password" (NP in /etc/shadow) can't login to the machine either, but "can" use system facilities like cron. Changing a user account from "locked" to "no password" can be tremendously advantageous if you can't let the user log in any more, but still need to keep the account around to run nightly jobs, or what have you.

So, let's say we have a user (his login will be "badseed1") that we needed to restrict access to on our Solaris Box. Let's also say that we did it when the box was running Solaris 8, and we did the simplest thing possible and locked up his account by running:

host # passwd -l badseed1

So, now that we've upgraded to Solaris 9 (or 10), we get the following when we check on his account (let's say it turns out we really need his account to be performing some action that it hasn't been performing since we stopped letting him log in. We didn't notice for a really long time. We were busy!!! ;)

host # passwd -s badseed1 badseeed1 LK

And we have confirmation that his password is locked. This is good (in that it makes sense) because we know that "locked" accounts can't use cron. The first thing we're going to do is get his shadow entry up to speed. That is, we're going to leave his account locked, but change the way Solaris handles his entry. In Solaris 8, his password entry in /etc/shadow simply consisted of "*LK*", but we're going to change that to make it like everyone else's (This also makes our previous post on generating encrypted password strings somewhat obsolete, but still entertaining :). It will only take two passwd commands to do this and then we can see the difference:

Now, as you see, the user account is still locked but, instead of having just "*LK*" as his or her shadow password entry, the locked password is now simply the regular password with the "*LK*" string prepended to it. This allows us to do the following if we want to "unlock" the password and restore the user to the password they originally had without having to do anything extra!

Now, we just have one last thing to do before we can get on with our lives. We need to set up badseed1's account so that it's "no-login." We want badseed1's account to be able to run cron jobs, but we don't want the user to be able to login, so providing the "no-login" shell is a happy medium between the two extremes of absolute availability and complete lockdown. And, again, this can now be done with a single command:

And we're all set. badseed1 can no longer log into our systems, but his or her cron jobs will run!

Hopefully you'll find some good use for these two very helpful new options to passwd("-u" and "-N"), as well as the newer locking system used by the standard option "-l" ...ok, the options, as of the time of this writing, aren't technically "new," but they were at one point, and, hopefully, if they aren't new to you, this post has served as an enjoyable refresher :)