Samba4 AD Replication

· 869 words · 5 minute read
Technology · Conferences
lca2010 · lca · samba · Andrew Bartlett

Andrew Bartlett - 9 Years Samba development.

This talked focused on Samba4’s Domain Controller features, and the moves closer to becoming a first-class AD server with the addition of AD Replication; there were some more general Samba questions at the end. Although unfortunately this talk seemed to bring out a couple of dickish questions from people wanting to fish for the speaker to say bad things about Microsoft.

Replication - users and groups

  • Data in the directory
  • Not Group Policy data
  • Between Domain Controllers
  • Replication of passwords - traditionally the weakness of other solutions.

Why Replication

  • Samba should be safer to deploy, but playing nice with others, instead of all-or-nothing.
  • No-one wants a single point of failure

Before, Samba4 was for greenfield sites, one domain controller, willing to take a hit or cut-and-run.

Cut and Run

  • Vampire AD domain,
  • Shutdown AD domain
  • Start Samba4
  • Hope
  • No way back. Do you want to ask users to remember their pre-migration login details if it doesn’t work out.

As of alpha11 replication has become bidirectional. Samba4 can be disabled without data loss.

Didn’t We Already Have Replication?

  • LDAP wan’t good enough. You can’t have Windows AD already.
  • No transactions for Samba<->Samba replication, either.
  • Still going to be used in FreeIPA.

DRS Replication

  • The native Windows solution.
  • Truly bidirectional and cross-platform (Windows<->Samba<->Samba<->Windows).
  • Not supported with the Windows backend.
  • Initiated by either Samba or Windows.
  • Tested against 2003, 2008, and 2008R2.
  • No relationship with CDB and clustering - tight model, replication is loose.
  • Backend is copied to the TDB (trivial Database) files, and they try to keep LDAP synced, but that won’t continue.
  • Once you’re syncing, you could use Samba to feed everything (including passwords) to LDAP. you could e.g. have a read-only DC with password store enabled and then squirt it out to an LDAP product.
  • Samba will provide an AD-style LDAP natively, and can talk to a different LDAP server.
  • Own KDC, working with Heimdall, Samba deals with PAC and other Microsoft extensions.
  • Embedded a DNS, probably BIND. BIND is being extended to talk to LDAP already as part of RH FreeIPA.
  • There’s a decent amount of documentation on the wire protocol from Microsoft. Noted that post-EU court decision Microsoft have been very good about providing documentation. The enginners the Samba team work with are very enthusiastic.
  • Samba4’s scalability is “improving from a shocking base”. e.g. 1000 user add took forever, but it’s mostly simple bugs/flaws that are being worked through. Mostly focused on thousands of users for the moment.
  • People are developing performance test cases for the team which they are using as a guide to performance problems.

Read Only Domain Controller

  • The next priority.
  • Allows safe incremental deployment.
  • Put it in branch offices or other less-secure sites as a cache.
  • Coming in the next few weeks.

Remaining Risks

  • Access Control - not fully locked down the LDB stack; some controls allow ACL bypass.
  • Samba4 may mislead clients, e.g. clients thinking there’s no group policies.
  • AD doesn’t validate inbound replications on the Windows side, so Samba bugs can corrupt the directory (as could Windows ones, for that matter). As an aside, this gave me the shits. The possibilities to foobar AD forests are mindblowing.
  • Admin tools.
  • Multi-domain forests.
  • Role management.
  • DNS.
  • DRS TODO on the Wiki.

Production Sites

  • Secret Russian Production site. Critical for development, because this is giving lots of feedback from real-world Samba4 AD, but the guys at the site prefer not to become well-known.
  • A few other less-known ones, limited feedback.
  • Real sites are crucial for use cases such as, e.g. password and machine account expiry.

Testing Sites

  • You can’t have version 1.0 so you can lie to your manager about whether it’s safe to stick in.
  • We will not release Samba4 just to get testing. Aside: KDE, take note!
  • You’d need to be comfortable with git, maybe writing patches.

Chit-chat

  • What will be missing from 1.0? Well, there’s a list of what’s in beta. Replication needs to be done. Stability of the database format needs to happen, migration tools needs to happen. Filesystem doesn’t need to be perfect, printing doesn’t need to be there.
  • When it goes to Windows, how do we pitch it? Suggestions include: read-only DCs in branch as accelerators.
  • Testing: Join a Windows box to a DC, move it to a private, disconnect network, then sync Samba4 on the private network to see what happens.
  • Windows 2008 RO compatability layer implementation will be a great boon for testing, because Microsoft will guarantee that an RO DC is safe to use, even if it’s Samba.
  • Samba4 does more validation of AD data than Windows, not least because the internal formats of the Samba4 servers are different from the wire formats (e.g. int -> integerString)
  • Microsoft’s playing nice with publishing data doesn’t extend to collaboration on new protocols and extensions, which are still handed down from over. Samba is “still a receiver”.
  • Samba4 as a file server is not a finished picture yet. The use cases that are there aren’t going away; most of the cool new stuff has been ported to Samba 3. Samba4 does have a CIFS proxy and accelerator that no-one else has.
  • There has been some work on testing Exchange with Samba4.
Share