Managing Passwords

Change password

A user may change their password from within the EMu Windows client. The new password is checked to see if it conforms to minimum standards (e.g. length, character mix, etc.) before being set.

See Change Password Registry entry for details.

Password expiry / ageing

An expired password occurs when a user has not changed their password within a prescribed number of days. Once the password expires, the user must set a new password the next time they log in to EMu. They will be prompted for the new password.

Password ageing allows a System Administrator to force users to change their password within a given number of days. For example, your institution may have a policy that users must change their passwords at least once a quarter.

Solaris 10

The passwd command is used to set up password ageing on Solaris 10. The format of the command is:

passwd -n min -x max user

where:

min

is the minimum number of days required between password changes.

Not supported by EMu due to limitations in Solaris.

max

is the maximum number of days for which the password is valid. Once max days have elapsed without a password change, the user will be prompted for a new password at the next successful login. A max value of -1 is used to disable password ageing.

user

is the name of the user account to which the restrictions are to apply.

The default values for min and max are defined in the file /etc/default/passwd. There are two variables used to set the minimum and maximum ageing values:

MINWEEKS
The minimum number of weeks between password changes. The default value is empty, implying no minimum is set.

Not supported by EMu due to limitations in Solaris.
MAXWEEKS
The maximum number of weeks between password changes. The default value is empty, implying no maximum is set.

Setting the minimum and / or maximum default values to non-empty in /etc/default/passwd will result in users without ageing having it enabled the next time their password is modified.

Password ageing is supported by the Shadow and NIS+ password databases. LDAP and AD also support password ageing via the shadowAccount class object.

Linux

The chage command is used to set up password ageing on Linux. The format of the command is:

chage -m min -M max user

where:

`min`	is the minimum number of days required between password changes. A value of zero indicate there is no minimum.
`max`	is the maximum number of days for which the password is valid. Once max days have passed without a password change, the user will be prompted for a new password at the next successful login. A max value of `99999` is used to disable password ageing.
user	is the name of the user account to which the restrictions are to apply.

The default values for min and max are defined in the file /etc/login.defs. There are two variables used to set the minimum and maximum ageing values:

PASS_MIN_DAYS
The minimum number of days between password changes. The default value is zero, implying no minimum is set.
PASS_MAX_DAYS
The maximum number of days between password changes. The default value is 99999, implying no maximum is set.

Setting the minimum and / or maximum default values to non-empty in /etc/login.defs will result in users without ageing having it enabled the next time their password is modified.

Password ageing is supported by the Shadow password database only. LDAP and AD also support password ageing via the shadowAccount class object, however changes to a user's settings must be made via ldapmodify or an ldap client (e.g. Active Directory Explorer for AD).

FreeBSD

FreeBSD provides a limited form of password ageing. Rather than setting a minimum and maximum number of days between password changes, it allows you to set the date on which a password should expire. Once the date arrives the user will be prompted for a new password. The pw command is used to set the date on which a password expires:

pw usermod user -p date

where:

user	is the name of the user account to which the restrictions are to apply.
`date`	is the date on which the password will expire. The date format is dd-mmm-yyyy (e.g. 23-Oct-2011). An empty value is used to remove an expiry date.

When the new password is set the expiry date field is cleared.

If you want to have a new expiry date calculated automatically when a password is set, you need to specify the passwordtime attribute in the login class file located at /etc/login.conf. The login class file allows a set of system attributes (resource usage, etc.) to be set on a login class basis. A user is then assigned to a login class using the pw command:

pw usermod user -L class

where:

user	is the name of the user account to be added to the login class.
`class`	is the class name as specified in the file `/etc/login.conf`.

To set the system wide password expiry date, the default login class should be modified to:

default:\

	:passwordtime=time:\

...

where:

time	is the time interval to set for a password to expire. A large number of formats are available for the value with `nnnd` being the most common. For example, 90d would indicate the password will expire ninety days after it was last set.

If you change values in /etc/login.conf, you need to rebuild the internal database by executing:

cap_mkdb /etc/login.conf

Password ageing is supported by Unix and NIS+ password databases only. LDAP and AD also support password ageing via the shadowAccount class object, however changes to a user's settings must be made via ldapmodify or an ldap client (e.g. Active Directory Explorer for AD).

