PKINIT name mapping?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

PKINIT name mapping?

Nordgren, Bryce L -FS
Hi all,

I'm looking to set up a KDC to issue TGTs from my organization's smart cards. Establishing a trust is a non-starter. My target environment is outside the firewall, all corporate infrastructure is inaccessible and will stay that way. However, CA bundles are public information. Looking at my PIV certificate, I see my SAN is:

Other Name:
     Principal Name=[hidden email]

I won't type that big long number every time I try to login. My peers will revolt. As it turns out, when I put the smart card in my corporate machine, klist shows that the client in the resulting tickets is: [hidden email]<mailto:[hidden email]>. There is really nothing in the certificate which would perform this mapping. I can, however, automatically generate a mapping file to push out to my KDC by querying AD. (For instance, I'm pretty sure a 1:1 mapping between userPrincipalName and sAMAccountName would do the trick.)

How would I compel the MIT Kerberos server to perform that same mapping? I want to be able to ask for a ticket for "[hidden email]", provide a certificate with a MS UPN of [hidden email]<mailto:[hidden email]> and have it work. I also want it to KRB_ERROR if a valid certificate with any other MS UPN tries to get a ticket for [hidden email]<mailto:[hidden email]>.

Has this already been done, and if not, would it be possible to do the mapping by writing a plugin?

Bryce
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: PKINIT name mapping?

Ken Hornstein
>I won't type that big long number every time I try to login. My
>peers will revolt. As it turns out, when I put the smart card in my
>corporate machine, klist shows that the client in the resulting tickets
>is: [hidden email]<mailto:[hidden email]>. There is really
>nothing in the certificate which would perform this mapping. I can,
>however, automatically generate a mapping file to push out to my KDC
>by querying AD. (For instance, I'm pretty sure a 1:1 mapping between
>userPrincipalName and sAMAccountName would do the trick.)
>
>Has this already been done, and if not, would it be possible to do the
>mapping by writing a plugin?

We've done that here, but to answer your question ... no, you can't do
it with a plugin.  Well, technically, you CAN ... the answer is "write
a whole new PKINIT plugin, or modify the existing one".  We did the
latter.

The way this is implemented is that you'd set a string for each principal
using the set_string interface; this would be a "cert match" rule
that would match the certificate presents (you can look at the man page
for krb5.conf, specifically the pkinit_cert_match rule for the syntax).
So you could map a specific principal to only work with a specific SAN,
just as an example.

In talks with MIT, they agreed those changes would be useful and it was
on my plate to submit those for review ... and that never happened.  But
it's still on the list of things for me to do.  These changes would also
include a few other things you might be interested in (the ability to
query against an OCSP server, and the ability to set the HW_AUTH flag
in the ticket if your client certificate had a particular policy OID
in it).  So, it's possible ... just not with the current code.

--Ken
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

RE: PKINIT name mapping?

Nordgren, Bryce L -FS
Ken,

Thanks for the info and the perspective!

> We've done that here, but to answer your question ... no, you can't do it with
> a plugin.  Well, technically, you CAN ... the answer is "write a whole new
> PKINIT plugin, or modify the existing one".  We did the latter.

Your code doesn't happen to be lying around github somewhere does it? :)

> The way this is implemented is that you'd set a string for each principal using
> the set_string interface; this would be a "cert match" rule that would match
> the certificate presents (you can look at the man page for krb5.conf,
> specifically the pkinit_cert_match rule for the syntax).
> So you could map a specific principal to only work with a specific SAN, just as
> an example.

Sounds doable as a path of least resistance. Updating sounds difficult. Or at least more challenging than my initial thought to dump a new map out of AD every night, replacing the previous map.

I suppose whether the map can be separable really boils down to whether it's always necessary to have a backend database which contains every user. In some situations, the map itself might suffice to define users: any mapped client principal could be served by the KDC as long as the certificate matches the associated rule. Of course, one will either be adding extra user principals, service principals or establishing trusts, so a db is still necessary to store the keys/passwords. Hmmm.

Writing a "complex" update system sounds like less effort than busting apart the backend db. :) I'm liking your solution.

Bryce


________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos