Kerberos Ticket Issues - Bind to AD using Centrify

[bgreeno]

I posted this comment/question on another discussion - https://jamfnation.jamfsoftware.com/discussion.html?id=4080, but don't think it will get any response because that discussion has been resolved.

We have an issue where if our users restart their computer their kerberos credentials are removed. We have many laptop users and they do not connect via Ethernet before logging back in after restarting. This means they do not acquire a new Kerberos ticket. We also use Centrify Express to bind our Macs. I am a novice when it comes to automating this process. Is there a way to automate this process for our Mac laptop users?

I've created an AppleScript command that can be run via Self Service after they've logged in and are connected via Wi-Fi to retrieve a new Kerberos Ticket so that they can print.

#! /bin/sh

osascript -e 'launch application "Terminal"' -e 'tell application "Terminal" to activate' -e 'tell application "Terminal" to do script with command "login $USER" in window 1' -e 'delay 15' -e 'do shell script "killall Terminal"'

It would be great to just request the ticket for them automatically using the currently logged user's password. Is this possible? Thanks for the help!

[JPDyson]

I'm afraid there's not a great answer to this; if their login is authenticated based on cached credentials, they won't get their TGT until their next manual login to something (unlocking the screen, mounting a share, etc). I can give you a better terminal command though (kinit).

[corbinmharris]

What version of Centrify? We were having folks off the network who cached credentials were expiring too soon. 5.1.3 seem to have resolved this for most folks, but we still have it happen every week for someone.

We do have an open ticket with Centrify to get it 100% resolved.

This is the current open ticket with Centrify -

The current theory as to what is happening is as follows: - The host knows itself as "mbp15undv35", and it is joined as such. - However the local hostanme is coming back as "dhcp-10-14-70-243", likely from the DHCP - Since "dhcp-10-14-70-243" does not exist in AD, it is likely the cause of the error.

- The network trace will more definitely tell the reason for "Server not found in Kerberos database".

For your reference, here are the full steps including the disabling of the ldap encryption:

1. Review ( http://support.apple.com/kb/HT3994 ) and make sure you are capturing from the correct interface.

2. Login to the Mac as Local Admin and add the following line to the bottom of /etc/centrify/centrifydc.conf

adclient.ldap.packet.encrypt: Disabled

1. Save the file and run:

sudo adreload adinfo -c

1. Make sure the above line appears in the list of parameters, if it doesn't - restart the Mac and try again.

2. Open the Diagnostic Tool and make sure CentrifyDC mode: Connected.

3. Go to the Debug / Logs section and click in order:

[ 0. Clear Debug Log Files ] [ 1. Enable / Disable Debugger ]

1. Open the Terminal and start the network trace (Run the tcpdump command from the Apple KB corresponding to your network interface.)

2. Open a SECOND Terminal window and run the following commands:

sudo addns -U -m sudo addns -U -u mluna-admin

(Replace "mluna-admin" as appropriate)

1. After the "Server not found in Kerberos database" errors are shown, go back to the Terminal with the network trace happening and stop recording.

2. Go back to the Diagnostic Tool > Debug / Logs and press:

[ 1. Enable / Disable Debugger ] [ 2. Save Debug Log files to Desktop ]

1. Send the DumpFile01.pcap and the Full_Log_Pack.zip files from the Desktop.

[bgreeno]

@corbin3ci I appreciate the post. I think our issue may be a little different. Our mac laptops never have an issue getting kerberos credentials if they don't shutdown. But if they do restart and then login while wireless, then they will not acquire new credentials until, as @JPDyson said

if their login is authenticated based on cached credentials, they won't get their TGT until their next manual login to something (unlocking the screen, mounting a share, etc)

.

@JPDyson, I'm interested in how to make it work via kinit. I'm just trying to find a way to acquire a new TGT if a user logs in using cached credentials without their having to do anything. The main issue this causes is laptop users not being able to print if they login using cached credentials, which of course causes them to submit helpdesk tickets. I could add the printers to their computer via IP address, but then they would not print through the print server, which tracks printing jobs.

Hopefully, this clarifies the issue more. @JPDyson, I've tried running ```
/usr/share/centrifydc/kerberos/bin/kinit
``` however, this requires the user's password. I want to automate it via JSS policy without their involvement i.e. if they are on 10.x subnet attempt to acquire a TGT.

[BLau]

Hi Ben,

There is a feature called "infinite renewal" which should get the Kerberos tickets to get recreated when it detects the Mac goes back into Connected mode. This should be set to true by default, but just in case - look in /etc/centrifydc/centrifydc.conf and look for the following line:

krb5.cache.infinite.renewal: true

If it's not there, then please add the line, save it and then run the command:

sudo adreload

After you connect back onto the network, run the command:

adinfo -m

And make sure that it returns "Connected".
If so, infinite renewal should allow the tickets to get renewed momentarily afterwards.

If it's not happening fast enough, try adjusting the "krb5.cache.renew.interval" parameter in the centrifydc.conf file. (Don't forget to run sudo adreload after making a change)

You can check which configuration parameters are currently active by running:

adinfo -c

Hope that helps!
Brian

[bgreeno]

@BLau thanks for the help. krb5.cache.infinite.renewal: true is set on our computers, however, the issue is when the computer is restarted the ticket is deleted. Laptops can't get a new ticket automatically because, after restart, the laptops are not connected to the network until after they login. I'm looking for a way to automatically get a ticket after they've logged in.

[BLau]

Hi Ben,

If infinite renewal is already enabled, then your laptop users should be getting their tickets recreated when they get back onto the network - even after they've already logged in (i.e. When the agent goes back into "Connected" mode).

If this is not working, then we'd need to see a set of debug logs to see why this is not happening behind the scenes.

We've actually worked together before, so I know you have a licensed account with us at Centrify and you can open a support ticket with us to look into this further.

Use the steps below:

- Before starting, make sure you've already downloaded our Diagnostic Tool to the Mac (http://community.centrify.com/t5/The-Centrify-Apple-Guys/Introducing-the-New-Mac-Diagnostic-Tool/ba-...)

1. Log into the Mac as the AD user (while disconnected)
2. Before connecting to the network, open the Diag Tool and enable debugging
3. Connect to the network
4. Run "adinfo -m" until it returns "Connected"
5. After it connects, give it around 5 minutes, and then double-check that no tickets were regenerated
6. Disable the debugger and pack up the logs
7. Send the debug logs into us and point back to this thread as a reference

Thanks!
Brian

[bgreeno]

@BLau Hi Brian, if possible, could we open up a Centrify support ticket so I could share some info with you outside of this thread?

[BLau]

Hi Ben,

Of course - check out our sparkly new Support Portal here and create a ticket in the usual manner.

Kind regards,
Brian