CAS is the Central Authentication Service for our campus. Whenever you log in to a service CAS is used to either check that you have already been properly authenticated or to have you authenticate, including two-factor authentication (2FA) using Duo.
Windows SSO (Single Sign-On) is a similar mechanism for allowing you to connect to various on-line services using your Microsoft Windows account. The Firefox browser has recently added support for Windows SSO for Windows 101 (as of Version 91 from August 10, 2021).
Unfortunately CAS seems to fail when using Firefox with Windows SSO support turned on. The result is the warning you get at the top of this page. The solution is to turn off Windows SSO support. To do so, pull down “Settings” from the “hamburger” icon in upper left corner, select “Privacy & Security” and then uncheck the box where it says “Allow Windows single sign-on for Microsoft, work, and school accounts”. The result should look like this:
Now you should have no problem authenticating to CAS.
Update – January 2022
In mid January 2022 the problem returned when I updated to Firefox version 96.0.1. On MacOS 12.1 (Monterey) the checkbox mentioned above is no longer there. On Windows 10 it’s there, but unchecking it does not solve the problem.
Our campus documentation suggests clearing all cookies, which of course has consequences far outside of just the one website I’m trying to visit. I found that deleting all cookies from just the domain microsoftonline.com fixed the problem.
This page describes how to configure the network interfaces for a Raspbery Pi running as a Wi-Fi Access Point (AP). This is just one step in a larger list of instructions, which can be found on the page Raspberry Pi Wifi Access Point. The instructions here do not include the routing, which is covered later.
We need to configure two networks, the “local” network managed by hostapd to be a Wi-Fi Access Point (AP), and the “upstream” network connection to the Internet. The upstream network can be wired or Wi-Fi, and it could use a fixed IP address, or it could be a DHCP client, so there are lots of possible variations. We will use wlan0 for the Wi-Fi Access Point, since we will always have that on Wi-Fi, and use wlan1 if the upstream network connection is also via Wi-Fi.
Local Area Network (LAN) for the Access Point (AP)
The first Wi-Fi adapter, called wlan0, will be used for the Wi-Fi Access Point (the local network). It’s best to use the IP address range for a Private Network.1 For a small home network you can put the following (or something like it) in the file /etc/network/interface:
This configuration is for a “Class C” network, which can have up to 254 IP addresses. For a large public event or venue you will probably want to use a class B or even a Class A network.2 In that case you can use the values in Table 1 to fill in the appropriate fields in the interfaces file.
Name
Size
address
network
netmask
broadcast
gateway
Class C
254
192.168.47.1
192.168.147.0
255.255.255.0
192.168.47.255
192.168.47.1
Class B
65,534
172.16.0.1
172.16.0.0
255.240.0.0
172.16.255.255
172.16.0.0.1
Class A
16,777,214
10.0.0.1
10.0.0.0
255.0.0.0
10.255.255.255
10.0.0.1
Table 1. Private Network settings for Class C, B, and A networks. For more details on private networks see RFC 19183
Upstream Connection
There are several different ways to make the upstream connection. It can be wired or Wi-Fi, and it could have a static IP address or it could get an address and other network settings from a DHCP server.
EDITED TO HERE
We will put the configuration for each interface in a separate file in the directory to make it easier to select which upstream interface to use, and also because it allows you to be a DHCP client on the upstream link.
(If you have a static or dhcp interface in /etc/network/interfaces then the dhcp client won’t start.4) If your access point won’t act as a DHCP client (it will definitely be a server, but that is different) then you can put all the configuration into the one file /etc/network/interfaces.
First, add the following to the top level file, /etc/network/interfaces:
# wlan0 is the Access Point
allow-hotplug eth0
allow-hotplug wlan1
# Now read full interface configuration from the subdirectory
source-directory /etc/network/interfaces.d
That last line is what reads the other files in that subdirectory. I have found that it is important to use allow-hotplog for wlan0 instead of auto; When I used auto then hostapd could not find wlan0, though it was up later when I checked. Maybe the boot order is different?
The upstream connection can be either via wired ethernet, on interface eth05 or via Wi-Fi, on interface wlan1. I will describe both and you can pick one or the other to connect to the Internet. It’s even possible to have both upstream links enabled at the same time — in case one fails the other will still work. You have to decide if you use DHCP (as a client) or a static the IP address and netmask and gateway.
First, put the following in the file /etc/network/interface.d/wlan1 for the second wireless interface:
Next, add the following to /etc/network/interface.d/eth0 for the wired upstream connection:
iface eth0 inet dhcp
These are just examples – you could use a static IP address for the wired interface, or use dhcp for the upstream WiFi connection. Having an entry for an interface that does not exist won’t cause problems.
SUNY New Paltz is in the process of adding Two-Factor Authentication (2FA) to their adminstrative computer systems, and I have been trying it out. This is a report on some of the things I’ve learned, such as how to get it to remember you for 5 days without having to accept all third-party cookies.
Two-Factor Authentication
A lot of people are familiar by now with Two-Factor Authentication. After you log in with a password (something you know) a message of some sort is communicated to you through a secure channel to a device assumed to be under your control (something you have). You then have to prove that you received this message, to prove that it is really you logging in, not just someone who has stolen your password.
A very familiar example is 2FA on Google accounts. When you log in with your password, Google sends a 6-digit code number as a text message to your mobile phone. (They will also call you on a voice land-line, if you don’t have a way to receive texts.) You then type in that 6-digit number to complete the authentication process. Facebook does something similar, but you use the Facebook app on your mobile device to get the 6-digit code, which changes every few minutes. I highly recommend enabling 2FA on both Google and Facebook.
New Paltz is using a 2FA system from Duo Security, which can work the same way, sending you a 6-digit “passcode” for you to enter as part of the authentication process. But Duo also offers the option of a “push,” in which the message is sent to an app on a device assumed to be under your control, and only your control. In that case you can simply push a button on the app to accept the authentication (or another button to deny it). You don’t have to type in the 6-digit number. The device can be a mobile phone, a “dongle” device you carry on your keychain, or even an Apple watch. Here is the challenge page you will see after you enter your password:
Figure 1. Duo 2FA challenge page
Click on “Send me a Push” and then press the “Accept” button on your mobile device and you are in. Easy.
Apple Watch
I have an Apple watch, which makes using Duo 2FA very easy.
After I’ve entered my password I click “Send me a Push,” and a screen on my watch comes up with the name of the site or service to which I’m trying to authenticate, and a button to Approve the connection (See Figure 2).
Figure 2: Duo Security on Apple Watch
There is another option under that, to Deny the connection, but I have to scroll down for that option. So far I have not accidentally pressed Approve when trying to scroll down to get to Deny but it’s a concern.
I prefer using the watch for authentication, but I have learned that if I have recently been using my iPhone and it is still open then the “push” will go to the phone and will not go to the watch. That is confusing at first, when you expect the push on your watch and it does not show up there. Check your phone.
(Maybe they could make it show up on both the phone and watch?)
In order to use the Apple watch app I had to install the iPhone app first, and then open the Apple Watch controls and find the Duo app there and enable “Show App on Apple Watch”.
Third-Party Cookies
When you initiate authentication and the Duo challenge page comes up, there is the option to have the device remembered (and authorized) for 5 more days. You can see a checkbox for this in the Challenge page in Figure 1. You can also see the disclaimer that “You need to enable cookies in order to remember this device.” What they actually mean is that you need to enable third-party cookies, which are cookies set on your browser from a site other than the one you are visiting. Even if you have enabled cookies in your browser, you will find that you are unable to check that box if your browser does not allow third-party cookies.
By default, I turn off third-party cookies. They are used for tracking by advertisers, which I prefer to avoid, and I can’t help but think they are a potential security weakness, though as of this writing I don’t know of any active exploits. The compromise is that browsers let you make exceptions, blocking most third-party cookies but allowing them from selected sites. Using Chrome, I found I could enable this 5-day “remember me” feature and still block third-party cookies in general if I made this exception for the site:
[*.]duosecurity.com
The special characters at the beginning are a “wild-card” match pattern, which is necessary because the hostname part of the URL seems to change from session to session. (In contrast, when I found how to enable Starfish Early Alert with a single exception for third-party cookies the hostname was specific to our campus.) The same should work with Firefox.
Although I have not finished testing yet, it seems that authorization is based on IP address, which means that if you use Duo 2FA on your desktop computer using one browser, then you are automatically authorized using a different browser. Does this required checking the “remember me” box or is it automatic? I am still trying to figure that part out.
I have an old iPad which has been dropped so many times that a piece of wire fell out the side, and I think that wire was the WiFi antenna. The iPad can only connect to WiFi when it’s close to the access point or when the signal is very strong. I figured out that my young daughter could still use it in the kitchen, far from the router, if I put a WiFi repeater in the kitchen. As it turns out, this also extends WiFi to the back patio, which is an added bonus.
I originally used an old Raspberry Pi 1B for this, and that’s still what I’ve mainly been using. It’s a good use for old hardware. It runs headless, with 2 USB wifi dongles, and sits under a cupboard just like lots of other modern appliances. But I’ve also tried this out with models 2B and 3B. The model 3B has an internal wifi interface, so you only need to add one extra USB dongle. The original wifi dongles did not have antennas, and that limited their range, so I’ve recently upgraded to the ones with antennas, as shown in the picture above.
This page was started in the summer of 2018, when I used Raspbian Stretch on a Raspberry Pi 1B, but the most recent revision was in December 2020 and I’ve made some improvements.1 I originally used instructions from user Dryfire117 on pastebin2. I later found useful instructions on the Raspberry Pi website.3 After going through the process several times and experimenting with variations I have been able to simplify things in several ways. For one thing, you can use either WiFi or wired ethernet for the upstream connection.
I’ve broken this up into several separate pages, because some of these steps are useful for related projects that I’ll be reporting on later, and because I think it’s just easier to follow and understand when it’s broken into separate parts like this. Here are the key steps:
Setup a new SD card
After flashing a new image on an SD card, boot it up and perform the “usual” set of configuration steps, as describe in “Raspberry Pi Initial Configuration” or your other favorite source.
Configure Network
We need to configure two networks, the “local” network managed by hostapd to be a WiFi Access Point (AP), and the “upstream” network connection to the internet. The upstream connection can either be wired or also via WiFi. The steps required to set this up have grown to the point that they have been put into a separate page, “Network Configuration for a WiFi Access Point.”
Install and configure hostapd
When I originally started doing this, you had to build hostapd from source code to get the nl20211 driver, but newer versions of Raspbian now include that driver by default, making things a bit easier. There are still a number of steps required to configure hostapd. Follow the instructions in the article “Configuring hostapd on Raspberry Pi.”
Set up DHCP server
The DHCP daemon is what assigns IP addresses to the computers that join your private network. Follow the instructions in the article “DHCP Daemon on Raspberry Pi.”
Configure NAT routing
Everything so far sets up an access point. Now we also need to configure the routing tables to perform Network Address Translation (NAT) and add a default route. Follow the instructions in the article “Raspberry Pi Access Point Routing Tables.“
Add DNS servers (optional)
The file /etc/resolv.conf contains the names of Domain Name Service (DNS) servers, but on Raspberry Pi this file gets overwritten at each reboot. It will probably contain the IP address of your upstream router, but nothing more. It is useful to have more nameservers for redundancy, in case one of them has a problem. Also, I now have a piHole DNS server on my local network, and I’d like to have anything on my internal network use that. The simplest way to do this is to edit the file /etc/resolvconf.conf and add a line like this:
name_servers=192.168.1.29 1.1.1.1 8.8.8.8
Take a look at /etc/resolv.conf after a reboot to confirm that these made it into the list.
Add Monitoring (Optional)
Since this device will run headless it can be useful to have a status display provided by a web page. This is easily done by adding a web server, either Apache or NGINX, which is described well on the Raspberry Pi website.4 In either case the main web page for the server lives in the directory /var/www/html/. You could make a simple HTML web page in the file index.html, or something more dynamic as a PHP script called index.php (such as this).
Save Everything
It’s useful to have a list of all the files you’ve modified to make this all work, so that you can go back and make checks or changes, so that you can make backup copies, and so that you can easily deploy the same files to another machine. I put the list into a file called wifipi_files.txt:
It is then simple to make a tar archive (tarball) containing just these files, using the command tar -czP --files-from=wifipi_files.txt -f wifipi.tgz
The -P flag preserves the full file path when the file is saved in the tarball. To deploy these files on another machine simply copy the tarball to the other machine and (as root or using sudo) give the command tar xzf wifipi.tgz
to extract them into place.
References and Notes
The original title of this page called this a WiFi “repeater”, which is somewhat ambiguous. The instructions here turn the Pi into an “Access Point” which has its own local network. It’s also possible to turn a Pi into a “bridge,” which just extends an existing network. I may try that out (and document it) in the future. ↩
This is the last step required to turn a Raspberry Pi into a WiFi Access Point. If you want to see all the previous steps, start with “Raspberry Pi Wifi Access Point“. When you get to this page you should already have done the following:
I originally followed more complicated instruction from user Dryfire117 at pastebin.com, 1 and then later became aware of a simpler way to do the same thing which is documented on the Raspberry Pi website.2 I think the way presented below is just as simple as the latter.
First, we need to enable IP forwarding by the Linux kernel, by editing the file /etc/sysctl.conf and uncommenting the line:
net.ipv4.ip_forward=1
You will need to be root or use sudo to edit this file. An alternative is to put this single line in the file/etc/sysctl.d/routed-ap.conf. Either way, this will take effect at the next reboot.
Next we will use iptables to add a routing rule to do Network Address Translation (NAT), and then add a default route. This is simply done by editing the configuration file for the upstream interface in the directory /etc/network/interfaces.d/ – either eth0 for a wired upstream interface, or wlan1 for a wireless upstream interface. Either way, add the following two lines to the file as part of the configuration for that interface:
As you might suspect, commands given after the “post-up” keyword are performed after the interface has successfully been brought up. The IP address after “gw” is the gateway address for the upstream network.
Reboot and verify that it’s all working, or to debug it if it isn’t.
I have tested using both upstream interfaces at the same time, but you really can’t. When both eth0 and wlan1 are brought up it seems that they compete and the IP masquerading setting for only one of them takes effect. That’s actually good, because if you delay one to let the other finish, so that you have IP masquerading set up for both interfaces, then it just doesn’t work (at least not if they are both on the same upstream network).
DHCP stands for “Dynamic Host Configuration Protocol”. The DHCP daemon is the process which assigns IP addresses to computers when they join a network, and gives them other important information about the network, including DNS server addresses. A local network used for a wireless Access Point usually has a DHCP server associated with it. It’s important to note that this is a DHCP server for the local network, but the AP may also act as a DHCP client to get it’s own network configuration information from the upstream link. These are two different things.
There are several packages that you can use to run a DHCP server. I chose the ISC DHCP server package (isc-dhcp-server), but I later learned that one can also use the dnsmasq package as a DHCP server.1 Choose one or the other.
Here is how I set up and configured dhcpd on Raspbian Stretch, using the isc-dhcp-server. This page was originally written in 2018, but I recently updated it in December 2020.
Install: Install the package: sudo apt-get install isc-dhcp-server
When you install this package it is configured to run automatically at boot time (
Configure: There are two files to edit or check:
Move the existing file /etc/dhcp/dhcpd.conf out of the way so you can replace it with your own: sudo mv /etc/dhcp/dhcpd.conf /etc/dhcp/dhcpd.conf.ORIG
(You should keep it because it contains good documentation and examples).
Then create and edit a new file /etc/dhcp/dhcpd.conf containing:2
#
# Configuration file for DHCP server on Rasberry Pi
#
ddns-update-style none;
option domain-name "wifipi.local";
option domain-name-servers 8.8.8.8, 1.1.1.1, 192.168.1.1;
default-lease-time 3600;
max-lease-time 86400;
authoritative;
log-facility local7;
# Configure service for local network 192.168.47.0 (the wireless AP)
subnet 192.168.47.0 netmask 255.255.255.0 {
range 192.168.47.50 192.168.47.250;
option routers 192.168.47.1;
}
##
Also edit the file /etc/default/isc-dhcp-server to add the line:
INTERFACESv4="wlan0"
Change the name of the interface to the local network if you are using something else.
Add a Delay: While I could start the service “by hand” once the Pi had booted, I found that the ISC DHCP server would sometimes not start at boot time, even though it is configured at installation to do so. When that happened I found a complaint in the log file (viewed with `grep dhcp /var/log/syslog`) like this:
dhcpd[345]: Not configured to listen on any interfaces!
The problem appears to be that the server is brought up at the same time the interface is being configured, and sometimes the interface is not ready yet. A simple solution3 is to add a slight delay to the init script that brings up the DHCP server. I edited the file /etc/init.d/isc-dhcp-server and found the line (in the start_daemon() function) which actually starts the daemon. I then added a sleep of a few seconds (at least 4 seemed to be needed) right before it. The code should look something like
As you can see, there is already a sleep of 2 seconds right afterwards to let the daemon get started.
A more elegant solution would be to create a systemd service file for this daemon. If that’s not been done in a newer release of the Raspberry Pi OS (I will check at some point) then I may do that and report the result. Another solution, of course, is to use dnsmasq instead.
The daemon hostapd is a Linux service which enables a “host” computer to become a WiFi Access Point (AP). Thus “host” + “AP” + “d” (for daemon) gives the name hostapd.
I originally learned to set up hostapd from instructions on Pastebin written by user Dryfire117,1 andlater found useful instructions on the Raspberry Pi website.2 The process originally involved building the daemon from source code to get support for the nl80211 driver, but that is now included with the prepackaged version you can install using apt-get. Here are the main steps:
Install: Install hostapd with the following command
$ sudo apt-get install hostapd
Configure: Create and edit the configuration file, at /etc/hostapd/hostapd.conf.
For starters, include the following:
interface=wlan1
#If this fails, try rt1871xdrv a
driver=nl80211
# Name of the new network: best use the hostname
ssid=wifipi
# Pick a channel not already in use
channel=6
# Change to b for older devices?
hw_mode=g
macaddr_acl=0
auth_algs=3
# Disable this to insure the AP is visible:
ignore_broadcast_ssid=0
This creates an open, unsecured access point. Anybody can connect to it without having to give a password. In some cases that is what you want, but in other cases you will want
to turn on WPA for security and add a password. In that case, add the following to the hostapd.conf file:
You should, of course, pick a better password. It has to be at least 8 characters long.
There are many, many other options which can be set in this configuration file, but these are the ones needed in most cases to get up and running. Full documentation of the options can be found in a sample configuration file at https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf
A few things I’ve learned from testing options on the Raspberry pi are that trying to enable the Automated Channel Selection (ACS) algorithm via “channel=0” does not work, and setting “hw_mode=any” does not work. At least they didn’t work for me when I tried them, but maybe they have been fixed since then.
Test: Test it manually to make sure the configuration file is okay:
If there are errors it will complain and abort. Unfortunately some older wifi devices don’t support all the features necessary to run an access point. This is where you find out if yours will work.If there are no problems it will run and you can see the network SSID on a nearby device. Simply press ^C to stop it.
Enable: Have The latest version of hostapd uses systemd startup rather than initd. It also starts out “masked” so you need to first unmask the service. The commands are (as root):
You can test manually that the service will start this way with
# systemctl start hostapd
You can, if you wish, change the location of the configuration file by editing the file /etc/defaults/hostapd and setting the variable DAEMON_CONF to the full path to the alternate configuration file.
Once hostapd is enabled and running, the next step is to enable the DHCP service, so that clients joining the network are automatically assigned IP addresses.
