I'm upgrading my desktop clients to use Mac OS X 10.6.2, and I'm having real trouble. Network users can't login using the login window. This works fine with 10.5.x clients.

I can also ssh as a network user to the affected computer and it works great. I just can't use the GUI login window.

Here's what I've tried:

  • I set the Login Options using the Accounts PreferencePane. I enabled network login and my OD master was set as the "Network Account Server."
  • Login window didn't work.
  • Restart. Didn't work.
  • Disabled and re-enabled "allow network users to log in at login window". Didn't work. Restarted. Didn't work.
  • Checked server OD security settings. Restarted server. Doesn't work.

Again, I can login via SSH, but the GUI login window doesn't work!

Any suggestions?


Here are some things to look at:

  • On the login window, underneath where it says Mac OS X, there will be some text -- I think the default is the computer's host name. Click on it several times. Does it show that 'Network Accounts are Available?' with a green indicator?

  • Is there anything interesting in /var/log/system.log or /var/log/secure.log? (Sometimes it is nice to ssh into the box, run tail -f on one of those files, and watch what happens when you log in).

  • Are you able to log in graphically/via ssh with a local account?

  • The fact that you can authenticate via ssh is a good sign, which seems to indicate that you are bound to the directory properly. Nevertheless, what does using dscl tell you?

  • If you run the command mcxquery in a terminal on the machine, do you get anything other than

    Error 'no data found' (-4584) running compositor for user: (user)  group: (null)  computer: =
  • Just to verify: These same clients worked fine before you upgraded to 10.6? Which OS is your server running?

  • * Can't check the login window, I'll try that tomorrow. * I can log in graphically and via ssh with local accounts - no problem. * Already checked dscl -- works fine, can find users. (Makes sense, with ssh working) * mcxquery doesn't return anything strange * Yes, these clients worked great with 10.5.x -- and existing 10.5.x clients still work. * The server is running 10.6.1, but I also tried an update to 10.6.2 today and that didn't help. – Geoff Hutchison Feb 16 '10 at 23:51
  • secure.log mentioned EAPOL connection. I'll check if there's somehow an 802.1X profile which is messing things up. – Geoff Hutchison Feb 16 '10 at 23:54
  • Hmm... Nothing obvious from all of that. Did mcxquery indicate that the computer is bound to and managed by your server? I'm still interested to see what the login window says when you click on it. Does anything change if you unbind the computer from the directory and rebind it? – Clinton Blackmore Feb 17 '10 at 15:29
  • The login window said Network Users were Available with a green light. Nothing changed when I rebound the client multiple times. As I describe below, the problem was EAPOL and 802.1X. Weird, but I understand why it wasn't an obvious fix. – Geoff Hutchison Feb 17 '10 at 19:48

The key clue in this puzzle was the EAPOL connection. This is responsible for 802.1X authentication, which is needed for our wireless network. Of course this is a desktop computer and had wireless disabled.

However, when I investigated the AirPort "Advanced" settings, I saw that there was a "LoginWindow" profile for 802.1X. In short, the Mac was attempting to authenticate to the wireless network with the login user/password. Of course that failed. Removing this 802.1X setting solved the problem.

I don't know why this only happened after the 10.6 upgrade.

Here's Apple's KB article: KB3326 - Network Preferences for 802.1X

At the login screen, one enters a name and password. If LoginWindow can't find a local user account with that name, it initiates an 802.1X session using the same name and password and in the case of an 802.11 network, it associates to the wireless network. After the 802.1X authentication completes, LoginWindow authenticates the user against the directory service. If that authentication succeeds, the user is logged in.

So for Google purposes... here's the secure.log:

Dec 16 12:20:39 tritium SecurityAgent[171]: Network Authentication will be attempted

Dec 16 12:20:39 tritium SecurityAgent[171]: Attempting EAPOL connection

Dec 16 12:20:39 tritium SecurityAgent[171]: EAPOLConnectTimeout = 60.000000

Dec 16 12:20:39 tritium SecurityAgent[171]: DSBindTimeout = 60.000000

Dec 16 12:20:39 tritium SecurityAgent[171]: EAPOL NOT connected
  • Wow. Good detective work. That is bizarre. – Clinton Blackmore Feb 18 '10 at 2:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.