[Samba] windows 7 machine account fails to authenticate against samba PDC
graham
I've added my windows7 client to the domain (samba running as pdc),
having applied the registry changes identified here
(http://wiki.samba.org/index.php/Windows7).
Partial success - domain users can login and see shares etc, BUT:
1 - the registry settings in ntlogon/NTConfig.POL are not applied. Am I
right in thinking that windows 7 ignores this policy?
And if so I therefore need to put the appropriate registry settings into
a logon script?
2 - every time a domain user logs in to the windows7 host smbd reports
an error:
[2010/02/02 19:07:51, 0]
rpc_server/srv_netlog_nt.c:603(_netr_ServerAuthenticate3)
_netr_ServerAuthenticate3: netlogon_creds_server_check failed.
Rejecting auth request from client WIN7HOST machine account WIN7HOST$
[2010/02/02 19:07:52, 0] auth/auth_sam.c:355(check_sam_security)
check_sam_security: make_server_info_sam() failed with
'NT_STATUS_NO_SUCH_USER'
This only occurs for the windows7 client (not XP clients).
What does this mean, is it a problem, and how do I fix it?!
3 - periodic errors reported by nmbd:
Packet send failed to 192.168.10.8(138) ERRNO=Operation not permitted
That's the ipaddress of the windows7 client.
Actually, looking back in the logs I see this has occasionally happened
for all but one of the xp clients too.
Again, what does this error mean, is it a problem, how would I fix it?
4 - windows7 client bombards the server on port 389 (ldap)
No idea why, no other (xp) clients do this. I'm guessing it /might/ be
part of question 2 above ,ie. maybe the win7 client is trying to
authenticate against ldap??
rgds all,
graham.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
Gaiseric Vandal
and save files? It does seem like it is trying to reauthenticate as an
active directory client.
Maybe config samba to only listen on port 139 and not 445 ("smb ports"
in smb.conf.) That might force the Win 7 client to treat the samba
server as a "NT4" server. I believe port 445 is for Smb-over-tcp while
139 is for smb-over-netbios-over-tcp.
graham
> What samba version?
version 3.4.5
> After you login from Win 7 can you actually open
> and save files?
yes. I'm not familiar enough with smb etc. to understand why the machine
itself is trying to authenticate in addition to the user, and whether it
matters.
> It does seem like it is trying to reauthenticate as an
> active directory client.
>
> Maybe config samba to only listen on port 139 and not 445 ("smb ports"
> in smb.conf.) That might force the Win 7 client to treat the samba
> server as a "NT4" server. I believe port 445 is for Smb-over-tcp while
> 139 is for smb-over-netbios-over-tcp.
I do have that set.
For completeness, the [global] config is:
workgroup = SMBDOMAIN
netbios name = SAMBASERVER
server string =
map to guest = Bad User
username map = /etc/samba/username-map
restrict anonymous = 1
log level = 1
smb ports = 139
name resolve order = wins lmhosts
time server = Yes
printcap name = cups
add machine script = /usr/sbin/useradd -d /dev/null -g sambausers -c
Machine -s /bin/false %u
logon script = logon.bat
logon path =
logon home =
domain logons = Yes
os level = 65
preferred master = Yes
domain master = Yes
wins support = Yes
Gaiseric Vandal
for the machine. The machine- if it is a domain member- does need to
have an account. Were you able to join the machine to the domain? if
so there should be both a samba (windows) account (verify with "pdbedit
-Lv") and a unix account (verify with "getent passwd.")
graham
> it looks like from the log entries that the samba can't find an account
> for the machine. The machine- if it is a domain member- does need to
> have an account. Were you able to join the machine to the domain? if so
> there should be both a samba (windows) account (verify with "pdbedit
> -Lv") and a unix account (verify with "getent passwd.")
Hi Gaiseric , thanks for getting back to me.
Yes, it appeared to join the domain correctly.
There is an appropriate machine account and entry in/etc/passwd, and it
looks identical to a working xp client's:
pdbedit -Lv:
Unix username: XPHOST$
NT username:
Account Flags: [W ]
User SID: S-1-5-21-764034647-1846980996-1928349337-1028
Primary Group SID: S-1-5-21-764034647-1846980996-1928349337-513
Full Name: XPHOST$
Home Directory:
HomeDir Drive:
Logon Script: logon.bat
Profile Path:
Domain: SMBDOMAIN
Account desc:
Workstations:
Munged dial:
Logon time: 0
Logoff time: never
Kickoff time: never
Password last set: Tue, 19 Jan 2010 12:21:19 GMT
Password can change: Tue, 19 Jan 2010 12:21:19 GMT
Password must change: never
Last bad password : 0
Bad password count : 0
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
---------------
Unix username: WIN7HOST$
NT username:
Account Flags: [W ]
User SID: S-1-5-21-764034647-1846980996-1928349337-1031
Primary Group SID: S-1-5-21-764034647-1846980996-1928349337-513
Full Name: WIN7HOST$
Home Directory:
HomeDir Drive:
Logon Script: logon.bat
Profile Path:
Domain: SMBDOMAIN
Account desc:
Workstations:
Munged dial:
Logon time: 0
Logoff time: never
Kickoff time: never
Password last set: Tue, 02 Feb 2010 19:04:05 GMT
Password can change: Tue, 02 Feb 2010 19:04:05 GMT
Password must change: never
Last bad password : 0
Bad password count : 0
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
getent passwd:
XPHOST$:x:1011:102:Machine:/dev/null:/bin/false
WIN7HOST$:x:1012:102:Machine:/dev/null:/bin/false
graham
I don't know why (I don't think I've changed anything), but there is an
extra log entry showing the host is in the passdb, but getpwnam() is
failing.
However, the machine name is definitely in /etc/passwd.
Can anyone cast any light on this apparent inconsistency, or what I
might do to diagnose the problem further?
[2010/02/05 17:19:16, 0]
rpc_server/srv_netlog_nt.c:603(_netr_ServerAuthenticate3)
_netr_ServerAuthenticate3: netlogon_creds_server_check failed.
Rejecting auth request from client WIN7HOST machine account WIN7HOST$
*[2010/02/05 17:19:23, 1] auth/auth_util.c:577(make_server_info_sam)
User WIN7HOST$ in passdb, but getpwnam() fails!*
[2010/02/05 17:19:23, 0] auth/auth_sam.c:355(check_sam_security)
check_sam_security: make_server_info_sam() failed with
'NT_STATUS_NO_SUCH_USER'
graham
machine account, I've upped the log level and added an extra debug
statement to getpwnam_alloc().
There are a couple of discrepancies which I very much hope someone can
explain, or at least point me in the direction of how to resolve!
Comparing the output for a winXP client (successful) and the win7 client
(unsuccessful), it seems that:
1 - the challenge-response mechanism is different for the win7 machine
to that of the winXp machine (and the win7 machine fails this
authentication).
Can anyone enlighten me as to why the different challenge, and why the
client might fail it?
This is the trace for the unsuccessful win7 machine:
[2010/02/05 22:55:10, 5] libsmb/credentials.c:70(creds_init_128)
creds_init_128
[2010/02/05 22:55:10, 5] libsmb/credentials.c:71(creds_init_128)
clnt_chal_in: 444EA615F23340F2
[2010/02/05 22:55:10, 5] libsmb/credentials.c:72(creds_init_128)
srv_chal_in : DE62C1B8DCC1E4AD
[2010/02/05 22:55:10, 5]
libsmb/credentials.c:221(netlogon_creds_server_check)
netlogon_creds_server_check: challenge : 2818DBF48BE4EBC0
[2010/02/05 22:55:10, 5]
libsmb/credentials.c:222(netlogon_creds_server_check)
calculated: EDC837F244BC1EBB
[2010/02/05 22:55:10, 2]
libsmb/credentials.c:223(netlogon_creds_server_check)
netlogon_creds_server_check: credentials check failed.
This is the trace for the successful winXP machine:
[2010/02/05 23:06:44, 5] libsmb/credentials.c:121(creds_init_64)
clnt_chal_in: DF0D76C6D2BF3CDB
[2010/02/05 23:06:44, 5] libsmb/credentials.c:122(creds_init_64)
srv_chal_in : EE4404370EE4219C
[2010/02/05 23:06:44, 5] libsmb/credentials.c:123(creds_init_64)
clnt+srv : CD527AFDE0A35E77
[2010/02/05 23:06:44, 5] libsmb/credentials.c:124(creds_init_64)
sess_key_out : 6D4885F56283E87B
2 - later, (perhaps as some fallback authentication?) the get_pwnam() is
called a number of times for this machine account, initially it succeeds
then in a later call fails NOT because the machine account isn't in
/etc/passwd, but because it is looked up in UPPER case.
Is this a bug?
Here's the trace for the failure:
[2010/02/05 22:55:18, 3] smbd/sec_ctx.c:418(pop_sec_ctx)
pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 0
[2010/02/05 22:55:18, 3] smbd/sec_ctx.c:210(push_sec_ctx)
push_sec_ctx(0, 0) : sec_ctx_stack_ndx = 1
[2010/02/05 22:55:18, 3] smbd/uid.c:428(push_conn_ctx)
push_conn_ctx(0) : conn_ctx_stack_ndx = 0
[2010/02/05 22:55:18, 3] smbd/sec_ctx.c:310(set_sec_ctx)
setting sec ctx (0, 0) - sec_ctx_stack_ndx = 1
[2010/02/05 22:55:18, 5] auth/token_util.c:522(debug_nt_user_token)
NT user token: (NULL)
[2010/02/05 22:55:18, 5] auth/token_util.c:548(debug_unix_user_token)
UNIX token of user 0
Primary group is 0 and contains 0 supplementary groups
[2010/02/05 22:55:18, 1] lib/util_pw.c:59(getpwnam_alloc)
my extra debug: sys_getpwnam(WIN7HOST$) failed
^ *the name as passed to getpwnam_alloc*
[2010/02/05 22:55:18, 1] auth/auth_util.c:577(make_server_info_sam)
User WIN7HOST$ in passdb, but getpwnam() fails!
rgds,
Greg Dickie
Hi,
I've just been debugging something related to this. Environment is
samba 3.4.6 with LDAP backend and windows 7 clients. In my case the user
in passdb but getpwnam() fails led me to adjust /etc/ldap.conf so that
machine accounts were also listed as valid users on the system.
I don't really understand why this is required since ldapsam:trusted =
yes in my case and I thought that parameter would bypass the getpwnam()
check.
No idea about the credentials failing, I'm just happy I can give domain
users privilege on the win7 machines ;-)
hope this helps,
Greg
--
Greg Dickie
just a guy
mrArcabuz
experience in case someone finds it useful:
I set up a standalone (tdb backend) PDC on samba 3.4.7 (Ubuntu 10.04 LTS)
and got similar messages as graham-65 did:
[2011/06/21 17:01:45, 1] auth/auth_util.c:577(make_server_info_sam)
User WIN7HOST$ in passdb, but getpwnam() fails!
[2011/06/21 17:01:45, 0] auth/auth_sam.c:355(check_sam_security)
check_sam_security: make_server_info_sam() failed with
'NT_STATUS_NO_SUCH_USER'
In my case, the logon proceeds normally & the user on WIN7HOST$ can open
and close files normally.
I believe the issue lies with the upper case name of the machine account.
I changed the machine account name to uppercase in the passwd & shadow
files and the message does not appear anymore in the logs.
This would explain why it's not an issue on an LDAP backend, as the uid
there is case insensitive.
Greetings
Jose
--
View this message in context: http://samba.2283325.n4.nabble.com/windows-7-machine-account-fails-to-authenticate-against-samba-PDC-tp2446003p3615534.html
Sent from the Samba - General mailing list archive at Nabble.com.
Fabio Muzzi
> Hi, it's been a while since the original message appeared, but here's my
> experience in case someone finds it useful:
> I changed the machine account name to uppercase in the passwd & shadow
> files and the message does not appear anymore in the logs.
>
> This would explain why it's not an issue on an LDAP backend, as the uid
> there is case insensitive.
backend, no LDAP) and I can confirm that /etc/passwd entries created by
adding machines to domain (via the "add machine script") show an
UPPERCASE name in Samba (that is, when I issue a "pdbedit -L" command)
but a lowercase name in /etc/passwd, resulting in errors being logged
when the machine connects to Samba because its username (uppercase)
cannot be found in /etc/passwd (where it is written in lowercase).
The workaround is in fact to edit /etc/passwd to se the machines
usernames to uppercase.
I don't understand why and when this behaviour changed.
I have a very old Samba installation that shows the older machine
entries in PDB file being lowercase, as in this example:
#pdbedit -L
...
nb-gmg$:1051:NB-GMG$
...
and other entries in the same PDB file being all uppercase, like this:
NOTEBOOK-FLAVIA$:4294967295:NOTEBOOK-FLAVIA$
Since all of the /etc/passwd file entries are lowercase, the second
example (NOTEBOOK-FLAVIA$) does not authenticate correctly. You can also
see that the output of the "pdbedit -L" command reports a wrong unix UID
(4294967295) for the uppercase entry, because it cannot find it in
/etc/passwd (being lowercase in passwd).
If I edit /etc/passwd and set the username in uppercase there, then
everything works, and also the unix UID shown by "pdbedit -L" is correct.
--
Fabio "Kurgan" Muzzi
- IZ4UFQ -
Giaaaanniiii! L'ottimismo e' il profumo di quella gnocca di tua
sorella!Corri anche tu alla UniEuro!Ci sono radio che traspirano, cani
di un'altra galassia!!!