PS.. are you planning on using google oauth for your corporate users? or just as guest portal? Cause remember that anyone with a google.com address can join. I have a private branch of the google oauth that limits you to a single google-apps domain and validates that users belong to it. I was in the process of merging it to PF but got sidetracked...but if its something you would use, I can try to get it done.
On Wed, Apr 29, 2020 at 12:39 PM Diego Garcia del Rio <garc...@gmail.com> wrote: > HI Bill > > I guess that it might be messing things up when doing the https redirect > if you have the self-signed cert... the redirection back might be failing > at the browser level? So if you host the portal on http it all works fine? > > what address is the pf server using for the registration vlan? > > On Wed, Apr 29, 2020 at 12:16 PM Bill Handler <bhand...@pcsknox.com> > wrote: > >> Diego, >> >> >> >> Thanks for the quick replies… The 192.0.2.1 address is something built in >> somehow – when I looked it up since it’s a public IP, and it comes back as >> some sort of test network/special use with the comment: >> >> >> >> Addresses starting with "192.0.2.", "198.51.100.", or "203.0.113." are >> reserved for use in documentation and sample configurations. They should >> never be used in a live network configuration. No one has permission to use >> these addresses on the Internet. >> >> >> >> That address is answering back in the packet capture between the PF >> server and the end-system on the registration VLAN. >> >> >> >> Since we’re just testing right now, we have not assigned a public cert to >> the server, but I’m curious that the initial portal interaction is >> unsecured – I’m not sure where in the config to even specify the portal >> address. I did notice that when I clear the browser cache, and visit the >> portal, I get the pop-up for the self-signed cert… However, I still wonder >> why I’m not getting the same pop-up or it’s not accepting the previously >> accepted self-signed cert for that oauth page. >> >> >> >> Thanks, >> >> >> >> Bill >> >> >> >> >> >> *From:* Diego Garcia del Rio <garc...@gmail.com> >> *Sent:* Wednesday, April 29, 2020 10:11 AM >> *To:* Bill Handler <bhand...@pcsknox.com> >> *Cc:* Jonathan Nathanson <jmhnathan...@gmail.com>; >> packetfence-users@lists.sourceforge.net >> *Subject:* Re: [PacketFence-users] Google oauth2 - >> Behavior/Troubleshooting - http vs https >> >> >> >> Hi Bill >> >> >> >> Interesting that of using http it works. I used publicly signed certs for >> my portal. Self signed will just be chaos for the end users unless you can >> push your root ca to the the devices beforehand (a managed fleet, which is >> not my case) >> >> >> >> Now it's clearer that you used the IP and it worked. I wondering what is >> replying with 192.0.2.1 address... but in my case, for DNS requests coming >> from the registration interface, packetfence replies with its own ip... So >> still curious as what's causing this 192 address to be sent back. >> >> >> >> >> >> >> >> On Wed, Apr 29, 2020, 10:37 Bill Handler <bhand...@pcsknox.com> wrote: >> >> Diego, >> >> >> >> Our internal DNS is just set for our data vlan – currently there is no >> DNS record for the PF server in our internal DNS server. The registration >> VLAN only lives on the switch directly connected to NIC 2 on the PF server >> and on my test switches that my testing end-systems are connected to. I >> have an IP on the registration VLAN (172) interface in PF 172.16.172.1 and >> on the VLAN interface on one of my test switches 172.16.172.2; this allows >> me to ensure that, since everything is tagged on the switch to switch and >> to the PF server, I can ping between them. I have the same setup for the >> Isolation VLAN (173 – 172.16.173.x). >> >> >> >> In the install guide/your screenshot, the Portal URL is listed as the >> FQDN of the PF server. That Portal URL is what is shown on the end-system >> browser. I’m using the default PF portal setup, and what is listed is the >> FQDN of the server… >> >> >> >> However, I’m not sure that a DNS entry in our local DNS server would help >> in this instance…The PF server handles DNS/DHCP for the Registration VLAN, >> it only reaches the internal DNS if something is in the passthrough >> correct? In my case PF is spoofing the FQDN in the portal up until the >> point that Google responds back with the token it seems; then PF DNS is >> replying with a 192.0.2.1 IP for the FQDN of the PF server. BTW, in case I >> mis-spoke, I’m replacing the FQDN with the IP address of the Registration >> VLAN Interface on the PF server – 172.16.172.1, and then registration goes >> through, not a different FQDN. >> >> >> >> Going through the process and copying all the URLs that show in the >> browser, I noticed that the site is initially http, but when google is >> called for the account login, it changes to https, and the portal URL is >> listed as https… >> >> >> >> When I change the redirect uri in Google/portal URL in PF from https to >> http it works. Since you have https on your portal, are you using the >> internal PF self-signed cert, or do you have a public cert installed? >> >> >> >> Thanks, >> >> >> >> Bill >> >> >> >> >> >> *From:* Diego Garcia del Rio <garc...@gmail.com> >> *Sent:* Wednesday, April 29, 2020 8:49 AM >> *To:* Bill Handler <bhand...@pcsknox.com> >> *Cc:* Jonathan Nathanson <jmhnathan...@gmail.com>; >> packetfence-users@lists.sourceforge.net >> *Subject:* Re: [PacketFence-users] Google oauth2 - >> Behavior/Troubleshooting - DNS Issue? >> >> >> >> Hi Bill >> >> >> >> I haven't installed pf10 yet. But I think the key item is the fact that >> the registration vlan DNS is not resolving to the correct PF address. Do >> you have any nic or vlan configured with that IP? >> >> >> >> You mention replacing the fqdn for that of the registration vlan. Is that >> provisioned on your own DNS server ? Cause in my case I only have a DNS >> entry for the "management" interface and packetfence uses the same name but >> spoofs the DNS with with registration vlan IP >> >> >> >> Maybe you have more than one registration vlan? >> >> >> >> >> >> >> >> On Wed, Apr 29, 2020, 09:23 Bill Handler <bhand...@pcsknox.com> wrote: >> >> Diego, >> >> >> >> Ran some packet captures on Monday and every time the end-system was >> looking for the IP of the packetfence host – DNS lookup – it was returned >> as a 192.0.2.1. This is some sort of internal IP that PF is using for the >> portal, as it is the default response no matter what is requested. I >> checked this via NSLookup on the end-system. >> >> >> >> Thinking I had messed something up in the initial config/deployment (this >> is still as test environment), I re-built/deployed with a fresh install. >> >> >> >> Once everything was built-out, I had the same results. After entering >> the credentials for Google login, I get the browser window stating that I >> need to log into the network with a ‘connect now’ button. The address >> within the browser shows: >> https://pf428.pcsknox.com/oauth2/callback?code=... >> >> >> >> pf428.pcsknox.com is the hostname/FQDN of the PacketFence server. In >> the capture I see the DNS request for this, but as I said it is returned as >> 192.0.2.1. If I replace the FQDN of the PF server with the Registration >> VLAN interface IP on the PF server, the authentication goes through and I >> get the screen showing that the role has been assigned, and am flipped to >> the correct VLAN. The packet capture shows a DNS query from the end-system >> for “dl.google.com”, which is answered with the correct info. About 2 >> seconds later there is a DNS Query from the end-system for “ >> passwordsleakcheck-pa.googleapis.com” which is also answered correctly. >> This is the last DNS request on this VLAN for the end-system. >> >> >> >> So for whatever reason, the system is not authenticating the >> response/token from Google when it is presented from the end-system – I >> think this is what is happening. It seems the process is breaking down >> between the end-system and the FP server when Google sends the token. I’m >> not sure where to look to see where the 192.0.2.1 address is coming from, >> or how to put an ‘A’ record in to the registration vlan dns to point the >> FQDN to the interface’s IP, or what is needed here. To me, it seems like a >> DNS issue on PF. >> >> >> >> Is this possibly a bug in the code? I do have packet captures from the >> end-system, the PF server on the registration vlan interface, and on the >> data vlan interface. >> >> >> >> Just to go over the setup, in case that is part of the issue… >> >> >> >> Hypervisor – Hyper-V 2019 >> >> Centos7 VM with PF 10 installed using documentation from >> https://packetfence.org/doc/PacketFence_Installation_Guide.html . >> 802.1x working fine tied to our AD server; using machine auth and user >> auth, SMS authentication works without issue. The only issue seems to be >> with Oauth. The PF server has 2 NICs, NIC 1 is for the data vlan untagged >> (eth0), NIC 2 is for the other vlans, registration, and isolation (eth1) >> tagged. PF is handing out DHCP on registration/isolation vlans. >> >> >> >> Any help is appreciated. >> >> >> >> Thanks, >> >> >> >> Bill >> >> >> >> *From:* Bill Handler >> *Sent:* Friday, April 24, 2020 4:40 PM >> *To:* Diego Garcia del Rio <garc...@gmail.com> >> *Cc:* Jonathan Nathanson <jmhnathan...@gmail.com>; >> packetfence-users@lists.sourceforge.net >> *Subject:* RE: [PacketFence-users] Google oauth2 - >> Behavior/Troubleshooting >> >> >> >> Diego, >> >> >> >> Thanks for your help and guidance on this… The end-system is getting the >> reply from Google with the authorization code – the Portal URL in the >> config that ends in ‘/callback’. However, the hostname of the pf server is >> not being resolved. If I replace the hostname.domain with the IP address >> of the registration VLAN interface on the PF server (the end-system’s >> gateway), the authentication proceeds and the end-system authenticates. >> >> >> >> Weirdness abounds… I’ll perform a packet capture on Monday when I’m back >> in the office to see if I can tell what the end-system is requesting for >> ‘website’ that google returns. >> >> >> >> Have a good weekend, and thanks again for your assistance. >> >> >> >> Thanks, >> >> >> >> Bill >> >> >> >> *From:* Diego Garcia del Rio <garc...@gmail.com> >> *Sent:* Friday, April 24, 2020 10:29 AM >> *To:* Bill Handler <bhand...@pcsknox.com> >> *Cc:* Jonathan Nathanson <jmhnathan...@gmail.com>; >> packetfence-users@lists.sourceforge.net >> *Subject:* Re: [PacketFence-users] Google oauth2 - >> Behavior/Troubleshooting >> >> >> >> Hi.. those errors are not errors. They are jus the logs of pfdns and its >> still related to the user trying / reaching google. >> >> >> >> you should look at the logs (especially packetfence.log) for any other >> messages around the time. Most of the log messages SHOULD have the mac >> address of the device trying to connect so you can grep for those >> >> >> >> (you can also use grep -i to make grep case insensitive, so "grep -i >> oauth" should find... all variations of oauth.. >> >> >> >> also try to set the debug level for the portal module to dEBUG or TRACE: >> >> >> >> like this: >> >> >> >> conf/log.conf.d/pfqueue.conf >> >> >> >> Change to following line from this >> >> >> >> log4perl.rootLogger = INFO, PFQUEUE >> >> >> >> To this >> >> >> >> log4perl.rootLogger = TRACE, PFQUEUE >> >> >> >> Then you can either wait 5 minutes (that is the time it takes for the >> >> logging level to be updated) >> >> >> >> Or restart the service if you do not want to wait. >> >> >> >> But adapt it to the portal module instead of pfqueue.conf >> >> >> >> On Fri, Apr 24, 2020 at 11:14 AM Diego Garcia del Rio <garc...@gmail.com> >> wrote: >> >> let me check what I have configured. But i think you do need n API >> enabled. >> >> >> >> On Fri, Apr 24, 2020 at 11:12 AM Bill Handler <bhand...@pcsknox.com> >> wrote: >> >> Again, apologies for my ignorance on this… >> >> >> >> When I created the Oauth credentials in the Google Developer site, I did >> not enable an API. I’m thinking I missed doing that. Since I’m just >> trying to authenticate users and not accessing anything within GSuite or >> anything else along those lines, I’m not sure what API I may need. >> >> >> >> Ideas? >> >> >> >> Thanks, >> >> >> >> Bill >> >> >> >> *From:* Bill Handler >> *Sent:* Friday, April 24, 2020 8:36 AM >> *To:* Diego Garcia del Rio <garc...@gmail.com> >> *Cc:* Jonathan Nathanson <jmhnathan...@gmail.com>; >> packetfence-users@lists.sourceforge.net >> *Subject:* RE: [PacketFence-users] Google oauth2 - >> Behavior/Troubleshooting >> >> >> >> Diego, >> >> >> >> Thanks for the pointers. The logs appear to be now located in the >> /usr/local/pf/logs directory. There is no logs folder in the >> /usr/local/pf/var directory. >> >> >> >> I ran the restart command and tried to log in via Google again… >> Rechecked the logs as I did before (grep OAuth), ran it a second time as >> ‘grep oauth’ and now got some responses… (this is with the openid defaults) >> >> >> >> [root@packetfence_v10 logs]# cat *.log | grep OAuth >> >> Apr 24 07:33:37 packetfence_v10 packetfence: INFO -e(243390): Adding >> Forward rules to allow connections to the OAuth2 Providers and passthrough. >> (pf::iptables::generate_passthrough_rules) >> >> >> >> [root@packetfence_v10 logs]# cat *.log | grep oauth >> >> Apr 24 07:43:35 packetfence_v10 haproxy[244351]: 172.16.172.237:50335 >> [24/Apr/2020:07:43:35.454] portal-http-192.0.2.1 172.16.174.1-backend/ >> 127.0.0.1 0/0/1/210/213 302 928 - - ---- 3/2/0/0/0 0/0 {pfv10.pcsknox.com} >> "GET >> /switchto/default_policy+default_registration_policy+default_oauth_policy >> HTTP/1.1" >> >> Apr 24 07:43:41 packetfence_v10 haproxy[244351]: 172.16.172.237:50627 >> [24/Apr/2020:07:43:39.361] portal-http-192.0.2.1 172.16.174.1-backend/ >> 127.0.0.1 0/0/0/1909/1910 302 1410 - - ---- 6/2/0/0/0 0/0 { >> pfv10.pcsknox.com} "POST /oauth2/go HTTP/1.1" >> >> Apr 24 07:44:54 packetfence_v10 haproxy[244351]: 172.16.172.237:51592 >> [24/Apr/2020:07:44:52.404] portal-http-192.0.2.1 172.16.174.1-backend/ >> 127.0.0.1 0/0/0/1827/1829 302 1410 - - ---- 4/2/0/0/0 0/0 { >> pfv10.pcsknox.com} "POST /oauth2/go HTTP/1.1" >> >> Apr 24 07:43:30 packetfence_v10 pfdns: 172.16.172.237 - >> [24/Apr/2020:07:43:30 -0400] "A IN oauthaccountmanager.googleapis.com. >> udp 52 false 512" NOERROR qr,rd,ra 102 61.289551ms >> >> [root@packetfence_v10 logs]# >> >> >> >> I put the old Google Auth config – yours with the userinfo.email settings >> and restarted the pf service. Tried to authenticate the end-system again, >> but still failed… >> >> >> >> Checked the logs as before, and here are the results (duplicate entries >> from above removed for clarity): >> >> >> >> [root@packetfence_v10 logs]# cat *.log | grep OAuth >> >> Apr 24 08:17:32 packetfence_v10 packetfence: INFO -e(7334): Adding >> Forward rules to allow connections to the OAuth2 Providers and passthrough. >> (pf::iptables::generate_passthrough_rules) >> >> >> >> [root@packetfence_v10 logs]# cat *.log | grep oauth >> >> Apr 24 08:14:58 packetfence_v10 haproxy[244351]: 172.16.172.237:60742 >> [24/Apr/2020:08:14:58.422] portal-http-192.0.2.1 172.16.174.1-backend/ >> 127.0.0.1 0/0/1/439/440 302 1482 - - ---- 4/3/0/0/0 0/0 { >> pfv10.pcsknox.com} "POST /oauth2/go HTTP/1.1" >> >> Apr 24 08:27:35 packetfence_v10 haproxy[8300]: 172.16.172.237:51328 >> [24/Apr/2020:08:27:33.905] portal-http-192.0.2.1 172.16.174.1-backend/ >> 127.0.0.1 0/0/0/1787/1788 302 1482 - - ---- 3/2/0/0/0 0/0 { >> pfv10.pcsknox.com} "POST /oauth2/go HTTP/1.1" >> >> Apr 24 08:27:59 packetfence_v10 pfdns: 172.16.172.237 - >> [24/Apr/2020:08:27:59 -0400] "A IN oauthaccountmanager.googleapis.com. >> udp 52 false 512" NOERROR qr,rd,ra 102 23.614118ms >> >> Apr 24 08:27:59 packetfence_v10 pfdns: 172.16.172.237 - >> [24/Apr/2020:08:27:59 -0400] "A IN oauthaccountmanager.googleapis.com. >> udp 52 false 512" NOERROR qr,rd,ra 102 25.300084ms >> >> [root@packetfence_v10 logs]# >> >> >> >> I’m hopeful that this helps, but again, I’m not sure what I’m looking for… >> >> >> >> Thanks, >> >> >> >> Bill >> >> >> >> *From:* Diego Garcia del Rio <garc...@gmail.com> >> *Sent:* Thursday, April 23, 2020 5:26 PM >> *To:* Bill Handler <bhand...@pcsknox.com> >> *Cc:* Jonathan Nathanson <jmhnathan...@gmail.com>; >> packetfence-users@lists.sourceforge.net >> *Subject:* Re: [PacketFence-users] Google oauth2 - >> Behavior/Troubleshooting >> >> >> >> Hi bill >> >> >> >> Please look at ALL the log files under /usr/local/pf/var/logs (the httpd >> logs only cover the requests from the devices). There will be two requests >> going to google.. one where Packetfence is doing NAT for the devices to be >> onboarded (this is the traffic from the user's browser) and then another >> that will go from packetfence itself to google again, using the token >> returned by the customer's browser to get the actual data from the google >> account. >> >> >> >> also, I dont remember if any of the changes to google oauth take effect >> immediately or you need to restart the PF service. (to restart the PF >> service use this script: >> >> >> >> /usr/local/pf/bin/pfcmd service pf restart >> >> >> >> >> >> >> >> >> >> >> >> On Thu, Apr 23, 2020 at 3:37 PM Bill Handler <bhand...@pcsknox.com> >> wrote: >> >> I’m hoping I’ve set up the Google part correctly, if not the >> authentication wouldn’t go through correct? I just needed to setup OAuth >> 2.0 Client IDs. I don’t need any API Keys or Service Accounts correct? In >> the Client ID I listed it as a web application >> >> >> >> Diego, >> >> >> >> Thanks for your help… This is my first experience with PacketFence, and >> I’m feeling my way through it. I’m not entirely sure what all your >> information means, so please pardon my ignorance. >> >> >> >> My Google Auth was set to the default openid that you listed. I changed >> it to the older scope/protected resource urls with no change. >> >> >> >> I know that the request is going out to google, and that something is >> coming back by seeing the url in the end-system’s browser. It seems like >> PF is not authenticating the token. >> >> >> >> I am still unsure what log file the logging entries you pointed out go >> to. I was in the logs folder and ran a ‘cat *.log | grep OAuth’ but came >> back with no results. >> >> >> >> Jonathan, >> >> >> >> We’re not using the A3 variant from HiveManger/Extreme IQ, I’m just >> working with PacketFence straight (Although we are an Extreme Networks >> partner and the AeroHive gear is part of our offerings now… ). PacketFence >> is only handing out DHCP on the registration VLAN, our internal DHCP is >> handing out IPs on our data vlan, Firewall is handing out IPs on guest and >> phone vlans. But, we’re never getting that far – the end-system is not >> being given the role and stays as unregistered. >> >> >> >> httpd.portal.error Log has no entries for today. I did a packet capture >> from the PF server and did see some traffic going to/from Google IP >> addresses, but it was TLS or TCP Acks and I could not tell what the payload >> was… >> >> >> >> Thanks, >> >> >> >> Bill >> >> >> >> *From:* Diego Garcia del Rio <garc...@gmail.com> >> *Sent:* Thursday, April 23, 2020 10:43 AM >> *To:* Jonathan Nathanson <jmhnathan...@gmail.com> >> *Cc:* packetfence-users@lists.sourceforge.net; Bill Handler < >> bhand...@pcsknox.com> >> *Subject:* Re: [PacketFence-users] Google oauth2 - >> Behavior/Troubleshooting >> >> >> >> Hi Jonathan, Bill, >> >> >> >> The device will get the role indeed after a disconnect / CoA but given >> Bill mentions that his other auth methods work... I would be surprised that >> CoA fails for this. Also, he should still be seeing the device having the >> new role. >> >> >> >> Below is my config of the google authentication source (old GUI, sorry). >> >> >> >> >> >> <Pic removed> >> >> >> >> also, i seem to be using the OLD user information scheme / url: >> >> >> >> (look here: >> https://github.com/inverse-inc/packetfence/commit/8f38c0e5b51ff5daf83f1720aef8253059fa1a96 >> ) >> >> >> >> i am using this: >> >> has 'scope' => (isa => 'Str', is => 'rw', default => ' >> https://www.googleapis.com/auth/userinfo.email'); >> has 'protected_resource_url' => (isa => 'Str', is => 'rw', default => ' >> https://www.googleapis.com/oauth2/v2/userinfo'); >> >> >> >> instead of the new defaults which are these: >> has 'scope' => (isa => 'Str', is => 'rw', default => 'openid email >> profile'); >> has 'protected_resource_url' => (isa => 'Str', is => 'rw', default => ' >> https://openidconnect.googleapis.com/v1/userinfo'); >> >> >> >> >> >> basically it looks like this: >> >> >> >> <Pic removed> >> >> >> >> >> >> So maybe your authorized scope in google is for this old schema and not >> the new open-id one? >> >> >> >> Also, keep in mind that accessing the google login portal from mobile >> devices can be tricky. Google blacklists the "embedded" browsers of most >> phones so you need to launch chrome manually or contact google to get an >> exception for your specific APP ID. >> >> >> >> Also, check your logs for any phrase like this: "OAuth2 Error: Failed to >> get the token" >> >> >> >> (look at the code here: >> https://github.com/inverse-inc/packetfence/blob/541c6c8545195881b136bc55edb7cd531594061d/html/captive-portal/lib/captiveportal/PacketFence/DynamicRouting/Module/Authentication/OAuth.pm >> ) >> >> >> >> >> >> you have these two logging entries in the code: (you might need to >> increase the logging level to debug). >> >> >> >> get_logger->info("OAuth2 successfull for username >> ".$self->username); >> $self->source->lookup_from_provider_info($self->username, $info); >> >> * pf::auth_log::record_completed_oauth($self->source->id, >> $self->current_mac, $pid, $pf::auth_log::COMPLETED, >> $self->app->profile->name);* >> >> $self->update_person_from_fields(); >> >> $self->done(); >> } >> else { >> >> *get_logger->info("OAuth2: failed to validate the token, redireting to >> login page."); get_logger->debug(sub { use Data::Dumper; "OAuth2 >> failed response : ".Dumper($response) });* >> pf::auth_log::change_record_status($self->source->id, >> $self->current_mac, $pf::auth_log::FAILED, $self->app->profile->name); >> $self->app->flash->{error} = "OAuth2 Error: Failed to validate >> the token, please retry"; >> $self->landing(); >> >> >> >> >> >> good luck! >> >> >> >> >> >> >> >> >> >> Cheers >> >> >> >> >> >> >> >> >> >> On Thu, Apr 23, 2020 at 3:04 AM Jonathan Nathanson < >> jmhnathan...@gmail.com> wrote: >> >> I had this very similar problem recently. Does A3 manage DHCP in the reg >> VLAN? >> >> >> >> The role should be assigned following a disconnect / COA packet sent to >> the client device to get them to reconnect, I believe. >> >> >> >> You should do a packet trace and check. You might also want to check >> corresponding log entries in httpd.portal.error to see if you can spot the >> issue there. >> >> >> >> Jonathan >> >> >> >> On Thu, 23 Apr 2020 at 01:32, Bill Handler via PacketFence-users < >> packetfence-users@lists.sourceforge.net> wrote: >> >> I’m running on v10, using the default whitelist in the Google Auth >> config. The end system is talking to google, verified with wireshark, and >> by inputting wrong password. >> >> >> >> The end system’s role never gets updated, even though I have a catchall >> rule in place that should move it to a different VLAN. >> >> >> >> I have not done a packet capture on server’s interface yet. The end >> system stays as unregistered, so the issue may be authenticating the token >> between PF and google. >> >> >> >> I’ve only tested using Chrome and Firefox browsers and only if Chrome is >> used does the redirect show accounts.blogger.com in the address field >> after entering the google account credentials. >> >> >> >> Both browser windows show the you may need to login to your network with >> a button; the button sends you back to the AUP. >> >> >> >> Is there a certain log that I would be able to see PF talking to google, >> or just checking wireshark packets? >> >> Thanks, >> >> >> >> Bill >> >> >> >> Sent from my iPad >> >> >> On Apr 22, 2020, at 5:15 PM, Diego Garcia del Rio <garc...@gmail.com> >> wrote: >> >> Just to be sure, do you have all the proper whitelists as well? Its weird >> that the user is directed to accounts.blogger.com... Also, you should be >> able to see your PF server making a request to google to validate the >> returned token. >> >> >> >> >> >> On which version of PF are you? I've been using google auth >> successfully all the way up to 9.2 (I haven tested anything newer though). >> >> >> >> Also, not sure the logic you're using but you might want to check that >> the google source is assigning a role to the device in question.. >> >> >> >> >> >> >> >> On Wed, Apr 22, 2020 at 5:51 PM Bill Handler via PacketFence-users < >> packetfence-users@lists.sourceforge.net> wrote: >> >> Running into an issue with Google oauth2 authentication via Captive >> Portal… >> >> >> >> - Have it configured and set as an External Authentication Source >> - Have all the correct settings on Google Developer site >> >> >> >> What’s happening is that after entering the username/password in the >> Google display on the captive portal, the user is not put into the correct >> VLAN/redirected. Authentication via AD/SMS/E-Mail works without issue. >> >> >> >> If using Chrome Browser, user is redirected to accounts.blogger.com with >> a long string afterwards, within Firefox, the url shows as the portal url >> with “?code=” with a long string – this is the token from Google I believe, >> based on some of the documentation. >> >> >> >> The user stays in the registration VLAN and is not moved to the correct >> role. Not sure where to check to see why the user is not moving. >> >> >> >> Any help is appreciated. >> >> >> >> Thanks, >> >> >> >> Bill >> >> >> >> _______________________________________________ >> PacketFence-users mailing list >> PacketFence-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/packetfence-users >> >> _______________________________________________ >> PacketFence-users mailing list >> PacketFence-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/packetfence-users >> >>
_______________________________________________ PacketFence-users mailing list PacketFence-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/packetfence-users
