"loginwindow" process preventing keyboard input and bringing apps forward (OS X 10.10 and 10.11)

timlarsen
Contributor

Hey all,

My team is experiencing a strange issue on several Macs that only began cropping up recently. The only change to our JSS was upgrading from 9.81 to 9.82 maybe 3-4 weeks ago. No new Configuration profiles, policies, etc. The issue is agnostic of HW, OS X version, network segment or connection type. All Macs are running McAfee ePO/endpoint protection for Mac v2.3.0 and I am unaware of any changes to our internal 802.1x or AD servers.

On macs that are experiencing the issue, one wakes their Mac from sleep (or screensaver) and then authenticates successfully to their profile. They retain full control of their mouse (and can click on UI elements and open/quit apps all using the mouse) but cannot do anything with their keyboard (except adjust the audio volume, screen brightness, etc.). Focus cannot be given to any application, even on application with currently opened windows (e.g. if you left a safari window open before the Mac went to sleep). Since we have fast user switching enabled, one CAN go to the login window and login as a different user and...here's the best part...that other user's UI works normally. Force quitting the "loginwindow" process resolves the issues with the affected user and one can then login as them again and all is well. But this is not a practical solution for our end users.

We don't believe the issue is keyboard-related, but rather the "loginwindow" or "windowserver" applications are in the foreground or active (albeit being invisible) preventing any other Applications from coming into the foreground.

In trying to peruse the system log on affected machines, the following types of messages are occurring right at the "epicenter" of the problem:

"Mar 3 10:34:02 NY2AC876C launchservicesd[93]: Application App:"Messages" asn:0x0-2e02e0 pid:21537 refs=7 @ 0x7fa348c61a50 tried to be brought forward, but isn't in fPermittedFrontApps ( ( "LSApplication:0x0-0x3b03b pid=2111 "loginwindow"")), so denying. : LASSession.cp #1531 SetFrontApplication() q=LSSession 100022/0x186b6 queue
Mar 3 10:34:02 NY2AC876C WindowServer[2112]: [cps/setfront] Failed setting the front application to Messages, psn 0x0-0x2e02e0, securitySessionID=0x186b6, err=-13066"

This may repeat several times for various apps that one tries to click on or launch.

We also have configuration profiles for Login Window, Security (when to require password after wake from sleep) and a custom payload reinforcing the password requirement by uploading com.apple.screensaver. Each profile only has one payload each. The issue we are experiencing, however, has been occurring since before the above configuration profiles were created. But I have not ruled out that I may need to redesign my profiles or combine login window with security as recommended in several posts on the nation.

So...I'm reaching out to the community to see if ANYONE has ANY leads on how I may resolve this problem or what is causing the issue (which, by the way appears to be random but has occurred consistently in the morning to the same users).

Thank you!

Tim L.

6 REPLIES 6

jonnydford
Contributor II

Yup, I've seen this and it's because of the Login Window profile. Remove that and the problem goes away.

If you need the login window profile make one in Apple's Server app and upload that to Casper.

As per my TAM:

We do seem to already have this product issue documented (reference D-006439). The documented behaviour is the same as you described, enabling the Login Window payload in a config profile causes the askForPassword value to be set to false in the Security & Privacy payload. One possible workaround for this is to create your desired config profile in Apple's Profile Manager and sign it. Upload this signed profile to the JSS and do NOT unlock it. Signed profiles cannot be modified by the JSS so that unwanted value change would not take place.

jnorris
New Contributor

We're having this same exact issue. Thanks for the followup Jonny. Tim, did his fix work for you?

kirkmshaffer
New Contributor II

We're seeing this as well. We got tripped up because we use a loginwindow profile for Yosemite, but not for El Capitan. Seems like the people being affected on El Capitan upgraded from Yosemite and the profile remains because it's scoped to deploy when it matches, not remove when it doesn't.

jenieze
New Contributor

Hey,

I was experiencing this issue and found the solution in this thread:

https://jamfnation.jamfsoftware.com/discussion.html?id=9982

(post on 1/23 by @jlong )

jenieze
New Contributor

Sorry 1/29!

skoonin
New Contributor

Hi All -

Is anyone able to elaborate on how to install the code-signing cert in OSX Server (10.11)? Can't seem to get this working.

Thanks!