[12:54:16] I have a few questions about krb5 [12:54:38] only a few ? :) [12:54:43] :-) [12:55:02] do you have a bit time? [12:55:30] for a while, yes [12:57:21] I'm creating a capture give you the url and then ask you ok [13:00:19] sure [13:02:24] http://samba.org/~metze/krb5-sign-seal-01.cap [13:03:16] got it [13:03:30] in packet 21 the ldap server returns accepted in the first reply [13:04:15] but in frame 27 the rpc server return accept incomplete [13:04:43] and accept ok in 29 [13:04:55] what is the difference [13:04:58] ? [13:05:21] is it the the rpc use sign and seal and the ldap only sign [13:05:59] and how could I implement that in the server [13:06:14] you probly only request cleartext in ldap [13:06:43] no, see frames 38... [13:08:34] how can I decide if I need to return ok or more_procession_required from the krb5_rd_req() return alues [13:08:40] how can I decide if I need to return ok or more_procession_required from the krb5_rd_req() return values [13:10:06] you look that the sasl and gssapi layer bits ? [13:10:12] I see krb5_rd_rep() and krb5_mk_rep() but I'm don't find understandable docs about how that needs to work [13:10:39] ? [13:10:40] its in the 8003 checksum in the krb gss layer [13:10:49] if mutual auth is required [13:11:05] ? [13:11:11] what packet [13:11:53] in the first gss token there is the 8003 checksum [13:12:16] what packet [13:12:44] the first spnego packet contains a optional optmistic token, inside that [13:12:59] ldap, or rpc [13:13:11] just tell me that number of the packet [13:13:22] that gss krb5 token have a authentictor with a checksumtype of 0x8003, it contains bits if mutual auth is required [13:14:12] why don't you just use the gss layer instead of krb5 ? [13:14:36] for ldap, its the first the first bind request (20) [13:15:01] mmm [13:15:13] i might be confused with ethereal [13:16:17] yes, its packet 20, I don't know any dcerpc, need to look closer at that [13:16:50] I see encryption type 23 rc4-hmac [13:17:25] at frame offset do you see 0x8003 [13:18:02] at what frame offset do you see 0x8003? [13:19:19] and for me the GSS-API blob in packet 20 looks the same like the one in 25 [13:20:10] given that the authenticator is encrypted, its not really possible to see [13:21:06] inside the encrypted authentictor there is a checksum, that checksum is of type 0x8003 [13:22:40] that checksum contains bits if the request is mutual auth or not [13:23:07] but what is your real question, I might have misunderstod what you are asking about [13:26:14] ok, are this flags checked in krb5_rd_req() [13:26:19] my packet 25 seem to be part of the dce-rpc bind, but its a fragment that ethereal haven't deframented, so the gss token is truncatned in packet 24 [13:26:29] no, its not its checked in the gssapi layer [13:26:57] see lib/gssapi/{accept_*,8003}.c [13:30:46] so what we do in samba4 and samba3 is just pass the ticket_blob to ads_keytab_verify_ticket() [13:31:02] and that passes it to krb5_rd_req() [13:31:37] and if the return code is 0 we pass back accept ok in the gss layer [13:32:05] so the rpc bind against samba4 replies accept ok in the first reply [13:32:43] and then w2k3 dcpromo stops and prompt the user for a password [13:34:27] but if the client reqested mutual auth, you need to do more, is that you problem ? [13:36:32] but didn't the client do that for the ldap too [13:37:46] you seem to blantaly ignoreing that inside the authentictor (and thus the checksum), that a problem [13:38:12] you should only do krb5_mk_rep if the user requested mutual [13:39:34] so what do I need to change in samba4, ads_keytab_verify_ticket() to match what windows does [13:39:58] wait a second and I'll uload the capture from w2k3 against samba4 [13:40:10] the one you already got is w2k3-w2k3 [13:41:35] its ads_verify_ticket that needs to look inside the authenector checksum and check the flags field [13:42:19] you can check that with a debugger (probably) [13:45:11] ok, now I need to now how [13:48:06] how do I convice ethereal to show me the DCERPC PDU ? [13:48:29] http://samba.org/~metze/krb5-sign-seal-samba-01.cap [13:48:30] the first (24) is split over 3 packets, 24,25,26 [13:49:41] edit->properies->Protocols->dcerpc and select both fields [13:50:06] edit->preferences->protocols->dcerpc and select both fields [13:50:25] I need to get some food back in ~30 mins [13:53:22] still failes to assable the first packet (24), I'm using ethereal-0.10.6 [13:55:55] <@tridge> good night! [13:57:04] good night [14:12:15] bah, of course the dhcp machine on the other side of campus decides it hates the world [14:21:17] night tridge [14:21:26] lha: I use 0.10.7 [14:23:56] I also have selected reassemble KRB5 and LDAP [14:23:59] and SMB [14:25:20] so what do I need to call in ads_ticket_verify [14:32:21] good knight?? we have 14:32 here [14:32:27] uihm. night ;) [14:34:17] lha: so is it corect to say that the apoptions 0x20000000 in the AP-REQ have no effect(ethereal says Mutal required for this flag) [14:40:31] how do the smbd-forks communicate. Via pipes or sockets? [14:44:30] metze: back from biride to recover dhcp server, with you in a second [14:44:58] thx [14:47:02] metze: look at gss_accept_sec_context and how it calls gssapi_krb5_verify_8003_checksum to extract flags [14:48:00] if you put breakpoint in ads_ticket_verify and check authenticator->cksum you'll see what flags are used [14:49:46] the first 32bits is the length, second 16 bytes are hash of binding, fast 20-23 bytes is the flag field [14:50:33] and the flags maps to the GSS_C_(context flags) flags [14:51:20] lha [~lha@vr.l.nxs.se] has quit IRC (Excess Flood) [14:51:54] lha [~lha@vr.l.nxs.se] has joined #samba-technical [14:52:02] lol... [14:52:04] sorry about that [14:52:15] ok, good day, you all! [14:52:47] Maiexus [~karsten@pD9E20083.dip.t-dialin.net] has quit IRC ("using sirc version 2.211+KSIRC/1.3.10") [14:53:11] if you dump authenicator->cksum I can parse it for you [14:54:48] one sec [15:07:15] so I need krb5_auth_con_getauthenticator() and then gssapi_krb5_verify_8003_checksum() [15:08:39] will gssapi_krb5_verify_8003_checksum isn't a portable interface, you need to do it yourself [15:10:20] ok [15:10:59] why are there krb5_cc_initialize() calls in gss_accept_sec_context () [15:12:42] in case there is delgated token (forwarded ticket) [15:13:31] or you could use the gssapi interface directly [15:13:55] we'll see [15:14:06] but I don't know if the dcerpc layer uses gss encryption or not [15:14:31] so there are also GSS_C_CONF_FLAG and GSS_C_INTEG_FLAG [15:14:38] lha: I think it do [15:14:56] if it doesn't, one would have to use the umich gss extention called lucid that export the cryptokeys [15:16:01] re (CONF/INT) in the authenticator ? that whats requsted to be supported by the client, that information is passed up the the caller if its acceptable [15:16:25] does the APOtions have an effect here [15:17:16] not really, because they don't commuicate the wishes of the initator [15:17:54] ok, we can ignore it then [15:23:21] jerry is now known as jerry[out][ [15:23:23] jerry[out][ is now known as jerry[out] [15:34:02] lha: gssapi_krb5_context is a global, right? [15:34:56] metze: you can't assume that, its not true for mit gss and will change when heimdal grows mechglue (soon) [15:36:23] what is mechglue [15:38:14] just create your own context, they are not that expensive/hard to create [15:38:41] mech glue is glue so you can have several gss mechs in the same application [15:39:24] so KRB5 and NTLMSSP or what do you mean? [15:39:26] mech glue is what you link to and, and the mech glue will dlopen the appopriate gss mechs [15:39:49] basicly, yes [15:39:53] ok [15:41:07] so if there is a ntlm gss mech/ssp, it could be used at the same time as the krb5 one using spnego to negociate [15:41:56] ok [15:42:33] is there any documentation on the portable krb5_* api [15:43:56] not really, there are some documentation in mit kerberos and some in heimdal current, when I finish writing writing the documentation for heimdal, I'll go over it and mark up what function are portable [15:44:19] btw: gsskrb5_accept_sec_context() doesn't handle GSS_C_MUTUAL_FLAG [15:44:30] if you find any issues that are simple to fix, please tell me and I'll make sure we change if its possible to change w/o breaking the api/abi [15:44:31] where is the dicumentation for heimdal [15:45:06] where is GSS_C_MUTUAL_FLAG checked [15:45:11] metze: manpages [15:46:22] accept_sec_context.c:448: if(flags & GSS_C_MUTUAL_FLAG) { [15:46:45] in heimdal current [15:49:18] ok I found it [15:50:00] but it always returns GSS_S_COMPLETE, is that the same as Accept Complete in ethereal [15:50:55] I would assume so, the the spnego return value that mean the lower mech is done [15:51:11] so what is the real error you get bind failes for dcerpc ? [15:54:28] I don't know excatly, I just see the windows return accept incomplete and samba4 not [15:55:05] but I'll try to debug the authenticator flags to see what the diference is