The login window doesn't give much in the way of indications why a user isn't allowed to log in -- it shakes its "head" no, but doesn't say why. Sometimes you can find something in the system.log file (view it with the Console utility) about what the problem was, but generally not.
My standard approach to narrowing down where errors like this are coming from is to test the critical parts of a network login (user info lookup, authentication, and home directory mount) by hand and watch for informative errors:
Log in as a local user (not a network user) on a client computer, and open the Terminal utility.
Run the command id suchandso
(where "suchandso" is the short name of a network user). It should reply with something like "uid=1025(suchandso), gid=20(staff)," etc. If it instead replies with "id: suchandso: no such user", you either have the wrong username or the client is having trouble looking up user info on the server over LDAP. (Note: if this were the problem in your case, you'd probably have all users failing, not just the one. Check anyway, just in case.)
There are actually two different modes of authentication, and you should test them both. First, check Password Server-style authentication with the command su suchandso
(followed by the user's password when prompted -- note that it won't echo as you type). You may get an error message from this even if it succeeds (e.g. something about the home folder not being found), so use the whoami
command to see if you're now running as "suchandso" -- if you are, PS-based authentication is working (and you should use the exit
command to go back to normal before proceeding).
Next, try to get a network authentication (Kerberos) ticket with the command kinit suchandso
(again followed by the user's password when prompted). If this works, it'll just come back with another shell prompt. If something goes wrong, you'll generally get an informative error message about what the problem is (e.g. if it says "Kerberos Login Failed: Clock skew too big", that means the client's clock is too far out of sync with the server's and one or both of them needs to be corrected).
If kinit
gives a "Password incorrect" message (despite the same password working for su
), that suggests that the server's password databases are out of sync and you should reset the user's password to force them back into agreement. Using the command passwd suchandso
is probably the best way to do this (doing a reset in Workgroup Manager won't always fix it).
If those work, use the Finder's Connect to Server (Command-K) feature to try to connect to the server; enter the server's full domain name in the Server Address field. You should not be prompted for a name and password (Kerberos authentication should be automatic after the kinit
command; if not, something's wrong with the file service's Kerberos setup). You should get a "Select the volumes to mount" dialog including the Users folder (or whatever folder your user homes are under). Note that the user's actual home folder will also be listed, but that's not what you want; select the "Users" folder instead. If the Users folder isn't listed, or you get an error trying to mount it, troubleshoot that.
If none of that shows any problem, you've got something more obscure going wrong. One other thing to try is to make sure the user's home folder settings are configured correctly: use WGM to switch the user's home folder to "(None)", save, then set it back and save again.
What do the logs say? Can he authenticate using that password anywhere else? For example, if someone else logs into the GUI, can you use the "broken" account to authenticate to / mount an AFP file server that authenticates against the same server? What is your authentication server? OD? AD? If OD, is the "broken" account's password storage type the same as the working accounts? – Spiff – 2011-03-28T20:33:52.993