Samba PDC/BDC

[Paul Lussier]

Ben Scott <dragonhawk at gmail.com> writes:

>   Well, like I said, the NTLM clients aren't really aware of LDAP. 
> It's NTLM all the way to the NTLM PDC at the main office.  What
> happens at that point is up to Samba.  So LDAP replication doesn't get
> involved (in this part).

I was approaching it from the context that the Samba configuration was
essentially taken care of, and all the magic that had to be done was
being handed off to LDAP by the Samba server.  So you're right, the
client side is completetly unaware of the LDAP configuration, that's
all handled by Samba.

>   Now, since we're on the subject, and you seem to know LDAP pretty
> well, I've got a question: Assume the Samba PDC at the main office
> passes the password change (or whatever) on to LDAP at the main
> office, and that all succeeds and everything.  How does the LDAP
> server at the remote site know that the LDAP database at the home site
> has been updated?  Does the main office LDAP server notify the remote
> office LDAP server somehow?  And if not, will that lead to problems
> because the Samba PDC at the main office and the Samba BDC in the
> remote office have different views of the world?

Well, at least with OpenLDAP, it's a push technology just like NIS or
DNS. If you update the main LDAP server, the only way for slaves to
know about that change is for the master server to push those changes
out to them.  With OpenLDAP this is done with slurpd.  On your master
server, slapd is the LDAP daemon which logs every transaction to a
log, much like a log-based file system.  slurpd is, for all intents
and purposes a "tail -f slapd.log | grep 'mod|add|del' | ldapnotify
slapd-slave" process.  IOW, slurpd watches the replication log slapd
is writing to.  When it notices a change in the database, it notes
that change and sends it to the slave server, which updates it's
records. 

From: http://www.openldap.org/doc/admin23/replication.html

Sample replication scenario:
   1. The LDAP client submits an LDAP modify operation to the slave slapd.

   2. The slave slapd returns a referral to the LDAP client
      referring the client to the master slapd.

   3. The LDAP client submits the LDAP modify operation to the master slapd.

   4. The master slapd performs the modify operation, writes out
      the change to its replication log file and returns a
      success code to the client.

   5. The slurpd process notices that a new entry has been
      appended to the replication log file, reads the replication
      log entry, and sends the change to the slave slapd via
      LDAP.

   6. The slave slapd performs the modify operation and returns a
      success code to the slurpd process.

>   Well, you were going on about LDAP contexts and stuff, but you never
> actually mentioned that each LDAP context would have to equal a
> different NTLM domain.

As I said, I was making assumptions that some things were self-evident :)

>  Given that Kenny was asking about using a single NTLM domain, that
> confused me.  (And I think everyone else was already confused.  (Or
> more likely, had lost interest. :) ))

He confused me with all the talk about the AD domains... It seemed
that he was saying "I want to replace an AD server with Samba and
LDAP", which I took to mean that he a) thought that could be done, and
b) wanted to retain whatever benefits over an NTLM domain AD offers.

I hereby resign from this thread, now that we've all determined to be
in violent agreement and confusion with each other.

-- 

Seeya,
Paul "We're all on the same page, their just in different languages"