Bug 8161 - specifying incorrect interface in config results in working samba but "incorrect password" messages on client
specifying incorrect interface in config results in working samba but "incorr...
Status: NEW
Product: Samba 3.5
Classification: Unclassified
Component: Domain Control
3.5.6
x86 All
: P5 normal
: ---
Assigned To: Guenther Deschner
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-24 12:17 UTC by Michael De Groote
Modified: 2011-05-24 12:17 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael De Groote 2011-05-24 12:17:14 UTC
During a migration  we encountered the following problem

old situation: 

samba listening on 192.168.0.200 and 10.0.1.80
eth0 had ip 192.168.0.200
eth1 had ip 10.0.1.80

relevant entries in smb.conf 

interfaces = 192.168.0.200 , 10.0.1.80
bind interfaces only = yes

=>all was working ok

=====
new situation:
samba listening on 192.168.0.200 and 10.0.1.80

only eth1 had an ip address assigned: 10.0.1.80

we forgot to modify the interfaces entry in smb.conf

=>the result was that after restarting samba (for some reason we did restart it, but changed nothing in the config..) both nmbd and smbd were running
BUT trying to log in from the windows clients on the domain we received every time "username or password incorrect". Looking in the logs it said

[2011/05/23 17:10:21.287566,  0] auth/auth_sam.c:493(check_sam_security)
  check_sam_security: make_server_info_sam() failed with 'NT_STATUS_NO_SUCH_USER'
[2011/05/23 17:10:24.309874,  0] passdb/pdb_get_set.c:212(pdb_get_group_sid)
  pdb_get_group_sid: Failed to find Unix account for TheUserTryingToLogIn

The problem was resolved by removing the reference to the 192.168.0.200 ip in the 'interfaces' entry in smb.conf.

The reason i file this as a bug is that nor smbd nor nmbd communicate clearly about what the problem is, but instead give the impression that there is something wrong with the link with the user db (openldap in this case).

I have to admit that i DIDNT run testparm beforehand, so i dont know if it would have generated warnings... (not going to reverse the situation atm, since it's working and in use by users, they'll probable splice my head if i break it now)