No posts for a long time since I am between countries. I got posted to a different branch of the firm I work with, so the past few weeks I have been busy relocating and setting up. Since the last week of March I am now in Dubai. A new place, a fresh start, yaay! Sadly, no blog posts so far as I don’t have time at work or after it. Hopefully that gets rectified soon as things start settling down.
Today I tried logging in to this blog and it wouldn’t let me. Kept denying access because the username/ password/ Google Authenticator code was incorrect. I know the first two have to be correct because I save them using LastPass so there’s no way I could have forgotten. The last one too has to be correct because it’s automatically generated after all, but who knows, maybe the plugin’s disabled or broken in the past few weeks?
Since this is a self-hosted blog I the idea to use phpMyAdmin and look at the WordPress database. Perhaps I can reset my password from there or disable Google Authenticator? Turns out that’s easy to do.
Step 1: Login to cPanel of your hosting provider and launch phpMyAdmin.
Step 2: Click the
Databases tab and select your database.
Step 3: Go over to the
wp_users table. The former is for Google Authenticator. The latter for password. The latter has a row for each user. Click the
Edit link for the user you want, go to the
user_pass field, and enter an MD5 hash of the password you want. (If you use DuckDuckGo you can simply type the word followed by
md5 and it will give you the MD5 hash! Else try this link).
In my case I didn’t mess with the password. I suspected Google Authenticator & simply wanted to disable that. So the first table was what I went after. This table has multiple rows. All user meta data belonging to a particular user will have the same
user_id. Find the user you are interested in, note the
user_id, then find the key called
googleauthenticator_enabled. If Google Authenticator is
enabled for the user this will say enabled; change it to
disabled and you are done.
That’s all for now!
I had to recreate a user’s Windows profile the other day and made the novice mistake of removing the profile from his computer by just deleting the folder from
c:\Users. Not a good idea coz that leaves all the registry stuff behind. The correct way to remove his profile would have been to go via the System properties, User Profiles, and then delete the profile. If it complains about the folder not being removed, then remove the folder.
What happened in my case since the registry stuff was still leftover is that Windows wouldn’t create a new profile folder because it thought the profile folder had an error. It kept logging the user in with a temporary profile and complained so: “You have been logged on with Temporary profile”.
Worse, I always thought
HKEY_USERS was where all the registry stuff was stored so that’s where I kept looking to try and delete the registry bits manually. Finally I realized it’s under
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList – doh!
HKEY_USERS only has the registry hives for actively loaded profiles – not necessarily the one logged in interactively, but also user accounts running in the background or that have recently run (via “run as” etc).
So I went to
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList, found the profile (which now had a
.bak suffixed to it), deleted it (because I want him to start afresh), and that got things working again.
After recreating the profile the user told me he wanted his Internet Explorer saved passwords. These are stored under
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\IntelliForms\Storage2 but I hadn’t saved his
HKCU hive before deleting the profile. Not a problem – I had a backup of the profile folder, so I:
- Copied the
NTUSER.DAT file from there to my computer (
NTUSER.DAT is basically the
HKCU hive for his account),
- Loaded it into my registry as a temporary hive,
...\Software\Microsoft\Internet Explorer\IntelliForms\Storage2 from this temporary location to a
- Opened this file in notepad and renamed the root to
I then sent the
.reg file to the user and once he opened it the passwords were imported into his registry.
Here’s the command I ran from an elevated command prompt to load the
ntuser.dat file to a temporary location
reg.exe load HKLM\TempHive .\ntuser.dat
Using the above temporary location, I had to rename
HKEY_CURRENT_USER once I exported the key and opened in notepad.