Re: [RADIATOR] AuthBy FILE - Dont check password
5.21.58 NoCheckPassword This optional parameter causes AuthBy not to check the password. This means that any password entered by the user will be accepted. This parameter is useful in conjunction with other authentication methods where the password check is done elsewhere. On 20-01-15 14:17, Jim Tyrrell wrote: Is it possible to have the AuthBy FILE check a file for the username but not check the password? I ideally want the AuthBy to just check for a username in a file of only usernames, and if it matches generate the Reply, if it fails to match the username then it will fall back to a 2nd AuthBy (via AuthByPolicy ContinueWhileReject) that will respond with a different reply. The idea being that if a user is in a username list the session will be tunneled to a certain endpoint, and if not the user will be tunneled to different IP. Thanks. Jim. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator -- Peter Havekes ICT-Ontwikkeling CSIRT | Diensteenheid ICT en Facilitair Avans Hogeschool | 0885256592 | Onderwijsboulevard 215 | 5223 DE 's-Hertogenbosch | http://www.avans.nl Twitter: https://twitter.com/phavekes Google+: https://plus.google.com/+PeterHavekes smime.p7s Description: S/MIME Cryptographic Signature ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] AuthBy FILE - Dont check password
You don't even need that if the file doesn't contain a password check item. On 2015-01-21 12:02, Peter Havekes wrote: 5.21.58 NoCheckPassword This optional parameter causes AuthBy not to check the password. This means that any password entered by the user will be accepted. This parameter is useful in conjunction with other authentication methods where the password check is done elsewhere. On 20-01-15 14:17, Jim Tyrrell wrote: Is it possible to have the AuthBy FILE check a file for the username but not check the password? I ideally want the AuthBy to just check for a username in a file of only usernames, and if it matches generate the Reply, if it fails to match the username then it will fall back to a 2nd AuthBy (via AuthByPolicy ContinueWhileReject) that will respond with a different reply. The idea being that if a user is in a username list the session will be tunneled to a certain endpoint, and if not the user will be tunneled to different IP. Thanks. Jim. ___ radiator mailing list radiator@open.com.aumailto:radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator ___ radiator mailing list radiator@open.com.aumailto:radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator *** T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien Handelsgericht Wien, FN 79340b *** Notice: This e-mail contains information that is confidential and may be privileged. If you are not the intended recipient, please notify the sender and then delete this e-mail immediately. *** ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Trying to understand EAP Response type 25, but no expected type known
On 20.1.2015 22.12, Michael Hulko wrote: I have two new servers that I am trying to put into production for our eduroam users. Both servers are identical. Configs are identical (with the minor changes required to make them indentifiable to the outside world). However, that is where it appears to stop. Hello Michael, since EAP is used, you should how the requests are distributed among the servers. If one of the servers is receiving, for example, EAP 25 (PEAP) requests but it has no previous EAP authentication state with the client, you will get the message you have quoted in the subject. In other words, there was an EAP 25 response but the server had no idea that it had started EAP 25 authentication with the client. What should happen is that first there is EAP 1 response which tells the client's EAP identity. Radiator will then respond with, for example, EAP 25 (PEAP) start request and the next reponse from the client should be EAP 25 response (or NAK if the client desires some other EAP method). Authentications to one server fails, while authentications to the other server succeeds. I am stumped. It appears from the trace that the client request makes it to the first Handler but never makes it to the TunnlledByPeap=1 handler to finish the authentication. Attached is a trace 4 log capture and the current config. I see that there are a number of Access-Accepts too, so my take is that the RADIUS messages are distributed to the two servers in such a way that the server that starts EAP message authentication does not get all the messages that are part of the whole authentication exchange. Some messages are sent to the other server which then logs the message in the subject. 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
