I've drawn up a driver config based on the Delimited Text driver that helps determine current password strength. While it can be reworked to do anything the base component right now reads a user being migrated through this driver (or whose password is changing) and creates a delimited text file with output like the following:
The first field is obviously the user's DN. The second is the password's total length followed by the number of lower-case characters, then number of upper-case characters, number of numeric characters, number of special characters (special defined as non-numeric, lower, or upper-case ascii), and then two other fields I added specifying if the password meets the default microsoft password complexity and then whether or not 'novell' is in the password (case-insensitive). In the example above the password could have been:
This meets Microsoft's complexity rules as I could find them (at least eight characters plus three of four rules (one lower, one upper, one numeric, one special) followed.
The last field, as mentioned, shows if 'novell' is in the password but could be modified or added-to for any number of "bad" strings. It is also feasible to add checks for the presence of the user's various attributes' values in the password (cn, sn, givenname, etc.) to verify that the user is not using any strings specific to their user object in the password even though those are possibly unique per user.
Potential uses for this config include verifying a new password policy's complexity rules (see how many people are or are not not complying) or before migrating into a new environment with certain rules (MAD comes to mind especially, since passwords not-complying may result in disabled users). If management wants a report on how many users are going above and beyond the password complexity rules this could get those data as well.
The benefit of doing this is an up-to-date result that can be easily parsed without having an administrator potentially break all kinds of organizational policies by learning everybody's passwords to serve the same purpose. The output can be put in a secured directory and parsed by automated processes that only administrators could access. Results could also be e-mailed to desired individuals all from within IDM should that be useful. In the end the output could be avoided altogether except in cases where a violation of a business rule (added to this configuration by the administrator) took place.
As a note about the security of this driver. In and of itself this driver is useless unless added to an environment by an administrator of the IDM system. Also it cannot get password information unless Universal Password is implemented and the user's distribution password attribute it set. Furthermore those attributes cannot even be read unless sufficient non-default rights are assigned to the driver object. As currently implemented this driver never writes anything back to eDirectory so this driver was tested giving just Read rights to All Attributes which was, even then, probably excessive. Tracing has been disabled and extra policies have been disabled for this configuration to maximize security though they can be re-enabled if needed. This driver configuration, as it works with passwords, should not be implemented in production just for fun and should be tested before use in production.