Problem with libkadm5clnt.so after upgrade to 1.4.1 - Kerberos

This is a discussion on Problem with libkadm5clnt.so after upgrade to 1.4.1 - Kerberos ; Hello we use LDAP+KERBEROS and after upgrading from 1.4 to 1.4.1 my scripts for users creation/change don't work anymore. They are based on 'kadmin' utility or perl module Authen::Krb5::Admin for remote management on the kerberos and LDAP db. As user/admin@REALM ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Problem with libkadm5clnt.so after upgrade to 1.4.1

  1. Problem with libkadm5clnt.so after upgrade to 1.4.1

    Hello
    we use LDAP+KERBEROS and after upgrading from 1.4 to 1.4.1
    my scripts for users creation/change don't work anymore.
    They are based on 'kadmin' utility or perl module Authen::Krb5::Admin
    for remote management on the kerberos and LDAP db.
    As user/admin@REALM I am used to do only
    'kinit user/admin@REALM'
    to grant me LDAP and KERBEROS admin access.
    All scripts then use the KRB5CCNAME file.
    Symptoms are that 'kadmin -c $KRB5CCNAME -q ...' or Authen::Krb5::Admin->init_with_creds
    refuse to try to use existing krbtgt/REALM@REALM to get the mandatory
    kadmin/krbserver.domain@REALM service ticket.
    If I do a 'kinit -s kadmin/admin user/admin' it works but
    then I can't use that service ticket to access LDAP.
    Replacing libkadm5clnt.so with previuos 1.4 version fixes it
    and after a run of init_with_creds my cache file correctly contains:
    08/02/05 12:56:20 08/03/05 12:56:20 krbtgt/REALM@REALM
    08/02/05 12:56:28 08/03/05 12:56:20 kadmin/krbserver.domain@REALM
    08/02/05 12:56:28 08/03/05 12:56:20 ldap/krbserver.domain@REALM

    Sources' Changelog file helps me to concentrate on
    krb5-1.4.1/src/lib/kadm5/clnt/client_init.c
    After some deep investigation with DDD (you know, it's summertime
    and sysadmin have a lot of sparetime
    seems that the section starting from line 434:
    code = kadm5_gic_iter(handle, init_type, ccache,
    client, pass, svcname, realm,
    full_svcname, full_svcname_len);
    if ((code == KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN
    || code == KRB5_CC_NOTFOUND) && svcname_in == NULL) {
    /* Retry with old host-independent service princpal. */
    code = kadm5_gic_iter(handle, init_type, ccache,
    client, pass,
    KADM5_ADMIN_SERVICE, realm,
    full_svcname, full_svcname_len);
    }

    check only for existing kadmin/fqdn@REALM or (fallback) kadmin/admin@REALM
    and obviously return an error. The embarassing thing is that if I create
    a cache with 1.4 libkadm5clnt.so it is gladly accepted by 1.4.1 libkadm5clnt.so
    I am not a kerberos guru so there could be something wrong
    in my configuration or in my way of understanding Kerberos philosophy.

    Any feedback will be appreciated.

    Regards
    Valerio Pulese


    -- admin@dei.unipd.it
    --
    -
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  2. Re: Problem with libkadm5clnt.so after upgrade to 1.4.1

    >>>>> "admin" == Utente amministrativo writes:

    admin> we use LDAP+KERBEROS and after upgrading from 1.4 to 1.4.1
    admin> my scripts for users creation/change don't work anymore.
    admin> They are based on 'kadmin' utility or perl module Authen::Krb5::Admin
    admin> for remote management on the kerberos and LDAP db.
    admin> As user/admin@REALM I am used to do only
    admin> 'kinit user/admin@REALM'
    admin> to grant me LDAP and KERBEROS admin access.
    admin> All scripts then use the KRB5CCNAME file.
    admin> Symptoms are that 'kadmin -c $KRB5CCNAME -q ...' or Authen::Krb5::Admin->init_with_creds
    admin> refuse to try to use existing krbtgt/REALM@REALM to get the mandatory
    admin> kadmin/krbserver.domain@REALM service ticket.

    Could you please quote the exact error you get?

    admin> If I do a 'kinit -s kadmin/admin user/admin' it works but
    admin> then I can't use that service ticket to access LDAP.

    I believe that using "kinit -s kadmin/admin user/admin" is the only
    way that's documented to work.

    admin> Replacing libkadm5clnt.so with previuos 1.4 version fixes it
    admin> and after a run of init_with_creds my cache file correctly contains:
    admin> 08/02/05 12:56:20 08/03/05 12:56:20 krbtgt/REALM@REALM
    admin> 08/02/05 12:56:28 08/03/05 12:56:20 kadmin/krbserver.domain@REALM
    admin> 08/02/05 12:56:28 08/03/05 12:56:20 ldap/krbserver.domain@REALM

    Your ability to get a kadmin/krbserver.domain@REALM ticket using a TGT
    indicates that your kadmin/krbserver.domain principal doesn't have the
    DISALLOW_TGT_BASED flag set, which should typically be the case for
    kadmin-related principals.

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


  3. Re: Problem with libkadm5clnt.so after upgrade to 1.4.1

    >>>>> "admin" == Utente amministrativo writes:

    admin> On Mon, Aug 08, 2005 at 03:09:37PM -0400, Tom Yu wrote:

    >> Could you please quote the exact error you get?


    admin> "Authenticating as principal user/admin@REALM with existing credentials.
    admin> kadmin: Matching credential not found while initializing kadmin interface"

    Thanks, I'll need to dig around some more to figure out exactly what
    is going on here.

    admin> If I do a 'kinit -s kadmin/admin user/admin' it works but
    admin> then I can't use that service ticket to access LDAP.

    That makes sense, as you won't have a TGT in that case.

    >> I believe that using "kinit -s kadmin/admin user/admin" is the only
    >> way that's documented to work.


    admin> It seems to me that when I connect with LDAP through GSSAPI
    admin> I don't need a ticket for a particular service but only a user/admin
    admin> principal.
    admin> When I am authenticated as user/admin in a REALM it should be enough.
    admin> Policies and ACLs complete the security scheme.
    admin> Correct me if I am wrong but I believe that this is the way
    admin> ticket-granting tickets work.

    Typically, the kadmin/* principals may not be issued via TGT, in order
    to prevent an attacker from walking up to an unattended session and
    changing someone's password, for example. Requiring proof of recent
    knowledge of the users's password adds an additional layer of
    security.

    admin> 'getprinc kadmin/admin' says:
    admin> [...]
    admin> Attributes: DISALLOW_TGT_BASED
    admin> Policy: [none]

    admin> When things started not working I firstly try unsetting
    admin> that flag (after reading krb5 API docs) but it
    admin> didn't fix the problem so I set it again to the default value.

    Note that kadmin/admin is a different principal from
    kadmin/krbserver.domain.

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


  4. Re: Problem with libkadm5clnt.so after upgrade to 1.4.1

    Hi

    On Mon, Aug 08, 2005 at 03:09:37PM -0400, Tom Yu wrote:
    > >>>>> "admin" == Utente amministrativo writes:

    >
    > admin> we use LDAP+KERBEROS and after upgrading from 1.4 to 1.4.1
    > admin> my scripts for users creation/change don't work anymore.
    > admin> They are based on 'kadmin' utility or perl module Authen::Krb5::Admin
    > admin> for remote management on the kerberos and LDAP db.
    > admin> As user/admin@REALM I am used to do only
    > admin> 'kinit user/admin@REALM'
    > admin> to grant me LDAP and KERBEROS admin access.
    > admin> All scripts then use the KRB5CCNAME file.
    > admin> Symptoms are that 'kadmin -c $KRB5CCNAME -q ...' or Authen::Krb5::Admin->init_with_creds
    > admin> refuse to try to use existing krbtgt/REALM@REALM to get the mandatory
    > admin> kadmin/krbserver.domain@REALM service ticket.
    >
    > Could you please quote the exact error you get?


    "Authenticating as principal user/admin@REALM with existing credentials.
    kadmin: Matching credential not found while initializing kadmin interface"

    > admin> If I do a 'kinit -s kadmin/admin user/admin' it works but
    > admin> then I can't use that service ticket to access LDAP.
    >
    > I believe that using "kinit -s kadmin/admin user/admin" is the only
    > way that's documented to work.


    It seems to me that when I connect with LDAP through GSSAPI
    I don't need a ticket for a particular service but only a user/admin
    principal.
    When I am authenticated as user/admin in a REALM it should be enough.
    Policies and ACLs complete the security scheme.
    Correct me if I am wrong but I believe that this is the way
    ticket-granting tickets work.
    However a future workaround would be to store differentservices tickets
    in two separate files:
    one for LDAP and the other for KRB5 managing.

    > admin> Replacing libkadm5clnt.so with previuos 1.4 version fixes it
    > admin> and after a run of init_with_creds my cache file correctly contains:
    > admin> 08/02/05 12:56:20 08/03/05 12:56:20 krbtgt/REALM@REALM
    > admin> 08/02/05 12:56:28 08/03/05 12:56:20 kadmin/krbserver.domain@REALM
    > admin> 08/02/05 12:56:28 08/03/05 12:56:20 ldap/krbserver.domain@REALM
    >
    > Your ability to get a kadmin/krbserver.domain@REALM ticket using a TGT
    > indicates that your kadmin/krbserver.domain principal doesn't have the
    > DISALLOW_TGT_BASED flag set, which should typically be the case for
    > kadmin-related principals.
    >
    > ---Tom


    'getprinc kadmin/admin' says:
    [...]
    Attributes: DISALLOW_TGT_BASED
    Policy: [none]

    When things started not working I firstly try unsetting
    that flag (after reading krb5 API docs) but it
    didn't fix the problem so I set it again to the default value.

    Thanks in advance

    Valerio Pulese

    --
    --
    -- admin@dei.unipd.it
    --
    -
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


+ Reply to Thread