This section explains how Directory Server password policy configurations affect password quality checks. This section also explains what Directory Server expects your password quality check plug-in to do.
One aspect of password policy involves refusing passwords that do not meet your quality criteria. When a user submits a password value, that value is to be stored on her entry in the userPassword(5dsat) attribute. You might want the server to ensure the password value is not easy to guess or to discover. You might also want the server to log a warning when a weak password is accepted, or even to refuse weak passwords. Determining what you want is part of setting up a password policy.
The password policy entry attribute that governs to what extent the server checks password quality is pwdCheckQuality(5dsat). When this attribute is set to cause the server to check password quality, the server can call plug-ins to do so. This chapter shows how to write a plug-in that checks password quality.
For a more extensive explanation of password policy configuration, see Chapter 7, Directory Server Password Policy, in Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide.
If you can achieve your password policy requirements by using the strong password check plug-in provided with Directory Server, do not write your own plug-in.
The strong password check plug-in provided with Directory Server can be configured for your deployment, checking the password quality aspects that you consider essential. You can configure the following:
The number of lowercase, uppercase, numeric, and special characters required in a password value
A special configuration setting also allows you to enforce a mix of characters.
The absence of prohibited strings, read from a dictionary file
You can use the default English-language file that is provided. Alternatively, you can add or substitute your own file.
These configuration settings are in addition to other checks. Such checks govern password length, whether the password matches common attributes on the entry, and so forth.
In many cases, you can avoid writing your own password check plug-in.
If you decide to implement your own password check plug-in, it must be of type passwordcheck. Your plug-in must implement at least the password checking function, SLAPI_PLUGIN_PASSWDCHECK_FN. This function verifies that all passwords supplied in the parameter block array, SLAPI_PASSWDCHECK_VALS, satisfy the quality check. The SLAPI_PASSWDCHECK_VALS may contain more than one password value.
The function must return the following values, depending on the password values to check.
Return this value when you must send a failure result to the client application for a reason other than quality check failure. You might return this value for example when the server is busy loading a large dictionary file. The server then would not be ready to check password quality.
When you return this value, the server aborts the add or modify operation in progress.
Return this value when all passwords in SLAPI_PASSWDCHECK_VALS satisfy the password quality check.
Return a positive integer when at least one of the passwords in SLAPI_PASSWDCHECK_VALS fails the password quality check.
When you return a positive integer, pass an error message back through SLAPI_RESULT_TEXT in the parameter block with slapi_pblock_set(). Allocate space for the message using slapi_ch_malloc(). The server takes responsibility to free the memory allocated for the message.
The message string must be in all lowercase. The message string must start with invalid password syntax: .
The server sends the client application a result of LDAP_CONSTRAINT_VIOLATION, 19. If, however, passwordRootdnMayBypassModsChecks(5dsat) is set to allow the directory root DN user to modify passwords irrespective of password policy checks, the server nevertheless accepts modifications by that user.
In the simple case used in this chapter, the work is minimal. For real—world cases, the work might however be significant, particularly if you choose to implement your own dictionary check. If you implement your own dictionary check, the plug-in might cache the dictionary content from a large file. In this case, load the dictionary as part of a plug-in start function rather than part of plug-in initialization. You thus avoid blocking startup of the server while the cache is constructed.