Screen Saver starts immediately after login

[jshipman]

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 com.apple.SetupAssistant.plist file with one that looks like:

<?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>DidSeeCloudSetup</key> <true/> <key>LastSeenCloudProductVersion</key> <string>10.8.3</string>
</dict>
</plist>

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?

[jhbush]

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.

[mark_sampers]

I use a similar process and things seem to be working for me. I believe the editing of the com.apple.SetupAssistant.plist 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/com.apple.SetupAssistant DidSeeCloudSetup -int 1
defaults write /path/to/volume/Library/Preferencs/com.apple.SetupAssistant LastSeenCloudProductVersion ’10.8?

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

Hope this helps,

[jlee]

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.

[petedogg]

Any update on this?

[leegalan]

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

[mattc]

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.

[Hernandez]

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

[ClassicII]

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

[Hernandez]

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.

[ClassicII]

whooo

This seems fixed in version 9 :)