Kerberos Issue - Client cannot Login to Yosemite Server

Question

Level 1

8 points

Kerberos Issue - Client cannot Login to Yosemite Server

Hi all,

I've successfully moved across from a Snow Leopard Server to Yosemite Server the manual way. I've managed to get all the users, email etc across. I had a few issues with SMB but I've not got them sorted. The only issue I have left is some of the users cannot login on a client machine (both running either Snow Leopard or Yosemite). The errors in console just mention about "com.apple.launchd.peruser. (com.apple.Kerberos.renew.plist) Exited with exit code: 1" and then stops the user logging in. I can connect to mail services, their AFP home directory and everything else fine. Console also shows that it mounts the home directory fine (I can also see this on the server where it list a connection from the client under the user's name.

Things I've tried:

- Checked hostname - All good with "success"

- Backed up and destroyed the LDAP server and then restored from backup

- Created a new user (not one that was pulled across from SLS) which also shows the same behaviour.

- Removing any old kerberos files on the client's and user's home directory.

- Checked the kerberos information for the User in Directory Utility. They all point to the correct server address.

On a Mavericks Client I get a slightly different error.

NetAuthSysAgent: NAHSelectionAcquireCredential The operation couldn’t be completed. (com.apple.NetworkAuthenticationHelper error -1765328228 - acquire_kerberos failed user@10.2.10: -1765328228 - unable to reach any KDC in realm 10.2.10, tried 0 KDCs)

This is strange that it tries the server IP address (which is actually 10.10.2.10). However I can't find anywhere that is mentions about 10.2.10 on the server config.

Any help would be great as I've been running the old SLS just to authenticate logins and then mount the home folder on the new server.

I used workgroup manager to export the users and didn't export Open Directory from SLS to Yosemite.

Thanks!

Posted on Jun 2, 2015 3:46 AM

Reply

Answer 1

Jun 2, 2015 5:12 AM in response to jbaileypro

It appears that your realm information is not correct. What is the fully qualified host name of the server? Is your DNS setup properly?

On a bound machine, try the following and report the results:

1: Log in as a the local admin

2: Open Terminal

3: Enter this command where username is an actual domain user name:

kinit username

4: When prompted, enter the user's password and hit return

5: Enter the following command:

klist

6: Try and connect to the server using the Finder's Go menu > Connect to Server

7: Repeat this command

klist

I am curious to see what your realm and service tickets are reporting.

Reid

Apple Consultants Network

Author "Yosemite Server – Foundation Services" :: Exclusively available in Apple's iBooks Store

Author "Mavericks Server – Foundation Services" :: Exclusively available in Apple's iBooks Store

Author "Mavericks Server – Control and Collaboration" :: Exclusively available in Apple's iBooks Store

Reply

Answer 2

jbaileypro Author

Level 1

8 points

Jun 2, 2015 6:41 AM in response to Strontium90

Thank you so much for your reply.

The hostname for the server is;

server.my-company.co.uk

This is reachable from both the internet and local. All internal clients are pointed towards the dns server on the yosemite machine (10.10.2.10). All addresses resolve correctly with ping/lookup.

Output from terminal:

$ kinit username

username@SERVER.MY-COMPANY.CO.UK's Password:

$ klist

Credentials cache: API:CDD612AC-E248-4E7C-9D75-A8280FD58C08

Principal: username@SERVER.MY-COMPANY.CO.UK

Issued Expires Principal

Jun 2 14:29:17 2015 Jun 3 00:29:13 2015 krbtgt/SERVER.MY-COMPANY.CO.UK@SERVER.MY-COMPANY.CO.UK

Connected to the server using afp://server.my-company.co.uk

Still asked me for a login so I used the same user.

Mounted home directory successfully.

$ klist

Credentials cache: API:CDD612AC-E248-4E7C-9D75-A8280FD58C08

Principal: username@SERVER.MY-COMPANY.CO.UK

Issued Expires Principal

Jun 2 14:29:17 2015 Jun 3 00:29:13 2015 krbtgt/SERVER.MY-COMPANY.CO.UK@SERVER.MY-COMPANY.CO.UK

Many thanks for you help again.

Reply

Answer 3

Linc Davis

Level 10

209,541 points

Jun 2, 2015 7:08 AM in response to jbaileypro

Many Open Directory problems can be resolved by taking the following steps. Test after each one, and back up all data before making any changes.

1. The OD master must have a static IP address on the local network, not a dynamic address. It must not be connected to the same network with more than one interface; e.g., Ethernet and Wi-Fi.

