[36992] in Kerberos
RE: PKINIT name mapping?
daemon@ATHENA.MIT.EDU (Nordgren, Bryce L -FS)
Tue May 19 12:48:30 2015
From: "Nordgren, Bryce L -FS" <bnordgren@fs.fed.us>
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Date: Tue, 19 May 2015 16:47:21 +0000
Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E7DBBD4@001FSN2MPN1-046.001f.mgd2.msft.net>
In-Reply-To: <201505182219.t4IMJLuq013497@hedwig.cmf.nrl.navy.mil>
Content-Language: en-US
MIME-Version: 1.0
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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 Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
