PRK invaild with long string of characters

[JaxsonPina]

Summary

PRK invalid status

does Escrow Buddy fix the invalid PRK that have the long strings of characters in the PRK field when you click on it.

Unknown do get fixed, its just the ones with the long characters

• Escrow Buddy version: 1.0.0
• macOS version: ventura or sonoma
• MDM version: jamf 10.50 Additional Context

[homebysix]

Hi @JaxsonPina - Yes, expected behavior after Escrow Buddy triggers a new key to be generated and escrowed would be that the "Personal Recovery Key Validation" would become Valid and the "Personal Recovery Key" would be a hyphen-separated 24-character alphanumerical string.

If after installing and configuring Escrow Buddy, logging in, and updating Jamf inventory on the affected Mac, the key is still invalid/unchanged, I would be interested in seeing your logs.

[homebysix]

Hi @JaxsonPina - Did you discover anything from the logs?

[JaxsonPina]

Thanks for following up, but we haven’t deployed it yet. We did update JAMF to 11.4.2 not so long ago and I will verify those with the characters after we get the OK, it should be sometime next week.

From: Elliot Jordan @.> Date: Thursday, May 30, 2024 at 11:29ter To: macadmins/escrow-buddy @.> Cc: JaxsonPina @.>, Mention @.> Subject: Re: [macadmins/escrow-buddy] PRK invaild with long string of characters (Issue #7)

Hi @JaxsonPinahttps://github.com/JaxsonPina - Did you discover anything from the logs?

— Reply to this email directly, view it on GitHubhttps://github.com/macadmins/escrow-buddy/issues/7#issuecomment-2139948480, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BFTTI3WB776CVXQFVKF2YELZE5AWDAVCNFSM6AAAAABCLHSNAWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZZHE2DQNBYGA. You are receiving this because you were mentioned.Message ID: @.***>

[k3vmo]

I believe I have an identical issue. Works in my cloud dev instance of 11.4 [upgraded from .3x] but not in my prod instance [11.4.x upgraded from 11.3]. I used Jamf Migrator and this is the only part of everything not working. My encryption state does eventually flip to valid, however the key is a similar random string. Grateful for any guidance

Logs are as follows:

lidf9fa@MWWKWTXGKM ~ % log show --predicate 'process == "mdmclient" AND (message CONTAINS "PUT) [Acknoledged(SecurityInfo" OR message CONTAINS "Saved PRK escrow file")'
Filtering the log data using "process == "mdmclient" AND (composedMessage CONTAINS "PUT) [Acknoledged(SecurityInfo" OR composedMessage CONTAINS "Saved PRK escrow file")"
Skipping info and debug messages, pass --info and/or --debug to include.
Timestamp                       Thread     Type        Activity             PID    TTL  
2024-05-28 13:42:33.708800-0400 0x100b     Default     0x0                  480    0    mdmclient: [com.apple.ManagedClient:FVEscrow] [0:MDMDaemon:FVEscrow:<0x100b>] Saved PRK escrow file: YES  Length: 453
2024-05-28 17:43:59.137865-0400 0x164a4    Default     0x0                  11554  0    mdmclient: [com.apple.ManagedClient:FVEscrow] [0:MDMDaemon:FVEscrow:<0x164a4>] Saved PRK escrow file: YES  Length: 453
2024-05-28 18:53:44.576066-0400 0x13226    Default     0x0                  6187   0    mdmclient: [com.apple.ManagedClient:FVEscrow] [0:MDMDaemon:FVEscrow:<0x13226>] Saved PRK escrow file: YES  Length: 453
--------------------------------------------------------------------------------------------------------------------
Log      - Default:          3, Info:                0, Debug:             0, Error:          0, Fault:          0
Activity - Create:           0, Transition:          0, Actions:           0
lidf9fa@MWWKWTXGKM ~ % log show --predicate 'process == "mdmclient" AND (message CONTAINS "PUT) [Acknoledged(SecurityInfo" OR message CONTAINS "Saved PRK escrow file")'
Filtering the log data using "process == "mdmclient" AND (composedMessage CONTAINS "PUT) [Acknoledged(SecurityInfo" OR composedMessage CONTAINS "Saved PRK escrow file")"
Skipping info and debug messages, pass --info and/or --debug to include.
Timestamp                       Thread     Type        Activity             PID    TTL  
2024-05-28 13:42:33.708800-0400 0x100b     Default     0x0                  480    0    mdmclient: [com.apple.ManagedClient:FVEscrow] [0:MDMDaemon:FVEscrow:<0x100b>] Saved PRK escrow file: YES  Length: 453
2024-05-28 17:43:59.137865-0400 0x164a4    Default     0x0                  11554  0    mdmclient: [com.apple.ManagedClient:FVEscrow] [0:MDMDaemon:FVEscrow:<0x164a4>] Saved PRK escrow file: YES  Length: 453
2024-05-28 18:53:44.576066-0400 0x13226    Default     0x0                  6187   0    mdmclient: [com.apple.ManagedClient:FVEscrow] [0:MDMDaemon:FVEscrow:<0x13226>] Saved PRK escrow file: YES  Length: 453
--------------------------------------------------------------------------------------------------------------------
Log      - Default:          3, Info:                0, Debug:             0, Error:          0, Fault:          0
Activity - Create:           0, Transition:          0, Actions:           0
lidf9fa@MWWKWTXGKM ~ % log show --predicate 'subsystem == "com.netflix.Escrow-Buddy" --style syslog --debug --info --last 24h                                           
quote> 
lidf9fa@MWWKWTXGKM ~ % log show --predicate 'subsystem == "com.netflix.Escrow-Buddy"' --style syslog --debug --info --last 24h
Filtering the log data using "subsystem == "com.netflix.Escrow-Buddy""
Timestamp                       (process)[PID]    
lidf9fa@MWWKWTXGKM ~ % log stream --level debug --predicate 'subsystem -- "com.netflix.Escrow-Buddy"'
log: Bad predicate (Unable to parse the format string "subsystem -- "com.netflix.Escrow-Buddy""): subsystem -- "com.netflix.Escrow-Buddy"
lidf9fa@MWWKWTXGKM ~ % log stream --level debug --predicate 'subsystem == "com.netflix.Escrow-Buddy"'

The other info from the security db looks fine:

root@MWWKWTXGKM lidf9fa # /usr/bin/security authorizationdb read system.login.console 
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>class</key>
    <string>evaluate-mechanisms</string>
    <key>comment</key>
    <string>Login mechanism based rule.  Not for general use, yet.</string>
    <key>created</key>
    <real>738179120.82697999</real>
    <key>mechanisms</key>
    <array>
        <string>builtin:prelogin</string>
        <string>builtin:policy-banner</string>
        <string>loginwindow:login</string>
        <string>builtin:login-begin</string>
        <string>builtin:reset-password,privileged</string>
        <string>loginwindow:FDESupport,privileged</string>
        <string>builtin:forward-login,privileged</string>
        <string>builtin:auto-login,privileged</string>
        <string>builtin:authenticate,privileged</string>
        <string>PKINITMechanism:auth,privileged</string>
        <string>builtin:login-success</string>
        <string>loginwindow:success</string>
        <string>HomeDirMechanism:login,privileged</string>
        <string>HomeDirMechanism:status</string>
        <string>MCXMechanism:login</string>
        <string>CryptoTokenKit:login</string>
        <string>Escrow Buddy:Invoke,privileged</string>
        <string>loginwindow:done</string>
    </array>
    <key>modified</key>
    <real>738270370.95355201</real>
    <key>shared</key>
    <true/>
    <key>tries</key>
    <integer>10000</integer>
    <key>version</key>
    <integer>11</integer>
</dict>
</plist>
YES (0)
root@MWWKWTXGKM lidf9fa # ls /Library/Security/SecurityAgentPlugins 
Escrow Buddy.bundle

[homebysix]

Interesting. Strings beginning with MIAG are likely to be PKCS7-encrypted. I wonder if Jamf is incorrectly storing the encrypted version of the PRK instead of decrypting it during storage or migration.

@k3vmo, I notice that there aren't any Escrow Buddy logs shown. Did the user of that Mac log out or restart within the 24 hours prior to the log collection? And was the GenerateNewKey preference setting set to true after Escrow Buddy was installed?

[k3vmo]

Yes, the systems had been logged out of, restarted multiple times over a week with no change but I too figured it was encryption related. Turns out it must have been the certificate got corrupted during the migrations. I created a new FV configuration in Jamf & saved to recreate the cert. Deployed it and it worked after just a few minutes. All systems got valid keys after doing so. If you see that random string id suggest recreating the FV payload.