Re: A client name with an '@'
On Wed, 2015-06-03 at 17:07 +, Nordgren, Bryce L -FS wrote: Or hack on the KDCs to implement AD-style case-insensitive/preserving realm matching. I'm starting to think that we ought to do this in Heimdal and MIT Kerberos, at least as an option. This plus canonicalizing is how our corporate system might work. I don't think there's a FEDIDCARD.GOV realm (or fedidcard.gov either) outside the scope of my PKINIT test. I think our corporate AD sees users from that domain and knows (somehow) how to map them into the USDA.NET realm. Klist has never shown me a FEDIDCARD.GOV ticket on my windows box, and I can't locate a FEDIDCARD.GOV KDC inside or outside the firewall. Maybe canonicalizing isn't the right word for this...appropriating user identities from unrelated virtual realms may be more descriptive. I had nothing to do with it. :) In AD there is a mapping function to know which user a certificate belongs to. AD does not care at all about the name you have in there outside the mapping. Once mapped what matters is the UPN on the user account, IIRC. Simo. -- Simo Sorce * Red Hat, Inc * New York Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Differentiate the ServiceTicket issued from Kinit vs PKinit
Never mind. I assume the flags is inside the ticket. Thanks Jim On Jun 3, 2015, at 3:52 PM, Jim Shi hanmao_...@apple.com wrote: Hi, Ken, The TGS ticket flag is set on KDC server. When the client get TGS back from the server, he/she is able to see the flag set by the KDC. Looks klist commands will show flags. However if the client passes the ticket to some service for verification, , the service will not be able see the these flags. Is that right? My understanding is that these flags are not passed to service?? Thanks Jim On Jun 3, 2015, at 6:39 AM, Ken Hornstein k...@cmf.nrl.navy.mil mailto:k...@cmf.nrl.navy.mil wrote: Does this mean the client certificate should have the policy : 1.3.6.1.4.1.311.20.2.2 (Smart Card Logon)? Is it only the client certificate or CA cert should also have this policy? Well, we don't use that particular OID; we use another one defined by our CA that indicates it comes from an approved Smart Card. But that's the basic idea. I don't want to get into a whole discussion about certificate policy; that's sort of outside of the scope of this thread. I will say that in our particlar case, it only matters that the client certificate has that policy OID on it and that's all our implementation checks for. And let me be clear; this is not something that exists in the supplied MIT Kerberos pkinit module. This is our own version of it. I've talked with MIT about incorporating our changes into their module, and they have been receptive; I just haven't had time recently to deal with it. --Ken Kerberos mailing list Kerberos@mit.edu mailto:Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos https://mailman.mit.edu/mailman/listinfo/kerberos Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Differentiate the ServiceTicket issued from Kinit vs PKinit
Hi, Ken, The TGS ticket flag is set on KDC server. When the client get TGS back from the server, he/she is able to see the flag set by the KDC. Looks klist commands will show flags. However if the client passes the ticket to some service for verification, , the service will not be able see the these flags. Is that right? My understanding is that these flags are not passed to service?? Thanks Jim On Jun 3, 2015, at 6:39 AM, Ken Hornstein k...@cmf.nrl.navy.mil wrote: Does this mean the client certificate should have the policy : 1.3.6.1.4.1.311.20.2.2 (Smart Card Logon)? Is it only the client certificate or CA cert should also have this policy? Well, we don't use that particular OID; we use another one defined by our CA that indicates it comes from an approved Smart Card. But that's the basic idea. I don't want to get into a whole discussion about certificate policy; that's sort of outside of the scope of this thread. I will say that in our particlar case, it only matters that the client certificate has that policy OID on it and that's all our implementation checks for. And let me be clear; this is not something that exists in the supplied MIT Kerberos pkinit module. This is our own version of it. I've talked with MIT about incorporating our changes into their module, and they have been receptive; I just haven't had time recently to deal with it. --Ken Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: A client name with an '@'
Ah, I didn’t read the context. MIT has supported client name canonicalisation in AS-REQs for a while so it might be worth a try. Also: re earlier message, enterprise principal names (UPNs) imply canonicalisation, so you shouldn’t need to set the canon flag if you’re using this name type. — Luke On 2 Jun 2015, at 11:37 pm, Nordgren, Bryce L -FS bnordg...@fs.fed.us wrote: You could try the -C and -E options to kinit: -C canonicalize -E client is enterprise principal name — Luke I could, but I'm not certain the MIT Kerberos KDC (to which kinit is connecting) knows how to canonicalize. Boy if I could get user principal mapping going, that would be sweet. For the moment, I seem to be PKINITing successfully. Bryce -- www.lukehoward.com soundcloud.com/lukehoward Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: A client name with an '@'
Hi, Nordgren, Bryce L -FS wrote: I could, but I'm not certain the MIT Kerberos KDC (to which kinit is connecting) knows how to canonicalize. It does not. It will however handle usernames with an embedded @ as any other, as you've already found. Boy if I could get user principal mapping going, that would be sweet. Or you might retain the uppercase realm and try to cross-sign between the uppercase and lowercase realms. Your (somewhat silly) clients logon to the lowercase realm and gain access to the (less errorprone) uppercase realm. Cheers, -Rick Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Differentiate the ServiceTicket issued from Kinit vs PKinit
On Tue, 2015-06-02 at 21:29 -0700, Jim Shi wrote: Hi, Simo, Does this require to modify MIT KDC source code? Yes -- Simo Sorce * Red Hat, Inc * New York Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Differentiate the ServiceTicket issued from Kinit vs PKinit
Hi Ken, Thanks for your response. This really helps. *Our KDC-side PKINIT module will set HW-AUTH flag on the TGT _if_ a particular policy OID is found in the client certificate (in our case, the policy OID we check for is if the certificate comes from a smartcard, so the use of HW-AUTH is appropriate). * Does this mean the client certificate should have the policy : 1.3.6.1.4.1.311.20.2.2 (Smart Card Logon)? Is it only the client certificate or CA cert should also have this policy? On Tue, Jun 2, 2015 at 6:11 PM, Ken Hornstein k...@cmf.nrl.navy.mil wrote: Today we use password based authentication (kinit). And we want to introduce PKinit. But while validating ServiceTicket we would like to know if the service ticket issued through Kinit to PKinit Is there a way to find this? We sort-of do this, but it may not directly be applicable. Our KDC-side PKINIT module will set HW-AUTH flag on the TGT _if_ a particular policy OID is found in the client certificate (in our case, the policy OID we check for is if the certificate comes from a smartcard, so the use of HW-AUTH is appropriate). Flags set in a TGT get propagated to service tickets, so we have code on application servers that checks to see if the HW-AUTH flag exists for service tickets to make authorization decisions. So, you could do that (if your client-side certificates is issued from a hardware device), or overload the HW-AUTH flag. Checking that on the application server side is easy. But ... if you don't want to do that, you MAY be able to check the service ticket for the AD_INITIAL_VERIFIED_CAS authorization data (although a quick glance suggests to me that MIT Kerberos doesn't generate that data, but I could be wrong about that). That would require further investigation. --Ken -- Thanks Regards, J.Aravind Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: A client name with an '@'
Boy if I could get user principal mapping going, that would be sweet. Or you might retain the uppercase realm and try to cross-sign between the uppercase and lowercase realms. Your (somewhat silly) clients logon to the lowercase realm and gain access to the (less errorprone) uppercase realm. I think if you had two realms that differed only by case, that would be a recipe for a disaster (what happened when you tried to look up realm information in DNS, which is case-insensitive for lookup?). Also, the venerably Russ Allberry created a lowercase realm for Stanford, and repeatedly has said that if he had to do it all over again he wouldn't have done a lowercase realm; too much software assumes an uppercase realm. Maybe that has changed in the intervening years. --Ken Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
RE: A client name with an '@'
Or hack on the KDCs to implement AD-style case-insensitive/preserving realm matching. I'm starting to think that we ought to do this in Heimdal and MIT Kerberos, at least as an option. This plus canonicalizing is how our corporate system might work. I don't think there's a FEDIDCARD.GOV realm (or fedidcard.gov either) outside the scope of my PKINIT test. I think our corporate AD sees users from that domain and knows (somehow) how to map them into the USDA.NET realm. Klist has never shown me a FEDIDCARD.GOV ticket on my windows box, and I can't locate a FEDIDCARD.GOV KDC inside or outside the firewall. Maybe canonicalizing isn't the right word for this...appropriating user identities from unrelated virtual realms may be more descriptive. I had nothing to do with it. :) Bryce Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: A client name with an '@'
On Wed, Jun 03, 2015 at 11:21:04AM -0400, Ken Hornstein wrote: Or you might retain the uppercase realm and try to cross-sign between the uppercase and lowercase realms. Your (somewhat silly) clients logon to the lowercase realm and gain access to the (less errorprone) uppercase realm. I think if you had two realms that differed only by case, that would be a recipe for a disaster (what happened when you tried to look up realm information in DNS, which is case-insensitive for lookup?). Or hack on the KDCs to implement AD-style case-insensitive/preserving realm matching. I'm starting to think that we ought to do this in Heimdal and MIT Kerberos, at least as an option. Also, the venerably Russ Allberry created a lowercase realm for Stanford, and repeatedly has said that if he had to do it all over again he wouldn't have done a lowercase realm; too much software assumes an uppercase realm. Maybe that has changed in the intervening years. I'd stay away from lower-case realm naming. We keep putting off reckoning with I18N. But the more we do it the more we'll effectively end up with the right solution (namely, recognize that we just-send-8, say that only UTF-8 will interop reliably, then make KerberosString be UTF8String with an IA5String implicit universal tag, list domainname slots in the protocol and put U-labels in them, recognize A-labels as aliasing U-labels in KDBs; with IDNA2008 we could even do the right thing as to treating realms as domainnames that are strangely capitalized). Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
RE: A client name with an '@'
Also, the venerably Russ Allberry created a lowercase realm for Stanford, and repeatedly has said that if he had to do it all over again he wouldn't have done a lowercase realm; too much software assumes an uppercase realm. Maybe that has changed in the intervening years. Kind of moot. These smart cards are issued from GSA credentialing centers for USDA and certificate production is outside my sphere of influence. The really odd part is that the lowercase realm is encoded into the certificate, but the realm in Active Directory is uppercase. I don't know if this is some kind of oversight, some kind of requirement to make Active Directory canonicalize correctly, or if they're intentionally making it hard to use. Thanks for all your help! Bryce Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: A client name with an '@'
On Wed, Jun 03, 2015 at 04:29:19PM +, Nordgren, Bryce L -FS wrote: Kind of moot. These smart cards are issued from GSA credentialing centers for USDA and certificate production is outside my sphere of influence. The really odd part is that the lowercase realm is encoded into the certificate, but the realm in Active Directory is uppercase. I don't know if this is some kind of oversight, some kind of requirement to make Active Directory canonicalize correctly, or if they're intentionally making it hard to use. AD matches realms case-insensitively (though case-preserving). Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Differentiate the ServiceTicket issued from Kinit vs PKinit
Never mind. I assume the flags is inside the ticket. Yeah, exactly. The KDC sets the flags, so you can trust their validity. The one big issue is that if you're programming the GSSAPI, there's not a standardized GSSAPI function you can call to retrieve those flags, which is unfortunate; for MIT Kerberos, there is a function called gss_krb5_get_ticket_flags() you can use and it looks like the same thing exists for Heimdal. --Ken Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: A client name with an '@'
Ken Hornstein k...@cmf.nrl.navy.mil writes: Also, the venerably Russ Allbery created a lowercase realm for Stanford, and repeatedly has said that if he had to do it all over again he wouldn't have done a lowercase realm; too much software assumes an uppercase realm. Maybe that has changed in the intervening years. It worked okay (still is, so far as I know), but all the documentation everywhere was wrong and it definitely wasn't worth the confusion. We never tried having realms that only differed in case, though. That really would have broken all DNS-based service discovery, etc. -- Russ Allbery (ea...@eyrie.org) http://www.eyrie.org/~eagle/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
