Hi Emmanuel, Per request from Steve, we need to add him as Kerby contributor. His account is smoyer1. Would you help with such think one more time? Thanks.
Regards, Kai -----Original Message----- From: Zheng, Kai [mailto:[email protected]] Sent: Wednesday, November 04, 2015 4:40 PM To: Apache Directory Developers List <[email protected]>; Steve Moyer <[email protected]> Subject: RE: [jira] [Created] (DIRKRB-440) Enhance Kinit to request a service ticket Hi Steve, Thanks again for the great discussion and details! What's your typical credential type when need to request a service ticket? How about adding some new APIs like following for the purposes? Note we're open on this. public ServiceTicket requestServiceTicketWithPassword(String principal, String password, String serverPrincipal) throws KrbException As you said, it looks like to address a different question than DIRKRB-440. Maybe you can fire a new JIRA for your change? It looks good to me that you provide your codes together in a GH PR request. It's convenient for the community to review in a whole but I guess we'll still need to fire a JIRA and attach the changes as a patch there for the commit. One thing I'm not sure is how the credit would be counted since it's not going in the typical way used in the ApacheDS project and its children. If it's doable and not much a burden, would it be OK to break down your changes into smaller patches and have new JIRAs for them? Please feel free to fire them. We need to add you in the contributor list so issues can be assigned to you, but don't worry, I guess the community would help with that, adding you and your colleagues into the list. Emmanuel or anybody, would you give your thoughts here? I thought we have already implemented kadmin in local mode. Do you need it in remote mode, say admin executes it in a remote host other than the KDC server host? If yes then we'll need quite much work to implement it. In the medium term we're going to implement the mode by providing REST APIs first then kadmin tool can call them remotely. Sure if it's desired we could collaborate and make it earlier. Kpasswd would need to implement the change password protocol, right? It's also in our medium term. Sure we'd love to get it supported earlier. Kvno tool is also great to have. Thanks for the awesome work! The community expect close collaboration with you and your colleagues, making the project step further. You're most welcome! Regards, Kai -----Original Message----- From: Steve Moyer [mailto:[email protected]] Sent: Wednesday, November 04, 2015 8:05 AM To: Apache Directory Developers List <[email protected]> Subject: Re: [jira] [Created] (DIRKRB-440) Enhance Kinit to request a service ticket After a bit more investigation, at least name types "Principal (1)" and "Service and Instance (2)" are allowed. The client interface is becoming a bit awkward since the only way to pass the server principal to the client is through a request option. I've been Wiresharking packets all day and am close to having KinitTool's AS request packet to the point where it matches the MIT kinit binary on my machine. The KinitTool change made doesn't actually do what it's supposed to - it obtains a TGT using the client principal and password (or ...), then uses the TGT to obtain a service ticket. The MIT kinit binary (and the Heimdal one as of a couple years ago) only send one request for a TGT. The client principal and password are set as normal but the principal passed via the -S argument is added as a server principal. I'm just about done getting the KdcOptions flags working in the AS request packets since FORWARDABLE, PROXIABLE and RENEWABLE_OK are typically sent along with a kinit (at least when a -S is used). I've found a few other miscellaneous bugs and was hoping I could submit them all with the patch (they were all discovered while working on this code). Since I'm actually changing more than one file, I've cloned the project's GitHub mirror and will submit a pull request that encompasses my work. I'd also like to propose some refactoring for the client. Currently KrbClient is centered around KDC operations, but we're going to need kpasswd and kadmin client functionality too (our SCIM implementation will switch to using Kerby once we can run kadmin). I also wanted to investigate using the same AsRequest and AsResponse both on the server and client. In any case, I'll submit the pull request with only the changes needed for DIRKRB-440 and continue the discussion for the rest of this on the mailing list. As an aside, you've got KinitTool and KListTool, but the changes in this pull request would make a KvnoTool pretty trivial. If you're interested, put another issue in Jira and assign it to me (I'm smoyer1 in the Apache Jira). I expect one or more of my coworkers will get involved with the project too! Thanks again for all the work you've put into this library! 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: "Zheng, Kai" <[email protected]> To: "Apache Directory Developers List" <[email protected]>, "Steve Moyer" <[email protected]> Sent: Tuesday, November 3, 2015 5:53:39 PM Subject: RE: [jira] [Created] (DIRKRB-440) Enhance Kinit to request a service ticket Thanks Steve for the great investigation! You're right there's an implementation gap here. Please feel free working on this. Look forward to your patch. I thought Yaning would be ready to review and commit it. Regards, Kai -----Original Message----- From: Steve Moyer [mailto:[email protected]] Sent: Tuesday, November 03, 2015 11:48 PM To: Apache Directory Developers List <[email protected]> Subject: Re: [jira] [Created] (DIRKRB-440) Enhance Kinit to request a service ticket I've been working on what is, in essence, the Kerberos kvno tool (except our Java code verifies that the slaves are synchronized to the master) and have been fighting against a problem that I believes underlies the -S option of KinitTool.java. When you request a TGT, you can add a server name (principal) which should be of type "Service and Instance (2)". Currently, the client's requestTgtWithOptions() method doesn't seem to support either the SERVICE_PRINCIPAL or SERVER_PRINCIPAL options. I'm looking into why. Looking at Wireshark, I think it's just not implemented in the client library code. Regardless of the values passed, the server name remains the (default) krbtgt@<DOMAIN>. I'll submit a patch once I get the client's TGT request working. 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: "Xu Yaning (JIRA)" <[email protected]> To: [email protected] Sent: Tuesday, November 3, 2015 7:28:27 AM Subject: [jira] [Created] (DIRKRB-440) Enhance Kinit to request a service ticket Xu Yaning created DIRKRB-440: -------------------------------- Summary: Enhance Kinit to request a service ticket Key: DIRKRB-440 URL: https://issues.apache.org/jira/browse/DIRKRB-440 Project: Directory Kerberos Issue Type: New Feature Reporter: Xu Yaning In the USAGE of {{KinitTool.java}}, it supports parameter "-S service_name" to enable the user to request a service ticket. It just need to be implemented. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
