Re: Kerby SNAPSHOTs

The latest SNAPSHOTs are available here: https://repository.apache.org/content/groups/snapshots/org/apache/kerby/ This should be updated every time the jenkins job successfully completes. Colm. On Fri, Nov 20, 2015 at 12:34 AM, Zheng, Kai wrote: > Thanks Stefan! So the

Re: Kerby SNAPSHOTs

Thanks so much! Steve -- “The mark of the immature man is that he wants to die nobly for a cause, while the mark of the mature man is that he wants to live humbly for one.” - Wilhelm Stekel - Original Message - From: "Colm O hEigeartaigh" To:

Re: [Announcement] New PMC Members

> On Nov 20, 2015, at 4:16 AM, Zheng, Kai wrote: > > Thanks for the kind consideration. It’s a great honor for me. Also > congratulations to Colm! Welcome to the Apache Directory PMC Colm and Kai! Shawn

RE: [Announcement] New PMC Members

Thanks for the kind consideration. It’s a great honor for me. Also congratulations to Colm! Regards, Kai From: Pierre Smits [mailto:pierre.sm...@gmail.com] Sent: Friday, November 20, 2015 5:58 PM To: Apache Directory Users List ; Apache Directory Developers List

Re: Categorize KrbOption by adding group info

Emmanuel and Kai, I hope I haven't done too much complaining! If I ever try to push the project in the wrong direction, please let me know. I intend to write a bit longer e-mail talking about what Penn State needs from the Kerberos client with some specific design questions about the Kerby

RE: Categorize KrbOption by adding group info

Thanks Steve for this complete deep thought about the client side design. It looks like centralizing all kinds of APIs in a place as KrbClient does isn't going in the right way. As we're going to support more mechanisms and provide more APIs for users, it will be hard without risk of breaking

RE: Categorize KrbOption by adding group info

Thanks Emmanuel! >> I just find it easier to stick to the RFC ... Agree. Just forgot to mention that in the core we do stick to the specs and define those types, like KdcOption. I would regard KrbOption(s) as the bridge or wrapper for the KrbClient API to frontend and interact with users'

RE: Categorize KrbOption by adding group info

That's awesome, thanks Kai. I've been tied up on another project (getting myvd integrated with apacheds-2.0.0-m20) but I'm hoping to dive back in this weekend Thanks Marc On Nov 20, 2015 1:25 AM, "Zheng, Kai" wrote: > Steve and Marc, > > It's done, along with some other

RE: Categorize KrbOption by adding group info

>> I'm not sure I see the point of having one gigantic Enum gathering all the >> possible flags that we can set on any different kerberos element. Ok, got your point. Yeah, KrbOption is becoming big, including all kinds of options from frontended mechanism (PKINIT, TOKEN ...), tools (KINIT,

Re: Categorize KrbOption by adding group info

Le 20/11/15 10:03, Zheng, Kai a écrit : >>> I'm not sure I see the point of having one gigantic Enum gathering all the >>> possible flags that we can set on any different kerberos element. > Ok, got your point. Yeah, KrbOption is becoming big, including all kinds of > options from frontended

RE: KDC is rejecting my TGS

Marc, You detail looks pretty good. Thanks! From your observation I copied below, I thought all the differences should be checked. The kvno (255 too large, bet 1) and principal name types for client and server may be the causes that block you, but I'm not very sure. For now, please set

RE: KDC is rejecting my TGS

The text format might save us some time when just want to take a look from having a tool dump out from hex. I guess the text could be ok if it's made more compact? -Original Message- From: Emmanuel Lécharny [mailto:elecha...@gmail.com] Sent: Saturday, November 21, 2015 7:04 AM To:

RE: KDC is rejecting my TGS

I have fixed the two mentioned issues and please check it out. The JIRAs are linked here https://issues.apache.org/jira/browse/DIRKRB-234 Will check other left things. -Original Message- From: Zheng, Kai Sent: Saturday, November 21, 2015 6:28 AM To: kerby@directory.apache.org Subject:

RE: KDC is rejecting my TGS

The hex format may does the good letting us find the exact missing or different field, though. It's concise and exact. -Original Message- From: Zheng, Kai [mailto:kai.zh...@intel.com] Sent: Saturday, November 21, 2015 9:06 AM To: kerby@directory.apache.org Subject: RE: KDC is rejecting

FW: [jira] [Created] (DIRKRB-463) Cryptographic Message Syntax (CMS) support

In the following days I will focus on implementing the long time desired CMS support completely. Jiajia Li has done pretty much great work on this. As she would focus on the PKINIT feature, I would continue with her work and get this done. Feedbacks are welcome! Regards, Kai -Original

Re: Categorize KrbOption by adding group info

Le 20/11/15 01:44, Zheng, Kai a écrit : > Hi Steve, > > Ref. https://issues.apache.org/jira/browse/DIRKRB-458 you're going to add > about 15 KDC flags into KrbOption. As we discussed it sounds reasonable. Now > here I'm considering it may be good to categorize them or easily identify > them as

RE: KDC is rejecting my TGS

OK, I will install the pcap stuff. What I've fixed is the TGS principal type, not the server principal type. As I said in the JIRA, it may be not the cause for the problem here. Another fix is the kvno. Still not the exact cause. I thought we need to figure out what field is missing in the ASN1

Re: KDC is rejecting my TGS

I think I'll make this easier and just provide links to a pcap. I pulled your updates Kai but am getting the same error. Here's the control: https://s3.amazonaws.com/ts-public-downloads/captures/kerberos-control.pcap.pcapng Here's the kerby capture:

RE: KDC is rejecting my TGS

See your snapshots. In the two AS-REQes, a diff is the kdc-option flags. Kerby sets the following all by default, which may be incorrect. In the client side KdcRequest.java file: protected void processKdcOptions() { // By default enforce these flags