Problem with libkadm5clnt.so after upgrade to 1.4.1

Tom Yu tlyu at MIT.EDU
Tue Aug 9 22:12:54 EDT 2005


>>>>> "admin" == Utente amministrativo <admin at bella.dei.unipd.it> 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 at 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


More information about the Kerberos mailing list