Re: RFR 8239385: KerberosTicket client name refers wrongly to sAMAccountName in AD
Yes, please. Thanks, Max > On May 5, 2020, at 11:58 AM, Martin Balao wrote: > > Hi Max, > > On 3/30/20 5:24 PM, Martin Balao wrote: >> >> CSR requested here: https://bugs.openjdk.java.net/browse/JDK-8241871 >> > > Now that the CSR has been approved, are we good to push? > > Thanks, > Martin.- >
Re: RFR 8239385: KerberosTicket client name refers wrongly to sAMAccountName in AD
Hi Max, On 3/30/20 5:24 PM, Martin Balao wrote: > > CSR requested here: https://bugs.openjdk.java.net/browse/JDK-8241871 > Now that the CSR has been approved, are we good to push? Thanks, Martin.-
Re: RFR 8239385: KerberosTicket client name refers wrongly to sAMAccountName in AD
> On Apr 1, 2020, at 8:22 AM, Martin Balao wrote: > > Hi Max, > > Thanks for having a look at the CSR. > > On 3/30/20 11:39 PM, Weijun Wang wrote: >> 1. I don't think there is a need to talk about the java.security.krb5.conf >> system property, the krb5.conf file name is more popular. >> > > Added a reference to the krb5.conf file in the first place. I wish we > could keep a reference to the System property for completeness. OK. I just want to emphasize that we are following MIT krb5 the reference implementation of krb5, but not inventing something new. --Max > >> 2. I'd rather always say "TGS requests" instead of "AP requests". >> > > Changed. This also helped me to fix an AS/AP typo. > > I set the target release to JDK-15. > > Look forward to the CSR approval. > > Thanks, > Martin.- >
Re: RFR 8239385: KerberosTicket client name refers wrongly to sAMAccountName in AD
Hi Max, Thanks for having a look at the CSR. On 3/30/20 11:39 PM, Weijun Wang wrote: > 1. I don't think there is a need to talk about the java.security.krb5.conf > system property, the krb5.conf file name is more popular. > Added a reference to the krb5.conf file in the first place. I wish we could keep a reference to the System property for completeness. > 2. I'd rather always say "TGS requests" instead of "AP requests". > Changed. This also helped me to fix an AS/AP typo. I set the target release to JDK-15. Look forward to the CSR approval. Thanks, Martin.-
Re: RFR 8239385: KerberosTicket client name refers wrongly to sAMAccountName in AD
1. I don't think there is a need to talk about the java.security.krb5.conf system property, the krb5.conf file name is more popular. 2. I'd rather always say "TGS requests" instead of "AP requests". Thanks, Max > On Mar 31, 2020, at 4:24 AM, Martin Balao wrote: > > Hi Max, > > CSR requested here: https://bugs.openjdk.java.net/browse/JDK-8241871 > > Look forward to your comments or approval there. > > Thanks, > Martin.- >
Re: RFR 8239385: KerberosTicket client name refers wrongly to sAMAccountName in AD
Hi Max, CSR requested here: https://bugs.openjdk.java.net/browse/JDK-8241871 Look forward to your comments or approval there. Thanks, Martin.-
Re: RFR 8239385: KerberosTicket client name refers wrongly to sAMAccountName in AD
Hi Max, Thanks for having a look at this. On 3/29/20 1:10 AM, Weijun Wang wrote: >> * Note: from a client side, sending an NT-ENTERPRISE cname means that >> the cname can change in the response. Windows AD 2016, however, does not >> change it unless 'canonicalize' flag is explicitly set in the request. > > Sounds quite reasonable to me. This means "You might find info associated > with my other names, but please always call me by my original name". > Yes, correct. In fact, Windows AD seems not to change the cname when an NT-ENTERPRISE cname is sent and 'canonicalize' is false. AS referrals keep working in this case. However, it's more of a suggestion: if any other KDC decides to change an NT-ENTERPRISE cname even when 'canonicalize' was false in the request, we will handle that and move on (this is a bit off RFC 6806 as 'canonicalize' should have been true when sending an NT-ENTERPRISE). That's what we -and the MIT client- mean with "NT-ENTERPRISE" implies 'canonicalize'. Thanks, Martin.-
Re: RFR 8239385: KerberosTicket client name refers wrongly to sAMAccountName in AD
The change looks good to me. > On Mar 29, 2020, at 8:12 AM, Martin Balao wrote: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8239385/8239385.webrev.00/ > ... > * Note: from a client side, sending an NT-ENTERPRISE cname means that > the cname can change in the response. Windows AD 2016, however, does not > change it unless 'canonicalize' flag is explicitly set in the request. Sounds quite reasonable to me. This means "You might find info associated with my other names, but please always call me by my original name". Thanks, Max
