Yubico / yubico-pam

Yubico Pluggable Authentication Module (PAM)
https://developers.yubico.com/yubico-pam
BSD 2-Clause "Simplified" License
689 stars 114 forks source link

Breaks in macOS 10.15 #201

Open Frederick888 opened 5 years ago

Frederick888 commented 5 years ago

Hi,

I have just upgraded to macOS 10.15 and it seems yubico-pam no longer works for /etc/pam.d/authorization and /etc/pam.d/screensaver.

/etc/pam.d/authorization

After the upgrade, I re-configured /etc/pam.d/authorization to:

# authorization: auth account
auth       optional       pam_krb5.so use_first_pass use_kcminit
auth       optional       pam_ntlm.so use_first_pass
auth       required       pam_opendirectory.so use_first_pass nullok
auth       required       /usr/local/lib/security/pam_yubico.so mode=challenge-response
account    required       pam_opendirectory.so

This caused me not able to log in or authenticate in e.g. System Preferences -> Security & Privacy. (had to enter recovery mode to unlock, oops!)

/etc/pam.d/screensaver

My /etc/pam.d/screensaver is configured as:

# screensaver: auth account
auth       optional       pam_krb5.so use_first_pass use_kcminit
auth       required       pam_opendirectory.so use_first_pass nullok
auth       required       /usr/local/lib/security/pam_yubico.so mode=challenge-response
account    required       pam_opendirectory.so
account    sufficient     pam_self.so
account    required       pam_group.so no_warn group=admin,wheel fail_safe
account    required       pam_group.so no_warn deny group=admin,wheel ruser fail_safe

It works ok if you don't have a YubiKey plugged in (blocks login successfully) or normally touch YubiKey when prompted. BUT, it crashes and forcibly logs out the user if you unplug YubiKey when the LED is blinking.

And since I cannot use yubico-pam in /etc/pam.d/authorization now, it means the challenge-response can be effectively bypassed since if my password is leaked, one can simply plug in a wrong key to log me out, then use my password to normally log in.

Frederick888 commented 5 years ago

Logs


# pam_yubico-authorization.log
debug: pam_yubico.c:838 (parse_cfg): called.
debug: pam_yubico.c:839 (parse_cfg): flags 0 argc 3
debug: pam_yubico.c:841 (parse_cfg): argv[0]=mode=challenge-response
debug: pam_yubico.c:841 (parse_cfg): argv[1]=debug
debug: pam_yubico.c:841 (parse_cfg): argv[2]=debug_file=/var/log/pam_yubico.log
debug: pam_yubico.c:842 (parse_cfg): id=0
debug: pam_yubico.c:843 (parse_cfg): key=(null)
debug: pam_yubico.c:844 (parse_cfg): debug=1
debug: pam_yubico.c:845 (parse_cfg): debug_file=3
debug: pam_yubico.c:846 (parse_cfg): alwaysok=0
debug: pam_yubico.c:847 (parse_cfg): verbose_otp=0
debug: pam_yubico.c:848 (parse_cfg): try_first_pass=0
debug: pam_yubico.c:849 (parse_cfg): use_first_pass=0
debug: pam_yubico.c:850 (parse_cfg): nullok=0
debug: pam_yubico.c:851 (parse_cfg): authfile=(null)
debug: pam_yubico.c:852 (parse_cfg): ldapserver=(null)
debug: pam_yubico.c:853 (parse_cfg): ldap_uri=(null)
debug: pam_yubico.c:854 (parse_cfg): ldap_bind_user=(null)
debug: pam_yubico.c:855 (parse_cfg): ldap_bind_password=(null)
debug: pam_yubico.c:856 (parse_cfg): ldap_filter=(null)
debug: pam_yubico.c:857 (parse_cfg): ldap_cacertfile=(null)
debug: pam_yubico.c:858 (parse_cfg): ldapdn=(null)
debug: pam_yubico.c:859 (parse_cfg): user_attr=(null)
debug: pam_yubico.c:860 (parse_cfg): yubi_attr=(null)
debug: pam_yubico.c:861 (parse_cfg): yubi_attr_prefix=(null)
debug: pam_yubico.c:862 (parse_cfg): url=(null)
debug: pam_yubico.c:863 (parse_cfg): urllist=(null)
debug: pam_yubico.c:864 (parse_cfg): capath=(null)
debug: pam_yubico.c:865 (parse_cfg): cainfo=(null)
debug: pam_yubico.c:866 (parse_cfg): proxy=(null)
debug: pam_yubico.c:867 (parse_cfg): token_id_length=12
debug: pam_yubico.c:868 (parse_cfg): mode=chresp
debug: pam_yubico.c:869 (parse_cfg): chalresp_path=(null)
debug: pam_yubico.c:899 (pam_sm_authenticate): pam_yubico version: 2.26
debug: pam_yubico.c:914 (pam_sm_authenticate): get user returned: frederick
debug: pam_yubico.c:490 (do_challenge_response): Checking for user challenge files
debug: pam_yubico.c:493 (do_challenge_response): Challenge files found
debug: pam_yubico.c:514 (do_challenge_response): Failed initializing YubiKey
debug: pam_yubico.c:706 (do_challenge_response): USB error: unknown error
debug: pam_yubico.c:718 (do_challenge_response): Challenge response failed: No such file or directory
debug: pam_yubico.c:1220 (pam_sm_authenticate): done. [authentication error]

