samba - Feb 2020 - Ldapsearch against Samba AD returns records outside the search base

Hello,

Ldbsearch returns the correct result. However this particular query is 
performed by an external system (that does not have access to the LDB 
files), to check whether a certain user belongs to a specific OU or not. 
The query is performed over LDAP against Samba, so it is not a 
ldapsearch-only problem. I only used ldapsearch to verify the behavior.

Regardless of if the query is wrong or not, I can't influence how this 
external system performs the query - the only things that can be changed 
are the search base and the attribute that contains the username. The 
problem here is that the results are not consistent. I was sure that 
this had worked correctly in the past, so I compiled Samba 4.9.4 from 
source and extracted an old backup copy of the Samba directory from last 
year: when the ldapsearch is run against Samba 4.9.4 it does NOT include 
results from outside the search base, but behaves exactly like the 
Windows DC:s.

Is it possible to configure the new (4.11.4->) Samba to behave like 
4.9.4 used to, because the current behavior is not consistent with the 
Windows DC:s and breaks this OU check? It is not apparent to me why the 
behavior has changed - surely the same criteria for uniqueness of the 
sAMAccountName etc have existed in 4.9.4, yet it chose to not return 
results outside the search base.

Regards,
-P

On 2020-01-31 17:08, Rowland penny via samba wrote:
> On 31/01/2020 13:50, Palle Kuling via samba wrote:
>> Hi,
>> 
>> I noticed the following problem with records returned outside the 
>> search base when the query is run against a Samba DC, but when the 
>> same query is run against a Windows 2008 or 2012 DC it does not 
>> happen. I'm pretty sure it worked correctly in the past. I updated 
>> from Samba 4.9.4 to 4.11.4 in December, but I noticed it only today, 
>> and I no longer have a backup of the old installation to verify. I 
>> tried building versions 4.11.5 and 4.11.6 against the same database, 
>> but they all behave in the same way. Am I missing some config option, 
>> or is it a bug? These kinds of queries are used to check if an account 
>> exists in a certain OU, so I would not want the DC:s to behave 
>> differently for the same query.
>> 
>> This is how it looks when I run a query (I redacted the domain and 
>> account names a bit):
>> 
>> ldapsearch -D username at internal.xxx.yy -w password -H
ldaps://<samba
>> DC> -s one -b ou=business,dc=internal,dc=xxx,dc=yy 
>> samaccountname=testadmin
>> # extended LDIF
>> #
>> # LDAPv3
>> # base <ou=business,dc=internal,dc=xxx,dc=yy> with scope oneLevel
>> # filter: samaccountname=testadmin
>> # requesting: ALL
>> #
>> 
>> # Test Admin, Test, internal.xxx.yy
>> dn: CN=Test Admin,OU=Test,DC=internal,DC=xxx,DC=yy
>> objectClass: top
>> objectClass: person
>> objectClass: organizationalPerson
>> objectClass: user
>> cn: Test Admin
>> <snip>
>> distinguishedName: CN=Test Admin,OU=Test,DC=internal,DC=xxx,DC=yy
>> 
>> # search result
>> search: 2
>> result: 0 Success
>> 
>> # numResponses: 2
>> # numEntries: 1
>> 
>> I would want results only from OU=Business, but the response comes 
>> from OU=Test. If I run the same query against one of the Windows DC:s, 
>> they return the answer I want (=no record):
>> 
>> ldapsearch -D username at internal.xxx.yy -w password -H
ldaps://<windows
>> DC> -s one -b ou=business,dc=internal,dc=xxx,dc=yy 
>> samaccountname=testadmin
>> # extended LDIF
>> #
>> # LDAPv3
>> # base <ou=business,dc=internal,dc=iceye,dc=fi> with scope
oneLevel
>> # filter: samaccountname=testadmin
>> # requesting: ALL
>> #
>> 
>> # search result
>> search: 2
>> result: 0 Success
>> 
>> # numResponses: 1
>> 
>> If the search base is replaced with -b 
>> ou=test,dc=internal,dc=xxx,dc=yy, both Samba and Windows return the 
>> same answer record. An ldapcmp between the Samba and Windows DC:s show 
>> no other differences than the Windows DC:s sometimes having more 
>> attributes listed (like WHENCREATED and INSTANCETYPE), but it was 
>> always like this. Also samba-tool drs showrepl shows no errors, so all 
>> DC:s should have the same data.
>> 
>> Regards,
>> -P
>> 
> Problem is, if you are searching on 'sAMAccountName', then you need
to
> search the entire directory, they must be unique.
> 
> Not saying that your search isn't returning the wrong result, just
> that you are doing an incorrect search. Also, does ldbsearch return a
> wrong result, if it doesn't, then it is an ldapsearch problem.
> 
> Rowland

