>I don't know if the Kerberos server is more popular than the KA server. My
Well, I think my opinions are well known on the subject :-), but my
gut feeling is that the kaserver is run by the majority of AFS sites,
mostly because few people are comfortable with changing one of the
major parts of AFS to something completely different.
>First off all, why doesn't kas look at the AFS token in the current shell?
>The search order for password is;
>
>1: -admin switch
>2: Unix UID
>
>I think it shoud be;
>
>1: -admin switch
>2: AFS token in the shell
>3: Unix UID
Unfortunately, this isn't possible.
When you use "klog", you're getting (essentially) a Kerberos service ticket
for the afs service. However, when you run kas, you're getting a service
ticket for the Authuser.Admin service. You can't use the AFS service
ticket for talking to the kaserver - it simply won't recognize it.
Note that this is a deliberate design decision - otherwise someone could
come up to an unattended workstation and change a user's password without
having to enter in the original password first. If one of your AFS
admins left their workstation unattended or used the amazingly insecure
AFS token passing rsh, then an attacker could do all sorts of evil things
with kas.
BTW, only a few of the AFS commands check the Unix userid ... and this
is only done for the root vs non-root case. Certainly none of the
commands that talk to other machines check the Unix userid.
>The second question is about the "kas examine" command. Today everyone
>always have to enter a password when they do an examine. I don't like that.
See above; you can't get around it (well ... that's not _exactly_ true).
>You will ask me why. In our cell we don't use the Transarc AFS login
>program, we are using a special version of XDM login and Athena Kerberos
>telnet.
It sounds like you should really be running a Kerberos KDC.
>So today the users don't get any warning messages before the
>password expires. We have an idea of creating a shell script that do a "kas
>examine <loginuser>" at logintime that views a warning message. But today
>the users have to enter their own passwords to get that type of scripts to
>work okey. And the users don't like to type their passwords a second time
>they login.
>
>The second thing is that we have some administative scripts that needs to
>look in the KAS database. If I have a ADMIN token when I run this type of
>script it would be much easier, today I have to enter my password each time
>the script do an "kas examine".
There _is_ a way around this.
kas won't ask for a password if you already have a token for
Authuser.Admin. But, AFAIK, there is no way (other than internally
to kas) to get a service ticket for Authuser.Admin. So you would
have to hack your login/script process to get an Authuser.Admin ticket
and then you should be able to run "kas" without any problems. This
has it's own wonderful security problems, though.
Note that it's been a year since we've ran a kaserver, so I could be
off on a few details, but I'm pretty sure most of what I've said above
is correct :-)
--Ken
