Authenticating Users with Google Cloud Identity

Gertjan

@leonida368 said in Authenticating Users with Google Cloud Identity:

I see that among the PfSense packages there is Acme Certificates. Should I use this?

@Gertjan said in Authenticating Users with Google Cloud Identity:

That's why where the pfSense package ACME comes in handy : it will 'arrange' a trusted certificate for you.

leonida368

Good morning, today I will dedicate myself to generating the certificate using this Acme Certificates package in order to close the captive portal configuration with authentication with Google Workspace (tomorrow I will be at the customer's site, DAY OF TRUTH!). Before starting I ask:

based on what logic does Letencrypt check if I own the customer's domain?

@Gertjan said in Authenticating Users with Google Cloud Identity:

I checked "Enable logout popup window"

You don't need it.
Must users, yourself included, have already disabled those nasty popup windows ages ago.
So that windows never (or very rarely) pops up.

If the popup doesn't appear, how will the user log out of their session?

A thousand thanks

Gertjan

@leonida368 said in Authenticating Users with Google Cloud Identity:

based on what logic does Letencrypt check if I own the customer's domain?

Oh...
You found the site of letsencrypt. They tell you the why, what, when : Getting started.

Basically, it goes like this :
The client app, acme.sh in this case, or certbot, or whatever other app/script/code start, and connects to letencrypt with your "ID" (some sort of account).
The client; acme;sh, tells letencrypt : I want a cert for example.tld.
letencrypt give the client back a code ([hash-1]) to be used as a "file name" and a code ([hash-2]) to be put into this file.

The client now accesses the registrar using the method the registrar offers : the default, ancient method is called "RFC 2136" and uses 'nsupdate', who connects itself to the master domain name server, and adds into to the domain name zone this very exact sub domain : .well-known/acme-challenge/.
So in the sub domain a text (TXT) record is created, called hash-1.
The content of hash-1 will be hash-2.
Exactly like the creation of a creating a A record in the sub domain "www", and the A record contains ... the IPv4 of your web site.

When our client (acme.sh) has created successfully this hash-1/.well-known/acme-challenge/example.tld, then you might want need to 'wait' bit, hence the delay field.
When the wait is over, the client signals letsencrypt that it can starting checking.

What does letsencrypt ? Easy : it resolves (it uses 'dig' of course !) for a TXT record at hash-1/.well-known/acme-challenge/example.tld and it should get back hash-2.
If it find it, then you have proven that you can access = control the domain "example.tld".
letsencrypt will now create a certificate for your domain and sign it, and send it over to the client.

Why the wait (DNS-Sleep) ? Because the acme client updates the master domain name server. When done, this master will signal all the domain name slaves. These slaves decide when they sync up with the master. This syncying has to be done before letsencrypt starts to test. If not, it could hit the master, or one of the slaves : if the slave didn't contain the "hash-1/.well-known/acme-challenge/example.tld", it would be a fail.

Look here : https://github.com/acmesh-official/acme.sh/tree/master/dnsapi
I explained how dns_nsupdate.sh (the "RFC 2136" works) as it talks to 'bind' or bind comptabile direcly.
But most registrars didn't want all their clients to 'talk' to their master domain name server, as it hosts thousands (or way more) domain names. That's potentially an issue.
So, all the other methods talks to "registrar APIs" and these API will then do the domain name syncing for your in the background, on their side.
Every registrar created its own method of course ;)

Gertjan

@leonida368 said in Authenticating Users with Google Cloud Identity:

how will the user log out of their session?

They don't and you shouldn't care.
As you said yourself :

@leonida368 said in Authenticating Users with Google Cloud Identity:

I set the following 2 timeouts
Idle timeout (Minutes)
Hard timeout (Minutes)

As this concerns a school, starting at 08h00 and everybody out at 17h00, make the soft time out 9 hours, hard time out 12h00.
The DHCP lease duration can be kept to default, like 6 or 12 hours or so. AS most devices are Wifi anyway, and the wifi connection will get interrupted a thousands time a day, the device will get the same Lease (IP) all day long. Keep track of the number of devices, though, so that you have enough IPs in the pool. Don't open a portal with a /24 (255 devices max) on a school with 1000+ potential users. A /22 will be needed.

That said : there is a way to have the user disconnect themselves. It's undocumented ..... but it is also a RFC ( 8390 !! ).
The story is hidden in the "captive portal is not working on mobiles" This title, which was of course a none issue, hides a nice feature. You have to use DHCP ISC and not Kea. You have to add a DHCP option, and add a file, place it in the captive portal root folder /usr/local/captiveportal/
This is just optional, though.
I use this method, as portal identification goes much faster with this.

leonida368

dear @Gertjan as usual I'm a landslide in my presentation. Let me explain better: at the school on the same device (e.g. laptop in class not personal device) over the course of a day various teachers gradually alternate so the Idle timeout (Minutes) must be just 10min and is necessary have the possibility that the teacher can disconnect voluntarily so I will study this DHCP option you are talking about.

