The behaviour of ldap_sasl_authid was changed in
e81a816cddab4a62f263d1a0274d5d3f101e8e0f so that it no longer accepted full
principal, but only hostname. The realm was read from the (undocumented)
ldap_sasl_realm option.
Moreover the "hostname" had to be specified in exactly the format that would
match the keytab later, ie if the first match was host/hostname, the option
would have to be specified as host/hostname, otherwise the user got an error.
I also found out that the principal selection is only used in IPA and AD
providers, but I'll file a separate ticket to track that. Right now, I'm
mostly interested in fixing the regression.
The attached patched modify that behaviour:
[PATCH 1/3] MAN: document the ldap_sasl_realm option
The option was completely undocumented.
[PATCH 2/3] LDAP: Provide a common sdap_set_sasl_options init function
The AD and IPA initialization functions shared the same code. This patch
moves the code into a common initialization function.
[PATCH 3/3] LDAP: Make it possible to use full principal in ldap_sasl_authid again
When the guessing of principals was introduced, we changed the existing
behaviour and instead of allowing both host/hostname@REALM and
host/hostname, only the latter worked and the realm was always appended
from the (then undocumented) ldap_sasl_realm option.
This patch changes the behaviour to be more backwards-compatible -- if
the ldap_sasl_authid contains the @-sign, then the ldap_sasl_realm is
not always appended.
The strict requirement of checking the requested authid/realm against
the one found in keytab was also kind of relaxed because it didn't
really work. For example when hostname was requested and the keytab
matched host/hostname first, the code blew up.
https://fedorahosted.org/sssd/ticket/1635