any way to get user's ldap dn (or part of it) as part of the ticket?

[Greg Hudson]

On 08/26/2016 02:10 AM, Chris Hecker wrote:
> I have a kerberized service that gets tickets from clients via 
> krb5_rd_req and I get the client name from the ticket using 
> krb5_unparse_name_flags.  On the KDC, these clients are in the LDAP 
> backend.  Is there any way to get the dn (which has a UUID) as part of 
> the ticket so I get can use it in the service?

There's no mechanism to do this at present, no.

> I know this is a bit of 
> a confusion between authn and authz, but I also know Microsoft has a 
> bunch of extensions that put a bunch of stuff into tickets that gets 
> carried around, and I'm wondering if there's an extension mechanism that 
> works for this.

Microsoft's PAC is visible to the server, not the client.

> I'd like to avoid another round-trip to the backend to 
> map from the client name to the UUID.  I'm willing to modify my MIT KDC 
> if necessary, although it'd be nice if was doable with a plugin in an 
> "official" way or something.

It might be possible to do this with preauth plugin modules.  The
kdcpreauth module would put the DN into a padata element via the
return_padata() function, and the clpreauth module would put the DN
value into a ccache config variable.  padata isn't protected on the wire
(unless FAST is used), but you might be able to encrypt or checksum the
DN in the reply key if that's important.  The preauth interface was
really intended to support preauthentication mechanisms and not adding
bits of information in the AS-REP, so you might run into a roadblock
that I'm not seeing.

>From a protocol perspective, encrypted padata (RFC 6806 appendix A) is
more attractive for this purpose, because it's protected inside the
encrypted AS-REP.  The KDC generates encrypted padata in
kdc_preauth.c:return_enc_padata().  There is no pluggable interface on
the KDC side or client side which grants access to encrypted padata, so
you'd be modifying the KDC and client code.

If you do either of these, you'll need to make up a padata type.
Negative padata types are reserved for unregistered use (RFC 4120
section 5.2.7).