We set up a DialIn W2K SP4 member server in our Samba 3.0.0 domain. When a client dials in the RAS server complains: Error 930: The authentication server did not respond to authentication requests in a timely fashion. I tracked down the RAS logfile IASSAM.LOG: [576] 18:30:34:921: NT-SAM Names handler received request with user identity root. [576] 18:30:34:921: Prepending default domain. [576] 18:30:34:921: SAM-Account-Name is "DOMAIN\root". [576] 18:30:34:921: NT-SAM Authentication handler received request for DOMAIN\root. [576] 18:30:34:921: Processing MS-CHAP v2 authentication. [576] 18:30:34:968: LogonUser succeeded. [576] 18:30:34:968: NT-SAM User Authorization handler received request for DOMAIN\root. [576] 18:30:34:968: Using downlevel dial-in parameters. [576] 18:30:34:968: DS not installed for domain DOMAIN. [576] 18:30:34:968: Connecting to SAM server on \\SERVER. [576] 18:30:35:093: Connecting to SAM server on \\SERVER. [576] 18:30:35:093: Per-user attribute retrieval failed: Access denied Here a corresponding "suspect" part of the level 10 smbd.log that breaks it?!? [2003/10/10 18:30:37, 5] rpc_parse/parse_prs.c:dbg_rw_punival(806) 0028 buffer : D.O.M.A.I.N. [2003/10/10 18:30:37, 4] rpc_server/srv_lsa_hnd.c:find_policy_by_hnd_internal(162) Found policy hnd[0] [000] 00 00 00 00 02 00 00 00 00 00 00 00 AD DE 86 3F ........ ....Þ.? [010] 56 50 00 00 VP.. [2003/10/10 18:30:37, 5] rpc_server/srv_samr_nt.c:access_check_samr_function(106) _samr_lookup_domain: access check ((granted: 0x00000020; required: 0x00000010) [2003/10/10 18:30:37, 2] rpc_server/srv_samr_nt.c:access_check_samr_function(115) _samr_lookup_domain: ACCESS DENIED (granted: 0x00000020; required: 0x00000010) [2003/10/10 18:30:37, 5] rpc_parse/parse_prs.c:prs_debug(81) 000000 samr_io_r_lookup_domain [2003/10/10 18:30:37, 5] rpc_parse/parse_prs.c:prs_uint32(634) 0000 ptr: 00000000 [2003/10/10 18:30:37, 5] rpc_parse/parse_prs.c:prs_ntstatus(664) 0004 status: NT_STATUS_ACCESS_DENIED Andrew Bartlett's comment from mailing list: This looks like a bug to me - can you file it in bugzilla.samba.org - I was involved in adding the access controls here, and I know there are issues - we didn't get all the access masks perfect. However, even when access is permitted, I'm not sure we serve up all the right attributes anyway...
I patched samba to always return ACCESS_GRANTED for testing (to pass the access right problem). So I came to the next step: IASSAM.LOG [556] 23:23:53:671: Connecting to SAM server on \\SERVER. [556] 23:23:53:671: Inserting attribute msNPAllowDialin. [556] 23:23:53:671: Successfully retrieved per-user attributes. Dialin now "only" fails with "Dialin not allowed for user", but I'm not able to set it in UserMgr. Is it possible to map this attribute to Samba? (Munged Dial???)
Can you try current 3.0 CVS, with tdbsam. Set the attribute using usrmgr.exe (user manager for domains, found on NT4 Server).
We're using a production system with LDAP backend, so hardly to convert to tdbsam. But since the pre2 (and current CVS) the usrmgr.exe isn't usable any more, "rpc not defined" or "handle not defined" on user details going hand in hand with the following panic: [2003/11/11 17:57:36, 1] smbd/ipc.c:api_fd_reply(292) api_fd_reply: INVALID PIPE HANDLE: 712c [2003/11/11 17:57:43, 1] smbd/service.c:make_connection_snum(705) general (192.168.100.105) connect to service Profiles initially as user root (uid=0, gid=0) (pid 9675) [2003/11/11 17:58:00, 0] lib/util.c:smb_panic(1400) PANIC: init_unistr2_from_datablob: malloc fail [2003/11/11 17:58:00, 0] lib/util.c:smb_panic(1408) BACKTRACE: 23 stack frames: #0 /usr/local/samba/sbin/smbd(smb_panic+0x193) [0x818a9b3] #1 /usr/local/samba/sbin/smbd(init_unistr2_from_datablob+0x52) [0x80e0272] #2 /usr/local/samba/sbin/smbd(init_sam_user_info20A+0x32) [0x8141fb2] #3 /usr/local/samba/sbin/smbd [0x8118832] #4 /usr/local/samba/sbin/smbd(_samr_query_userinfo+0x229) [0x8118bf9] #5 /usr/local/samba/sbin/smbd [0x8111eb9] #6 /usr/local/samba/sbin/smbd(api_rpcTNP+0x20c) [0x81282dc] #7 /usr/local/samba/sbin/smbd(api_pipe_request+0xd0) [0x8128040] #8 /usr/local/samba/sbin/smbd [0x81224b6] #9 /usr/local/samba/sbin/smbd [0x81226af] #10 /usr/local/samba/sbin/smbd [0x812293b] #11 /usr/local/samba/sbin/smbd [0x8122b08] #12 /usr/local/samba/sbin/smbd(write_to_pipe+0xdb) [0x8122a7b] #13 /usr/local/samba/sbin/smbd [0x8086888] #14 /usr/local/samba/sbin/smbd [0x8086a86] #15 /usr/local/samba/sbin/smbd(reply_trans+0x9d2) [0x80874c2] #16 /usr/local/samba/sbin/smbd [0x80bc4b9] #17 /usr/local/samba/sbin/smbd [0x80bc560] #18 /usr/local/samba/sbin/smbd(process_smb+0x1be) [0x80bc86e] #19 /usr/local/samba/sbin/smbd(smbd_process+0x150) [0x80bd2d0] #20 /usr/local/samba/sbin/smbd(main+0x72f) [0x81e1f6f] #21 /lib/libc.so.6(__libc_start_main+0xbd) [0x400d59ed] #22 /usr/local/samba/sbin/smbd(chroot+0x31) [0x8073d21]
Now we have "Munged Dial" to map the dial-in right, so the attribute problem should be gone away. The problem is now the NT_STATUS_ACCESS_DENIED, have we a chance to handle it?
One report of this working in 3.0.2[a] and then breaking in 3.0.3pre1
It only works (at least in 3.0.2) when the access check will be bypassed. (else NT_STATUS_ACCESS_DENIED in _samr_lookup_domain will be returned, see first comment of this bug) Policy problem?!? See my posting http://lists.samba.org/archive/samba/2004-March/083592.html By the way, bug 1132 is a duplicate
*** Bug 1132 has been marked as a duplicate of this bug. ***
Created attachment 890 [details] Patch to make Samba PDC working with RAS servers This patch solves the problem with the permission of the SAMR_LOOKUP_DOMAIN call of the RAS server. 0x20 is granted for guest when the RAS server calls but it is checked against 0x10 without the patch and so denied. Don't know if correct, but works for us.
Created attachment 895 [details] level 10 log for the error case This level 10 log shows up the problem during RAS auth (ACCESS DENIED) without the patch.
I've found out that my patch is opposite to this one: http://cvs.samba.org/cgi-bin/cvsweb/samba/source/rpc_server/srv_samr_nt.c.diff? r1=1.86.2.40&r2=1.86.2.41
patch applied for .30.11pre2. I'll deal with the win9x user manager later when I audit the access checks in srv_samr_nt.c.
Thanks.