It looks like the service discovery will break the SSL connection to the ldap server.
xwiki.authentication.ldap.ssl=1 is set, but the ssl connection is tried on port 389, which will fail.
And the setting xwiki.authentication.ldap.port=636 is ignored.
For an workaround set xwiki.authentication.ldap.service_discovery=0.
I’m hardly a service discovery expert, but from what I see in the code this seems to suggest that you have a record with a wrong port associated with the configured host.
The problem is, that 2 default port exits for LDAP. 389 for ldap and 636 for ldaps (via SSL).
But as far as I see, the auto discover will ignore the ssl settings.
dig -t SRV _ldap._tcp.foo.foo
will shown the correct servers. But the connection is done on port 389 instant of 636.
When I disable the service discovery, the connection is done via port 636 as needed.
I know, but what I mean is that the port used by the authenticator is coming from the record, so maybe the record is wrong (when there is no record, the behavior is the same as when auto discovery is disabled). If you enabled debug log, you should see exactly what port is set in the record next to something like “Connection to LDAP server [mydomain.com:389]”. Would be interesting to know exactly what leaded to use 389.
This is what I mean, when SSL is enabled, then the port returned by the dns query must be ignored, because the RFC only specify an ldap query and no ldaps query. This will result in the fact for now, that all ldaps configuration are broken. Because the given ldaps port in the configuration is ignored. And using startTLS over the ldap port is an very bad idea, because sensitive information can be transmitted in clear text. So the best way will be, when an ldaps port is set, that port will be used and only the host name for the ldap server will be used from the dns query.
when SSL is enabled, then the port returned by the dns query must be ignored, because the RFC only specify an ldap query and no ldaps query
If you mean RFC2782: That does not talk about LDAP specifically but about SRV RRs in general. The canonical registry of service names for SRV records and protocols is defined in RFC6335 and is maintained by IANA. You can access that here: Service Name and Transport Protocol Port Number Registry
To autodiscover the LDAP over TLS (what was called slapd) service one needs to look up _ldaps._tcp.yourdomain.com. That’s currently not done by the authenticator so you’re correct: When ssl is enabled alongside service discovery, the authenticator would try to establish an LDAPS connection on the port returned by the SRV record (probably 389) which should only serve LDAP. So this is definitely a bug or at least unexpected behaviour.
I just released a 9.6.1 version of the authenticator with @spike77453’s fix. Would be great if you could check if it’s better with it @mdc_xwiki.