[OpenAFS] kaserver//k5 parallel migration
John W. Sopko Jr.
Fri, 19 Jan 2007 14:59:39 -0500
Douglas E. Engert wrote:
> 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 machine.
>> 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.
No problem for us. We have always kept our L/Unix account and
Windows account user names the same.
>> 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 cell
>> >> 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
>> >> databases, kaserver and Windows AD. When we create accounts we use
>> >> 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
John W. Sopko Jr. University of North Carolina
email: sopko AT cs.unc.edu Computer Science Dept., CB 3175
Phone: 919-962-1844 Sitterson Hall; Room 044
Fax: 919-962-1799 Chapel Hill, NC 27599-3175