Automating the World

We have migrated servers, if you encounter any issues, please let us know on Slack, or post it.


We have also disabled registration as we migrate to the new forum systems. The slack (slack.labtechgeek.com) will always be accepting new users.
 
User avatar
dkstepanko
Topic Author
Posts: 3
Joined: Mon Jun 09, 2014 3:18 pm
Current LT Agent Count: 3000+
Location: Edmonton, AB, Canada
Contact:

LabTech Location Password Mangement

Thu Jul 31, 2014 6:41 pm

Hello Fellow LabTechers!

Most of you know me from the IRC Channel. I'm the chatty one it seems. I've been working on this little tidbit for the last few days and there was enough people who were interested in it that I thought I'd share it with you all here.

Background - I work for a Managed Services Provider. Our process for accessing Client Machines is that we will use the same username/password for our administrator account and the only thing that changes is the domain. Previously, we've used a Services account for LabTech credentials but with the new features in Ignite that I migrated us over too ... this is now causing problems because that account is locked down and alot of the VBS scripts that Ignite wants to use can't run with it.

We also have a process that I manage, that since we use one account for most things ... whenever a technician leaves our employment -- I change the password.

This would be a problem for me to change the location password for all these locations.

So, here's the method to my madness and how I intend on making it work.

Our location passwords have wildly different names. I've been given the power of the Banhammer to standardize things.

Step 1 - Standardized Administrator Name

This was relatively easy, just need to go through every location in LabTech and add a new Password Entry. I was able to accomplish this with the 'One-Time Location Password Insert.xml' script.

It'll grab a list of all location & client IDs and run a loop with a SQL Insert Statement.

Something that I noticed while watching SQLSpy and opening/closing the Location Password screen repeatedly was the pattern it uses for AES Encryption. You'll notice that the password field in the table is encrypted. The actual AES_Encrypt('Password',SHA'(' @AESValue@') ... There is a white space inbetween the astrophe and @AESValue@. The AESValue that gets used in that sequence is the CLIENTID + 1. Use the wrong value and the password will not show up when you view the list in LabTech.

Step 2 - Adjust the Standardized Administrator Name

Now, you'll notice in the first script that I use just plain ol' f12admin for the username. I tried using %domain%\f12admin but LT was evaluating the domain to my local one. No big deal, I just ran the following statement against the mysql database.

UPDATE passwords
SET UserName = '%domain%\\f12admin'
WHERE Title = 'F12 Administrator';

All updated and nice.

Step 2.5 - Removing silly %domain% from all usernames

So, something new that I discovered. We can no longer use %domain%\<username> in the location password field with the new changes to LabTech. I had Support confirm it that the whoami's fail when it attempts to run PowerShell or anything of that sort with the new Exchange Monitors.

So, what to do when the old LT Admin had everyone fill in %domain% for every password? Well, you script it, ofcourse!!

I've updated the LTPWMGMT.zip file to include my newest script for updating all this. I'll also throw down the steps the script does.

1. SQL Query to grab all passwordIDs that contain %domain% in the username field.
2. Lots of LOG: entries you can use to for testing to ensure it's grabbing the right information before committing changes to the password database
3. Drop the %domain% from the username
4. Use the ClientID to grab the actual domain ... but not from a Domain Controller that adds in the stupid DC: ... and ignores anything with WORKGROUP listed as the domain -- Things break here if it can't find anything.
5. It will also create a log file in the C:\F12\ folder of the LabTech Server with the outputs. So you can see the ClientID and PasswordID along with what was inserted into the DB for review if something looks funny.

The script is called - ONE TIME - LT Passwords Domain Change.xml

Step 3 - Assigning Password to LabTech Locations

This is my project for tomorrow ...


Step 4 - Managing F12 Administrator Password

This was also very easy. I used the LT Database Password Update.xml script for this. It'll have a global value of @F12AdminPW@ defined in there. I just run this against the LabTech Server and it updated things nicely. Had to do a password change today and used it as my testing case.

