Bcps Wifi Password

[Giulia Satmary]

Severalapps in ClassLink are designed to save your login credentials including the passwords. (ie. NC Ed, PowerSchool, SchoolNet, etc.) When a student moves schools their passwords are changed and therefore need to be updated in ClassLink.....

Active Directory (AD) credentials are used to login to your MacBook, PC's, the faculty wifi (BCS-Faculty AD) and to print. Faulty are allowed up to 3 devices with their Active Directory account. (ie. Macbook, iPad, phone, etc.)

In compliance with federal law, Burke County Public Schools administers all educational programs, employment activities, and admissions without discrimination against any person based on gender, race, color, religion, national origin, age, or disability.

When visiting my daughter in hospital their public wifi allows me to access the web but won't allow me to send/recieve emails. Works fine everywhere else. Is this because you have to sign in to their wifi via a portal (no user name or password required)? Are they blocking my pop/smtp access? If so, does anyone have a soluution please? (not webmail please, I'm too old to remember all that stuff)

Thanks for the speedy response JimHdk and nmcdonald1995, very kind. Both your solutions sound very plausible and will no doubt be useful to other people with the same problem as me, but with more technical ability. I was hoping there would be an ultra-simple solution.

Public WIFI may be running on an Automatic Proxy which will block certain things, where as it looks like it is blocking your mail, you can fix this by either putting in proxy settings for your Mail account which can be found on the Mail host site.

I think the suggestion by JimHdk is fair simple. Most Internet services providing email offer a way to access email via a browser like Safari instead of using the Mail app. You start Safari, got to the webmail webpage, enter a user name and password and are provided with a list of waiting emails. You can read emails, reply to emails, delete emails and create new emails on those sites. This is a very common way for people who travel a lot and who encounter your problem, to access their emails.

I chime in with the webmail option. I was in a similar situation. My mom was in a facility and it had AT&T wifi but my mail simply would not download. I had to go to yahoo's interface via safari to access my mail. Something in the security settings just would not work and the simplest way was honestly to find a work around rather than struggling with a network that you have no control over.

There is a lot of confusion around this on here, so I am making this post to be sure to understand it correctly. My school uses Aruba networks wifi, and after I type my Active Directory username and password (RADIUS authentication), it tells me I have to trust a certificate from 'wifiaruba.myschoolname.com' (Organization: My School) issued by DigiCert SHA2 High Assurance Server CA (Issuer Name, at least that is what the certificate says). I click trust and it goes away. My phone does not trust this by default it seems. Is it because this theoretically allows my school to decrypt SSL communications? If it really were from DigiCert, surely my phone would trust it?

It's ok. The certificate you installed and trusted is used to provide you secure authentication against their RADIUS server and prevent you from connecting to rogue RADIUS server. If someone decides to steal your Active Directory credentials by installing a rogue RADIUS server your phone will pop up with a warning that RADIUS certificate is not trusted.

By trusting this certificate you are not risking with anything else. This certificate can't be used by school to read your SSL traffic or attempt to MITM your SSL traffic. From what I read in your question, your school does it correctly and cares about your security.Regarding your question: why your phone does not trust that certificate (which is certainly issued by trusted authority). RADIUS requires explicit trust to particular RADIUS authentication certificate, because you don't know what AP you are connecting to. Otherwise, an attacker could get certificate from other trusted CA vendor (say, Let's Encrypt) and use it to impersonate school RADIUS server and steal your credentials.

This is not an issue in SSL context, because you know what kind of certificate you expect, because you manually type web site name in address bar. In wi-fi don't know to which AP you are connected and to ensure that it is legitimate, AP should provide RADIUS certificate you explicitly trust.

The problem is that before you authenticate to the wireless network, you are not actually connected to the network and can't reach any other host. When your device attempts to authenticate, the EAP supplicant on your phone will only be communicating with the authentication server.

With most EAP methods used by 802.11 wireless, the server will present a certificate to the EAP supplicant and the supplicant must make a decision if it will pass your credentials (username/password) back to the server. Since your device isn't yet connected to the network, the EAP supplicant is working with limited knowledge.

At the minimum, unless certificate validation is disabled, the EAP supplicant will check that the certificate is a valid certificate issued from a trusted CA and that the hostname listed on the certificate matches the hostname of the authentication server.

With some EAP supplicants, you can also optionally configure a designated CA(s) as the issuer of the certificate (i.e. only from Thawte or Digicert) and/or specific hostnames for the authentication servers. Many mobile devices (phones, tablets, etc) do not have these options.

Without use those options or some other sort of check, your phone would automatically accept any authentication server that would provide a valid certificate with a matching hostname. This would make it easy for an attacker to impersonate your school's wireless network and capture credentials on their own "authentication server." The prompt for you to accept the certificate is your chance to approve or reject sending your credentials to the authentication server.

Once you have accepted the certificate the first time, you should only ever see the prompt again if your phone is presented a different certificate (or you delete and re-add the wireless profile). Some schools will have multiple authentication servers so it isn't unusual to see this multiple times. However if you ever find a certificate suspicious (i.e. "arubuwifi.jimbobscomputers.com"), you should not accept it.

When it says "not trusted", that means that your phone could not verify the certificate. Unfortunately, an iPhone does not tell you why it can't verify it. It is possible that there is an attacker who signed their own certificate (it is very easy to do this on any computer) and simply forged the names of your school and of DigiCert etc. While it is not feasible to forge a signature for one of, say, DigiCert's real keys, it is possible to simply put in a garbage signature or fake DigiCert key; the iPhone won't be able to verify it and will simply say "not trusted".

So what could an attacker do if they had you trust their certificate? Well, if they get you to accept a signing certificate, then yes, they could inspect all of your SSL/TLS traffic. This is what censoring nation-states do to spy on their citizens' traffic.

3a8082e126