Re: [RADIATOR] Status-Server changes in patches for Radiator 4.11
On 05/12/2014 02:22 PM, a.l.m.bu...@lboro.ac.uk wrote: >> Status-Server based failure detection needs two options specified in >> AuthBy RADIUS or Host within AuthBy RADIUS: >> - Flag: UseStatusServerForFailureDetect >> - Integer: KeepaliveTimeout numsec > > what is the interplay/interaction with RADSEC for this StatusServer method? It is similar to AuthBy RADIUS. That is, when there is no traffic, Status-Server is requested from the RadSec peer. If the peer does not respond, then it is marked as being down. This is similar to when Status-Server is not used and the peer does not reply to requests. Is this what you were thinking of? Here's a quick summary for those who are thinking if they should enable Status-Server or not. This is likely familiar to eduroam folks: In roaming scenarios Status-Server is better since the next hop can be just fine but there's a remote server which is dead and does not respond. However, if RadSec is used locally, then it might be better to rely on ignored requests when it is known that a server will stop responding when it has for example, lost its connection to the backend DB. Thanks, Heikki -- Heikki Vatiainen 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
Re: [RADIATOR] Preventing Computer/Machine Authentication in AuthBy NTLM
On 05/13/2014 11:15 PM, Michael Rodrigues wrote: > I would like to REJECT any non-EAP in the outer handler. I've tried to > rearrange things to have only AuthBy FILE in the outer hanlder, having > AuthBy NTLM only in each inner handler. Hello Michael, try this: # your current config for # Default Handler # Catches everything non-EAP # Could reject with e.g., AuthBy INTERNAL Note that the above may require setting another Handler before the default to catch the accounting, if this Radiator instances receives accounting too. > This would also (I think) > require me to move my AuthBy INTERNAL to each inner handler so that it > can get inner_identity once it is unpacked after AuthBy NTLM. After this > I would AuthBy FILE for blacklist. > > However, I can't seem to get my outer handler to drop non-EAP requests: I'd say the two Handler approach requires you not to rearrange internals or require any large changes. Please let us know how it works. PS. I've been traveling lately so unfortunately it took a bit longer than usual to reply. Thanks, Heikki -- Heikki Vatiainen 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
