Samba PDC/BDC

klussier at comcast.net klussier at comcast.net
Mon Jan 16 12:45:01 EST 2006


 -------------- Original message ----------------------
From: Paul Lussier <p.lussier at comcast.net>
> klussier at comcast.net writes:

> 
> You seem to think there's a separation of components here.  Not so.
> Setting Samba up to use LDAP means to authenticate against LDAP.
> Therfore, your LDAP configuration plays an extremely important part in
> your Samba configuration, since it becomes the authenticating agent
> for the clients.  Your samba server is going to hand off all
> authentication and authorization requests from the client to the LDAP
> server!

There is (or at least, can be) a separation of componants. The Windows Client authenticates to the Samba server. It knows nothing about the LDAP server. It is merely talking to the PDC for "DomainName". The Samba server is configured to authenticate against a given point in the LDAP directory (i.e.  ldap user suffix = ou=foo,ou=corp or ou=bar,ou=corp or ou=*,ou=corp). So, while the Windows clients are talking to what they view as a PDC of "DomainName", the samba server is checking the credentials against ou=foo,ou=corp,dc=comapny,dc=com or, if the location is different, ou=bar,ou=corp,dc=comapny,dc=com, or whatever search subtree it has. The "Windows Domain" remains the same, as it is a netbios name, but the place in the LDAP tree is different depending on the smb.conf. 
 
> > My question, however, was on the "Windows Domain". Can I have the
> > same Windows Domain in both places (regardless of where they
> > actually authenticate).
> 
> A member of a Windows Domain authenticates against it's Domain
> Controller.  Hence, my answer to set it up hierarchically using LDAP.
> LDAP becomes you're authenticating agent in your scheme, since there
> is no "DC" per se, just a Samba server configured to hand off requests
> to an LDAP server.  Have local DCs which authenticate users configured
> such that either DC will allow users from both "domains" to access
> everything via LDAP.
> 
> > 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.

> > I read it. It was a while back, but it's a good book.
> 
> Read it again.

I suggest you read up on how Windows actually does things (I don't actually suggest this, as it is fairly insane how Windows does some things :-). Providing a backend does no good if the clients won't use it. I'm not saying that Windows does things correctly (as it is quite obvious that it is completely broken behavior, IMO). LDAP is the backend to Samba. Samba is the authentication point to the Windows clients. 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...). 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.
 
> > You should read the Paranoid Penguin in LJ. They explain how to pull
> > the Windows systems into single sign-on environment.
> 
> I did, they don't, you can't.

I haven't read part 3 yet (just came in last friday..). I was left with the impression that there was a way to do it. 
 
> Yep, MIT Kerberos for Windows works great.  Still doesn't get you
> single sign-on.
> 
> By the way, my definition of single sign-on is rather strict.  Not
> only must the user be able to use the same username and passphrase
> everywhere, but I as the administrator must have only and exactly *1*
> location in which to manage *everything*.  This is not possible today
> in a heterogeneous environment which includes products from Microsoft.

Your definition isn't "strict", it is just incorrect. How and where you manage things has absolutely nothing to do with single sing-on. SSO 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. 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. 

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

C-Ya,
Kenny



More information about the gnhlug-discuss mailing list