# pam_yubico-screensaver.log
debug: pam_yubico.c:838 (parse_cfg): called.
debug: pam_yubico.c:839 (parse_cfg): flags 0 argc 3
debug: pam_yubico.c:841 (parse_cfg): argv[0]=mode=challenge-response
debug: pam_yubico.c:841 (parse_cfg): argv[1]=debug
debug: pam_yubico.c:841 (parse_cfg): argv[2]=debug_file=/var/log/pam_yubico.log
debug: pam_yubico.c:842 (parse_cfg): id=0
debug: pam_yubico.c:843 (parse_cfg): key=(null)
debug: pam_yubico.c:844 (parse_cfg): debug=1
debug: pam_yubico.c:845 (parse_cfg): debug_file=14
debug: pam_yubico.c:846 (parse_cfg): alwaysok=0
debug: pam_yubico.c:847 (parse_cfg): verbose_otp=0
debug: pam_yubico.c:848 (parse_cfg): try_first_pass=0
debug: pam_yubico.c:849 (parse_cfg): use_first_pass=0
debug: pam_yubico.c:850 (parse_cfg): nullok=0
debug: pam_yubico.c:851 (parse_cfg): authfile=(null)
debug: pam_yubico.c:852 (parse_cfg): ldapserver=(null)
debug: pam_yubico.c:853 (parse_cfg): ldap_uri=(null)
debug: pam_yubico.c:854 (parse_cfg): ldap_bind_user=(null)
debug: pam_yubico.c:855 (parse_cfg): ldap_bind_password=(null)
debug: pam_yubico.c:856 (parse_cfg): ldap_filter=(null)
debug: pam_yubico.c:857 (parse_cfg): ldap_cacertfile=(null)
debug: pam_yubico.c:858 (parse_cfg): ldapdn=(null)
debug: pam_yubico.c:859 (parse_cfg): user_attr=(null)
debug: pam_yubico.c:860 (parse_cfg): yubi_attr=(null)
debug: pam_yubico.c:861 (parse_cfg): yubi_attr_prefix=(null)
debug: pam_yubico.c:862 (parse_cfg): url=(null)
debug: pam_yubico.c:863 (parse_cfg): urllist=(null)
debug: pam_yubico.c:864 (parse_cfg): capath=(null)
debug: pam_yubico.c:865 (parse_cfg): cainfo=(null)
debug: pam_yubico.c:866 (parse_cfg): proxy=(null)
debug: pam_yubico.c:867 (parse_cfg): token_id_length=12
debug: pam_yubico.c:868 (parse_cfg): mode=chresp
debug: pam_yubico.c:869 (parse_cfg): chalresp_path=(null)
debug: pam_yubico.c:899 (pam_sm_authenticate): pam_yubico version: 2.26
debug: pam_yubico.c:914 (pam_sm_authenticate): get user returned: frederick
debug: pam_yubico.c:490 (do_challenge_response): Checking for user challenge files
debug: pam_yubico.c:493 (do_challenge_response): Challenge files found
debug: util.c:222 (check_firmware_version): YubiKey Firmware version: 5.1.2

