Password Notification Service Driver
PWNotify can send email notifications to Users, Helpdesk and Manager, as well as log to NAudit/Sentinel.
The following notifications can be send our regularly on schedule:
- Upcoming Password Expiration: send notifications up to three times (e.g. 14, 5, and one day) before a password actually expires. If you provide a web-based password self-service tool like the IDM user app, iManager 2.02 with the forgotten password applet or PWM, include a direct link in your notification mail for your users convenience.
- Upcoming Account Expiration: send notifications well before accounts expire, so appropriate action (e.g. renew a contract) can be taken if necessary before the account gets locked and needs manual re-activation.
- Unused Accounts: send notifications about accounts that have not been used to log in for a while. After confirmation, you may want to disable or delete them for security reasons.)
Additionally, notifications can be triggered through login-related events as well:
- Password Expiration: send notifications when passwords are expired and the remaining grace logins fall below a limit as a last-chance reminder to change a password
- Intruder Lockout: send notifications on intruder lockout so users can instantly contact helpdesk/security and also know when their accounts can be accessed again.
- Account Creation: send notifications incl. account summaries (login name, email address, home dir location, initial password, room number etc.) to users/helpdesk/managers. You may want to remind managers to e.g. order a new computer in time and provide helpdesk with the necessary data to set it up at the right desk and customize it so the new employee can really start working on his first day in office.
- (Soon to come: Password Changes: send confirmations when passwords have been changed to help recognise intruders)
- download the latest release from http://www.brummelhook.com/dirxml
- copy bh-dirxmlutils.jar to your dirxml/idm server, make sure it's in the class path (try /usr/lib/dirxml/classes on SLES/OES Linux or SYS:System\lib on OES Netware. Figure out by yourself on Windows...)
- import SRV_PWNotify_idm35.XML trough iManager or Designer
- configure the driver through GCVs to match your needs
- create additional email templates from the contents of EmailTemplates.ZIP (still in 3.0 format. Make sure you have the latest IDM plugins to do so, just copy 'n' paste into iManager)
- start the driver (in a lab, i'd recommend :-)
Most configuration is done through Global Configuration Values. These are in detail:
In the default configuration, the driver connects to ldaps://127.0.0.1:636 and sends notifications for all accounts in the tree. It reads the first value of the Security Equals attribute from the driver object, obtains the corresponding Distribution Password (DP) and uses this data to authenticate via LDAP. If you want to use a different server/account or DP is not set on the account, you need to specify user/password in the corresponding GCVs.
LDAP User Search Base and Scope determine which accounts you want to send notifications about.
LDAP maximum result set size: you can limit the maximum number of results a single LDAP query returns, e.g. during testing or to prevent server overload in huge trees.
OS JAVA Settings:
Depending on the number of events you have going through the driver during any polling period on the Publisher channel, you may need to increase the JAVA Heap space on your OS that IDM is running on. To increase the heap you will have to restart some components of your system
- Create an sys:\etc\java.cfg
- Add DIRXML_JVM_MAX_HEAP=512M to the file. This will incresae the heap to 512M. I would move to 256M first.
- Unload JAVA. You will of course have to restart IDM
- You can issue an java -showmemoryPID to see the new Heap setting
- Edit /etc/init.d/ndsd
- Add the following two lines near the begining of the file(Some people use the pre_ndsd_start file)
- export DHOST_JVM_MAX_HEAP
- You can use top to see the new Heap memory on the ndsd process
This driver is quite scalable, and can handle a tremendous amount of events. The scalability is directly dependent on the amount of JAVA Heap you have available. The driver has been tested with a polling interval of 1 Hour on the Publisher channel and has successfully processed 50,000 password expirations with a JAVA Heap of 512M. This was done on both NetWare6.5 and SLES10.
If for some reason you believe you will process more than 50,000 password expirations in one interval period, you can test with a higher JAVA Heap, or decrease your interval time to get fewer password expirations.
Java Heap size required is directly related to the number of nodesets being returned in the query. A nodeset with one user, one attribute, and one value usually takes up around 10K of Java heap. That is a rough estimate based on some crude testing.
The engine, and the rest of your drivers probably need most of the 64 Meg default value, so consider boosting the value based on the size of your user base.