On 01/02/2020 09:54, Palle Kuling via samba wrote:
> Hello,
>
> Ldbsearch returns the correct result. However this particular query is 
> performed by an external system (that does not have access to the LDB 
> files), to check whether a certain user belongs to a specific OU or 
> not. The query is performed over LDAP against Samba, so it is not a 
> ldapsearch-only problem. I only used ldapsearch to verify the behavior.
I beg to differ, if it works using ldbsearch, but doesn't work using 
ldapsearch, then it sounds like an ldapsearch problem
>
> Regardless of if the query is wrong or not, I can't influence how this 
> external system performs the query - the only things that can be 
> changed are the search base and the attribute that contains the 
> username. The problem here is that the results are not consistent. I 
> was sure that this had worked correctly in the past, so I compiled 
> Samba 4.9.4 from source and extracted an old backup copy of the Samba 
> directory from last year: when the ldapsearch is run against Samba 
> 4.9.4 it does NOT include results from outside the search base, but 
> behaves exactly like the Windows DC:s.
It doesn't matter whether this worked in the past or not, your search 
filter is wrong, I would expect something like this:

"(&(objectCategory=person)(objectClass=user)(sAMAccountName=$USER))"

You also need to search the entire directory, you cannot have a user 
with the samaccountname 'fred' in one OU and another user with the 
samaccountname 'fred' in another OU, samaccountnames must be unique.
>
> Is it possible to configure the new (4.11.4->) Samba to behave like 
> 4.9.4 used to, because the current behavior is not consistent with the 
> Windows DC:s and breaks this OU check? It is not apparent to me why 
> the behavior has changed - surely the same criteria for uniqueness of 
> the sAMAccountName etc have existed in 4.9.4, yet it chose to not 
> return results outside the search base.
>
If it did work before and allowed you to create the same samaccountname 
in different OU's, then this was incorrect, If it has been fixed, then I 
do not see it being unfixed ;-)

Rowland

Hello,

Is it not Samba that is listening to the LDAP ports and is serving me 
the answer to my query? This problem does not only happen when the LDAP 
database is searched using ldapsearch, it happens also using other tools 
that connect to the LDAP ports. I still don't fully grasp what this has 
to do with the uniqueness of the sAMAccountNames - they are unique 
throughout my directory and I don't expect them to be otherwise. I also 
don't get why it is fine for the LDAP port to respond to queries in a 
different manner than ldbsearch? Ldbsearch honors the basedn, but the 
LDAP port does not. Furthermore, it seems that this is not only attached 
to the sAMAccountName. The exact same problem happens if I search for 
userPrincipalName.

The AD domain Samba servers in this case is internal.xxx.yy. Users are 
sorted into different organizational units. In the directory these are 
for example OU=Business,DC=internal,DC=xxx,DC=yy and 
OU=Test,DC=internal,DC=xxx,DC=yy. There is an external system, that uses 
this database to check whether an user belongs to a certain OU, by 
searching for sAMAccountName with a base DN of the OU to be tested. If 
the user is in that OU, the LDAP search is expected to return the user 
DN, otherwise the search would not return anything. This is how it 
worked in the past. When the query is run against the new Samba DC, it 
returns user DN:s from other OU:s that are on the same level to the 
search base, but not equal to the search base. I'm fine with the search 
being "performed" on the entire directory and the uniqueness of any 
parameter being verified, but I simply don't want any responses from 
outside the search base regardless of if they exist or not. Are you 
telling me that this new behavior is expected? In that case, it means we 
cannot use the external system to verify whether an user belongs to a 
particular OU in this manner anymore. If this behavior is the result of 
something being fixed, could you maybe point me to the exact fix that 
changed this behavior?

Using the filter you suggest does not change anything. See the various 
results below;

Queried against Samba 4.11.4 (query is for OU=Business but response is 
from OU=Test):
$ldapsearch -D username at internal.xxx.yy -w password -H 
ldaps://192.168.1.1 -s one -b ou=business,dc=internal,dc=xxx,dc=yy 
"(&(objectCategory=person)(objectClass=user)(sAMAccountName=testadmin))"
# extended LDIF
#
# LDAPv3
# base <ou=business,dc=internal,dc=xxx,dc=yy> with scope oneLevel
# filter: 
(&(objectCategory=person)(objectClass=user)(sAMAccountName=testadmin))
# requesting: ALL
#