Examples

Our institution has a policy that passwords must be changed at least once a quarter. There is no minimum time between changes.
Solaris 10

As the policy is a default setting the best solution is to edit /etc/default/passwd and set the following entries:
```
MINWEEKS=
```
```
MAXWEEKS=13
```
Linux

As the policy is a default setting the best solution is to edit /etc/login.defs and set the following entries:
```
PASS_MIN_DAYS=0
```
```
PASS_MAX_DAYS=90
```
FreeBSD

As the policy is a default setting the best solution is to edit /etc/login.conf and update the default login class to contain the following entry:
```
default:\ 
```
```
	:passwordtime=90d:\
```
```
	...
```
Windows

If the setting is to be domain wide, then the Global Security Policy should be updated, otherwise if it is machine specific, the Local Security Policy should be used. The following attributes should be set:

Minimum password age set to 0.

Maximum password age set to 90.
We have a default policy of forcing password changes every quarter, however we would like to disable password ageing for a certain user (boris)
Solaris 10

The following command may be used to disable password ageing for user boris:
```
passwd -x -1 boris
```
Linux

The following command may be used to disable password ageing for user boris:
```
chage -M 99999 boris
```
FreeBSD

The following command may be used to disable password ageing for user boris:
```
pw usermod boris -p ''
```
Windows

View the properties for the user account. If Active Directory is enabled, run dsa.msc to view Active Directory users, otherwise run lusrmgr.msc to list local users. Right-click on user boris and select Properties. Turn on the Password never expires checkbox, e.g.:

Reset password

If a user forgets their password, the System Administrator can clear the old password (or set a new one) and force the user to enter a new password the next time they log in to EMu.

The password reset facility allows a System Administrator to force a user to change their password the next time they log in successfully. It is generally used when a user forgets their password. In this case the System Administrator sets a new password and then forces the user to change it the next time they access the system.

Account ageing / Expire account

A user's account may expire. Once the account has expired the user will no longer be able to access EMu. There are two ways to expire an account:

The user has not logged in to EMu for a given number of days.
An absolute date after which access to the system will be denied.

The account ageing facility allows a System Administrator to set a date after which the user account becomes inactive. If a user tries to access EMu after the set date, a message indicating that the account has expired is displayed and access is denied.

Examples

We have a number of students working for our institution over the summer break. We would like to expire their accounts once they return to university on 1st March 2012.

In each case below, it is not possible to set the expiry date for all students with the one command. Each user account needs to be set individually.

Solaris 10

The command required to set the expiry date is:

usermod -e '03/01/12' student1

Linux

The command required to set the expiry date is:

chage -E '2012-03-01' student1

FreeBSD

The command required to set the expiry date is:

pw usermod student1 -e '01-03-2012'

Windows

Run dsa.msc and view the properties for the student1 user account. On the Account tab turn on the End of radio button in the Account expires group box. Set the expiry date to 1 March 2012.
One of the students (student2) is not returning to university and will continue to work for us for the foreseeable future. We need to remove their expiry date

Solaris 10

The command required to remove the expiry date is:

usermod -e '' student2

Linux

The command required to remove the expiry date is:

chage -E '' student2

FreeBSD

The command required to remove the expiry date is:

pw usermod student2 -e ''

Windows

Run dsa.msc and view the properties for the student2 user account. On the Account tab turn on the Never radio button in the Account expires group box.

Account locking

The account locking facility allows a System Administrator to turn off access for a user account. While the account is locked, the user will not be able to log in to EMu. The error message will indicate an incorrect username / password combination has been supplied. When an account is unlocked the user may access EMu again using their old password. Account locking is useful if a user is leaving for an extended period of time, but does plan to return in the future.

Examples

User boris has taken leave for a year. We would like to lock his account while he is away
Solaris 10

The command required to lock the user account is:
```
passwd -l boris
```
Linux

The command required to lock the user account is:
```
passwd -l boris
```
FreeBSD

The command required to lock the user account is:
```
pw lock boris
```
Windows

If Active Directory is enabled, run dsa.msc to view the Active Directory users, otherwise run lusrmgr.msc to list local users. View the properties for user account boris. Turn on the Account is disabled checkbox.
User boris has now returned from leave and we would like to unlock his account
Solaris 10

The command required to unlock the user account is:
```
passwd -u boris
```
Linux

The command required to unlock the user account is:
```
passwd -u boris
```
FreeBSD

The command required to unlock the user account is:
```
pw unlock boris
```
Windows

If Active Directory is enabled, run dsa.msc to view the Active Directory users, otherwise run lusrmgr.msc to list local users. View the properties for user account boris. Turn off the Account is disabled checkbox.

Maximum Retries

The maximum retries setting allows a System Administrator to set the maximum number of incorrect passwords that may be entered consecutively before the user's account is locked. Implementing a maximum retries limit is useful if you suspect people are trying to break into user accounts by guessing their password.

Solaris 10

Solaris 10 provides a variable called RETRIES in the file /etc/default/login for setting the maximum number of password retries before an account may be locked. The default value is empty, implying no limit.

Solaris 10, by default, does not lock an account when the limit is reached. In order to lock the account two mechanisms are provided. The first mechanism is system wide, while the second is on a per user basis. The system wide setting is found in the file /etc/security/policy.conf. The LOCK_AFTER_RETRIES variable must be set to YES to force accounts to be locked once the maximum number of retries is triggered. The setting may also be enabled on a per-user basis in the file /etc/user_attr. The usermod command is used to set the per-user value:

usermod -K lock_after_retries=value user

where:

value	is `no` (account locking is disabled once the retries limit is reached) or Yes (account locking is enabled once the retries limit is reached).
user	is the name of the user account for which to set `lock_after_retries`.

Once an account has been locked due to exceeding the maximum number of tries, the user cannot log in to EMu until the account is unlocked (via passwd -u user).

Account locking after a maximum number of incorrect passwords is supported by the Shadow and NIS+ password databases. LDAP and AD also support account locking via the posixAccount and shadowAccount class objects.

Linux

Linux uses the pam_tally module in the PAM sub-system to implement account locking after a set number of failed passwords. In order to enable the module you need to include it in the Texpress PAM configuration file located at /etc/pam.d/texpress. The following two entries need to be added:

auth		required		pam_tally.so onerr=fail deny=5

account		required		pam_tally.so reset

The order of these two lines in the PAM configuration file is important. The first line must appear before the entry for:

auth ... pam_unix.so

and the second line must appear after the entry for:

account ... pam_unix.so

The deny argument determines the number of failed password attempts before the user can no longer log in to the system.

Once a user has reached the deny limit, they cannot log in until the number of failed passwords is reset to zero. The faillog command is used to reset the count (and hence allow the user to retry logging in):

faillog -r -u user

where:

user	is the name of the user account to unlock.

It is also possible to set the maximum number of password attempts on a per user basis, rather than system wide. If per-user limits are to be used, the PAM entries in the configuration file should be altered to:

auth			required		pam_tally.so onerr=fail deny=5 per_user

account		required		pam_tally.so reset

The faillog command is then used to set the per-user limit:

faillog -u user -m max

where:

`max`	is the number of password failures before the account is disabled. A value of zero turns off checking.
user	is the name of the user account for which to set the limit.

FreeBSD

Like Linux, FreeBSD also uses PAM to provide support for setting a maximum number of login attempts before a user is locked out. FreeBSD uses the pam_abl module to provide the required PAM support. The pam_abl package is not installed on a FreeBSD system by default. You may need to install the package before enabling it.

To enable the module you need to include it in the Texpress PAM configuration file located at /etc/pam.d/texpress. The following entry needs to be added:

auth	required	/usr/local/lib/pam_abl.so config=/usr/local/etc/pam_abl.conf

The position of this line in the PAM configuration file is important. The line must appear before the entry for:

auth ... pam_unix.so

The config argument defines the location of the pam_abl configuration file. The configuration file allows system wide and per-user properties to be set.

To set a system wide entry, edit the configuration file located at /usr/local/etc/pam_abl.conf and alter the host_rule property. The format of the setting required to set the maximum login retries is:

*:retries/period

where:

`retries`	is the number of login attempts before locking out the user.
`period`	is the period in which the retries have to occur for the user to be locked out. The period is generally a number of days, for example `30d`. After the period has expired, the account may be accessed again.

To set a user specific entry, the user_rule should be used. The format of a user specific entry is:

