Some product using LDAP/ADS authentication use queries with base dn containing whitespace after the separating comma. Example ------- Domain : test.dom Base DN : dc=test, dc=dom (notice the whitespace after the comma) ldapsearch -a always -h [SambaIP] -D "Administrator@test.dom" -W -b "dc=test, dc=dom" -s sub "(objectClass=domain)" No Result With ADS & OpenLdap this kind of query works.
The same apply for some product or bad query where '\r\n' are added to the end of the basedn. Example for a query captured with pcap where response from samba was nosuchObject : (CN ... has been modified to remove some important information) Query : -------------------------------------------------- Frame 646: 221 bytes on wire (1768 bits), 221 bytes captured (1768 bits) on interface 0 Ethernet II, Src: TyanComp_db:eb:64 (00:e0:81:db:eb:64), Dst: TyanComp_dc:3d:41 (00:e0:81:dc:3d:41) Internet Protocol Version 4, Src: 192.168.0.211, Dst: 192.168.0.201 Transmission Control Protocol, Src Port: 61476, Dst Port: 3268, Seq: 265, Ack: 2163, Len: 167 Lightweight Directory Access Protocol LDAPMessage searchRequest(4) "CN=EJE,OU=MALR,OU=MAE,OU=CIAS,DC=domain,DC=loc " baseObject messageID: 4 protocolOp: searchRequest (3) searchRequest baseObject: CN=EJE,OU=MALR,OU=MAE,OU=CIAS,DC=domain,DC=loc\r\n scope: baseObject (0) derefAliases: neverDerefAliases (0) sizeLimit: 0 timeLimit: 0 typesOnly: False Filter: (objectclass=*) filter: present (7) present: objectclass attributes: 0 items [Response In: 647] Response : -------------------------------------------------- Frame 647: 169 bytes on wire (1352 bits), 169 bytes captured (1352 bits) on interface 0 Ethernet II, Src: TyanComp_dc:3d:41 (00:e0:81:dc:3d:41), Dst: TyanComp_db:eb:64 (00:e0:81:db:eb:64) Internet Protocol Version 4, Src: 192.168.0.201, Dst: 192.168.0.211 Transmission Control Protocol, Src Port: 3268, Dst Port: 61476, Seq: 2163, Ack: 432, Len: 115 Lightweight Directory Access Protocol LDAPMessage searchResDone(4) noSuchObject (acl_read: Error retrieving instanceType for base. at ../source4/dsdb/samdb/ldb_modules/acl_read.c:784) [2 results] messageID: 4 protocolOp: searchResDone (5) searchResDone resultCode: noSuchObject (32) matchedDN: errorMessage: acl_read: Error retrieving instanceType for base. at ../source4/dsdb/samdb/ldb_modules/acl_read.c:784 [Response To: 646] [Time: 0.000517000 seconds] The same query against a windows AD, does not return error the ldap auth/search work
Please note that, for at least samba 4.10, white space after or before comma and at the end of base search are correctly ignored/remove. But \r\n are not removed. (In the example, \r\n is after DC=loc) Example of a working query against 2008R2 AD : ldapsearch -a always -h 192.168.0.53 -D "administrateur@domaine.loc" -W -b "OU=Informatique,DC=domaine,DC=loc " -s sub "(objectClass=user)" Result : # search result search: 2 result: 0 Success # numResponses: 10 # numEntries: 9 The same against samba 4.10.5 : Result : # search result search: 2 result: 32 No such object text: acl_read: Error retrieving instanceType for base. at ../../source4/dsdb/s amdb/ldb_modules/acl_read.c:759 Can someone make a simple patch to remove this offending characters at the end of the query ? I did try some code editing, but got always a crash of samba when query is used.
Created attachment 15288 [details] Temp Fix for CRLF in DN Temporary fix to trim CR LF (\r or \n) for DN. This is based on trim for whitespace in function ldb_dn_explode and if we are "in_value"
With the attachment, samba 4.10.5 is currently running and no crash for now. LDAP Query in comment #1 and #2 are now resolved. Can someone review this simple patch to make sure everything should be OK ?
Created attachment 15760 [details] Temp Fix for CRLF in DN - samba 4.11
Romain, thanks for the capture descriptions. Is there some product that is generating these packets? Are linebreaks in the middle of DNs (after/before a comma) treated the same way by Windows? In this matter I think we we match RFC 4514, but not the older RFC 2253 (which the Microsoft docs reference), which says: Implementations MUST allow a semicolon character to be used instead of a comma to separate RDNs in a distinguished name, and MUST also allow whitespace characters to be present on either side of the comma or semicolon. The whitespace characters are ignored, and the semicolon replaced with a comma.
> Is there some product that is generating these packets? Yes, an professional application using Windev. > Are linebreaks in the middle of DNs (after/before a comma) treated the same way by Windows? Yes, Windows is treating the DN as expected. For memory, I did use Windows and Samba to understand why the application did not work with Samba but was OK with Windows. As of writing, samba 4.12 & 4.13 are OK with this patch.
Samba 4.14 is OK with this patch.