Jamf Nation Community

snovak · ‎09-08-2014

We've been having an issue where network accounts (usually repeat logins) will occasionally be unable to login to the workstation. I've written a script that fixes the problem (deletes the user record in the local directory) but I'd like to identify the cause, as dealing with it on a case-by-case basis isn't exactly efficient. Has anyone else been having this issue?

General configuration:
OS Version: 10.9.4

AD config

Create mobile account at login
[unchecked] Require confirmation before creating a mobile account
Use UNC path for Active Directory to derive network home location
Network protocol: SMB
Default user shell: /bin/bash
Map UID to attribute: [AD Attribute]

Example issue log:

Sep 8 08:49:33 WORKSTATION nsupdate[166] <Notice>: krb5_sendto_context is called on main thread, its a blocking api Sep 8 08:49:33 WORKSTATION nsupdate[166] <Notice>: gss_init_sec_context is called on main thread, its a blocking api Sep 8 08:49:33 WORKSTATION nsupdate[167] <Notice>: gss_init_sec_context is called on main thread, its a blocking api Sep 8 08:49:35 WORKSTATION nsupdate[196] <Notice>: krb5_sendto_context is called on main thread, its a blocking api Sep 8 08:49:35 WORKSTATION nsupdate[196] <Notice>: gss_init_sec_context is called on main thread, its a blocking api Sep 8 08:49:35 WORKSTATION nsupdate[197] <Notice>: gss_init_sec_context is called on main thread, its a blocking api Sep 8 08:49:40 WORKSTATION WindowServer[87] <Warning>: 3891612: App SecurityAgent cannot order in untagged windows before login. Sep 8 08:49:40 WORKSTATION SecurityAgent[140] <Error>: CGSOrderWindowList Sep 8 08:49:41 WORKSTATION csia[397] <Warning>: 3891612: (connect_and_check) Untrusted apps are not allowed to connect to or launch Window Server before login. Sep 8 08:49:41 WORKSTATION csia[397] <Error>: kCGErrorFailure: This user is not allowed access to the window system right now. Sep 8 08:49:41 WORKSTATION csia[397] <Error>: _RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL. Sep 8 08:49:43 WORKSTATION awacsd[58] <Notice>: Exiting Sep 8 08:49:49 WORKSTATION SecurityAgent[140] <Notice>: User info context values set for FAILED_USER Sep 8 08:49:49 WORKSTATION SecurityAgent[140] <Notice>: Unknown user "FAILED_USER" login attempt PASSED for auditing Sep 8 08:49:53 WORKSTATION SecurityAgent[140] <Notice>: User info context values set for FAILED_USER Sep 8 08:49:53 WORKSTATION SecurityAgent[140] <Notice>: Unknown user "FAILED_USER" login attempt PASSED for auditing Sep 8 08:49:59 WORKSTATION SecurityAgent[140] <Notice>: User info context values set for FAILED_USER Sep 8 08:49:59 WORKSTATION SecurityAgent[140] <Notice>: Unknown user "FAILED_USER" login attempt PASSED for auditing Sep 8 08:50:09 WORKSTATION SecurityAgent[140] <Notice>: User info context values set for FAILED_USER Sep 8 08:50:09 WORKSTATION SecurityAgent[140] <Notice>: Unknown user "FAILED_USER" login attempt PASSED for auditing Sep 8 08:51:01 WORKSTATION SecurityAgent[140] <Notice>: User info context values set for FAILED_USER Sep 8 08:51:01 WORKSTATION SecurityAgent[140] <Notice>: Unknown user "FAILED_USER" login attempt PASSED for auditing Sep 8 08:51:55 WORKSTATION SecurityAgent[140] <Notice>: User info context values set for FAILED_USER Sep 8 08:51:55 WORKSTATION SecurityAgent[140] <Notice>: Unknown user "FAILED_USER" login attempt PASSED for auditing Sep 8 08:52:26 WORKSTATION SecurityAgent[140] <Notice>: User info context values set for FAILED_USER Sep 8 08:52:26 WORKSTATION SecurityAgent[140] <Notice>: Unknown user "FAILED_USER" login attempt PASSED for auditing Sep 8 08:52:31 WORKSTATION SecurityAgent[140] <Notice>: User info context values set for FAILED_USER Sep 8 08:52:31 WORKSTATION SecurityAgent[140] <Notice>: Unknown user "FAILED_USER" login attempt PASSED for auditing Sep 8 08:52:35 WORKSTATION SecurityAgent[140] <Notice>: User info context values set for FAILED_USER Sep 8 08:52:35 WORKSTATION SecurityAgent[140] <Notice>: Unknown user "FAILED_USER" login attempt PASSED for auditing Sep 8 08:52:38 WORKSTATION SecurityAgent[140] <Notice>: User info context values set for FAILED_USER Sep 8 08:52:38 WORKSTATION SecurityAgent[140] <Notice>: Unknown user "FAILED_USER" login attempt PASSED for auditing Sep 8 08:52:45 WORKSTATION SecurityAgent[140] <Notice>: User info context values set for FAILED_USER Sep 8 08:52:45 WORKSTATION SecurityAgent[140] <Notice>: Unknown user "FAILED_USER" login attempt PASSED for auditing Sep 8 08:53:01 WORKSTATION SecurityAgent[140] <Notice>: User info context values set for SUCCESSFUL_USER Sep 8 08:53:01 WORKSTATION authorizationhost[596] <Notice>: krb5_sendto_context is called on main thread, its a blocking api Sep 8 08:53:01 WORKSTATION SecurityAgent[140] <Notice>: Login Window login proceeding

