Hi Eleanor,
Apologies – I just saw this email. You mentioned a Jisc mailing list – can you tell me which list that is? I’m concerned I’ve missed something here. As for the on-boarding SSID, we’ve found that the old traditional CAT site is easy to deal
with, but a tool like geteduroam would need somewhat more (given some of its back-end infrastructure is based in the cloud). A year or two ago, we had this query from Uni Cardiff, and I ran a DNS capture to see which hosts would be accessed when attempting
to use iOS and Android devices for Google Play, Apple AppStore and subsequently geteduroam. This is what I have from that experiment.
query[A]
19-courier.push.apple.com from 192.168.4.11
query[A]
21-courier.push.apple.com from 192.168.4.11
query[A]
44-courier.push.apple.com from 192.168.4.11
query[A]
api.smoot.apple.com from 192.168.4.11
query[A]
bag.itunes.apple.com from 192.168.4.11
query[A]
buy.itunes.apple.com from 192.168.4.11
query[A]
captive.apple.com from 192.168.4.11
query[A]
cat.eduroam.org from 192.168.4.11
query[A]
cf.iadsdk.apple.com from 192.168.4.11
query[A]
cl2.apple.com from 192.168.4.11
query[A]
cl3.apple.com from 192.168.4.11
query[A]
cl4.apple.com from 192.168.4.11
query[A]
cl5.apple.com from 192.168.4.11
query[A]
configuration.apple.com from 192.168.4.11
query[A]
configuration.ls.apple.com from 192.168.4.11
query[A]
crt.sectigo.com from 192.168.4.11
query[A]
crt.usertrust.com from 192.168.4.11
query[A]
d5ymw72datw3x.cloudfront.net from 192.168.4.11
query[A]
discovery.eduroam.app from 192.168.4.11
query[A]
e10499.dsce9.akamaiedge.net from 192.168.4.11
query[A]
e17437.dscb.akamaiedge.net from 192.168.4.11
query[A]
e4478.a.akamaiedge.net from 192.168.4.11
query[A]
e673.dsce9.akamaiedge.net from 192.168.4.11
query[A]
e6858.dscx.akamaiedge.net from 192.168.4.11
query[A]
gateway.fe.apple-dns.net from 192.168.4.11
query[A]
gateway.icloud.com from 192.168.4.11
query[A]
geant.ocsp.sectigo.com from 192.168.4.11
query[A]
gs-loc.apple.com from 192.168.4.11
query[A]
gsp10-ssl.apple.com from 192.168.4.11
query[A]
gsp64-ssl.ls.apple.com from 192.168.4.11
query[A]
gsp85-ssl.ls.apple.com from 192.168.4.11
query[A]
gspe1-ssl.ls.apple.com from 192.168.4.11
query[A]
gspe21-ssl.ls.apple.com from 192.168.4.11
query[A]
gspe35-ssl.ls.apple.com from 192.168.4.11
query[A]
gsp-ssl.ls.apple.com from 192.168.4.11
query[A]
identity.ess.apple.com from 192.168.4.11
query[A]
init.ess.apple.com from 192.168.4.11
query[A]
init.itunes.apple.com from 192.168.4.11
query[A]
init-p01md.apple.com from 192.168.4.11
query[A]
init.push.apple.com from 192.168.4.11
query[A]
iphone-ld.apple.com from 192.168.4.11
query[A]
keyvalueservice.fe.apple-dns.net from 192.168.4.11
query[A]
keyvalueservice.icloud.com from 192.168.4.11
query[A]
lcdn-locator.apple.com from 192.168.4.11
query[A]
mesu.apple.com from 192.168.4.11
query[A]
ocsp.apple.com from 192.168.4.11
query[A]
ocsp.digicert.com from 192.168.4.11
query[A]
ocsp-lb.apple.com.akadns.net from 192.168.4.11
query[A] ocsp.pki.goog from 192.168.4.11
query[A]
ocsp.sectigo.com from 192.168.4.11
query[A]
ocsp.usertrust.com from 192.168.4.11
query[A]
p29-fmip.icloud.com from 192.168.4.11
query[A]
p29-keyvalueservice.icloud.com from 192.168.4.11
query[A]
partiality.itunes.apple.com from 192.168.4.11
query[A]
pd.itunes.apple.com from 192.168.4.11
query[A]
play.itunes.apple.com from 192.168.4.11
query[A]
safebrowsing.googleapis.com from 192.168.4.11
query[A]
setup.icloud.com from 192.168.4.11
query[A]
s.mzstatic.com from 192.168.4.11
query[A]
static.ess.apple.com from 192.168.4.11
query[A]
su.itunes.apple.com from 192.168.4.11
query[A]
time-ios.apple.com from 192.168.4.11
query[A]
updates.cdn-apple.com from 192.168.4.11
query[A]
www.apple.com from 192.168.4.11
query[A]
www-cdn.icloud.com.akadns.net from 192.168.4.11
query[A]
www.icloud.com from 192.168.4.11
query[A]
xp.apple.com from 192.168.4.11
query[A]
xp.itunes-apple.com.akadns.net from 192.168.4.11
I hope this is somewhat more useful. Note that Google Play and Apple AppStore are also cloud-based, but given we’re likely to be in the same region, the list may fulfil somewhat of your requirements.
With kind regards
Stefan Paetow
Federated Roaming Technical Specialist
eduroam(UK), Jisc
e-mail/teams:
address@concealed
gpg: 0x3FCE5142
On Mondays and Wednesdays, I am not available between 12:00 noon and 15:00. For eduroam support, please contact us via
address@concealed and mark it for the eduroam team’s attention.
jisc.ac.uk
Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol,
BS2 0JA. T 0203 697 5800.
Hi,
Apologies for cross posting with one of the Jisc groups but I thought people on here might have some additional feedback. I'm looking at improving the user experience of our onboarding/setup ssid and have hit a few issues so I was wondering how other institutions
implement this.
I envisaged a user would connect to our setup ssid which most devices automatically detect as a captive portal and redirect the user to a 'sign-in' setup page. This page is an information page of how to connect with a link to the eduroam cat tool so that users
can configure their devices to connect to eduroam. The ssid has an allow/white list to various websites to give users access to the tools required to configure their devices. These are the problems I've hit so far with this:
Apple:
Apple devices check for connectivity to captive.apple.com and
when they can't reach that they fire up the CNA (Captive Network Assistant). This doesn't have full browser capability and doesn't allow a user to download the mobile config file that's required to configure their device. Has anyone found a way around this?
The only solution I've found is that I can bypass CNA on the captive portal (Aruba) which means the user has to open a web browser the navigate to the setup page.
To enable download of the geteduroam app from Google Play I have to whitelist www.google.com.
With that url in the whitelist Android thinks it has Internet access so doesn't redirect to the captive portal to display the 'sign-in' setup page. Again the user would have to open a web browser and browse to the setup page.
My thinking was that the automatic redirect was a better user experience. Am I fighting a losing battle trying to use the automatic detection of the captive portal to direct users to a setup page for onboarding? Should I just whitelist the url's that detect
this and recommend going through the browser? I'm interested in how other institutions have this set up and what the user experience is?
Eleanor Coultish
Network Operations Manager
