On 03/12/2014 08:22 AM, karel.vandervel...@kpn.com wrote: > Does anyone know if it is possible to handle the errors of an > unreachable LDAP server vs not capable to bind differently within > radiator? If so, please advise.
Try setting 'ServerChecksPassword' option. See the reference manual for details. I think the behaviour you describe below is correct since its purpose is to return IGNORE to let AuthByPolicy and possibly the RADIUS client to know that it was not possible to get a definitive yes/no answer from the LDAP server. In other words, use anonymous bind + search followed by ServerChecksPassword or set up a user that does the bind and search followed by ServerChecksPassword if anonymous bind is not allowed. > For an access service we use the bind feature to let the LDAP server > check the password for that specific user object, and then retrieve the > required attributes. But when the username/password combination is wrong > the result is IGNORE and hence another authentication attempt is done > towards the second LDAP server (which of course also results in a > non-successful bind attempt). Thanks, Heikki -- Heikki Vatiainen <h...@open.com.au> Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
