Kerb v4 for MacOS X

[Miro Jurisic]

>Currently, we're using this pretty often. CMU is upgrading lots
>of servers to Kerb5 from Kerb4. Users who hadn't updated their
>password (via changing their password) recently would not be able
>to access new kerb5 services (as their password entry contained
>just an old kerb4 entry). Anyhow, the technical reasons are a
>bit past me. :) I could ask one of our systems developers to
>explain if you're curious.
>
>We also have started running "password crackers" against our
>/etc/passwd to check for easy-to-guess/crack passwords. And
>we encourage users to change passwords if guessed.

My personal opinion is that change password is an operation not done 
frequently enough to warrant putting in the Kerberos menu. I 
understand the v4 -> v5 transition issue, but that's only going to 
happen once for any given user. Maybe it's possible that you could 
convince me that this would be valuable at CMU, but I would still not 
be convinced that this is something that's useful in general. The 
whole purpose of the Menu and the Control Strip is to provide 
commonly used functionality. For example, you can compare this with 
the Energy Saver control panel and Control Strip module, where the 
CSM gives you the basic functionality used often, and an option to 
open the Control Panel if you need more control (note that Kerberos 
Menu and Kerberos Control Strip module both allow you to open the 
Kerberos Control Panel on 9).

I think that the answer here is that you have a 2-step procedure (on 
Mac OS 9) for changing password: select "Open Kerberos Control Panel" 
from Kerberos Menu and then click on "Change Password". I am having a 
hard time believing that this is either hard to explain to users or 
hard for users to do when they need to change their password.

On Mac OS X, if you are running the Kerberos application, you can 
close its main window, and then all  you will have is the Dock icon 
which shows you the current status. If you click on that icon, the 
main window opens, and you can then click on the "Change Password" 
button. So, if you are running the Kerberos application, it's again a 
2-step process -- click on the dock icon, click on "Change Password".

We are not opposed to a Kerberos Menu on Mac OS X, however Apple has 
not provided the documentation for us to do that, and we have focused 
on a number of more important issues. Don't forget that the Kerberos 
Menu was completely absent in KfM 3.0 on Mac OS 9, and only came back 
in 3.5 -- I would not be surprised if something similar happens on 
Mac OS X. We certainly will not hold up 4.0 final release for 
Kerberos Menu on Mac OS X :-)

>So let me re-phrase :) : We like people to easily know if they
>have current tickets or not. The KfM for classic always shows
>by default whether the user has current tickets (via the menu
>icon)

If you run the Kerberos Application on Mac OS X, you get that display 
in the dock. Which brings us to your next question...

>If there's documentation somewhere on how I can configure the
>installer to place & "run" Kerberos by default on an install,
>that would rock!

There is no way to configure the installer to do this right now. 
Without further investigation I can't tell you whether we can or want 
to do this right now, so I can't tell you much here :-)

>  So hence, by "run", I mean is an active program
>on OS X (with that silly triangle under the icon in the Dock).
>I could be mistaken, but if you open the Kerberos application,
>you can choose "Keep in Dock", but when the Application is not
>open, active, and running, the icon will show a YELLOW key whether
>there are active tickets or not.

This is a good point. We'll have to think about this. I agree it can 
be confusing.

>2 new requests from our other Mac expert (who also said you guys
>rock and did a great job with Kerberos for Mac) - we're just
>full of praise:

We really appreciate that :-)

>3) Kerberos for Mac generates a "Service Expired" message if the
>Time is out of bounds / off synch. Users get confused by this: Could
>the error message be changed to something with the word "time" in
>it; even Time Out of Bounds is fine.

That's interesting. Are you using any form of preauthentication? I 
could have sworn we verified this and it worked fine in our setup.

>Sure, it would be great if Kerberos could tie into the System Prefs
>and either let the user update the time immediately or take them to
>the Date & Time prefs. But that's asking a lot.

It's really none of our business whether your users have time set 
right or not. We can't give them useful instructions for what to _do_ 
once in the D&T prefs, because that really depends on what CMU wants 
them to do. Do you want them to use a specific time server? Setup 
time by hand? Something else? The best answer is probably for CMU to 
choose a policy for what the users should do, document the policy, 
and provide a simple app the users can run to setup their machines 
according to that policy. I agree that the error message is 
suboptimal, and we can look into that, but I definitely know that 
there is one preauthentication mechanism which makes it impossible to 
detect time out of bounds errors with 100% reliability.

>4) If someone deletes their Kerberos Preferences, they lose their
>ANDREW.CMU.EDU or CS.CMU.EDU realm and Kerberos reverts to an MIT.EDU
>server. Is this possible to customize, so CMU's distribution has
>the default set to ANDREW.CMU.EDU ? :)

Yes, you can edit 
/System/Library/Frameworks/Kerberos.framework/Frameworks/KerberosPreferences.framework/Resources/DefaultRealmsConfiguration 
after the installer installs it.

meeroh
-- 

<http://web.meeroh.org/> | MIT I/S Mac developer | KB1FMP

"Well, I must endure the presence of two or three caterpillars if I 
wish to become acquainted with the butterflies." -- Antoine de 
Saint-Exupery, "The Little Prince"