subject:"\[PacketFence\-users\] Google oauth2 \- Behavior\/Troubleshooting"

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting - http vs https

2020-04-29 Thread Diego Garcia del Rio via PacketFence-users

Hi Bill

For 802.1x I'm really not in the loop I seem to recall having seen this
question (or something similar) floating around... but no clue.

For chromebooks... you might be able to use the new "secure LDAP"  option
that google provides.. maybe I guess it all depends whether you want to
authenticate the machine or the user.



On Wed, Apr 29, 2020, 13:09 Bill Handler  wrote:

> Diego,
>
>
>
> If I set to http everything works as it should.  The Google authentication
> is strictly for guest, and to verify it can be done.  For people that have
> google domains, we’d limit it to their own google domain for internal
> access.  What I’m curious about is using 802.1x for authenticating managed
> Chromebooks – We’d likely have to pull them from the google domain and
> import them into radius I image…
>
>
>
> I do have another question, if you know…  While 802.1x works, I want to
> throw in a curveball.  On other NAC solutions, we’re able to use 802.1x for
> the user and machine.  i.e. the machine connects to the network wired or
> wirelessly and authenticates against AD via servicePrincipalName and gets
> its machine profile.  When a user logs in, the machine account
> deauthenticates/logs out, and the user is authenticated using
> sAMAccountName and gets their user profile.  I’ve noticed that while PF
> picks up the username when they log in, the profile does not flip to the
> user.  The connection profile lists the domain user auth source first, so
> it should hit that first when the user logs in.  It seems that the machine
> is not logging out/deauth-ing when the user logs in and/or since PF
> recognizes the machine, it just keeps the existing profile.
>
>
>
> Thanks,
>
>
>
> Bill
>
>
>
>
>
> *From:* Diego Garcia del Rio 
> *Sent:* Wednesday, April 29, 2020 11:48 AM
> *To:* Bill Handler 
> *Cc:* Jonathan Nathanson ;
> packetfence-users@lists.sourceforge.net
> *Subject:* Re: [PacketFence-users] Google oauth2 -
> Behavior/Troubleshooting - http vs https
>
>
>
> 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 
> 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 
> 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 
> *Sent:* Wednesday, April 29, 2020 10:11 AM
> *To:* Bill Handler 
> *Cc:* Jonathan Nathanson ;
> 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 befo

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting - http vs https

2020-04-29 Thread Bill Handler via PacketFence-users

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 
Sent: Wednesday, April 29, 2020 10:11 AM
To: Bill Handler 
Cc: Jonathan Nathanson ; 
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 
mailto: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 mailto:garc...@gmail.com>>
Sent: Wednesday, April 29, 2020 8:49 AM
To: Bill Handler mailto:bhand...@pcsknox.com>>
Cc: Jonathan Nathanson mailto:jmhnathan...@gmail.com>>; 
packetfence-users@lists.sourceforge.net<mailto: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 
mailto:bhand...@pcsknox.com>&

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting - http vs https

2020-04-29 Thread Diego Garcia del Rio via PacketFence-users

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 
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 
> 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 
>> *Sent:* Wednesday, April 29, 2020 10:11 AM
>> *To:* Bill Handler 
>> *Cc:* Jonathan Nathanson ;
>> 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  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;

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting - http vs https

2020-04-29 Thread Diego Garcia del Rio via PacketFence-users

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  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 
> *Sent:* Wednesday, April 29, 2020 10:11 AM
> *To:* Bill Handler 
> *Cc:* Jonathan Nathanson ;
> 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  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 
> *Sent:* Wednesday, April 29, 2020 8:49 AM

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting - http vs https

2020-04-29 Thread Diego Garcia del Rio via PacketFence-users

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  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 
> *Sent:* Wednesday, April 29, 2020 8:49 AM
> *To:* Bill Handler 
> *Cc:* Jonathan Nathanson ;
> 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  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

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting - http vs https

2020-04-29 Thread Bill Handler via PacketFence-users

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 
Sent: Wednesday, April 29, 2020 8:49 AM
To: Bill Handler 
Cc: Jonathan Nathanson ; 
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 
mailto: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<http://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<http://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<http://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.

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting - DNS Issue?

2020-04-29 Thread Diego Garcia del Rio via PacketFence-users

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  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 
> *Cc:* Jonathan Nathanson ;
> 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 
> *Sent:* Friday, April 24, 2020 10:29 AM
&

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting - DNS Issue?

2020-04-29 Thread Bill Handler via PacketFence-users

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 
Cc: Jonathan Nathanson ; 
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 mailto:garc...@gmail.com>>
Sent: Friday, April 24, 2020 10:29 AM
To: Bill Handler mailto:bhand...@pcsknox.com>>
Cc: Jonathan Nathanson mailto:jmhnathan...@gmail.com>>; 
packetfence-users@lists.sourceforge.net<mailto: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 y

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting

2020-04-24 Thread Bill Handler via PacketFence-users

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 
Sent: Friday, April 24, 2020 10:29 AM
To: Bill Handler 
Cc: Jonathan Nathanson ; 
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 
mailto: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 
mailto: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 mailto:garc...@gmail.com>>
Cc: Jonathan Nathanson mailto:jmhnathan...@gmail.com>>; 
packetfence-users@lists.sourceforge.net<mailto: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<http://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<http://127.0.0.1> 
0/0/1/210/213 302 928 - -  3/2/0/0/0 0/0 
{pfv10.pcsknox.com<http://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<http://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<http://127.0.0.1> 
0/0/0/1909/1910 302 1410 - -  6/2/0/0/0 0/0 
{pfv10.pcsknox.com<http://pfv10.pcsknox.com>} "POST /oauth2/go HTTP/1.1"
Apr 24 07:44:54 packetfence_v10 haproxy[244351]: 
172.16.172.237:51592<http://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<http://127.0.0.1> 
0/0/0/1827/1829 302 1410 - -  4/2/0/0/0 0/0 
{pfv10.pcsknox.com<http://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<http://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 t

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting

2020-04-24 Thread Diego Garcia del Rio via PacketFence-users

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 
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 
> 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 
>> *Cc:* Jonathan Nathanson ;
>> 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[244

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting

2020-04-24 Thread Bill Handler via PacketFence-users

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 
Cc: Jonathan Nathanson ; 
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 mailto:garc...@gmail.com>>
Sent: Thursday, April 23, 2020 5:26 PM
To: Bill Handler mailto:bhand...@pcsknox.com>>
Cc: Jonathan Nathanson mailto:jmhnathan...@gmail.com>>; 
packetfence-users@lists.sourceforge.net<mailto: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:3

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting

2020-04-24 Thread Diego Garcia del Rio via PacketFence-users

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  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 
> *Cc:* Jonathan Nathanson ;
> 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 
> *Sent:* Thursday, April 23, 2020 5:26 PM
> *To:* Bill Handler 
> *Cc:* Jonathan Nathanson ;
> packetfence-users@lists.sourceforge.net
> *Subject:* Re: [PacketFence-users] Google oauth2 -
> Behavior/Troubleshooting
>
>
>
> Hi bill
>
>
&

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting

2020-04-24 Thread Bill Handler via PacketFence-users

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 
Sent: Thursday, April 23, 2020 5:26 PM
To: Bill Handler 
Cc: Jonathan Nathanson ; 
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 
mailto: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 some

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting

2020-04-23 Thread Diego Garcia del Rio via PacketFence-users

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  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 
> *Sent:* Thursday, April 23, 2020 10:43 AM
> *To:* Jonathan Nathanson 
> *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).
>
>
>
>
>
> 
>
>
>
> 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:
>
>
>
> 
>
>
>
>
>
> 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/packetf

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting

2020-04-23 Thread Bill Handler via PacketFence-users

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 
Sent: Thursday, April 23, 2020 10:43 AM
To: Jonathan Nathanson 
Cc: packetfence-users@lists.sourceforge.net; Bill Handler 
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).




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:




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 
mailto: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

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting

2020-04-23 Thread Jonathan Nathanson via PacketFence-users

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 
> 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

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting

2020-04-22 Thread Bill Handler via PacketFence-users

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 
mailto: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 
mailto: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] Google oauth2 - Behavior/Troubleshooting

2020-04-22 Thread Bill Handler via PacketFence-users

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

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting - http vs https

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting - http vs https

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting - http vs https

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting - http vs https

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting - http vs https

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting - http vs https

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting - DNS Issue?

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting - DNS Issue?

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting

Re: [PacketFence-users] Google oauth2 - Behavior/Troubleshooting

[PacketFence-users] Google oauth2 - Behavior/Troubleshooting

18 matches

Site Navigation

Mail list logo

Footer information