RH 7.0 and Winbind in an NT4.0 domain

[Patrick Spinler]

Question:

Is there an easy way to dump the contents of the secrets database and
see what _is_ there ?

Thanks,
-- Pat

Patrick Spinler wrote:
> 
> Just FYI:
> 
> I am still unable to get a working system, running the latest winbindd
> out of cvs branch APPLIANCE_TNG today.  From the error "winbindd -d100"
> spits at me, I guess that it's a domain trust issue (since my
> workstation is in one domain 'RCHWKS', and my test domain id is in a
> second domain 'MC', which 'RCHWKS' trusts).  It's only a wild ass guess,
> though.
> 
> (winbind log info here from a pam login attempt here)
>   adding trusted domain MC
>   adding trusted domain RCH
>   server: dc=RWKSRV00, pwdb_init=1, lsa_hnd=1
>   RCH: dc=, got_sid=0, sam_hnd=0 sam_dom_hnd=0
>   MC: dc=, got_sid=0, sam_hnd=0 sam_dom_hnd=0
>   RCHWKS: dc=, got_sid=0, sam_hnd=0 sam_dom_hnd=0
>   accepted socket 10
>   [ 1220]: pam auth mc/pjs11
>   could not get trust password for domain MC
> 
> I can see some intregeing stuff with the wbinfo command, but getent
> passwd (or group) shows nothing beyond my local passwd/group database.
> 
> I just did a little tracing through the code.  The "could not get trust
> account password" error is being generated because the trust password is
> not in the secrets database
> 
>  nsswitch/winbindd_misc.c:_get_trust_account_passwd()
>    calling
>    secrets/secrets.c:secrets_fetch()
> 
> but I'm unclear where in the code path, if anywhere, the domain trust
> account is supposed to be obtained and stored in the secrets database.
> 
> More investigation as time permits.  If anyone has any clues, please
> help.
> 
> -- Pat
> 
> Shaun Cloherty wrote:
> >
> > Patrick Spinler wrote:
> >
> > > Shaun:
> > >
> > > I'm trying to get a very similar configuration working (rh 6.2 instead
> > > of 7.0, though).
> > >
> > > First, it sounds like you may have a basic samba configuration issue.
> > > smbd and nmbd not starting is the first thing I'd look into.  Do you
> > > have samba installed where the init.d/smb script expects ?  It sounds
> > > like that script isn't finding smbd/nmbd.
> >
> > Correct, I added the path to the top of the init.d/smb script, and smbd and
> > nmbd now start without a problem. I also modified the script to launch the
> > winbindd daemon... very nice.
> >
> > > Second, I don't think that your domain membership for these machines is
> > > going to do you any good.  Specifically, the dual boot is going to muck
> > > you up.  Both half's of the machine can't be members in the nt domain
> > > under the same machine account unless you have a magic way for both
> > > sides to share the same machine password entry (in winnt registry and
> > > linux /etc/.../DOMAIN.MACHINE.mac file)
> >
> > Humm... I'm not sure what happens on the NT side, I'm not much of an NT user.
> > Perhaps you are right, but I now have 'getent passwd' spewing out a list of
> > local users and a list of NT domain users... which is what I wanted. Actually
> > authenticating the NT users to login  is another matter... is that where this
> > .mac file becomes an issue?
> >
> > > Third, it looks like your getent command is hanging on input from
> > > winbindd.
> >
> > Correct again, it turns out that a defunct winbindd process was still hanging
> > around tying up the pipe... killed it and the problem vanished.
> >
> > My next challenge is to force authentication via winbindd against the NT
> > server. I've been struggling with the PAM documentation all weekend, and
> > still don't really know what I'm doing...
> >
> > > Someone suggested to me that I dump the precompiled winbindd and
> > > recompile from the APPLIANCE_TNG cvs branch.  I'm going to give that a
> > > try today or tomorrow.
> >
> > Let me know how you get on, I attempted to compile from the .tar.gz appliance
> > source, but never had much success, in desperation I installed the
> > precompiled package.
> >
> > Shaun
> >
> > --
> > Shaun Cloherty
> > Graduate School of Biomedical Engineering
> > University of New South Wales
> 
> --
>       This message does not represent the policies or positions
>              of the Mayo Foundation or its subsidiaries.
>   Patrick Spinler                       email:  Spinler.Patrick at Mayo.EDU
>   Mayo Foundation                       phone:  507/284-9485

-- 
      This message does not represent the policies or positions
	     of the Mayo Foundation or its subsidiaries.
  Patrick Spinler			email:	Spinler.Patrick at Mayo.EDU
  Mayo Foundation			phone:	507/284-9485