debug: pam_yubico.c:528 (do_challenge_response): Loading challenge from file /Users/frederick/.yubico/challenge-xxx
debug: drop_privs.c:58 (pam_modutil_drop_priv): Privilges already dropped, pretend it is all right
debug: util.c:437 (load_chalresp_state): Challenge: xxx, hashed response: xxx, salt: xxx, iterations: 10000, slot: 2
debug: drop_privs.c:102 (pam_modutil_regain_priv): Privilges already as requested, pretend it is all right
debug: pam_yubico.c:582 (do_challenge_response): Challenge-response FAILED
debug: pam_yubico.c:706 (do_challenge_response): USB error: unknown error
debug: pam_yubico.c:718 (do_challenge_response): Challenge response failed: Operation timed out
debug: pam_yubico.c:1220 (pam_sm_authenticate): done. [authentication error]
Frederick888 commented 5 years ago

Just compiled master branch locally and it was the same symptom.

face commented 5 years ago

+1 I can confirm the same USB error for /etc/pam.d/authorization on catalina. ssh pgp key management, and pam sudo appear to work ok. The same configurations work working fine on mohave.

The screensaver integration will also log you out if you type the wrong user password and touch the yubikey (the expected behavior is for osx to offer another password attempt, not log you out).

Here is the log file from a screensaver session with the wrong user password which causes a logout:

debug: pam_yubico.c:838 (parse_cfg): called. debug: pam_yubico.c:839 (parse_cfg): flags 0 argc 3 debug: pam_yubico.c:841 (parse_cfg): argv[0]=mode=challenge-response debug: pam_yubico.c:841 (parse_cfg): argv[1]=debug debug: pam_yubico.c:841 (parse_cfg): argv[2]=debug_file=/var/log/pam_yubico.log debug: pam_yubico.c:842 (parse_cfg): id=0 debug: pam_yubico.c:843 (parse_cfg): key=(null) debug: pam_yubico.c:844 (parse_cfg): debug=1 debug: pam_yubico.c:845 (parse_cfg): debug_file=14 debug: pam_yubico.c:846 (parse_cfg): alwaysok=0 debug: pam_yubico.c:847 (parse_cfg): verbose_otp=0 debug: pam_yubico.c:848 (parse_cfg): try_first_pass=0 debug: pam_yubico.c:849 (parse_cfg): use_first_pass=0 debug: pam_yubico.c:850 (parse_cfg): nullok=0 debug: pam_yubico.c:851 (parse_cfg): authfile=(null) debug: pam_yubico.c:852 (parse_cfg): ldapserver=(null) debug: pam_yubico.c:853 (parse_cfg): ldap_uri=(null) debug: pam_yubico.c:854 (parse_cfg): ldap_bind_user=(null) debug: pam_yubico.c:855 (parse_cfg): ldap_bind_password=(null) debug: pam_yubico.c:856 (parse_cfg): ldap_filter=(null) debug: pam_yubico.c:857 (parse_cfg): ldap_cacertfile=(null) debug: pam_yubico.c:858 (parse_cfg): ldapdn=(null) debug: pam_yubico.c:859 (parse_cfg): user_attr=(null) debug: pam_yubico.c:860 (parse_cfg): yubi_attr=(null) debug: pam_yubico.c:861 (parse_cfg): yubi_attr_prefix=(null) debug: pam_yubico.c:862 (parse_cfg): url=(null) debug: pam_yubico.c:863 (parse_cfg): urllist=(null) debug: pam_yubico.c:864 (parse_cfg): capath=(null) debug: pam_yubico.c:865 (parse_cfg): cainfo=(null) debug: pam_yubico.c:866 (parse_cfg): proxy=(null) debug: pam_yubico.c:867 (parse_cfg): token_id_length=12 debug: pam_yubico.c:868 (parse_cfg): mode=chresp debug: pam_yubico.c:869 (parse_cfg): chalresp_path=(null) debug: pam_yubico.c:899 (pam_sm_authenticate): pam_yubico version: 2.26 debug: pam_yubico.c:914 (pam_sm_authenticate): get user returned: face debug: pam_yubico.c:490 (do_challenge_response): Checking for user challenge files debug: pam_yubico.c:493 (do_challenge_response): Challenge files found debug: util.c:222 (check_firmware_version): YubiKey Firmware version: 5.1.2