user:retries/period

where:

user	is the name of the user account to which the setting applies.

The remaining values are the same as for the host_rule property. More sophisticated rules may be set. Please see the manual entry for pam_abl for complete details.

The pam_abl command is used to clear an account once it has been disabled. The format of the command is:

pam_abl --okuser user

where:

user	is the name of the user account to be re-enabled.

Examples

Our institution has a policy of allowing five failed login attempts before locking a user account. To unlock the account the user must contact the System Administrator
Solaris 10

The setting required in the file /etc/default/login is:
```
RETRIES=5
```
and the setting required in the file /etc/security/policy.conf is:
```
LOCK_AFTER_RETRIES=YES
```
Linux

Add the following line to /etc/pam.d/texpress:
```
auth required pam_tally.so onerr=fail deny=5
```
The line should be added before the line:
```
auth ... pam_unix.so
```
FreeBSD

Install pam_abl and add the following line to the PAM configuration file located at /etc/pam.d/texpress (note that this should be entered on a single line):
```
auth required /usr/local/lib/pam_abl.so config=/usr/local/etc/pam_abl.conf
```
The line should be added before the line:
```
auth ... pam_unix.so
```
Edit the pam_abl configuration file located at /usr/local/etc/pam_abl.conf and add the line:
```
host_rule=*:5/1h
```
The rule will allow up to five incorrect login attempts per hour.

Windows

If the setting is to be domain wide, then the Global Security Policy should be updated; otherwise, if it is machine specific, the Local Security Policy should be used. The following attribute should be set:

Account lockout threshold set to 5.
We have one particular user (boris) who suffers from dyslexia, so we do not want to lock his account after five incorrect password submissions
Solaris 10

The command required to disable account locking for user boris is:
```
usermod -K lock_after_retries=no boris
```
Linux

Edit the PAM configuration file located at /etc/pam.d/texpress and add the per_user property to the pam_tally auth entry:
```
auth required pam_tally.so onerr=fail deny=5 per_user
```
The command required to disable account locking for user boris is:
```
faillog -m 0 -u boris
```
FreeBSD

Edit the pam_abl configuration file located at /usr/local/etc/pam_abl.conf and add the following entry:
```
user_rule=boris:100/1s
```
While the above rule does not disable the checking, it will only lock out a user if there are more than 100 login attempts per second (which is very unlikely).

Windows

Windows does not provide a per-user setting for the number of login attempts before locking a user's account.

Valid Passwords

When a user submits a new password for updating it may be worthwhile checking that the password is sufficiently obscure as to not be easily guessed. The check may include looking for:

known words
a mixture of characters and digits
a mixture of lower case and upper case characters
a minimum length

The password validation facility provides a mechanism where new passwords can be checked against a number of criteria before being approved for updating.

Solaris 10

Solaris 10 provides support for checking that a new password supplied by a user meets a minimum set of conditions. The conditions are defined in the file /etc/default/passwd and are checked each time a user sets a new password. If the new password does not pass all checks, it is disallowed. The checks available are:

`DICTIONDBDIR`	The path of a directory containing a series of pre-compiled dictionary files. The files are checked to see if a new password appears in one of them. If so, the password is rejected. The `mkpwdict` command is used to build the pre-compiled dictionary files. The default value is empty, implying a dictionary check is not performed.
`DICTIONLIST`	A comma separated list of full file names to dictionary files. Each dictionary file should contain one word per line with a newline character used to end the line. A new password is checked against the contents of the dictionary files before being passed. The default value is an empty list, implying dictionary look ups are not performed.
`HISTORY`	The maximum number of prior passwords to maintain for each user. When a user submits a new password it is checked against the last `HISTORY` passwords the user has set and if a match occurs, the password is disallowed. If the value for HISTORY is empty or zero, password histories are disabled. The default value is empty, implying password histories are disabled. Password histories are only supported by the Shadow password database.
`MINALPHA`	The minimum number of alphabetic characters required. If `MINALPHA` is not set, the default is 2.
`MINDIGIT`	The minimum number of digits required. If `MINDIGIT` is not set or is set to zero, the default is no checks. You cannot set MINDIGIT if MINNONALPHA is specified.
`MINNONALPHA`	The minimum number of non-alpha characters (including numeric and special) required. If `MINNONALPHA` is not set, the default is 1. You cannot set MINNONALPHA if either MINDIGIT or MINSPECIAL is specified.
`MINSPECIAL`	The minimum number of special characters (non-alphabetic and non-digit) required. If `MINSPECIAL` is not set or is zero, the default is no checks. You cannot set MINSPECIAL if you specify MINNONALPHA.
`MINLOWER`	The minimum number of lower case letters required. If not set or zero, the default is no checks.
`MINUPPER`	The minimum number of upper case letters required. If not set or zero, the default is no checks.
`MINDIFF`	The minimum character differences required between an old and a new password. If `MINDIFF` is not set, the default is 3.
`NAMECHECK`	Enable / disable checking for the username as the password. The default is to perform the check. A value of `NO` disables this feature.
`PASSLENGTH`	The minimum acceptable length for a password in characters.
`WHITESPACE`	Whether whitespace characters (space, tab, etc.) are acceptable in a password. The default value is that whitespace is acceptable. A value of `NO` disables this feature.