# Test Admin, Test, internal.xxx.yy
dn: CN=Test Admin,OU=Test,DC=internal,DC=xxx,DC=yy
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
<snip>
distinguishedName: CN=Test Admin,OU=Test,DC=internal,DC=xxx,DC=yy

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Queried against Samba 4.9.4 (the response from OU=Test is not returned 
in this case):
~/samba-4.9.4$ ldapsearch -D username at internal.xxx.yy -w password -H 
ldaps://192.168.1.1 -s one -b ou=business,dc=internal,dc=xxx,dc=yy 
"(&(objectCategory=person)(objectClass=user)(sAMAccountName=testadmin))"
# extended LDIF
#
# LDAPv3
# base <ou=business,dc=internal,dc=xxx,dc=yy> with scope oneLevel
# filter: 
(&(objectCategory=person)(objectClass=user)(sAMAccountName=testadmin))
# requesting: ALL
#

# search result
search: 2
result: 0 Success

# numResponses: 1

Queried from the external system against Samba 4.11.4:
[560] Creating LDAP context with uri=ldaps://192.168.1.1:636
[560] Connect to LDAP server: ldaps://192.168.1.1:636, status = 
Successful
[560] supportedLDAPVersion: value = 2
[560] supportedLDAPVersion: value = 3
[560] Binding as username at internal.xxx.yy
[560] Performing Simple authentication for username at internal.xxx.yy to 
192.168.1.1
[560] LDAP Search:
	Base DN = [ou=Business,dc=internal,dc=xxx,dc=yy]
	Filter  = [sAMAccountName=testadmin]
	Scope   = [ONE LEVEL]
[560] User DN = [CN=Test Admin,OU=Test,DC=internal,DC=xxx,DC=yy] <--- 
This User DN was not returned in the past

And for completeness, these are the ldbsearches against Samba 4.11.4 
database, which honor the base:
/usr/local/samba/private/sam.ldb.d# ldbsearch -H 
DC=INTERNAL,DC=XXX,DC=YY.ldb -b ou=business,dc=internal,dc=xxx,dc=yy 
'samaccountname=testadmin'
# returned 0 records
# 0 entries
# 0 referrals
/usr/local/samba/private/sam.ldb.d# ldbsearch -H 
DC=INTERNAL,DC=XXX,DC=YY.ldb -b ou=test,dc=internal,dc=xxx,dc=yy 
'samaccountname=testadmin'
# record 1
dn: CN=Test Admin,OU=Test,DC=internal,DC=xxx,DC=yy

Regards,
-P



On 2020-02-01 14:05, Rowland penny via samba wrote:
> On 01/02/2020 09:54, Palle Kuling via samba wrote:
>> Hello,
>> 
>> Ldbsearch returns the correct result. However this particular query is 
>> performed by an external system (that does not have access to the LDB 
>> files), to check whether a certain user belongs to a specific OU or 
>> not. The query is performed over LDAP against Samba, so it is not a 
>> ldapsearch-only problem. I only used ldapsearch to verify the 
>> behavior.
> I beg to differ, if it works using ldbsearch, but doesn't work using
> ldapsearch, then it sounds like an ldapsearch problem
>> 
>> Regardless of if the query is wrong or not, I can't influence how
this
>> external system performs the query - the only things that can be 
>> changed are the search base and the attribute that contains the 
>> username. The problem here is that the results are not consistent. I 
>> was sure that this had worked correctly in the past, so I compiled 
>> Samba 4.9.4 from source and extracted an old backup copy of the Samba 
>> directory from last year: when the ldapsearch is run against Samba 
>> 4.9.4 it does NOT include results from outside the search base, but 
>> behaves exactly like the Windows DC:s.
> 
> It doesn't matter whether this worked in the past or not, your search
> filter is wrong, I would expect something like this:
> 
>
"(&(objectCategory=person)(objectClass=user)(sAMAccountName=$USER))"
> 
> You also need to search the entire directory, you cannot have a user
> with the samaccountname 'fred' in one OU and another user with the
> samaccountname 'fred' in another OU, samaccountnames must be
unique.
> 
>> 
>> Is it possible to configure the new (4.11.4->) Samba to behave like 
>> 4.9.4 used to, because the current behavior is not consistent with the 
>> Windows DC:s and breaks this OU check? It is not apparent to me why 
>> the behavior has changed - surely the same criteria for uniqueness of 
>> the sAMAccountName etc have existed in 4.9.4, yet it chose to not 
>> return results outside the search base.
>> 
> If it did work before and allowed you to create the same
> samaccountname in different OU's, then this was incorrect, If it has
> been fixed, then I do not see it being unfixed ;-)
> 
> Rowland