Unreliable?

[timmrogers]

I've been using this app together with Untangle with great success at our school for about a year.

I disabled it for the summer, and at the start of the school year. My goal was to begin using it again today. Testing seemed fine, so I had no concerns.

However, while perhaps 1 in 25 students were able to authenticate normally, most could not. And Google notified me of multiple "suspicious logins" for users trying to authenticate.

Are you still finding that that application works reliably for you? Had Google perhaps changed something on their end that might make it not be so?

I really appreciate this application, and I'd love to be able to continue to use it. Thank you.

[ghost]

Yes, I had the issue you described when the headless browser method of authentication was used. As of version 0.4, that method is no longer used. Can you confirm that you have updated to version 0.4 or later?

[timmrogers]

Thanks for the reply, Tim.

I don't see a way to display the version. But I did a fresh install on a
new server a month ago or so, so I assume that I am using the latest
version. Is there that I can confirm that?

On Mon, Oct 5, 2015 at 9:18 AM Tim Cooper [email protected] wrote:

Yes, I had the issue you described when the headless browser method of
authentication was used. As of version 0.4, that method is no longer used.

Can you confirm that you have updated to version 0.4 or later?

—
Reply to this email directly or view it on GitHub
#3 (comment)
.

[ghost]

Run the following command in the folder where the program is installed. You should hopefully see similar output:

% npm version
{ 'google-apps-radius': '0.4.1',
  npm: '3.3.5',
  ares: '1.10.1-DEV',
  http_parser: '2.5.0',
  modules: '46',
  node: '4.1.1',
  openssl: '1.0.2d',
  uv: '1.7.4',
  v8: '4.5.103.33',
  zlib: '1.2.8' }

[ghost]

If you do find yourself on version 0.4 or later, log in to Google via a web browser before trying google-apps-radius again. You may have to convince Google's security system that you are a legitimate.

[timmrogers]

Looks like I do have Version 0.4.1.

trogers@server-6:/usr/local/lib/node_modules/google-apps-radius$ npm version
{ http_parser: '1.0',
node: '0.10.29',
v8: '3.14.5.8',
ares: '1.10.0',
uv: '0.10.27',
zlib: '1.2.8',
modules: '11',
openssl: '1.0.1k',
npm: '1.4.21',
'google-apps-radius': '0.4.1' }
trogers@server-6:/usr/local/lib/node_modules/google-apps-radius$

The odd thing is, it works fine for my account. And for a few of our
students. But most are getting rejected - and I'm getting security
warnings. Google clearly isn't happy with this.

Am I right that you are authenticating by opening a SMTP message and
verifying the username/password that way?

On Mon, Oct 5, 2015 at 9:58 AM Tim Cooper [email protected] wrote:

Run the following command in the folder where the program is installed.
You should hopefully see similar output:

% npm version
{ 'google-apps-radius': '0.4.1',
npm: '3.3.5',
ares: '1.10.1-DEV',
http_parser: '2.5.0',
modules: '46',
node: '4.1.1',
openssl: '1.0.2d',
uv: '1.7.4',
v8: '4.5.103.33',
zlib: '1.2.8' }

—
Reply to this email directly or view it on GitHub
#3 (comment)
.

[ghost]

Am I right that you are authenticating by opening a SMTP message and verifying the username/password that way?

That is correct.

I am reading from this Google page that accounts need to "have cleared the CAPTCHA word verification test", in order to log in via SMTP. Perhaps you can get those accounts who are having issues to log in to Gmail on a device already on the network, then have them connect via radius.

[timmrogers]

I was just looking at that same Google page! But all of our students are
using Google Apps (and Haiku LMS via Google Apps) daily. I don't believe
that any have not "cleared the CAPTCHA word verification test" - unless
that needs to be done again under some circumstances. I'll follow up on
that.

I'm curious though. Is there some more supported way to do what you are
doing? Does Google not offer an API or some other approach to authenticate?
Seems like they would.

On Mon, Oct 5, 2015 at 10:18 AM Tim Cooper [email protected] wrote:

Am I right that you are authenticating by opening a SMTP message and
verifying the username/password that way?

That is correct.

I am reading from this Google page
https://support.google.com/a/answer/176600 that accounts need to "have
cleared the CAPTCHA word verification test", in order to log in via SMTP.
Perhaps you can get those accounts who are having issues to log in to Gmail
on a device already on the network, then have them connect via radius.

—
Reply to this email directly or view it on GitHub
#3 (comment)
.

[ghost]

I'm curious though. Is there some more supported way to do what you are doing? Does Google not offer an API or some other approach to authenticate? Seems like they would.

As far as I can tell, they do not.

