OK - I'm actually functioning but I'm afraid and I want to fill in a knowledge gap - perhaps a slight gap in the How-To Book or my ability to soak in its' wisdom. LDAP up and working on two machines, master & slave and changes made in master can be found by ldapsearch on slave faster than two up arrows and a return (gosh, it only took me 10 days but the light bulb has definitely lit). Two Linux systems PDC - Linux2 - also is LDAP master BDC - Linux1 - also is LDAP slave smbpasswd -w PASSWORD puts binddn password into secrets.tdb Machine is added to domain, no problem right, because PDC fields this whereas BDC handles most of logon chores. What if PDC/LDAP is offline? Doesn't Machine Add then get added to slave LDAP? How about if user changes his password? Do I really want the secrets.tdb to have rootdn PASSWORD? Shouldn't this be a non-rootdn in the BDC's smb.conf with only sufficient access to see sambaNTPassword & sambaLMPassword with read only and no write privileges to anything? I.E. PDC down, no password changes, no new machine accounts. Craig
-----Original Message----- <snip> Machine is added to domain, no problem right, because PDC fields this whereas BDC handles most of logon chores. What if PDC/LDAP is offline? Doesn't Machine Add then get added to slave LDAP? How about if user changes his password? Do I really want the secrets.tdb to have rootdn PASSWORD? Shouldn't this be a non-rootdn in the BDC's smb.conf with only sufficient access to see sambaNTPassword & sambaLMPassword with read only and no write privileges to anything? I.E. PDC down, no password changes, no new machine accounts. Craig Craig, Usually, it's recommended you set the binddn to something other than root, but with priviledges that can modify anything needed (even on the PDC). In a BDC situation, that user canNOT have access to modify anything (and will be required to be set as the updatedn in the slapd.conf anyways, if it's a replication slave). Cheers, Clint