Archive for October, 2013
I can never remember the name of modeline for some reason- I always call it a slug. Here is the proper syntax for it as found here:
/* vim: set sw=2: */
Now the next time I google for “Vim slug” this page will come up and I can feel dumb all over again.
It is usually a pain in the butt to figure out how to find the DN of a user and I can never remember how I did it; Fortunately I stumbled across this link which gives the following advice:
You may be asked to define a DN so that a service can bind to it to authenticate a query. Each user in Active Directory has a distinguished name. However, you cannot find it through the ADUC tool.
From a command prompt on your domain controller type: ldifde -f c:\export.txt
View the export.txt file in Notepad and do a find on the username. For example, you do a find on username zimbrauser. You will see something like this:
This means that zimbrauser is in the OU called External in your AD forest exonline.intranet.
This worked beautifully for me. I’ll admit that it is a bit of a kludge, but damn… it’s so simple.
As usual, if this was helpful, leave a comment telling me so.
Backstory time! I’m currently in the process of implementing a new Configuration Management system. Since this will only cover a small subsection of servers, I opted to go with Puppet Enterprise (PE). As part of the installation, it asks you for your email address to use as a username- I used my work address. After getting it installed and configured, I thought it would be a good idea to auth off of Active Directory; I forgot to disable the internal account when doing this, meaning there were two email@example.com that were possible; by the time I had figured this out, puppet had “locked” my account; I disabled the AD auth to confirm that yes, firstname.lastname@example.org was indeed locked.
So, how do you unlock the admin account? After spending a couple of hours googling and asking on freenode’s #puppet channel, I decided to brute force it. By default, PE uses its own postgres database, so I figured out how to crack that open, then dug through the tables and fields, then through the PE sourcecode until I found the secret…
- Find the password for console_auth here in /etc/puppetlabs/installer/database_info.install.
- Connect to the internal postgres DB (presuming you used it): psql -h localhost -p 5432 -U console_auth console_auth using the password found in the file above.
- Run the following SQL command: update authorized_users set status=’enabled’, login_failure_count=0 where username=’email@example.com’;
And that’s it- all that gnashing of teeth for three little steps. Now I can change the admin account to something less conflicty, and retry the AD authentication.
If this saves your butt, please let me know- I couldn’t find this documented anywhere.