Posted on 09-08-2014 07:45 AM
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
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
Posted on 09-11-2014 02:49 AM
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.
Posted on 03-23-2015 02:39 PM
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.
Posted on 12-14-2017 09:19 AM
For a solution see my answer to the post:
https://www.jamf.com/jamf-nation/discussions/12776/apple-macs-losing-ad-binding