Handling LDAP Password Changes with NSL and GroupWise
Novell Cool Solutions: Feature
By Rutger Blom
Digg This -
Posted: 5 Apr 2006
Quite a few users in our organization are logging in to the Novell network using biometrics. Together with SecureLogin installed on the client machine, this really gives a smooth single-sign-on environment most of the time. There are not many times these users need to type a password any more.
We still had a problem. We are also running GroupWise, which in our setup is using LDAP authentication. The LDAP database is eDirectory. Making a SecureLogin SSO script for GroupWise was not a problem - it's even included as a prebuild script. The challenge was that our security policy says the LDAP password needs to be changed every 30 days.
It's not difficult to add some lines to the SSO script so that it takes care of password changes. When the change password GroupWise dialog shows up SecureLogin catches this dialog and records the new password that the user submits.
But we wanted to make things even better and more secure. I don't want a user using biometric authentication having to type his or her new LDAP password. I want SecureLogin to generate a secure password, and I want SecureLogin to somehow notify the user about this new password. After all, the user still needs to know or learn the new password when logging in to GroupWise WebAccess from the outside from a public machine, for example, or when logging in via VPN.
There are several ways to solve this. We did it this way: we started by creating a SecureLogin password policy for the LDAP password. This policy defines the requirements we have on the LDAP password. The GroupWise SSO script uses this password policy when generating the new password. Once the policy was in place we pointed it out at the top of our GroupWise SSO script. Our password policy is called LDAPPwdPolicy:
RestrictVariable ?NewPassword LDAPPwdPolicy
When it's time for the user to change his or her password, GroupWise presents a special dialog for this. This dialog needs to be defined in the SSO script:
## Change password dialog box Dialog Title "GroupWise byt l?senord" (Swedish for GroupWise change password) Class #32770 EndDialog
Now we wanted SecureLogin to take care of the password change instead of the user having to type the new password twice manually:
ChangePassword ?NewPassword Random Type ?NewPassword #1039 Type ?NewPassword #1040 Click #1 Set $Password ?NewPassword
The scripts generates the password, types it in twice, and clicks OK. After this, the temporary ?NewPassword variable gets stored in $Password.
Informing the User about the New Password
Finally, the script should inform the user about the new password. Our first thought was a pop-up dialog presenting the new password. It's not difficult to add this to the SSO script. At the same time, we didn't find this to be very secure. Anybody passing by seeing the pop-up can see the new password. Also, there is a risk that the user might quickly click away the dialog, not taking note of the new password.
We came up with the following solution. We let the SSO script write the new password to a .txt file in the user's home directory. After this, the .txt file is e-mailed to the user.
First we created a small batch file that helps the SSO script writing the new password to the .txt file. Then the SSO script runs the batch file:
Run M:\Biometrics\Password\password.cmd $Password
The password is stored in the .txt file in the user's home directory. This could be enough, but we were afraid the user would never open this .txt file and therefore never learn the new password. We wanted to e-mail the password, too.
For this we used a tiny freeware program called bmail.exe. This is a command shell SMTP client that's perfect for use with SecureLogin scripts. For more information and download, follow this link:
So the last 3 lines in our GroupWise SSO script look like this:
Set ?domain "@svalov.se" Strcat ?email $Username ?domain Run M:\Biometrics\Password\bmail.exe -s 192.168.1.1 -t ?email -f email@example.com -h -a "Here is your new password" -m W:\password.txt -c
The first two lines create a variable "?email" containing the users e-mail address. This variable is then used by the bmail.exe program in the last line. I'm sure one could get the user's email address directly from eDirectory, too.
Well, that does the job. Besides the email we also created a new ZENworks application object that points to the password.txt file, opening it with Notepad. This object appears in the user's NAL and is called "My password" in case the user wants to see the password once more.
Another thing we added at the top of the GroupWise SSO script is "SetPlat LDAP". This creates a credential store called LDAP that can be used by other SSO scripts. The $Username and $Password variables are then looked up in this credential store. This is handy when having SSO scripts for other applications that use LDAP for authentication. In our case, some other applications that use LDAP for authentication are the proxy server and GroupWise Messenger. We created SSO scripts for these applications and started the scripts with "SetPlat LDAP" so the SSO picks up the credentials from there.
Note: This solution was tested in an environment with Windows XP, SecureLogin 3.5, and eDirectory.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com