Cisco Meraki Access Manager: Cloud-Native Zero-Trust

Thanks for having me here. My name is Alex Berger. I'm a principal engineer, uh, working on our cloud managed, uh, portfolio.

Uh, and joining me is Steven Orr, uh, distinguished engineer. Um, and we're here today to talk about, uh, Meraki Access Manager, which is, uh, kind of our cloud native zero trust service that we just, uh, launched this week. And I wanna get into a little bit of detail there.

Well, I gotta turn on my clicker. There we go. Um, so yeah, I'm just gonna go through a quick level set intro, uh, get into access manager and the cloud architecture, and then hand it over to Mr.

Or do, uh, some use case walkthroughs and then a demo. So for those of you that aren't familiar, and I think everyone here is familiar with Meraki, but anyone watching that's not familiar with Meraki, uh, Meraki is Cisco's, uh, cloud managed network platform. And, uh, within Meraki we've always had support for one X services.

Um, you know, whether it's simple things like VLAN assignment or access lists attached to a Radius session, um, or even like zero trust with microsegmentation using, uh, adaptive policy. But we've always relied on an external radius service, whether it's Cisco ICE built out and self-hosted, or even, uh, you know, cloud services. And with that, we won't go that you have a lot of complexity when it comes to connectivity.

Uh, one of my, um, least favorite things is trying to figure out how to build different types of tunnels to secure communication over the internet so that you don't send, uh, credentials and clear text. 'cause Radius itself is not, uh, very protected. Um, and there's a lot of, uh, cost associated with hosting things, uh, yourself and like could be from maintenance, um, monitoring and management, and then also paying for the power and everything that comes along with, uh, hosting your own services.

And then there's also having to manage overlays for connectivity and being able to make sure that network devices can still communicate, um, with those core services. 'cause if Radius is down, a lot of times the network isn't necessarily operational, uh, for users. And so not only that, but all of these things come with, uh, a consistent need to sync policy configurations from your network devices, uh, to that security, uh, appliance or security service.

This means things like access list names, um, sgt, um, VLANs and what VLANs are appropriate for a specific implementation. And so there's a lot of console pivots, which can be kind of difficult, especially if you're just getting in, you're having to train people, they have to learn, you know, the network ux, uh, security appliance, ux, and then have to understand how to troubleshoot all those and jump between the two, um, you know, pretty consistently. And so we took a lot of feedback from our customers over the years, and we've had a lot of folks ask us, Hey, how can I get a cloud managed service that kind of takes care of a lot of that pain and a lot of that, uh, extra effort when it comes to just wanting to deploy, um, you know, secure access to the network.

And so we built Meraki Access Manager as a scalable, uh, as a service solution in our dashboard. So you have a single console, and we support wireless in switching today for one X and macoff, um, so that we can authenticate the devices that connect and make it very easy to apply things like sgs or, you know, group policy assignment and keeping that context in dashboards. So when you go to build a rule, you don't have to go and look up what the name of these things are.

We have all that stuff populated, so you can just drop down and select it. I have a question. Yes.

Does it also work with non Meraki Switches? Not today. So when I say Meraki, and I'll go into what we specifically support, but it's anything that's Meraki managed, so that could be Catalyst or our MSS today.

Um, but some of our key focuses from feedback we received from customers was to try to help reduce management overhead. Um, not everybody likes to host services, and a lot of folks are trying to get away from having services that are, um, where they have to sit there and upgrade and take care of. So just trying to make sure it is as simple as possible, keep it everything within the same console, the same dashboard, so that when you troubleshoot, you can go from looking at an authentication or an authentication failure to finding where that device was connecting and getting any context necessary quickly.

And probably the one that is nearest and dearest to my heart is helping enable, uh, adoption of microsegmentation. So I've been working on, uh, Meraki's Adaptive policy for six years now, and being able to have everything built through the same dashboard, uh, not requiring extra services makes it a lot more, um, a lot simpler to actually get things going and take advantage of those services. Now I mentioned earlier about, uh, credential transport and whether you're building VP n tunnels or you're using like Rad sec, usually AP to do extra work just to get stuff, uh, where you need it in a secure manner.

But with a, uh, wow, with Access Manager, um, everything goes over the security tunnel that we use for, um, control. So you don't have to worry about poking any extra holes in your firewall. Um, it just rides over that same secure tunnel.

Um, that means if you have dashboard connectivity, you have access to or connectivity to access manager From a switching, uh, support perspective, as I was mentioning, all current generation ms, anything that can run, uh, MS 16 firmware and above is supported our first generation of Catalyst, uh, switch management, which, uh, I've presented on a couple times here, but is supported. And we're bringing support for our cloud native xe, um, next gen, uh, software stack that we just launched into beta. Um, and hopefully here in 17 15 3 if that, uh, everything works out the way we want.

Uh, from a switching perspective, we support E-T-L-S-E-T-T-L-S PAP for username password authentication, uh, and MACOFF bypass. So, you know, if you have devices that don't have a supplicant, you can still do some sort of at least checking before they connect to the network, um, over that tunnel. We do send, uh, you know, the credential exchange.

Um, we also send connectivity details through accounting. So there's also, there's profiling attributes, um, you know, counters, et cetera. So we're able to tell if a session's still active and also start to pull a lot of that data together for us to provide, um, granular profiling of, uh, endpoints.

one x making sure that your network's locked down, but you still get a lot of that automation and, um, capability. I have a question for the profiling on the feature set. Let's say I have a print server that is in MEC bypass.

