Bug 11130 - KDC TGS not finding principal
KDC TGS not finding principal
Status: RESOLVED FIXED
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Other
4.1.16
x64 Other
: P5 major
: 4.3
Assigned To: Andrew Bartlett
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-03-03 15:16 UTC by Izan Díez Sánchez
Modified: 2015-10-06 08:01 UTC (History)
2 users (show)

See Also:


Attachments
Work in progress patches (the test still fail...) (5.84 KB, patch)
2015-03-26 10:32 UTC, Stefan Metzmacher
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Izan Díez Sánchez 2015-03-03 15:16:45 UTC
Trying to connect to a database server from a client W7 to a server W2008 the samba is not able to grant service

-----------------------------------
[2015/03/02 19:57:03.794542,  3, pid=6266, effective(0, 0), real(0, 0)] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: TGS-REQ ids@DOMAIN.AD from ipv4:192.168.0.100:49276 for DATABASE_SERVER@DOMAIN.AD [canonicalize, renewable, forwardable]
[2015/03/02 19:57:03.794633, 10, pid=6266, effective(0, 0), real(0, 0), class=ldb] ../lib/ldb-samba/ldb_wrap.c:71(ldb_wrap_debug)
  ldb: ldb_trace_request: SEARCH
   dn: DC=domain,DC=ad
   scope: sub
   expr: (&(objectClass=user)(samAccountName=DATABASE_SERVER))
   attr: objectClass
   attr: sAMAccountName
   attr: userPrincipalName
   attr: servicePrincipalName
   attr: msDS-KeyVersionNumber
   attr: msDS-SecondaryKrbTgtNumber
   attr: msDS-SupportedEncryptionTypes
   attr: supplementalCredentials
   attr: msDS-AllowedToDelegateTo
   attr: dBCSPwd
   attr: unicodePwd
   attr: userAccountControl
   attr: objectSid
   attr: pwdLastSet
   attr: accountExpires
   control: 1.3.6.1.4.1.7165.4.3.17  crit:0  data:no
   control: 1.2.840.113556.1.4.529  crit:1  data:yes
 
[2015/03/02 19:57:03.794895, 10, pid=6266, effective(0, 0), real(0, 0), class=ldb] ../lib/ldb-samba/ldb_wrap.c:71(ldb_wrap_debug)
  ldb: ldb_trace_request: (resolve_oids)->search
[2015/03/02 19:57:03.794938, 10, pid=6266, effective(0, 0), real(0, 0), class=ldb] ../lib/ldb-samba/ldb_wrap.c:71(ldb_wrap_debug)
  ldb: ldb_trace_next_request: (rootdse)->search
[2015/03/02 19:57:03.794993, 10, pid=6266, effective(0, 0), real(0, 0), class=ldb] ../lib/ldb-samba/ldb_wrap.c:71(ldb_wrap_debug)
  ldb: ldb_trace_next_request: (schema_load)->search
[2015/03/02 19:57:03.795032, 10, pid=6266, effective(0, 0), real(0, 0), class=ldb] ../lib/ldb-samba/ldb_wrap.c:71(ldb_wrap_debug)
  ldb: ldb_trace_next_request: (lazy_commit)->search
[2015/03/02 19:57:03.795068, 10, pid=6266, effective(0, 0), real(0, 0), class=ldb] ../lib/ldb-samba/ldb_wrap.c:71(ldb_wrap_debug)
  ldb: ldb_trace_next_request: (dirsync)->search
[2015/03/02 19:57:03.795110, 10, pid=6266, effective(0, 0), real(0, 0), class=ldb] ../lib/ldb-samba/ldb_wrap.c:71(ldb_wrap_debug)
  ldb: ldb_trace_next_request: (paged_results)->search
[2015/03/02 19:57:03.795145, 10, pid=6266, effective(0, 0), real(0, 0), class=ldb] ../lib/ldb-samba/ldb_wrap.c:71(ldb_wrap_debug)
  ldb: ldb_trace_next_request: (ranged_results)->search
[2015/03/02 19:57:03.795184, 10, pid=6266, effective(0, 0), real(0, 0), class=ldb] ../lib/ldb-samba/ldb_wrap.c:71(ldb_wrap_debug)
  ldb: ldb_trace_next_request: (anr)->search
[2015/03/02 19:57:03.795220, 10, pid=6266, effective(0, 0), real(0, 0), class=ldb] ../lib/ldb-samba/ldb_wrap.c:71(ldb_wrap_debug)
  ldb: ldb_trace_next_request: (server_sort)->search
[2015/03/02 19:57:03.795255, 10, pid=6266, effective(0, 0), real(0, 0), class=ldb] ../lib/ldb-samba/ldb_wrap.c:71(ldb_wrap_debug)
  ldb: ldb_trace_next_request: (asq)->search
[2015/03/02 19:57:03.795289, 10, pid=6266, effective(0, 0), real(0, 0), class=ldb] ../lib/ldb-samba/ldb_wrap.c:71(ldb_wrap_debug)
  ldb: ldb_trace_next_request: (extended_dn_in)->search
[2015/03/02 19:57:03.795332, 10, pid=6266, effective(0, 0), real(0, 0), class=ldb] ../lib/ldb-samba/ldb_wrap.c:71(ldb_wrap_debug)
  ldb: ldb_trace_next_request: (descriptor)->search
[2015/03/02 19:57:03.795370, 10, pid=6266, effective(0, 0), real(0, 0), class=ldb] ../lib/ldb-samba/ldb_wrap.c:71(ldb_wrap_debug)
  ldb: ldb_trace_next_request: (acl)->search
[2015/03/02 19:57:03.795415, 10, pid=6266, effective(0, 0), real(0, 0), class=ldb] ../lib/ldb-samba/ldb_wrap.c:71(ldb_wrap_debug)
  ldb: ldb_trace_next_request: (aclread)->search
[2015/03/02 19:57:03.795452, 10, pid=6266, effective(0, 0), real(0, 0), class=ldb] ../lib/ldb-samba/ldb_wrap.c:71(ldb_wrap_debug)
  ldb: ldb_trace_next_request: (operational)->search
[2015/03/02 19:57:03.795503, 10, pid=6266, effective(0, 0), real(0, 0), class=ldb] ../lib/ldb-samba/ldb_wrap.c:71(ldb_wrap_debug)
  ldb: ldb_trace_next_request: (rdn_name)->search
[2015/03/02 19:57:03.795540, 10, pid=6266, effective(0, 0), real(0, 0), class=ldb] ../lib/ldb-samba/ldb_wrap.c:71(ldb_wrap_debug)
  ldb: ldb_trace_next_request: (extended_dn_out_ldb)->search
[2015/03/02 19:57:03.795589, 10, pid=6266, effective(0, 0), real(0, 0), class=ldb] ../lib/ldb-samba/ldb_wrap.c:71(ldb_wrap_debug)
  ldb: ldb_trace_next_request: (show_deleted)->search
[2015/03/02 19:57:03.795629, 10, pid=6266, effective(0, 0), real(0, 0), class=ldb] ../lib/ldb-samba/ldb_wrap.c:71(ldb_wrap_debug)
  ldb: ldb_trace_next_request: (partition)->search
[2015/03/02 19:57:03.795679, 10, pid=6266, effective(0, 0), real(0, 0), class=ldb] ../lib/ldb-samba/ldb_wrap.c:71(ldb_wrap_debug)
  ldb: partition_request() -> (metadata partition)
[2015/03/02 19:57:03.795716, 10, pid=6266, effective(0, 0), real(0, 0), class=ldb] ../lib/ldb-samba/ldb_wrap.c:71(ldb_wrap_debug)
  ldb: ldb_trace_next_request: (tdb)->search
[2015/03/02 19:57:03.797351, 10, pid=6266, effective(0, 0), real(0, 0), class=ldb] ../lib/ldb-samba/ldb_wrap.c:71(ldb_wrap_debug)
  ldb: ldb_trace_response: REFERRAL
  ref: ldap://domain.ad/CN=Configuration,DC=domain,DC=ad
 
[2015/03/02 19:57:03.797428, 10, pid=6266, effective(0, 0), real(0, 0), class=ldb] ../lib/ldb-samba/ldb_wrap.c:71(ldb_wrap_debug)
  ldb: ldb_trace_response: DONE
  error: 0
 
[2015/03/02 19:57:03.797497,  3, pid=6266, effective(0, 0), real(0, 0)] ../source4/kdc/db-glue.c:1389(samba_kdc_lookup_server)
  Failed to find an entry for DATABASE_SERVER
[2015/03/02 19:57:03.797542,  3, pid=6266, effective(0, 0), real(0, 0)] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: Searching referral for DATABASE_SERVER
[2015/03/02 19:57:03.797595,  3, pid=6266, effective(0, 0), real(0, 0)] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: Server not found in database: DATABASE_SERVER@DOMAIN.AD: No such entry in the database
[2015/03/02 19:57:03.797637,  3, pid=6266, effective(0, 0), real(0, 0)] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: Failed building TGS-REP to ipv4:172.31.0.122:49276
[2015/03/02 19:57:03.797891,  3, pid=6266, effective(0, 0), real(0, 0)] ../source4/smbd/service_stream.c:66(stream_terminate_connection)
  Terminating connection - 'kdc_tcp_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED'
-----------------------------------

I think the bug is in the samba_kdc_lookup_server function of the db-glue.c and the way it issues the query to find the principal.
Comment 1 Izan Díez Sánchez 2015-03-05 16:20:22 UTC
From: https://lists.samba.org/archive/samba/2015-March/189795.html

On 05/03/15 15:23, Izan DíezSánchez wrote:
>
>
> schnaggy <schnaggy <at> schnaggy.de> writes:
>
>>
>>> On 05 Mar 2015, at 10:45, Rowland Penny <rowlandpenny <at>
> googlemail.com> wrote:
>>> On 03/03/15 09:56, Izan Díez Sánchez wrote:
>>>> Hi again. I apologize for my vague previous question. After some
> investigation I can be much more precise
>> in my consult. Furthermore, I think I found a bug…
>>>> ...
>>>>
>>>> User "ids" is requesting a ticket to connect to the
> "DATABASE_SERVER". In the process samba makes an
>> ldbsearch looking for the server but does not find it. Why? Because
> the sAMAccountName that is searching
>> lacks the trailing dollar "$" that every machine account has.
>>>> Is this a bug? Any idea on how can I workaround this issue?
>>>> We have a production environment with Windows DC working and
> planned to migrate to samba4 but need
>> everything working flawlessly.
>>>>
>>>>
>>> No, I don't think this is a bug, I think it is a mis-configuration
> of *oracle*.
>>> If authentication works by removing the '$' sign from the computers
> samacountname, then there is your
>> problem, oracle doesn't expect the '$' sign but it should because
> *every* AD computer samaccountname
>> ends with a '$' sign.
>>> So, to put it another way, this is not a samba problem, it is an
> oracle problem, try searching the internet
>> with something like 'oracle windows authentication nts’
>> Yes, you are right. It’s not a samba problem if the oracle client
> tries to authenticate with a machine
>> account name and stripping the $-sign. My fault. I’m gonna try some
> metawork searches. Maybe there will
>> be any hints...
>>
>> BTW: we use a win 8.1pro with a local oracle server installation, not
> win7 and a remote oracle on a win 2008 server
>> schnaggy
>>
>>> Rowland
>>> -- 
>>> To unsubscribe from this list go to the following URL and read the
>>> instructions:  https://lists.samba.org/mailman/options/samba
>> Carsten Wagner
>>
>> schnaggy <at> schnaggy.de
>>
> Thanks schnaggy ;) I had also tested the local setup and your
> workaround, but breaking another thing to fix this is not a solution.
>
> Rowland, how is it an oracle client problem if it works out of the box
> in a Windows Active Directory?

No body said it worked against a windows AD DC and as someone else 
posted a work around, it was too easy to say it wasn't a bug, but now 
that you say it works with windows, then yes it does sound like a bug 
and your best course would be file a bug report.

