[PATCH] Use UPN from Kerberos ticket

[Sumit Bose]

Hi,

this patch should fix https://fedorahosted.org/sssd/ticket/1634 and
eliminates the need to guess the UPN in the PAC responder.

bye,
Sumit

[Simo Sorce]

On Fri, 2013-03-22 at 15:37 +0100, Sumit Bose wrote:
> Hi,
>
> this patch should fix https://fedorahosted.org/sssd/ticket/1634 and
> eliminates the need to guess the UPN in the PAC responder.

Nack,
sorry I think that if we really want to change the protocol we should
send all the data available we may want to use from the ticket, not just
the client principal name, or we will need new revisions every time we
decide we need to check another bit of data.

If we do not want to do that work now I am ok splitting this in 2 parts,
and just use thje MS_PAC UPN buffer if available and construct the
client principal for the SamAccoutnName field in the PAC and defer
sending the client principal and other data from the Kerberos ticket by
opening a new trac ticket.

Simo.

[Jakub Hrozek]

On Mon, Mar 25, 2013 at 10:46:06AM -0400, Simo Sorce wrote:
> On Fri, 2013-03-22 at 15:37 +0100, Sumit Bose wrote:
> > Hi,
> >
> > this patch should fix https://fedorahosted.org/sssd/ticket/1634 and
> > eliminates the need to guess the UPN in the PAC responder.
>
> Nack,
> sorry I think that if we really want to change the protocol we should
> send all the data available we may want to use from the ticket, not just
> the client principal name, or we will need new revisions every time we
> decide we need to check another bit of data.
>
> If we do not want to do that work now I am ok splitting this in 2 parts,
> and just use thje MS_PAC UPN buffer if available and construct the
> client principal for the SamAccoutnName field in the PAC and defer
> sending the client principal and other data from the Kerberos ticket by
> opening a new trac ticket.
>
> Simo.

We decided to defer this work because there seems to be no real-world
use-case where the UPN would be any different than the one we guess.

Ticket #1634 has been moved to deferred.