Troubleshooting Passwords

Language:

The following examples suggest ways to debug problems with passwords. For background information, see the passwd(1) and user_attr(4) man pages.

Example 79 Using the openldap System Account to Run a cron Job

In this example, the administrator changes the password string for an Oracle Solaris-delivered system account from *LK* to NP. The account runs a cron job that updates the data in the directory periodically with an external data source over a UNIX domain socket that is locked down to the openldap user only.

Initially, the openldap account is locked. The time that the password was locked is 12111.

# grep openldap /etc/shadow
openldap:*LK*:12111::::::
# passwd -N openldap 
WARNING: changing account in reserved uid range: openldap.
passwd: password information changed for openldap

The –N makes the password entry a value that cannot be used for login with UNIX authentication.

# passwd -u openldap
WARNING: changing account in reserved uid range: openldap.
passwd: password information changed for openldap

The –u option unlocks the account. The account remains a non-UNIX authentication account.

# grep openldap /etc/shadow
openldap:NP:13222::::::

In the final entry, the openldap non-UNIX authentication account has no password. The account is protected by the locked-down UNIX domain socket.

Example 80 Creating a Role That Requires the User's Password

This example shows how to configure administrative accounts to be authenticated with the user's password, similar to the way the sudo user is configured. In the root role, you create the user and the role, make the role require the user password, and assign the role to the user.

# useradd [ ... ] jdoe
# roleadd [ ... ] administrator
# rolemod -K roleauth=user administrator
# usermod -K type=role administrator jdoe

Example 81 Overriding the Password Requirements for an Account

In this example, the root role changes a password several times, overriding the password constraints.

# passwd -n 14 -x 25 user1

The /etc/shadow entry resembles the following:

user1:$5$Cuz1WCgx$4CFN...:last-changed-date:14:25::::

The administrator in the root role is able to change the password several times the same day:

# passwd user1
Enter user1's password: password
# grep user1 /etc/shadow
user1:$5$Cuz1WCgx$4CFN...:11333:14:25::::
# passwd user1
Enter user1's password: password
user1:$5$Cuz1WCgx$4CFN...:11444:14:25::::

Because the root role has the solaris.passwd.assign authorization, root can override the password constraints of a minimum of 14 days between password changes (-n 14) and a maximum of 25 days (-x 25). user1, who does not have the solaris.passwd.assign authorization, cannot change the assigned password for at least two weeks. As the following shows, the user also cannot change another user's password:

$ passwd user2
Enter user1's password: password
Permission denied: Missing authorization: solaris.passwd.assign