Mm-hmm. Somebody unplugs this types of Mac in and starts then to doing some other, let's say, behavior, then a normal print server would do. Would you be able to protect and say, okay, this is out of the profile, we should maybe start blocking this part because it looks like no longer the print servers here behind this thing?

Yeah, that's a great question. So we're working towards supporting a lot of the, um, extra kind of attributes that we could use to determine, yeah, devices changed, whether it's, you know, following the profiling data, looking at like DHCP attributes, you know, those different bits. Have you ever heard of device sensor?

We're using the same concept for, um, in this case, but we don't have that set today. We are working towards it. And I have a slide towards the end of this entire session kind of talking about some of the stuff we're working on.

We are looking at ways of taking like flow telemetry and figuring out if using that to help fingerprint. So like, we have a lot of plans right now. It's just pretty much just macoff and, um, then traditional, um, authorization, like through certificates, The problem, the weakest piece in the whole thing, most of these devices have the MAC printed out somewhere on it.

And yeah, this kind of, you're only as good as the weakest pointer. Absolutely. Yeah.

And so, I mean, we don't, we definitely don't like, say, use Mac off and you're good to go. Um, it's just an option. It does give you some automation, but yes, we do need to have more things to, you know, help ensure that, um, people aren't spoofing MAC addresses from a wireless perspective.

Uh, just jumping forward, and if there's any questions, please interrupt me, but, um, from a wireless perspective, anything that we've been shipping for the last seven, eight years, uh, is supported. So that's our eight to two 11 AC wave two or wifi five wave two access points and above. 6 firmware.

So if you look in dashboard and you're wondering what firmware, that's just the firmware indicator, um, uh, to be able to be supported wireless, same set of credentials, um, same kind of concepts. We're using the same, sending the same kind of data, including those profiling attributes. And one big difference is obviously wireless uses PS Ks in some cases.

one X on your devices, you can still do per device PSK, and then send back different attributes, uh, as you, um, as they connect. So just kind of gives us a little bit of flexibility. So I want to get to the demo or let Mr or get to the demo.

So I'm gonna go through real quick the, uh, on the architecture side and then hand it over to him. Um, we look at high availability from a couple different, um, couple different perspectives. So there's the device side.

All of our network devices build a primary and secondary tunnel, and those are two tunnel servers that are in geographically disperse locations, so they're not sitting in the same data center. Um, making sure that we're, we have high availability for connectivity to dashboard itself. Um, these are always in geo, so we're not gonna connect you to, like, if you were in Europe, connect you to the us, it's gonna be within the same geo.

So, um, not, you know, so that we don't end up with any of the data privacy, um, normal things that you have to deal with. Um, but that means that, you know, from a tunnel connectivity perspective to the cloud, high availability there from the device, um, dot one x macko, um, any of those processes that we run locally, there are resiliency functions that we built in. Um, we did just release radius caching on, uh, catalyst side so that if you had, you know, a link severed, um, we can restore the last authorization.

It's kind of one of those, you give up a little bit of the security side to keep the same policy in place. But, um, so radius down, be able to restore that, uh, uh, that last policy. And there's other things like critical auth wireless actually has a couple fallback mechanisms to, um, validating like certificates.

Uh, and it all is also building radius caching as well, so that we have a, you know, way of staying resilient across the board. Cloud. Service wise, we are using, uh, you know, Kubernetes and service clustering.

This allows us to do, uh, you know, horizontal scaling really quickly, and to be able to support many, many, many, many sessions, uh, concurrently. Um, once again, you know, from that tunnel termination, the services are available behind those tunnel endpoints. So there's no, um, like rerouting and adding in tons of latency, but also with things like enter ID which is our primary IDP that we support today, or our main IDP we support today, um, we do synchronize, uh, any of the information so that we're not sitting there making calls to enter ID over and over again for authentications and are able to have it as low latency as possible.

So trying to keep low latency, high availability. That being said, any questions before I, uh, What is the overall requirement that you have from a location to the back end when it comes to latency? How much is supported?

So let's, I'm thinking about some regions of the world where maybe the next cloud data center from Cisco is not, uh, that good, uh, latency perspective. Uh, Yeah. And we do have really, um, a fairly dispersed, uh, locations from like latency perspective.

Typically we see under, under a hundred milliseconds of connectivity. Um, we don't necessarily have like a latency restriction other than, uh, at some point endpoints or devices connecting. one x, uh, they may have some issues with not getting responses back in time.

Um, I don't have that right in front of me though, on specific timers, but I think it does vary by device. Um, At the end of the day, we'll work just the client has to wait a little a Bit longer. Correct?

It should, yeah. I mean, it's, it's gonna follow some of the, the standard radius timeout kind of, uh, concepts, but, um, it's not multiple seconds, right? So it's The ICE would often, there was extra tuning needed to make it work, and so, but you tested it for more or less for the region than it was working fine.

Yeah. Yeah. I mean, and I think as we just launched this, we're gonna be continuing to build more and more things and there probably will be things that we end up, um, tuning, um, as we go.

But, uh, for the most part, yeah, it shouldn't, there shouldn't be anything like hard line cut in the sand, if that makes sense. Okay. Thanks Alex.

Yep. Uh, again, uh, thanks everybody. Uh, name's Steve or, so we're gonna go through a couple of use cases.

Uh, so again, would appreciate some feedback. And definitely on the latency issues with the a hundred millisecond, you know, kind of looking around that a hundred milliseconds, that's really what we target. So I'm a wifi guy, right?

So, uh, so it's, uh, what we target for roaming anyway, right? So that's why Alex had mentioned about caching, about caching the credential. So in case, you know, we're, we're decreasing the, uh, the need for those, uh, really low latency links by bringing some of the, the credential caching back down to the, uh, to the dashboard.

So again, if there's any questions, please feel free. Uh, so one of the, one of the big use cases that we've seen, again, this isn't necessarily just for access manager, this is where we've been, uh, you know, seeing things for microsegmentation, microsegmentation, uh, with that convergence of IT and OT within the same infrastructure. So one of the things that we've seen, obviously everybody's familiar with, uh, for us, it's called IPSK, or PPSK or any of the, uh, wireless mechanism I call 'em, I like to call 'em vanity, uh, passphrases.

'cause that's about what they're worth is a vanity passphrase. But, uh, so we, we've got a couple ways to do it, right? So that the iot device could be an Xbox in a, in a university, it could be an iot device on a factory floor, uh, they get on the network, they're gonna authenticate.

And what we're gonna do, and as Alex had mentioned, right? So one of the things that Access manager's really great at is accelerating, uh, the capabilities for adaptive policy in that microsegmentation deployment. So, I'm sorry, go ahead.

So it's A kind of SGT, right? SG ts? Absolutely.

Yeah. So the scale, you'll see either secure group tags or scalable group tags. I've been around a while, so we've modified the name here and there, but yeah, it's secure group tags.

So we basically, you know, we're, we're putting a, a shim the metadata field, uh, with an actual, uh, value based on, you know, however we wanna profile the device. So, uh, and that's where, where you look at where it says the IOT group. So that IOT group is a logical entity that says, Hey, this is this group tag that's defining that.

Now, the good thing about group tags is we're actually shimming it in the ethernet frame, as opposed to relying on an IP address or something else. So it is immutable in the sense that the station doesn't set it, it comes in from, uh, the first hop network device, whether it's an access point or a switch. Uh, it imposes the tag in that tag for versus the network.

And we can do policing actions based on it. Uh, again, so we can look up rules, which is the key thing, right? And rules could be anything.

It could be as simple as, uh, SGT one can't talk to SGT two, or you can actually get in and do some really fine granular, uh, acls also, if you want to, uh, permit or deny specific protocols. So that's all within the realm of possible, that policy gets pushed to the network device. So the network device, as opposed to the client is imposing the rule, and then we're using the infrastructure as an enforcement point as opposed to a single point, uh, on the network.

So again, when we, when we abstract this out, we try to keep it very simple in, in certain cases where it's like, okay, I've got this iot environment, so I'm gonna be able to talk to a controller. Most, uh, in most iot environments, you need layer two adjacency, right? To, uh, an IOT controller.

But what we don't want it to talk to is other controllers. Uh, that's, that's the key piece, right? And we want it, we definitely don't usually want the IOT devices talking to user endpoint user devices, right?

So, uh, then we get, uh, say, door locks. Now I've seen networks where they wanna put, say like a university, they wanna put door locks and video cameras on the same network, but they don't want door locks and video cameras to be able to exchange information and talk to each other. So in this case, we can actually mix wired and wireless, even if it's the same vlan, even if it's the same subnet, we can actually mix policies because the SGT is imposed at the MAC layer.

So the IP addresses, I won't say they become irrelevant, but they don't become the major enforcement point, right? So it allows us to microsegment within a vlan within a subnet, and we'll, I'll show you a little bit later in the demo on some of the cool things we were able to do, uh, with bringing access manager out. But again, uh, we just profile it basically on the way it gets on the network, and then we can dump it into the, uh, you know, IOT building group.

And then that policy matrix that gets defined is what enforces the ma uh, the microsegmentation rules. Any question? Go ahead.

Noshi, Everything is set up because iot devices become more vulnerable, became mm-hmm. More vulnerable, right? Yeah.

That's why you do segmentation. Yeah. So, Well, there's a couple things, right?

So the microsegment or the iot devices depend on a couple things, right? So they like to broadcast, they like to have layer two adjacency. So typically what it means, say in a wireless world, it means I suddenly have to generate multiple SSIDs to handle the broadcast traffic.

This way, uh, it's almost as if the SSID just becomes a logical container. And we can use the SGT as a way to segment out so that the io, you know, your door locks won't ne won't see the broadcast traffic from the, uh, uh, you know, the iot. So the HVAC controls In most cases, you don't have one IOT type, you have correct many, and you want to separate them, and, And you can do it, right?

As said, this is, this is the kind of the, um, OT segmentation, like I come from, uh, the, uh, federal background. So we used to build parallel networks for everything very costly, very expensive. And it's the same thing in the OT world today, right?

It OT completely separate. Uh, one of the things that we're seeing people migrate to is being able to use like group tags to be able to provide that segmentation, that logical segmentation on the same physical infrastructure. The dark downside on the other end is sometimes they built an OT network mm-hmm.

And they dump all kinds of function into that. And then yeah, you have kind of the same problems that you had before. Yeah.

So, yeah. So it, it's not a, it's not a panacea for every, every potential problem, but for those OT networks that, that we can get to conversions on, it's a great way to provide that single physical infrastructure for multiple logical environments. Question?

Good? Yeah. Okay.

Sorry. Alright. So, uh, did I, there we go.

Yeah. So with the policy, right? So we can actually institute the policy for the building device.

Again, like I said, it could be door locks, could be video cameras, what have you. And then I, I really wish it was more complicated than this. It's really kind of point and click.

It's like, here's this group, here's that group permit deny. Or if I want to become more granular and do a custom ACL, it's just that simple. So we're really providing this logical matrix versus coming from the world that we all came from.

It's like, I've gotta know the IP addresses. Gotta know the port numbers. Gotta figure out what protocols to be able to permit and deny becomes very complicated, right?

