Re: [SmartcardServices-Users] Activate screensaver with token
Yoann, would defaults write com.apple.screensaver tokenRemovalAction 1 get around the caching issue? I note that my accounts do all show tokenRemovalAction 1, and pulling the CAC from the machine causes the screensaver to activate. It's just when I go to unlock the screensaver, the CAC doesn't work if it's a mobile or local account, only works if it's a network account. Thank you, John
Le 23 mars 2016 ? 19:10, Lance Terada, CTR <lance.terada.ctr@mhpcc.hpc.mil> a ?crit :
Hi Shawn,
Yes, I already enabled smart cards for login. So I guess I?m having another issue as I?ve set that option but my screensaver still doesn?t turn on after I pull my CAC. The read command returns correct information.
Is there anything else I can check?
Did you restart your computer since you?ve set this setting? Or at least killed the cfprefsd service ? Look at the syslog when you remove the smart card to see if the removal is correctly seen.
On Mar 22, 2016, at 6:47 PM, Shawn Geddis <geddis@icloud.com <mailto:geddis@icloud.com>> wrote:
sudo /usr/libexec/plistbuddy -c "Add:tokenRemovalAction integer 1" /Users/<username>/Library/Preferences/com.apple.screensaver.plist sudo /usr/libexec/plistbuddy -c "Add:askForPassword integer 1" /Users/<username>/Library/Preferences/com.apple.screensaver.plist sudo /usr/libexec/plistbuddy -c "Add:askForPasswordDelay integer 0" /Users/<username>/Library/Preferences/com.apple.screensaver.plist
You can also READ what the settings are using ?defaults':
$ sudo defaults read /Users/<username>/Library/Preferences/com.apple.screensaver
Don?t forget cfprefsd when editing plist files on disk. If you use defaults, cfprefsd is updated, but if you use anything else the caching service isn?t updated and your new settings never used.
Le 24 mars 2016 à 20:25, Daly, John L CIV NAVAIR, 4G0000D <john.l.daly@navy.mil> a écrit :
would defaults write com.apple.screensaver tokenRemovalAction 1
get around the caching issue?
Yes, as soon as you use defaults to manipulate defaults user domain you don’t have any issues with the caching service. For what I understand this service is linked with the sandbox. It manages access right to preference domains (private and shared one). The thing is, plist files aren’t directly read by Cocoa and Carbon API. Preferences are read in cfprefsd memory. So killing cfprefsd is needed when you deploy new preferences via file instead of regular API.
I note that my accounts do all show tokenRemovalAction 1, and pulling the CAC from the machine causes the screensaver to activate. It's just when I go to unlock the screensaver, the CAC doesn't work if it's a mobile or local account, only works if it's a network account.
This might be linked to authentication mechanism and AuthenticationAuthority settings. If the screen saver activates when you remove the card, this setting is working. If when you put back the card the screensaver doesn’t ask for a PIN code, this is linked to authentication. How do you manage the link between local account and smart card in your tests? What’s the result of those two commands: dscl /Local/Default read /Users/<mobile_account> AuthenticationAuthority dscl /Local/Default read /Users/<mobile_account> OriginalAuthenticationAuthority I’m wondering if authentication caches have the right settings to use smart cards. I haven’t played for a long time with SmartCard on OS X. I will try to find time to make a new lab setup and write an updated documentation for 10.11.
The defaults write command didn’t work for me either. I ran the two dscl commands and got my hash information for the AuthenticationAuthority option and “No such key: OriginalAuthenticationAuthority” for the other. Thanks, Lance
On Mar 24, 2016, at 9:29 PM, Yoann Gini <yoann.gini@gmail.com> wrote:
Le 24 mars 2016 à 20:25, Daly, John L CIV NAVAIR, 4G0000D <john.l.daly@navy.mil> a écrit :
would defaults write com.apple.screensaver tokenRemovalAction 1
get around the caching issue?
Yes, as soon as you use defaults to manipulate defaults user domain you don’t have any issues with the caching service.
For what I understand this service is linked with the sandbox. It manages access right to preference domains (private and shared one).
The thing is, plist files aren’t directly read by Cocoa and Carbon API. Preferences are read in cfprefsd memory. So killing cfprefsd is needed when you deploy new preferences via file instead of regular API.
I note that my accounts do all show tokenRemovalAction 1, and pulling the CAC from the machine causes the screensaver to activate. It's just when I go to unlock the screensaver, the CAC doesn't work if it's a mobile or local account, only works if it's a network account.
This might be linked to authentication mechanism and AuthenticationAuthority settings.
If the screen saver activates when you remove the card, this setting is working. If when you put back the card the screensaver doesn’t ask for a PIN code, this is linked to authentication.
How do you manage the link between local account and smart card in your tests?
What’s the result of those two commands:
dscl /Local/Default read /Users/<mobile_account> AuthenticationAuthority dscl /Local/Default read /Users/<mobile_account> OriginalAuthenticationAuthority
I’m wondering if authentication caches have the right settings to use smart cards.
I haven’t played for a long time with SmartCard on OS X. I will try to find time to make a new lab setup and write an updated documentation for 10.11. _______________________________________________ SmartcardServices-Users mailing list SmartcardServices-Users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/smartcardservices-users
participants (3)
-
Daly, John L CIV NAVAIR, 4G0000D
-
Lance Terada, CTR
-
Yoann Gini