Balabit - ldapsearch tests against Active Directory
Balabit SCB Solution · Config document · referenced from Active Directory and access control
note
<SCB_SVC_PASSWORD> replaces the bind password that my notes held in clear text on the first line; do not pass a password with -w on a command line. Several of these commands are broken as written (a typo in the bind DN, a missing quote, a filter in place of the base DN); they are kept as they are and explained below. The notes record no output, only the labels "OK1" and "OK2".The ldapsearch commands with which I checked, before and while configuring the appliance, that the service account scb_svc could bind to the first domain controller, that the user OU could be read, and how nested group membership could be resolved with Active Directory's in-chain matching rule.
| Item | Value |
|---|---|
| Run as | root (the notes show the # prompt) on a Linux host with the OpenLDAP client; the notes do not name the host |
| Against | The first domain controller dc1-a-vcad001, 10.11.16.209, on the LDAP port 389 (-h without -p or -H), with StartTLS (-Z) on some lines and without it on others |
| Bind | CN=scb_svc,OU=USERS_SVC,DC=ad,DC=example,DC=net, password typed at the prompt (-W) except on the first line |
| Source | My working notes, the ldapsearch block, undated; the order is the order in the notes |
| Output | Not recorded |
The commands
All eight commands as they stand in the notes, each run on its own.
$ ldapsearch -b OU=USERS_STD,DC=ad,DC=example,DC=net -D CN=sbc_svc,OU=USERS_SVC,DC=ad,DC=example,DC=net -h 10.11.16.209 -Z -w <SCB_SVC_PASSWORD> $ ldapsearch -b OU=USERS_STD,DC=ad,DC=example,DC=net -D CN=scb_svc,OU=USERS_SVC,DC=ad,DC=example,DC=net -h 10.11.16.209 -Z -W -s sub "(objectclass=*) $ ldapsearch -b (member:1.2.840.113556.1.4.1941:=(OU=USERS_STD,DC=ad,DC=example,DC=net)) -D CN=scb_svc,OU=USERS_SVC,DC=ad,DC=example,DC=net -h 10.11.16.209 -Z -W $ ldapsearch -b OU=USERS_STD,DC=ad,DC=example,DC=net -D CN=scb_svc,OU=USERS_SVC,DC=ad,DC=example,DC=net -h 10.11.16.209 -Z -W $ ldapsearch -b "OU=USERS_STD,DC=ad,DC=example,DC=net" -D "CN=scb_svc,OU=USERS_SVC,DC=ad,DC=example,DC=net" -h 10.11.16.209 -W -x "(memberOf:1.2.840.113556.1.4.1941:=cn=admin01,OU=USERS_STD,DC=ad,DC=example,DC=net)" cn $ ldapsearch -b "OU=RBAC_ROLES,OU=RBAC,DC=ad,DC=example,DC=net" -D "CN=scb_svc,OU=USERS_SVC,DC=ad,DC=example,DC=net" -h 10.11.16.209 -W -x "(memberOf:1.2.840.113556.1.4.1941:=cn=admin01,OU=USERS_STD,DC=ad,DC=example,DC=net)" cn $ ldapsearch -b "OU=RBAC_ROLES,OU=RBAC,DC=ad,DC=example,DC=net" -D "CN=scb_svc,OU=USERS_SVC,DC=ad,DC=example,DC=net" -h 10.11.16.209 -W -x "(memberOf:1.2.840.113556.1.4.1941:=cn=admin01,OU=RBAC_ROLES,OU=RBAC,DC=ad,DC=example,DC=net)" cn $ ldapsearch -b OU=RBAC_ROLES,OU=RBAC,DC=ad,DC=example,DC=net -D CN=scb_svc,OU=USERS_SVC,DC=ad,DC=example,DC=net -h 10.11.16.209 -Z -W
| Line | What it does, and what is wrong with it |
|---|---|
| 1 | Reads the user OU OU=USERS_STD with StartTLS. The bind DN says sbc_svc instead of scb_svc, so this bind cannot have succeeded as written. The password is given on the command line with -w |
| 2 | The same with the right account, password at the prompt and the filter (objectclass=*) over the whole subtree. The closing quote of the filter is missing, so the shell waits for more input |
| 3 | An attempt at the in-chain rule: member:1.2.840.113556.1.4.1941:= asks for the objects that have the given object among their members, directly or through nested groups. It is written as the base DN (-b) instead of the filter, with brackets around an OU, which is not a member of anything, and the brackets are not quoted; an unquoted bracket is a syntax error in bash, so as written the line would not have run. In the notes two example filters copied from elsewhere follow it, one with member: and one with memberOf: and the same rule |
| 4, labelled OK1 | Line 2 without the broken filter: bind as scb_svc with StartTLS, read OU=USERS_STD. The notes mark this one OK. It has no -x; as I understand the OpenLDAP client, that means a SASL bind rather than a simple bind, and the notes do not show how it got through |
| 5, labelled OK2 | Simple bind (-x), no StartTLS, base OU=USERS_STD, filter (memberOf:1.2.840.113556.1.4.1941:=cn=admin01,OU=USERS_STD,…), return only cn. This asks for the objects that are, directly or nested, members of admin01. admin01 is a user and has no members, so as I understand the rule the answer is empty; "OK" can only mean that the command ran |
| 6 | The same filter with the base OU=RBAC_ROLES, where the role groups live: still the members of the user admin01, so still nothing to find |
| 7 | The same with admin01 placed in OU=RBAC_ROLES, where no user account is. The # prompt is missing on this line in the notes |
| 8 | Lists OU=RBAC_ROLES with StartTLS, without a filter: the role groups SCB_ADM, SCB_OPS, SCB_USERS_* themselves |
The question I was trying to answer, "which role groups is this user in, through nesting", needs the rule the other way round: member:1.2.840.113556.1.4.1941:= followed by the user's DN, with OU=RBAC_ROLES as the base, which is what line 3 aimed at. None of the commands in the notes has that form. None of them used LDAPS on port 636 either, which is what the appliance itself uses (AAA (site 1)); and lines 5 to 7 sent the password of the service account over the network without encryption, because -x without -Z is a simple bind in clear text.
Checked against OpenLDAP 2.7 and the Active Directory documentation
| As built | Today |
|---|---|
-h 10.11.16.209 | OpenLDAP 2.6.4 (2023) removed the -h and -p options from the client tools; the server is given as a URI with -H, for example ldaps:// on 636 or ldap:// with -ZZ |
-Z | Still requests StartTLS; only -ZZ makes the command fail if StartTLS does not succeed |
1.2.840.113556.1.4.1941 | Still documented by Microsoft as LDAP_MATCHING_RULE_IN_CHAIN, which "walks the chain of ancestry in objects all the way to the root"; the scope is not limited and queries with a high fan-out can be processor intensive |
None of the eight lines runs unchanged with a current ldapsearch, because of -h. Rewritten with -H and -ZZ, the StartTLS tests would also stop silently falling back to clear text.