As you can see Solaris 10 provides quite a bit of control over what constitutes a valid password. The settings above are on a system wide basis. It is not possible to apply any of the settings on a per-user basis.

Linux

Linux uses the pam_cracklib module in the PAM sub-system to implement password validation. In order to enable the module you need to include it in the Texpress PAM configuration file located at /etc/pam.d/texpress. The following two entries need to replace the existing password entry:

password		required		pam_cracklib.so minlen=6 difok=3

password		required		pam_unix.so use_authtok

The pam_cracklib module takes a number of parameters, including:

minlen
The minimum length for an acceptable password.
difok
The minimum number of characters difference between the previous password and the new password.
dictpath
Full file prefix for cracklib dictionaries. The default value is /usr/lib/cracklib.dict. The cracklib dictionary extensions are:
- .hwm
- .pwd
- .pwi

pam_cracklib provides a dictionary containing over 50,000 words. It is also possible to configure pam_cracklib to enforce passwords to contain a mixture of lower case, upper case, digits and special characters. See the pam_cracklib manual page for complete details on how to configure these restrictions.

FreeBSD

FreeBSD uses the pam_passwdqc module in the PAM sub-system to implement password validation. In order to enable the module you need to include it in the Texpress PAM configuration file located at /etc/pam.d/texpress. The following two entries need to replace the existing password entry:

password		requisite		pam_passwdqc.so enforce=users

password		required		pam_unix.so no_warn try_first_pass

The pam_passwdqc module takes a number of parameters, including:

enforce
Indicates whether weak passwords should be allowed. The allowed values are:
- everyone - strong password are enforced for all users.
- users - strong passwords are enforced for all non-root users.
- none - strong passwords are not enforced.
max
The maximum allowed password length. The default value is 40.
match
The length of a common sequence between old and new passwords for the new password to be considered unsuitable. The default value is four, while a value of zero disables sub-string matching.

min

The minimum allowed password lengths for different combinations of character sequences. A password is broken down into a number of characters classes. The classes are:

digits
lower-case letters
upper-case letters
other characters

The format of the setting for min is:

min=N0,N1,N2,N3,N4

where:

`N0`	is the minimum length where a password contains characters from one class only.
`N1`	is the minimum length where a password contains characters from two classes.
`N2`	is the minimum number of words for a passphrase (not used by EMu).
`N3`	is the minimum length where a password contains characters from three classes.
`N4`	is the minimum length where a password contains characters from all four classes.

A value of disabled is used to disallow passwords of a given format. The default value is min=disabled,24,12,8,7.

pam_passwdqc does not provide a dictionary look-up facility, however judicious use of the min property forces users to submit passwords with non-obvious sequences.

`date`	is the date after which the account is no longer valid. The date format used is yyyy-mm-dd. An empty date value is used to remove an expiry date.
`user`	is the name of the user account to expire.

`date`	is the date after which the account is no longer valid. The date format used is dd-mm-yyyy. An empty date value is used to remove an expiry date.
`user`	is the name of the user account to expire.

`date`	is the date after which the account is no longer valid. The date format used is mm/dd/yy. An empty date value is used to remove an expiry date.
user	is the name of the user account to expire.