Re. the ongoing failure of the windows7 client to authenticate its
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,
graham.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
