[seawolfe]

OK, this is how you can test for and fix this issue.

1. When you are logged into a computer for the first time as a user, open terminal and run the [b]klist[/b] command. If you have not received Kerberos credentials from the server, you this will return “No credentials cache found while getting the ccache principal”. If that is the case, then go to step 2 below. If you receive a different response, then this issue isn’t your problem.

2. To ensure the Kerberos problem isn’t with the server, run the [b]kinit[/b] command and enter the user password to obtain a TGT. Run klist again and you should see the proper Kerberos credentials. If you don’t see this, then you have issues either with the user account or the server.

3. To confirm (and reproduce) this behaviour, you can run the [b]kdestroy -a[/b] command, log out and back in, and you should find that the user has no Kerberos credentials cached when you run [b]klist.[/b].

4. To fix this issue, you will need to edit the /etc/authorization file. However, this should be done with care and only after a backup of the file has been made or you could cause yourself a lot of grief. Apple has an article detailing this issue as someone else noted (http://support.apple.com/kb/HT4100 for more information). However, this is way to make the changes at the command line using plist buddy (note that this only works for 10.5 and 10.6). You will need to reboot after making this change.

/[b]bin/cp /etc/authorization /etc/authorization.save
/usr/libexec/PlistBuddy /etc/authorization -c “set rights:system.login.console:mechanisms:4 builtin:krb5authnoverify,privileged”
[/b]

If you have problems with accounts getting locked out after doing this, then you have another problem, probably with the AD server.

[Author]

Posts