debug: pam_yubico.c:528 (do_challenge_response): Loading challenge from file /Users/face/.yubico/challenge-xxxx debug: drop_privs.c:58 (pam_modutil_drop_priv): Privilges already dropped, pretend it is all right debug: util.c:437 (load_chalresp_state): Challenge: xxxx, hashed response: xxx, salt: xxx, iterations: xxx, slot: 2 debug: drop_privs.c:102 (pam_modutil_regain_priv): Privilges already as requested, pretend it is all right debug: pam_yubico.c:604 (do_challenge_response): Got the expected response, generating new challenge (63 bytes). debug: drop_privs.c:58 (pam_modutil_drop_priv): Privilges already dropped, pretend it is all right debug: pam_yubico.c:690 (do_challenge_response): Challenge-response success! debug: drop_privs.c:102 (pam_modutil_regain_priv): Privilges already as requested, pretend it is all right debug: pam_yubico.c:1220 (pam_sm_authenticate): done. [success]

tob1k commented 5 years ago

Can confirm the same problem here.

I found this closed issue which describes the same problem happening during the public betas, and then being subsequently fixed 🤔

https://github.com/Yubico/yubico-pam/issues/197

Frederick888 commented 5 years ago

@tob1k I don't think that's the same issue tho? I'm not familiar with the macOS entitlements stuff but I can use challenge-response for sudo right now.

tob1k commented 5 years ago

@Frederick888 Yeah I'm not 100% sure either. But the log output seemed the same, and if you check the entitlements for sudo, it's missing the usb entitlements as described in #197

$ sudo codesign -d --entitlements :- /usr/bin/sudo
Executable=/usr/bin/sudo
<?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>com.apple.private.AuthorizationServices</key>
    <array>
        <string>com.apple.security.sudo</string>
    </array>
</dict>
</plist>
Frederick888 commented 5 years ago

@tob1k I think you might be on the right track. I just checked my Console -> Errors and saw a 0x100001988: TCC deny IOHIDDeviceOpen error as mentioned in #197.

May I know whether it's possible to overwrite the entitlements (or disable runtime entitlement check system-wide)?

tob1k commented 5 years ago

May I know whether it's possible to overwrite the entitlements (or disable runtime entitlement check system-wide)?

@Frederick888 I'm not sure. I looked into the same thing but at the very least it looks like you would need an Apple Developer ID (which I don't have)

Frederick888 commented 5 years ago

@tob1k Well, I remembered that I once code signed lldb/gdb to work around the entitlements as described in https://opensource.apple.com/source/lldb/lldb-69/docs/code-signing.txt but apparently a random self-signed root certificate will just break sudo as it's a system executable...

Frederick888 commented 5 years ago

I've filed an issue regarding the entitlements of /System/Library/Frameworks/Security.framework/Versions/A/MachServices/authorizationhost.bundle/Contents/MacOS/authorizationhost to Apple but haven't got any response so far.

But, I mean, where are the Yubico devs? Is this project still maintained?

klali commented 5 years ago

But, I mean, where are the Yubico devs? Is this project still maintained?

We're aware of the issue, unfortunately not with alot of insight to add at this point.

authorizationhost has changed entitlements for 10.15, if that's the culprit or not is a good question. This might even be an intentional change from Apple, that the login process should not be able to talk with a USB device.

Frederick888 commented 5 years ago

@klali I really believe you guys need to talk to Apple about this. I don't think such kind of technical feedback from individual customers who are not familiar with either macOS entitlements or yubico-pam per se like me would attract much attention from them.

Frederick888 commented 5 years ago

