Xu, Qiang (FXSGSC) wrote:
Xu, Qiang (FXSGSC) wrote:
Hi, all:
In my testing of SASL LDAP binding, I found the GSSAPI plugin library (/usr/lib/sasl2/libgssapiv2.so) will go mad if an IPv6 address of Kerberos authentication server is passed
to it. It just can't recognize the IPv6 address, and would
take it as a hostname.
For example, the IPv6 address of the Kerberos server is "3ffe:2000:0:1:e0be:1872:d4f8:6b2c", and the authentication
domain is "xcipv6.com". When GSSAPI plugin receives this IPv6
address, it would think the address is in a form of
"hostname:port", so would split the address at the first
colon, and combine it with the domain name, to form an FQDN
"3ffe.xcipv6.com". Then it would try to resolve this FQDN to
get the IP address (v4?). Of course, the resolving would lead
to an error. And SASL binding can't go through.
I believe this is happening inside MIT Kerberos V5 library,
so you need to talk to MIT.
Hi, Alex:
On second thoughts, I wonder how you can determine it is a problem inside MIT Kerberos V5 distribution? Because in my testing, authentication has no problem. Only LDAP queries (done with SASL binding) failed after the user logs in. And from the trace, it seems the problem can be boiled down to that the Kerberos server can't be located in LDAP SASL interaction. In this process, shouldn't it be Cyrus-SASL library's responsiblity to find out the location of Kerberos server?
Could you tell me the reason why you think MIT distribtion is the blackhand?
Because GSSAPI (Kerberos V5) plugin is not calling any DNS resolution
functions directly as far as I can see.
