• KRB5 ccache on MACOS

    From Markus Moeller@21:1/5 to All on Sun Oct 10 00:58:48 2021
    Hi

    I was trying to share a FILE ccache between different process/logins on a MAC but it seems gss_init_sec_context ignores KRB5CCNAME on a MAC. Is that correct ? If so is there a way to share the API ccache ?

    The case I have is a background job seems to use the API ccache of when
    the user was logged in. When I log off and log in again I can't access the original ccache anymore i.e. I can't update the credentials and need to kill and restart the background job.

    Thank you
    Markus

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Markus Moeller@21:1/5 to All on Sun Oct 10 19:23:53 2021
    Hi,

    I tried to use the MIT version 1-19 instead on my MAC but run into a
    different issue. The same code works on Linux but on MAC I get this SPNEGO error. Any hint why this might be the case ?

    gss_init_sec_context()failed: Unspecified GSS failure. Minor code may
    provide more information. SPNEGO cannot find mechanisms to negotiate

    major_status = gss_init_sec_context(&minor_status,
    GSS_C_NO_CREDENTIAL,
    &gss_context,
    server_name,
    gss_mech_spnego,
    0,
    0,
    GSS_C_NO_CHANNEL_BINDINGS,
    &input_token, NULL, &output_token, NULL, NULL);


    Thank you
    Markus


    "Markus Moeller" wrote in message news:sjtabp$7tp$2@ciao.gmane.io...

    Hi

    I was trying to share a FILE ccache between different process/logins on a MAC but it seems gss_init_sec_context ignores KRB5CCNAME on a MAC. Is that correct ? If so is there a way to share the API ccache ?

    The case I have is a background job seems to use the API ccache of when
    the user was logged in. When I log off and log in again I can't access the original ccache anymore i.e. I can't update the credentials and need to kill and restart the background job.

    Thank you
    Markus


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ken Hornstein@21:1/5 to Markus Moeller on Sun Oct 10 18:13:53 2021
    Copy: kerberos@mit.edu

    I was trying to share a FILE ccache between different process/logins on a
    MAC but it seems gss_init_sec_context ignores KRB5CCNAME on a MAC. Is that >correct ? If so is there a way to share the API ccache ?

    Which version of MacOS X are you on?

    --Ken

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Markus Moeller@21:1/5 to All on Mon Oct 11 00:32:38 2021
    It is

    #sw_vers
    ProductName: macOS
    ProductVersion: 11.6
    BuildVersion: 20G165


    Markus

    "Ken Hornstein" wrote in message news:202110102213.19AMDrlM030098@hedwig.cmf.nrl.navy.mil...

    I was trying to share a FILE ccache between different process/logins on
    a
    MAC but it seems gss_init_sec_context ignores KRB5CCNAME on a MAC. Is that >correct ? If so is there a way to share the API ccache ?

    Which version of MacOS X are you on?

    --Ken
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ken Hornstein@21:1/5 to Markus Moeller on Mon Oct 11 09:04:59 2021
    Copy: kerberos@mit.edu

    It is

    #sw_vers
    ProductName: macOS
    ProductVersion: 11.6
    BuildVersion: 20G165

    Alright, so, Big Sur.

    There were significant changes in the credential cache support on Big Sur.
    I didn't check for file cache support, but .... it looks like to me that
    in fact Kerberos on Big Sur _does_ respect the KRB5CCNAME enviroment
    variable:

    % env KRB5CCNAME=FILE:/tmp/foo klist
    Credentials cache: FILE:/tmp/foo
    Principal: kenh@CMF.NRL.NAVY.MIL
    [...]

    Now it may be that gss_init_sec_context() may be doing something slightly
    more magical. If that is the case ... well, I'm not sure there is an
    easy fix for that.

    You can share API credential caches; previously to Big Sur it used Mach Ports for the IPC mechanism, and that was based on the Unix userid for access.
    With the new mechanism, I am not sure how that works, exactly. Specifically
    I do not know whether or not you can access one set of credentials from
    another login session.

    Regarding your problem with MIT Kerberos, I think your problem THERE is
    that MIT Kerberos does not support the new credential cache mechanism on
    Big Sur, and basically that error you are getting means "No credentials
    found". I submitted a pullup request to add support for that, and it
    is here:

    https://github.com/krb5/krb5/pull/1221

    If you apply that patch to MIT Kerberos, it might work better for you.

    --Ken

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Markus Moeller@21:1/5 to Ken Hornstein on Mon Oct 11 19:41:35 2021
    Thank you for the information and the patch. I will try do some more
    testing then.

    Kind Regards
    Markus

    "Ken Hornstein" wrote in message news:mailman.0.1633957533.27705.kerberos@mit.edu...

    It is

    #sw_vers
    ProductName: macOS
    ProductVersion: 11.6
    BuildVersion: 20G165

    Alright, so, Big Sur.

    There were significant changes in the credential cache support on Big Sur.
    I didn't check for file cache support, but .... it looks like to me that
    in fact Kerberos on Big Sur _does_ respect the KRB5CCNAME enviroment
    variable:

    % env KRB5CCNAME=FILE:/tmp/foo klist
    Credentials cache: FILE:/tmp/foo
    Principal: kenh@CMF.NRL.NAVY.MIL
    [...]

    Now it may be that gss_init_sec_context() may be doing something slightly
    more magical. If that is the case ... well, I'm not sure there is an
    easy fix for that.

    You can share API credential caches; previously to Big Sur it used Mach
    Ports
    for the IPC mechanism, and that was based on the Unix userid for access.
    With the new mechanism, I am not sure how that works, exactly. Specifically
    I do not know whether or not you can access one set of credentials from
    another login session.

    Regarding your problem with MIT Kerberos, I think your problem THERE is
    that MIT Kerberos does not support the new credential cache mechanism on
    Big Sur, and basically that error you are getting means "No credentials
    found". I submitted a pullup request to add support for that, and it
    is here:

    https://github.com/krb5/krb5/pull/1221

    If you apply that patch to MIT Kerberos, it might work better for you.

    --Ken

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)