That, that those access list can become very unmanageable. So ITO OT use cases. So moving on.

So another use case that we get involved in is managed devices, right? So I've got, uh, corporate managed devices, like, so at Cisco, our iPhones, our MacBooks are all corporate managed. So we use a an MDM to push certificates.

So that's primarily how we get on the network. Uh, so we do ETLS as a certificate validation, or you could do P-E-T-T-L-S, whatever you wanna do with an inner method, uh, for certificate based. So, and everybody knows there's challenges doing certificate based authentication, but, uh, what we're trying to do here is provide that operational simplification so you don't have that heavy lift for doing ETLS that you normally would.

So again, uh, we can do certificate validation in a couple ways. Uh, Alex had mentioned we have an IDP, uh, integration with intra, we also have an integration with Meraki Systems manager, which is integrated, that you can use certificates from. So we have a, a couple different ways, depending upon the scale that you need for, for your organization to do certificates.

Uh, but very much the same way we, you know, you get on the network, you do an EP authentication with, you know, use TLS as the outer negotiate with the certificates, you get an access acceptant, you're on the network. So the other one that we've seen, and, and there's a lot of work being done here, uh, I'll call 'em, you know, semi managed IOT devices where now that most devices are starting to ship with sys, uh, the secure unique device identifiers, customers are wanting to use thesys to actually authenticate the devices onto the network. So there's some interesting, like where you eventually see this going is like your light bulb.

You screw in your light bulb, it powers on, and you're using the instead of a MAC address, you're using the CD on the device to actually provide, um, the authentication mechanism to, uh, prove that it should be on the network. So we're starting to see this. So again, those don't necessarily have great user interfaces.

You're typically kind of vicariously going through a, through an app or something to, uh, to be able to put them on the network. So the fact that we can actually, uh, be able to use the network to kind of profile and then provide that segmentation is a huge benefit, uh, that, you know, allows us to create these simple rules. 'cause then they don't have to know specifically, is it X vendors iot device, or why vendor's, iot devices, all these IOT devices, I'm gonna, uh, put into a, uh, into an SGT.

But again, same thing, mix and match or rule sets, you know, kind of plug and play as you, as you move along. Uh, finally, uh, I guess as Alex had mentioned, uh, the RA ID integration that we do, so now got a larger organization, we've got intra id, I've got multiple groups of users, multiple device types that are out there. How do I make this scalable?

And again, apply the Meraki model of operational simplification, uh, to being able to manage an IDP and get those devices into the network. So, uh, one thing Alex had mentioned is, and I'll show you in, in the demo in a couple shots, um, we actually do sync the intra ID database to the Meraki dashboard. So we can pull in the users, pull in the groups, uh, so that we can actually use those to define the rule sets and the policies.

Go ahead. You got a question? Yes, go ahead.

It's called client misbehave. What if a client misbehaves? Yes.

So this is, this is the ultimate challenge we have, period, right? Is what happens with misbehaving clients. I mean, that's, that's not one x that's in the millisecond world instead of the second world of Microsoft.

Yeah. So, uh, if what you're saying is, uh, if I understand your question correctly, what happens if a client, a supplicant doesn't authenticate correctly And it starts a new one and A new one, and it starts a new one? So, I, I have a beautiful example of this, and my daughter will hate me because, oh, Alex and I just did this, uh, before, before the session.

So, um, the demo's running on my home network, so I'll get a chance to see my home network. Uh, but one of my MacBooks, which we're running ETLS on misbehaved, so we had to use the tools that we had. I live in New York, so we were troubleshooting why this ETLS client on my, my MacBook was misbehaving.

So we used a bunch of different tools, the logs that come up in, um, in, uh, access Manager. And then it triggered, uh, as MINTA had just showed you, uh, it triggered the intelligent packet capture. So we're actually able to pull the intelligent packet capture and see, uh, the e messages go back and forth and realize that, uh, I, they had to, we had to go in and re-accept the certificate for ETLS.

It wasn't, uh, it aired out. So my daughter had to go in and, and, and click the right things to get the certificates back online. So yes, we can get notified.

The, uh, intelligent packet capture actually does a phenomenal job in helping us troubleshoot remotely, uh, the e authentication. So we can get fairly granular, fairly deep, pretty quick, Uh, just on the intra ID that I got, what you can, I, I authenticate against enterra and I, you can assign me a group based on this membership. So now something changed, I lock out.

Mm-hmm. Somebody else is logging in. Can you then interact, reevaluate, and assign a new policy?

Or how is this working? Yeah, So it depends on how you're authenticating in. So if you're doing ETLS and you're doing machine authentication, right?

So basically installing the, yeah. Then, then you're based on not the user login, you're based on the machine login. So that's kind of, uh, a different scenario.

Now, ETLS doesn't inherently allow you to do multi auth, meaning I authenticate the device and the user. There's other protocols, like, uh, eep Fast used to do it. TEP does it where you wanna be able to have multiple auth.

E chaining is basically what we're talking about, right? I auth authenticate the device, I put it in a, put it in a vlan, put it in an SGT, then I authenticate the user and I can move it. That's like the functions of ETLS today and TTLS aren't there yet.

Yeah, I see. The industry is a bit shifting. We all want zero trust approach.

Mm-hmm. Yeah. And this is following the user.

Every, everything becomes user centric and enter ID centric. And we would like, kind of in the future to see everything covered so that we somehow have a reevaluation that it is not one time I got access to the network. Now I'm in.

So that when this condition is changing, following the condition access approach, also my policies are changing with, Right? So one of the things you can, uh, you know, like in, we've seen it nice and we've seen those, right? You basically tweak the authentication timers, so, or the association timers in the wireless network to trigger that.

So if the device falls asleep, it'll off in the back end Thing. Um, you're talking about more like application access control, those types of things. Yeah.

So I would, I would say one thing we're trying to do is look at this as a kind of a East west network kind of segmentation. Um, the ability to apply those policies, but we still have things like SSE where you'd be able to, um, oh yeah, that X is really dark, I couldn't see it. Um, uh, but use things like SSE to be able to do that application enforcement where it could follow, um, things a little bit more closely with the user and the access to the resources.

Um, you don't have to have that, but if you do need to get down to that granularity, that's a way to kind of combine the two. Yeah, I understand where we are standing now. Mm-hmm.

Just saying from my wishes as a customer, this is where, where I see everything is going, zero trust, identity based, no longer machine based. So I think machine based is a thing that will fade out over time and everything will become more identity based. No, absolutely agree.

And and that's our, sorry, and that's our struggle with certs, right? So you put the cert on the device, if the user logs out, then you're hoping that they didn't approve that cert in the trust store for every de every user on the device, right? 'cause then they're basically using your username or your credentials to get on.

So there, there's work being done now to do some interesting credential work, uh, in both the I-E-T-F-I-E-E and uh, wifi alliance. So we'll start to see things develop a little bit more. Um, again, with intra ID kind of getting back to that, that similar topic.

So this allows us to logically separate out the network. So I can have multiple EEP types on the same SSID on the same wireless infrastructure, assign them to different, could be the same blan, could be the same subnet, and then, uh, do this with group tags. Or I could actually, as, as Alex has said, we could push the VLAN information, uh, to the access point to the switch subnet, and then also do group tags as well.

So we can do this all based on how they come into the network, or come on. And then if they switch SSIDs. So, uh, and again, Alex had mentioned this too, so, so the important thing is the initial authentication goes back to enterra.

And then what we do is we cache it so that we cut down on that latency time, uh, for having to hit enterra every time we want to do some type of an authentication. Because the, the big thing is the more users you have going to enterra, right? Doing that authentication, that database gets really huge.

So we're pulling in those users that are actually actively authenticating onto the network. And as I said, policy, same thing that we showed in the IOT example, right? Same kind of mix and match.

I picked the, you know, the SGT group permit. Deny who else I wanted to talk to or just give it internet access. All can be done just, uh, a couple simple clicks.

And as we mentioned before, so we do ETLS, we do E-T-T-L-S with pap, and then you can do MAC address bypass, and you can also do IPSK. So I'll show you an example of IPSK. Like it's always been kind of, I'll call it, challenging to configure IPSK.

And this way, again, we, we really do make the SSIDs become logical containers where the PSK we no longer assign to the SSID. We're just basically telling the, the access point go to access manager to get the PSK for this SSID. And that could be based off of, we can do things off of Mac addresses or just, Hey, if you have the PSK, you're gonna get the assignment.

So, uh, so onto the demo. So, uh, before we jump in, are there any questions? I just have to switch my Go ahead.

Shoot. I'm gonna switch. And So I suppose I have some fiber connections in between my Meraki fabric.

Is there a way to do SXP speaker and listening from Meraki sides to a firewall where my network is converging? So I would give you the short answer. Alex is gonna give you the much longer answer.

Um, Not Jeff. Okay. So, um, not yet.

No, we are, we are looking at ways to, uh, you know, more or less leverage SXP or things like that. Um, the one thing we have to worry about is like scaling. So if you, if you sync SXP in the wrong direction, you could blow up a switch.

So, um, we're trying to make, we're, we're doing some things, hopefully to make it as foolproof as possible, but yeah, to be able to take situations like that, yes. That was longer than I think you Just said. See, I, I would've said, not right now, But, uh, just to, so we can level set on the, on the demo as well.

So, uh, one of the cool things that we did when we set the demo up, uh, Alex had mentioned that, uh, all of our cloud native catalyst devices are, are gonna be getting this, this capability. So every switch, every access point is running the, the cloud native beta code. So this is actually Cisco iOS XE on the Meraki dashboard using sgs with access managers.

So this is kind of the latest and greatest stuff. I'm gonna switch to a chair so I can drive this for everybody so I'm not hunched over. Um, and if you have any questions, please shoot.

So, uh, what I, what I wanted to share was, this is kind of the corporate I-O-T-S-S-I-D, where we typically have identity PSK, where you're trying to group devices. This is the bulk of the configuration. It's like one click, you put the identity PSK with radius, point it to access manager, and that's it.

For the SSID, there's no complex configuration. Uh, you pick your, you know, obviously WPA two personal and move on. Now, what I do typically is I don't leave it in the, I put it in a default, SSID.

So if you scroll down, it's like, Hey, what's my VLAN tag? I'm gonna put it in a default dead end VAN, so that if you fall through the policy, I'm not gonna allow you on the network with an IPSK. This way, uh, you, your dead end, if you have the right IPSK, we'll put you in the right, uh, vlan, we will put you in the right, uh, group tag.

So that's actually a real quick, uh, kind of down and dirty way of, uh, getting that configured. And as you can see in the left hand side, now, uh, in the pan, we have an access manager, and can everybody see, do I need to make it bigger? Let's, good.

We have an access manager, uh, panel here. So what we can do is, you know, we'll look at users first, and I'll show you how we, how easy it is to sync Tora. Uh, so if you want to add your IDP, all we have to do, in this case, you can see a, a quick summary of the number of users we have and the number of groups that we have.

But in order to add intra id, you just go in and click, and you can add it fairly quickly, right? It just puts your tenant ID, the application ID value, and it'll sync and pull in the, in the information. So, again, much simpler, much quicker than we, we normally would have, uh, with trying to manage this across multiple servers.

And then you can actually come in here, and as I said, we, we sync the users and their groups. So now we actually have usernames, uh, where they're coming from, the IDP, and we have the user groups. All of these are attributes we can now use for authentication, wired or wireless onto the network.

And again, with that, we can also apply them into, into different sgt. So, and we don't really bring the, the user information that we're bringing over, like if you click on 'em, it is just basically gonna bring you, uh, kind of what groups they belong to. If they belong, they're able to belong to multiple groups.

So, uh, let me move on here real quick, since I know we've got some time. So, uh, you can also bring in certificates, as I said. So we can bring in certificates from, uh, system manager, bring 'em in from intra ID, and use those for both.

Uh, so when we use 'em for ETLS, obviously there's one on the client, one on the server with E-T-T-L-S. It's on the, on the server, right? 9% of the time, uh, we're giving an anonymous identity, uh, for that outer tunnel so that we protect that user's, uh, information.

So, uh, let me go real quick and I'll show you like the next step that I used to to, to do this was I go to a adaptive policy. Now, again, we've consolidated all of this under access manager to make it easy to use. So this is, this is the foundation of the rule set.

Basically what we're doing is creating a, a group name, right? You can call it whatever you like, uh, you know, test, you can create an SGT value, uh, 700, and then you put your description and you can review the changes and you click and it pushes it to the, to the infrastructure. Now, what we want to do from here though, is this is already set up that we have on some of the, the, uh, the user groups.

What we want to do from here is go create policies. That's really the important part. And this is, this is the simplicity of the Meraki interface on creating these, uh, what used to be complex access control lists.

Uh, it gives us the ability really quickly if we want to, uh, I'll take a corporate IOT example. Um, and what we've done here is we can actually go up and add a policy, and you see all your s STTs that are available, you can click on one and you can see what's blocked in red is already in use. That's already blocked.

So what we can do is say, okay, I don't want my corporate IOT to talk to guest, and then what do I wanna do? Allow, deny or do a custom. The custom is an acl l if you wanna put in a custom IP based ACL absolutely can do it.

But if you wanna just say, Hey, SGT, you know, 500 can't talk to SG T 700. Um, I just did a nation ports it. So because, because it's in the Mac, it's a, it's a metadata field in the Mac, it's everything.

It is not a, now if you want to do specific ports, that's when you go in and do the custom ACL. Yeah. So You do custom A CLI can do a port.

Yeah, you can do, yes. So I Could, for example, block SIFs in my client workspace Yeah. To prevent ransomware attacks.

Yeah, You could, anything that you can do in a traditional IP, ACL, you can actually, you can put in there as well, right? So what you'd wanna do, if, if you're gonna default deny, then you're gonna wanna put in an ACL above it that permits the specific traffic that you're looking for. So, again, like I said, I wish, I wish the demo was more, more involved in what it is to, to show you how to do these, uh, uh, the, the permitting and denying of, of these group tags.

But, uh, the policies basically immediately get applied into the infrastructure. So the, the next step to that is, okay, well what happens from there, right? So if I go back to access manager, right?

So now we, we've created the policy, well, we've created the tags, created the policy, created the network that it's gonna be on. So obviously we're not gonna do it here, but we've got clients running in the network. So that was my daughter's, uh, work this morning to help us out.

Uh, what we can show is the session log. So this is where you would go to see, um, basically Radius, You wanna show the rules, the rule Configuration. Yeah, I'll get, yeah, I'll get, I just wanted to get to the authentication and then get to the rule.

Got it. Uh, so right from here, you can actually see, I'll do the last hour. You can see, uh, authentications, it'll list all the authentications in there, right?

So you've got, um, in this case, IOT hvac, I'm using as IPSK, uh, we've got E-T-T-L-S coming in, uh, from, uh, one station on corporate, BYOD as an SSID, and then we've got another ETLS, uh, station coming in. So if you click on them, you get a pop-up window and you get immediate information on, uh, what type of device. The cool thing that you can see right from here is what SSID, what VLAN would adapt policy, uh, SGT, it's getting assigned.

And then if it was a failure, you would get some additional information in here on where you needed to go to troubleshoot. So, and it, because it's certificate based on this one, we can actually see information on like the TLS, uh, cipher suites that were used. So there's some additional information there for, for those.

So, uh, back to what Alex was saying, if we go back to the access rules themselves, hold So this is actually how we get the authentication done, right? So if I go create a rule, right? It's a, it's a linear rule, so you've gotta, as with anything, right?

You've gotta make sure that you don't block something first that you, uh, you want to permit. So in this case, um, we created, I created a rule on corporate managed devices. This is one that was using an MDM.

So the first attribute that we used was simply just using intra ID as the data source, the IDP source. And then what you can do is you can actually go in, because we're importing all the in ID information, it auto-populates the list of groups. So if I wanna match multiple groups, I can match multiple groups.

And then again, this was just, Just just a side question. Yes, somebody's editing this in intra id, how fast is this sync until a new group shows up here? So you can do two things.

One, there, there's a default time. Do you remember what the default sync is? I don't off the top of my head.

I can, it's on the, uh, I'll get back, but you can also, if you know somebody's edit, go ahead Kevin. Four minutes. Four hours.

Okay. Well, but you can actually go back in and, uh, there's a sync, manual sync, it'll trigger. So if you know somebody's, uh, editing intra or adding new user groups, you can go in and do a manual.

So You're doing skim provisioning, I assume, or something like that. I believe. Kevin, do you know specifically how we're doing the provisioning?

We, we've got a regular polling and synchronization. Uh, you, we can trigger like a resync. So if there's new users provisioned or a change made at intro, we can force that.

But we'll, we're bringing the timer down and we mean to make that configurable in the future. Anyway, thanks for the question. Okay, so, uh, let me quick jump back to the, uh, the access rules.

So like I said, in this case, the first one we're doing is, uh, ETLS based. So if we look at it, right, so we're using intra, we're making sure the account's enabled just to make sure no one with a invalid account is getting on. And then we can actually use an endpoint certificate.

So in this case, we're using anything that contains a DP, which is the certificates that we issued to the device. And then this is the key part for us, which is you can allow full access, deny access, or do the restricted access. And in the restricted access case, this gives us the ability to assign out of VLAN Adaptive policy, domain identity PS K group policy.

So it gives us the flexibility there. So in this case, we were just saying, I, you know, just said, Hey, I'm gonna put it in a VAN 300. I'm gonna put in Adaptive Policy Group Corporate manage, which we defined earlier.

And once you save it, that's the fir, that's the first rule that's gonna get authenticated. Uh, to show you the other one, this was the identity PSK one, where basically come in, the actual first attribute is the network access. So basically saying it's coming in on a specific SSID.

Um, and you can click and pull down, do the dropdown on the SSID restricted access. Again, give it the vlan, give it the SGT, and this is where you actually type in the identity PSK. So you're not actually binding the identity PSK to the SSID like we usually would.

We're actually binding it to the authentication rule and the policy. So any questions on that before we Good? Alright, so again, same thing, uh, for E-T-T-L-S, similar kind of configuration.

Now you can get more granular, I didn't want to get too far down in the weeds on these configurations, but you can actually, on the same SSID, you can apply different sg ts and policies between using E-T-L-S-E-T-T-L-S and you know, based on your groups. So you can apply multiple group tags in that same SSID construct, even inside the same subnet. Now, one of the other interesting things that, that we can do by looking at the actual client devices as well, uh, one of the big problems we typically have is random Mac addresses, specifically on wifi, people coming in with random MAC addresses.

We can actually, uh, police on random MAC addresses and make policy decisions. So if you're coming in on BYOD and you have random, random and changing MAC addresses configured, we can actually assign you a different policy until you change your MAC address to something that's not, uh, random. So again, just some granular capabilities that are inside.

Is It, so is it also tied into Meraki Device Manager? So I can create an onboarding experience with a certificate push You, you can still, yeah, you still use Mera. We're not precluding you from using Meraki MDM to, uh, to Put a policy to together so that a new user comes in, joins in open on the open network, identifies itself using SAML and whatnot, and then pushes the certificate and a change of authorization to push it to the corporate SSID.

Yeah, There's no reason you, I mean, from a certificate distribution or install, it's using an MDM is far better. Does, does it tie in with Access Manager to create those kind of policies and flows? So you would use Access Manager to identify, you know, basically you have the cert and the search store here, you would use the access manager to reference the certificate that that systems manager push down.

So if I go back, uh, let me, sorry, I'm jumping around on this one. If I look at certificates, because this is my network and I have both, um, systems manager and enter configured on it, I ha I do have a, you know, the, uh, ca for from systems manager Yeah. Configured.

So you can actually have a mix of multiple IDPs. So in this case, I have one that I use for just authenticating against systems manager and I can still apply policies to, yeah, And to your, to your question, we have a thing called Trusted Access that, sorry. No, you're good.

Um, uh, a thing called Trusted Access that can be used along with it so that you can provision BYOD devices, for instance, um, with TLS. So, So, uh, what we can jump to is, we'll, we'll, uh, we'll jump in on kind of the intelligent packet capture piece, what we were talking about before, just gonna show, uh, some of the capabilities. So as I said, uh, Alex and I were, were downstairs trying to troubleshoot why we, we had an ETLS client failing and, you know, the intelligent packet capture on the MR picked up that we had Radius login failures.

So again, you just click on the, the intelligent packet capture, and there's a bunch of different, uh, profiles that you can use, and one of the cases you can pick on eep, and it'll actually bring up the EEP types and just filter out the EEP types and highlight them so that you can come in. And, you know what, we basically found out that, you know, there was an alert down here that, you know, the client was getting disconnected, and that's when I called up and found out that this certain needed approval on, on the laptop. So definitely, definitely a, a massive time saver.

And the same thing can be done from a group tag perspective. Uh, we're not doing group tags on this one right here, but you can pick on an adaptive policy filter and it'll highlight and show you the adaptive policy interactions between the, the sources and destinations. I'll go through, go through a few of these, and then if you have any questions, anything, just let me know.

Thanks. Uh, so is there more, I usually try to put something a little more cheeky in there, but, uh, that's what I came up with this time. Um, so as Steven mentioned, we're working on bringing in all of the kind of cloud native xe, um, supported switches that's like 9,200 L um, here soon, like 92 hundreds.

We're gonna be bringing in 95 hundreds, which are probably less likely for, uh, one X and these types of services. But, um, as we bring in all these platforms have support out of the box to be able to, you know, perform authentications authorizations with access manager. Um, and, uh, I think it's, I need to verify that it's, it should be 17 15 3.

Um, we will put it in our release notes. So let's, oh, sorry. Uh, we'll put it in our release notes.

Um, so if you are looking at this later, you can check and see. Um, we are building out a, uh, user database and dashboard. Not everybody wants, uh, you know, or has like the need for NID.

