Enhanced password strength in IBM Network Authentication Service for AIX

In a Kerberos environment, protecting principals' passwords is imperative to preserve the system security. Learn how Kerberos administrators can take advantage of the password protection and password strength enhancement features provided by IBM® Network Authentication Service (NAS) for AIX®.       Introduction The Kerberos principal password is the key through which you can unlock the reply of the Key Distribution Center (KDC) server and if that password is compromised, there is no other way to check the authenticity of the principal. Hence, administrators must choose a very hard to break password so that nobody can crack it, thus compromising system security. You can always instruct the end-users to strengthen their passwords and inform them about the password policy. This is a kind of protection from outside, but there should also be a mechanism from inside, which forces the end-users to choose a strong password; hence the enhanced password strength feature in IBM Network Authentication Service (NAS) for AIX. The IBM NAS administration server (kadmind) provides an enhanced password strength-checking facility. It is the responsibility of the kadmind server to check and validate the principal's password. The server can validate the password against the password policy assigned to the principal (see the Resources section for a developerWorks article on Kerberos password policy management) and the password rules specified in the rules configuration file. Enhanced password strength feature activation In order to activate the enhanced password strength feature in IBM NAS, the administrator needs to mention the location of the rules configuration file in the Key Distribution Center (KDC) configuration file '/var/krb5/krb5kdc/kdc.conf'. This needs to be done using the ‘password_rules’ relation in the [realm] stanza of the configuration file, as shown below: [kdcdefaults] kdc_ports = 88 [realms] TEST = { database_name = /var/krb5/krb5kdc/principal admin_keytab = /var/krb5/krb5kdc/kadm5.keytab acl_file = /var/krb5/krb5kdc/kadm5.acl dict_file = /var/krb5/krb5kdc/kadm5.dict key_stash_file = /var/krb5/krb5kdc/.k5.TEST kadmind_port = 749 kdc_ports = 88 max_life = 24h 0m 0s max_renewable_life = 7d 0h 0m 0s master_key_type = des3-cbc-sha1 supported_enctypes = des3-cbc-sha1:normal arcfour-hmac:normal aes256-cts:normal des-cbc-md5:normal des-cbc-crc:normal password_rules = /var/krb5/krb5kdc/password_rules.conf }   If the 'password_rules = ' line is not specified in the /var/krb5/krb5kdc/kdc.conf file or the file specified does not exist or cannot be accessed, the enhanced password strength feature is not enabled. The password rule file contains the various password rules that strengthen the password by helping the user to choose a good password. These rules are written under the stanzas. The file can have the following three stanzas: The [default] stanzas contains the password rules that are applied to the whole realm. All the principals in the realm are by default governed by the rules specified under this stanza. The [policies] stanzas contains the password rules that affect the individual policies. This is used when there is need to apply more rules apart from the realm-wide rules. The [principals] stanzas contain the password rules on a per-principal basis. The administrator can have specific tailored rules for few very important principals (like admin/admin, etc.).   If any stanza is repeated, then the last occurrence of the stanza is taken into consideration and others are ignored. All the incomplete, unknown, and misspelled entries are also ignored. If the password rule file is corrupted for some reason, then kadmind logs and displays an error and then exits. The password rule configuration file has the same format as that of IBM NAS configuration files (/etc/krb5/krb5.conf and /var/krb5/krb5kdc/kdc.conf), as shown below: # This stanza has the realm-wide default rules [default] mindiff = 3 maxrepeats = 3 minalpha = 4 minother = 1 minlen = 6 maxlen = 24 minage = 604800 histsize = 5 # Add a separate dictlist line for each dictionary you want to add dictlist = /usr/dict/words dictlist = /var/krb5/krb5kdc/words # This stanza has the per-policy rules [policies] staff = { minlen = 8 } admin = { minlen = 10 minother = 2 histsize = 8 } # This stanza has the per-principal rules [principals] admin/admin = { mindiff = 4 histsize = 10 }   A sample password rule file is shipped with IBM NAS as /usr/samples/krb5/password_rules.conf. The next section describes all the available password rules.     Password rules A password rule governs a single restriction or checks on the principal's password. These enhanced password strength rules can be set on a realm, policy, and per-principal basis. By default, the rules are set for the entire realm. The existing principals' password is not affected by new password rules. If the password is changed after activating the password rules, the new password should follow the rules. IBM NAS supports four types of the password rules:   Composition rules Age rules Re–use (or history) rules Dictionary rules   Composition rules These rules specify what a password can consist of, such as whether a password should consist of only alphabets or alphanumeric characters. The following rules are supported: mindiff = <number> The minimum number of characters in the new password, which must be different from the characters in the old password. maxrepeats = <number> The maximum times a given character can appear in a password. minalpha = <number> The minimum number of alphanumeric characters in a password. minother = <number> The minimum number of non-alphabetic characters in a password. minlen = <number> The minimum number of characters in a password. (minimum value is 1 a password can’t be a null string) maxlen = <number> The maximum number of characters in a password.   The composition-checking algorithm validates the characters in a password for a valid range against the following rules: Negative values are not allowed. If a negative value is specified, the server logs a warning and the value is ignored. If minalpha and minother combined is greater than maxlen, maxlen is set to minalpha + minother. The minimum value for minlen is 1. (A password cannot be a null string.) If a value for minlen is unspecified or if it is specified as 0, it is set to 1. No warnings are logged in this case. Maxlen must be greater than or equal to minlen. If minlen is greater than maxlen, maxlen is set to the minlen value. A value of 0 for mindiff, maxrepeats, minalpha, minother, or maxlen indicates that no checking will be done for that rule.   Age rules These rules specify how soon the password can be changed. The following rule is supported. minage = <seconds> The minimum amount of time a password must exist before it can be changed. This value is in the unit of second. It must be an integer greater than or equal to zero. If it is unspecified or zero, then this rule is not applied. If the value is negative, then it is ignored and a warning is logged by the kadmind server. Note. When the administrator changes the password by using the change_password kadmin command, then minage checking is ignored.   Re-use (or history) rules This rule provides the ability to specify the number of different passwords that must be used before a password can be used again. The following rule is supported: histsize = <number> A certain number of password changes that must occur before a previous password can be reused. Valid values for histsize is 1 to 10. If the value is unspecified or passed, then it is set to 1. However, if a value greater then 10 is passed, then it is set to 10 with a warning.   Dictionary rules Dictionary rules offer the ability to specify a list of words (as a dictionary file) to use during password verification. The following rule is supported: dictlist = <filename> A list of dictionary files that contain words that are unacceptable for use as passwords.   Dictionary files have the same format as the AIX Dictionary File format: One word per line. Each word starts in the first column and ends with the new line character. Embedded, leading, and trailing white space is not stripped.   The dictionary files must either reside on the machine where the kadmind is running or be accessible by way of an explicit path if they are on remote mounted file systems. Dictionary files must be specified with an absolute path. Notes: You must transfer the dictionary files if the master KDC and kadmind are moved to a new machine. If you unconfigure IBM NAS, you might need to manually remove any dictionary files from your system. If kadmind cannot find a specified dictionary file, a warning is logged about the missing file, but users are still able to change their password. The missing dictionary file is not checked.       Rules management To recap, there are three places in the password configuration file where the administrator can specify the password rules, per-principal, per-policy, or realm-wide; the decisions need to be taken on where to put which rule. Each stanza has its own purpose and limitation. Each time the rule file is modified, the kadmind daemon need to be restarted, which is why it is always recommended to specify realm-wide or per-policy rules only so as to have minimal impact on the kadmind server. If rules are specified at the principal level, the administrator might need to restart the kadmind server each time a single principal or a batch of principals are being added. It is not a good practice to restart the server daemon in the production environment. The kadmind daemon reads all the rules for the kadmin command interface only at the startup time, whereas the kadmind.local command interface rereads the rule file at each invocation. Therefore, it is recommended to restart the kadmind server whenever the rule file or the dictionary file has changed, so that the kadmin and kadmin.local command interface will give consistent results. The following example shows how the kadmind and kadmin.local read the password configuration file. For the kadmin interface, the kadmind daemon reads the file at the startup time, like this: bash-2.05b# hostname land.in.ibm.com bash-2.05b# date Wed Apr 30 11:35:42 CDT 2008 bash-2.05b# start.krb5 kadmind Starting kadmind... kadmind was started successfully. The command completed successfully.    Once the daemon is started successfully, it will log in the log file (default log file - /var/krb5/log/kadmin.log) as follows: Apr 30 11:35:47 land.in.ibm.com kadmind[26712](info): Seeding random number generator Apr 30 11:35:47 land.in.ibm.com kadmind[26712](info): Password strength is enabled using rules file /var/krb5/krb5kdc/password_rules.conf. Apr 30 11:35:47 land.in.ibm.com kadmind[25232](info): starting    At the start up, kadmin.local command interface logs information regarding the password rule file in the log file, as shown in the example below: bash-2.05b# hostname land.in.ibm.com bash-2.05b# date Wed Apr 30 11:30:11 CDT 2008 bash-2.05b# kadmin.local kadmin.local:    The moment you run kadmin.local interface, it will log the following information in the log file: pr 30 11:30:15 land.in.ibm.com kadmin.local[22428](info): Password strength is enabled using rules file /var/krb5/krb5kdc/password_rules.conf.    The dictionary file list specified in the [default] stanza of the password rule file and the default dictionary file (mentioned in the /var/krb5/krb5kdc/kdc.conf file) are loaded into memory when the kadmind server is started. The dictionary file list specified for the individual policy or principal are not read at the startup; rather, they are read as required and added to the existing list of dictionary files in the memory. Along with the dictionary file check, there are some implied rules that are maintained when the password strength check is enabled. For instance, the password cannot be same as the principal name or realm name. The following example shows how the dictionary check is performed. For the example, let’s have a dictionary file/var/krb5/krb5kdc/words containing these words: bash-2.05b# cat /var/krb5/krb5kdc/words kerberos ibm admin nas aix   Also, don’t forget to mention the dictionary file name under [dictlist] stanza in the password_rule file, as below: bash-2.05b# cat /var/krb5/krb5kdc/password_rules.conf [default] mindiff = 3 maxrepeats = 3 minalpha = 0 minother = 0 minlen = 6 maxlen = 24 minage = 604800 histsize = 5 # Add a separate dictlist line for each dictionary you want to add dictlist = /var/krb5/krb5kdc/words    Also, in the /var/krb5/krb5kdc/kdc.conf file, mention the name of the password_rule file. Now, let's try creating a principal ‘vipin’ with a password ‘kerberos.’ It should fail. bash-2.05b# /usr/krb5/sbin/kadmin.local kadmin.local: ank -pw kerberos vipin WARNING: no policy specified for vipin@TEST; defaulting to no policy. Note that policy may be overridden by ACL restrictions. Unable to create principal "vipin@TEST". Status 0x29c2518 - Password is either in the password dictionary or is the same as the principal or realm name. kadmin.local: q    Hence, our dictionary file is in effect and working! Password rules: How they are applied? When the enhanced password strength feature is in action, there could be a scenario where multiple instances of a password rule is applied to a principal. In such cases, the strictest rule is applied. The strictest rule is enforced according to the following table: Table 1. Merging rules   Rule Strictest mindiff largest value maxrepeats smallest value minalpha largest value minother largest value minlen largest value maxlen smallest value minage largest value histsize largest value If more than one dictionary file list is given for a principal in the realm, policy, and principal levels, then all lists are concatenated and consulted during the password verification. As we know that enhanced password strength feature is activated only when the ‘password_rule’ file is specified in the /var/krb5/krb5kdc/kdc.conf file, the password is verified based on the fact that whether the principal has a policy and whether the password_rule file is activated or not. The following table summarizes all the possible conditions: Table 2. Password verification rules   Does principal have a policy? Is a password_rules file activated? Password verification rule No No No password strength checking is done. Dictionary file is not checked. No Yes Enhanced rules in the password_rules file are checked. If a dictionary is specified in kdc.conf, it also is checked. Yes No No enhanced checks are made. The policy rules are checked and the dictionary check is made if one is specified in kdc.conf. Yes Yes The existing policy based rules are checked as well as the enhanced rules in the rules file. If a dictionary file is specified in kdc.conf, it is checked. Conflicts between rules in the policy record and the [policy] stanza of the rules file are merged as described in Table1.     Conclusion This article covered all about the enhanced password strength feature provided by IBM NAS and informs the Kerberos administrators how to exploit it to the fullest.