Sun, 09 Dec 2007
k5 Zephyr, Part 1
Fully k5 zephyr has been in various states for the past few years. Recently, gendalia, a former co-worker of mine back at Iowa State has been tasked with pounding on it at work. Last week I loaded the new code in the TPROA realm to assist with doing cross-realm testing.
After some difficulty with getting my kdcs to work with a combination of having a principal with only des-* keys, being able to convert those into a srvtab, and have the kdc be able to find the keys when given a direct v4 tgt request (solved with a combination of pounding on my kdcs like a confused caveman — the kvno on my zephyr/zephyr went from 2 to 25 — and ifdefing out anything that was trying to get k4 credentials) we had something where we could send back and forth.
Interestingly, TPROA -> MENELOS will send auth zephyrs, but everything MENELOS -> TPROA was unauth. I suspect there is some enctype mismatches. But in the process of debugging that, I noticed that braindumps between my two zephyr servers were not working. Yes, my old nemesis, failing brain dumps.
After a couple days of staring at the code and littering it with printfs to simply understand what the hell it is doing, I understood enough of the code to see that the "server" side of the brain dump process wasn't written, so the server would run bdump_send, not actually do anything, and resume sending regular zephyr packets to the other server. This confused it to no end, because it was expecting to get an authentication exchange packet back and was getting regular zephyr packets (which, when it tried to decode them, made it really confused).
After several hours of staring at the "client" side of the code, I made an initial attempt at the "server" side, which did not work at all. After a couple of more hours of staring at the code again (and breaking out gdb, building with debug symbols and getting close to trying to decyper the asn.1 packet that the "server" was getting back and choking on) I realized that I had blindly copied too much code from the "client" side.
So, to write this down so I don't have to re-learn it the next time I have to understand this, this is how the brain-dump works up through the authentication steps:
| Server | Client |
| Server starts up, sends HELLO to all peer servers | |
| IHEARYOU | |
| Braindump avail, get it here | |
| send krb_ap_req, ask for mutual authentication | |
| read krb_ap_req, does it look good? Okay, send krb_ap_rep | |
| Read krb_ap_rep, good? Excellent |
My screwup was to have the server do a krb5_rd_rep when it should have been doing krb_rd_req. Incidentially, if krb_rd_rep spits out Unknown error: 1859794434, it's complaining about an unknown asn.1 field because it's reading the wrong type of packet. So, once I read enough to figure out what should happen in an ap_req/ap_rep exchange and coded it, I had working braindumps.
Posted at: 15:23 | category: /computers/zephyr | Link
Wed, 23 May 2007
Zephyr Weirdness
Okay, this is probably better entitled "Stupidity on My Part". If you have multiple zephyr servers and forget to put the keytab with the zephyr/zephyr principal in the proper place, they can't talk to each other. The symptom of this is your zephyr servers constantly trying to braindump at each other, and failing. Once I realized I had forgotten to put the keytab as well as the srvtab in the proper place, everything started working.
Posted at: 23:18 | category: /computers/zephyr | Link