Matt Johnson
2005-Oct-31 11:40 UTC
[Samba] Samba 3.0.20b in ADS mode with MIT realm trust problems
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>
Junior Systems Programmer
Computing Support Group
"Computers are the most intelligent idiots there are."
- Norman Teller
Matt Johnson
2005-Nov-07 09:48 UTC
[Samba] Samba 3.0.20b in ADS mode with MIT realm trust problems
Anyone? We've made no progress on this since the original email, unfortunately... 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>