 Hello, everyone. Picture yourself in 1995, we are looking at IPv4, running out of space, everybody's panicking, we don't know what we're going to do. This is what we're going to talk about today, so stick with us, we'll be right back. Hey, John, how you doing today? Good. Hey, yeah, let's talk about IPv6. IPv6? It would be getting married by now, I think. That's right. I was going to say, I was going to make the joke that if you bought a cat, if you had a cat when IPv6 was launched, the cat would be dead, but apparently it's not inclusive for cat lovers to, for me to make that joke, now that I just did anyway, so. Hey, I'm a dog lover. Cooper's hanging out and is kind of over there because he'd be in the pest today. I can hear my two upstairs that are winding at the door, so my wife must be around somewhere. Yeah. But IPv6, why are we still talking about this? We're still talking about it because what we're going to talk about today is Azure AD is going to start natively accepting authentication requests over IPv6 traffic. Why is there any IPv6 traffic? Today there hasn't been, but now starting later this month and into next month, we're going to be enabling IPv6 support across the board in Azure AD. Good times because IPv4 address space, as we know, has basically been depleted at this point, so it's a big borrower steal to get a new address. Actually, last conference I was at, we had a conversation. It was a networking thing, and I asked somebody if they were adopting IPv6 or if they were doing anything with it, and they said, why? Because everything they do, whether it's in the cloud in Azure or AWS or any other cloud, is all private IP spaces. They said, we'll never run out of that because we've reused the same addresses or classes across our environments, and there's no point for us to do that. Your private spaces, yes, but with our new work from everywhere, work from anywhere, remote worker space, and those great things that we have, mobile devices, our insert favorite brand name of phone here, a lot of those now support IPv6, and those mobile operators are using that space for those devices. So, we need to really start thinking about that and using those public IPs to our advantage. Okay, no, that makes sense. You know what? I had not thought about the proliferation of mispronounced that, but the growth of the mobile market, especially IoT is also still growing, and those all require IP addresses. So, I had not thought of that, but you're correct. It's going to eat up into the, oh, the pool is depleted, but the ISPs are sitting on a stack of them that they're slowly renting out. My ISPs actually provide a IPv6 address and a block for personal use. So, the home lab where I do my testing in has IPv6 support enabled, and so I can actually see IPv6 traffic coming from my home network. Okay. One thing about IPv6, you mentioned Azure AD. I seem to recall getting an email about actions I needed to take. Was that in the same relation? Yes. So, about mid-February timeframe, we sent an email, and I think I have it up on my screen here, if we can show that. We sent an email talking about IPv6 coming to Azure AD, and we want to make sure that customers add your publicly available IPv6 ranges to your named locations before we flip the switch to start turning this on. Okay. You'll have to tell me what is that location, that trusted location, what is that about, and where does that come from? Yep. So, we have this concept of named locations in Azure Active Directory. Those named locations get used in several areas. So, you can add a named location to a conditional access policy, and either allow or block traffic to or from that endpoint, and then it also gets used to enhance detections in tools like identity protection. When traffic is coming from a known trusted location that's defined by that network location, it can lower the risk score associated with that sign in. And so, I can show you exactly where we would go and configure that and where that's set up. Okay. So, this is my test tenant, and we'll go into security, and we can go to named locations. Okay. Do you want to maximize this? Yep. Let me maximize that. Sorry about that. No worries. So, we're in named locations here, and this is my trusted location for IPv6 that I've been testing with. Okay. So, that is if you're a company and you have branch offices or a warehouse somewhere where somebody's connecting to your main office for inventory control or anything like that, but you know that that place is safe, so you name it and define it as a trusted location. Yeah. You can define locations and not mark them trusted. Okay. So, I know this IP address, or I can say I know this IP address, and I want to add a level of confidence to it by marking it trusted. So, that would be, yes, Contoso's headquarters. They know that every bit of traffic flowing out from this IP address is one of their headquarters public IP addresses. Okay. And they want to mark that as such. And then what's great is now I can combine this with a policy in conditional access and say for this policy, I'm testing with a specific user. Yep. Any cloud application that falls in the condition of any network location except my trusted networks. So, this is a very restrictive policy that says anyone accessing any cloud app from any network is going to be blocked unless that network location is marked as trusted. Okay. So, that's something you would set for your most critical system. I only ever want my accounting people to access the accounting application from Contoso's headquarters network location. Perfect. And if they're coming from outside of that, they're going to be blocked. So, the one thing to make sure of when you're doing that is to exclude anything like your emergency access accounts, your break glass accounts to get back in because if you lock yourself out, that is a really painful process in order to get on the phone with support, prove that you have access to that tenant and get them to help you get back in. It is a very painful process. You do not want to go through that. That is the worst thing to paint yourself into a corner. Yes. Do not ever try to paint yourself into this corner. I think I'd done that once on stage doing a demo and I blocked the accounts that I was using for my demo. I did it one time and called the PG and they were like, don't you have any other accounts that can get in? And I managed to find one account that I was able to get in with and fix the policy and change it and was able to get myself back into my test environment. It was not a fun day. I got laughed at for a little bit from the PMs. All right. So, now that we have this policy, how does somebody make sure that it's working? Yeah. All right. So, we can go to our sign-in logs and see that traffic flowing in from a network location. So, if I go back in, I can go to my sign-in logs in Azure AD and I can look for specific traffic patterns. Is this something while we're waiting to this to refresh? Is this something that Sentinel also kind of pitches in or gets the data from? Yes. If you're exporting your logs to log analytics or Sentinel, you could search through and query those logs for traffic patterns. So, we'll look for IP addresses that include, and this is really easy for IPv6 traffic. They all have colons in them. So, if I just look for IP addresses, contain a colon. This will now filter my logs. And, of course, today while I'm doing a demo, the sign-in logs are going to go a little slow. All right. There we go. So, I can look and I can see, yes, I have traffic flowing through this IPv6 endpoint. And if I click on one of these entries, I can go to conditional access. I can see my test policy. Okay. And under location, it says not matched, which is what I expect, because this is a trusted location and has been excluded. And there's the public IP that was seen coming from my device. And so, it allowed that traffic to flow. Okay. If I came from a network location that was not part of that, I would get a green matched and that traffic would have been blocked. And so, I don't have an IPv6 version of that, but I can show you a IPv4 block from here. And I had matched on this traffic. And because that traffic was matched, it blocked. Okay. That's very cool. Very cool. And it's like we sent the email and I seemed to recall when you showed it on screen that this has to be done before March 31st. So, that's coming up. Yes. So, what's going to happen on April 1st? So, on April 1st, on April Fool's Day, or thereabouts, you'll start seeing IPv6 traffic show up in your sign-in logs. So, we're asking customers to go in and update those named locations before that point in time. We want you to do that because if you have a restrictive policy set that says block anything but my trusted network locations, after we turn on IPv6 traffic, you may end up with a block on your users. So, we want your users to continue to be able to access their resources. We don't want you to have a flood of tickets come in for IPv6 traffic and your users being blocked after they've been able to access resources without any problem. So, we have an article that we've published here that talks about IPv6 support in Azure Active Directory. You can get there through aka.ms slash azuread IPv6. Okay. I'll put that in the show notes below. All right. And this goes over the basics of what's changing, when it's going to happen, what we want customers to do, and then how they can actually test like I just showed in their own environments. So, you can create what's called an NRPT rule and point that to other DNS servers so that you will get IPv6 endpoints for login.microsoftonline.com. Okay. Once we turn on IPv6 support, we want everyone to remove those NRPT rules because if we update DNS settings on our side, those older servers may not see that as we roll through servers. So, we want to make sure that everybody has the most up-to-date information. So, you can go through, you can test here. And this actually talks about how to find those addresses in your sign-in logs. And if you're using log analytics, a query that you can use in log analytics to look for those IPv6 addresses. Yeah. And we're doing this at the end of our 1st of April. So, we're cutting it a little close and hopefully this will be published hopefully a couple of weeks before that we get to that deadline. But that has nothing to do with like virtual network or your workload within Azure starting to use IPv6, correct? Nope. This is separate from your Azure virtual networks. So, this is specifically Azure AD endpoints. This is the authentication stack. This is making sure that your users can get into the resources that are protected with Azure AD. Okay. And so, I guess we'll have to have another episode where we cover IPv6 within virtual network and within your workloads. But this is strictly for authentication. I think your buddy Michael Vendor might be equipped to have a conversation about that networking side of things. That's the point. That's the plan. Anything else that we need to really kind of grasp at in regards to IPv6? No. We just really want people to take this seriously and take a look. Go do an audit of your network locations. Make sure you update them, keep them up to date. Mark things as trusted as needed and check your conditional access rules. Make sure that you've got your policies set up accordingly. Something that just popped into my head. In this day and age with the amount of people that we have working from home and working remotely, if you said that your ISP is giving you IPv6, that means that there's probably any number of IPv6 or ISPs that are providing IPv6 IP address for their endpoints. Yes. Absolutely. You may already be in a situation where a significant amount of your staff is coming in over those addresses. So, they may currently have an IPv6 address, but Azure AD is not seeing that today. So, Azure AD will see it starting at the end of the month. On the end of the month. But so, if we haven't updated that at that point, all these people. So, you can use those queries that you showed earlier to identify whether or not you already have a lot of staff that are coming over IPv6 and then make the change. Yes. If need be, you can then go in and add locations as you require. Okay. Perfect. Well, John, this was short and sweet, but super impactful, hopefully. Let's get everybody out there to go and update your trusted or your named location with your IPv6 info. And so, I thank you very much for taking the time and to tell us all about this. And we're going to put some information about all your Azure AD documentation and networking into the show notes. Yep, aka.ms slash Azure AD IPv6. And if somebody wants to follow you on, oh, I see it right there on the screen, at Buckeye JFlow. Buckeye JFlow on Twitter and Instagram if you want to see some dog pictures. Oh, that's right. Doggy, we can never have too many doggy pictures. Yep. All right. I am Pierre Romain or at Wired Connect. And thank you for taking time to view this content. Again, make sure to go update your information for Azure AD. And we'll see you in the next episode. Cheers. Thanks. Bye.