Randomize management password, but ability to lookup password in JSS

There is no easy way to get to the password if you do the randomization of password. Why would you need that password?

I can understand the need here. I don't think @rseys is talking about the JSS management account, but rather a local admin account that IT techs need to access a machine without logging in as the user. Its not good practice to keep the password for such an account the same across all machines any more than any other local admin level account. If its compromised on one system, its effectively compromised on all of them.

There is, I think, an existing Feature Request to add this capability submitted by @donmontalvo I'll locate it and link it here so you can vote it up in case you haven't already.

@mm2270 is exactly right -- the concern is if our administrative account (used by Help Desk to support our Mac-users) is compromised on one machine, this means 100% of our Macs are now compromised ... we wish to mitigate this risk.

It doesn't sound like JAMF has an in-house solution -- do you guys have any recommendations for 3rd party tools perhaps?

Hello All,

This is a similar conversation to this one. https://jamfnation.jamfsoftware.com/discussion.html?id=16977 Please check out what's there and see if that will help solve some of your problems or give you an idea of where you can start to take the script.

@mm2270 same concern posted by @rseys, if the local admin account password is breached, all Macs are breached. If JSS can randomize the local admin account password, so every Mac has a different password, and techs who have sufficient access rights in JSS can look up that password, we've mitigated risk.

Escrow last 12 passwords for local admin account (not management account)

Sort of like FV2 keys are escrowed, but adding randomization.

Don

Hi Everyone,

So a few things to consider when doing stuff like this. Many RNG algorithms out there are not secure. They are heavily subjected to replay attacks. So there is risk if you start using something like say /dev/urandom for example over something like open SSL.

For some general overview information you can check out this wiki page on SPRNGs.

SPRNGs

When you escrow these passwords they should probably be encrypted on the client end, and then sent securely to an application (most likely some sort of web app) which holds the private key securely in a database or something and can reveal the current password. You would want full end point to end point encryption otherwise there will be some risks, and I will leave those risks to be quantified by security experts of the world since I am not a security expert. The JSS does not offer these features and you should probably look at either building or buying something for it.

However, we have published on our GitHub a proof of concept that you can use to escrow passwords and randomize them locally. I will just highly advise you vet this and test this in your own environment and you have your Info Sec bless this.

password generator

Again, and I cannot stress this enough, please test this before going to production and have your security experts vet it.

Thanks,
Tom

I did something similar at one point. I wrote a script which would enable encryption on a TimeMachine backup disk with a random password, then save that password to an Extension Attribute in the JSS using the API. Then I decided it was way all too insecure so I deleted the tool having never deployed it. But if it would help you, I'll be happy to dig through my archive and find the script. You would have to modify it to set your backdoor account password instead of TimeMachine, but the process should all be similar otherwise.

Thanks everyone for the responses -- it doesn't seem there were many good solutions in-place from what I have found and the responses from above. Has anyone stumbled across any new developments since this was last posted?

Bump! Jamf, are you listening? This needs to be a thing already! :D