[Samba] ADS mode / MIT realm trust problem (3.0.20b)

Matt Johnson mwj at doc.ic.ac.uk
Wed Nov 23 22:39:22 GMT 2005


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 at 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 at 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 at DOC.IC.AC.UK]
>  [2005/10/31 11:00:57, 3] smbd/sesssetup.c:reply_spnego_kerberos(192)
>    Ticket for foreign realm mwj at 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 at doc.ic.ac.uk>


More information about the samba mailing list