Service Modules in new Client?

[RobertD]

@Joe-Schmitt said in Service Modules in new Client?:

The new client is much much easier to build modules for. However it doesn’t allow third party ones. If you have some ideas get in contact with me and we can see about possibly adding them.

So compiling dlls and dropping the fog service folder will no longer work?

In the past we have had problems with students acquiring the local admin password (Cracking the ntlm hash, it being exposed on a post it note or something else). This password is set across the board on desktops, which allowed them to jump from machine to machine (RDP, SMB, Remote execution, or being leaked by some other method). One of the modules we want to create would manage the local Administrator password. Each machine would have a randomly set admin password by this module which would then be sent to an encrypted web service where it would also be stored encrypted. So every admin password on every machine is different. If a campus technician needed the local password for a machine they would request it through a web portal where they would access restriction based on their credentials. Everything could then be audited.

This service module could also be configured to cycle passwords on a normal basis and/or reset the admin password for a specific host on demand from the web portal.

[george1421]

@RobertD If you have access to AD there is a different/better way to manage the local admin passwords.

[RobertD]

@george1421 We are an AD shop, but some of our machines are not domained.

[george1421]

@RobertD Sorry I was going to post a link, but the URL I had saved was broken so it took me a bit longer to get the links.

https://technet.microsoft.com/en-us/mt227395.aspx
https://adsecurity.org/?p=1790

[MRCUR]

@george1421 @RobertD Second the suggestion of LAPS. That is the appropriate way to manage local admin passwords in an AD environment.

[RobertD]

@george1421 said in Service Modules in new Client?:

@RobertD Sorry I was going to post a link, but the URL I had saved was broken so it took me a bit longer to get the links.

https://technet.microsoft.com/en-us/mt227395.aspx
https://adsecurity.org/?p=1790

Good information! However it’s only effective for domain joined machines. Most of our mobile devices are not on the domain (thin clients, laptops, etc - Everything has the fog client)

[RobertD]

We also really like the idea of google’s project GRR, however navigating and creating tasks in it is complicated at best. It would be incredibly convenient if we could build modules for fog to do some of the simple stuff GRR does.

• Search hosts for a file hash - if it exists report back
• Search hosts for a specific event in the event viewier - if it exists report back

[george1421]

@RobertD

The FOG client, could do this, but the issue you will have is managing what the passwords are/will be. You will need to keep an index/ database record for this.

Other ways for mitigation is to only allow devices to boot from authorized media (i.e. hard disk and network). Then lock down the bios so no changes can happen. You can also manage Dell (if you have them) bios passwords with windows utilities.

[RobertD]

@george1421 said in Service Modules in new Client?:

The FOG client, could do this, but the issue you will have is managing what the passwords are/will be.

This is exactly what the module would be programmed to do.

Sudo code:

'Check against the database first
If @PassLastChangedDate < @DateThreshold
'Create a random password and set in on the database side first
’ If successful set it on the local machine
End

[Wayne Workman]

@RobertD said in Service Modules in new Client?:

@Joe-Schmitt said in Service Modules in new Client?:

The new client is much much easier to build modules for. However it doesn’t allow third party ones. If you have some ideas get in contact with me and we can see about possibly adding them.

So compiling dlls and dropping the fog service folder will no longer work?

In the past we have had problems with students acquiring the local admin password (Cracking the ntlm hash, it being exposed on a post it note or something else). This password is set across the board on desktops, which allowed them to jump from machine to machine (RDP, SMB, Remote execution, or being leaked by some other method). One of the modules we want to create would manage the local Administrator password. Each machine would have a randomly set admin password by this module which would then be sent to an encrypted web service where it would also be stored encrypted. So every admin password on every machine is different. If a campus technician needed the local password for a machine they would request it through a web portal where they would access restriction based on their credentials. Everything could then be audited.

This service module could also be configured to cycle passwords on a normal basis and/or reset the admin password for a specific host on demand from the web portal.

Microsoft just recently released a tool that does exactly what you want. I would recommend using that.

Read here for some info:
https://www.404techsupport.com/2015/05/microsoft-makes-local-administrator-password-solution-official/

[MRCUR]

@Wayne-Workman This is exactly what @george1421 linked to earlier and I mentioned below.

[Wayne Workman]

@MRCUR Oh. Cool then. I read from bottom to top, when I hit that first post explaining what he was doing, I posted this and didn’t read any further.

[RobertD]

@Joe-Schmitt said in Service Modules in new Client?:

The new client is much much easier to build modules for. However it doesn’t allow third party ones. If you have some ideas get in contact with me and we can see about possibly adding them.

Hi Joe,
I installed fog 1.3 RC1 last night and noticed under Fog Configuration > Client Updater it looks like there is a module upload section for the fog client. I thought in the new version of fog it didn’t allow third party modules. I guess I’m confused or misunderstood. Can someone explain what this is used for?

Thanks!

[Joe Schmitt]

@RobertD that section is used by the legacy client not the new one. @Tom-Elliott perhaps you could go through and put a notice (e.g. red text) by things that are only support by legacy, such as geeenfog, client module updater, directory/user cleanup and so on.

[RobertD]

@Joe-Schmitt Got it. Thanks for the clarifying. Is there any possibility this will be added back in the future? This could be so useful for proprietary business processes to just use the FOG service instead of having to create our own and install it in addition to the FOG service.

I haven’t played around with the new client since our 0.32 version so I’m excited to see what’s changed.

Thanks for all you guys do!

[Joe Schmitt]

In the far future yes (FOG 2.0 is built around plugins). But for 1.3 you will need to perform a custom build AND swap out the fogproject public cert with your company’s. That way you can sign your builds and still auto update.

[Tom Elliott]

@Joe-Schmitt @RobertD I feel I should notify people.

I did not make a “red text” field as suggested. Instead I added a “warning triangle” that seats itself next to the question mark. When you hover over it it gives the requisite details of the Legacy/New Client status. This is true for both hosts and groups, and there’s a more direct amount of text laid out for the Service configuration page. (Cogs icon at top).

[RobertD]

Just wanted to thank everyone for their suggestions( @george1421 @Wayne-Workman). We did install LAPS on a test OU and it works perfectly. We’ll likely be rolling it out in the next week or two. For those machines off the domain, oh well…