Ugh, what a title…..
A client of mine is on the road to recovery. I have thus far, taken them from about 1998, to roughly mid 2000s status in terms on IT practices. I like working for this client, they are a quirky bunch of people, and have managed to create one of the finest examples of wildly unkempt, organic IT growth I have ever seen. They have survived thus far by paying so called professionals to put out bush fires. They simply had no idea any other alternative existed. I have convinced them that IT doesn’t have to be so painful.
It is time to roll out Active Directory. The vast majority of their machines are home versions of windows, so they won’t be joining the domain any time soon, but we can at the very least bring some sanity to the file server environment. Right now, they have two file servers, and employees named Steve log in with usernames like Brittany, who hasn’t worked for the org in three years. No one knows how to change passwords, nor create new accounts. At the same time, I am rolling out useful internal tools such as a wiki, and a trouble ticketing system, all authenticating against AD/LDAP. Less passwords would be great here, this place is awash in a veritable sea of sticky notes.
A few of the employees are proficient enough that I can grant them the ability to manage basic AD functions, such as account creation, and password resets. However, they all have machines that cannot join the AD domain due to them all being home versions. Sadly, that is not going to change for some time. Baby steps here, folks, baby steps. So, I need a way for them to authenticate against the AD domain, launch MMC, and retain saved settings for AD management.
The first issue is that MMC requires an account with local admin privileges to even start. Firing it up locally presents us with the friendly UAC. Fine, great. So, I snap in the AD controls, it gripes because I am not a member of a domain, so I tell it to change domain to my client’s (Via a VPN, don’t panic, I’m not grotesquely stupid). I am informed that my username or password are incorrect. This is because MMC is running as the local privileged account, not one that was successfully authenticated against the remote AD domain. We can use runas to resolve this:
So, we can just make a bat or ps1 file, and have the user run that, right? Wrong!
Open a powershell prompt, and try this, it will fail. You will be informed that the operation requires privilege elevation. Start a powershell prompt as an administrator, and try again, it will work fine.
But I want to make this into a button that a non-technical end user can click. I can train them how to change passwords, I will not be able to teach them command line anything. They’ll write it down, and then never do it, opting to instead, call me every single time.
Okay, so I’ll just go into the shortcut settings, and tell it to run as Administrator. Except, Windows won’t let me check that option in this particular case. I have no idea why, and now that I have a workaround, I don’t much care.
First you need to prepare the MMC console, as one spawned naked isn’t useful to a non-technical user. Launch an administrative powershell prompt, run the little ditty from above, and snap in all the appropriate tools. Connect them all to the correct domains. Make sure you select all the check boxes that say, “Save this domain setting for the current console.” Then save the console settings somewhere reasonable. This makes sure your end user won’t have to do this work every time.
Now create a ps1 file that looks like this:
Save that somewhere sane, create a shortcut somewhere that makes sense for the end user, and then be really nice and edit the friggin registry to make “Open” actually execute ps1 scripts, and edit send them to notepad. Why this isn’t the default, I have no idea. Here is how you do that btw:
Then get all fancy, and change the icon of the shortcut, and there you have it, problem solved. Non-technical users can now be easily trained to reset passwords, and have a button they click on that lets them do so. Wheeee!