[Samba] Ldapsearch against Samba AD returns records outside the search base

Sat Feb 1 16:29:26 UTC 2020

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