samba - Mar 2011 - pam_winbind([sshd|su|...]:account): valid_user: wbcGetpwnam gave WBC_ERR_DOMAIN_NOT_FOUND

I've been getting these in my log for some time and was wondering what I had
to do to get 'pam_winbind' to 'work' with my samba 'DC'?

In looking around the net, others w/this error message were having a
problem with blocking login's and password changes, completely.

In my case, I have the 'pam_winbind.so' module in
'/etc/pam.d/common-passwd'
setup with 'password sufficient', instead of 'password
required', and have
other modules (like pam_unix2) that can continue the authorization should
pam_winbind fail.   So the above error doesn't seem to prevent any
valid operation from succeeding,
  BUT
  I'm wondering why I am getting the error.  I.e.

  1) is it a mistake for samba (or winbind, or whoever) to have configured
winbind to be in the pam-authorization chain *at-all*?   OR
  2) Since I am trying to run my samba server as a DC (my local Win7 
Workstation
is joined to the domain), I *should* have this module in the stack, but 
somehow
it isn't configured correctly (this is what I believe to be the case).

  In the case of 2, the errors seem to occur only on authorizations 
occurring
on the DC (i.e. the main machine running samba in DC mode).  So somehow,
winbind isn't setup to correct process 'unix' validations through my
samba DC. 

Is this type of 'unix' verification supported against a 3.5.4 Samba DC,
or is this only supported for testing against a windows DC?

I.e. if it is the later, then I shouldn't try to use winbind at all(?) :-(.

If it is supported, any idea where I might look to see why winbind
isn't supporting 'local' Samba DC validation?


I could just take the route of 'disabling' any attempt at using winbind
for my unix validation attempts as an 'easy way out' to get rid of these
messages, but I'd prefer to fix the problem rather than bury it,
**IF POSSIBLE**...

So, is this a lost cause, or an arcane misconfiguration?  If the latter,
any idea where to look for the break?  

I have a feeling it has something to do with local login's having no
Domain name attached to them (i.e., because they are 'local', and it not
realizing that 'local' = 'Domain'...  but that's a pure
guess on my part...

Ideas?

Thanks...
Linda

Hi Linda,

On Thu, 2011-03-03 at 11:31 -0800, Linda Walsh wrote:
> In my case, I have the 'pam_winbind.so' module in
'/etc/pam.d/common-passwd'
> setup with 'password sufficient', instead of 'password
required', and have
> other modules (like pam_unix2) that can continue the authorization should
> pam_winbind fail.   So the above error doesn't seem to prevent any
> valid operation from succeeding,
I am unable to speak to the error specifically, but I do have some
practise with a similar kind of setup...
I just recently posted how I get ubuntu machines to validate domain
credentials against a samba pdc.  I can say from experience that the
same methodology works when applied to the pdc itself, however the
configurations were slightly different.  So that post might give you
some guidelines to go with.
In this case, I believe if you are using sufficient and that fails, then
it will continue down the list till it finds one that does succeed.  so
the error doesn't prevent success, but it probably does prevent success
with that module (ie your local unix account is working as opposed to
the domain account).
>   BUT
>   I'm wondering why I am getting the error.  I.e.
> 
>   1) is it a mistake for samba (or winbind, or whoever) to have configured
> winbind to be in the pam-authorization chain *at-all*?   OR
No, if you want to log into a unix box with a domain account, I think
you need to have the winbind.so config in your pam.d files on that unix
box.
>   2) Since I am trying to run my samba server as a DC (my local Win7 
> Workstation
> is joined to the domain), I *should* have this module in the stack, but 
> somehow
> it isn't configured correctly (this is what I believe to be the case).
> 
>   In the case of 2, the errors seem to occur only on authorizations 
> occurring
> on the DC (i.e. the main machine running samba in DC mode).  So somehow,
> winbind isn't setup to correct process 'unix' validations
through my
> samba DC.
Your pdc must have wins server enabled, your smb.conf has to define the
wins server and the password server, among other things.  You will
basically have to configure the winbind client and the wins server in
your smb.conf.  commands like wbinfo -g, wbinfo -u, getent group and
getent passwd need to all be working in order for authentication against
the samba pdc to work.  If those four commands don't produce expected
results, I can all but promise that things won't work as expected.
As stated with the other post, I needed to mess with the net command
quite a bit to get things working.  Though the windows computers were
working flawlessly on the existing domain before I implemented ubuntu
boxes, using winbind forced me to "clean up" my user/group situation.
If your user/group accounts are not correctly configured, then no amount
of fiddling with winbind is going to make it work.  Hence my ability to
tell you that you can use winbind on the pdc itself, doing so was one of
the things that enabled me to narrow in on that particular problem.
>  
> 
> Is this type of 'unix' verification supported against a 3.5.4 Samba
DC,
> or is this only supported for testing against a windows DC?
> 
> I.e. if it is the later, then I shouldn't try to use winbind at all(?)
:-(.
If you want to log into a unix box with a windows Domain Account, you
need winbind.  Or another method than the one I use...
> 
> If it is supported, any idea where I might look to see why winbind
> isn't supporting 'local' Samba DC validation?
Make sure your nsswitch.conf file is configured correctly.  Make sure
your pdc is joined to its own domain.  Make sure you can use the various
switches of wbinfo to go through a user/group account backwards and
forwards.
> 
> 
> I could just take the route of 'disabling' any attempt at using
winbind
> for my unix validation attempts as an 'easy way out' to get rid of
these
> messages, but I'd prefer to fix the problem rather than bury it,
> **IF POSSIBLE**...
> 
> So, is this a lost cause, or an arcane misconfiguration?  If the latter,
> any idea where to look for the break?  
Definitely not a lost cause, probably a regular misconfiguration as
opposed to arcane.
> 
> I have a feeling it has something to do with local login's having no
> Domain name attached to them (i.e., because they are 'local', and
it not
> realizing that 'local' = 'Domain'...  but that's a pure
guess on my part...
There is an smb.conf entry called "use default domain" or some such
that
prevents the requirement of DOMAIN\ in the username "DOMAIN
\domain.name".  I personally found it much easier to not enable that
until after I had everything working, because then I could tell the
difference between a domain account and a local account.  With it
enabled, the two accounts are indistinguishable by name.  After I knew
domain authentication was working, I then implemented the setting to
make life easier for my users...
> 
> Ideas?
Plenty, but that is for another mailing list...
> 
> Thanks...
> Linda
> 
> 
Bob Miller
334-7117/660-5315
http://computerisms.ca
bob at computerisms.ca
Network, Internet, Server,
and Open Source Solutions