[Freeipa-devel] Notes on server to server sasl

[Rich Megginson]

Simo Sorce wrote:
> On Fri, 2008-10-17 at 17:15 -0600, Rich Megginson wrote:
>   
>> I'm using the current HEAD code.  My master is F9 x86_64 and my replica 
>> is F8 i386.  For the most part, the setup documented here 
>> http://freeipa.org/page/InstallAndDeploy works pretty well.
>>
>> Setup
>> 1) I'm not using DNS, just testing with VMs, so I had to make sure my 
>> VMs were assigned a consistent IP address via dhcp - and edit /etc/hosts 
>> to use the fqdn
>> 2) I did not assign a hostname at install time, so I had to edit 
>> /etc/sysconfig/network to assign the hostname and reboot - probably 
>> could have done that with dhcp too (anyone know how?)
>> 3) I had to edit the firewall settings to allow 389 and 636 tcp (and udp 
>> for good measure) on both the master and replica
>> 4) I added the --no-host-dns option to ipa-server-install, but I'll need 
>> to add that to several other ipa- cmd line tools as well - I just hacked 
>> them instead to pass in verify_fqdn(name, True)
>>
>> Notes
>> 1) ipa-replica-install did not add a replication agreement from the 
>> replica to the master, but it configured the replica as a master (for 
>> MMR) - is this expected?
>>     
>
> Yes they are all masters in freeipa-land so far.
>   
I did this again after fixing some problems - still no replication 
agreement from replica->master
>   
>> 2) There was no principal for ldap/fqdn.of.replica at REALM - do I have to 
>> add this manually?
>>     
>
> It should be under cn=kerberos, if you manually add another one in
> cn=services I guess all you get is a broken system.
> At the  very least you reset the secret and /etc/dirsrv/ds.keytab gets
> out of sync.
>   
Ok.  I fixed my problem - now all the principals are there.
>   
>>   I did anyway and it made kerberos happier (but not 
>> work) with replication, but it seemed to break lots of stuff on the 
>> replica (could no longer ldapsearch -Y GSSAPI on the replica, could not 
>> ipa-finduser on the replica)
>>     
>
> You broke it indeed.
>   
Yep, now fixed.
>   
>> * Server to Server SASL/GSSAPI
>> I modified Fedora DS to do SASL/GSSAPI bind for replication from the 
>> master to the replica.  I then had to modify /etc/sysconfig/dirsrv to do 
>> the following:
>> kinit -k -t /etc/dirsrv/ds.keytab ldap/fqdn.of.master at REALM
>> parse klist to get the tgt filename
>> export KRB5CCNAME=tgtfilename
>> chown dirsrv:dirsrv $KRB5CCNAME
>>     
>
> This will not work, you need to teach dirsrv how to do these operations
> itself, and how to handle renewals when the TGT expires. Otherwise you
> just get a hackish thing that works a few hours and then breaks.
>   
Sure.  I'll note that this is how openldap does it for server to server 
sasl - they typically have some sort of script or daemon that renews the 
ticket.

How else should this be done?
>   
>> I then had to add the ldap host principal for ldap/fqdn.of.replica at REALM 
>> (not sure why it wasn't there?).  After startup, the master attempts to 
>> do a SASL/GSSAPI bind to the replica, and gets this error in kdc5krb log 
>> on the master:
>> NO PREAUTH: authtime xxxx, ldap/fqdn.of.master at REALM 
>> <mailto:ldap/fqdn.of.master at REALM> for ldap/fqdn.of.replica at REALM 
>> <mailto:ldap/fqdn.of.replica at REALM>, Generic error (see e-text)
>>     
>
> I think this is related to the above explanation.
>
>   
>> Is what I'm trying to do possible within the IPA kerberos framework?
>>     
>
> Yes.
>
> Simo.
>
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3258 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20081020/de8b76c0/attachment.bin>