On 28/03/11 15:33 -0700, Stephen Ingram wrote:
Instead of just setting the cyrus sasl options to use kerberos5 mech, I'm trying to use the ldap mech and then perform SASL bind to the directory. This is so I can hopefully support either a uid or mail attribute login. As I keep receiving an "authentication failed" error, I'm guessing this might not be directly possible using saslauthd. Does it only support a direct bind as the user attempting to authenticate or can it support a bind to ldap as an administrative user who then performs a search for the login user dn? For example, here is saslauthd.conf: ldap_auth_method: bind ldap_use_sasl: yes ldap_mech: GSSAPI ldap_realm: 4TEST.NET ldap_id: admin ldap_servers: ldap://ldap3.4test.net ldap_search_base: dc=4test,dc=net ldap_filter: (|(uid=%u)(mail=%u))
See saslauthd/LDAP_SASLAUTHD in the source for documentation. 'ldap_use_sasl' and 'ldap_auto_method: bind' are mutually exclusive. I don't believe ldap_search_base or ldap_filter are going to be used with ldap_use_sasl enabled. If you want that level of control with a sasl bind, and assuming your server is OpenLDAP, you could move that logic into your slapd.conf/slapd-config configuration. See chapter 15 of the OpenLDAP Software 2.4 Administrator's Guide, and in particular section 15.2.7 (Search-based mappings). You could reconfigure to use ldap_auth_method: bind, without sasl, to achieve the 2 step bind process you referred to. Two ways to trouble shoot: 1. Configure 'ldap_debug: 1' (undocumented) within your saslauthd.conf to get debugging information. You might need to run saslauthd in debugging mode to see them. 2. Test your configuration outside of saslauthd, and attempt to troubleshoot the bind process with the OpenLDAP client utilities. E.g.: ldapwhoami -d -1 -Y GSSAPI -H ldap://ldap3.4test.net -U testuser -R 4TEST.NET -- Dan White