Sorry, I only just joined the mailing list (to try to address this exact issue) so I can't directly quote Markus' original message on this.
The use of GSSAPI with perl-ldap broke with version 0.37. A change was made at that time to deal with some issue revolving around servers in a round-robin cycle not having the same server name. That, apparently, was causing some issue. Unfortunately, the solution chosen was to change the "connected name" in LDAP.pm from a machine name to an IP address. That apparently seemed to solve whatever the initial problem was, at least in the case(s) in question, I guess. However, that does not work at all well with GSSAPI, particularly when used in conjunction with Kerberos as the actual authenticating agent. When Kerberos/GSSAPI is used, a ticket (cerdential) exists for the desired user on the client machine. When trying to use this ticket to authenticate to the LDAP server, a new ticket needs to be obtained that is associated with the LDAP service. The way that is done is that a new ticket is acquired that is associated with the Kerberos principal ldap/<machine>@<DOMAIN> where <DOMAIN> is the Kerberos realm and <machine> is the name of the server machine. For example, at our local setup, the realm is 'UALBERTA.CA' and our LDAP server(s) is known as 'directory.srv.ualberta.ca' with IP address 129.128.98.57. When we authenticate to LDAP using Kerberos, we need (and used to get with Net::LDAP) a ticket for 'ldap/directory.srv.ualberta...@ualberta.ca'. When the 'connected_name' was changed to an IP address, <machine> changed to a portion of the IP address, in our case '128.98.57', so that it now tries to create a ticket for 'ldap/128.98...@ualberta.ca'. That doesn't work, nor should it. If we re-configured the LDAP server(s) to use THAT Kerberos server name, all of the non-Net::LDAP code that currently works fine would break. The concept of embedding IP addresses within service credentials also goes against the whole intent of GSSAPI and DNS. My only resolution at the time was to undo the round-robin patch that was introduced in version 0.37. That fixed my problem. I would, however, like to find a solution that meets both needs but I'm not sure what the actual issue is with round-robin machines. We do, in fact, use something similar ... directory.srv.ualberta.ca is a front end address that is redirected via an OpenBSD 'router' to more than 20 individual LDPA server machines, each with their own IP address and machine name. We haven't had a problem. Not exactly the same as DNS round-robin but fairly close ------------------------------------------------------------------------ Antoine Verheijen Email: antoine.verhei...@ualberta.ca AICT (formerly CNS) Phone: (780) 492-9312 University of Alberta Fax: (780) 492-1729
