[Freeipa-devel] Notes on server to server sasl

[Rich Megginson]

Simo Sorce wrote:
> On Mon, 2008-10-20 at 10:53 -0600, Rich Megginson wrote:
>   
>> 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
>>     
>
> The script failed to create it ?
>
>   
>>> 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 think you have a couple of ways.
>
> 1. if the connections are long lived you could decide to always acquire
> a new TGT before try to establish a connection.
>   
I decided to take this approach.  The connections are relatively long 
lived and infrequently acquired.
> 2. if connections are frequent, you might decide to check before a
> connection if credentials are still valid and renew if not.
>   
Is there a way to do this without actually attempting to authenticate?  
I've tried the validation functions, but I get an error from the KDC to 
the effect of "validation is not permitted".
> 3. You have another task running periodically that refreshes
> credentials.
>
> Simo.
>
>