Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MDM storage of LAPS password? #97

Open
jelockwood opened this issue Jun 7, 2023 · 3 comments
Open

MDM storage of LAPS password? #97

jelockwood opened this issue Jun 7, 2023 · 3 comments

Comments

@jelockwood
Copy link

@joshua-d-miller
As far as I can see your version of macOSLAPS is designed to store the LAPS password in AD and hence should be retrievable by other AD admins. It also according to the documentation may store it locally in a keychain but this seems pointless as you would need a local admin account credential to login to retrieve the local keychain stored credential.

Whilst right now I am working at a site which has a local AD that could be utilised for this my experience is that Macs being bound to AD is an increasingly rare situation.

As I am sure you are aware several other LAPS solutions store the LAPS credential in an MDM - typically Jamf Pro. (Some other more 'modern' MDMs have built-in LAPS capabilities.)

If I am right, is there any possibility of you adding the capability to store the credential in Jamf Pro? (This would be done in an extension attribute using the Jamf API to access it.)

@jelockwood
Copy link
Author

@joshua-d-miller
Ah! Whilst I could not find it in the Wiki, I see that the way you currently do this for Jamf is to have Jamf run an extension attribute script to read the contents of a file that contains the password.

Whilst the file is in the 'hidden' root home directory it is not completely secure and I believe it also contains the password in plain text.

As mentioned some other LAPS solutions store it directly in Jamf by using the Jamf API to write to an extension attribute and furthermore do so with an encryption of the content. (The encryption key is stored in Jamf and also not stored locally on the Mac.)

This approach is a bit more complex to initially write but that should only need doing once and you could look at some other examples for guidance on this. It does however have the benefit of not storing the password in plain text on the Mac at any stage.

@dbnewman
Copy link

We just migrated to Kandji and my solution personally (as Kandji does not have extension attributes, and I didn't want to open the API to clients) was to create an audit and enforce script which installs a public key on the devices, and uses this public key to encrypt the password and echo it out as a json string my admins can then use to decode.

Looks something like this under the devices library item.
Screenshot 2024-01-17 215315

@joshua-d-miller
Copy link
Owner

In prerelease 4.0.0 I have changed the mechanism that instead of outputting the password to the filesystem temporarily we are outputting a random UUID which is the title of the temporary keychain entry that security can access and pull the password. Do you feel this might be a more acceptable solution? Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants