On 3.6.2021 17.12, Jan Tomasek wrote:
I'm running two Radiator servers for authentication of our users in
cesnet.cz realm on our eduroam WiFi. Each Radiator has a dedicated LDAP
server. WiFi is controlled by a WLC. I expected that if any of RADIUSes
fails WLC will fail back to another. That is true for the RADIUS server,
but not for LDAP server failure.
That should be the case also when Radiator can't use the LDAP server
because of LDAP server's failure.
In case there is the LDAP server failure, the Radiator returns
access-reject for default FailureBackoffTime = 600s. WLC has no chance
to discover that there is a problem because it receives a response and
continues to send clients to the failing RADIUS server. Is there any
chance how to not respond to request when AuthyBy LDAP2 fails?
AuthBy LDAP2 should already return IGNORE when it can not connect to
LDAP server, LDAP query fails or some other LDAP related failure
happens. Returning ignore is exactly for the reason you describe: allow
the RADIUS client to do a fail over.
Would you have any logs that show the LDAP failure that triggers a
reject of ignore? If there's a case that results in a reject, I'd like
to check why this happens.
Is there a chance to re-check failed LDAP server before
FailureBackoffTime expires? When there is no remaining LDAP server in
Host pool this waiting doesn't make much sense?
Currently IGNORE is returned directly when FailureBackoffTime is still
in effect.
I'm wondering if you have something in your configuration that turns an
ignore to a reject after AuthBy LDAP2 is called?
At this moment I reduced FailureBackoffTime from 600s to 60s and
provided multiple LDAP servers to AuthBy LDAP2. Which seems to be working.
It's good to hear that the above helps but the AuthBy itself should also
work so that it can signal LDAP failure by using ignore and allowing the
client to a proper failover.
Can you check if your config has something that does this? If not, I'd
like to see the logs to see why AuthBy LDAP2 does not return IGNORE.
My config:
Looks good but please check if there are additional hooks or AuthBys
that may turn IGNORE to a REJECT.
Thanks,
Heikki
<AuthBy LDAP2>
Identifier Check2017LDAP
UsernameMatchesWithoutRealm yes
Host ldap
Port 636
UseSSL
SSLCAFile /etc/radiator/certs/chain_CESNET_CA4.pem
FailureBackoffTime 60
AuthDN xxxx
AuthPassword xxxx
BaseDN dc=cesnet,dc=cz
UsernameAttr uid
PasswordAttr radiusPassword
AuthAttrDef radiusTunnelPrivateGroupID,
Tunnel-Private-Group-ID, reply
SearchFilter
(&(%0=%1)(|(objectClass=eduroamTestAccount)(objectClass=radiusUser)))
EAPType PEAP,MSCHAP-V2,LEAP,TTLS
# 2. 11. 2018 Semik - prestavame posilat korenovy certifikat
EAPTLS_CAPath /etc/ssl/certs/null
EAPTLS_CertificateFile /etc/radiator/certs/radius.cesnet.cz.crt
EAPTLS_CertificateType PEM
EAPTLS_PrivateKeyFile /etc/radiator/certs/radius.cesnet.cz.key
EAPTLS_PrivateKeyPassword xxxx
EAPTLS_MaxFragmentSize 1000
EAPTLS_SessionContextId %0%n%2%{Called-Station-Id}
AutoMPPEKeys
EAPTLS_PEAPVersion 0
EAPAnonymous %n
SSLeayTrace 0
</AuthBy>
<Handler Realm=cesnet.cz, TunnelledByTTLS=1>
AuthBy Check2017LDAP
</Handler>
<Handler Realm=cesnet.cz, TunnelledByPEAP=1>
AuthBy Check2017LDAP
</Handler>
<Handler Realm=cesnet.cz>
AuthBy Check2017LDAP
AuthLog authlogger
AuthLog FTICKS-FULL
AddToReplyIfNotExist Tunnel-Type=1:VLAN,\
Tunnel-Medium-Type=1:Ether_802
</Handler>
Best regards
--
Heikki Vatiainen <h...@open.com.au>
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory,
EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc.
_______________________________________________
radiator mailing list
radiator@lists.open.com.au
https://lists.open.com.au/mailman/listinfo/radiator