I'll probably optimize it ... or nest it at some other point. But for now, this is where I am at.

Does it work? I have no clue yet for the actual agent. I'll test that once I get back to assigning the Credentails to the LabTech Locations.

I attached my two scripts in the ZIP folder. If you'll find this useful.

Let's see how this does for my first LTG post. :)

EDIT: Added Step 2.5

Cheers,
DK
You do not have the required permissions to view the files attached to this post.
Last edited by dkstepanko on Mon Aug 11, 2014 4:08 pm, edited 1 time in total.
D.K. Stepanko - MCSA, WatchGuard Certified (XTM/XCS)
Advanced Computing Specialist
F12 Networks

http://www.f12.net
 
User avatar
dobermantech
Geek
Posts: 61
Joined: Thu Dec 12, 2013 3:31 pm
Current LT Agent Count: 1500+
Location: Under a bridge
Contact:

Re: LabTech Location Password Mangement

Fri Aug 01, 2014 12:49 pm

Very Awesome contribution man. We'll be utilizing this in a very big way come 2 weeks when I have to change all passwords because of a tech leaving the firm. Things like this are what make the geek great!

Awesome work

/ir
Ian Richardson, BBA, MCSA, LTCP
CEO, Director of Engineering -- Doberman Technologies LLC
http://www.dobermantechnologies.com
 
User avatar
dkstepanko
Topic Author
Posts: 3
Joined: Mon Jun 09, 2014 3:18 pm
Current LT Agent Count: 3000+
Location: Edmonton, AB, Canada
Contact:

Re: LabTech Location Password Mangement

Tue Aug 05, 2014 5:28 pm

So, I've also recently discovered that we can no longer use %domain% anymore in the Password Field. We were previously told this and it doesn't surprise me that it changed ... it was a long time ago (when we originally deployed). So, I'll be cooking up another script to go through and change the %domain%\f12admin & %domain%\techservices account to swap the %domain% to clientdomain.tld

Stay tuned. Once I can get LT Support to finally get something done about my current OutofMemory Exception on the new server that they can't figure out after a week.
D.K. Stepanko - MCSA, WatchGuard Certified (XTM/XCS)
Advanced Computing Specialist
F12 Networks

http://www.f12.net
 
User avatar
dkstepanko
Topic Author
Posts: 3
Joined: Mon Jun 09, 2014 3:18 pm
Current LT Agent Count: 3000+
Location: Edmonton, AB, Canada
Contact:

Re: LabTech Location Password Mangement

Mon Aug 11, 2014 4:09 pm

Updated main post with Step 2.5

Describes the method I used to get everything changed as LT Support confirmed you can't use %domain%\username anymore. New script added too!
D.K. Stepanko - MCSA, WatchGuard Certified (XTM/XCS)
Advanced Computing Specialist
F12 Networks

http://www.f12.net
 
jerbo128
Posts: 18
Joined: Thu Jul 31, 2014 9:14 pm
Current LT Agent Count: 1000+

Re: LabTech Location Password Mangement

Tue Dec 16, 2014 8:01 am

DK -
Have Im having trouble getting the one time location password insert script to work. Ive added enough logging to the script to see that it does count total records, and go through the loop, and finishes without errors. But not a single entry into the database. I am running it against a single pc.
Do you have any suggestions?

Or anyone else able to tell me a way that I can see exactly what's getting sent to the sql so that I can troubleshoot there? I have manually pasted the sql into a query window, and replaced the variables with real data, and that does work.

Thanks for the help!

J
 
Darrell_Null
Posts: 12
Joined: Wed May 07, 2014 7:55 am
Current LT Agent Count: 3000+

Re: LabTech Location Password Mangement

Fri Aug 11, 2017 11:33 am

I see this thread has not been updated recently. Is this script still applicable and does it function on Automate 11?