MSP Accounts Plugin - Free

[MrRat 4]

This plugin was created to manage our user accounts in the client domains. Unique accounts for every technician are required for accountability and this plugin makes managing all those accounts in all of the client AD domains quite simple. Even if you don't use unique domain accounts for your techs, this plugin provides management for the administrative account that Labtech requires in each domain.

 

Add/Remove a user in all domains found in Labtech

Add/Remove all existing users in a single domain

Assign an account as the Labtech administrative (deployment) account in all locations

Automate changing (randomization) of passwords on a scheduled basis

Lookup/Change your password across all domains with a single click

Manually entered Passwords are checked for complexity

 

Download Here

 

As always, I am open to comments and suggestions for improvement.

 

 

The "My Account" screen is the only tab visible to Labtech users without the "Security Class Config" right.

 

 

 

Manage Users

 

 

 

Manage Locations

Edited March 24, 2016 by Guest

[seano 0]

can you post some screenshots? this looks super useful

[MrRat 4]

screenshots added to original post

 

and the Service Account tab is below

Edited March 24, 2016 by Guest

[SamRau 0]

Are the passwords stored encrypted? or plain text in the SQL database?

[MrRat 4]

Are the passwords stored encrypted? or plain text in the SQL database?

 

Encrypted using MySQL's AES_ENCRYPT command.

[Darrell_Null 0]

The plug-in appears to load as I have an menu item named MSP Accounts to the right of Help, but when I click on it, nothing happens.

[MrRat 4]

The plug-in appears to load as I have an menu item named MSP Accounts to the right of Help, but when I click on it, nothing happens.

 

odd. try restarting the "Labtech Database Agent" service on the Labtech server.

[Darrell_Null 0]

Tried disabling and enabling again as well as restarting the database agent from the server rather than the control center with the same results. This is what I found in the LabTech Errors log.

 

LTAgent v100.332 - 12/2/2015 9:37:21 AM - Plugin SetSQL Error:You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '` tinyint(3) NOT NULL, PRIMARY KEY (`MSP_Name`)) ENGINE=InnoDB DEFAULT CHARSET=u' at line 1:::

LTAgent v100.332 - 12/2/2015 9:37:21 AM - Plugin SetSQL Error:Table 'labtech.plugin_itsc_msp_accounts_settings' doesn't exist:::

[MrRat 4]

LTAgent v100.332 - 12/2/2015 9:37:21 AM - Plugin SetSQL Error:You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '` tinyint(3) NOT NULL:

 

thanks, that log made it easy to find. it has been fixed. Download it again and Update the plugin.

[Darrell_Null 0]

That fixed that issue, but it is throwing lots of dsadd failures when trying to add a single account as a test. From the output it looks like it failed to create the OU, tried again, and then tried to add the user all of which failed. I do not see any output where it created the user and confirmed that the user does not exist. Disabling for now.

 

Parameters: cmd!!!/C dsadd ou "Managed_Service_Provider User Accounts"

Output: dsadd failed:Value for 'Target object for this command' has incorrect format.

type dsadd /? for help.

[MrRat 4]

That fixed that issue, but it is throwing lots of dsadd failures

 

I'm sorry. Obviously needed some beta testers to send to before releasing here. I'll get this fixed today.

Edited December 3, 2015 by Guest

[MrRat 4]

fixing the bug was simple enough. but i'm doing more testing from a new user perspective.

 

of course once im in the code i cant get back out without trying to improve it

* found and fixed a race condition and the fix has the side benefit of running faster

* trying to implement a way to verify changes after they are made and then either report or try to fix.

Edited December 4, 2015 by Guest

[Guest CloudIT2015]

this is going to be extremely useful. My suggestions are to:

-Not push to every client when adding a user to MSP Users tab. Maybe leave that to Manage Locations but add all clients.

-Be able to exclude Clients and/or a better way to exclude locations

-Removing "User Accounts" addition from the end of my MSP Name.

 

Nice work!! We have been wanting to use individual user accounts for all of our clients but would be a lot of work managing those user accounts. This is going to make that super simple.

[MrRat 4]

Thank you for the suggestions.

 

-Not push to every client when adding a user to MSP Users tab.

 

kind of defeats the purpose of the plugin. what is the reasoning here?

 

 

-Be able to exclude Clients and/or a better way to exclude locations

 

what would be better way to exclude locations; another tab with a list and checkboxes?

 

 

-Removing "User Accounts" addition from the end of my MSP Name.

 

hmm. i should make stuff like that configurable just not sure how that would impact existing implementations. i going to have to think about this one.

