Kerb v4 for MacOS X
meeroh at MIT.EDU
Fri Jan 25 17:27:00 EST 2002
>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
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
>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
after the installer installs it.
<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"
More information about the krbdev