The way they would like people to authenticate is using OAuth, however, this is not possible without first letting users online (white-listing Google's domains through your captive portal may not be such a bad thing, though; I believe this is how packetfence does it). You could also build a system where the passwords are stored on site, meaning the external connection to Google for radius authentication is not needed.

[timmrogers]

OAuth 2.0 seems like it is the right approach. Could just whatever
server(s) are needed for it be white-listed? Any idea how complex that
would be to implement?

Wow. The SSO seems overwhelming! And I've been working with systems like
this for a while now. But that reads like greek, even to me.

On Mon, Oct 5, 2015 at 10:39 AM Tim Cooper [email protected] wrote:

I'm curious though. Is there some more supported way to do what you are
doing? Does Google not offer an API or some other approach to authenticate?
Seems like they would.

As far as I can tell, they do not.

The way they would like people to authenticate is using OAuth, however,
this is not possible without first letting users online (white-listing
Google's domains through your captive portal may not be such a bad thing,
though; I believe this is how packetfence does it). You could also build a
system where the passwords are stored on site
https://support.google.com/a/answer/60224, meaning the external
connection to Google for radius authentication is not needed.

—
Reply to this email directly or view it on GitHub
#3 (comment)
.

[ghost]

OAuth 2.0 seems like it is the right approach. Could just whatever server(s) are needed for it be white-listed? Any idea how complex that would be to implement?

A system like packetfence should provide this functionality for you.

Wow. The SSO seems overwhelming! And I've been working with systems like this for a while now. But that reads like greek, even to me.

So far the SMTP authentication method has worked for us. If it ever stops working, I'll mostly likely investigate other ways to do the authentication, include, perhaps, creating a new package to simplify SSO integration.

[ghost]

Another thing to note: a commercial product called ironwifi uses IMAP for authentication:

If your users wish to authenticate using their existing Google passwords, enable IMAP access for your Google Apps account. IronWifi uses this secure protocol to remotely authenticate your users.

It is possible that Google's security is less likely to lock someone out of IMAP access, compared to SMTP access. This is something else worth investigating.

[timmrogers]

Thanks, Tim.

As I explored this over the summer, I was able to duplicate your
functionality with Python - which I am more familiar with. It always worked
nicely for me...as did your utility, until now. I'll explore the IMAP
approach, when I can find some time.

Thanks very much for the utility - and the discussion.

On Tue, Oct 6, 2015 at 5:40 AM Tim Cooper [email protected] wrote:

Another thing to note: a commercial product called ironwifi uses IMAP for
authentication https://www.ironwifi.com/google-apps/:

If your users wish to authenticate using their existing Google passwords,
enable IMAP access for your Google Apps account. IronWifi uses this secure
protocol to remotely authenticate your users.

It is possible that Google's security is less likely to lock someone out
of IMAP access, opposed to SMTP access. This is something else worth
investigating.

—
Reply to this email directly or view it on GitHub
#3 (comment)
.

[bravo2]

I am facing the same issue with google apps authentication. I changed this code to use IMAP instead of SMTP for authentication. But IMAP also gives the same error as SMTP auth:
Error: Please log in via your web browser: https://support.google.com/mail/accounts/answer/78754 (Failure)
Is there any other suggestion/work-around than I can try? PacketFence seems to be a little heavy-weight for my use-case.

[ghost]

Could you try logging in from your browser to first unlock the account, followed by adding your network's IP address(es) in either (or both) of the following places:

• https://support.google.com/a/answer/60730
• https://support.google.com/a/answer/60751

After a week or so, let us know if your accounts get locked out again.

[bravo2]

Thanks bontibon for your attention here. I do understand the reason and the ClientLogin requirement to authenticate first via browser. I haven't tried the email whitelist yet though.

I am planning to use this with pfsense captive portal authentication and I cannot ask all users to login via browser first. Even for a few who tried the browser login, the authentication attempts from google-apps-radius module failed with response code 534. It could be due to the lack of email whitelist entry, as you pointed out above.

I have it working now with a change to return authentication success if the SMTP response code is 534. Would you like a PR for this?

[ghost]

Thanks for the information, @bravo2. Unfortunately, due to licensing, I would not be able to accept your pull request.

I am able to change the authenticator to treat a 534 response as a login success, but I'm a little hesitant to do so. The reason being it that Google does not include 534 on their list of SMTP response codes. You will also note that code 535's description is listed as "Please log in with your web browser and then try again". 535 is also used for standard "username and/or password incorrect" errors.

I suppose another fix for this would be to check the SMTP authentication status string for the text "Please log in via your web browser". I could only do that, though, if I knew for certain that that message is only shown when a user provides correct credentials, which I am still not 100% sure of.

[bravo2]

I see your point. In fact, I did write up a working solution with imap login (instead of smtp) which checks the error response text for "Please log in via your web browser". But I switched back to smtp as it gives a more accurate response code I can rely on.

Per IANA SMTP Enhanced Status Codes Registry, 534 indicates weaker auth type whereas 535 is auth failure. Does google's list of SMTP response codes have a typo where it uses 535 instead of 534?