Problem with libkadm5clnt.so after upgrade to 1.4.1

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

Problem with libkadm5clnt.so after upgrade to 1.4.1

Utente amministrativo
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


-- [hidden email]
--
-
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Problem with libkadm5clnt.so after upgrade to 1.4.1

Tom Yu
>>>>> "admin" == Utente amministrativo <[hidden email]> 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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Problem with libkadm5clnt.so after upgrade to 1.4.1

Utente amministrativo-2
Hi

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

> >>>>> "admin" == Utente amministrativo <[hidden email]> 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

--
--
-- [hidden email]
--
-
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Problem with libkadm5clnt.so after upgrade to 1.4.1

Tom Yu
>>>>> "admin" == Utente amministrativo <[hidden email]> 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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos