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.
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
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
Created attachment 10912 [details] Work in progress patches (the test still fail...) Here's my current work in progress...
(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.
(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?
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;
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>
(In reply to schnaggy from comment #7) Yes, this is fixed in 4.3.*