[Guest CloudIT2015]

kind of defeats the purpose of the plugin. what is the reasoning here?

From the Manage Users tab as soon as I add a user it adds it to all of my clients. I think it would be better if you could set up your users then push them whenever your ready. More for peace of mind that I can set up my users then configure my exclusions then push to all clients that are not part of my exclusions.

 

what would be better way to exclude locations; another tab with a list and checkboxes?

That sounds good or show the list of clients and domains with check boxes. There is a limit to how many locations you can add to your exclude locations box in your settings tab. It also can be a pain to gather all of your location ID's.

 

hmm. i should make stuff like that configurable just not sure how that would impact existing implementations. i going to have to think about this one.

Maybe by default it adds this but you can choose to opt out. Otherwise as long as the OU gets added automatically I suppose it doesn't matter. I just have OU's that are already there with the name I was trying to use.

[MrRat 4]

Output: dsadd failed:Value for 'Target object for this command' has incorrect format.

 

Fixed the issue.

Added validation and alternate fallback methods for create and delete.

Added timers in various places to slow the plugin down which has resulted in 100% reliability in my testing (your results may vary)

Added separate validation steps to verify the account changes. User will receive an email from the validation about 20 minutes after the command has been issued.

 

As far as reliability goes this version makes the previous one look silly.

 

Download link in first message has been updated to the latest version. 2.151208

[MrRat 4]

then configure my exclusions then push to all clients that are not part of my exclusions.

 

This was written from our perspective of there being 2 sets of clients; the first allowing all techs, and the second requiring prior approval of user adds.

 

From the sound of your request it seems like you have user specific exclusions or at least many more sets of exclusions? I'm going to have to think about the UI and manageability of that many variations.

[mcmcghee 1]

This is great. Could potentially replace the many scripts I have to do this manually. Can I make a couple of feature requests?

• The ability to create local users on non-domain machines
  
• Copy group memberships from existing domain admin

[scubes13 0]

+1 for non-domain clients.

 

Also, I'd request the ability to also add these changes to Mac clients.

 

I haven't tested, but I assume this is only built for Windows at the moment.

[MrRat 4]

The ability to create local users on non-domain machines

 

how would you want to choose which computers to add users to?

if you wanted to add all users to all computers in a specific location that would be simple to add

[MrRat 4]

I haven't tested, but I assume this is only built for Windows at the moment.

 

yes, Windows only

[kiddx 0]

Hey this looks like it would be a good replacement for the 5 scripts we run constantly! we make a domain admin account *and* a local account with the same creds across all machines domain and non-domain joined. This way during an issue , like network issue, DNS , or malware hijack we have a local account that can get on the machine in safe mode or anytime the domain is not available. We did ours similar where we made a group of non-changing networks/locations and those are skipped . We made a checkbox at the client level for our scripts to check. While it works I know it can be done much easier and this looks like the right way to do it.

 

FYI, on a Mac/Linux all you would have to do is run the proper command to make a user (adduser) and update the pw (passwd) and send it over

[starbucksgold 0]

Have this installed and am currently testing in Lab environment with 10.5. Looks pretty good so far. Conceptually this is great. Simplifies and solves for manually scripted processes I do today.

 

So how are the passwords retrieved for your tech accounts so they can logon and utilize these accounts after they have been created? I must be missing something stupid simple here.

 

This plugin is not properly registering with LT Plugin Manager and is not showing in the LT DB Table for plugins with a proper GUID. Was this developed following the SDK guidelines? Just curious as to how we know the version we are running and how you plan on updates for future releases?

 

Thanks.

 

-jeff

[MrRat 4]

So how are the passwords retrieved for your tech accounts so they can logon and utilize these accounts after they have been created? I must be missing something stupid simple here.

 

the first tab of the plugin "My Account" allow the user to view and change their own password.

 

 

 

This plugin is not properly registering with LT Plugin Manager and is not showing in the LT DB Table for plugins with a proper GUID. Was this developed following the SDK guidelines? Just curious as to how we know the version we are running and how you plan on updates for future releases?

 

well i thought i was following the SDK, but apparently not. could you point me to the docs for these issues? thanks

[MrRat 4]

we make a domain admin account *and* a local account with the same creds across all machines domain and non-domain joined.

 

i'm liking the idea of a single account per location pushed to each machine as a local account. and i can store/randomize the password like i do for the service account.

simple to implement and the UI would just be 1 checkbox "add local account to each workstation"

 

should it be added to just workstations or servers also?