setup question : mschap + perl authentication
Hi community I have a question for you guys. I'm wondering if it's possible to authenticate a user who is using mschap authentication with perl. I already made a perl script, which I use with rlm_perl to authenticate users to an ftp backend. I use that script to authenticate users from the authentication proxy of a Cisco PIX. My next setup is to authenticate user requests from a Wireless Access Point with EAP-TTLS. Is it possible to do that with the radiusd.conf ? I already tried to setup like this in the authenticate section : mschap { perl } But problem is, the perl script doens't seems to receive the same information as a PIX request. Do I need to modify my script to talk mschap ? Is there a perl module to understand the mschap protocol ? Thanks in advance, Johan
Johan wrote:
I'm wondering if it's possible to authenticate a user who is using mschap authentication with perl.
Sure. Just re-write all of the MS-CHAP authentication protocol in rlm_mschap in Perl. But why the heck would you want to do that?
I already made a perl script, which I use with rlm_perl to authenticate users to an ftp backend. I use that script to authenticate users from the authentication proxy of a Cisco PIX.
Does the FTP backend support MS-CHAP? If not, there's no point in writing any Perl code to integrate the two.
My next setup is to authenticate user requests from a Wireless Access Point with EAP-TTLS. Is it possible to do that with the radiusd.conf ?
I already tried to setup like this in the authenticate section :
mschap { perl }
But problem is, the perl script doens't seems to receive the same information as a PIX request. Do I need to modify my script to talk mschap ?
I think you're randomly trying to get something to work, without understanding what's going on.
Is there a perl module to understand the mschap protocol ?
Look on CPAN. We don't manage Perl packages here. Alan DeKok.
Alan DeKok wrote:
Johan wrote:
I'm wondering if it's possible to authenticate a user who is using mschap authentication with perl.
Sure. Just re-write all of the MS-CHAP authentication protocol in rlm_mschap in Perl.
But why the heck would you want to do that?
You know i've been thinking of doing that in PHP (PHP Based supplicant for weblogin via RADIUS), i'm sure it's possible... and it would be of some benefit, just the RFC makes my head hurt... one of the few times I've regreted not studying computer science. *sigh* something to do with hashing the nt hash using different sha functions. Got PAP working though thats not exactly hard... and CHAP seems very easy , so i'll do that tomorrow. Have a request hash <Radius to Supplicant> Hash this hash with a hash of the password <Supplicant> Here have the request hash and the hash of the request hash with the password.. <Supplicant to Radius> *works* And the advantage of supporting MSChap is that you don't have to store your passwords in cleartext... Just NT4 or LMHash which while not much more secure than cleartext , looks far more impressive in a password database. But yes, as Alan said, why bother implimenting the server side MSChap module in perl ... rlm_perl wasn't really designed for this kind of stuff, more for request flow control and acquiring extra attributes from databases and various other perly type things. You ok Alan ? You've seemed less yeah go look at this howto / man page and more *stab stab* die recently ... Sorry abundance of Guinness ... Thanks, Arran
Arran Cudbard-Bell wrote:
And the advantage of supporting MSChap is that you don't have to store your passwords in cleartext... Just NT4 or LMHash which while not much more secure than cleartext , looks far more impressive in a password database.
And the server already does the heavy lifting of implementing MS-CHAP. Why re-invent the wheel?
You ok Alan ? You've seemed less yeah go look at this howto / man page and more *stab stab* die recently ...
Questions like "why are you so mean" can't be answered with "read this man page". They require careful analysis. Though the incidence of such complaints did go down after Section 5 was added to the top-level README. Alan DeKok.
On Mon, 2007-07-09 at 22:44 +0100, Arran Cudbard-Bell wrote:
Alan DeKok wrote:
Johan wrote:
I'm wondering if it's possible to authenticate a user who is using mschap authentication with perl.
Sure. Just re-write all of the MS-CHAP authentication protocol in rlm_mschap in Perl.
But why the heck would you want to do that?
You know i've been thinking of doing that in PHP (PHP Based supplicant for weblogin via RADIUS), i'm sure it's possible... and it would be of some benefit, just the RFC makes my head hurt... one of the few times I've regreted not studying computer science. *sigh* something to do with hashing the nt hash using different sha functions.
I suggested this to a BlueSocket rep after my 802.1x talk at NetworkShop 2006 (I think...) to get over the problems of PAP on eduroam - but my suggestion went further and was to do it in JavaScript on the browser, have the server simply act as a relay. I imagine that'd be even trickier. I got about an hour into coding it and lost the will to live...
Phil Mayers wrote:
On Mon, 2007-07-09 at 22:44 +0100, Arran Cudbard-Bell wrote:
Alan DeKok wrote:
Johan wrote:
I'm wondering if it's possible to authenticate a user who is using mschap authentication with perl.
Sure. Just re-write all of the MS-CHAP authentication protocol in rlm_mschap in Perl.
But why the heck would you want to do that?
You know i've been thinking of doing that in PHP (PHP Based supplicant for weblogin via RADIUS), i'm sure it's possible... and it would be of some benefit, just the RFC makes my head hurt... one of the few times I've regreted not studying computer science. *sigh* something to do with hashing the nt hash using different sha functions.
I suggested this to a BlueSocket rep after my 802.1x talk at NetworkShop 2006 (I think...) to get over the problems of PAP on eduroam - but my suggestion went further and was to do it in JavaScript on the browser, have the server simply act as a relay.
I imagine that'd be even trickier. I got about an hour into coding it and lost the will to live...
Trying to code an MSCHAP client in JS thats just insane ?! But kudos for trying. It appears that there is actually a wrapper class in the pecl repository to do PAP , ChapMD5, MSChapV1 MSChapV2. You'd need the Radius extension installed, though that too can be downloaded from pecl. What exactly was the issue with doing PAP over Eduroam ? Was it people being afraid of passing weakly encrypted passphrases around the interweb, or home sites just not bothering to implement PAP on their Radius servers ?
Hi,
What exactly was the issue with doing PAP over Eduroam ? Was it people being afraid of passing weakly encrypted passphrases around the interweb, or home sites just not bothering to implement PAP on their Radius servers ?
No, the issue is a different one: you will have to enter your credentials on the visited site, and it will either a) be able to see them (using outright PAP) b) send you a beautiful/ugly PHP/JS piece of code to encrypt stuff - but then the user would need to trust that piece of code from an inst he doesn't know Both of these give the visited inst a chance to get hold of your credentials. With EAP and TLS tunnels, this is conceptually not possible and is thus stronger. eduroam security standards don't allow that your password is visible anywhere but at home (if at all). Note that the interweb thingy is not that critical, it can be overcome: visited inst RADIUS server gets PAP credentials, initiates its own EAP-TTLS-PAP session to home, puts user's credentials in it. Authenticates user and relays the outcome as PAP reply. This solves the en-route problem, but cannot overcome the problem that still the visited inst *has* your password. Note also that your problems _can_ be solved quite cleanly, but without RADIUS. Put your captive portal behind a AAI infrastructure such as Shibboleth. Workflow is: - user gets captive portal page - is asked "Where are you from" -> enters realm or selects text box - Firewall for his IP address is opened _only_ for his home AAI place - gets redirected to his own AAI place (can verify TLS cert, connection is encrypted) - authenticates at home, gets cookie / session ID so that captive portal gets informed that he's properly authenticated - firewall opens for all traffic That way, the user only reveals his credentials to home, not the visited inst. There is a nice paper and prototype impl of this for Shibboleth, I can look up the source if you're interested. Why don't we do that then? The wireless link is still unencrypted with this ansatz. Again a violation of our security mimimums. And this problem is a lot harder to solve than authentication above. We would probably need to go to the IEEE asking for a "WPA2-Noauth-JustEncrypt" profile, where the AP just hands out a EAPoL-Key to the client, performing no prior authentication. This would just encrypt the link, and authentication could take palce with the above thing. *Then*, web-redirect is again a viable alternative. But going to the IEEE is not exactly a walk in the park. Greetings, Stefan -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473
credentials in it. Authenticates user and relays the outcome as PAP reply. This solves the en-route problem, but cannot overcome the problem that still the visited inst *has* your password.
Ah yes, I can see that being a problem, damn this means we can't offer any JRS authenticated services other than wireless and wired network access. We were planning on a few kiosks dotted around campus... though in theory if those Kiosks supported EAP Based login, the tunnel would be between the Kiosk and the users Home RADIUS server... Would this be acceptable, Or would the fact that we could still theoretically capture the users credentials from the login screen be an issue ?
Note also that your problems _can_ be solved quite cleanly, Shibboleth is in no way clean ! It's an evil necessary... actually the Idea is good ,Just the WAYF page is just so horribly cludgy. I think the idea of a pre-login form on the authenticated service would be a good idea. You enter your username string user@domain, this sets a identification cookie containing that string and redirects you to your home gateway (using a central list of domain->gateway mappings) . You then provide your password at your home gateway, which then directs you back to the page where you were originally sent from. No nasty WAYF pages.
Unfortunately this would mean you could be identified, and I know thats a big feature of Shibboleth... that Service providers don't know who's using their service, just that they've been authorised to do so. *sigh* there must be a solution , just no ones figured it out yet .
but without RADIUS. Put your captive portal behind a AAI infrastructure such as Shibboleth. Workflow is...
Were implementing shibboleth already, due to go live summer 2008...
That way, the user only reveals his credentials to home, not the visited inst. There is a nice paper and prototype impl of this for Shibboleth, I can look up the source if you're interested.
I've read more shibboleth technical documentation than I would care to already, but thanks for the offer .
Why don't we do that then? The wireless link is still unencrypted with this ansatz. Again a violation of our security mimimums. And this problem is a lot harder to solve than authentication above. We would probably need to go to the IEEE asking for a "WPA2-Noauth-JustEncrypt" profile, where the AP just hands out a EAPoL-Key to the client, performing no prior authentication. This would just encrypt the link, and authentication could take palce with the above thing. *Then*, web-redirect is again a viable alternative. But going to the IEEE is not exactly a walk in the park.
No, quite. So this would be a kind of walled garden approach using shibboleth for authentication ?
Greetings,
Stefan
Regards, Arran -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900
Hi,
Ah yes, I can see that being a problem, damn this means we can't offer any JRS authenticated services other than wireless and wired network access. We were planning on a few kiosks dotted around campus... though in theory if those Kiosks supported EAP Based login, the tunnel would be between the Kiosk and the users Home RADIUS server... Would this be acceptable, Or would the fact that we could still theoretically capture the users credentials from the login screen be an issue ?
Note also that your problems _can_ be solved quite cleanly, Shibboleth is in no way clean ! It's an evil necessary... actually the Idea is good ,Just the WAYF page is just so horribly cludgy. I think the idea of a pre-login form on the authenticated service would be a good idea.
install pGina on the kiosk systems, for example...and let those kiosk systems talk directly back to your ORPS RADIUS server. the request will then be proxied through to the home site if they are a visitor (ie dont enter your realm) alan
Hello, Our users connect from our internal lan to the internet through pptp connection ( so we can control when they login and how much they use the net). LAN ---->PPTP---->Internet I'm using active directory for authentication (rlm_ldap for PAP and ntlm_auth for mschap) and authorization with groups and everything. Everything works like a charm! The problem is that I've setup a few with internal static ip addresses (192.168.12.X range) and a few with our valid ip address range (85.15.X.X range). I'm assigning these ip addresses in Active Directory through msRadiusFramedIPAdrress attribute. Users with static ip address of 85.X are getting their static ip addresses, but not users in 192.X range. (they get 255.255.255.255) After digging for a while I noticed I could assigned ip addresses up to 127.255.255.255 and get the ip assigned. Right after 128.0.0.0 the static ip will not get assigned to the user. Apparently the 4 byte integer in the active directory for msRadiusFramedIPAddress is being treated as a signed integer, so anything more then 127.255.255.255 is treated as a negative value and an invalid value. Is there a setting to treat this 4 byte as an unsigned integer? A setting? Or this is a bug? Thank you in advance, And thank you for this great software :) Cheers, parham
Check the attribute format. InetAddr shouldn't be doing that. Ivan Kalik Kalik Informatika ISP Dana 10/7/2007, "Parham Beheshti" <p_beheshti@rasana.net> piše:
Hello, Our users connect from our internal lan to the internet through pptp connection ( so we can control when they login and how much they use the net).
LAN ---->PPTP---->Internet
I'm using active directory for authentication (rlm_ldap for PAP and ntlm_auth for mschap) and authorization with groups and everything. Everything works like a charm! The problem is that I've setup a few with internal static ip addresses (192.168.12.X range) and a few with our valid ip address range (85.15.X.X range). I'm assigning these ip addresses in Active Directory through msRadiusFramedIPAdrress attribute. Users with static ip address of 85.X are getting their static ip addresses, but not users in 192.X range. (they get 255.255.255.255) After digging for a while I noticed I could assigned ip addresses up to 127.255.255.255 and get the ip assigned. Right after 128.0.0.0 the static ip will not get assigned to the user. Apparently the 4 byte integer in the active directory for msRadiusFramedIPAddress is being treated as a signed integer, so anything more then 127.255.255.255 is treated as a negative value and an invalid value. Is there a setting to treat this 4 byte as an unsigned integer? A setting? Or this is a bug? Thank you in advance, And thank you for this great software :) Cheers, parham
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
tnt@kalik.co.yu wrote:
Check the attribute format. InetAddr shouldn't be doing that.
It's Microsoft. ...
I'm assigning these ip addresses in Active Directory through msRadiusFramedIPAdrress attribute. Users with static ip address of 85.X are getting their static ip addresses, but not users in 192.X range. (they get 255.255.255.255) After digging for a while I noticed I could assigned ip addresses up to 127.255.255.255 and get the ip assigned. Right after 128.0.0.0 the static ip will not get assigned to the user. Apparently the 4 byte integer in the active directory for msRadiusFramedIPAddress is being treated as a signed integer, so anything more then 127.255.255.255 is treated as a negative value and an invalid value.
i.e. When FreeRADIUS queries the Microsoft software for the IP address, it doesn't get "1.2.3.4". It sometimes gets "123456789", and it sometimes gets "-345567890". Unix systems can deal with IP addresses. They can treat large hex or decimal numbers as IP addresses. But they draw the line at negative numbers.
Is there a setting to treat this 4 byte as an unsigned integer? A setting? Or this is a bug? Thank you in advance,
It's a bug in the Microsoft software.
And thank you for this great software :)
Thanks. Alan DeKok.
Actually connecting to AD with Apache LDAP Studio, I see a negative number. Searched MS Site for a bit, couldn't find anything ... I'll probably just use the users file then... Thanks for your help Parham -----Original Message----- From: freeradius-users-bounces+p_beheshti=rasana.net@lists.freeradius.org [mailto:freeradius-users-bounces+p_beheshti=rasana.net@lists.freeradius. org] On Behalf Of Alan DeKok Sent: Wednesday, July 11, 2007 12:40 AM To: FreeRadius users mailing list Subject: Re: AD + Static IP Address tnt@kalik.co.yu wrote:
Check the attribute format. InetAddr shouldn't be doing that.
It's Microsoft. ...
I'm assigning these ip addresses in Active Directory through msRadiusFramedIPAdrress attribute. Users with static ip address of 85.X are getting their static ip addresses, but not users in 192.X range. (they get 255.255.255.255) After digging for a while I noticed I could assigned ip addresses up to 127.255.255.255 and get the ip assigned. Right after 128.0.0.0 the static ip will not get assigned to the user. Apparently the 4 byte integer in the active directory for msRadiusFramedIPAddress is being treated as a signed integer, so anything more then 127.255.255.255 is treated as a negative value and an invalid value.
i.e. When FreeRADIUS queries the Microsoft software for the IP address, it doesn't get "1.2.3.4". It sometimes gets "123456789", and it sometimes gets "-345567890". Unix systems can deal with IP addresses. They can treat large hex or decimal numbers as IP addresses. But they draw the line at negative numbers.
Is there a setting to treat this 4 byte as an unsigned integer? A setting? Or this is a bug? Thank you in advance,
It's a bug in the Microsoft software.
And thank you for this great software :)
Thanks. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
Ah yes, I can see that being a problem, damn this means we can't offer any JRS authenticated services other than wireless and wired network access. We were planning on a few kiosks dotted around campus... though in theory if those Kiosks supported EAP Based login, the tunnel would be between the Kiosk and the users Home RADIUS server... Would this be acceptable, Or would the fact that we could still theoretically capture the users credentials from the login screen be an issue ?
Well, Alan mentioned pGina, and that would sort of fulfill the security requirements. It's still somewhat borderline, because you are supposed to enter something on an untrusted computer (mind keyboard sniffers et al). eduroam was meant as a WLAN infrastructure for *your own* laptop. An exact border on where to stop calling things eduroam remains to be drawn. Application-layer authentication is usually something to be taken care of by an application-level AAI infrastructure.
Note also that your problems _can_ be solved quite cleanly,
Shibboleth is in no way clean ! It's an evil necessary... actually the Idea is good ,Just the WAYF page is just so horribly cludgy. I think the idea of a pre-login form on the authenticated service would be a good idea. You enter your username string user@domain, this sets a identification cookie containing that string and redirects you to your home gateway (using a central list of domain->gateway mappings) . You then provide your password at your home gateway, which then directs you back to the page where you were originally sent from. No nasty WAYF pages.
Not working heavily on AAI stuff other than eduroam, I can take it easy here and just say: *shrug* however you implement it, I don't particularly care.
RADIUS. Put your captive portal behind a AAI infrastructure such as Shibboleth. Workflow is...
Were implementing shibboleth already, due to go live summer 2008...
That way, the user only reveals his credentials to home, not the visited inst. There is a nice paper and prototype impl of this for Shibboleth, I can look up the source if you're interested.
I've read more shibboleth technical documentation than I would care to already, but thanks for the offer .
That one actually made me laugh :-) I guess Shibboleth even beats the legendary 12-pound UNIX manuals.
No, quite. So this would be a kind of walled garden approach using shibboleth for authentication ?
It's not a walled garden: eduroam's sister project eduGAIN (educational GEANT Authentication Infrastructure) provides tools to cross technology borders, i.e. if you have a non-Shibboleth Identity Provider for your credentials and a Shibboleth service, eduGAIN will translate the requests from one language to another and make them interoperate. So, in short, ANY AAI infrastructure will do (as long as an eduGAIN adapter ["bridging element"] exists). So, it's not like you are tied to Shibboleth. We have a cross-federation service already between PAPI and Shibboleth, A-Select soon to come... But I guess we're drifting off-topic here... sorry. Stefan -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473
participants (8)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Arran Cudbard-Bell -
Johan -
Parham Beheshti -
Phil Mayers -
Stefan Winter -
tnt＠kalik.co.yu