[Samba] LDAP Master/Slave

[Michael Gasch]

 > This belongs to the fact that a bdc is read only.
 > This is my understanding....and practised...or do you now something
 > other workaround?

this is also my understandig
a solution could be the (experimental) multimaster patch for openldap

but it's not recommended on productive systems

greez

rruegner schrieb:
> Hi John,
> let me explain....if you have conected smb ldap master pdc with
> a vpn ( ie. Openvpn ) to a bdc smb ldap slave and if the vpn
> brakes , win clients from the vpn network are working with
> the last entries from the slave ldap.
> As in the blackout period the pdc isnt exist and the bdc ldap slave is 
> not writeable , you cant make any changes ( like bringing up new 
> machines on the fly, chnage passwords etc )until the vpn is up again to 
> the pdc ldap master.
> This belongs to the fact that a bdc is read only.
> This is my understanding....and practised...or do you now something
> other workaround? ( which might be possible with ldap in principal, but 
> will end in heavly syncing the ldap directory in network blackout periods )
> Best Regards
> 
> 
> 
> John H Terpstra schrieb:
> 
>> On Wednesday 18 August 2004 16:11, rruegner wrote:
>>
>>> thats right
>>
>>
>>
>> I am not sure if I understand what is being said here. Samba should 
>> refer password changes to the PDC and it should apply the changes to 
>> the LDAP directory.
>>
>> - John T.
>>
>>
>>> regards
>>>
>>> Jason C. Waters schrieb:
>>>
>>>> I don't think this is a solution.  If I understand what you were 
>>>> saying,
>>>> on the BDC I should have this as the passwd backend:
>>>>
>>>> passwd backend = ldapsam:"ldaps://ldap.server2 ldaps://ldap.server1"
>>>>
>>>> server2 - the BDC and ldap slave which is read only
>>>> server1 - is the PDB and has the ldap master which users can 
>>>> read/write,
>>>> so they could update their passwords.
>>>>
>>>> If I have it setup this way, the users that on the other side will 
>>>> never
>>>> be able to update their passwords, at least on that leg of the VPN.  Or
>>>> maybe I just thinking about this the wrong way.
>>>>
>>>> Jason
>>>>
>>>> rruegner wrote:
>>>>
>>>>> Hi,
>>>>> if you want to stay bdc stay alive, in cases
>>>>> when vpn broke so on your bdc smb.conf
>>>>> your slave ldap should be the first entry in the passwd backend,
>>>>> so if vpn brake , the slave ldap operates with its last
>>>>> entries from the master and will give the win clients any chance
>>>>> to operate just like if the pdc is alive.
>>>>> If vpn is up again it the ldap should refresh the slave automatic.
>>>>> But note, a bdc is read only so changes can olny be made to the master
>>>>> ldap on the pdc.So no changes can be made to the domain during the
>>>>> blackout period.
>>>>> If you want a full functional bdc you also should setup user clients
>>>>> homes and profiles in your outside ( vpn ) office hosted on the bdc.
>>>>> ( a seperate dhcp server and an bind slave with longtime zone caching
>>>>> is very usefull, too )
>>>>>
>>>>> Regards
>>>>>
>>>>> Jason C. Waters schrieb:
>>>>>
>>>>>> Is anyone using this?  My smb.conf file has this line in
>>>>>> server1(master)
>>>>>>
>>>>>> passwd backend = ldapsam:"ldaps://ldap.server1 ldaps://ldap.server2"
>>>>>>
>>>>>> and this is what server2(slave ldap, BDC) looks like:
>>>>>>
>>>>>> passwd backend = ldapsam:"ldaps://ldap.server1 ldap.server2"
>>>>>>
>>>>>> This is what happens.  When I take down server 1's ldap server,
>>>>>> server2 just starts using its local ldap server.  But if I take down
>>>>>> the VPN between the two, I try the same test, pdbedit -L, it works
>>>>>> but it take about 6 seconds for it to timeout on server1.  Is this
>>>>>> normal or do I need to change some DNS setting?  Thanks for your 
>>>>>> help.
>>>>>>
>>>>>> Jason
>>
>>
>>

-- 


          "Matrix - more than a vision"

**************************************************
                  Michael Gasch

            - Central IT Department -

Max Planck Institute for Evolutionary Anthropology
Deutscher Platz 6
04103 Leipzig

Germany
**************************************************