[OpenAFS] kaserver//k5 parallel migration
Douglas E. Engert
Fri, 19 Jan 2007 10:20:02 -0600
John W. Sopko Jr. wrote:
> I got this to work! That is I turned the kaserver back on and
> made sure the kvno were different in /usr/afs/etc/KeyFile. On
> the same machine I can do klog to the kaserver and things seem to work
> fine. Or I can kinit/aklog! Pretty nice! I also tested on another linux
> I do not quite understand why it works though. The fileserver is
> using the afs service keys from AD since the krb.conf file is
> pointing to the AD realm, or the -realm option to the fileserver :-).
Not really. The file server will accept a token, use the kvno
from the token to look in the KeyFile for a matching entry.
The KeyFile only has kvnos and keys. No service principal or realms
> If you klog to the kasserver you get a TGT from the kaserver. I think
> the kaserver then issues you a TGS afs service ticket the one generated
> from "bos setkey".
Sort of, the bos setkey end up in the KeyFile. The kaserver has a matching
(kvno and key ) entry in its database.
> But the fileserver is pointing to the AD afs service
> ticket. I tried reading how service ticket works and have to admit I do
> not fully understand them.
The asetkey can take the key from the AD created keytab, and copy
the kvno and key to the KeyFile. No principal is copied.
> I even made my user passwords different in the kaserver and
> the AD server and it still works fine! I just want to be sure this
> will work and why.
The catch here is you must make sure that your old kaserver based
users and AD based users are in the same name space. i.e.
joe on the kaserver is the same user as joe in the AD. Otherwise
the joe in AD now has AFS access to the old joe's files.
This is especially true if the cell name matches your AD Domain name
because the file server can not tell them apart.
> This will be a fantastic migration path for us and I
> am sure others. I think this will work whether or not you are using
> a MIT/Heimdal or Windows KDC server.
Yes it will.
> As I said, I will put together the steps for all of this. Just need
> some more time. BTW, Microsoft sent me the new ktpass. I still want
> to put it through more testing and understand the options better.
> I hope to work on this this afternoon.
> One ktpass questions. You originally told me to use the "-DesOnly"
> option, there is a + or - option to the command, the - turns
> this option off. I believe we want it on "+DesOnly". Does
> this option force a single DES key? Again just trying to
> understand more detail. I used "+DesOnly" with ktpass to create
> my working keytab.
> I just installed the the windows openafs 1.5.1302 client. Looks
> good! I will be testing on how to migrate it soon.
> Thanks for all your help.
> >> AM I CRAZY?
> >> -----------
> >> Once I get Windows AD working can I run both our current kaserver and
> >> Windows AD authentication against our production cs.unc.edu openafs
> >> at the same time? If I can generate afs/cs.unc.edu service pincipals
> >> with the same password on the kaserver and the AD server will this
> >> This may be a good migration path for us. We currently have 2 password
> >> databases, kaserver and Windows AD. When we create accounts we use the
> >> same user login name for both wndows and linux. Most users keep their
> >> passwords the same so logging into Windows gives them an afs token.
> >> Even if they don't we just tell them to use their Windows password
> >> as we migrate machine configurations.
> >> This way we can migrate machines to authenticate to "Windows AD only"
> >> over a short period of time and start testing real live systems.
> >> First I have to get Windows AD afs service pricnipal working.
> > AFS only stores DES keys by key version number. Ensure that your
> > kaserver key and your AD key have different version numbers and
> > you will be just fine.
> > Jeffrey Altman
Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439