Destroy Kerberos Ticket

Since we deployed Leopard to the computers labs at work, I’ve been running in to this annoying problem involving Kerberos. I hadn’t spent any time trying to figure out how to circumvent it until now because it really only affects administrators. We can deal with our own problems right?

When a user logs in, they authenticate to our server using their account username (use Alice for this example). At this point they are given a Kerberos ticket. From then on, in Leopard, whenever the user attempts to connect to an AFP share on the server, Leopard assumes that they are connecting as the same user, Alice. Because the Kerberos ticket is still valid, the user is automatically authenticated as Alice. Of course, this makes perfect sense. That’s the whole point of Kerberos: single sign-on.

The problem resides in the assumption that the user wants to connect as the same user every time. What if Alice is actually an admin who needs to log on to a share using different credentials? Here’s an example: I’m testing a student account, with normal student privileges. During the course of my testing, I need to access a document from our administrative share point. Now, obviously the student account does not have access to the administrative share point. I would need to log in to the share using a user with permissions to access the administrative share point.

Unfortunately, Leopard will not even ask me what user account I want to use because I already have a valid Kerberos ticket for the student account. Fortunately, after finally getting fed up with this problem, a quick bit of googling solved it.

All that needs to be done is to destroy the Kerberos ticket. Simply open Keychain Access and select Kerberos Ticket Viewer from the Keychain Access menu. Select your Kerberos ticket from the window and click the destroy button. This doesn’t actually harm anything, it simply makes your Kerberos ticket expire. The next time you try and connect to the server, you will be asked to authenticate again; at which point you can authenticate as a different user.

Alternately, you could also create a new Kerberos ticket using a separate username to the same server. The before authenticating to a share, you would simply change the active user. Unfortunately it seems as though you can only access one at a time. For example, I could not mount two different user’s home directories at the same time. I would have to activate a user, mount their home directory, eject it, activate the second user, and then mount their home directory. Hmm, as you can probably see, there doesn’t really seem to be a reason why this would be useful. Probably simply destroying the ticket is the best bet.

For more information on this, check out the Mac OS X 10.5: About Kerberos in Mac OS X 10.5 clients knowledge base article from Apple.

Let Me Google That For You

If you work in IT Support, or even just have a reputation for being pretty good with computers, I can imagine that a lot of lazy people ask you dumb questions about computers. For me, one of the most frustrating aspects of working in IT Support is constantly being asked to help people that won’t help themselves. The initiative to actually look for answers to common problems oftentimes seems to be completely missing

Finally, Dave Child of Added Bytes has developed the solution: Let Me Google That For You Bookmarklet. Simply brilliant.

HTTP Errors

Here’s a great Flickr set on interpretations of the different HTTP Errors:

An Illustration of the HTTP Error 400. Shows a hot dog with two ice cream scoops and a cherry on top



appointive
appointive
appointive
appointive