Samba PDC/BDC

[Paul Lussier]

klussier at comcast.net writes:

> Hi All,
>
> I am in the process of replacing a Windows AD Domain controller with
> Samba and LDAP. I have another office elsewhere in the world that is
> connected via an IPSEC VPN. I want to create a secondary Samba/LDAP
> server in that office so that they can authenticate against a local
> server rather then having to traverse the VPN tunnel several
> times. Replicating LDAP is pretty easy using slurpd and maintains
> the centralized management model that I am trying to build (create a
> user here, and they can log in over there). My question is more on
> the Samba side of things. Can I build the Samba server over there as
> a BDC like in the old days when there was a concept of a PDC and a
> BDC? Can I still have both Samba servers act as a domain controller
> for the same Windows domain? I haven't displaced Active Directory
> before, so what pitfalls should I be aware of? Is there anything
> non-obvious to setting up the same domain in two places?

I wouldn't do it quite like that.  I would set up a multi-tiered
environment.  Have a "corporate" PDC/LDAP/SAMBA controller which does
not much more than deal with replication.  Then have 2 secondary
servers which are local to each network.  Have these be sub-domains of
the corporate.

For example:                   ou=corp, dc=foo, dc=com
                                      /        \
       ou=here, ou=corp, dc=foo, dc=com        ou=there,ou=corp,dc=foo,dc=com

You can then easily set acls within LDAP and Samba as to who from
which location is allowed where. The easy default to allow everyone
access to everything is then ou=corp, dc=foo, dc=com.  You can further
the hierarchy as it makes sense into things like:

  ou=groups, ou=[t]here, ou=corp, dc=foo, dc=com
  ou=finance, ou=groups, ou=[t]here, ou=corp, dc=foo, dc=com
  ou=software, ou=groups, ou=[t]here, ou=corp, dc=foo, dc=com
  ou=hardware, ou=groups, ou=[t]here, ou=corp, dc=foo, dc=com

etc.  I would recommend reading the O'Reilly book on LDAP, it gives a
decent overview of this type of thing, as do the articles in LJ last
year on LDAP Everywhere (actually, these articles were very good on
the design architecture considerations, but light on the
implementation details, but the O'Reilly book makes up for that.)

LJ has also had a somewhat decent series of articles lately on LDAP,
Samba, and Kerberos. The O'Reilly Kerberos book is a pretty decent
gentle introduction to Kerberos, but the manuals from MIT are far
better for actuall configuration, installation, and administration
info.

While I haven't ever deployed Samba and LDAP together, I've done quite
a bit of reading on the subject.  What I've read so far is that
authentication is the real tough part and very difficult to implement
properly.  Ideally, what you'd like to do is have your name service be
LDAP, but your authentication be Kerberos.  Unfortunately, unless you
use Active Directory, Windows is completely incapable of retrieving ns
info from one location and authenticating somewhere else.  Samba is
also the week point here, since Samba isn't currently capable of
authenticating against Kerberos on behalf of the client.  In order to
do so, you'd need to have the client send passwords over the wire in
cleartext.  Ideally, Samba and Windows would be able to connect to
each other over an SSL/TLS connection, but don't believe that's
possible either.  So, what you're left with is probably a Rube
Goldberg option of using IPSec and configuring windows to use that in
order to securely send it's passwords in cleartext to the Samba
server, which could then authenticate against Kerberos.

Or, you could store all passwords in LDAP, which I believe is
possible, but not overly desirable from a security perspective.

The real solution is to ditch anything related to Windows, and use
AFS, Kerberos, and LDAP (Macs can handle this just fine, as can every
Linux or BSD variant that I know of :)
         


-- 

Seeya,
Paul