leonida368

So, I mentioned myself in the configuration and the following doubts/problems emerged:

DNS Resolver
I imagine that the "SSL/TLS certificate" field is useless since I don't tick "Enable SSL/TLS service", right?

Acme certified
After clicking on "issue" in System / Certificates / Authorities I expected to find an external Acmecert CA as per the guide but instead there isn't one

in services / Captive Portal for the "SSL/TLS Certificate" field I should be able to choose the ACME account created but I can't find it.

I performed the following steps:

I installed the ACME package
I went to Services / Acme Certificates
Account keys
add
in name I entered pfs.client domain (in my case pfs.associazionedonvitale.edu.it)
in ACME Server I chose "Let's Encrypt Production ACME v2"
I clicked on Create new account key
I clicked on Register ACME account key
Save
Certificates
add
I gave the name of the certificate pfs.client domain (in my case pfs.associazionedonvitale.edu.it)
Status: Active
I gave the account created before
private key: 2048-bit RSA
Domain SAN list section
mode: Enabled
domainname: pfs.client domain (in my case pfs.associazionedonvitale.edu.it)
method: DNS-Manual
Certificate renewal after: 3650
Save
I clicked on "issue"
General settings
I checked "Cron Entry"
Save

Gertjan

@leonida368 said in Authenticating Users with Google Cloud Identity:

DNS Resolver
I imagine that the "SSL/TLS certificate" field is useless since I don't tick "Enable SSL/TLS service", right?

Not needed, totally not recommended for captive portal usage.

@leonida368 said in Authenticating Users with Google Cloud Identity:

I should be able to choose the ACME account created but I can't find it.

You have to select the certificate that you've imported into the Certificate manager
Or
You have to select the certificate that the acme.sh package put in there. Did you get one ?

@leonida368 said in Authenticating Users with Google Cloud Identity:

method: DNS-Manual

When you chose "DNS-Manual" you agree with the fact that you have to do this every give or take 60 days.

Do you have access with some sort of GUI to the associazionedonvitale.edu.it domain ? Really ?

But I get it, your top level domain is "edu.it" so you have to find the guy that works on the Ministry of education to get access to the domain "associazionedonvitale.edu.it". Italy is in Europe, so that will take months if not years before you have access to that one

@leonida368 said in Authenticating Users with Google Cloud Identity:

Certificate renewal after: 3650

600 max should do - but this value doesn't matter if you use the DNS-Manual method.

edit : read this : https://github.com/acmesh-official/acme.sh/issues/1029 and the reality is mentioned on the very first line

So many users are using dns manual mode, but they don't really understand the manual mode .
I'd like to add a new command parameter, something like:
acme.sh --issue -d example.com --dns --yes-I-understand-dns-manual-mode
Which forces the user to read our wiki and make sure they know they will need to manually renew the cert in 90 days.
Without given this new parameter, acme.sh will show the wiki link and refuse to work.

Think about what I've said earlier : for about 10 € a year ( !! ) you have your own domain name.
You don't have to / won't have to use it as a visible domain on the Internet. That's what I did : I have a domain name like my-hotel-in-france.fr, this domain is sued to access our web site, our mails etc
I have a second domain name, my-hotel-in-france.net that I use like this :

I use this domain only 'internally' and especially for the https access of my captive portal.
Because I run my own DNS, I can go easy on myself and use RFC2136, as I control both sides.
Btw : But you have to be nuts to run your own "domain name DNS" these days.

acme :

and since then I never looked back. https access totally automated. Actually even better as before when we had to renew the certs every year (when StartTLS was a thing - but they went 'bust' (in short))

leonida368

@Gertjan said in Authenticating Users with Google Cloud Identity:

You have to select the certificate that you've imported into the Certificate manager
Or
You have to select the certificate that the acme.sh package put in there. Did you get one ?

in ServicesAcmeCertificates

in SystemCertificatesCertificates

leonida368

@Gertjan said in Authenticating Users with Google Cloud Identity:

When you chose "DNS-Manual" you agree with the fact that you have to do this every give or take 60 days.

Do you have access with some sort of GUI to the associazionedonvitale.edu.it domain ? Really ?

But I get it, your top level domain is "edu.it" so you have to find the guy that works on the Ministry of education to get access to the domain "associazionedonvitale.edu.it". Italy is in Europe, so that will take months if not years before you have access to that one

I don't have access to anything related to the DNS configuration of the customer's domain. So what method should I set instead of DNS-Manual? But then I don't understand: how does the service carry out the public registration of pfs.associazionedonvitale.edu.it automatically?

leonida368

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?

leonida368

@Gertjan are you abandoning me right now?

stephenw10

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

Gertjan

@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:             AVAILABLE

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

stephenw10

They might be able to issue you a server cert to use of course. Avoid using LetsEncrypt entirely.

leonida368

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

leonida368

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

stephenw10

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

leonida368

@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

Gertjan

@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.debug

First, 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 8002

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

leonida368

@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