Script

#!/bin/bash
#
# 090_loginIssueTool.sh - Fixes some generic issues with
# network accounts that try to login and fail

#############
# Variables #
#############

USER=""

if [ "$4" != "" ]
then
    export USER="$4"
else
    exit 1
fi

#############
# Functions #
#############

log() {
    syslog -s -k Facility local7 Level info Message "$1"
}

####################
# Actual scripting #
####################

dscl . -read /Users/$USER
if [ $? -eq 0 ]
    then
        dscl . -delete /Users/$USER
        log "The local user account info for $USER has been removed from dscl" 
fi

jamf policy -event rejoin_ad


exit 0

Olivier · ‎09-11-2014

Seems as if loginwindow or similar processes could not properly process the login name, that you typed in the login field...

A nice to have troubleshooting command is : "sudo defaults write /Library/Preferences/com.apple.loginwindow DBLogging -array Process Users UsersExtra OpenDirectory Autologin FDE"

This enables extreme verbose logging for anything related to login process. Don't know if it is really applicable to your case, nor I remember exactly what log files are used with this command, but quite sure you will find them ;-).

Disable the logging with "sudo defaults delete /Library/Preferences/com.apple.loginwindow". You may want also to use "odutil set log debug" and look at /var/log/opendirectory* logs, as they might also be useful.

almonte32 · ‎03-23-2015

@snovak

I know this is a pretty late response, but I've had the exact same issue as you since upgrading to OSX 10.9, all 10.7.x and 10.8.x clients never had this issue. I dont have casper (just wanted to throw that out there), so I usually just have to delete computer from AD (unjoin domain) then rejoin. Annoying.
I contacted Apple and the support engineer said he never seen the authentication error 2100.

Attached is the error I get, and log says something similar to yours.

Have you found any solution besides the script? It's obviously something with 10.9 and SMB/AD. The issue is so random that I cant even isolate the prob. Happens on wired and wireless clients.

almonte32 · ‎12-14-2017

For a solution see my answer to the post:
https://www.jamf.com/jamf-nation/discussions/12776/apple-macs-losing-ad-binding

Jamf Nation Community

10.9 - AD mobile accounts unable to log in