A janela de login não dá muitas indicações de porque um usuário não tem permissão para efetuar login - isso abala sua "cabeça" não, mas não diz por quê. Às vezes, você pode encontrar algo no arquivo system.log (visualizá-lo com o utilitário Console) sobre qual era o problema, mas geralmente não.
Minha abordagem padrão para restringir a origem de erros como este é testar as partes críticas de um login de rede (pesquisa de informações do usuário, autenticação e montagem do diretório base) manualmente e observar erros informativos:
Efetue login como um usuário local ( não um usuário da rede) em um computador cliente e abra o utilitário Terminal.
Execute o comando id suchandso (onde "suchandso" é o nome abreviado de um usuário da rede). Ele deve responder com algo como "uid = 1025 (suchandso), gid = 20 (staff)," etc. Se ele responder com "id: suchandso: no such user", você tem o nome de usuário errado ou o cliente está tendo dificuldade em procurar informações do usuário no servidor através do LDAP. (Nota: se este fosse o problema no seu caso, você provavelmente teria todos os usuários falhando, não apenas aquele. Verifique de qualquer maneira, apenas no caso.)
Na verdade, existem dois modos diferentes de autenticação e você deve testá-los. Primeiro, verifique a autenticação no estilo do servidor de senhas com o comando su suchandso (seguido pela senha do usuário quando solicitado - observe que ele não vai ecoar enquanto você digita). Você pode receber uma mensagem de erro mesmo que tenha sucesso (por exemplo, algo sobre a pasta home não ser encontrada), então use o comando whoami para ver se você está rodando como "suchandso" - se você estiver, PS A autenticação baseada em mensagens está funcionando (e você deve usar o comando exit para voltar ao normal antes de continuar).
Em seguida, tente obter um tíquete de autenticação de rede (Kerberos) com o comando kinit suchandso (novamente seguido pela senha do usuário quando solicitado). Se isso funcionar, apenas voltará com outro prompt de shell. Se algo der errado, você geralmente receberá uma mensagem de erro informativa sobre o problema (por exemplo, se "Falha no login do Kerberos: distorção do clock muito grande", significa que o relógio do cliente está muito fora de sincronia com o servidor e um ou ambos precisam ser corrigidos).
Se kinit der uma mensagem "Senha incorreta" (apesar da mesma senha funcionar para su ), isso sugere que os bancos de dados de senha do servidor estão fora de sincronia e você deve redefinir a senha do usuário para forçá-los a concordar . Usar o comando passwd suchandso é provavelmente a melhor maneira de fazer isso (fazer um reset no Workgroup Manager nem sempre irá consertá-lo).
Se isso funcionar, use o recurso Conectar-se ao Servidor (Command-K) do Finder para tentar se conectar ao servidor; insira o nome de domínio completo do servidor no campo Endereço do servidor. Você não deve ser solicitado a fornecer um nome e uma senha (a autenticação Kerberos deve ser automática após o comando kinit ; caso contrário, há algo errado com a configuração Kerberos do serviço de arquivos). Você deve obter uma caixa de diálogo "Selecione os volumes para montar", incluindo a pasta Usuários (ou qualquer pasta em que as residências dos usuários estejam). Observe que a pasta pessoal real do usuário também será listada, mas não é isso que você deseja; selecione a pasta "Usuários". Se a pasta Usuários não estiver listada ou se você receber um erro ao tentar montá-la, solucione o problema.
Se nada disso mostrar algum problema, você tem algo mais obscuro dando errado. Uma outra coisa a tentar é certificar-se de que as configurações da pasta pessoal do usuário estão configuradas corretamente: use WGM para mudar a pasta home do usuário para "(None)", salve, defina-a novamente e salve novamente.