Managing Non-Login and Locked Solaris Accounts

Today's entry will focus on enhancements to the passwd(1) command to better support the distinction between locked and non-login accounts. Specifically, we will be looking at the new -u and -N options to the passwd(1) command as well as how they relate to the much older -l option. These new capabilities will help administrators obtain better control over how their accounts are accessed and how they can in fact manage those accounts. In the past, some of the interfaces discussed below could only be achieved through manual editing of password files. The addition of these new command line options provides a much safer option for administrators to use.

While the distinction between non-login and locked accounts has existed in Solaris for many years, it became more pronounced in Solaris 9 where the semantics of locked accounts were more rigidly enforced.

Many customers noticed, for example, that locked accounts could no longer execute jobs using cron(1M). This problem was exacerbated by the fact that many commonly referenced security recommendation guides tell users to lock all of the accounts to which interactive access was not needed (which is most of the default accounts). When this was done, cron jobs for accounts such as "sys" (used for collecting system activity records) stopped working. This problem highlighted the intended difference between non-login and locked accounts and the need for additional interfaces to control them.

For those not already aware, a non-login account is one that must exist on the system (to provide a UID for example) but should not be allowed to login to a system interactively. That is, while a non-login account may be able to leverage delayed execution mechanism such as cron(1M), they cannot access the system using login(1), telnet(1) ftp(1), ssh(1), etc. Accounts that are non-login will have the token NP as their password. You can also identify non-login accounts using the passwd(1) command:

# passwd -s daemon
daemon    NL
# grep "\^daemon:" /etc/shadow

In this case, the daemon account has been configured as a non-login account.

A locked account on the other hand is one that is not permitted to access the system in any way - it is locked. A locked account differs from one marked as non-login in that locked accounts are not permitted to use delayed execution methods like cron(1M). Locked accounts are those whose password string has the prefix \*LK\*. Further, you can identify locked accounts using the passwd(1) command:

# passwd -s listen
listen    LK
# grep "\^listen:" /etc/shadow

In this case, the listen account has been locked.

Here is a practical example. In this case, I will add a new account gmb to the system. By default, new accounts created using useradd(1M) are locked. After assigning a new password, I will demonstrate the use and result of the new -N and -u options to the passwd(1) command in addition to the -l option which has been around for ever.

First, let's create a test account called gmb. You will notice that by default the account will be locked.

# useradd -d /export/home/gmb gmb
# passwd -s gmb
gmb       LK

Next, a password will be assigned to the gmb account in the usual way using the passwd(1) command...

# passwd gmb
New Password:
Re-enter new Password:
passwd: password successfully changed for gmb
# passwd -s gmb
gmb       PS
# grep "\^gmb:" /etc/shadow

You will notice that the "passwd -s" command now returns the keyword PS for "password set". If the account did not have a password defined, the keyword NP (for "no password") would have been returned.

Now that we have a password, let's lock the account and see what happens to the password string in /etc/shadow as well as to the output of "passwd -s":

# passwd -l gmb
passwd: password information changed for gmb
# passwd -s gmb
gmb       LK
# grep "\^gmb:" /etc/shadow

You will notice that the account was in fact locked, but what is new in Solaris 10 is that the password string is not replaced with the "\*LK\*" value. Instead, a "\*LK\*" string prefix is prepended to the password so that the original value can be kept if desired. The great thing about this is that it does not depend on the password algorithm used. With the addition of flexible crypt in Solaris 9, you can replace the default crypt algorithm with either others provided by default in Solaris or one of your own and this new locking mechanism will still just work.

To unlock a locked account, you just use the new "-u" option to the passwd(1) command:

# passwd -u gmb
passwd: password information changed for gmb
# passwd -s gmb
gmb       PS
# grep "\^gmb:" /etc/shadow

The account is now unlocked and the "\*LK\*" prefix has been removed from the user's password string. The last thing that we will look at today is how you create a non-login account. To do this, simply use the "-N" option to the password command:

# passwd -N gmb
passwd: password information changed for gmb
# passwd -s gmb
gmb       NL
# grep "\^gmb:" /etc/shadow

