On 01/26/2011 09:32 AM, James Roman wrote:
Simo Sorce wrote:
On Tue, 25 Jan 2011 15:58:35 -0500
James Roman<james.ro...@ssaihq.com>  wrote:

On 1/25/11 2:44 PM, Simo Sorce wrote:
On Tue, 25 Jan 2011 14:33:14 -0500
James Roman<james.ro...@ssaihq.com>   wrote:

On 01/25/2011 12:42 PM, Simo Sorce wrote:
On Tue, 25 Jan 2011 12:04:25 -0500
James Roman<james.ro...@ssaihq.com>    wrote:

I noticed today that one of our FreeIPA 1.2.2 servers has stopped
issuing tickets. When I attempt to restart all the IPA services
the krb5kdc service failed to restart with the following error:

krb5kdc: Unable to access Kerberos database - while initializing
database for realm DOMAIN.COM

I don't see any issues with the local LDAP database, or the kdc
account in the LDAP database. I suspect the problem is with the
ticket granting ticket on the problem server, but am unsure how
to go about validating this assertion. I have not tried to
restart the ipa services on the working server for fera that it
might stop working.
Do you see errors in /var/log/krb5kdc.log ?


The error above is the only one that repeats in the krb5kdc.log
when I attempt to restart the krb5kdc service. The actual error
that is shown in standard out is:

Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm
- see log file for details
Ok can you check the dirsrv logs and see if the KDC is actually
trying (and perhaps getting auth refused) at all ?

/var/log/dirsrv/slapd-DOMAIN-COM/access should show your KDC
attempts to access the LDAP server and bind as the uid=kdc.....


Looks like an authentication failure:

[25/Jan/2011:15:11:29 -0500] conn=391 op=0 BIND
dn="uid=kdc,cn=sysaccounts,cn=etc,dc=domain,dc=com" method=128
version=3 [25/Jan/2011:15:11:29 -0500] conn=391 op=0 RESULT err=49
tag=97 nentries=0 etime=0
[25/Jan/2011:15:11:29 -0500] conn=391 op=-1 fd=73 closed - B1

The ldappwd file on both systems look identical. I don't think that
the SSL certificate comes into the equation, but I have no way of
knowing whether it initiates TLS or not.

No in ipa 1.2.x the kdc is configured to use ldap:// with no

I wonder if your local DS is having problems.

Can you change krb5.conf to point to the other server (maybe using
ldaps:// so as to not expose the password in the clear) and see if the
krb5kdc will start that way ?

Don't use this in production, just as a test to identify where the
problem lies.

if it turns out it is the local DS that is having issues, then we can
try to force sync it again.

Ah btw, on what distribution version is this? what 389-ds base version
are you using ?


So if I switch the kdc.conf to point to the other FreeIPA ldap server the krb5kdc service starts up without any problems. I was just about to force a sync when I noticed this in the error log on the working ldap server (lets call it ipserver2):

[17/Jan/2011:10:24:33 -0500] NSMMReplicationPlugin - agmt="cn=meToipaserver1.domain.com636" (ipaserver1:636): Succesfully bound cn=replication manager,cn=config to consumer, but password has expired on consumer.

This is the earliest record I have on the ldap replica without going to tape. So it appears that the replica password has expired. So I have this problem. ipaserver1 is used as my winsync server, but I can not use it to start krb5kdc. ipaserver2 has a working ldap server, but is not synchronizing with the winsync master. If I fix the password expiration issue, is it going to break ipaserver2?\
See here for information about how to make the repl manager password not expire - http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Creating_the_Supplier_Bind_DN_Entry

if you fix the password expiration issue, it should not break anything

Freeipa-users mailing list

Freeipa-users mailing list

Reply via email to