Authenticating Users with Google Cloud Identity
-
So if I understand correctly, my client has a domain on Google Workspace called Istitutodonvitale.edu.it
Now with Acme when I create an account, then a certificate for pfs.Istitutodonvitale.edu.it and click on "issue", when I read about an update of the TXT DNS record we are not talking about the DNS on the Internet that manages the public domain on the Internet Istitutodonvitale.edu.it but of the internal domain Istitutodonvitale.edu.it and therefore the DNS TXT record that is updated is that of the PfSense DNS server?
Did I get it right? -
@Gertjan are you abandoning me right now?
-
It's only been 2hrs and he has a real job!
Did you read the docs? https://docs.netgate.com/pfsense/en/latest/packages/acme/index.html
There are also numerous youtube walk-throughs like Lawrence Systems' : https://www.youtube.com/watch?v=gVOEdt-BHDY&t=0s
-
@leonida368 said in Authenticating Users with Google Cloud Identity:
are you abandoning me right now?
Noop.
I've also a hotel to run
hotel = a building full with people, all asking the questions I've never heard before. We all have all the answers in our pockets (Phones), and still people know less every day. And be aware : I'm doing this job (hotel) for 30 years now, so I keep on presuming I saw it all. And every day I proof myself wrong again.@leonida368 said in Authenticating Users with Google Cloud Identity:
I don't have access to anything related to the DNS configuration of the customer's domain.
But you have to if you want to have a certificate that has "pfs.associazionedonvitale.edu.it".
That's what "https" is all about ( !! + !! )
Every Certificate Authority, like Letsencrypt, will ask you this. Without it : no certificate.Example : why can't you get a certificate that says it's "update-servers.microsoft.com" ?
Because you don't have access to the DNS zone of "update-servers.microsoft.com".
If you had, you could get your hands on a certificate right now, and 10 minutes later you can redirect all the PC's on the planet so they download YOUR windows updates, instead of the official ones.
Internet would 'die' one hours later ....So, again : certificates, https etc are serious business. there are rules to know, and respect. Breaking them, or not knowing them can have huge consequences.
Getting a domain name - just for testing - like this :
and 'play' (actually : learn) with it - 11€50 a year. A packet of cigarettes costs more here.
Before ordering : look up of the registrar supports 'Letsencrypt' !
Or : have the registrat generate the certicate for you (check if you can download it !).
If possible, re download the certicate every < 90 days, put the certciate into the pfSense Certificate Manager (manual operation) and you'll be fine. No need for the acme package.
Eventually, you do want to automate this ..@leonida368 said in Authenticating Users with Google Cloud Identity:
But then I don't understand: how does the service carry out the public registration of pfs.associazionedonvitale.edu.it automatically?
As explained above.
Letsencrypt will do a 'dig' for this known sub domain : "hash-1/.well-known/acme-challenge/example.tld"
hash-1 is random generated string by Letsencrypt.
hash-2 : same thing.Btw : Ask your pfSense :
[24.03-RELEASE][root@pfSense.bhf.tld]/root: whois associazionedonvitale.edu.it % IANA WHOIS server % for more information on IANA, visit http://www.iana.org % This query returned 1 object refer: whois.nic.it domain: IT organisation: IIT - CNR address: Via Moruzzi, 1 address: Pisa I-56124 address: Italy contact: administrative name: Marco Conti organisation: IIT - CNR address: Via Moruzzi, 1 address: Pisa I-56124 address: Italy phone: +39 050 315 2123 fax-no: +39 050 315 2113 e-mail: direttore@iit.cnr.it contact: technical name: Maurizio Martinelli organisation: IIT - CNR address: Via Moruzzi, 1 address: Pisa I-56124 address: Italy phone: +39 050 315 2087 fax-no: +39 050 315 2207 e-mail: maurizio.martinelli@iit.cnr.it nserver: A.DNS.IT 194.0.16.215 2001:678:12:0:194:0:16:215 nserver: D.DNS.IT 2a0e:dbc0:0:0:0:0:0:39 45.142.220.39 nserver: DNS.NIC.IT 192.12.192.5 2a00:d40:1:1:0:0:0:5 nserver: M.DNS.IT 2001:1ac0:0:200:0:a5d1:6004:2 217.29.76.4 nserver: NAMESERVER.CNR.IT 194.119.192.34 2a00:1620:c0:220:194:119:192:34 nserver: R.DNS.IT 193.206.141.46 2001:760:ffff:ffff:0:0:0:ca ds-rdata: 41901 10 2 47f7f7ba21e48591f6172eed13e35b66b93ad9f2880fc9bada64f68ce28ebb90 whois: whois.nic.it status: ACTIVE remarks: Registration information: http://www.nic.it/ created: 1987-12-23 changed: 2023-01-20 source: IANA # whois.nic.it Domain: associazionedonvitale.edu.it Status: AVAILABLEThere you have the name, address, everything.
But again : this domain falls under "edu.it" so lets state upfront : forget it. You can't have access to the DNS of that domain, or even a sub domain. Not like 'tomorrow' or so. -
They might be able to issue you a server cert to use of course. Avoid using LetsEncrypt entirely.
-
ok I'll analyze what you wrote to me and pray for me tomorrow
@Gertjan Thank you and I'm so sorry for my intrusiveness -
ok so with this domain I have to forget to use acme ok clear, but I could do it if I had a domain with which I can control DNS management such as one of those cheap domains you showed me. With the latter it is also possible to download the certificate and enter it into pfsense.
But you won't believe it: in the configuration of the captive portal in the SSL/TLS Certificate field I gave the certificate downloaded from the Google Workspace LDAP app.
Well the captive portal works! It's true that the certificate untrusted error message comes up but it works! If so, initially I will continue in this way while waiting to better manage the certificate/domain issue. What do you say?
Thanks -
@leonida368 said in Authenticating Users with Google Cloud Identity:
But you won't believe it: in the configuration of the captive portal in the SSL/TLS Certificate field I gave the certificate downloaded from the Google Workspace LDAP app.
Ah, that would do it!
Yes you should be able to continue with a self-signed cert for now and add a valid cert later if you need to.
-
@stephenw10 good morning, ok then I'll proceed this way. I have 2 more things left:
can you explain this disconnection thing through a dhcp option better? Yesterday while testing on some devices, I noticed that if you call up the captive portal URL the logoff button appears, except that it doesn't always work, why? Furthermore, the director of this school would also like the Internet browsing logs of logged in users, i.e. the websites visited by them.Thanks always
-
@leonida368 said in Authenticating Users with Google Cloud Identity:
n you explain this disconnection thing through a dhcp option better?
In a view words :
The classic captive portal detection behavior :
When a device connects to the portal, it sends a DHCP request out first. it will get back from pfSense an IP, a gateway, a DNS.
Now, the original magic kicks in : look what device does next, right after get an IP address (DHCP lease). An Apple device will launch a hidden 'Safari' browser request to http://captive.apple.com/hotspot-detect.html. Click on this link to see what happens.
You get back a page with the 7 letter word "Success". If "Success" came back, the device knows that it is not on a captive portal - or, to be more precis : it has a direct connection to the Internet.
The fact that "Success" came back also means that DNS worked : the device had to resolve "captive.apple.com" to be able to connect, as a device (web browser doesn't no nothing about host names, it needed an IP to connect to somewhere.What if there was a captive portal ?
Resolving should still work (so if 'nothing seems to work on a captive portal, DHCP and DNS must work on a captive portal !!) so the hidden browser sends the "http://captive.apple.com/hotspot-detect.html".
This is nothing more as a TCP request to a destination IP 17.253.109.201 or 17.253.109.202 (for me, right now).
To see and understand what happens next, look at the pfSense "pf" firewall rules (not the captive portal GUI rules !). You can see them here : /tm/rules.debugFirst, somewhat on the top of the rules :
# Captive Portal ether pass on { igc1 } tag "cpzoneid_2_rdr" ether anchor "cpzoneid_2_auth/*" on { igc1 } ether anchor "cpzoneid_2_passthrumac/*" on { igc1 } ether anchor "cpzoneid_2_allowedhosts/*" on { igc1 }The first rule will 'tag' traffic coming from the connected portal network device with the tag "cpzoneid_2_rdr".
I'll mention the anchors later.
# Captive Portal rdr on igc1 inet proto tcp from any to ! <cpzoneid_2_cpips> port 443 tagged cpzoneid_2_rdr -> 192.168.2.1 port 8003 rdr on igc1 inet proto tcp from any to ! <cpzoneid_2_cpips> port 80 tagged cpzoneid_2_rdr -> 192.168.2.1 port 8002Note 192.168.2.1 is my pfSense captive portal IP.
This rule says :
Incoming TCP traffic, tagged with "cpzoneid_2_rdr", that is send to a destination port 80 = http (or 443 = https) for every possible (= any) destination address is no 'redirected' to 192.168.2.1 port 8002 (or port 8003 for https).Guess what is listing on this address 192.168.2.1 port 8002 ? The captive portal login page web server !
So, the sequence again :
The device sends a web request too "http://captive.apple.com/hotspot-detect.html" using destination port 80 (because : remember : http request).
The pfSense pf firewall will redirect this traffic to 192.168.2.1 port 8002.
The result will be : the login page get send back as an answer to the request.The device doesn't get back the result "Success" but a page full with something else, the captive portal login page. The device will now open up a web browser instance, and repeat repeat everything it just did.
The result will be : the user holding the device sees a web page : the captive portal login page.The new method base on RFC 8910 :
Remember the essential DHCP sequence ?
What if the DHCP gave more then just an IP, gateway and DNS ?
If it gives a special option number "114", part of the RFC, that says : "Here is an URL that you need to visit if you want an Internet connection ?"
Now, the portal visiting devices will know straight away where to go to get an captive portal login page. This method is way faster, needs less 'hassle', easier to implement.
It works for some 'modern' devices already, like Apple devices and other devices with recent OSes.
When connected to te portal, and I open the Wifi properties, I see this :
When I open the blue link (translated) "Open the portal page" while connected, I see :
I see this default page because I didn't put in place my own "home made" Logout page.
When I click on Disconnect, I will be disconnected from the portal.True : ordinary uses don't look at the properties of their (Wifi) connection, so they won't find this open easily.
You could inform the user on the LOGIN page that the user should visit his Wifi properties to disconnect. Very view will actually do so ...The "RFC 8910" can be added to pfSense with the upload of one file - shown in the other thread and the addition of a DHCP option, as shown in the other thread.
So easy to implement. -
@Gertjan ok I'll study this solution and then implement it. In the meantime I wanted to use the Idle timeout (Minutes) field set to 2min, then asking the teacher on duty who finishes his lesson to disable the wifi otherwise even if no one is surfing on the device, in Status / Captive Portal the Last Activity field increases always even if the PC is not used (probably for a series of background processes that require connectivity), so there must be a total lack of connectivity.
I tried with my device: I log in to the portal, then I deactivate the wifi and continuously refresh the Status / Captive Portal page. Well, an unpleasant surprise! the Last Activity field always increments, so the user on my device will never log out! How is it possible? How can I solve it?
Thank you -
@leonida368 said in Authenticating Users with Google Cloud Identity:
Furthermore, the director of this school would also like the Internet browsing logs of logged in users, i.e. the websites visited by them.
That is an entirely different problem and one that is not easily solved. The only way to actually see all the URLs visited is to install Squid proxy and force all users to use it. I would try to avoid doing that if at all possible!
-
@stephenw10 This is really a big problem, the manager wanted authentication with Google Workspace precisely so that in case of problems he can always trace the person who committed the infringement (e.g. child pornography sites). Do you think that in another school there are saw the postal police arrive.
They as public institutions are held to stringent navigation constraints including the retention of navigation logs for a certain period. -
OK, well to do that you need to use an Authenticated proxy so in pfSense that means Squid. But you should be aware that Squid will likely be deprecated at some point unless it gets updated:
https://www.netgate.com/blog/deprecation-of-squid-add-on-package-for-pfsense-softwareThe captive portal by itself will not log traffic directly. It will log users against the IPs they are given though. You can use that along with flow records to see what IP addresses were accessed but not FQDNs.
To see full URLs requires a proxy with full SSL interception.
-
what I don't understand is why Netgate is deprecating Squid but then doesn't have a viable alternative to it.
At this point I would be better off installing a package like pfBlocker-NG on PFS which is not a proxy but uses another technology for content filtering but at least produces some logs. What do you say -
As mentioned by @stephenw10 proxing your captive portal clients is ..... let me paraphrase this :
You just bought a car, and you're somewhat manage to actually drive without touching other object and people. Great.
Now you want to join the F1 in Monaco to try to beat Verstappen because 'why not' as you think you can drive ....@leonida368 said in Authenticating Users with Google Cloud Identity:
what I don't understand is why Netgate is deprecating Squid
If squid was a process with some libraries and some basic 'ethernet' needs, it would be easy : write a GUI part that takes care of the process's settings files, and some process control code and done.
This isn't the case with squid. Squid is as big and complex as pfSense, probably more.
A proxy isn't a firewall, it isn't a router, it needs to access the actual data stream.
But, as you already know, you can not 'crack' TLS. If you could, everybody could, and security world wide would fail .... Worlds economic would fail. School will be over. Issue solved.
To really answer this question, you have to know what squid is, how it works, how how to admin it.A proxy would have to intercept a TLS communication. To do this, the device that is used by the client has to be 'modified' so it uses a proxy, not an open Internet connection.
You've probably se this option in a browser or OS setting without giving it to much though.
This situation is the contrary of a captive portal, as you do not admin the devices the visitors use : you even don't know who they are, what devices they use. When they connect.
You couldn't really create a captive portal login page where you state :Please go to the local administrator (== you) on the first floor so the administrator can modify your device so it uses our proxy from now on. En when you leave the premises, please visit me again so I undo these modifications again.
Added to that, there are many sites, every day more and more, that do not work when you (your portal clients) are using a proxy. So you have to mange a list with 'exceptions'.
There is a reasonable "plan B" : most sites that offer content that you don't want to make avaible for your portal visitors are part of lists, full with IP addresses or host names (DNSBL).
That why pfBlockerng exists. It will block the resolving of the host name p#ornhub.com and/or block the access to certain known IPs.@leonida368 said in Authenticating Users with Google Cloud Identity:
Do you think that in another school there are saw the postal police arrive.
Plan C : route all captive portal traffic out over a VPN connection. Get in VPN endpoint outside of Europe. Local (or European) law keepers won't bother you anymore ^^ because VPN == TLS and 'they' can't break it neither.
-
@leonida368 said in Authenticating Users with Google Cloud Identity:
ok I'll study this solution and then implement it. In the meantime I wanted to use the Idle timeout (Minutes) field set to 2min, then asking the teacher on duty who finishes his lesson to disable the wifi otherwise even if no one is surfing on the device, in Status / Captive Portal the Last Activity field increases always even if the PC is not used (probably for a series of background processes that require connectivity), so there must be a total lack of connectivity.
I tried with my device: I log in to the portal, then I deactivate the wifi and continuously refresh the Status / Captive Portal page. Well, an unpleasant surprise! the Last Activity field always increments, so the user on my device will never log out! How is it possible? How can I solve it?
Thank youplease can you answer this too?
-
You mean :
goes up and up without even a cable connected to the pfSense captive portal interface ? Or Wifi radio shut down ?
Look here : Diagnostics> Limiter Info
There is a limiter / scheduler for every individual connected portal user. It's these pipes that are also used to count send / received bytes.
These pipes are MAC/IP based, so another IP/MAC can not 'pollute' your pipe.
When I connect my phone : user 'x' :
and right after connection I switch to another Wifi, the Last activity will stay at "09:10:32" as my device isn't part of the portal network anymore.
I'm not sure how to solve this issue, as it isn't an issue for me.
@leonida368 said in Authenticating Users with Google Cloud Identity:
(probably for a series of background processes that require connectivity)
Oh, you didn't know that ? If you power on a PC, even before you can enter a password, it has already communicated with 'other devices', Internet included, a lot.
edit at 09h37 :
still 09:10:32 ....
-
hi @Gertjan, basically what I mean is that if for example I set the Idle timeout (Minutes) field to 1min, even if I disable wifi on the device, the user session disconnects at least after 10min if not more. I think this is a problem.
-
I've set my "Idle timeout (Minutes)" to 1 minute.
<166>1 2024-05-28T12:42:34.743231+02:00 pfSense.brit-hotel-fumel.net logportalauth 70503 - - Zone: cpzone1 - ACCEPT: x, e0:92:5c:d9:6c:fe, 192.168.2.6 <166>1 2024-05-28T12:44:21.624258+02:00 pfSense.brit-hotel-fumel.net logportalauth 88950 - - Zone: cpzone1 - IDLE TIMEOUT: x, e0:92:5c:d9:6c:fe, 192.168.2.612:44:21 - 12:42:34 = 107 seconds or 1 minutes 47 seconds.
The portal prune task executes every 60 seconds :
[24.03-RELEASE][root@pfSense.bhf.tld]/var/log: ps ax | grep 'prune' 5641 - Is 0:00.00 /usr/local/bin/minicron 60 /var/run/cp_prunedb_cpzone1.pid /etc/rc.prunecaptiveportal cpzone1so 1:47 could be right.
"Idle timeout (Minutes)" set to "1 minute" is, IMHO, not a useful setting. Something like 60 minutes, or more, seems far more seasonable to me.
