What solutions are similar to LAPS: https://www.microsoft.com/en-us/download/details.aspx?id=46899
...which basically randomizes the built-in Administrator account password, on EACH individual machine. When our Help Desk supports these machines, they are able to perform a lookup in AD (delegated access of course) to acquire the randomized password.
I know Casper offers the solution to randomize an account password, but I do not think that this password is able to be looked up in the JSS. Maybe I am simply overlooking something simple? If this is not possible with the JSS, do any of you have alternate solutions for my goal?
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?
@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.
Sort of like FV2 keys are escrowed, but adding randomization.
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.
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.
Again, and I cannot stress this enough, please test this before going to production and have your security experts vet it.
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.