Still no response from Apple. Can anyone check

  1. the entitlements of authorizationhost in 10.14
  2. whether this is fixed in 10.15.1?

Thanks.

Frederick888 commented 5 years ago

I can confirm that this issue can still be reproduced in 10.15.1. And the bloody update reset a bunch of /etc files again including /etc/pam.d... do they plan to inflict this atrocity on me every time it updates in the future? Geez, I mean, geez... I gotta make some time to figure out the EFI chainloading asap so that I can ditch the rubbish system.

MartinMKD commented 5 years ago

upvoting this. Worked on El Capitan for both authorization and screensaver PAM. Now only screensaver works on Catalina, but Apple seems to have disabled Yubkey working in 'authorization'.. Any ideas if this is entirely Apple's doing or can Yubi fix this?

budachst commented 5 years ago

Also… the newly released MacBookPro 16" only runs Catalina…

andyneff commented 5 years ago

@MartinMKD I'm not 100% sure if Yubico can fix it. But the extra piece of information I'll throw out there is that this does not only affect pam_yubico. I know some others who were using some form of pam kerberos, and it was broken by Catalina too, so this does not bode well. That being said, it may always be possible to have it fixed on the Yubico side, I just don't know enough about the problem to say for sure.

MartinMKD commented 5 years ago

In their zeal to remain "inventive"/ahead of the curve, Apple manages to break things that work such as Yubikey/PAM auth.. along with other useless innovations, like the function key touchbar ....

phroze commented 4 years ago

Any updates on a potential fix for this issue? It's been a while since Catalina was released. Currently our company is not security compliant since we require Yubikey 2FA at logon. Why isn't Yubico providing us updates/information on this issue? This is an important feature, one of the reasons we chose for the Yubikey...

face commented 4 years ago

This is still broken in osx 10.15.2. Is Yubico working with Apple to fix this?

debug: pam_yubico.c:514 (do_challenge_response): Failed initializing YubiKey
debug: pam_yubico.c:706 (do_challenge_response): USB error: unknown error
chuegel commented 4 years ago

Same issue here.

klali commented 4 years ago

Mostly as an update. Yubico has no more information about this, we've opened a radar with apple and tried to get clarity with no answers so far.

andyneff commented 4 years ago

