Hi, A final repost of the below issue -- we still are not making any progress. It is unclear whether we need to be using winbind -- I don't believe so, and the Terpstra Samba 3 book doesn't suggest that this is necessary in this configuration; but please correct me if my preconception is flawed. If this is the 'wrong place' to ask -- any suggestions about where I should be looking? Likewise, if any more information is required, what do I need to provide? To reiterate -- we have a 'working' Samba server for the ADS domain of which it is a member -- it just doesn't authenticate users who present credentials from the MIT realm trusted by that domain which are mapped in the AD of the member domain to AD accounts when the credentials are presented by Windows clients. Likewise -- anyone with experience of running Samba in this environment who might be able to hint at anything we might have missed? Matt On Mon, 31 Oct 2005, Matt Johnson wrote:> Hi all, > > We're having some issues getting Samba to work in the way we'd like it to in > our domain infrastructure. > > We have a real Windows domain WIN (WIN.DOC.IC.AC.UK) which is run on Windows > 2003 domain controllers. We also have an MIT Kerberos realm DOC.IC.AC.UK. A > realm trust exists such that WIN.DOC.IC.AC.UK trusts DOC.IC.AC.UK for > authentication, and users have appropriate Kerberos name mappings in the AD. > > All of the core Windows domain/realm trust stuff seems to work; we can log > in using the MIT Kerberos principal and get the right user account -- so > this level of the setup is working fine. > > We have a Samba 3.0.20b server running in ADS mode, I believe the following > are the requisite config entries: > > security = ads > realm = WIN.DOC.IC.AC.UK > workgroup = WIN > wins server = (our domain controllers) > password server = * > remote announce = (our domain controllers)/WIN > nt acl support = yes > encrypt passwords = yes > lanman auth = no > password level = 0 > wins support = no > > ...and it is a member server in WIN.DOC.IC.AC.UK. ("net ads join" stuff all > done and working fine.) > > Now, the problem itself: > > Case 1: If we log into a WinXP SP2 client (a member workstation of the WIN > domain) using the credentials stored in the AD for WIN, we can access shares > on the Samba server. (All well and good.) > > Case 2: If we log into the same WinXP client using the trusted realm > credentials in DOC.IC.AC.UK, we can access shares hosted on real Windows > servers. (So that should mean that we have the domain trust set up correctly > as far as the AD is concerned.) > > Case 3: If I log into a Unix machine and have credentials in DOC.IC.AC.UK > and use "smbclient -k" to connect to a share on the Samba server, this works > uniformly, 100% of the time. > > Case 4: If we log into the same WinXP client using the trusted realm > credentials in DOC.IC.AC.UK, we can only very rarely (< 1% of the time) > access shares on the Samba server. > > It seems to work rarely and non-deterministically! When it fails, it seems > that either the client or the server is attempting to authenticate me using > WIN.DOC.IC.AC.UK alone, which Samba barfs over. > > (IP addresses / real hostnames redacted.) > > [2005/10/31 11:18:40, 3] smbd/negprot.c:reply_nt1(337) > using SPNEGO > [2005/10/31 11:18:40, 3] smbd/negprot.c:reply_negprot(559) > Selected protocol NT LM 0.12 > [2005/10/31 11:18:40, 3] smbd/process.c:process_smb(1114) > Transaction 1 of length 240 > [2005/10/31 11:18:40, 3] smbd/process.c:switch_message(900) > switch message SMBsesssetupX (pid 23393) conn 0x0 > [2005/10/31 11:18:40, 3] smbd/sec_ctx.c:set_sec_ctx(288) > setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0 > [2005/10/31 11:18:40, 3] smbd/sesssetup.c:reply_sesssetup_and_X(751) > wct=12 flg2=0xc807 > [2005/10/31 11:18:40, 3] smbd/sesssetup.c:reply_sesssetup_and_X_spnego(588) > Doing spnego session setup > [2005/10/31 11:18:40, 3] smbd/sesssetup.c:reply_sesssetup_and_X_spnego(619) > NativeOS=[Windows 2002 Service Pack 2 2600] NativeLanMan=[Windows 2002 5.1] > PrimaryDomain=[] > [2005/10/31 11:18:40, 3] smbd/sesssetup.c:reply_spnego_negotiate(480) > Got OID 1 3 6 1 4 1 311 2 2 10 > [2005/10/31 11:18:40, 3] smbd/sesssetup.c:reply_spnego_negotiate(483) > Got secblob of size 40 > [2005/10/31 11:18:40, 3] libsmb/ntlmssp.c:debug_ntlmssp_flags(62) > Got NTLMSSP neg_flags=0xe2088297 > [2005/10/31 11:18:40, 3] smbd/process.c:process_smb(1114) > Transaction 2 of length 338 > [2005/10/31 11:18:40, 3] smbd/process.c:switch_message(900) > switch message SMBsesssetupX (pid 23393) conn 0x0 > [2005/10/31 11:18:40, 3] smbd/sec_ctx.c:set_sec_ctx(288) > setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0 > [2005/10/31 11:18:40, 3] smbd/sesssetup.c:reply_sesssetup_and_X(751) > wct=12 flg2=0xc807 > [2005/10/31 11:18:40, 3] smbd/sesssetup.c:reply_sesssetup_and_X_spnego(588) > Doing spnego session setup > [2005/10/31 11:18:40, 3] smbd/sesssetup.c:reply_sesssetup_and_X_spnego(619) > NativeOS=[Windows 2002 Service Pack 2 2600] NativeLanMan=[Windows 2002 5.1] > PrimaryDomain=[] > [2005/10/31 11:18:40, 3] libsmb/ntlmssp.c:ntlmssp_server_auth(606) > Got user=[mwj] domain=[WIN] workstation=[CLIENT] len1=24 len2=24 > [2005/10/31 11:18:40, 3] libads/ldap.c:ads_connect(285) > Connected to LDAP server 146.169.x.x > [2005/10/31 11:18:40, 3] libads/ldap.c:ads_server_info(2514) > got ldap server name dc@WIN.DOC.IC.AC.UK, using bind path: > dc=WIN,dc=DOC,dc=IC,dc=AC,dc=UK > [2005/10/31 11:18:40, 3] libsmb/cliconnect.c:cli_start_connection(1407) > Connecting to host=DC > [2005/10/31 11:18:40, 3] lib/util_sock.c:open_socket_out(867) > Connecting to 146.169.x.x at port 445 > [2005/10/31 11:18:40, 3] rpc_parse/parse_lsa.c:lsa_io_sec_qos(181) > lsa_io_sec_qos: length c does not match size 8 > [2005/10/31 11:18:40, 3] auth/auth.c:check_ntlm_password(219) > check_ntlm_password: Checking password for unmapped user > [WIN]\[mwj]@[CLIENT] with the new password interface > [2005/10/31 11:18:40, 3] auth/auth.c:check_ntlm_password(222) > check_ntlm_password: mapped user is: [WIN]\[mwj]@[CLIENT] > [2005/10/31 11:18:40, 3] smbd/sec_ctx.c:push_sec_ctx(256) > push_sec_ctx(0, 0) : sec_ctx_stack_ndx = 1 > [2005/10/31 11:18:40, 3] smbd/uid.c:push_conn_ctx(388) > push_conn_ctx(0) : conn_ctx_stack_ndx = 0 > [2005/10/31 11:18:40, 3] smbd/sec_ctx.c:set_sec_ctx(288) > setting sec ctx (0, 0) - sec_ctx_stack_ndx = 1 > [2005/10/31 11:18:40, 3] smbd/sec_ctx.c:pop_sec_ctx(386) > pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 0 > [2005/10/31 11:18:40, 3] libads/ldap.c:ads_connect(285) > Connected to LDAP server 146.169.x.x > [2005/10/31 11:18:40, 3] libads/ldap.c:ads_server_info(2514) > got ldap server name dc@WIN.DOC.IC.AC.UK, using bind path: > dc=WIN,dc=DOC,dc=IC,dc=AC,dc=UK > [2005/10/31 11:18:40, 3] libsmb/cliconnect.c:cli_start_connection(1407) > Connecting to host=DC > [2005/10/31 11:18:40, 3] lib/util_sock.c:open_socket_out(867) > Connecting to 146.169.x.x at port 445 > [2005/10/31 11:18:40, 0] auth/auth_domain.c:domain_client_validate(199) > domain_client_validate: unable to validate password for user mwj in domain > WIN to Domain controller \\DC. Error was NT_STATUS_WRONG_PASSWORD. > [2005/10/31 11:18:40, 2] auth/auth.c:check_ntlm_password(317) > check_ntlm_password: Authentication for user [mwj] -> [mwj] FAILED with > error NT_STATUS_WRONG_PASSWORD > > When it works, it realizes that there is a foreign realm involved and > authenticates fine. > > 2005/10/31 11:00:56, 3] smbd/negprot.c:reply_nt1(337) > using SPNEGO > [2005/10/31 11:00:56, 3] smbd/negprot.c:reply_negprot(559) > Selected protocol NT LM 0.12 > [2005/10/31 11:00:56, 3] smbd/process.c:process_smb(1114) > Transaction 2 of length 1568 > [2005/10/31 11:00:56, 3] smbd/process.c:switch_message(900) > switch message SMBsesssetupX (pid 22782) conn 0x0 > [2005/10/31 11:00:56, 3] smbd/sec_ctx.c:set_sec_ctx(288) > setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0 > [2005/10/31 11:00:56, 3] smbd/sesssetup.c:reply_sesssetup_and_X(751) > wct=12 flg2=0xc807 > [2005/10/31 11:00:56, 3] smbd/sesssetup.c:reply_sesssetup_and_X_spnego(588) > Doing spnego session setup > [2005/10/31 11:00:56, 3] smbd/sesssetup.c:reply_sesssetup_and_X_spnego(619) > NativeOS=[Windows 2002 Service Pack 2 2600] NativeLanMan=[Windows 2002 5.1] > PrimaryDomain=[] > [2005/10/31 11:00:56, 3] smbd/sesssetup.c:reply_spnego_negotiate(480) > Got OID 1 2 840 48018 1 2 2 > [2005/10/31 11:00:56, 3] smbd/sesssetup.c:reply_spnego_negotiate(480) > Got OID 1 2 840 113554 1 2 2 > [2005/10/31 11:00:56, 3] smbd/sesssetup.c:reply_spnego_negotiate(480) > Got OID 1 3 6 1 4 1 311 2 2 10 > [2005/10/31 11:00:56, 3] smbd/sesssetup.c:reply_spnego_negotiate(483) > Got secblob of size 1337 > [2005/10/31 11:00:57, 3] smbd/sesssetup.c:reply_spnego_kerberos(179) > Ticket name is [mwj@DOC.IC.AC.UK] > [2005/10/31 11:00:57, 3] smbd/sesssetup.c:reply_spnego_kerberos(192) > Ticket for foreign realm mwj@DOC.IC.AC.UK > > The clocks on all machines involved are synchronized to a single source. > > Has anyone heard of this type of problem and/or has a solution? Equally, > does anyone need more information to debug the problem? > > Thanks, > > Matt >-- Matt Johnson <mwj@doc.ic.ac.uk>
John H Terpstra
2005-Nov-23 23:14 UTC
[Samba] ADS mode / MIT realm trust problem (3.0.20b)
On Wednesday 23 November 2005 15:39, Matt Johnson wrote:> Hi, > > A final repost of the below issue -- we still are not making any > progress. It is unclear whether we need to be using winbind -- I don'tI suspect you may need to run winbindd, but would prefer to defer to input from one of the Kerberos/ADS gurus.> believe so, and the Terpstra Samba 3 book doesn't suggest that this isI wrote BOTH Samba books that are part of the Samba documentation project, it would help to know which of these you have referred to.> necessary in this configuration; but please correct me if my > preconception is flawed. > > If this is the 'wrong place' to ask -- any suggestions about where I > should be looking? Likewise, if any more information is required, what > do I need to provide?This is the correct forum, but since it is user supported you are not guarranteed a response. If yuor need is urgent you should consider commercial Samba support - see: http://www.samba.org/samba/support/> To reiterate -- we have a 'working' Samba server for the ADS domain of > which it is a member -- it just doesn't authenticate users who present > credentials from the MIT realm trusted by that domain which are mapped > in the AD of the member domain to AD accounts when the credentials are > presented by Windows clients.I have not addressed this type of configuration in any of the official documentation as I consider this to be well outside of normal scope. If someone is willing to contribute a chapter on Kerberos to ADS integration involving Samba this will be most welcome. Cheers, John T.> Likewise -- anyone with experience of running Samba in this environment > who might be able to hint at anything we might have missed? > > Matt > > On Mon, 31 Oct 2005, Matt Johnson wrote: > > Hi all, > > > > We're having some issues getting Samba to work in the way we'd like it > > to in our domain infrastructure. > > > > We have a real Windows domain WIN (WIN.DOC.IC.AC.UK) which is run on > > Windows 2003 domain controllers. We also have an MIT Kerberos realm > > DOC.IC.AC.UK. A realm trust exists such that WIN.DOC.IC.AC.UK trusts > > DOC.IC.AC.UK for authentication, and users have appropriate Kerberos name > > mappings in the AD. > > > > All of the core Windows domain/realm trust stuff seems to work; we can > > log in using the MIT Kerberos principal and get the right user account -- > > so this level of the setup is working fine. > > > > We have a Samba 3.0.20b server running in ADS mode, I believe the > > following are the requisite config entries: > > > > security = ads > > realm = WIN.DOC.IC.AC.UK > > workgroup = WIN > > wins server = (our domain controllers) > > password server = * > > remote announce = (our domain controllers)/WIN > > nt acl support = yes > > encrypt passwords = yes > > lanman auth = no > > password level = 0 > > wins support = no > > > > ...and it is a member server in WIN.DOC.IC.AC.UK. ("net ads join" stuff > > all done and working fine.) > > > > Now, the problem itself: > > > > Case 1: If we log into a WinXP SP2 client (a member workstation of the > > WIN domain) using the credentials stored in the AD for WIN, we can access > > shares on the Samba server. (All well and good.) > > > > Case 2: If we log into the same WinXP client using the trusted realm > > credentials in DOC.IC.AC.UK, we can access shares hosted on real Windows > > servers. (So that should mean that we have the domain trust set up > > correctly as far as the AD is concerned.) > > > > Case 3: If I log into a Unix machine and have credentials in > > DOC.IC.AC.UK and use "smbclient -k" to connect to a share on the Samba > > server, this works uniformly, 100% of the time. > > > > Case 4: If we log into the same WinXP client using the trusted realm > > credentials in DOC.IC.AC.UK, we can only very rarely (< 1% of the time) > > access shares on the Samba server. > > > > It seems to work rarely and non-deterministically! When it fails, it > > seems that either the client or the server is attempting to authenticate > > me using WIN.DOC.IC.AC.UK alone, which Samba barfs over. > > > > (IP addresses / real hostnames redacted.) > > > > [2005/10/31 11:18:40, 3] smbd/negprot.c:reply_nt1(337) > > using SPNEGO > > [2005/10/31 11:18:40, 3] smbd/negprot.c:reply_negprot(559) > > Selected protocol NT LM 0.12 > > [2005/10/31 11:18:40, 3] smbd/process.c:process_smb(1114) > > Transaction 1 of length 240 > > [2005/10/31 11:18:40, 3] smbd/process.c:switch_message(900) > > switch message SMBsesssetupX (pid 23393) conn 0x0 > > [2005/10/31 11:18:40, 3] smbd/sec_ctx.c:set_sec_ctx(288) > > setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0 > > [2005/10/31 11:18:40, 3] smbd/sesssetup.c:reply_sesssetup_and_X(751) > > wct=12 flg2=0xc807 > > [2005/10/31 11:18:40, 3] > > smbd/sesssetup.c:reply_sesssetup_and_X_spnego(588) Doing spnego session > > setup > > [2005/10/31 11:18:40, 3] > > smbd/sesssetup.c:reply_sesssetup_and_X_spnego(619) NativeOS=[Windows 2002 > > Service Pack 2 2600] NativeLanMan=[Windows 2002 5.1] PrimaryDomain=[] > > [2005/10/31 11:18:40, 3] smbd/sesssetup.c:reply_spnego_negotiate(480) > > Got OID 1 3 6 1 4 1 311 2 2 10 > > [2005/10/31 11:18:40, 3] smbd/sesssetup.c:reply_spnego_negotiate(483) > > Got secblob of size 40 > > [2005/10/31 11:18:40, 3] libsmb/ntlmssp.c:debug_ntlmssp_flags(62) > > Got NTLMSSP neg_flags=0xe2088297 > > [2005/10/31 11:18:40, 3] smbd/process.c:process_smb(1114) > > Transaction 2 of length 338 > > [2005/10/31 11:18:40, 3] smbd/process.c:switch_message(900) > > switch message SMBsesssetupX (pid 23393) conn 0x0 > > [2005/10/31 11:18:40, 3] smbd/sec_ctx.c:set_sec_ctx(288) > > setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0 > > [2005/10/31 11:18:40, 3] smbd/sesssetup.c:reply_sesssetup_and_X(751) > > wct=12 flg2=0xc807 > > [2005/10/31 11:18:40, 3] > > smbd/sesssetup.c:reply_sesssetup_and_X_spnego(588) Doing spnego session > > setup > > [2005/10/31 11:18:40, 3] > > smbd/sesssetup.c:reply_sesssetup_and_X_spnego(619) NativeOS=[Windows 2002 > > Service Pack 2 2600] NativeLanMan=[Windows 2002 5.1] PrimaryDomain=[] > > [2005/10/31 11:18:40, 3] libsmb/ntlmssp.c:ntlmssp_server_auth(606) > > Got user=[mwj] domain=[WIN] workstation=[CLIENT] len1=24 len2=24 > > [2005/10/31 11:18:40, 3] libads/ldap.c:ads_connect(285) > > Connected to LDAP server 146.169.x.x > > [2005/10/31 11:18:40, 3] libads/ldap.c:ads_server_info(2514) > > got ldap server name dc@WIN.DOC.IC.AC.UK, using bind path: > > dc=WIN,dc=DOC,dc=IC,dc=AC,dc=UK > > [2005/10/31 11:18:40, 3] libsmb/cliconnect.c:cli_start_connection(1407) > > Connecting to host=DC > > [2005/10/31 11:18:40, 3] lib/util_sock.c:open_socket_out(867) > > Connecting to 146.169.x.x at port 445 > > [2005/10/31 11:18:40, 3] rpc_parse/parse_lsa.c:lsa_io_sec_qos(181) > > lsa_io_sec_qos: length c does not match size 8 > > [2005/10/31 11:18:40, 3] auth/auth.c:check_ntlm_password(219) > > check_ntlm_password: Checking password for unmapped user > > [WIN]\[mwj]@[CLIENT] with the new password interface > > [2005/10/31 11:18:40, 3] auth/auth.c:check_ntlm_password(222) > > check_ntlm_password: mapped user is: [WIN]\[mwj]@[CLIENT] > > [2005/10/31 11:18:40, 3] smbd/sec_ctx.c:push_sec_ctx(256) > > push_sec_ctx(0, 0) : sec_ctx_stack_ndx = 1 > > [2005/10/31 11:18:40, 3] smbd/uid.c:push_conn_ctx(388) > > push_conn_ctx(0) : conn_ctx_stack_ndx = 0 > > [2005/10/31 11:18:40, 3] smbd/sec_ctx.c:set_sec_ctx(288) > > setting sec ctx (0, 0) - sec_ctx_stack_ndx = 1 > > [2005/10/31 11:18:40, 3] smbd/sec_ctx.c:pop_sec_ctx(386) > > pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 0 > > [2005/10/31 11:18:40, 3] libads/ldap.c:ads_connect(285) > > Connected to LDAP server 146.169.x.x > > [2005/10/31 11:18:40, 3] libads/ldap.c:ads_server_info(2514) > > got ldap server name dc@WIN.DOC.IC.AC.UK, using bind path: > > dc=WIN,dc=DOC,dc=IC,dc=AC,dc=UK > > [2005/10/31 11:18:40, 3] libsmb/cliconnect.c:cli_start_connection(1407) > > Connecting to host=DC > > [2005/10/31 11:18:40, 3] lib/util_sock.c:open_socket_out(867) > > Connecting to 146.169.x.x at port 445 > > [2005/10/31 11:18:40, 0] auth/auth_domain.c:domain_client_validate(199) > > domain_client_validate: unable to validate password for user mwj in > > domain WIN to Domain controller \\DC. Error was NT_STATUS_WRONG_PASSWORD. > > [2005/10/31 11:18:40, 2] auth/auth.c:check_ntlm_password(317) > > check_ntlm_password: Authentication for user [mwj] -> [mwj] FAILED > > with error NT_STATUS_WRONG_PASSWORD > > > > When it works, it realizes that there is a foreign realm involved and > > authenticates fine. > > > > 2005/10/31 11:00:56, 3] smbd/negprot.c:reply_nt1(337) > > using SPNEGO > > [2005/10/31 11:00:56, 3] smbd/negprot.c:reply_negprot(559) > > Selected protocol NT LM 0.12 > > [2005/10/31 11:00:56, 3] smbd/process.c:process_smb(1114) > > Transaction 2 of length 1568 > > [2005/10/31 11:00:56, 3] smbd/process.c:switch_message(900) > > switch message SMBsesssetupX (pid 22782) conn 0x0 > > [2005/10/31 11:00:56, 3] smbd/sec_ctx.c:set_sec_ctx(288) > > setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0 > > [2005/10/31 11:00:56, 3] smbd/sesssetup.c:reply_sesssetup_and_X(751) > > wct=12 flg2=0xc807 > > [2005/10/31 11:00:56, 3] > > smbd/sesssetup.c:reply_sesssetup_and_X_spnego(588) Doing spnego session > > setup > > [2005/10/31 11:00:56, 3] > > smbd/sesssetup.c:reply_sesssetup_and_X_spnego(619) NativeOS=[Windows 2002 > > Service Pack 2 2600] NativeLanMan=[Windows 2002 5.1] PrimaryDomain=[] > > [2005/10/31 11:00:56, 3] smbd/sesssetup.c:reply_spnego_negotiate(480) > > Got OID 1 2 840 48018 1 2 2 > > [2005/10/31 11:00:56, 3] smbd/sesssetup.c:reply_spnego_negotiate(480) > > Got OID 1 2 840 113554 1 2 2 > > [2005/10/31 11:00:56, 3] smbd/sesssetup.c:reply_spnego_negotiate(480) > > Got OID 1 3 6 1 4 1 311 2 2 10 > > [2005/10/31 11:00:56, 3] smbd/sesssetup.c:reply_spnego_negotiate(483) > > Got secblob of size 1337 > > [2005/10/31 11:00:57, 3] smbd/sesssetup.c:reply_spnego_kerberos(179) > > Ticket name is [mwj@DOC.IC.AC.UK] > > [2005/10/31 11:00:57, 3] smbd/sesssetup.c:reply_spnego_kerberos(192) > > Ticket for foreign realm mwj@DOC.IC.AC.UK > > > > The clocks on all machines involved are synchronized to a single source. > > > > Has anyone heard of this type of problem and/or has a solution? Equally, > > does anyone need more information to debug the problem? > > > > Thanks, > > > > Matt > > -- > Matt Johnson <mwj@doc.ic.ac.uk>-- John H Terpstra Samba-Team Member Author: The Official Samba-3 HOWTO & Reference Guide, 2 Ed., ISBN: 0131882228 Samba-3 by Example, 2 Ed., ISBN: 0131882221X Hardening Linux, ISBN: 0072254971 Other books in production.