Vertica 11 LDAPAuth and LDAPLink errors: cannot use both: "ldaps" and "StartTLS"

raulk89

Hi

I upgraded from vertica 10.1 to vertica 11.
In vertica version 10.1, my ldap authentication and ldap link both worked fine.

Now I upgraded to version 11
I did find this document link, where it states that some parameters were removed from 11 onwards.

• Client-server TLS parameters:
  "SSLCertificate, SSLPrivateKey, SSLCA, EnableSSL"

• LDAP authentication parameters:
  "tls_key, tls_cert, tls_cacert"

• LDAPLink and LDAPLink dry-run parameters:
  "LDAPLinkTLSCACert, LDAPLinkTLSCADir, LDAPLinkStartTLS, LDAPLinkTLSReqCert"

I reconfigured my client-server TLS parameters, and did manage to get this working.

But I have problem with LDAPLink and LDAPAuth.

Little side note, for me this auth. parameter "tls_cacert" is still allowed in vertica 11. I do not know is there some documentation issue in this link or sth.. But yeah, at the moment on version 11.0.0, I can use it still.

LDAPLink error:

2021-08-23 14:53:21.959 LDAPLinkService:0x7f6d41436700 @v_mydb_node0001: 00000/6308: LDAP parameters (for server "ldaps://domain.com") is malformed - cannot use both: "ldaps" and "StartTLS"

LDAPAuth error:

2021-08-23 15:43:04.858 Init Session:0x7f6d55bf5700 @v_mydb_node0001: 00000/6308: LDAP parameters (for server "ldaps://domain.com") is malformed - cannot use both: "ldaps" and "StartTLS"

I have searched everywhere, I do not have this "StartTLS" parameter set anywhere.

LDAP auth parameters:

     auth_oid      | auth_name | auth_parameter_name |           auth_parameter_value
-------------------+-----------+---------------------+-------------------------------------------
 45035996278006078 | LDAP1     | host                            | ldaps://domain.com
 45035996278006078 | LDAP1     | basedn                      | DC=domain,DC=com
 45035996278006078 | LDAP1     | binddn                       | vertica.manager@domain.com
 45035996278006078 | LDAP1     | bind_password      | ********************
 45035996278006078 | LDAP1     | search_attribute    | sAMAccountName
 45035996278006078 | LDAP1     | tls_reqcert               | hard
 45035996278006078 | LDAP1     | tls_cacert                 | /etc/openldap/cacerts/xxxxxxxxxxx.crt

LDAPLink parameters:

  level   |        name         |      setting
----------+---------------------+--------------------------------------------------------------------------
 DATABASE | LDAPLinkDryRun            | 1
 DATABASE | LDAPLinkURL                   | ldaps://domain.com
 DATABASE | LDAPLinkSearchBase   | DC=domain,DC=com
 DATABASE | LDAPLinkBindDN            | vertica.manager@domain.com
 DATABASE | LDAPLinkBindPswd       | ********************
 DATABASE | LDAPLinkFilterGroup    | (&(objectClass=group)(|(CN=xxxxxxxxxxxxx)(CN=YYYYYYYYYYYYYY)))
 DATABASE | LDAPLinkFilterUser       | (&(objectClass=user)(CN=*)(memberOf=CN=xxxxxxxxxxxxx,DC=domain,DC=com))
 DATABASE | LDAPLinkGroupName  | name
 DATABASE | LDAPLinkUserName     | sAMAccountName
 DATABASE | LDAPLinkOn                     | 1

I have tried, if I change both URL-s, by removing "s": ldaps -> ldap
Then it is working.

But I would rather not remove this. I would like to know where this "StartTLS" setting comes from..?

Raul

SergeB

This might be a documentation issue (I'll file a JIRA).

I think any TLSMODE value (in TLS CONFIGURATION LDAPLink ) enables starttls by default and it looks like we still perform the check against the ldap url that generates the error you see.

This is a change from 11.0 where starttls was set optionally via LDAPLinkStartTLS.

From 10.1 documentation.
[Optional] Specifies whether or not to use the StartTLS operation during bind. You can only use this parameter if the LDAP server's URL is "ldap://..." (not "ldaps://..."

raulk89

This might be a documentation issue (I'll file a JIRA).

If that previous link is documentation issue, then I would presume this link has the same issue. Perhaps there are more documentation pages there.

I think any TLSMODE value (in TLS CONFIGURATION LDAPLink ) enables starttls by default and it looks like we still perform the check against the ldap url that generates the error you see.

So basically, there is nothing more to do, than just start using ldap (without "s") from now on instead of ldaps..?

Raul

SergeB

You're correct in 11.0 , Using ldaps is now controlled by enabling the LDAPLink TLS Configuration, and LDAPLinkURL should always start with ldap://

I also reported your tls_cacert observation.

Thanks for catching those.

raulk89

Ok, thanks.

Raul