After updating to from 10.15.1 to 10.15.2, logging in with the yubikey worked without issue (It's been working for login only in Catalina this whole time, just not screensaver or privilege elevation). But after a second reboot, it stopped working.

  1. Insert Yubikey
  2. Log in with correct password
  3. It does not wait for you to press the yubikey, but it did blink, and the screen turns white for a few seconds
  4. The login screen restarts, including the MOTD prompt showing up again.

So Apple has at least made it 100% broken instead of 80% broken.

andyneff commented 4 years ago

@Frederick888 in regards to you comment about the pam.d files being reset, I always assume that anything I customize on a mac will be reset. I treat OS updates a "firmware" updates. For this reason, I configure a LaunchDaemon that will reprogram anything I ever edit on a mac. In this case I run a carefully crafted awk and sed script that will update pam.d files every time the computer is rebooted, fairly robustly. This has kept my yubikey setting since I started using it a year and a half ago.

leggomyinfo commented 4 years ago

Could anyone post instructions on how to remedy this from recovery mode? I’m struggling with Terminal and am locked out. Thank you for any help!

chulander commented 4 years ago

Could anyone post instructions on how to remedy this from recovery mode? I’m struggling with Terminal and am locked out. Thank you for any help!

https://vcsjones.dev/2016/01/21/regaining-access-to-os-x-after-a-lost-yubikey/

  1. if you have an apfs file system, replace coreStorage with apfs
  2. mount the volume with the id from the list of disk
  3. use your pw to decrypt the drive
  4. edit the /Volumes/YOUR-VOLUME-ID/etc/pam.d/authorization file and remove the yubikey line. if you edit the /etc/pam.d/authorization, that is the incorrect file.
leggomyinfo commented 4 years ago

Thanks for the reply @chulander. I forgot to update this thread when my computer was stolen shortly after I posted. Unfortunately, it's moot now.

GregoryEAllen commented 4 years ago

Yubikeys are now a requirement at our lab, and new Macs come with Catalina. So this issue is affecting our ability to purchase Apple hardware. Can you please point me to the Radar issue, so I can try to escalate this issue with Apple directly?

MartinMKD commented 4 years ago

@GregoryEAllen I got logins to work on Catalina by configuring Yubi to work as a smartcard. It's a bit more involved to set up but at least it works until Apple issues a fix for killing Yubikey PAM based logins.

GregoryEAllen commented 4 years ago

@MartinMKD could you please provide a link to instructions for this workaround? Does it also support screensaver authorization?

Do we know whether this is Apple's bug, or in yubico-pam?

tob1k commented 4 years ago

@MartinMKD Were you able to get your yubikey to function as a second factor when configured as a smart card?

When I previously investigated this the smart cards function as an alternative to authenticating with a password, not in addition to.

MartinMKD commented 4 years ago

@GregoryEAllen this is what I followed to configure it as a smartcard on Catalina.

At this time, it's not clear whether it's Yubi's or Apple's bug since neither has confirmed either way, but I'm leaning more toward Apple introducing this bug/feature - whether deliberately or not, remains to be seen.

MartinMKD commented 4 years ago

@tob1k technically smartcard is 2FA - you've the physical card w/the certs that authenticate you as the 2nd factor and the PIN you must enter to unlock the card. Neither one would work without the other.

On MacOS you can also disable anything except Smartcard logins, which should provide you with an extra layer of security.

zero-one-devteam commented 4 years ago

Not excatly. Of course, you need a PIN to use the certificates on the smartcard. But it's not 2FA for the Mac, as you can log-in into the mac without the smartcard but with your password only. You may define a quite complex password (maybe a combination of some chars you enter and a static password provided by pressing the button on same Yubikey (you have to configure the key accordingly)) to get a little bit more security. But it's not 2FA as we know it from the challenge response method configured in the PAM config files.

budachst commented 4 years ago

Well… on Catalina using a MDM solution you can enforce the use of a smartcard, no matter what. The only thing you need to do "manually", by setting a derfaults, that is, to prevent FV2 booting straight to the desktop after passing the decryption.

This is actually 2FA and we have resolved to it, since it works entirely without tinkering with the system at all.

MartinMKD commented 4 years ago

Is there anyone with paid Apple support who can field this question to them and get a certain response of why this stopped working? At this rate, I think we will be waiting for a very long time for a resolution

zero-one-devteam commented 4 years ago

Yubico is already talking to Apple to get this problem resolved. I think that they have better connections as we have. Maybe it is not a bug but by design that there is no access to a usb device during logon. Then we won‘t get it back.

The option to configure your Mac for Smartcard only with the help of a profile (you do not Even need MDM if there aren‘t many devices) is a good workaround.

You should configure a firmware password as it is quite easy to delete the profile in recovery mode.

MartinMKD commented 4 years ago

I'm not really adept at MacOS sysadmin stuff, how do you configure a policy to disable the regular password logins and only enable smartcard? I found some instructions on Apple but they were shallow, not indicating how one would go about generating this giant XML file which has a flag that disables regular password logins and only leaves smartcard enabled logins. I've a 2015 MacBook Pro. Thanks.

budachst commented 4 years ago

You can use some tools - first which comes to mind is AppleConfigurator2. However, I do find it a bit bloated and not very intuitive to use. However, there are other tools like ProfileCreator and PPPC Utility - which both are on Github, are good start.

Regarding not using a MDM… the number of payloads which can be applied to Catalina without a MDM solution is rather small and I'd bet that none of the security-related are among those few. But, you can try that - create a playload using ProfileCreator or AppleConfigurator2 and try to load it via the profiles command… if this particular paylod can only be loaded via an authorized MDM, profiles will tell you…

MartinMKD commented 4 years ago

@budachst thanks man. I did look a while back at Apple Configurator 2 from the app store, but couldn't pinpoint which option disabled the regular logins and enabled smart card only. I remember it having hundreds of options, none of which seemed would do what I needed. I find it curious why I would need MDM to apply policies locally.

zero-one-devteam commented 4 years ago

You could follow this guide https://support.apple.com/en-us/HT208372#configsample Copy and paste the xml in an editor and open it in configurator 2.

budachst commented 4 years ago

Here is also a very good source for Apple profiles and their payloads here on Github. https://github.com/ProfileCreator/Configuration-Profile-Reference

I am using this updated version all the time, when wondering, what Apple has been up to in regards of profiles/payloads.

MartinMKD commented 4 years ago

@budachst @zero-one-devteam

tried opening the provided XML that includes enforceSmartCard, did not pick it up under any tab in Apple Configurator 2. :( I think Apple Configurator 2 is kind of crippled for desktop use. It seems more suited for modifying iOS policies. I'm gonna try the other tool you suggested.

budachst commented 4 years ago

Well… it originally was, but you can actually do all sorts of stuff with it. I do prefer ProfileCreator from Github over it, because it's more easy to use. But as always, ymmv.

budachst commented 4 years ago

The main issue with all payloads touching security configs in Catalina, they will be signed using a trusted certificate and that will probably mean to register your Mac with a MDM.

However, this is, what a profile would look like:

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>PayloadContent</key>
    <array>
        <dict>
            <key>PayloadDescription</key>
            <string>Configures SmartCard settings</string>
            <key>PayloadDisplayName</key>
            <string>SmartCard</string>
            <key>PayloadIdentifier</key>
            <string>de.jvm.ProfileCreator.A66B54FD-3D7E-416A-BCC3-3939328F873D.com.apple.smartcard.DE7F08B3-C88A-4919-8CBF-A928185D39A0</string>
            <key>PayloadOrganization</key>
            <string></string>
            <key>PayloadType</key>
            <string>com.apple.smartcard</string>
            <key>PayloadUUID</key>
            <string>DE7F08B3-C88A-4919-8CBF-A928185D39A0</string>
            <key>PayloadVersion</key>
            <integer>1</integer>
            <key>checkCertificateTrust</key>
            <integer>0</integer>
            <key>enforceSmartCard</key>
            <true/>
            <key>oneCardPerUser</key>
            <false/>
            <key>tokenRemovalAction</key>
            <integer>1</integer>
        </dict>
    </array>
    <key>PayloadDescription</key>
    <string>enables and enforces teh use of PIV smartcards</string>
    <key>PayloadDisplayName</key>
    <string>SmartCard</string>
    <key>PayloadIdentifier</key>
    <string>de.jvm.ProfileCreator.A66B54FD-3D7E-416A-BCC3-3939328F873D</string>
    <key>PayloadOrganization</key>
    <string>Some Org</string>
    <key>PayloadScope</key>
    <string>System</string>
    <key>PayloadType</key>
    <string>Configuration</string>
    <key>PayloadUUID</key>
    <string>A66B54FD-3D7E-416A-BCC3-3939328F873D</string>
    <key>PayloadVersion</key>
    <integer>1</integer>
</dict>
</plist>

This is something, which you can click yourself using ProfileCreator, export it and try to load it via the profiles command, but don't be disappointed if profiles refuses to install it…

MartinMKD commented 4 years ago
Screen Shot 2020-01-21 at 11 40 24 PM
MartinMKD commented 4 years ago

There's no guarantee that any MDM provider would support this. And Apple twisting my hand into having to sign up for MDM is just pure b.s., IMHO.

budachst commented 4 years ago

Well… this profile has been created using ProfileCreator - I have only copied the XML from the exported .mobileconfig file. And believe me, this is the way I am always creating all payloads that are missing in my MDM, which is MobileIron. I just couldn't stand paying Jamf the extra-high premium for their product, just to have all possible payloads being templated for me…

So, this works with MobileIron and it will also with TinyMDM or any other MDM solution, which allows for the import of pre-formatted payloads for Apple.

MartinMKD commented 4 years ago

I'll give it a whack. JAMF does have a free option, though probably doesn't have what you need :). Hadn't heard of MobileIron.

MartinMKD commented 4 years ago

I apologize, I actually imported the policy file from Apple's website - that one didn't load in Profile Creator. The one you pasted did.