Rich Megginson wrote:
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 ?

Simo.

          
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
DOMAIN.COM
- 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.....
user.

Simo.

      
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://127.0.0.1 with no
auth.

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 ?

Simo.

  
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
So it looks like the replication password issue was a red herring as far as the kerberos is concerned. I issued the command "ipa-replica-manage synch ipaserver1.domain.com" from the working ldap replica and no longer get password expiration errors in the error logs. However, I still can not get the krb5kdc process on ipaserver1 to start when it uses the local (ldap://127.0.0.1/) LDAP database. If I perform an LDAP search of the kdc account  using the Directory Manager account, both kdc entries are identical, so it does not seem to be the password for the KDC account that is preventing the krb5kdc service from starting. Could it be the service or host principals? Should I init from ipaserver2 -> ipaserver1 (Note: ipaserver1 is the winsync server)?

ipaserver1:
FC 11
ipa-server-1.2.2-2.fc11.i586

ipaserver2:
FC10
ipa-server-1.2.2-1.fc10.i386




_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to