Um, some smaller organizations wanna just have a user database. They can manage themselves, see this a lot. Um, especially, I mean, unless you have like hundreds and hundreds of users or thousands of users, a lot of times folks wanna just build something quickly.

This also means that you can have backup user accounts if you don't, uh, like for, um, you know, temporary users, um, like contractors that come in. Um, but there will be a UI and an API based management so that you can create accounts, manage accounts, um, you know, however you'd like, whether as a human or as a script or, you know, whatever running, uh, I mentioned this earlier, but we've been working on a lot of things to dynamically, uh, change interface configurations based on, you know, small things like you could match C-D-P-L-L-D-P, um, type data and automate a port that's not necessarily secure in any way, shape or form. one X or MAB to be able to change a port config.

And an example of this is we have a feature called Secure Port, which is where our access points use, uh, certificates to actually authenticate and then get a trunk configuration so that they can pass traffic. Um, we're bringing that into access manager so that we can have a little bit more control over what the interface configs are, but be able to make sure that if someone unplugs an ap, the port isn't open for the world to do whatever they'd like. Um, and that's a, that's a big one.

I'm actually looking forward to this 'cause there's a lot of other things that we're looking to build out, uh, trying to kind of create a way to secure, but, you know, have some of that automation. Um, for config, This is also addressing the use case of unmanaged switches. So often we have all these nice policy and somewhere somehow added an unmanaged switch, and then they are sitting, uh, everybody plugs into to, to that unmanaged thing.

So you could be able also to limit then, I don't know, via vendor MEC or see if you have multiple me addresses on such Box. Yeah, if you could, um, going back before I get to that next one, then, uh, in that case though, we could also use something like multi auth, which is you can authenticate many, many, uh, devices by the port and that gives you the ability to still apply policy as that traffic ingress. And so, um, if it was like Macau or if you're doing like actual one x, um, unmanaged switches are pain.

So it's just kind of trying to work around some of that. But, um, that's a way I, I would probably do it is probably using multi, multi auth and then just applying those policies directly. But you could use the port, um, like a port template and essentially Put it in security.

I would shut it down. Yeah. Yeah.

But could I, could I also use NEAT or something similar to Neat so that, ah, which is actually being authenticated in multi-domain as well to prevent misuse on the uplink, Right. So definitely a goal. Um, one of the things that's kind of scary about, uh, having the infrastructure authorized, um, is there's any blip in like a network device doesn't connect.

Um, a lot of people will try it and then not necessarily lose it, use it through the whole architecture. So, um, definitely want to do something like that. We, uh, as I said, with the access points, we have the ability to, um, authenticate them with a TLS certificate.

Uh, that doesn't preclude us actually looking into like, you know, switching those kind of boxes. Yeah, absolutely. And I mean, it's a good, it's a good call.

I, it's something we've been looking into, I'll just put it that way. But, um, yep. The other one, uh, and this one's important, and Kevin that popped in here has been, um, doing a lot of really good work on, uh, this profiling side of things.

I mean, not everybody knows what's connected to their network or knows what types of devices you have. Really distributed environment, doing inventory and trying to track what's there is difficult. And so not only difficult, but also trying to identify what types of groupings you should, uh, create for policy.

You could put everything in iot, but as you mentioned earlier, um, you have lots of different iot devices and some of 'em are in the different policies than others. And so we are building out, uh, taking profiling attributes and, um, doing really granular profiling, not only so that we can tell you what type of device it is, but also make suggestions, uh, or guided SGT creation so that if we see very like common device types, uh, be able to group those and say like, you know, would you like to create an SGT based on, uh, that device grouping? Um, I didn't put this on here, but we are also looking at pulling in, uh, flow telemetry and then giving you kind of a guided policy creation on top of it so that you have two devices and you wanna make sure that you're not, you dropping legitimate traffic.

Be able to look at, um, historical communications and yeah, have a policy that, uh, that you know is not gonna get you fired, I guess is, uh, best way to look at it. Starts with the clients, right? What's that?

It starts with the client. That's the most important part to get them visible how they behave and Absolutely. And in the meantime, like we do have support for things like, we do flow telemetry exporting.

So a lot of folks have flow analysis tools, um, like secure network analytics does actually this policy, um, kind of visibility so you can see the flows between groups. It's neat stuff. Um, but yeah, we wanna try to bring all that to the cloud so you don't have to have, um, you know, services that you have to manage yourself.

Last thing, uh, IDP expansion. Entry ID is just the start. Um, this one's a little, uh, is kinda being worked on in parallel to bring in more and more, um, you know, cloud identity providers.

Uh, I think the biggest thing is we wanna try to keep it as simple as possible. Same workflow, add new IDP, pull in the accounts, and then be able to have, you know, the granular matching of, uh, users and groups, et cetera. Um, but that sort of wraps it up.

Any, any questions? The end? Any plans for other, uh, identity provider than enterra id, Okta or Kevin?

Uh, YYY, yes. The, um, uh, obvious ones be Google and, uh, Okta that we want to work on next. There's also some Cisco developments on this front too, that we'll be working with.

So, uh, all of the above. And the goal would be to make those IDP integrations relevant to other services in Meraki dashboard too. So not just for our security use cases, Any plans on integrating it with the MX series, so I can finally do group VPN based on saml, Ah, uh, integration with, uh, mx.

So, yes, uh, uh, yeah, things we're, what what we've delivered first is focused on managed switching and, and wireless. Um, we also have other categories of devices like switches that are only in a hybrid mode monitoring, so there's other options to support and multiple use cases for the mx, uh, potentially including some additional authentication options as well as the ones we've outlined today.