> I finally dug a bit into the code and found the line in which the
> unsuccessful query is performed:
>
> If in the samba_kdc_lookup_server function of the db-glue.c change the
> following piece of code:
> ----------------------------------------------
>
> 		lret = dsdb_search_one(kdc_db_ctx->samdb, mem_ctx, msg,
> 				       *realm_dn, LDB_SCOPE_SUBTREE,
> 				       attrs,
> 				       DSDB_SEARCH_SHOW_EXTENDED_DN |
> DSDB_SEARCH_NO_GLOBAL_CATALOG,
> 				       "(&(objectClass=user)
> (samAccountName=%s))",
> 				       ldb_binary_encode_string(mem_ctx,
> short_princ));
> ----------------------------------------------
> by
> ----------------------------------------------
> 		lret = dsdb_search_one(kdc_db_ctx->samdb, mem_ctx, msg,
> 				       *realm_dn, LDB_SCOPE_SUBTREE,
> 				       attrs,
> 				       DSDB_SEARCH_SHOW_EXTENDED_DN |
> DSDB_SEARCH_NO_GLOBAL_CATALOG,
> 				       "(&(objectClass=user)
> (samAccountName=%s$))",
> 				       ldb_binary_encode_string(mem_ctx,
> short_princ));
> ----------------------------------------------
> Note the dollar sign. Recompiled and get it working as expected.
>
> Problem here: I don't know how it will impact the normal functioning of
> kerberos. However, so far, I have not been able to notice any error. In
> any case I am not willing to trust this hack for a production
> environment and I need some help of people with understanding of why
> that line of code is written in that way and not the other.

I personally would have changed the search filter to this:

"(&(objectClass=user)(|(samAccountName=%s)(cn=%s)))",

With this filter, you would get the same result as previously, but it 
would also find machines if 'cn' is matched.

However, I am no expert in kerberos and there are probably valid reasons 
why the search filter is the way it is, so I would urge you to file a 
bug report on this.

Rowland

> I hope we can reach a solution. Thank you for your time,
>
> \\Izan
Comment 2 Andrew Bartlett 2015-03-10 00:11:18 UTC
To progress with this, we need to have this re-tested against git master, and then a patch added to the torture/krb5/kdc-canon.c that checks this particular combination. 

I also have requests outstanding with the dochelp team at Microsoft requesting a full and complete description of what names are valid and what attributes are used
Comment 3 Stefan Metzmacher 2015-03-26 10:32:13 UTC
Created attachment 10912 [details]
Work in progress patches (the test still fail...)

Here's my current work in progress...
Comment 4 Stefan Metzmacher 2015-03-26 10:36:56 UTC
(In reply to Izan Díez Sánchez from comment #1)

> "(&(objectClass=user)(|(samAccountName=%s)(cn=%s)))",

This is wrong I've tested it against windows,
it's really:

"(&(objectClass=user)(|(samAccountName=%s)(samAccountName=%s$)))"

And we should only allow this we get a unique result.
Comment 5 Izan Díez Sánchez 2015-03-26 15:26:39 UTC
(In reply to Stefan (metze) Metzmacher from comment #3)
One thing that I don't understand. What test is failing, the one you created? Isn't the patch covering what you tested on Windows?
Comment 6 schnaggy 2015-04-17 09:21:23 UTC
Patch patched:

diff --git a/source4/kdc/db-glue.c b/source4/kdc/db-glue.c
index 72985a7..5525984 100644
--- a/source4/kdc/db-glue.c
+++ b/source4/kdc/db-glue.c
@@ -1702,7 +1702,7 @@
 		len1 = strlen(name1);
 		if (len1 >= 1 && name1[len1 - 1] != '$') {
 			filter = talloc_asprintf(mem_ctx,
-					"(&(objectClass=user)(|(samAccountName=%s)(samAccountName=%s$))",
+					"(&(objectClass=user)(|(samAccountName=%s)(samAccountName=%s$)))",
 					name1, name1);
 			if (filter == NULL) {
 				return ENOMEM;
Comment 7 schnaggy 2015-10-06 07:20:43 UTC
Seems to be fixed in Commit 61de10240e26f6edf4961841206347d0652c40d9

s4:kdc/db-glue: allow principals in form of computer@EXAMPLE.COM

This should be translated to computer$@EXAMPLE.COM.

Note the behavior differs between client and server lookup.
In samba_kdc_lookup_client() we need to fallback in case of
NO_SUCH_USER. samba_kdc_lookup_server() needs to do a single search
and only use the result if it's unique.

Bug: https://bugzilla.samba.org/show_bug.cgi?id=11130

Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Comment 8 Stefan Metzmacher 2015-10-06 08:01:32 UTC
(In reply to schnaggy from comment #7)

Yes, this is fixed in 4.3.*