Wireshark for Kerberos debugging

Wireshark is a convenient tool for understanding the network traffic going from your client macine to your Active Directory server. The traffic should occur when a Kerberos ticket is requested by your browser when you open it against Kantega SSO in one of the Atlassian products. If you cannot see any traffic, please check Browser configuration to set up your browsers to send Kerberos tickets when requested.

Wireshark should be installed on the client machine where you have logged in as a domain user.

Before starting, download and install Wireshark on the client desktop.

You should initially be present with a screen that looks something like this. Click the indicated button to start a new capture (if you have an existing result Wireshark will ask if you wish to save this first).

Open

In the dialog that pops up, select the network interface(s) you want to capture traffic on. In this case "wlp61s0". You could also just use "any". The sparkline in the "Traffic" column indicates that something's happening on the interface (in other words, interfaces with flat sparklines likely aren't that interesting and can be ignored).

Disable promiscuous mode and enter "port 88" as the capture filter, to limit the number of packages that get captured. Then click Start.

Open

You should now be presented with an initially empty list of packets. This list updates live as traffic happens.
Now try logging into JIRA/Confluence etc. using Kerberos, and the list should start to fill up. A successful Kerberos interaction/login will look something like the screenshot. In the customer case, it's more likely there will be some error message. Hopefully, the capture can tell us why.

Stop the capture once you've gone through a full login (assuming it isn't empty). Then do File/Save to have the capture for later reference if it's needed.

After stopping the capture, you can optionally enter "kerberos" in the display filter box to hide TCP "noise" and only display the decoded Kerberos packets. Assuming this information is available, this is what we need to look at. The bottom pane contains decoded information (in this case a successful TGS-REP). You'll likely not want to send us the capture file itself (to have control over the information you're sharing with us), so instead, take some screenshots of the overview + expanded data nodes, like so.  

Note: If during testing you see NO Kerberos traffic what so ever, try doing "klist purge" from a console window first. When Kerberos tickets already exist in the cache, there will be no port 88 traffic. Don't do this during the failure capture itself, however, as this may be clearing the cause of the problem.