You will notice that the user's original password has been removed and replaced with the string "NP". This account is now a non-login account and the original password has been discarded. You will not be able to login to this account, but the account will be able to make use of delayed execution facilities. To re-enable an account for interactive logins, simply reassign a password to the account using the passwd(1) command.

That's all for this installment. I hope you find this kind of information useful. In future installments, I will continue to highlight some of the lesser known enhancements that contribute to Solaris security in the hopes of raising awareness and their use.

Technorati Tag:


Cool info. Any ideas if there is a plan to make an account su only? I.E. we have a need to make an account su only so it can not be logged into from a remote source (i.e. ssh, telnet, etc). But still be able to run cron jobs, etc... thanks

Posted by Jason on September 22, 2004 at 07:36 AM EDT #

Jason - thank you for your feedback. It is very much appreciated! As far as making an account 'su' only - that is achievable today using the Solaris Role-based Access Control facility that was introduced in Solaris 8.

I was thinking about doing a more detailed example on this in a future blog, so I will just provide you with the necessary details. To manage roles on a system, you can use the roleadd(1M), roledel(1), and rolemod(1M) commands. The manual pages for these commands will give you everything you need. You can also get more information on roles, rights and privileges (Solaris 10 only) in the System Administration Guide: Security Services book (Solaris product documentation).

To change an existing account from a regular user to a role, you could just add/modify the user's entry in the /etc/user_attr file (or its naming service counterpart), as follows. Change:




After making this change, the user gmb will not be able to log into the system directly. You will only be able to 'su' to that account once you have already successfully logged into the system.

Hope this helps! Please let me know if you have any questions.


Posted by Glenn Brunette on September 23, 2004 at 06:27 AM EDT #

Thanks for the info. The version of ssh I am running (from is not role aware.. so I can still log in to the account even after making it a role. Will have to see if I can fix that..

Posted by Jason on September 24, 2004 at 06:26 AM EDT #

Did you ever find a solution for ssh?

Posted by Patrick on October 01, 2004 at 02:55 AM EDT #

Jason, Patrick,

Can you configure your versions of Secure Shell to use PAM? If so, you should be able to use Solaris "roles". Take a look at your product documentation and/or manual pages for "Keyboard Interactive" support. There should be an option to enable this in your sshd_config file.

If not, you should file a bug with your Secure Shell vendor to support this core feature of the Solaris OS. This capability has been available since Solaris 8. I had thought, however, that most vendors did support this today.


Posted by Glenn Brunette on October 01, 2004 at 06:47 AM EDT #

This is simply great information on such a common and utility I thought I already knew how to use. Thanks for bringing this to my attention. I wonder if there's "big fat diff" somewhere that shows me what has changed from Solaris 8 to 9 and from 9 to 10. I think it would be fun if I could find some of these gems on my own without an exhaustive search through the man pages. The release notes generally talk about whole subsystems which get added or removed, but not like: "Hey, a new option was added to the passwd(1) command, and here's what it does..."

Posted by Dale Sears on November 28, 2004 at 07:38 PM EST #


Thank you very much! I am happy to hear that you found the article useful. I will be working on a few more Solaris 10 security articles to appear here in the near future. Keep on the lookout for them!

To answer your question, have you taken a look at the Solaris 10 What's New documentation? There is a section in this documentation called "Features by Release Date". It is at the end of the list of sections. I think that may do the trick for you. Let me know.

If not, please consider filing an RFE against the Solaris documentation in order to better fit your needs. This is a great way to get your voice heard and your requirements recorded. Please feel free to submit a follow up comment with the RFE identifier so that others who may be interested can add their voice and requirements to the list.

Thank you again! Take care,


Posted by Glenn Brunette on November 29, 2004 at 08:10 AM EST #

Yes, Features by Release Date was the kind of info I was looking for. It's just named with a more mature name than "big fat diff." So it was hard to find... ;-) ... Thanks again!

Posted by Dale Sears on December 05, 2004 at 05:50 PM EST #

Post a Comment:
Comments are closed for this entry.

This area of cyberspace is dedicated the goal of raising cybersecurity awareness. This blog will discuss cybersecurity risks, trends, news and best practices with a focus on improving mission assurance.


« June 2016