Screen Saver starts immediately after login

New Contributor III

Yesterday I changed around some settings on some workstations so that I would no longer see the Apple ID/iCloud prompt at first login and I included a Configuration Profile that has a login window payload that allows local admins to bypass any managed restrictions.

Both of these work marvelously, but now those workstations are going immediately to screen saver after login and requiring a password to get back to the desktop (this is not the default privacy setting)

I accomplished the AppleID/iCloud disable by switching out the file with one that looks like:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "">
<plist version="1.0">
<dict> <key>DidSeeCloudSetup</key> <true/> <key>LastSeenCloudProductVersion</key> <string>10.8.3</string>

The screen saver/password issue only happens at first login. I have tried returning the plist back to it's original state. I have tried removing the configuration profile for admin bypass. No Joy so far. Any ideas?


Valued Contributor II

jshipman, we are seeing the same issue here. It seems to to have started after the 10.8.3 update. I only see it with AD network accounts.


I use a similar process and things seem to be working for me. I believe the editing of the differs in 10.8 vs 10.7 so if you are using a 10.7 edited plist you may want to recreate it for 10.8.

I used the following two commands to create my modified plist:
defaults write /path/to/volume/Library/Preferencs/ DidSeeCloudSetup -int 1
defaults write /path/to/volume/Library/Preferencs/ LastSeenCloudProductVersion ’10.8?

I then packaged the modified plist with Composer and set it to FUT and FEU in Casper Admin.

Hope this helps,

New Contributor

jshipman, we are also seeing the same behavior after updating our clients to 10.8.3 (screen saver activates at first login for users). Will try what mark.sampers recommended and report back.

New Contributor II

Any update on this?

New Contributor III

We are also seeing the same behavior. We are now on 10.8.4 and it hasn't been fixed.

New Contributor

We are also seeing this! Running 10.8.4 with AD accounts. We found the following in the system.log which may indicate the problem:

Sep 6 14:16:59 Marco-3901 mdmclient[642]: [Agent:824622809] Processing server request: EraseDevice for: <User: 824622809>
Sep 6 14:16:59 Marco-3901 mdmclient[642]: ** ERROR ** [Agent:824622809] No PIN received in EraseDevice request
Sep 6 14:17:04 Marco-3901 mdmclient[642]: [Agent:824622809] Using loginwindow to lock screen for: EraseDevice (uid: 824622809)
Sep 6 14:17:04 Marco-3901 mdmclient[642]: ** ERROR ** [Agent:824622809] ### Errors while processing: EraseDevice ###
Sep 6 14:17:04 Marco-3901 mdmclient[642]: ** ERROR ** [Agent:824622809] <NSPOSIXErrorDomain:-2> FindMyMac 'EraseDevice' error: <ParamError> <NSPOSIXErrorDomain:-2>

It would seem that the mdmclient locks the screen and then fails.

New Contributor II

Our 10.8 workstations are also exhibiting this same issue even after installing the 10.8.5 combo update. I wonder how many are affected by this issue. Our logs show exactly the same as what mattc posted. I take it there is no confirmed solution? Any feedback would be greatly appreciated. Thanks

Contributor III

This is pretty annoying. Has any one found a workaround for this ?

New Contributor II

Ultimately, this issue for us appeared to correlate with Undercover unintentionally being blocked from communicating with its server by our web filter. As a result, I think it would trigger this behavior in an attempt to erase the device as a security measure but fortunately nothing was ever erased because it required a 6 digit pin that was not specified by Undercover. The behavior stopped once the exceptions were made in the filter. This was back in November and we have not seen the issue since. Thats the best we could conclude from our environment but it may be different in others. Hope the info helps.

Contributor III


This seems fixed in version 9 :)