ldapsearch tool "--control" argument does not work

[suryad]

Test 1: Password policy control with --control option does not work ldapsearch -T -h hostname -p 1636 -Z --control 1.3.6.1.4.1.42.2.27.8.5.1:false -D "userdn" -w wrong-password -b "dc=example,dc=com" "(uid=jdoe)" uid

Bind Result:

Result Code: 49 (invalid credentials)

Diagnostic Message: Reason: 52e - Invalid credentials

An error occurred while attempting to create a connection pool to communicate with the directory server: LDAPException(resultCode=49 (invalid credentials), diagnosticMessage='Reason: 52e - Invalid credentials', ldapSDKVersion=6.0.7, revision=76bbe43ece90ad78306ba2e5c349f33f0bf13fde)

Test 1: Password policy control with --usePasswordpolicycontrol option works as expected ldapsearch -T -h hostname -p 1636 -Z --usePasswordpolicycontrol -D "userdn" -w wrong-password -b "dc=example,dc=com" "(uid=jode)" uid

Bind Result:

Result Code: 49 (invalid credentials)

Diagnostic Message: Reason: 52e - Invalid credentials

Password Policy Response Control:

OID: 1.3.6.1.4.1.42.2.27.8.5.1

Error Type: None

Warning Type: None

An error occurred while attempting to create a connection pool to communicate with the directory server: LDAPException(resultCode=49 (invalid credentials), diagnosticMessage='Reason: 52e - Invalid credentials', responseControls={PasswordPolicyResponseControl(isCritical=false)}, ldapSDKVersion=6.0.7, revision=76bbe43ece90ad78306ba2e5c349f33f0bf13fde)

[dirmgr]

I'm not sure that Active Directory supports that control. I'm not especially familiar with Active Directory, but I've looked online and haven't seen any indication that it supports that control.

However, the tool output does indicate that the server did in fact return a password policy response control, but that it did not include either a warning type or an error type. That is a perfectly valid version of the response control, especially in a case in which the authentication attempt failed because you provided incorrect credentials.

[suryad]

Thank you for the quick response. I have tested it on a ODSEE LDAP server as well as a RadiantOne VDS LDAP server, not on an Active Directory.

When i run the ldsapsearch with the "--usePasswordpolicycontrol" option, i can see the control received by the server in the ldap server access logs (radiantone VDS).

2023-03-07 14:19:19,036 |hostname~230306094354|--> conn[SSL/TLS]=13769 op=1 MsgID=1 BindRequest {version=3, name=userdn, authentication=***} LDAPControl {1.3.6.1.4.1.42.2.27.8.5.1 false}

But, when i use the "--control 1.3.6.1.4.1.42.2.27.8.5.1:false" option for the same password policy control, I don't see the control received by the server in the ldap server logs.

2023-03-07 14:17:15,494 |hostname ~230306094354|--> conn[SSL/TLS]=13751 op=1 MsgID=1 BindRequest {version=3, name=userdn, authentication=***}

The behavior is same with other controls that i have tested. I don't see the control received by the server from the ldapsearch tool. --control 2.16.840.1.113730.3.4.4:false (Netscape Password Expired) --control 1.2.840.113556.1.4.319:false:10 (Paged search control)

[dirmgr]

I apologize for initially misinterpreting the server as being Active Directory. I mistakenly assumed that from the "Reason: 52e" portion of the response, which looks like something that Active Directory returns.

As for the issue with the password policy request control, the problem that you're running into with the --control argument is that for the ldapsearch command-line tool, that argument is only used to specify the controls to include in search requests, and the failure you're encountering is in the bind request, so it's not even getting to the point of sending the search request. If you want to have a generic control sent in the bind request, then you should use the --bindControl argument instead.

And by the way, the Netscape password expired control is a response control rather than a control, so it should never be included in a request from the client, but only in the response from the server. And while the simple paged results control is something that does apply to search requests rather than bind requests (so the --control argument is applicable there), the value that you have for that control is not valid. When you provide the value for a control using its generic representation, you need to ensure that it's properly encoded, and for that control, you'd need to use the base64-encoded representation of the ASN.1 sequence that includes an integer element with the requested page size and a (presumably empty, at least for the request to retrieve the first page) octet string for the cookie. For a simple paged results control with a page size of 10 and no cookie, the argument would need to look like:

--control 1.2.840.113556.1.4.319:false::MAUCAQoEAA==

[suryad]

Appreciate the wondeful explanation.

• Using the "--bindControl 1.3.6.1.4.1.42.2.27.8.5.1" argument worked on the ldapsearch command-line tool, for gettting password policy related info.
• Also using the "--control 1.2.840.113556.1.4.319:false::MAUCAQoEAA==" argument worked on the ldapsearch command-line tool, for getting paged results.
• I understood that "password expired/expiring controls" are "server response controls".