2. You must have a working DNS service, and the server's hostname must match its fully-qualified domain name. To confirm, select the server by name in the sidebar of the Server application window, then select the Overview tab. Click the Edit button on the Host Name line. On the Accessing your Server sheet, Domain Name should be selected. Change the Host Name, if necessary. The server must have at least a three-level name (e.g. "server.yourdomain.com"), and the name must not be in the ".local" top-level domain, which is reserved for Bonjour.

3. The primary DNS server used by the server must be itself, unless you're using another server for internal DNS. The only DNS server set on the clients should be the internal one, which they should get from DHCP if applicable.

4. If you have accounts with network home directories, make sure the URL's are correct in the user settings. A return status of 45 from the authorizationhost daemon in the log may mean that the URL for mounting the home directory was not updated after a change in the hostname. If the server and clients are all running OS X 10.10 or later, directories should be shared with SMB rather than AFP.

5. Follow these instructions to rebuild the Kerberos configuration on the server.

6. If you use authenticated binding, check the validity of the master's certificate. The common name must match the hostname and domain name. Deselecting and then reselecting the certificate in Server.app has been reported to have an effect in some cases. Otherwise delete all certificates and create new ones.

7. Unbind and then rebind the clients in the Users & Groups preference pane. Use the fully-qualified domain name of the master.

8. Reboot the master and the clients.

9. Don't log in to the server with a network user's account.

10. Disable any internal firewalls in use, including third-party "security" software.

11. If you've created any replica servers, delete them.

12. If OD has only recently stopped working when it was working before, you may be able to restore it from the automatic backup in /var/db/backups, or from a Time Machine snapshot of that backup.

13. Reset the password policy database:

sudo pwpolicy -clearaccountpolicies

14. As a last resort, export all OD users. In the Open Directory pane of Server, delete the OD server. Then recreate it and import the users. Ensure that the UID's are in the 1001+ range.

If you get this far without solving the problem, then you'll need to examine the logs in the Open Directory section of the log list in the Server app, and also the system log on the clients.

Reply

Answer 4

Jun 3, 2015 5:09 AM in response to jbaileypro

You are missing your service ticket for the server and service when you get results from the second klist. Now the mystery is discovering why it is not working. You are getting what appears to be a properly formatted TGT.

Try running:

sudo ktutil list

In the list you should see something similar to:

1 aes256-cts-hmac-sha1-96 afp/wave.carbontechnologies.com@WAVE.CARBONTECHNOLOGIES.COM

1 aes128-cts-hmac-sha1-96 afp/wave.carbontechnologies.com@WAVE.CARBONTECHNOLOGIES.COM

1 des3-cbc-sha1 afp/wave.carbontechnologies.com@WAVE.CARBONTECHNOLOGIES.COM

Obviously the server address and realm will match your environment. This is where the service principle for the AFP service can be found.

Stupid question. Is the OD Master and the file server the same machine?

Reply

Answer 5

jbaileypro Author

Level 1

8 points

Jun 4, 2015 1:26 AM in response to Strontium90

Thank you for all your replies.

I've got a little further and got users logging in correctly but with a very strange side affect. I can only get users to login to a home directory located on an external drive. If the user's home directory is located on the internal server drive it will give the kerberos error. The really strange thing is that I can see in the server logs that it mounts the users home directory and gets some of the listings for folder. The user's home directory can also be mounted successfully over AFP in the Finder. All user permissions have been repaired using "Server Cleanup".

Again simply moving the same home directory to the external drive lets the login complete successfully.

The reason that most users are located on the internal drive is because there is a fast SSD in the Mac Mini. The external drive is a MyBook Raid1 drive connected using firewire 800. Still fast enough but does produce bottlenecks.

I have also tried moving the user and let the login process create a new home directory on the internal drive. This creates a home directory in the correct place but also errors.

I have also created a new folder for a users share on the root of the internal drive. This also has the same issues as the "Users" folder on the internal drive.

I have checked permissions and they seem correct (they are also the same as the external drive's Users folder). Again AFP can mount the home directory in Finder and login can create a new home directory but won't complete login.

The home directory mount in the users advanced settings looks to also be correct (file path wise).

Any other ideas?

Thanks to Linc Davis. I went through all those steps listed. All completed successfully but no change.

Strontium90 - Yes. It is the same machine hosting both the users directories (over AFP as most of the clients are Snow Leopard at the moment) and Open Directory.

When I run the command on a bound client machine it just lists many tickets but they are all SHA1 hashed. For example:

1 aes256-cts-hmac-sha1-96 afpservert/LKDC:SHA1:hash key@LKDC:SHA1.same hash key

None of them are not hashed.

Thanks again guys!

Reply