kcpytkt to copy a service ticket for client principal not matching the default principal

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

kcpytkt to copy a service ticket for client principal not matching the default principal

Josef Petermann
Hi,

Our goal is to spawn user sessions that have a service ticket for a third service without having to enter a password nor using unconstrained delegation. Let's assume the users come pre-authenticated and we only have their username.

We are using protocol transition and contrained delegation on Service A ([hidden email]) to obtain a service ticket for Service B (HTTP/[hidden email]) for User X (jpetermann).

    # kinit -k -t /etc/httpd/rstudio-server.keytab [hidden email]
    # klist
    Ticketzwischenspeicher: FILE:/tmp/krb5cc_0
    Standard-Principal: [hidden email]

    Valid starting       Expires              Service principal
    15.06.2020 17:31:08  16.06.2020 03:31:08  krbtgt/[hidden email]
        erneuern bis 22.06.2020 17:31:08

    # kvno -k /etc/httpd/rstudio-server.keytab -U jpetermann -P HTTP/[hidden email]
    HTTP/[hidden email]: KVNO = 3, Schlüsseltabelleneintrag gültig

    # klist
    Ticketzwischenspeicher: FILE:/tmp/krb5cc_0
    Standard-Principal: [hidden email]

    Valid starting       Expires              Service principal
    15.06.2020 17:31:08  16.06.2020 03:31:08  krbtgt/[hidden email]
        erneuern bis 22.06.2020 17:31:08
    15.06.2020 17:31:43  16.06.2020 03:31:08  [hidden email]
        für Client [hidden email], erneuern bis 22.06.2020 17:31:08
    15.06.2020 17:31:43  16.06.2020 03:31:08  HTTP/[hidden email]

Now we are trying to use kcpytkt to extract the service ticket for Service B for User X from the ccache of Service A. Unfortunately we are unable to extract a service ticket for a user that is not the default principal:

    # kcpytkt -c /tmp/krb5cc_0 /home/jpetermann\@lab.biz/cache42
    HTTP/[hidden email]/[hidden email]: Matching credential not found while retrieving credentials

How can we get kcpytkt to match a credential not matching the default principal? Ideally, the solution would involve supplying the client principal as an additional command line argument to kcpytkt.

Is there maybe another way to provide a service ticket to the user's session?

Thanks and Regards,

Josef Petermann



_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: kcpytkt to copy a service ticket for client principal not matching the default principal

Greg Hudson
On 6/15/20 5:28 PM, Josef Petermann wrote:
> How can we get kcpytkt to match a credential not matching the default principal? Ideally, the solution would involve supplying the client principal as an additional command line argument to kcpytkt.

We don't build or install kcpytkt except on Windows.

I have been thinking of adding some options from Heimdal's kgetcred to
kvno, including --out-ccache, which initializes a ccache and stores the
retrieved credential into it.  Would that be adequate here?
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

AW: kcpytkt to copy a service ticket for client principal not matching the default principal

Josef Petermann
Hi Greg,

thanks for the hint regarding Heimdal's implementation,
we managed to use kgetcred to extract the service credential.

    # kinit -k -t /etc/httpd/rstudio-server.keytab [hidden email]
    # kvno -k /etc/httpd/rstudio-server.keytab -U jpetermann -P HTTP/[hidden email]
    # kgetcred -n --out-cache=/home/jpetermann\@lab.biz/cache45 HTTP/[hidden email]

> I have been thinking of adding some options from Heimdal's kgetcred to
> kvno, including --out-ccache, which initializes a ccache and stores the
> retrieved credential into it.  Would that be adequate here?

It would be really helpful for us to have that functionality in krb5 as well, yes.
Note that we also needed to use the -n flag to create a cache in the name of the "foreign" client principal.

Thanks,
Josef
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev