LDAPS with SASL External on port 636: Active Directory errors out with LdapErr: DSID-0C0905F0

Question

LDAPS with SASL External on port 636: Active Directory errors out with LdapErr: DSID-0C0905F0

David Pereira 21

I have been trying to configure SASL External over LDAPS (Port 636). Below things are already in place.

Have enforced the LDAP (aka AD server 2019) for LDAP signing and Binding via Domain Controllers Group Policy.
Have a User Certificate issued by its Enterprise CA configured with User DN (cn=testuser,cn=users,dc=dummydomain,dc=test) in Subject and SAN (cn=testuser,cn=users,dc=dummydomain,dc=test), SAN also includes the UPN (******@dummydomain.test) and the certificates are uploaded to active directory. The certificate extension uses Client Authentication
Client and the server are trusting the CA which have issued the cert for the LDAPS server certificate and the User certificate
Have a linux server in place with OpenLDAP client installed.

The .ldaprc has the below settings:
TLS_REQCERT hard
TLS_CACERT /etc/openldap/cacerts/caroot.pem
TLS_CERT /etc/openldap/certs/usercert.pem
TLS_KEY /etc/openldap/certs/private.key
SASL_MECH external
TLS_PROTOCOL_MIN 1.2

Below works successfully on port 389 with LDAP (START-TLS):
Command:
ldapwhoami -Y EXTERNAL -H ldap://server.dummydomain.test -Z
Results of above command:
SASL/EXTERNAL authentication started
SASL username: cn=testuser,cn=users,dc=dummydomain,dc=test
SASL SSF: 0
u:DUMMYDOMAIN\testuser

Using the same with LDAPS on port 636 doesn't work at all and gives the below error.
Command:
ldapwhoami -Y EXTERNAL -H ldaps://server.dummydomain.test
Results of above command:
SASL/EXTERNAL authentication started
ldap_sasl_interactive_bind_s: Authentication method not supported (7)
additional info: 00002027: LdapErr: DSID-0C0905F0, comment: Invalid Authentication method, data 0, v4563

Have searched with DSID for any references on error and I was not able to find any resolution or references on the same.
I wonder what is the difference and why SASL-EXTERNAL works fine on port 389 with START-TLS and refuses to work on port 636 with the error stated above.

The debug logs also don't provide much information:
*host: server.dummydomain.test port: 636 (default)
refcnt: 2 status: Connected
last used: Tue Sep 13 11:14:09 2022
ld 0x55c987e4e3c0 Outstanding Requests:
msgid 1, origid 1, status InProgress
outstanding referrals 0, parent count 0
ld 0x55c987e4e3c0 request count 1 (abandoned 0)
** ld 0x55c987e4e3c0 Response Queue:
Empty
ld 0x55c987e4e3c0 response count 0
ldap_chkResponseList ld 0x55c987e4e3c0 msgid 1 all 1
ldap_chkResponseList returns ld 0x55c987e4e3c0 NULL
ldap_int_select
read1msg: ld 0x55c987e4e3c0 msgid 1 all 1
ber_get_next
ber_get_next: tag 0x30 len 104 contents:
read1msg: ld 0x55c987e4e3c0 msgid 1 message type bind
ber_scanf fmt ({eAA) ber:
read1msg: ld 0x55c987e4e3c0 0 new referrals
read1msg: mark request completed, ld 0x55c987e4e3c0 msgid 1
request done: ld 0x55c987e4e3c0 msgid 1
res_errno: 7, res_error: <00002027: LdapErr: DSID-0C0905F0, comment: Invalid Authentication method, data 0, v4563>, res_matched: <>
ldap_free_request (origid 1, msgid 1)
ldap_int_sasl_bind: EXTERNAL
ldap_parse_sasl_bind_result
ber_scanf fmt ({eAA) ber:
ldap_parse_result
ber_scanf fmt ({iAA) ber:
ber_scanf fmt (}) ber:
ldap_msgfree
ldap_err2string
ldap_sasl_interactive_bind_s: Authentication method not supported (7)
additional info: 00002027: LdapErr: DSID-0C0905F0, comment: Invalid Authentication method, data 0, v4563
ldap_free_connection 1 1
ldap_send_unbind
ber_flush2: 7 bytes to sd 3
TLS trace: SSL3 alert write:warning:close notify
ldap_free_connection: actually freed*

Any help on getting this worked is much appreciated. Thanks in anticipation.

Accepted answer

7 additional answers

Your answer

Answer 1

Hello All,

I think that we now have a good understanding of the situation regarding use of SASL EXTERNAL authentication against Active Directory and tests verify that the Microsoft implementation behaves as documented (by Microsoft in [MS-ADTS]).

A client certificate can be used for authentication via both the ldaps scheme and the Start TLS mechanism, but the protocol steps differ. ldapwhoami does not support using certificate authentication against Active Directory via the ldaps scheme (the LDAP bind step cannot be suppressed).

The IANA Uniform Resource Identifier (URI) Schemes Registry say this about the ldaps scheme:

Encoding considerations:
Unknown, use with care.

Applications/protocols that use this scheme name:
Not an IETF standard, but commonly used in applications.

Interoperability considerations:
Unknown, use with care.
May be unsuitable for open use on the public internet.
Security considerations:
Unknown, use with care.

Gary

Answer 2

Hello David,

The DSID information encodes the directory, file and line number of the source code file where the problem was reported (the vNNNN number encodes the build of the software). This information will vary with different builds of the server, so it is not a good "identifier" when used to search for similar problems.

The error code 00002027 has the symbolic name CRYPT_E_NO_VERIFY_USAGE_DLL.

Does adding a "-v" option to ldapwhoami reveal any more information?

Would you be prepared to share trace data created on the LDAP/AD server?

Gary

Answer 3

Gary Reynolds 9,621

Hi,

The 00002027 is the hex Windows Error code, which doesn't provide any additional information

Hex: 0x00002027 	Int: 8231  
Severity Code: 00,	Source Facility: NULL,	Error Code: Hex: 0x2027 Int: 8231  
  
(8231) The requested authentication method is not supported by the server.

I would also try changing the TLS_REQCERT option to never, and also reduce TLS_PROTOCOL_MIN 1.2 to 1.0. While the LDAP connection and Start_TLS option worked, I can't find any details on the behavior when TLS encryption is started and if the server certificate is verified. So you might have a certificate configuration issues.

I'm not familiar with the OpenLDAP client but is there an option to do an ldap_bind as a separate operation which might help identify the authentication issue.

Gary.

Gary Reynolds 9,621 Reputation points

2022-09-14T00:04:25.823+00:00

Correction, the start_tls function will do the same certificate verification as a ldap_sslinit call - https://learn.microsoft.com/en-us/previous-versions/windows/desktop/ldap/using-start-stop-tls-encryption

Answer 4

@Gary Reynolds @Gary Nebbett
The TLS handshake is done and the server cert and client cert is also verified.

I had not posted the above verbose lines as it would be a lot of information to look at. Have attached the working START-TLS (Port-389 LDAP - 240873-ldaps-start-tls-389-debug-working.txt) debug logs and aswell as the non-working one for comparison (Port-636 LDAPS - 240829-ldaps-tls-636-debug-failure.txt).
The certificate seems to be fine as I'm using the same certificate with START-TLS on port 389 and it works 100% fine without any errors and also LDAP bind is successful with the user certificate.

The only issue is with using port 636 (This is TLS/SSL).

The main purpose here is to test Certificate based authentication with Mutual Auth which works as expected with LDAP START-TLS. So, having to set TLS_REQCERT never is not an option.

However as per you suggestion I have given a try with the configs but the result is the same.

Answer 5

Gary Nebbett 6,216

Hello David,

Would you be prepared to share trace data from the AD server? If the "test" like names in the information you have post are accurate, then this should not be a problem.

I still need to work out what tracing would be most helpful for this scenario (I have never used SASL EXTERNAL authentication), so that might take a while...

Interesting to see that @Gary Reynolds has posted a correction to his first post - we two Garys seem to share several troubleshooting characteristics: I wanted to post a correction to my first post too. Gary was correct with the error code: CRYPT_E_NO_VERIFY_USAGE_DLL is the symbolic name for the error code decimal 2027; because it seemed vaguely relevant to the problem (and perhaps because there was no leading "0x"), I did not notice the number base error :-(

Gary

David Pereira 21 Reputation points

2022-09-14T07:59:59.89+00:00

Yes, no issues providing the Trace Logs. Also the "test" names are accurate.
@Gary Nebbett Can you direct me getting those LDAP Trace details from the AD server?
Gary Nebbett 6,216 Reputation points

2022-09-14T08:19:01.343+00:00

Hello David,

I am working on that. I need to set-up and trace SASL EXTERNAL authentication on my systems first so that I can work out which trace providers offer the most insight into that type of authentication. Once done, I will let you know the results.

My initial starting point would be this command (to start the trace):

netsh trace start scenario=lan capture=yes provider={1C83B2FC-C04F-11D1-8AFC-00C04FC21914} keywords=0xFFFFFFFF level=255 provider={90717974-98db-4e28-8100-e84200e22b3f} keywords=0xFFFFFFFF level=255 provider={3e7da688-9a79-4dd5-81c9-54d74c456890} keywords=0xFFFFFFFF level=255 provider={37d2c3cd-c5d4-4587-8531-4696c44244c8} keywords=0xFFFFFFFF level=255 provider={6b510852-3583-4e2d-affe-a67f9f223438} keywords=0xFFFFFFFF level=255 provider=Schannel keywords=0xFFFFFFFF level=255 report=disabled overwrite=yes tracefile=why.etl

The trace is stopped with the command netsh trace stop.

I need to set-up LDAPS first and am just about to go for a bike ride, so if you want to try the commands above, then that data might be enough to get a handle on the problem cause.

Gary

Update @16:20 CEST: I have added an additional provider - the trace should be "good to go" now...
Gary Reynolds 9,621 Reputation points

2022-09-14T09:14:11.507+00:00

Hi David,

Are you able to provide the instructions that you have following to enable client certificate based authentication?

Also could you please confirm that the CA root certificate of the has been installed in the NTAuth certificate store - https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/import-third-party-ca-to-enterprise-ntauth-store

Gary.
Gary Reynolds 9,621 Reputation points

2022-09-14T20:27:52.12+00:00

Hi Gary,

What's your take on this page from the AD sasl external auth - https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/126300e8-5ff9-4643-9ac6-97e3f4aa1926

In the case of DCs, the external authentication information that is used to validate the identity of the client making the bind request comes from the client certificate presented by the client during the SSL/TLS handshake that occurs in response to the client sending an LDAP_SERVER_START_TLS_OID extended operation. When the server receives an EXTERNAL SASL bind following a successful LDAP_SERVER_START_TLS_OID extended operation in which a valid certificate was presented by the client, the server causes the connection to be bound as the identity represented by that certificate.

I could be wrong but to me this suggests that a start_tls operation must be used before the bind for client certificate based authenticate, which is what we see in the ldap log file. The comments on the ldap_start_tls functions says that the connection must not be TLS. Which would suggest that sasl external auth is not supported on an ldaps connection.

https://learn.microsoft.com/en-us/windows/win32/api/winldap/nf-winldap-ldap_start_tls_sw

David - do you have anything to say it should work on ldaps connections, also can you try including the -Z option on the ldaps connection?

Gary.
Gary Nebbett 6,216 Reputation points

2022-09-15T06:47:44.75+00:00

Hello Gary,

You are clearly someone who is used to looking for nuances in standards documents!

My (current) take on that text is that it is unnecessarily overly descriptive/prescriptive. "Start TLS" is the only (RFC) standardised method of using SSL/TLS with LDAP and perhaps the author had that in mind when writing the text.

From what I have observed so far, I would say that both "Start TLS" and ldaps:// methods should work with SASL EXTERNAL if a client certificate is presented and if that certificate can be mapped to an account (see "KB5014754: Certificate-based authentication changes on Windows domain controllers").

In that list of ETW trace providers above, I included raw packet data (for more insight into the plaintext part of TLS negotiation), Schannel, Kerberos (potentially used in certificate mapping) and 3 NTDSA providers, so I am hopeful that something useful will show up.

Gary

Share via

LDAPS with SASL External on port 636: Active Directory errors out with LdapErr: DSID-0C0905F0

7 additional answers

Your answer