Alternative to ClientLogin for Google Apps authentication?
Hi, My organization has a FreeRADIUS server set up to authenticate wifi users with their Google Apps email address and generated app password. It accepts them over EAP in plain text and then runs them against the ClientLogin API in a perl script. Google has deprecated ClientLogin and is cutting it off in April this year. I have consulted with a couple cloud radius providers and they say they can keep this system working as it currently does - users create a Google app password, sign into the WiFi network with it, and they get on the network. This is ideal since we can just direct our existing server's IP to the cloud provider, and our hundreds of clients keep working without a single change. Is there any way FreeRADIUS can authenticate against Google with an app password, without ClientLogin being around anymore? I looked into OAuth2 but it looks like that will require all existing clients to manually sign in again and change details, since it'll require interaction to create the first refresh token. A horrifying other option is to start caching user's passwords on the radius server as they are successfully authenticated, so that we have their working config stored, then when Google cuts off the API we authenticate users against a local database of those stored passwords, manually adding/disabling new/old ones for any user changes. Ugly, insecure, and broken. Any advice? Thanks, Dan
On 29 Jan 2015, at 04:26, Daniel Smith <danielesmith@gmail.com> wrote:
Hi,
My organization has a FreeRADIUS server set up to authenticate wifi users with their Google Apps email address and generated app password. It accepts them over EAP in plain text and then runs them against the ClientLogin API in a perl script.
Google has deprecated ClientLogin and is cutting it off in April this year. I have consulted with a couple cloud radius providers and they say they can keep this system working as it currently does
They probably use FreeRADIUS as a backend. I know Cloudessa does at least. They don't support the project in any way though.
- users create a Google app password, sign into the WiFi network with it, and they get on the network. This is ideal since we can just direct our existing server's IP to the cloud provider, and our hundreds of clients keep working without a single change.
Is there any way FreeRADIUS can authenticate against Google with an app password, without ClientLogin being around anymore? I looked into OAuth2 but it looks like that will require all existing clients to manually sign in again and change details, since it'll require interaction to create the first refresh token.
I don't know how they're doing it. But if you have any requests like extra HMAC functions and want to try something with Oauth2, i'd be happy to help out. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Fri, Jan 30, 2015 at 12:04 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 29 Jan 2015, at 04:26, Daniel Smith <danielesmith@gmail.com> wrote: Is there any way FreeRADIUS can authenticate against Google with an app password, without ClientLogin being around anymore? I looked into OAuth2 but it looks like that will require all existing clients to manually sign in again and change details, since it'll require interaction to create the first refresh token.
I don't know how they're doing it. But if you have any requests like extra HMAC functions and want to try something with Oauth2, i'd be happy to help out.
Well we figured out an easy way to solve this - change the perl script that our FreeRADIUS instance is running to authenticate using ClientLogin, to instead connect to pop.gmail.com:995 with an app password. Works perfectly, and no indication I could find anywhere that Google is deprecating it any time soon. One issue however, is that FreeRADIUS now segfaults. If it's ran without -X that is. i.e. if I run "/usr/sbin/radiusd -d /etc/raddb" it starts up and listens for requests, but then the instant an auth is sent it segfaults in SSLeay.so (which is being used by the perl script it's calling). I know, I know, library version mismatches between OpenSSL or something. *However*, if I run "/usr/sbin/radiusd -d /etc/raddb -X" it runs 100% perfectly, doesn't crash, doesn't segfault, everything's A-OK, people authenticate fine. Of course we would prefer to run it without -X as it's messing with our logging. Any advice on how to debug this, or why it would work fine with -X and segfault without it? We're running it in AWS, so the most recent version we have access to is 2.12 unfortunately. This still appears to be an easy fix, since -X gets it working.
I know, I know, library version mismatches between OpenSSL or something. *However*, if I run "/usr/sbin/radiusd -d /etc/raddb -X" it runs 100% perfectly, doesn't crash, doesn't segfault, everything's A-OK, people authenticate fine.
/usr/sbin/radiusd -t Will disable threads, and confirm whether it's a concurrency issue or something else.
Of course we would prefer to run it without -X as it's messing with our logging. Any advice on how to debug this,
Don't bother with 2.1.12. If it still occurs in a more recent version, then run it under valgrind and/or gdb. valgrind --tool=drd will check for concurrency issues. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On 16-04-15 15:42, Arran Cudbard-Bell wrote:
Don't bother with 2.1.12. If it still occurs in a more recent version, then run it under valgrind and/or gdb.
It's actually a known bug in 2.1.12, fixed with https://github.com/alandekok/freeradius-server/commit/ecb3cd1dbedb764ab98532... Running single-threaded also prevents the problem. -- Herwin Weststrate
On Thu, Apr 16, 2015 at 9:46 AM, Herwin Weststrate <herwin@quarantainenet.nl> wrote:
On 16-04-15 15:42, Arran Cudbard-Bell wrote:
Don't bother with 2.1.12. If it still occurs in a more recent version, then run it under valgrind and/or gdb.
It's actually a known bug in 2.1.12, fixed with https://github.com/alandekok/freeradius-server/commit/ecb3cd1dbedb764ab98532...
Running single-threaded also prevents the problem.
I would very much prefer to upgrade, however as of right now I don't have that option. Frustrating to say the least. ClientLogin is being deprecated this Monday, so I need to keep authentication going as a priority, then look at upgrades later. I just tried the -t option in our sandbox, and it runs perfectly. I googled around but couldn't find the implications of this - increased overhead? Or just slightly increased response time due to requests queueing up instead of executing concurrently? Right now we only service 20 or so requests per minute, so I'm not too concerned about performance. Thanks for the help.
On 16 Apr 2015, at 15:13, Daniel Smith <danielesmith@gmail.com> wrote:
On Thu, Apr 16, 2015 at 9:46 AM, Herwin Weststrate <herwin@quarantainenet.nl> wrote:
On 16-04-15 15:42, Arran Cudbard-Bell wrote:
Don't bother with 2.1.12. If it still occurs in a more recent version, then run it under valgrind and/or gdb.
It's actually a known bug in 2.1.12, fixed with https://github.com/alandekok/freeradius-server/commit/ecb3cd1dbedb764ab98532...
Running single-threaded also prevents the problem.
I would very much prefer to upgrade, however as of right now I don't have that option. Frustrating to say the least. ClientLogin is being deprecated this Monday, so I need to keep authentication going as a priority, then look at upgrades later.
I just tried the -t option in our sandbox, and it runs perfectly. I googled around but couldn't find the implications of this - increased overhead? Or just slightly increased response time due to requests queueing up instead of executing concurrently? Right now we only service 20 or so requests per minute, so I'm not too concerned about performance.
Then it'll be fine, just run with -t. It limits the server to processing one request at a time. It may not handle large spikes in traffic well. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
I just tried the -t option in our sandbox, and it runs perfectly. I googled around but couldn't find the implications of this - increased overhead? Or just slightly increased response time due to requests queueing up instead of executing concurrently? Right now we only service 20 or so requests per minute, so I'm not too concerned about performance.
Then it'll be fine, just run with -t.
It limits the server to processing one request at a time. It may not handle large spikes in traffic well.
That may be an issue, we've had APs get kernel panics in the past, and saw 70-80 people re-authenticate in the space of 5 seconds. At any rate we now have a workaround, and as a bonus a great reason to finally push through an upgrade. Thanks guys!
participants (3)
-
Arran Cudbard-Bell -
Daniel Smith -
Herwin Weststrate