[Samba] password server is not connected

[Andrew Bartlett]

On Wed, 2003-01-29 at 14:13, David Bear wrote:
> bringing the discussion back online -- thanks jerry for the responses.
> please see below..
> 
> On Tue, Jan 28, 2003 at 10:56:24AM -0600, Gerald (Jerry) Carter wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > On Mon, 27 Jan 2003, David Bear wrote:
> > > thanks for the reply.  I was not aware that I could use
> > > password server = somewindowserver
> > > with security = domain
> > Yup.  In fact, in Samba 3.0 you can use 
> > 	password server = DC1 DC2 *
> > which will fail over to autolookups if DC1 and DC2 are unavailable.
> > 
> > > I would like to be able to use domain security.  That buys me domain
> > > functionality with machine trusts.  However, I DO NOT control the NT
> > > domain that we authenticated users against.  So, my domain controller
> > > would be in the position of 1) storing and authenticating MACHINE
> > > accounts in its OWN smbpasswd file and 2) authentication users against a
> > > different smb server (in this case a windows active directory) which I
> > > do not control.
> > 
> > You have a Samba PDC that is authenticating against a Windows NT PDC?
> > No.  This would not be a good configuration.  Why do you need Samba as a 
> > PDC in this case?
> > 
> Actually this is a very valid scenario for us.  We have central IT
> that provided AD and kerberos authentication services.  However, they
> do not create administrative principal/identities for us.  They only
> create user accounts.  (and they manage all the links for password
> updates)  This leaves us with a very powerfull service but powerless.
> 
> Now I could bring up a windows AD and become an OU in the grand
> unified microsoft directory.  But that has side effect that I don't
> want -- ie I don't want to rely on microsoft for something as
> important as directory service.
> 
> What I prefer is to use  CENTRAL account managment services for
> authenticating the unwashed masses.  Then I want to create my own set
> of administrative principals that are authenticated against my own
> authentication servers (smbpasswd is fine now, but LDAP/kerberos is
> what I think the futurer holds)  
> 
> Then, we create our own domain controllers to manage user profiles --
> and handle or OWN adminstrative identites (ergo we retain complete
> control of administrative accounts rather than relegate them to AD and
> have the possibility of an AD hack steal admin accounts).  
> 
> This would be similar to an old style trust relationship betwen NT
> domains.  For large organizations even mickeysoft recommended have
> resource domains and user account domains.  If SAMBA could implement
> this, then the trust would be a 'limited' trust -- very enticing?
> That trust of course limited to just authenticating users (and those
> users priviledge would further be contolled through our own group
> schema) and then not all users.
> 
> Some may think this a strange request, but in a large university like
> ours, there is such decentralization that it makes sense.
> 
> To recap, what I want is something like
> 
> security = domain
> password server = somesmbserver
> 
> without having to join the samba box to the domain

This just isn't possible - or stable.  security=domain *requires* the
domain join, and security=server is slow, unstable (the conn can be
dropped) and is really a bad idea.

> AND
> retain machine trust accounts on my samba box as well as additional
> administrative identities that could be used to manage machines in my
> domain..
> AND
> be able to have additional samba servers join my domain as member
> servers and use a transitive relationship to authenticate users against
> my samba server which then authenticates to microsoft AD.
> 
> My guess is this shouldn't be too hard to implement.  I'm no C
> programmer though -- and this is way out of my league.

Sounds like you want an NT4-style domain trust to the AD server. 
Indeed, I don't see why we can't even have a Win2k domain membership
with that server.

We need to do a little more work to winbindd, then it should 'just
work'.  

The main thing we need to do is stop Samba 'locking up' when winbind is
running, and referenced by nsswtich on the PDC.  This occurs because
winbind sends SAMR requests to localhost, which makes nsswtich calls,
which can trigger the nss libs to talk to winbind again.

After that, we just have a few little details to sort out, like putting
the domain trust passwords into the PDB (allowing them to be shared via
LDAP).

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20030129/3743813b/attachment.bin