Re: [WIRELESS-LAN] Protecting Cisco 1815w APs

[Matthew Craig]

We use standard flush-mount boxes, such that there is no protruding box to 
tamper with most of time; the device is flush with the wall.  If a protruding 
box must be installed, there really is no way to prevent people from making 
holes in it or ripping it off.


We utilize the locking screw with cover-up sticker that comes with the device.  
This helps… one has to go through the trouble of discovering the sticker and 
having a sufficient screwdriver to back the screw out, or straight up ripping 
it off the wall (which can be difficult)

For the RJ-45 ports, if we don’t want them to be used (such as the passthrough 
if not used), we use RJ-45 block-outs

Cisco offers Physical Security Kits we keep in stock that has additional screws 
and stickers plus the RJ-45 block-outs: AIR–SEC–50=

If we need bulk RJ-45 block-outs for a large project or something, we buy: 
https://www.amazon.com/Lindy-RJ45-Port-Blockers-40471/dp/B00F3VBOU6/ref=pd_bxgy_147_img_2?ie=UTF8=1=XG25B9TBZNJX5B4YXE4Z



All of these above really help.




If we don’t want an ethernet cable removed we use port-lock kits, although this 
is rarely used: 
https://www.cdw.com/product/Panduit-outlet-port-lock-kit/1648217?cm_cat=google_ite=1648217_pla=NA-NA-Panduit_CN_ven=acquirgy_id=CjwKCAjwy7CKBhBMEiwA0Eb7au_NZdEqvxzyZ2RGMPSAOGiK-G4pC_EpSZvKNBgjXTxWKMAI1MOfZxoCfsoQAvD_BwE:G:s=CjwKCAjwy7CKBhBMEiwA0Eb7au_NZdEqvxzyZ2RGMPSAOGiK-G4pC_EpSZvKNBgjXTxWKMAI1MOfZxoCfsoQAvD_BwE_kwcid=AL!4223!3!496173788312!!!g!325109538940!!12244136370!117820874592




Our most common issue is people using the device to step up higher on the wall 
or smashing it with furniture.  I am unaware of any way to truly prevent this.  
We are a charge-back shop, so any replacement is bought by the building owner 
(sometimes they choose to simply not replace them and go without), so its not a 
big deal to us personally.




-
Matt







On Sep 23, 2021, at 11:19 AM, Eric Jensen 
mailto:epjen...@alaska.edu>> wrote:

WARNING: This email originated external to the NMSU email system. Do not click 
on links or open attachments unless you are sure the content is safe.
Hi Sean,

We have quite a number of the 1815W access points deployed throughout our 
campus housing as well.  We haven't noticed much issue with the LAN ports on 
the bottom getting damaged, but we have had occasional issues with students 
disconnecting them.  Ours are primarily mounted on surface mount j-boxes, so 
students will typically just remove a knockout hole and fish the cable out to 
disconnect, but we've had some get pried off as well, which, thankfully, has 
primarily just damaged the mounting plate.  We haven't done much to prevent it, 
but we do shut the switchport down to the room whenever an AP is disconnected, 
to provide an opportunity for educating the user.  Additionally, this year we 
had stickers printed to place on each AP with (very brief) instructions for 
connecting to our different wireless options, as well as to the wired ports on 
the bottom of the unit, and include our helpdesk website and phone number.  The 
idea being that having readily available instructions/help will reduce work for 
us as well as frustration for the students.  Don't really have any hard numbers 
as to how much it has helped, but our Residence Life staff were pretty 
enthusiastic about the idea.

All of that said, I know Oberon makes an enclosure that works with those APs 
(https://oberoninc.com/products/1017-wh/),
 which you could utilize if the problem is pervasive enough.  However, for us 
it's a low enough occurrence rate, and the 1815W units are inexpensive enough, 
that it would be far more costly to install the enclosures, in both time and 
money, than it is to deal with the occasional disconnected/damaged AP.

Cheers,

Eric

--
--

---
Eric Jensen
Senior Network Communications Specialist
University of Alaska - Office of Information Technology
email:  epjen...@alaska.edu
phone:  907-450-8326
---

On Thu, Sep 23, 2021 at 8:55 AM Gray, Sean 
mailto:sean.gr...@uleth.ca>> wrote:
Hi Everyone,

I hope you are all surviving another semester start up without too much pain!

We have a large number of wall mounted Cisco 1815w access points on campus. 
Lately we have noticed that the LAN ports are getting damaged and are looking 
at way to stop people tampering with the patch cables.

I’m interested to see if anyone else has experienced this problem and am 
wondering what steps they took to protect their access points?

Re: [WIRELESS-LAN] ISE-NPS-Azure MFA

[Matthew Craig]

Isn’t SAML entirely a web-based thing?  Sure, you can tie it into the actual 
website URL of your ASA, but what about logging in directly from the AnyConnect 
client itself?  This is not referenced in any documents I’ve seen so far.  Is 
this possible?

website login for AnyConnect would be unfriendly to many users who are already 
hostile to having to use VPN in the first place.



My research on the topic is that many people are going to ISE 3.0 and using PAP 
to go to Azure AD for RA AnyConnect.  Additionally Azure AD doesn’t seem to 
support PEAP-MSCHAPv2 right now, which does directly concern wireless.  (and 
yes I know EAP-TLS is the the way that it “should” be done, but the “should" 
doesn’t materialize into reality for many people.  Many simply are not in a 
position to roll out EAP-TLS)

Azure AD seems to be designed with Cloud web-apps in mind only, and this 
apparently is creating alot of gaps on the Networking end, and Microsoft is not 
in the Networking business to care.


Please correct me on any point, I do have alot of knowledge gaps on this 
subject.


-
Matt







On Aug 26, 2021, at 9:14 AM, Jeffrey D. Sessler 
mailto:j...@scrippscollege.edu>> wrote:

WARNING: This email originated external to the NMSU email system. Do not click 
on links or open attachments unless you are sure the content is safe.
I 2nd Tim’s suggestion.  If the VPN is Cisco-based, they support using SAML 
against AzureAD including MFA.

https://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/215935-configure-asa-anyconnect-vpn-with-micros.html

Jeff

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Manon Lessard 
mailto:manon.less...@dti.ulaval.ca>>
Date: Thursday, August 26, 2021 at 7:54 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] ISE-NPS-Azure MFA
We are talking VPN here and for the entire campus…

Manon Lessard
Chargée de programmation et d’analyse
CCNP, CWNE #275, AWA 10, ESCE Design
Direction des technologies de l'information
Pavillon Louis-Jacques-Casault
1055, avenue du Séminaire
Bureau 0403
Université Laval, Québec (Québec)
G1V 0A6, Canada
418 656-2131, poste 412853
Télécopieur : 418 656-7305
manon.less...@dti.ulaval.ca
www.dti.ulaval.ca
Avis relatif à la confidentialité | Notice of 
Confidentiality


From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of James Andrewartha 
mailto:jandrewar...@ccgs.wa.edu.au>>
Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Thursday, August 26, 2021 at 10:50 AM
To: 
"WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] ISE-NPS-Azure MFA

Microsoft note this behaviour and have some sort of workaround in their NPS MFA 
extension: 
https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-nps-extension#radius-protocol-behavior-and-the-nps-extension

Really though, doing MFA for RADIUS is a square peg in a round hole, use MFA to 
provision a client cert and do EAP-TLS instead.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Manon Lessard 
mailto:manon.less...@dti.ulaval.ca>>
Reply to: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Thursday, 26 August 2021 at 10:20 pm
To: 

Re: [WIRELESS-LAN] [EXT] Re: [WIRELESS-LAN] Android 11 Manual Profile Configuration Variable

[Matthew Craig]

Does all this have any consequences for “traveling” eduroam clients?


Elaboration:

Location: home at myorg.edu
ssid: eduroam
username: profess...@myorg.edu
Professor X’s supplicant config: Domain = myorg.edu
my radius server: radius.myorg.edu




Professor X travels to otherorg.edu:

Location: traveling at otherorg.edu
ssid: eduroam
username: profess...@myorg.edu
Professor X’s supplicant config: Domain = myorg.edu
otherorg radius server: aaa.otherorg.edu



Does this not break?

What do?



-
Matt Craig
Network Engineer
Information and Communication Technologies
New Mexico State University








On Feb 11, 2021, at 8:19 AM, Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu>
 wrote:

WARNING: This email originated external to the NMSU email system. Do not click 
on links or open attachments unless you are sure the content is safe.
Yes, the EAP server certificate subject should be the same eTLD as the 
credential realm.

Said differently, if EAP identity is 
`t...@capptoso.com`, the server certificate should be 
`.capptoso.com`.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Jethro R Binks 
mailto:jethro.bi...@strath.ac.uk>>
Date: Thursday, February 11, 2021 at 10:15
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] [EXT] Re: [WIRELESS-LAN] Android 11 Manual Profile 
Configuration Variable
Can I drill into this a bit please just be clear on my understanding?

On Thu, 11 Feb 2021, Sweetser, Frank E. wrote:

> "The STA is configured with EAP credentials that explicitly specify a CA
> root certificate that matches the root certificate in the received
> Server Certificate message and, if the EAP credentials also include a
> domain name (FQDN or suffix-only), it matches the domain name
> (SubjectAltName dNSName if present, otherwise SubjectName CN) of the
> certificate [2] in the received Server Certificate message."
>
> In particular, note the bit about SAN if present, otherwise CN.  A
> strict reading of this (which Android appears to follow) means that
> unlike the web browser behavior we're all used to, if there is a dNSName
> in the SAN list, then the CN will not be evaluated in matching the
> client configured domain.  This means that if you have:
>
>
>   *   A client configured domain of myorg.edu
>   *   A server CN of radius.myorg.edu
>   *   A server SAN of radius.myotherorg.edu

Particularly, "EAP credential domain name", as contrasted with the
"Domain" setting in the client discussed earlier.

My understanding is that the "Domain" setting in the client is telling the
client "the radius server must present a certificate with this
subjectAltName/CN".  Equivalent to the Validate server connection /
Connect to these servers settings seen elsewhere?

But "EAP credential domain name" to me means the credentials one provides
to authenticate as, so usern...@myorg.edu say.

Is this saying that the server cert subjectAltName/CN must be 
"myorg.edu"?
That's not what the common case is now I would say; most radius server
certs would likely carry a name "aaa.myorg.org", 
"radius.myorg.org" or
somesuch.

Do I misunderstand "EAP credentials also include a domain name (FQDN or
suffix-only)" ??

Reading the document a bit more, "EAP credentials" seems to be a broader
phrase equated to "network profile" (see 5.3.1), so perhaps means "the
bundle of settings including login credentials and Domain of radius server
for validation", so "EAP credential domain name" is referring to the
Domain (for cert validation) ie "radius.myorg.org", 
not any domain part of
the login credentials ie "myorg.org"?  Is that a correct 
reading?

Jethro.

.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
Jethro R Binks, Network Manager,
Information Services Directorate, University Of Strathclyde, Glasgow, UK

The University of Strathclyde is a charitable body, registered in
Scotland, number SC015263.

**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at 

Re: [WIRELESS-LAN] 8540 Code version- holiday work

[Matthew Craig]

Lee,

We’re currently running 8.5.135.0, and its been running fine for us for a long 
time, despite multiple comments on this list of problems with that code.

However just within in last couple of months or so we’ve been chasing problems 
with clients in dorms connecting to 702w (but dorms with 1815w are fine).  
Clients keep dropping and re-associating; rapid tx errors causing 
de-associating then coming back in the logs etc...


We think something had to have changed on the client side as we’ve had no 
issues for a long time prior… students bought a bunch of new ax chipsets this 
semester that don’t like older N radios?, bigsur updates?… haven’t been able to 
pin it down.



Cisco won’t say much more than ditch 702w… but can’t do that on a dime of 
course.



We have been targeting 8.5.151.0 and 8.5.161.0 as an upgrade path to see if it 
helps.  8.5.161.0 is the recommended TAC release, but I have a somewhat 
irrational feeling to try 8.5.151.0 first.  Your comments about 8.5.151.0 not 
totally sucking vindicate my feeling!  :)



-
Matt Craig
Network Engineer
Information and Communication Technologies
New Mexico State University









On Nov 20, 2020, at 4:30 AM, Lee H Badman 
<00db5b77bd95-dmarc-requ...@listserv.educause.edu>
 wrote:

WARNING: This email originated external to the NMSU email system. Do not click 
on links or open attachments unless you are sure the content is safe.
Knowing that there is no easy answer on questions of Cisco code versions, I’ll 
throw it out there anyways. We have been on 8.5.151.0 for quite some time now , 
with mostly good reliability for 3700s and 3800s alike (occasional need to 
reboot 3700s), We are due to minimally reboot everything, and I’ve been 
following the various discussions regarding code bugs and specific client 
issues these past few months.

So curious- is there a solid, reliable newer version to consider? We are not in 
a hurry to get into .11ax yet for a number of reasons. Given the long and 
problematic history of WLC code, 8.5.151.0 has been as close to “wow, it 
actually doesn’t totally suck” as we’ve ever been.

Regards,

Lee Badman | Network Architect (CWNE#200)
Information Technology Services
(NDD Group)
206 Machinery Hall
120 Smith Drive
Syracuse, New York 13244
t 315.443.3003   e lhbad...@syr.edu w 
its.syr.edu
Campus Wireless Policy: 
https://answers.syr.edu/display/network/Wireless+Network+and+Systems
SYRACUSE UNIVERSITY
syr.edu


**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at 
https://www.educause.edu/community


**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

Re: [WIRELESS-LAN] Transitioning from older controller to new controller

[Matthew Craig]

I am intersted as well.





-
Matt Craig
Network Engineer
Information and Communication Technologies
New Mexico State University









On Nov 11, 2020, at 1:25 PM, Mike Atkins 
mailto:matk...@nd.edu>> wrote:

WARNING: This email originated external to the NMSU email system. Do not click 
on links or open attachments unless you are sure the content is safe.
You are not late at all.  I certainly am.  I have 8-9 e-mails for interest.  
I'll send out a quick survey to collect information from those that responded.  
I will send it to the list again to pickup others that might be interested.


On Wed, Nov 11, 2020 at 3:17 PM Michael Heflin 
<02002057e293-dmarc-requ...@listserv.educause.edu>
 wrote:
Little late but would be interested in this as we are moving from 8540's to 
9800's

**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at 
https://www.educause.edu/community


--




Mike Atkins
Infrastructure Architect
Office of Information Technology
University of Notre Dame




**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at 
https://www.educause.edu/community


**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

Re: [WIRELESS-LAN] Cisco 8540 WLC random reboots

[Matthew Craig]

Yes, we ran into this, as did other schools from what I hear.

After working with TAC for quite awhile, they came out with 8.5.131.0 and that 
seems to fix the issue, as well as some other issues.

Its been bug wack-a-mole since 8.5 code came out, but so far (*fingers crossed* 
*knock-on-wood*) this one has dare I say been working alright.



---
New Mexico State University / CHECS.net
Network Operations Center
575-646-5999
---

On Jul 9, 2018, at 10:44 AM, Mallon, Jason 
mailto:jemal...@ua.edu>> wrote:

We are currently in the process of migrating to 8540s (8.5.120) from 8510s.  
Here recently we started noticing the HA unit on two of the pairs was in 
maintenance mode.  We rebooted the controllers and they seem to have stayed in 
a continuous boot loop.  We restarted one of the controllers to its emergency 
code (8.2.166) and it rebooted correctly without any issues, disabled SSO mode, 
rebooted back into 8.5.120 with no issues.  We enabled SSO again and 
immediately went back to having boot loop issues.  Is anybody else seeing this 
issue?

Jason Mallon
Network Engineer II, OIT
The University of Alabama
jemal...@ua.edu
** Participation and subscription information for this EDUCAUSE 
Constituent Group discussion list can be found at 
http://www.educause.edu/discuss.


**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/discuss.