PWM – Open Source Password Self Service for LDAP directories – Yay!

I recently setup a new secondary windows domain. All of the users are logging in remotely via a VPN connection and their workstations belong to a different, separate domain… I quickly found myself having to regularly administer accounts… What I needed was a password self-service tool so users could take care of simple things like updating their passwords for expired accounts, resetting forgotten credentials, etc.

Budget was tight for the project, and if you do any kind of google search for this tool, paid enterprise stuff like manage engine and netwrix are at the top of the search results.

Manage Engine isn’t free or particularly cheap if you have a fair number of users. Netwrix has a freeware version of their software however it is hamstrung for one on features and based on ancient ASP code (which they still charge for…) for another. If you are running any kind of modern Microsoft network (Server 2008 R2 or newer) avoid Netwrix like the plague. I installed it several times and made sure I had all of the dependencies installed (which are numerous) and still never could get the key functionality to work correctly.

If you are a typical MS person, you, like me, probably wouldn’t have thought to add those two magical words to your google search… “open source”.

After doing as much though, a server application called PWM quickly comes to the forefront. I am not going to go into a full configuration and install of PWM here. However I am going to quickly give a few notes on potential pitfalls I fell head-first into and hopefully shorten your initial setup and installation of the software.


Before you go any further, you need to make sure all of the proper ports are open between your Active Directory Domain Controller and your PWM server. You can see which ports are needed for AD traffic here: What ports on the firewall should be open between Domain Controllers and Member Servers?

A bit of background… I was installing on a Server 2012 server and had two domain controllers running Server 2012 R2 in my environment. Here are the problems I ran into that you should avoid as well as some useful tips…

1. Do not install PWM, Java Virtual Machine, or Apache Tomcat on a server in your environment that is already running IIS. Also, don’t install it directly on a Domain Controller… that is just bad form…
2. Get the Java JDK from here: oracle java jdk download page – Specifically your are probably wanting to get the file called “jdk-8u25-windows-x64.exe” or whatever the latest version is. The important things is you want either “windows-x86″ or window-x64” in the file name and specifically you want “jdk”. That executable will install everything you need. Install Java FIRST!
3. Next, get Apache Tomcat 7 from here: apache tomcat 7 download page and the specific file you are looking to get is: “32-bit/64-bit Windows Service Installer”
4. DO NOT get Tomcat 8 – PWM doesn’t work correctly with it – not sure why…
5. Install Tomcat – by default in Tomcat 7 there is no administrative user setup, you have to modify an xml file located in something to the effect of: “C:\Program Files\Apache Software Foundation\Tomcat 7.0\conf\tomcat-users.xml” – use notepad (run as administrator) and add a line like this:
   <user username="admin" password="secret" roles="manager-gui" />

   and restart tomcat service – this adds a user named admin with the password “secret” – use a secure password

6. Once tomcat is setup, browse on that system to http://127.0.0.1:8080/ and make sure the config page for tomcat server comes up, if so, you are doing well
7. Next, download the latest PWM zip file from here: https://drive.google.com/folderview?id=0B3oHdiTrftrGV3ZrMi1LUzVCY1U&usp=sharing#list – open the zip file, copy the .war file to the Tomcat webapps directory which is somewhere like this: “C:\Program Files\Apache Software Foundation\Tomcat 7.0\webapps”
8. Tomcat should automagically create a new folder called PWM and install the contents of the war file there. PWM is now installed and ready to be configured
9. This next one is fun (read “pain in the ass”)… One of your domain controllers needs to be promoted to a certificate authority. I am sorry if I just lost a few people there. Basically, Active Directory only allows remote password changes to be made over secure SSL connections – for those connections to work, you will need a CA in your environment and your Java install will need to trust it. I found this page to be the most helpful for getting this setup.
10. Once you go through the full install of “Active Directory Certificate Services” on one of your domain controllers, it will create certs for all of your other domain controllers – you need to extract on of those certs and import it into Java – to do this, on Server 2012 R2 – go to the certificate authority command console window – expand your domain and look under “issued certificates” – you should see certs for each DC – double click the one that PWM will be using to make password changes on, go to the “details” tab – click “copy to file” – use “DER encoded binary x.509 (.cer)” choose a place to save it to on that machine – click “finish” and then make sure you know where the file is.
11. Copy that .cer file to the system running java/tomcat/pwm and put it in the “c:\program files\java\jdkX.X.X_XX\bin” folder. Then open an elevated command prompt, navigate to that folder, and run the following command (modify jdk folder, .cer filename, and alias name for your environment)
    keytool -import -keystore "C:\Program Files\Java\jdkX.X.X_XX\jre\lib\security\cacerts" -file yourfilename.cer -alias DCserverName
12. Once you have imported that cert into Java’s keystore – open a browser and go to http://127.0.0.1:8080/pwm and commence with the guided setup of PWM
13. Couple of items with PWM setup – If you aren’t familiar with LDAP “distinguished name” and other attribute syntax, the attribute editor in Active Directory users and computers is a big help – in “users and computers” go to “view” and select “advanced features” then double-click on a user account and select “properties” and look at the “attribute editor” tab. Find “distinguishedName” and click on it and study the syntax – that will help a lot.
14. During setup of PWM – you will be asked about using the directory to store challenge/response questions or using a database, etc… Use “LocalDB” – that is the easiest thing to do. Using the directory potentially involves modifying the schema and other such pain and using a database involves installing MySQL which is more headache.
15. Also, PWM needs an account to use for interacting with Active Directory on the user’s/client’s behalf. Setup an account with a non-expiring, very strong, password and make sure that account is a domain admin account. There might be a more secure way to go about this as far as needing less privileges but I am not going to dive into that here. In short, this is a service account for PWM and you can use this account for PWM to interact with Active Directory

That probably sounds like a really long list… In reality, this just scratches the surface of PWM and pretty much just gets it installed and running. There is a myriad of additional configuration options once it is all setup. Here is the beauty of it though… You go through all of that headache and you get an incredibly flexible self-service tool for your users… for absolutely FREE. It should be pretty stable/reliable as well. I plan on only using it internally so security is less of a concern – if you are deploying this on a public facing site/interface, please be very careful. This will save your organization lots of $$$ in licensing costs though and you a lot of helpdesk time. PWM is actively being worked on as well, unlike products like Netwrix which apparently haven’t been overhauled in the last decade.

Hopefully this is a big help to anyone else attempting to jump all the hurdles to get this software up and running. Cheers!