Samba PDC/BDC

[Paul Lussier]

klussier at comcast.net writes:

>> > The reason for this is that people will travel between here and
>> > there quite often,
>>  Yeah, so.  Just set the ACLs up to allow anyone in 'ou=*, ou=corp,
>> dc=foo, dc=com' access to whatever you want everyone to access.
>
> This is completely ineffectualy, since they will not be able to find
> their domain controller when they are on the other network. If there
> laptop is configured to look for the PDC for "HERE" and the only thing
> that they find is the PDC for "THERE", then Windows will not attempt
> to authenticate.  Hence, having the same netbios domain name in both
> places. The LDAP ACL's can be set to allow anyone to connect to
> anything, but that doesn't help if the clients won't talk to the Samba
> server in the first place.

You're lacking some ingenuity here.  Every Samba server is the PDC for
it's local physical network, and a BDC for the remote network.
Therefore, though HERE can't directly talk to the PDC for HERE when
it's THERE.  It can access the BDC for HERE, which *is* THERE.

Who's on first again?

> Providing a backend does no good if the clients won't use it.

The clients don't use it directly, Samba uses it.  Without it, none of
this will work.

> If the Windows client can't find it's authentication point,
> it creates a temprary profile on the system to allow login and
> deletes the profile when the user logs off (I hate myself for
> knowing this...).

So, you *also* want roaming profiles? (This is part of Windows I don't
know too much about.  However, I have read that roaming profiles is
usually a bad idea.)  My (albeit limited) understanding of roaming
profiles is that they're stored on the DC, no?  If so, then wouldn't
make it rather irrellevent whether you have one or two domains, since
the profile is probably best served from a local system?  If this is
the case, then it would actually seem that 2 domains would be easier
to deal with, since the only time a user experienced a slow log in
time would be when at the other location and needing to download their
profile (perhaps this is why I've read roaming profiles are bad?)

As an aside, this sounds amazingly like having an NFS-based home
directory and trying to NFS mount it across a T1 from 3000 miles away!
Let me tell you, udp-based NFS over a T1 is *really* slow! :)

> Your solution creates two Windows domains. A windows system can only
> be a member of one domain at any given time (who ever thought that
> that was a good idea should be shot).  Therefore, a user would have
> to log into the local administrator account on the laptop, change
> the Windows Domain, reboot, then log in. That defeats the intention
> of unifying the Windows domain.

Or, it makes things more manageable, since you have a BDC in each
location.
  
> Your definition isn't "strict", it is just incorrect.

No it's not, it's more strict than the normal definition, which is:

> the act of providing a single username/password (or whatever the
> credentials method is) once for access to anything during any given
> logon session.

> How and where you manage things has absolutely nothing to do with
> single sing-on.

Sure it does.  If I provide a single usernme/password to someone for
access to "everything", and I then have to update several different
authentication devices (i.e. AD, Kerberos, and hand-full of htpasswd
files, a VPN system, etc.) then I don't really have single-signon,
what I have is a hodge-podge of systems which all occassionally have
the same settings, but *could* at any given time be completely out of
sync with each other.

My definition guarantees that since there is a single location for the
management of the accounts, then the username and password will always
be correct and never be out of sync.

> Once a set of credentials has been provided by the user, access to
> other things (be that a system, an application, or whatever) is
> handled in the background without the user needing to provide said
> credentials again.

Then, by this definition, you *need* a single management location,
since, if you have a single username and password which access
multiple, disjointed systems, these systems all need a central
location to authenticate against.

> However, I am not trying to provide SSO. I am simply trying to provide
> a unified password infrastructure that can be centrally managed.

Which is essentially the beginnings of an SSO infrastructure, and, by
(my) definition, building an SSO infrastructure gets you exactly what
you want :)

-- 

Seeya,
Paul