windows 7 machine account fails to authenticate against samba PDC
in [Samba]
|
Prev: [Samba] windows 7 machine account fails to authenticate against samba PDC
Next: [Samba] WG: Problem with Excel
From: graham on 6 Feb 2010 09:00 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
From: Greg Dickie on 28 Feb 2010 14:40
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 On Sat, 2010-02-06 at 13:58 +0000, graham wrote: > 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. > > -- Greg Dickie just a guy -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba |