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 JobIn 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 PasswordThis 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 jdoeExample 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