[OpenAFS] kaserver//k5 parallel migration

[John W. Sopko Jr.]

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
> names.
> 
>>
>> 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 
>> work?
>>  >>
>>  >> 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
>>
> 

-- 
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