WEBVTT 00:00:11.240 --> 00:00:13.339 And welcome to the Everyday Defender podcast. 00:00:13.779 --> 00:00:15.699 I'm your host Chris Goosen. And as always, I'm 00:00:15.699 --> 00:00:17.480 joined by my friend from the Netherlands. How 00:00:17.480 --> 00:00:19.780 are you doing, Kos? Hey, Chris, how are you doing? 00:00:19.920 --> 00:00:22.559 I'm fine. It's finally getting a little bit. 00:00:23.079 --> 00:00:25.760 We get a little bit more hours of light these 00:00:25.760 --> 00:00:28.280 days. So I'm already looking forward to some 00:00:28.280 --> 00:00:30.839 better weather as well. So going towards summer. 00:00:31.600 --> 00:00:34.859 That's awesome for you guys. I live in Australia. 00:00:34.979 --> 00:00:37.399 We have great weather most of the time, so it's 00:00:37.399 --> 00:00:40.520 pretty good. Even in winter times, right? Yeah. 00:00:40.759 --> 00:00:43.579 I think tomorrow we're expecting like 38 degrees 00:00:43.579 --> 00:00:45.439 Celsius tomorrow, so it'll be very hot tomorrow 00:00:45.439 --> 00:00:48.740 again. um but hey i really can't complain it's 00:00:48.740 --> 00:00:51.240 uh you know it's it's pretty good uh we have 00:00:51.240 --> 00:00:53.179 no bushfires we have no floods going on at the 00:00:53.179 --> 00:00:55.920 moment so hey yeah like i said it's it's very 00:00:55.920 --> 00:00:58.520 very good um it's funny to hear what kind of 00:00:58.520 --> 00:01:00.320 different problems you have over there as well 00:01:00.320 --> 00:01:02.359 well we had some snow recently and the whole 00:01:02.359 --> 00:01:05.560 country is derailed literally when we got some 00:01:05.560 --> 00:01:07.959 snow in Hey, I was watching the Winter Olympics 00:01:07.959 --> 00:01:10.760 last night and the the Dutch are very very good 00:01:10.760 --> 00:01:13.620 at the the skiing You know skating stuff, right? 00:01:13.700 --> 00:01:15.579 So yes, that's why you guys are skating around 00:01:15.579 --> 00:01:21.379 most of the time. So Anyway in today's episode 00:01:21.379 --> 00:01:24.379 I am excited about your topic because I really 00:01:24.379 --> 00:01:28.400 am excited to hear about pass keys and Kind of 00:01:28.400 --> 00:01:30.340 look the current state of pass keys, right? So 00:01:30.340 --> 00:01:35.239 excited to kind of dig into that Uh, I have been 00:01:35.239 --> 00:01:37.900 thinking a lot about, uh, sec ops and automation 00:01:37.900 --> 00:01:40.739 and PowerShell and that type of geeky stuff. 00:01:41.319 --> 00:01:43.260 And I kind of thought it'd be good to talk a 00:01:43.260 --> 00:01:45.519 little bit about the state of where we are with 00:01:45.519 --> 00:01:48.599 PowerShell modules and automation and stuff like 00:01:48.599 --> 00:01:52.280 that. Um, and so, um, I'm also touching a little 00:01:52.280 --> 00:01:54.620 bit on your nostalgia heartstrings, I guess, 00:01:54.859 --> 00:01:56.939 Chris. That's right. That's right. I, I, you 00:01:56.939 --> 00:02:00.379 know, I, it's funny how uh long it's been you 00:02:00.379 --> 00:02:02.379 know this this this whole thing and uh you know 00:02:02.379 --> 00:02:04.560 i guess we'll kick into it straight away um and 00:02:04.560 --> 00:02:07.620 and kind of tell the story right so so i've i've 00:02:07.620 --> 00:02:10.599 called this module um module wars and if you 00:02:10.599 --> 00:02:13.000 picture sort of that star wars theme and maybe 00:02:13.000 --> 00:02:15.719 that star wars theme song playing right so um 00:02:15.719 --> 00:02:17.800 the history lesson for this is you know a long 00:02:17.800 --> 00:02:20.939 time ago in a galaxy far far away um it wasn't 00:02:20.939 --> 00:02:24.020 that far away it was it's 2012ish or so It was 00:02:24.020 --> 00:02:27.460 far away. Well, you know, that is true. That 00:02:27.460 --> 00:02:31.340 is true. I put together a script back then that 00:02:31.340 --> 00:02:33.520 when I was just sort of I was doing a lot of 00:02:33.520 --> 00:02:36.159 exchange online work, right. And I put together 00:02:36.159 --> 00:02:39.439 a script to simplify connecting to exchange online. 00:02:39.840 --> 00:02:43.840 And it started off just as a script, you know, 00:02:43.860 --> 00:02:46.620 just a basic piece of piece one script. And I 00:02:46.620 --> 00:02:49.439 ended up adding a GUI to it because I just want 00:02:49.439 --> 00:02:53.099 to see if I could do it. And then Uh, that it 00:02:53.099 --> 00:02:54.960 was great. And I used to use this thing. And 00:02:54.960 --> 00:02:57.740 after a while, I realized that I shared this 00:02:57.740 --> 00:03:00.240 with so many people. Um, and it was all over 00:03:00.240 --> 00:03:02.099 the place. Right. And that, that I was like, 00:03:02.099 --> 00:03:03.919 you know, I'm going to, I'm going to publish 00:03:03.919 --> 00:03:05.360 this thing. And I don't know. I mean, you've 00:03:05.360 --> 00:03:07.300 been around long enough. You probably remember 00:03:07.300 --> 00:03:09.560 the, the tech net gallery, right? Where we used 00:03:09.560 --> 00:03:11.360 to publish our scripts before get help was a 00:03:11.360 --> 00:03:14.340 thing. So, so I had it published on, um, on tech 00:03:14.340 --> 00:03:16.860 net gallery for a really long time and over time. 00:03:16.900 --> 00:03:19.020 And it was called connect EXO back then. Cause 00:03:19.020 --> 00:03:21.569 it. really just disconnected you to Exchange 00:03:21.569 --> 00:03:23.870 Online. And this was before, you know, widely 00:03:23.870 --> 00:03:26.349 deployed MFA even, right? So really all it did 00:03:26.349 --> 00:03:29.330 was it would launch a little box that said username, 00:03:29.430 --> 00:03:31.210 password, you click okay. And it would launch 00:03:31.210 --> 00:03:35.189 into the Exchange PowerShell modules. Obviously 00:03:35.189 --> 00:03:38.229 over time, more and more modules became available. 00:03:38.689 --> 00:03:40.509 MFA became a thing. There was a whole bunch of 00:03:40.509 --> 00:03:43.729 things. And so I, you know, started sort of developing 00:03:43.729 --> 00:03:47.449 this tool that became known as Connect 365. And 00:03:47.449 --> 00:03:51.400 I, couldn't find exactly when Connect 365 was 00:03:51.400 --> 00:03:53.319 was born, but I think it was sort of probably 00:03:53.319 --> 00:03:58.419 around 2014 or so. Connect 365 was probably at 00:03:58.419 --> 00:04:01.360 least 10 years ago. And it just became a tool 00:04:01.360 --> 00:04:06.199 to very easily connect to all the services in 00:04:06.199 --> 00:04:09.219 M365. So you could load all the modules and actually 00:04:09.219 --> 00:04:11.360 later on I built like a prerequisite checker 00:04:11.360 --> 00:04:13.180 so I could even check if the modules were installed 00:04:13.180 --> 00:04:15.849 for you. Um, and then you could select all of 00:04:15.849 --> 00:04:17.389 the things that if you wanted to connect to exchange 00:04:17.389 --> 00:04:19.689 online and Azure AD and all of these things, 00:04:20.029 --> 00:04:21.790 connect, you could select all the ones you wanted 00:04:21.790 --> 00:04:25.290 to connect to click. Okay. It would, um, log 00:04:25.290 --> 00:04:27.790 you in and it would load all of the correct modules 00:04:27.790 --> 00:04:29.810 for you so that you had one PowerShell window 00:04:29.810 --> 00:04:32.290 and you could go off and do, you know, all the 00:04:32.290 --> 00:04:35.589 things that you, you wanted to do. Um, I actually 00:04:35.589 --> 00:04:37.750 recognize the screenshot. So you put in the show 00:04:37.750 --> 00:04:41.360 notes Chris. So I probably used your tool without 00:04:41.360 --> 00:04:44.339 me knowing you back then. So that's funny. That's 00:04:44.339 --> 00:04:46.240 funny. Yeah, that's that's cool though. And you 00:04:46.240 --> 00:04:48.360 know, over the years, this has just been a it's 00:04:48.360 --> 00:04:50.600 been a little passion project of my own where 00:04:50.600 --> 00:04:53.560 I've just done things on it just whenever I wanted 00:04:53.560 --> 00:04:55.740 to test myself or do something where I you know, 00:04:55.740 --> 00:04:58.939 I could I wanted to figure out if I could do 00:04:58.939 --> 00:05:00.560 something right. So I you know, at one point 00:05:00.560 --> 00:05:03.860 in time, I think maybe 2022 or 2023, I built 00:05:03.860 --> 00:05:07.430 my own API so I could do a version check. That 00:05:07.430 --> 00:05:09.209 may mean nothing to anyone, but it was just a 00:05:09.209 --> 00:05:11.430 fun thing for me to do to be able to build an 00:05:11.430 --> 00:05:14.069 API that does something very simple like check 00:05:14.069 --> 00:05:17.430 versions. Now, long story short, and the reason 00:05:17.430 --> 00:05:21.810 we're going on this whole history is that ultimately, 00:05:22.310 --> 00:05:25.709 we were connecting to modules in PowerShell to 00:05:25.709 --> 00:05:30.230 do things. Over time, not only has names changed, 00:05:30.769 --> 00:05:32.990 Azure AD became Entry ID, and we've had all these 00:05:32.990 --> 00:05:36.620 name changes. the way we authenticate to our 00:05:36.620 --> 00:05:39.100 modules and our services has changed. MFA has 00:05:39.100 --> 00:05:41.019 become a thing. Service principles are a thing. 00:05:41.160 --> 00:05:43.420 All of these things have sort of started to take 00:05:43.420 --> 00:05:47.060 shape. And so, you know, the world is changing, 00:05:47.220 --> 00:05:50.379 right? And I've been thinking a lot lately about 00:05:50.379 --> 00:05:53.019 making some changes to Connect 365, bringing 00:05:53.019 --> 00:05:56.579 it up to date again. And one of the things that 00:05:56.579 --> 00:05:59.540 I kind of realized was there's a lot of just 00:05:59.540 --> 00:06:01.480 bad information around, right? I think a lot 00:06:01.480 --> 00:06:05.100 of folks seem to believe and think that the graph, 00:06:05.220 --> 00:06:09.560 Microsoft .graph or the graph SDK is the only 00:06:09.560 --> 00:06:13.500 way to interact with M365 via PowerShell these 00:06:13.500 --> 00:06:15.980 days. Now, if you're really, really hardcore, 00:06:16.519 --> 00:06:19.939 you're probably just using graph natively. So 00:06:19.939 --> 00:06:23.459 you're doing invoke web request or invoke what 00:06:23.459 --> 00:06:25.399 have you. Instructing your own headers and bodies. 00:06:26.000 --> 00:06:30.500 Right. But for many of us, as cool as that is, 00:06:30.670 --> 00:06:32.810 it's not always an efficient thing unless you're 00:06:32.810 --> 00:06:34.329 like a developer and this is what you do all 00:06:34.329 --> 00:06:35.709 the time, right? And if you're going to go out 00:06:35.709 --> 00:06:37.910 and write scripts to do things, you could spend 00:06:37.910 --> 00:06:39.310 the time to do that. But if you're just going 00:06:39.310 --> 00:06:41.410 to be doing like admin tasks on a day -to -day 00:06:41.410 --> 00:06:44.009 basis, maybe that's a little heavy. It's a bit 00:06:44.009 --> 00:06:46.750 of a heavy tool to be using. And so what I wanted 00:06:46.750 --> 00:06:49.069 to do was sort of talk a little bit about where 00:06:49.069 --> 00:06:54.860 we are with modules. for managing M365 and Entra 00:06:54.860 --> 00:06:57.439 or Entra ID, right? I'm not really going to widen 00:06:57.439 --> 00:06:58.639 this too much because I'm sure there's a bunch 00:06:58.639 --> 00:07:00.800 of stuff around there for just Azure. And, you 00:07:00.800 --> 00:07:03.079 know, we have those are the AZ or AZ modules 00:07:03.079 --> 00:07:05.879 for managing all the Azure service. I'm not really 00:07:05.879 --> 00:07:07.160 talking about that today. I'm really just going 00:07:07.160 --> 00:07:11.959 to talk about where we are with M365 specifically. 00:07:12.060 --> 00:07:14.980 And, you know, as you guessed it, we have the 00:07:14.980 --> 00:07:17.800 Microsoft Graph or I think it's technically called 00:07:17.800 --> 00:07:20.699 the Microsoft Graph SDK for PowerShell. I think 00:07:20.699 --> 00:07:24.959 that's the the real name. That's something that 00:07:24.959 --> 00:07:28.120 sort of came about around 2020. Microsoft started 00:07:28.120 --> 00:07:31.199 sort of making that public and you'll be familiar 00:07:31.199 --> 00:07:34.319 with the sort of MG command that's right. So 00:07:34.319 --> 00:07:38.339 get MG user and stuff like that. Whereas if you 00:07:38.339 --> 00:07:40.040 think a little bit about some of the historic 00:07:40.040 --> 00:07:44.540 way we would connect to, for example, Azure AD. 00:07:44.810 --> 00:07:47.269 we first started with something called MSOnline 00:07:47.269 --> 00:07:50.370 or the MSOL module, which was, you know, get 00:07:50.370 --> 00:07:53.930 MSOL user. Very, very old. That stuff sort of 00:07:53.930 --> 00:07:57.410 started getting deprecated in 23 .4 timeframe. 00:07:57.610 --> 00:08:00.290 I think we had the Azure AD modules, which actually 00:08:00.290 --> 00:08:02.949 use something called Azure Graph, which is an 00:08:02.949 --> 00:08:05.889 older version of what is essentially Microsoft 00:08:05.889 --> 00:08:08.879 Graph today. and you would be familiar with those 00:08:08.879 --> 00:08:14.399 ones with get AAD user and stuff like that. The 00:08:14.399 --> 00:08:16.319 evolution of all of those things that came out 00:08:16.319 --> 00:08:20.639 of those when they got deprecated in 2024 is 00:08:20.639 --> 00:08:24.000 the Microsoft Graph PowerShell SDK or Microsoft 00:08:24.000 --> 00:08:26.160 .Graph, which is really just the name of the 00:08:26.160 --> 00:08:29.740 package. That's what most people use, I guess, 00:08:29.879 --> 00:08:31.779 and that's where most people's heads go when 00:08:31.779 --> 00:08:35.850 you talk about automation and, and PowerShell 00:08:35.850 --> 00:08:40.429 use for, for M365, but it's a handy tool. Obviously 00:08:40.429 --> 00:08:43.289 there's a ton there. Um, and you know, it does 00:08:43.289 --> 00:08:46.669 obviously Entra, it does Intune, some teams, 00:08:46.970 --> 00:08:48.690 there's some SharePoint in there. It's really, 00:08:48.690 --> 00:08:51.309 really good if you want to do reports and you 00:08:51.309 --> 00:08:52.990 know, if you want to work in, for example, conditional 00:08:52.990 --> 00:08:54.690 access policies, all that type of stuff, like 00:08:54.690 --> 00:08:58.529 it's a very deep, uh, tool set, but it isn't 00:08:58.529 --> 00:09:02.110 the only tool set. And I personally find it pretty 00:09:02.110 --> 00:09:04.649 tricky to use because it's so closely linked 00:09:04.649 --> 00:09:07.269 to graph. It doesn't always work the way you 00:09:07.269 --> 00:09:10.250 expect, right? You can't just pass in a username 00:09:10.250 --> 00:09:12.409 and expect to get a result there. You really 00:09:12.409 --> 00:09:14.750 need to be formatting everything correctly, and 00:09:14.750 --> 00:09:16.570 you're going to be using GUIDs a lot of the time. 00:09:17.470 --> 00:09:20.649 So, you know, it can be a little tricky. But 00:09:20.649 --> 00:09:24.909 the good news is that there are still some workload 00:09:24.909 --> 00:09:27.710 specific modules that do exist. And actually, 00:09:28.470 --> 00:09:30.730 something I recently found that I didn't know 00:09:30.730 --> 00:09:34.759 about was the Microsoft Intra PowerShell module. 00:09:35.059 --> 00:09:38.440 It's Microsoft .Intra and it's more of a lightweight 00:09:38.440 --> 00:09:41.980 for just administration of Intra ID. So if you're 00:09:41.980 --> 00:09:43.600 going to be doing stuff with users and groups 00:09:43.600 --> 00:09:46.159 and apps and policies and stuff like that, you 00:09:46.159 --> 00:09:49.039 don't need to go and use a graph. Now, obviously 00:09:49.039 --> 00:09:50.879 you can use graph if it's doing what you want, 00:09:51.299 --> 00:09:53.080 but this is a much more lightweight, slightly 00:09:53.080 --> 00:09:57.029 easier to use module. that I was very pleasantly 00:09:57.029 --> 00:09:59.149 surprised with. And so I thought, you know what, 00:09:59.330 --> 00:10:01.629 that's one I definitely want to mention and talk 00:10:01.629 --> 00:10:05.250 about here. We still have the Exchange Online 00:10:05.250 --> 00:10:08.210 management or Exchange Online tools. Now I think, 00:10:09.029 --> 00:10:10.490 and I'm sure there's going to be some, I'm probably 00:10:10.490 --> 00:10:12.590 going to get this wrong. Someone's going to correct 00:10:12.590 --> 00:10:14.750 me, but I think this is the third version of 00:10:14.750 --> 00:10:17.250 the Exchange Online modules. So there was the 00:10:17.250 --> 00:10:21.269 original Exchange Online module. then there was 00:10:21.269 --> 00:10:23.409 V2, which was very slow and didn't work so great. 00:10:23.490 --> 00:10:25.850 And then I think this is the actual third release 00:10:25.850 --> 00:10:31.350 of the Exchange online PowerShell module. And 00:10:31.350 --> 00:10:32.629 if you're going to do anything with Exchange 00:10:32.629 --> 00:10:34.889 Online, and also if you're going to do anything 00:10:34.889 --> 00:10:37.330 in the security compliance center, sort of purview 00:10:37.330 --> 00:10:40.049 type stuff, that's the module you want to use 00:10:40.049 --> 00:10:43.850 for that. And I think what you'll find is folks 00:10:43.850 --> 00:10:47.070 who have a sort of a multi -dimensional role 00:10:47.070 --> 00:10:51.779 where you're administering M365 as a whole, you're 00:10:51.779 --> 00:10:53.419 probably going to have multiple of these things 00:10:53.419 --> 00:10:55.919 installed. I do a lot of security assessments 00:10:55.919 --> 00:10:59.679 for M365. Usually I have all of these things 00:10:59.679 --> 00:11:01.659 installed on whatever machine I'm working on 00:11:01.659 --> 00:11:04.059 because I'm connecting to Graph, I'm connecting 00:11:04.059 --> 00:11:06.120 to Exchange Online to do stuff, I'm connecting 00:11:06.120 --> 00:11:09.519 to Teams and things like that. So the Microsoft 00:11:09.519 --> 00:11:14.779 Teams... module still exists. It's still available. 00:11:14.899 --> 00:11:17.500 You can still use it. Microsoft SharePoint Online 00:11:17.500 --> 00:11:20.299 also has, it's called microsoft .online .sharepoint 00:11:20.299 --> 00:11:23.059 .powershell. That module still exists as well. 00:11:23.379 --> 00:11:26.360 So really, if we think about what's gone away 00:11:26.360 --> 00:11:30.779 and what we've lost, it's only those Azure AD 00:11:30.779 --> 00:11:35.080 specific things that have been around for a long, 00:11:35.299 --> 00:11:36.820 long time, right? And they don't work anymore. 00:11:37.360 --> 00:11:41.830 Actually, I went and found, I have a very old 00:11:41.830 --> 00:11:43.750 desktop machine that sits next to me on the floor 00:11:43.750 --> 00:11:46.289 here. And this thing is never booted up. Usually 00:11:46.289 --> 00:11:48.450 it just sits here. And I plugged it in today, 00:11:48.570 --> 00:11:50.830 booted up into Windows 11, because I don't have 00:11:50.830 --> 00:11:53.669 a Windows 11 machine anywhere else. And, and 00:11:53.669 --> 00:11:55.950 actually tested a bunch of the stuff from Windows 00:11:55.950 --> 00:11:59.070 11. So I could, you know, make sure I wasn't 00:11:59.070 --> 00:12:02.090 giving false information. And yeah, the MSOL 00:12:02.090 --> 00:12:05.509 doesn't work anymore. The Azure AD module doesn't 00:12:05.509 --> 00:12:07.389 work anymore. If you connect to it, you get a 00:12:07.389 --> 00:12:09.409 very nice error message that says its access 00:12:09.409 --> 00:12:12.970 is denied. So those, those have gone away. They've 00:12:12.970 --> 00:12:14.529 obviously been deprecated and there's been a 00:12:14.529 --> 00:12:17.529 long sort of deprecation story there since, since 00:12:17.529 --> 00:12:21.070 I think it's March of 2024, but, um, exchange 00:12:21.070 --> 00:12:23.169 online is still there. Teams are still there. 00:12:23.309 --> 00:12:25.070 SharePoint is still there. And then there's some 00:12:25.070 --> 00:12:27.210 other ones that, you know, you may or may not 00:12:27.210 --> 00:12:29.049 use, right? I think these are a little bit lesser 00:12:29.049 --> 00:12:30.549 known and then, but probably not something you 00:12:30.549 --> 00:12:32.470 would use all the time unless you specifically 00:12:32.470 --> 00:12:35.429 work in these areas. There's an AIP service module, 00:12:35.429 --> 00:12:38.529 um, for, you know, the, the old AIP or rights 00:12:38.529 --> 00:12:41.370 management stuff. There's a couple of modules 00:12:41.370 --> 00:12:43.549 for the power platform. So if you dig into sort 00:12:43.549 --> 00:12:45.549 of power apps administration, there's some modules 00:12:45.549 --> 00:12:48.409 there. Um, and then there's a power BI management 00:12:48.409 --> 00:12:50.470 module as well. If you actually are, you know, 00:12:50.830 --> 00:12:53.110 a heavy power BI user in your, in your tenant, 00:12:53.110 --> 00:12:54.990 in your environment, which is really, really 00:12:54.990 --> 00:12:59.029 helpful. So Chris, are these modules now? Um, 00:12:59.090 --> 00:13:01.990 because I was encountering the issues with the 00:13:01.990 --> 00:13:06.210 Azure AD modules, uh, uh, a while ago when I 00:13:06.210 --> 00:13:09.539 migrated to Mac OS because As you know, Mac OS 00:13:09.539 --> 00:13:12.360 only runs PowerShell Core. So the newer version, 00:13:12.620 --> 00:13:15.879 what is it? Everything beyond, starting from 00:13:15.879 --> 00:13:20.500 version six. And the Azure AD module only work 00:13:20.500 --> 00:13:23.059 on the classic Windows PowerShell. And I still 00:13:23.059 --> 00:13:25.759 get a lot of confusion from that because a sys 00:13:25.759 --> 00:13:28.860 admin to which I provide a PowerShell script 00:13:28.860 --> 00:13:31.500 will automatically open up Windows PowerShell 00:13:31.500 --> 00:13:34.399 on their desktop or server. And they aren't even 00:13:34.399 --> 00:13:37.960 aware of PowerShell Core. Are all the modules 00:13:37.960 --> 00:13:40.899 you mentioned, are they now also transitioned 00:13:40.899 --> 00:13:43.059 into the PowerShell Core world or are some of 00:13:43.059 --> 00:13:46.519 them still requiring legacy Windows PowerShell? 00:13:46.539 --> 00:13:49.100 So that is a very good question, right? I know 00:13:49.100 --> 00:13:51.700 the graph obviously is one that was built for 00:13:51.700 --> 00:13:55.200 that. Yes, that's the new one. Yeah, now I have 00:13:55.200 --> 00:13:57.700 not tested the, have I tested the Entra one? 00:13:58.399 --> 00:14:01.639 I believe I have tested the Entra one. Exchange 00:14:01.639 --> 00:14:05.289 works well with PowerShell Core. Yeah, and I'm 00:14:05.289 --> 00:14:07.649 pretty sure that teams and SharePoint do as well. 00:14:08.149 --> 00:14:10.370 The one that I'm least familiar with is probably 00:14:10.370 --> 00:14:12.549 SharePoint, because I don't do a ton of SharePoint 00:14:12.549 --> 00:14:15.789 work, right? But what is nice now, now apart 00:14:15.789 --> 00:14:17.649 from the fact that they're all named, the naming 00:14:17.649 --> 00:14:19.070 standards of these things are all different, 00:14:19.230 --> 00:14:21.529 right? Some of them, Microsoft, the Intra, Microsoft, 00:14:21.549 --> 00:14:24.330 the Graph, that's cool. Exchange Online Management, 00:14:24.669 --> 00:14:27.490 you know, the naming is all over the shop. But 00:14:27.490 --> 00:14:29.309 what is nice is that all of these things are 00:14:29.309 --> 00:14:30.870 now available through the PowerShot gallery. 00:14:30.990 --> 00:14:33.149 So all of them are there. And I think because 00:14:33.149 --> 00:14:35.850 of that, we're seeing a little bit more standardization 00:14:35.850 --> 00:14:40.350 on using stuff with core. Like you, I'm a Mac 00:14:40.350 --> 00:14:43.490 user. And so I also find it very frustrating 00:14:43.490 --> 00:14:45.009 when I need to do something and I have to go 00:14:45.009 --> 00:14:47.590 and find a Windows machine to be able to test 00:14:47.590 --> 00:14:49.950 or do stuff because I don't, you know, I don't 00:14:49.950 --> 00:14:51.970 have a Windows machine and I don't run a VM, 00:14:52.230 --> 00:14:54.909 Windows VM specifically for just modules. Right. 00:14:54.929 --> 00:14:58.090 So not anymore, anyway. Um, so, but now it's 00:14:58.090 --> 00:14:59.970 a good, it's a good call out. I do believe most 00:14:59.970 --> 00:15:02.529 of them are now cross platform and they also 00:15:02.529 --> 00:15:04.710 sort of support, you know, newer releases of, 00:15:04.710 --> 00:15:06.289 of, of PowerShell, which is, which is really 00:15:06.289 --> 00:15:08.850 helpful. Um, obviously you still get the little 00:15:08.850 --> 00:15:10.929 nuances. I get the same problem because in, you 00:15:10.929 --> 00:15:14.190 know, in my work environment, I'm one of very 00:15:14.190 --> 00:15:17.009 few that uses a Mac. So if I write scripts, the 00:15:17.009 --> 00:15:19.230 parts are always messed, messed up because, you 00:15:19.230 --> 00:15:20.870 know, I'm using forward slashes instead of back 00:15:20.870 --> 00:15:22.710 slashes. Cause I'm on a Mac and everyone else 00:15:22.710 --> 00:15:24.669 is using, you know, what, what have you. So. 00:15:24.879 --> 00:15:27.379 that gets a little interesting sometimes. So 00:15:27.379 --> 00:15:29.820 I got to think about that if I'm going to be 00:15:29.820 --> 00:15:32.399 giving scripts to colleagues to run because, 00:15:33.200 --> 00:15:37.159 you know. Yeah, maybe also good to point that 00:15:37.159 --> 00:15:39.539 out to our listeners since we're talking PowerShell 00:15:39.539 --> 00:15:42.440 now. This is not specifically Microsoft security 00:15:42.440 --> 00:15:45.759 topic perhaps, but we touch PowerShell regularly, 00:15:45.820 --> 00:15:49.059 of course. So Windows PowerShell or PowerShell, 00:15:49.100 --> 00:15:52.559 as we all know, was originally a Microsoft closed 00:15:52.559 --> 00:15:56.100 source product. up until version 5 .something, 00:15:56.299 --> 00:15:58.980 which is the latest version still shipped with 00:15:58.980 --> 00:16:01.639 your Windows installation. Microsoft branched 00:16:01.639 --> 00:16:05.759 it off into an open source PowerShell afterwards, 00:16:06.159 --> 00:16:09.820 and that became PowerShell Core. I also believe 00:16:09.820 --> 00:16:12.059 it's built on .NET something. It has a different 00:16:12.059 --> 00:16:15.759 architecture under the hood. I don't know the 00:16:15.759 --> 00:16:18.100 specifics on that. But starting with PowerShell 00:16:18.100 --> 00:16:22.440 6, and we're now up until 7 .something. 7 .5, 00:16:22.559 --> 00:16:24.019 I believe. I don't know from the top of my head, 00:16:24.879 --> 00:16:28.820 but yeah, so 7 .5. PowerShell Core is the latest 00:16:28.820 --> 00:16:31.700 PowerShell, so people please stop using Windows 00:16:31.700 --> 00:16:34.039 PowerShell, although it is shipped with your 00:16:34.039 --> 00:16:36.179 Windows installation and you have to install 00:16:36.179 --> 00:16:38.480 PowerShell Core separately. I don't understand 00:16:38.480 --> 00:16:41.600 why Microsoft does not just ship Core with Windows 00:16:41.600 --> 00:16:45.419 or makes it a default feature on Windows or whatever, 00:16:45.720 --> 00:16:48.350 but you have to install it manually. And also 00:16:48.350 --> 00:16:50.970 I see a lot of people still using ISE, right? 00:16:51.610 --> 00:16:53.250 Windows PowerShell with ISE. That's so funny. 00:16:53.649 --> 00:16:55.750 And I never, you see, I never used ISE. That 00:16:55.750 --> 00:16:58.590 was never my part of my workflow. And so it's 00:16:58.590 --> 00:17:02.190 really, well, I say that I've obviously, and 00:17:02.190 --> 00:17:04.230 I think many of us, you know, back in the day 00:17:04.230 --> 00:17:06.339 I've had... time where you log on to a server 00:17:06.339 --> 00:17:08.980 for something and then you need to look at a 00:17:08.980 --> 00:17:10.920 PS1 and the only thing that's on there is either 00:17:10.920 --> 00:17:13.480 notepad or ISE right and and I would usually 00:17:13.480 --> 00:17:15.900 just use notepad but yeah we've all opened ISE 00:17:15.900 --> 00:17:18.279 by mistake for that on those but no I've never 00:17:18.279 --> 00:17:20.160 been an ISE user but you're right it's funny 00:17:20.160 --> 00:17:22.660 to see people that that are sort of stuck in 00:17:22.660 --> 00:17:25.569 that in that way of doing things Well, I used 00:17:25.569 --> 00:17:28.289 ISE with some more complex scripts because you 00:17:28.289 --> 00:17:30.509 can add some breaks, for example, in between 00:17:30.509 --> 00:17:32.650 and do some more advanced debugging where there 00:17:32.650 --> 00:17:35.170 are some issues and you can see the actual values 00:17:35.170 --> 00:17:38.049 of your variables while the script was running. 00:17:38.750 --> 00:17:40.789 But you can all do that in VS Code nowadays. 00:17:40.890 --> 00:17:42.650 A lot of people don't know that, but there are 00:17:42.650 --> 00:17:45.250 debuggers in VS Code and you can run PowerShell 00:17:45.250 --> 00:17:47.750 there and add breaks and everything. So there's 00:17:47.750 --> 00:17:51.240 no need to use ISE ever again. That's right. 00:17:51.460 --> 00:17:53.140 And you're right though, as well with, with just, 00:17:53.140 --> 00:17:55.819 you know, a normal PowerShell. I think why it's 00:17:55.819 --> 00:17:57.700 probably still out there is there's, it's backward 00:17:57.700 --> 00:17:59.319 compatibility, right? And if you're going to 00:17:59.319 --> 00:18:02.220 be doing, um, anything with, um, and I think 00:18:02.220 --> 00:18:06.440 it's so my, uh, Microsoft forms or WPF, PF, where 00:18:06.440 --> 00:18:09.279 you have a GUI interface to a script or something 00:18:09.279 --> 00:18:12.819 that stuff historically works better on the older 00:18:12.819 --> 00:18:16.400 versions of, of, um, uh, of, of PowerShell at, 00:18:16.440 --> 00:18:17.940 you know, there's more things you need to do 00:18:17.940 --> 00:18:21.190 on, on core to make that work. And for a lot 00:18:21.190 --> 00:18:23.670 of us who have written these types of scripts, 00:18:24.170 --> 00:18:26.890 we're not hardcore .NET developers where this 00:18:26.890 --> 00:18:29.789 is an easy thing for us to transition. So I think 00:18:29.789 --> 00:18:32.250 part of it is just that there's a lot of investment. 00:18:32.450 --> 00:18:35.190 Folks have put a lot of time into building scripts 00:18:35.190 --> 00:18:38.869 and automations and stuff that still rely on 00:18:38.869 --> 00:18:41.490 PowerShell 3 or work on PowerShell 3, and they 00:18:41.490 --> 00:18:43.650 haven't taken the time. Now, I would say to those 00:18:43.650 --> 00:18:45.839 folks, if you're listening, you probably should 00:18:45.839 --> 00:18:48.079 start thinking about moving to newer versions 00:18:48.079 --> 00:18:50.680 of PowerShell, right? I'm sure there's, apart 00:18:50.680 --> 00:18:52.720 from performance and all sorts of other issues, 00:18:52.859 --> 00:18:54.680 there's probably security reasons why you'd want 00:18:54.680 --> 00:18:57.619 to be doing that as well. And as all the operating 00:18:57.619 --> 00:19:01.819 systems go away, it's something to think about. 00:19:02.720 --> 00:19:04.359 But I think that's it. I think it's really just 00:19:04.359 --> 00:19:09.680 a backward compatibility thing. Yeah, if you're 00:19:09.680 --> 00:19:11.720 installing it on Linux or Mac, it's always going 00:19:11.720 --> 00:19:14.440 to be cool. So we always get the latest and greatest 00:19:14.440 --> 00:19:18.599 when we do that. And also maybe a fun fact, PowerShell 00:19:18.599 --> 00:19:23.680 6, so the open source variant, the open source 00:19:23.680 --> 00:19:26.619 one, the PowerShell Core, was released in January 00:19:26.619 --> 00:19:30.920 of 2018. So it's already eight years ago. So 00:19:30.920 --> 00:19:34.059 it's not new anymore. So actually, interesting, 00:19:34.279 --> 00:19:37.700 I saw this week that Jeffrey Snowver has retired. 00:19:38.000 --> 00:19:40.880 Uh, or retirees retiring. And so for those folks, 00:19:41.059 --> 00:19:43.019 Jeffrey's Nova was the person who actually created 00:19:43.019 --> 00:19:46.119 PowerShell. Um, and he's a lovely, lovely, lovely 00:19:46.119 --> 00:19:47.940 guy. I've met him. I've been lucky enough to 00:19:47.940 --> 00:19:51.380 meet him a few times now at a MVP summit and 00:19:51.380 --> 00:19:52.920 had some great conversations with him. He's such 00:19:52.920 --> 00:19:55.640 a cool guy. Um, just such a smart, lovely, lovely 00:19:55.640 --> 00:19:57.779 person. And, uh, yeah, I think it was this week 00:19:57.779 --> 00:20:00.259 or last week I read that he was, he was retiring. 00:20:00.359 --> 00:20:02.460 Uh, he's had a fantastic career at Microsoft. 00:20:02.900 --> 00:20:04.890 So You know, thank you for giving us PowerShell, 00:20:05.390 --> 00:20:07.450 Mr. Snow, but we appreciate it very, very much. 00:20:09.150 --> 00:20:11.309 So wrapping this up, I guess there's a couple 00:20:11.309 --> 00:20:13.049 of things I wanted to kind of call out as well, 00:20:13.049 --> 00:20:16.029 or just draw attention to that there's some community 00:20:16.029 --> 00:20:19.009 or sort of non -Microsoft official modules as 00:20:19.009 --> 00:20:21.329 well that I really think are sort of must haves, 00:20:21.490 --> 00:20:23.789 right? Especially if you're doing a lot of automation 00:20:23.789 --> 00:20:27.369 and stuff. There's the sort of PMP dot PowerShell, 00:20:27.430 --> 00:20:29.950 which is the sort of PowerShell module for managing 00:20:29.950 --> 00:20:33.779 M365. I think it really started as a SharePoint 00:20:33.779 --> 00:20:36.359 thing, but it's become sort of a much wider. 00:20:36.680 --> 00:20:39.420 So, you know, more than 700 commandlets across 00:20:39.420 --> 00:20:41.960 sort of SharePoint teams, Planner, Power Platform, 00:20:42.180 --> 00:20:45.519 Entra. Really sort of really nice community project 00:20:45.519 --> 00:20:49.000 there to kind of build automation and PowerShare 00:20:49.000 --> 00:20:53.200 capabilities for managing M365. Really good one. 00:20:53.819 --> 00:20:56.539 Import Excel. I mean, you know, if you're going 00:20:56.539 --> 00:20:59.119 to do anything with reporting and importing, 00:20:59.319 --> 00:21:02.160 exporting, you know, CSVs are good. spreadsheets 00:21:02.160 --> 00:21:06.200 are better, right? And being able to import and 00:21:06.200 --> 00:21:10.000 export PowerShell spreadsheets, or yeah, Excel 00:21:10.000 --> 00:21:12.440 spreadsheets without actually having Excel installed 00:21:12.440 --> 00:21:15.880 is pretty cool. I think Doug Fink is the author 00:21:15.880 --> 00:21:19.460 of that module, very cool module that I would 00:21:19.460 --> 00:21:22.500 say is almost a must have. And then I've got 00:21:22.500 --> 00:21:27.140 MSale PS, which is really a wrapper for the MSale 00:21:27.140 --> 00:21:30.049 or C authentication libraries in .NET. So this 00:21:30.049 --> 00:21:31.509 was really, really useful. If you're going to 00:21:31.509 --> 00:21:34.049 be doing things where, you know, we talked about 00:21:34.049 --> 00:21:37.789 just using native graph before where you, um, 00:21:37.970 --> 00:21:40.269 you know, you do an actual, you know, invoke 00:21:40.269 --> 00:21:43.009 web requests to the end point. Well, if you use, 00:21:43.009 --> 00:21:46.529 um, the MSAL PS module, you could actually get 00:21:46.529 --> 00:21:49.450 your tokens and stuff in a, in a little bit more 00:21:49.450 --> 00:21:52.150 simple way. Um, and then you can use those tokens 00:21:52.150 --> 00:21:54.509 to sort of onward connect. So it makes it really, 00:21:54.509 --> 00:21:57.960 really simple. If you're calling APIs maybe where 00:21:57.960 --> 00:22:00.099 there aren't really good PowerShell modules or 00:22:00.099 --> 00:22:02.720 PowerShell modules are a little bit incomplete 00:22:02.720 --> 00:22:06.000 and you're going to have to rely on the native 00:22:06.000 --> 00:22:08.920 APIs. Yeah, this is a great way to kind of handle 00:22:08.920 --> 00:22:12.359 and wrap that authentication layer. So definitely 00:22:12.359 --> 00:22:16.140 something to check out. So as I said before, 00:22:16.400 --> 00:22:18.460 I'm going to be working on some updates to Connect 00:22:18.460 --> 00:22:21.619 365 over the next few months. I have some ideas. 00:22:21.880 --> 00:22:23.839 One of the things that's always bugged me about 00:22:23.839 --> 00:22:26.869 it is that it's because of the web interface 00:22:26.869 --> 00:22:30.730 or the graphical interface on it. It's always 00:22:30.730 --> 00:22:33.390 been Windows only. I'm going to do some work 00:22:33.390 --> 00:22:36.650 now to take it to PowerShell Core and make it 00:22:36.650 --> 00:22:39.730 available to Windows and Mac so that it can be 00:22:39.730 --> 00:22:41.849 used across and update some of the modules, get 00:22:41.849 --> 00:22:43.529 rid of some of the old things that are no longer 00:22:43.529 --> 00:22:46.910 available to us, all that type of stuff. If anyone's 00:22:46.910 --> 00:22:49.089 listening to this and you have used it or haven't 00:22:49.089 --> 00:22:50.970 used it and you heard about it for the first 00:22:50.970 --> 00:22:53.220 time today, you know, have a look, reach out 00:22:53.220 --> 00:22:55.319 to me on socials or on GitHub if there's any 00:22:55.319 --> 00:22:57.839 sort of feedback or feature requests. You know, 00:22:57.839 --> 00:23:00.279 it's an old tool. It's been around for, you know, 00:23:00.359 --> 00:23:02.819 10 or 12 or something like that years now. And 00:23:02.819 --> 00:23:05.380 at one point in time, it was heavily used by 00:23:05.380 --> 00:23:07.839 folks. I suspect a lot of people have moved on 00:23:07.839 --> 00:23:11.200 to other things, but I want to do my bit and 00:23:11.200 --> 00:23:14.039 bring it up to, you know, 2026 standard here 00:23:14.039 --> 00:23:16.039 in the next few months. So yeah, feel free to 00:23:16.039 --> 00:23:19.500 reach out to me if you've got some ideas. And 00:23:19.500 --> 00:23:22.339 because I'm not sure if PowerShell Core does 00:23:22.339 --> 00:23:27.200 support any ways to do some UI window creation. 00:23:27.769 --> 00:23:29.950 in front, especially because it's running on 00:23:29.950 --> 00:23:32.549 multiple platforms. You can always consider doing 00:23:32.549 --> 00:23:36.410 some nice ASCII art menus, Chris. I'm a big fan 00:23:36.410 --> 00:23:39.269 of those. A TUI, right? We move away from the 00:23:39.269 --> 00:23:43.430 GUI to the TUI, the text user interface. TUI's 00:23:43.430 --> 00:23:46.109 are all the rage these days. I never heard about 00:23:46.109 --> 00:23:49.089 the term TUI, but I'll remember that. Yeah, it's 00:23:49.089 --> 00:23:53.289 the new GUI, I would say. Yeah, nice. Thanks 00:23:53.289 --> 00:23:56.430 Chris for that for that topic Looking forward 00:23:56.430 --> 00:23:58.970 to to your updates coming soon to the community. 00:23:59.269 --> 00:24:02.269 I like I like to visit to revisit actually pass 00:24:02.269 --> 00:24:06.309 keys So this is not new we talked about pass 00:24:06.309 --> 00:24:08.930 keys before actually in our very first episode 00:24:08.930 --> 00:24:14.009 and December of 2024 time flies But quite a few 00:24:14.009 --> 00:24:16.250 things have changed since then and I believe 00:24:16.250 --> 00:24:21.730 now well lately PassKeys became such mature that 00:24:21.730 --> 00:24:25.190 I think it's now finally time to start onboarding 00:24:25.190 --> 00:24:28.910 this at scale, especially the whole user experience 00:24:28.910 --> 00:24:31.809 has improved a lot lately. And there are some 00:24:31.809 --> 00:24:35.589 new features being announced in the public preview 00:24:35.589 --> 00:24:39.150 lately. I saw some community work on the topic, 00:24:39.289 --> 00:24:41.230 so that's why I thought it would be a good time 00:24:41.230 --> 00:24:45.849 to revisit PassKeys. Maybe just to start off 00:24:45.849 --> 00:24:50.160 with a short recap. A passkey is a passwordless 00:24:50.160 --> 00:24:54.259 sign -in method. It uses public key cryptography 00:24:54.259 --> 00:24:57.579 instead of typing a shared secret and the device 00:24:57.579 --> 00:25:00.359 creates a unique key pair for each website or 00:25:00.359 --> 00:25:02.819 service and it keeps the private key safe on 00:25:02.819 --> 00:25:05.759 the device and it proves the position with an 00:25:05.759 --> 00:25:07.900 unlock like biometrics with your fingerprint 00:25:07.900 --> 00:25:12.240 or a pin code. So it's complete multifactor but 00:25:12.240 --> 00:25:15.900 it is not vulnerable to any man -in -the -middle 00:25:15.900 --> 00:25:19.700 attacks. And I think pass keys matter because 00:25:19.700 --> 00:25:22.779 phishing has also gotten more effective by stealing 00:25:22.779 --> 00:25:25.619 passwords, but also by performing some real world 00:25:25.619 --> 00:25:28.759 man in the middle tricks. We talked about them 00:25:28.759 --> 00:25:33.079 before. Evilgenics is a popular example of how 00:25:33.079 --> 00:25:36.380 that can be demonstrated in practice. So the 00:25:36.380 --> 00:25:38.680 attacker is relaying the user's authentication 00:25:38.680 --> 00:25:42.029 through a fake login page. letting the user perform 00:25:42.029 --> 00:25:45.829 their actual login and MFA and then the authentication 00:25:45.829 --> 00:25:48.609 token can be replayed. But there's also a risk 00:25:48.609 --> 00:25:52.789 with traditional MFA called MFA fatigue, where 00:25:52.789 --> 00:25:56.990 you get multiple prompts on your MFA device and 00:25:56.990 --> 00:26:00.250 in the hope that people just accept it or approve 00:26:00.250 --> 00:26:03.130 the request. And that way the attacker has a 00:26:03.130 --> 00:26:05.210 successful MFA and they can register an additional 00:26:05.210 --> 00:26:08.430 MFA device, for example, to get some persistence 00:26:08.430 --> 00:26:12.480 on the account. So fishing resistant MFA methods 00:26:12.480 --> 00:26:16.839 like pass keys. break that chain by binding the 00:26:16.839 --> 00:26:20.799 sign in to a legitimate site and requiring cryptographic 00:26:20.799 --> 00:26:24.039 proof that can't be replayed through a fake login 00:26:24.039 --> 00:26:27.279 page. So that's the short gist of it. And again, 00:26:27.339 --> 00:26:29.220 quite a lot has changed since we first talked 00:26:29.220 --> 00:26:31.900 about this, especially the user experience was 00:26:31.900 --> 00:26:34.599 a bit lacking at the start. When Microsoft introduced 00:26:34.599 --> 00:26:37.759 pass keys, it was first limited to only physical 00:26:37.759 --> 00:26:41.180 pass keys like the Yubi keys, but also the old 00:26:41.180 --> 00:26:44.410 user experience was a bit wonky. you were required 00:26:44.410 --> 00:26:47.829 to register a traditional MFA through the Authenticator 00:26:47.829 --> 00:26:50.509 app as well. And then you can add an additional 00:26:50.509 --> 00:26:53.569 MFA device in the form of physical passkey. But 00:26:53.569 --> 00:26:57.730 if you really want to require a phishing resistant 00:26:57.730 --> 00:27:01.630 MFA across the board, you still had those MFA 00:27:01.630 --> 00:27:03.890 Authenticator apps registered and everything. 00:27:04.150 --> 00:27:06.930 And the whole user experience, when somebody 00:27:06.930 --> 00:27:09.650 logs in for the first time, it wasn't possible 00:27:09.650 --> 00:27:11.809 to register a passkey right away. And that's 00:27:11.809 --> 00:27:14.420 also recent change. I think that was definitely 00:27:14.420 --> 00:27:16.680 helps the onboarding. When I was at Ignite and 00:27:16.680 --> 00:27:19.200 I was working at the intro booth, um, that was 00:27:19.200 --> 00:27:21.160 a very large complaint from a lot of customers 00:27:21.160 --> 00:27:24.000 about adoption of pass keys because they were 00:27:24.000 --> 00:27:26.680 like, well, we've got to go through this wonky 00:27:26.680 --> 00:27:29.119 process to get folks registered and onboarded. 00:27:29.460 --> 00:27:31.740 Then we can only get them to a pass key. And 00:27:31.740 --> 00:27:33.259 a lot of people were really complaining about 00:27:33.259 --> 00:27:35.000 that. There was, I remember speaking to one, 00:27:35.180 --> 00:27:37.700 one gentleman, I think he was from Germany and 00:27:37.700 --> 00:27:40.180 he was like, You don't even know how many tens 00:27:40.180 --> 00:27:42.220 of hours I've spent trying to work around this 00:27:42.220 --> 00:27:43.819 and we just can't. I was like, yeah, I don't 00:27:43.819 --> 00:27:45.579 think you can at this point. So this is great 00:27:45.579 --> 00:27:48.500 news that this is something that can now be, 00:27:48.680 --> 00:27:50.670 you know, has been. updated or at least made 00:27:50.670 --> 00:27:52.230 a little bit more user -friendly. I'm not sure 00:27:52.230 --> 00:27:55.490 when this was introduced. Apparently after Ignite, 00:27:55.589 --> 00:28:00.450 I must admit I'm not into the deep weeds of passkey 00:28:00.450 --> 00:28:04.009 development. So I just noticed this because syncable 00:28:04.009 --> 00:28:06.670 passkeys is now a thing as well. So at first 00:28:06.670 --> 00:28:10.029 we only had device -bound passkey. So the physical 00:28:10.029 --> 00:28:13.990 passkeys, I use a YubiKey myself with a fingerprint 00:28:13.990 --> 00:28:18.990 sensor on there. Later Microsoft introduced passkey. 00:28:18.759 --> 00:28:22.099 through their Microsoft Authenticator app, which 00:28:22.099 --> 00:28:25.299 was still device bound. So you register the passkey 00:28:25.299 --> 00:28:27.740 on the Authenticator app. But when you were doing 00:28:27.740 --> 00:28:31.019 an authentication, a short Bluetooth connection 00:28:31.019 --> 00:28:33.220 was set up with the device to verify you were 00:28:33.220 --> 00:28:36.460 actually there at the same computer you're authenticating 00:28:36.460 --> 00:28:39.019 to. So that made a device bound. And device bound 00:28:39.019 --> 00:28:42.619 also means when you lose your iPhone or you lose 00:28:42.619 --> 00:28:46.119 your YubiKey, your key is gone. You cannot just 00:28:46.119 --> 00:28:48.740 restore an iCloud backup on a different iPhone 00:28:48.740 --> 00:28:51.380 and expect the pass keys to return there as well 00:28:51.380 --> 00:28:53.619 because it was bound to the original device, 00:28:53.900 --> 00:28:56.420 part of the cryptographic proof and the whole 00:28:56.420 --> 00:28:59.220 idea of the authentication mechanism. Now with 00:28:59.220 --> 00:29:01.720 syncable pass keys, you have the ability to store 00:29:01.720 --> 00:29:05.039 the pass key in, for example, like an iCloud 00:29:05.039 --> 00:29:08.150 keychain or one password or... Keeper or any 00:29:08.150 --> 00:29:11.869 other password vault. We've seen this a lot last 00:29:11.869 --> 00:29:14.170 couple of months with other services like GitHub, 00:29:14.430 --> 00:29:18.009 Amazon, a lot of websites now ask you to register 00:29:18.009 --> 00:29:21.789 a passkey for you and that is obviously better 00:29:21.789 --> 00:29:26.609 than just a password because it is MFA built 00:29:26.609 --> 00:29:28.990 in actually into the authentication process. 00:29:29.980 --> 00:29:32.740 But there is also a downside to that because 00:29:32.740 --> 00:29:35.660 your passkey, your cryptographic proof is stored 00:29:35.660 --> 00:29:39.019 in a password vault. It might be synced through 00:29:39.019 --> 00:29:41.960 an online service. If your computer might be 00:29:41.960 --> 00:29:44.980 compromised or maybe your browser plugin is compromised 00:29:44.980 --> 00:29:47.680 or there are other scenarios thinkable where 00:29:47.680 --> 00:29:50.940 your passkey might belong, might land in the 00:29:50.940 --> 00:29:54.700 wrong hands. So that is a security consideration 00:29:54.700 --> 00:29:59.680 I will get to later as well. Together with syncable 00:29:59.680 --> 00:30:03.720 passkeys and a better onboarding flow and user 00:30:03.720 --> 00:30:06.579 experience, we now also have passkey profiles, 00:30:07.019 --> 00:30:10.799 which also enables us to limit and set specific 00:30:10.799 --> 00:30:14.059 passkey profiles to specific groups of users, 00:30:14.059 --> 00:30:16.539 for example. And this is really valuable where 00:30:16.539 --> 00:30:18.480 you, for example, say, okay, we have a certain 00:30:18.480 --> 00:30:22.420 account. We want that to have syncable passkeys. 00:30:22.500 --> 00:30:25.000 Those don't have any, I don't know, high level 00:30:25.000 --> 00:30:30.829 privileges where we accept a somewhat less secure. 00:30:31.130 --> 00:30:33.809 Well, it's not less secure, but there might be 00:30:33.809 --> 00:30:36.809 some additional attack vectors on a syncable 00:30:36.809 --> 00:30:39.910 passkey. But we accept that for regular users, 00:30:39.930 --> 00:30:42.710 for example, because it's much easier the fact 00:30:42.710 --> 00:30:45.049 that they can sync their passkey and they won't 00:30:45.049 --> 00:30:47.069 call the service desk any longer when they lose 00:30:47.069 --> 00:30:49.049 their physical key, for example, or their phone. 00:30:49.490 --> 00:30:52.130 And we accept that risk, that additional risk, 00:30:52.210 --> 00:30:54.650 so to speak, and we create a separate passkey 00:30:54.650 --> 00:30:57.230 profile for those groups of users. and we allow 00:30:57.230 --> 00:30:59.329 syncable pass keys for those and not for any 00:30:59.329 --> 00:31:01.470 other high privilege roles. That makes a lot 00:31:01.470 --> 00:31:04.910 of sense. So if you wanted to promote YubiKey 00:31:04.910 --> 00:31:08.910 use still for your admin users, you could still 00:31:08.910 --> 00:31:11.210 make sure that admin users and anyone who has 00:31:11.210 --> 00:31:14.130 a PIM role or something like that, an admin account 00:31:14.130 --> 00:31:17.410 specific still has to use a YubiKey or some physical 00:31:17.410 --> 00:31:21.890 thing. but your frontline workers and information 00:31:21.890 --> 00:31:23.730 workers and everyone else in the business, they're 00:31:23.730 --> 00:31:25.849 okay to be able to store that thing in their 00:31:25.849 --> 00:31:28.289 vault. That's pretty cool. Yeah. And by the way, 00:31:28.329 --> 00:31:30.650 now you touch on that topic, there is also something 00:31:30.650 --> 00:31:34.490 we call step up authentication. And this was 00:31:34.490 --> 00:31:36.430 already possible with your conditional access 00:31:36.430 --> 00:31:38.569 policies. And I think it's already a good idea 00:31:38.569 --> 00:31:42.170 to consider role -based conditional access policies 00:31:42.170 --> 00:31:45.970 where you say whenever somebody is a global administrator 00:31:45.970 --> 00:31:49.990 we require a phishing resistant MFA string for 00:31:49.990 --> 00:31:52.789 example. So when you log in with your regular 00:31:52.789 --> 00:31:55.740 MFA through the Authenticator app you request 00:31:55.740 --> 00:31:58.119 a role of the global administrator. Somebody 00:31:58.119 --> 00:32:00.940 approves the role, hopefully. I hope it has an 00:32:00.940 --> 00:32:03.839 approval step. And then once you get to the global 00:32:03.839 --> 00:32:06.759 administrator role, you get a prompt again to 00:32:06.759 --> 00:32:10.220 do an additional MFA. And then your authenticator 00:32:10.220 --> 00:32:12.259 approval will not cut it any longer. And you 00:32:12.259 --> 00:32:15.559 have to take out the UB key or the physical pass 00:32:15.559 --> 00:32:17.079 key or the pass key on your authenticator. It's 00:32:17.079 --> 00:32:18.700 an interesting scenario you talk about there 00:32:18.700 --> 00:32:23.960 because one of the problems with PIM role authentication 00:32:23.960 --> 00:32:26.380 or activation is that a lot of organizations 00:32:26.380 --> 00:32:29.140 want to go, you know, you have your PIM role, 00:32:29.640 --> 00:32:32.359 but I want to force MFA again when the user activates 00:32:32.359 --> 00:32:34.740 the role. So you've logged in, you've MFA'd, 00:32:34.920 --> 00:32:37.180 you go and activate a role. They want to force 00:32:37.180 --> 00:32:40.220 that second MFA again. If you're not stepping 00:32:40.220 --> 00:32:43.440 up, that's really difficult to do because the 00:32:43.440 --> 00:32:46.079 original MFA that you've just done satisfies 00:32:46.079 --> 00:32:48.880 the MFA requirement. And so unless you've been 00:32:48.880 --> 00:32:50.779 logged in for a very long time or what have you, 00:32:50.839 --> 00:32:53.140 you're not always going to see that sort of second 00:32:53.140 --> 00:32:56.480 MFA request, right? Unless you actually are stepping 00:32:56.480 --> 00:32:58.980 it up to a higher level or a more secure level 00:32:58.980 --> 00:33:01.900 of MFA. So that's definitely one way to do that. 00:33:02.299 --> 00:33:04.160 Yeah. And you can also think of the scenario 00:33:04.160 --> 00:33:08.059 where a token replay was already used to gain 00:33:08.059 --> 00:33:10.420 access to your account and somebody just requests 00:33:10.420 --> 00:33:12.940 a PIM role and now they're global administrator 00:33:12.940 --> 00:33:16.339 with that same cash to token. You're right. Yeah. 00:33:17.050 --> 00:33:19.930 So step up authentication is also important. 00:33:20.849 --> 00:33:23.190 So I think for those reasons alone, you should 00:33:23.190 --> 00:33:25.569 really look into pass keys and make sure your 00:33:25.569 --> 00:33:28.849 high privilege roles and users are protected 00:33:28.849 --> 00:33:33.079 better than just with regular MFA nowadays. When 00:33:33.079 --> 00:33:35.880 I started using this, I got a little bit confused 00:33:35.880 --> 00:33:39.819 about the term attestation. That is something 00:33:39.819 --> 00:33:44.119 you can or should enable on those passkey profiles, 00:33:44.140 --> 00:33:48.160 which got introduced as well. And attestation, 00:33:48.460 --> 00:33:51.059 I had to look it up. It's part of the Web Auth 00:33:51.059 --> 00:33:54.859 N protocol, the web standard regarding passkeys. 00:33:55.420 --> 00:33:59.240 It's about proving what authenticator created 00:33:59.240 --> 00:34:02.259 the credential. again using cryptographic evidence 00:34:02.259 --> 00:34:05.220 during the registration. So the relying party, 00:34:05.460 --> 00:34:07.900 which is Microsoft Entry ID in this case, can 00:34:07.900 --> 00:34:10.679 validate the evidence against trusted metadata 00:34:10.679 --> 00:34:15.579 to decide whether to accept that specific authenticator 00:34:15.579 --> 00:34:18.679 model. And I read somewhere online people saying, 00:34:18.719 --> 00:34:21.659 without attestation, your pass keys are just 00:34:21.659 --> 00:34:25.500 regular key pairs. You still get a strong key 00:34:25.500 --> 00:34:28.300 based login, but the service cannot reliably 00:34:28.300 --> 00:34:31.400 prove which authenticator model or provider generated 00:34:31.400 --> 00:34:34.239 the keys or whether claimed identifiers were 00:34:34.239 --> 00:34:37.760 actually genuine. So attestation is really important 00:34:37.760 --> 00:34:41.159 to enable. So if you're using device bound pass 00:34:41.159 --> 00:34:44.099 keys with FIDO keys, for example, or UB keys 00:34:44.099 --> 00:34:47.440 or any other, or through the authenticator app, 00:34:47.500 --> 00:34:50.440 make sure that attestation is enabled. When Microsoft 00:34:50.440 --> 00:34:54.190 started off with... pass keys through the Authenticator 00:34:54.190 --> 00:34:57.030 app, you had to disable attestation because back 00:34:57.030 --> 00:35:00.369 then, apparently, the whole registration and 00:35:00.369 --> 00:35:03.949 the metadata was not in centralized databases 00:35:03.949 --> 00:35:06.090 or whatnot. I'm not sure how that works in the 00:35:06.090 --> 00:35:09.469 back end. That's also a reason why I think it 00:35:09.469 --> 00:35:13.190 was not streamlined a year or more ago. Now you 00:35:13.190 --> 00:35:15.469 should enable attestation on your device bound 00:35:15.469 --> 00:35:18.530 pass keys. And if preferably, you can also add 00:35:18.530 --> 00:35:23.829 an AA GUID, which is, let me see, I put the acronym 00:35:23.829 --> 00:35:28.989 in the show notes, I believe. Let me see where 00:35:28.989 --> 00:35:31.929 did I put it there. I cannot find it anymore. 00:35:32.070 --> 00:35:35.670 I'm not sure what the AA stands for. Attestation 00:35:35.670 --> 00:35:40.659 something. Well. I'll look it up. I'll make sure 00:35:40.659 --> 00:35:43.639 it's in the show notes. But the AA GUID is actually 00:35:43.639 --> 00:35:47.059 a GUID of a PaaSky provider. You can add as an 00:35:47.059 --> 00:35:50.739 additional level to put in an allow or a block 00:35:50.739 --> 00:35:53.719 list, where you say, for example, we only register 00:35:53.719 --> 00:35:58.380 UI keys, for example, or face and physical keys. 00:35:58.559 --> 00:36:01.800 And we only put those AA GUIDs in the allow list 00:36:01.800 --> 00:36:04.840 to make sure that we enforce the usage of only 00:36:04.840 --> 00:36:07.719 those two providers in addition to attestation. 00:36:08.320 --> 00:36:10.840 Right. So that also then prevents the use of, 00:36:11.199 --> 00:36:13.079 even though you might, let's say you, you, you 00:36:13.079 --> 00:36:15.380 only allow Yubi keys, but you don't allow any 00:36:15.380 --> 00:36:18.539 of the other branded ones, right? That then you 00:36:18.539 --> 00:36:20.960 can't have someone turn up with some other key 00:36:20.960 --> 00:36:23.539 that they found on Amazon and use it. If your 00:36:23.539 --> 00:36:26.639 policy says only Yubi keys. I've seen some scripts 00:36:26.639 --> 00:36:30.440 in the community that either extract or provide 00:36:30.440 --> 00:36:33.280 or both a list of what these, cause, cause obviously 00:36:33.280 --> 00:36:35.260 the manufacturers have a fixed, you know, AA 00:36:35.260 --> 00:36:38.590 GUID, right? Or what have you. So yeah, there's 00:36:38.590 --> 00:36:41.010 a lot of information out there about why this 00:36:41.010 --> 00:36:43.679 is a good idea as well, which is cool. Yeah, 00:36:43.679 --> 00:36:46.900 I did it at our own company a while ago when 00:36:46.900 --> 00:36:49.179 we started with passkey registration. We had 00:36:49.179 --> 00:36:51.500 a couple of different models because we had some 00:36:51.500 --> 00:36:53.800 biometric ones and some pin ones. So we used 00:36:53.800 --> 00:36:57.019 Vathion and Ubiqui and I believe even a third 00:36:57.019 --> 00:37:00.699 provider. I just registered it without having 00:37:00.699 --> 00:37:03.639 the allow list of AA GUIDs. And then I used a 00:37:03.639 --> 00:37:05.860 PowerShell module again to retrieve from entry 00:37:05.860 --> 00:37:10.059 ID from the graph all the passkey GUIDs from 00:37:10.059 --> 00:37:12.559 all the users. And then I had my unique list. 00:37:12.519 --> 00:37:15.260 of three GUIDs which are put in the allow list. 00:37:15.579 --> 00:37:18.860 And I know as of then, we wouldn't allow any 00:37:18.860 --> 00:37:23.780 other vendors. Yeah, very cool. Yeah. But the 00:37:23.780 --> 00:37:25.880 thing is with the syncable pass keys, you cannot 00:37:25.880 --> 00:37:30.460 enable attestation. So you have to disable that 00:37:30.460 --> 00:37:32.500 on the additional pass key profile. And that's 00:37:32.500 --> 00:37:35.320 why it's also maybe a little bit more risky in 00:37:35.320 --> 00:37:39.360 that regard. So that's why you should really 00:37:39.360 --> 00:37:42.869 consider scoping that syncable passkey profile 00:37:42.869 --> 00:37:49.090 to a specific set of group with users. Another 00:37:49.090 --> 00:37:52.590 consideration you should be aware of is guest 00:37:52.590 --> 00:37:57.510 accounts. So Microsoft will not let your guest 00:37:57.510 --> 00:38:00.489 users register for a passkey. I'm not sure why 00:38:00.489 --> 00:38:04.030 that is. It is in the docs and it is known as 00:38:04.030 --> 00:38:07.989 a limitation as of now. So getting your guests 00:38:07.989 --> 00:38:11.710 onto passkeys is a little bit less straightforward. 00:38:12.789 --> 00:38:16.289 But there's a workaround to this. We at the company 00:38:16.289 --> 00:38:19.869 I work for use a lot of passkeys. also in our 00:38:19.869 --> 00:38:22.429 managed services towards our customers. And we 00:38:22.429 --> 00:38:25.130 want to make sure that everybody logs in with 00:38:25.130 --> 00:38:27.829 a passkey, even if they switch. to the other 00:38:27.829 --> 00:38:30.750 tenants of the customers we are providing services 00:38:30.750 --> 00:38:33.449 to. And a workaround you can use is by going 00:38:33.449 --> 00:38:36.690 into the cross -tenant access settings. First 00:38:36.690 --> 00:38:39.429 of all, I would always advise you to set up a 00:38:39.429 --> 00:38:42.849 conditional access policy to require the highest 00:38:42.849 --> 00:38:45.130 authentication strength, so to make sure it's 00:38:45.130 --> 00:38:48.050 phishing -resistant MFA for your services. And 00:38:48.050 --> 00:38:50.429 then in the cross -tenant access setting, you 00:38:50.429 --> 00:38:53.610 can set up your partner, your partner tenant, 00:38:53.929 --> 00:38:56.969 where the guest accounts come from. and then 00:38:56.969 --> 00:39:00.050 you can trust the inbound MFA claim for those 00:39:00.050 --> 00:39:03.030 partners. Because you know it already aligns 00:39:03.030 --> 00:39:05.090 with your highest authentication strength, thanks 00:39:05.090 --> 00:39:08.090 to the conditional access policy, you are sure 00:39:08.090 --> 00:39:11.710 that they can only come in with the highest MFA 00:39:11.710 --> 00:39:14.510 and you can trust the claim. So you don't expect 00:39:14.510 --> 00:39:17.670 them, you don't require them to do an additional 00:39:17.670 --> 00:39:21.610 MFA prompt when they reach your tenant. And this 00:39:21.610 --> 00:39:24.489 has multiple benefits because as I said, we have 00:39:24.489 --> 00:39:28.690 a managed SOC sort of speak with a lot of security 00:39:28.690 --> 00:39:31.530 analysts connecting to over a hundred different 00:39:31.530 --> 00:39:34.449 customer tenants. And before they had an MFA 00:39:34.449 --> 00:39:37.389 registration with all of these individual hundred 00:39:37.389 --> 00:39:40.869 customers. When somebody lost their phone, they 00:39:40.869 --> 00:39:43.429 had to re -register MFA for all the different 00:39:43.429 --> 00:39:45.269 tenants and they probably had to call the customer. 00:39:45.769 --> 00:39:50.170 I have a list of this. MFA registrations from 00:39:50.170 --> 00:39:52.789 different customers. Now, I also, I do separate 00:39:52.789 --> 00:39:56.269 my, just FYI, I mean, I guess I separate my MFA 00:39:56.269 --> 00:39:58.630 stuff. You know, I use Microsoft Authenticator 00:39:58.630 --> 00:40:01.630 specifically and purely for work related stuff. 00:40:01.769 --> 00:40:03.489 You know, for my own personal use, I have different 00:40:03.489 --> 00:40:05.550 things that I use for that. But so at least I 00:40:05.550 --> 00:40:07.570 don't have jumbled in there, you know, personal 00:40:07.570 --> 00:40:09.769 accounts and work accounts, but I have a very 00:40:09.769 --> 00:40:11.570 long list of customer because obviously every 00:40:11.570 --> 00:40:13.250 customer that I work with, I have an account, 00:40:13.449 --> 00:40:16.139 every account has MFA. You know, yeah, I could 00:40:16.139 --> 00:40:18.179 see how this becomes very long list. But those 00:40:18.179 --> 00:40:20.940 MFAs are bound to your device. If you lose your 00:40:20.940 --> 00:40:23.059 phone and you buy a new phone, even if you restore 00:40:23.059 --> 00:40:25.519 a backup from it, the MFA registration should 00:40:25.519 --> 00:40:28.460 be done again. And then you have to call up all 00:40:28.460 --> 00:40:30.860 your customers again to make sure they reset 00:40:30.860 --> 00:40:33.949 the MFA registration. This was a big thing for 00:40:33.949 --> 00:40:37.570 us in the past. So now we make sure that every 00:40:37.570 --> 00:40:40.650 single customer of ours requires the phishing 00:40:40.650 --> 00:40:43.550 resistant MFA authentication strength when we 00:40:43.550 --> 00:40:46.349 come into their portal. And in return, we ask 00:40:46.349 --> 00:40:51.630 them to trust our MFA claim as a two -way validation 00:40:51.630 --> 00:40:54.309 in that regard. And which makes it great because 00:40:54.309 --> 00:40:56.829 the physical passkey the security analyst holds 00:40:56.829 --> 00:41:00.170 is literally the key to access all the different 00:41:00.170 --> 00:41:04.429 tenants. revoke that passkey or if we revoke 00:41:04.429 --> 00:41:06.250 their guest account, they don't have any access 00:41:06.250 --> 00:41:08.710 anymore as well to all of the different types. 00:41:09.130 --> 00:41:12.960 That's a really good way to work that. I put 00:41:12.960 --> 00:41:14.880 a screenshot in the show notes where you can 00:41:14.880 --> 00:41:17.579 find this actual setting. Obviously, it's a little 00:41:17.579 --> 00:41:19.679 bit different if you work with a lot of different 00:41:19.679 --> 00:41:21.960 partner tenants with a lot of different guest 00:41:21.960 --> 00:41:24.360 accounts, then you might want to exempt them 00:41:24.360 --> 00:41:27.340 from the PassKey requirements. But otherwise, 00:41:27.800 --> 00:41:31.400 you should definitely look into making sure PassKey 00:41:31.400 --> 00:41:36.530 is your new default along the road for MFA. Did 00:41:36.530 --> 00:41:38.869 I see Microsoft are actually going to be doing 00:41:38.869 --> 00:41:41.550 that as well for you? Did they not announce last 00:41:41.550 --> 00:41:44.550 week or the week before that pass keys are going 00:41:44.550 --> 00:41:48.030 to become the default MFA for moving forward? 00:41:48.309 --> 00:41:50.289 There's a date. I'll have to look it up, I guess. 00:41:50.289 --> 00:41:53.349 Okay, great. Well, I missed that news. No, I 00:41:53.349 --> 00:41:55.130 think Microsoft are going to be forcing folks 00:41:55.130 --> 00:42:00.269 as well to do it, which we can debate. Whether 00:42:00.269 --> 00:42:03.289 that's a good or bad thing, I guess you can see 00:42:03.289 --> 00:42:05.909 both sides of it. But I do think that they want 00:42:05.909 --> 00:42:08.630 folks to adopt it. It makes sense to adopt it 00:42:08.630 --> 00:42:11.590 because it is a more secure way to do it. But 00:42:11.590 --> 00:42:13.829 a lot of businesses are not. A lot of companies 00:42:13.829 --> 00:42:15.769 are still struggling with MFA adoption, right? 00:42:15.969 --> 00:42:18.130 So go and now throw pass keys at them. It's just 00:42:18.130 --> 00:42:21.030 going to be slightly messy. Yeah. And even with 00:42:21.030 --> 00:42:24.190 the syncable pass keys, it's arguably still safer 00:42:24.190 --> 00:42:28.429 than allowing replayable MFA requests, right? 00:42:29.300 --> 00:42:32.599 And with the AA GUIDs I mentioned before, you 00:42:32.599 --> 00:42:36.280 can also require your users that they can only 00:42:36.280 --> 00:42:39.699 store that syncable passkey in a vault you approve 00:42:39.699 --> 00:42:42.559 of. So for example, when you use LastPass Enterprise 00:42:42.559 --> 00:42:45.800 or Keeper for Business or whatever, you can put 00:42:45.800 --> 00:42:49.679 those AA GUIDs in the passkey profile so that 00:42:49.679 --> 00:42:52.380 the user cannot store it in their personal iCloud 00:42:52.380 --> 00:42:54.579 keychain, for example, and can only store it 00:42:54.579 --> 00:42:57.800 in the business password vault, for example. 00:42:58.039 --> 00:43:02.280 Yeah, that makes sense. I put a lot of links 00:43:02.280 --> 00:43:04.780 in the show notes, not only the documentation 00:43:04.780 --> 00:43:07.800 about syncable pass keys, the new pass key profiles, 00:43:07.900 --> 00:43:11.019 which both are in a public preview right now, 00:43:11.219 --> 00:43:15.900 but also some links to Jan Bakker's blogs. You 00:43:15.900 --> 00:43:18.219 probably know him, Chris. He's from the Netherlands, 00:43:18.260 --> 00:43:23.480 of course. They call him Mr. Paski as well in 00:43:23.480 --> 00:43:25.920 the community. He writes a lot about the topic. 00:43:26.280 --> 00:43:28.440 He has some good blogs about it with some great 00:43:28.440 --> 00:43:32.840 examples and make sure to check that out as well. 00:43:33.480 --> 00:43:35.599 Yeah, absolutely. I was going to say, I just 00:43:35.599 --> 00:43:40.340 found AAGooid is Authenticator Attestation Globally 00:43:40.340 --> 00:43:43.340 Unique Identifier. I just found it in the notes. 00:43:44.139 --> 00:43:46.769 Oh, it is in the notes. Well, yes. I knew it 00:43:46.769 --> 00:43:50.630 was somewhere. Well, the AA GUID for short. Okay, 00:43:50.630 --> 00:43:55.190 thanks. So yeah, with Jan Bakker and also your 00:43:55.190 --> 00:43:58.789 PowerShell topic brings us to the community project 00:43:58.789 --> 00:44:02.769 of this month. And I actually cobbled together 00:44:02.769 --> 00:44:05.170 multiple community products because this month 00:44:05.170 --> 00:44:07.929 I saw something really cool happen in the community. 00:44:08.170 --> 00:44:12.789 It all started with Fabian Barach, a German security 00:44:12.789 --> 00:44:15.789 MVP. We have mentioned before, he's also one 00:44:15.789 --> 00:44:19.010 of the contributors of Meister. And I think we 00:44:19.010 --> 00:44:21.630 should touch on Meister again in the future as 00:44:21.630 --> 00:44:24.269 well, because I saw a version 2 .0 coming by. 00:44:24.650 --> 00:44:26.829 But well, let's save that for a later episode. 00:44:27.489 --> 00:44:29.769 But Fabian wrote a blog about a tool he created 00:44:29.769 --> 00:44:33.550 called Invoke Entry ID Passkey Login. And it 00:44:33.550 --> 00:44:35.590 lets you authenticate against the Microsoft Draft 00:44:35.590 --> 00:44:40.420 with MFA as a user. but from a script using pass 00:44:40.420 --> 00:44:43.559 keys, which is pretty clever stuff because some 00:44:43.559 --> 00:44:47.280 of the APIs will not allow you to authenticate 00:44:47.280 --> 00:44:51.260 as a machine and only as a dedicated user. So 00:44:51.260 --> 00:44:53.860 that's why he had to work around some stuff to 00:44:53.860 --> 00:44:57.119 do something in a GitHub action he created. But 00:44:57.119 --> 00:45:00.480 then Nathan McNulty, he's an MVP from the US, 00:45:01.039 --> 00:45:03.559 picked it up and built a standalone version of 00:45:03.559 --> 00:45:07.400 that called passkeylogin .ps1. His version uses 00:45:07.400 --> 00:45:09.860 a passkey exported from an Azure Key Vault, which 00:45:09.860 --> 00:45:14.179 is already a nice addition. And then Jos Lieben, 00:45:14.280 --> 00:45:17.559 he's from the Netherlands again. He said, hold 00:45:17.559 --> 00:45:21.019 my beer. And he took it even further. So he created 00:45:21.019 --> 00:45:24.320 new FidoKey .ps1, which is a script which can 00:45:24.320 --> 00:45:26.659 actually generate the passkeys for an account. 00:45:27.500 --> 00:45:29.800 So that's three community members building on 00:45:29.800 --> 00:45:31.579 top of each other in a short amount of time. 00:45:31.599 --> 00:45:35.150 And I thought that was really cool to see. Using 00:45:35.150 --> 00:45:37.469 these methods obviously raises some security 00:45:37.469 --> 00:45:41.030 concerns because you're authenticating with a 00:45:41.030 --> 00:45:45.050 very secure passkey in an automated way with 00:45:45.050 --> 00:45:48.550 scripts storing the passkey locally temporarily 00:45:48.550 --> 00:45:52.150 or storing it in a key vault. It has its downsides, 00:45:52.150 --> 00:45:58.659 of course. But you can use the new passkey profile 00:45:58.659 --> 00:46:01.480 to have maybe a separate automation specific 00:46:01.480 --> 00:46:04.820 account in there to allow it only for certain 00:46:04.820 --> 00:46:08.820 actions. And while still enforcing the stricter 00:46:08.820 --> 00:46:11.219 requirements for your normal interactive logins, 00:46:11.239 --> 00:46:14.000 for example. Again, from a security perspective, 00:46:14.269 --> 00:46:16.590 You have to be very careful here. You need proper 00:46:16.590 --> 00:46:19.889 scoping, secure storage, as I said, of the PASCII 00:46:19.889 --> 00:46:22.250 material, and very clear understanding, I think, 00:46:22.289 --> 00:46:24.409 of what you're actually doing. But I think when 00:46:24.409 --> 00:46:27.070 done responsibly, this can be extremely powerful. 00:46:27.769 --> 00:46:29.889 Think about automated environment provisioning, 00:46:29.889 --> 00:46:32.849 for example, one -time onboarding of tasks and 00:46:32.849 --> 00:46:34.969 other interactions with APIs that would otherwise 00:46:34.969 --> 00:46:38.449 require some manual MFA prompts. And beyond the 00:46:38.449 --> 00:46:40.590 technical details, I think again, the most impressive 00:46:40.590 --> 00:46:43.050 part is how the community came together. Yeah, 00:46:43.050 --> 00:46:45.349 people's people spending their spare time creating 00:46:45.349 --> 00:46:47.670 tools and just simply giving it away to the rest 00:46:47.670 --> 00:46:49.789 of us. Yeah, there's so much cool stuff out there. 00:46:49.829 --> 00:46:52.829 That's you know, and I think it's good to good 00:46:52.829 --> 00:46:55.309 to see people still putting the putting the effort 00:46:55.309 --> 00:46:57.909 in, right? Because I you know, it can be a thankless 00:46:57.909 --> 00:47:00.110 job as well. And it's nice that people are still 00:47:00.110 --> 00:47:02.329 sort of doing it. And you know, especially these 00:47:02.329 --> 00:47:04.590 folks, I, I got to say, I've definitely come 00:47:04.590 --> 00:47:07.960 is it Yoss? Is that how you say his name? I've 00:47:07.960 --> 00:47:10.840 definitely come across his stuff before. He's 00:47:10.840 --> 00:47:13.880 been doing this for a long time. If you look 00:47:13.880 --> 00:47:16.079 at his blog, he's got some like articles there 00:47:16.079 --> 00:47:18.880 from like 2014 and whatnot. So he's been contributing 00:47:18.880 --> 00:47:20.639 and pushing things into the community for a long, 00:47:20.860 --> 00:47:24.400 long time. So it's great when we come across 00:47:24.400 --> 00:47:25.940 these things where we can kind of give these 00:47:25.940 --> 00:47:27.960 guys a little bit of a shout out as well. So 00:47:27.960 --> 00:47:30.199 very, very cool. I think it deserves the recognition 00:47:30.199 --> 00:47:33.659 and definitely a shout out. helped them get, 00:47:34.179 --> 00:47:36.659 I don't know, help other people with the stuff 00:47:36.659 --> 00:47:39.300 they built and they made. Yeah. No, very cool. 00:47:39.440 --> 00:47:42.480 That's very, very cool, Koos. Thank you for that. 00:47:42.820 --> 00:47:44.980 Thoughtful and for stitching those together for 00:47:44.980 --> 00:47:47.019 me. I'd seen one or two of them pop up on LinkedIn, 00:47:47.099 --> 00:47:49.300 but I hadn't sort of stitched all of them together. 00:47:49.900 --> 00:47:52.500 I also did see today, this week or last week, 00:47:53.099 --> 00:47:55.780 the Maester V2 come out. I was playing with it 00:47:55.780 --> 00:47:58.920 yesterday, actually. I haven't seen, I mean, 00:47:58.969 --> 00:48:01.130 There's some changes on the interface and it 00:48:01.130 --> 00:48:03.690 looks like they have some settings, a settings 00:48:03.690 --> 00:48:05.829 bar now where you can actually make some, do 00:48:05.829 --> 00:48:08.090 some settings back into the tenant, which is 00:48:08.090 --> 00:48:10.230 interesting. I haven't messed with it too much. 00:48:10.449 --> 00:48:12.309 I literally just yesterday, I was updating some 00:48:12.309 --> 00:48:16.530 of my automations that use Maester. So played 00:48:16.530 --> 00:48:19.190 with it. Let's keep it as a cliffhanger for now. 00:48:19.489 --> 00:48:23.170 Yeah, absolutely. Absolutely. I can't believe 00:48:23.170 --> 00:48:25.710 we're at the end of, pretty much coming up on 00:48:25.710 --> 00:48:27.289 the end of February, right? So we'll be seeing 00:48:27.289 --> 00:48:30.030 each other here in a few weeks time again. That's 00:48:30.030 --> 00:48:33.269 going to be fun. It's already March. I know. 00:48:34.730 --> 00:48:37.650 MVP Summit is coming up for people who might 00:48:37.650 --> 00:48:40.570 not be aware. And we'll be doing obviously a 00:48:40.570 --> 00:48:43.340 live recording again in Redmet. Yeah, that'd 00:48:43.340 --> 00:48:46.320 be very, very cool. And it might be either on 00:48:46.320 --> 00:48:48.980 Microsoft campus or in a kitchen at an Airbnb. 00:48:49.099 --> 00:48:51.880 We'll see about that when it happens. Or in a 00:48:51.880 --> 00:48:54.519 cigar bar somewhere that we find. A cigar bar? 00:48:54.780 --> 00:48:58.500 I'll hold you to it. Yes. Thank you, folks, very 00:48:58.500 --> 00:49:01.159 much for joining us for another episode. We really 00:49:01.159 --> 00:49:03.719 appreciate you spending time with us. And as 00:49:03.719 --> 00:49:05.860 always, reach out to us if there's anything that 00:49:05.860 --> 00:49:07.579 is troubling you or anything that you'd like 00:49:07.579 --> 00:49:11.920 to see us cover or get our commentary on on the 00:49:11.920 --> 00:49:15.139 show. Like, subscribe, all those cool things. 00:49:16.139 --> 00:49:17.420 I look forward to seeing you next month, man. 00:49:17.619 --> 00:49:20.599 I've already started shopping for Tim Tams for 00:49:20.599 --> 00:49:24.780 all of the suitcase of Tim Tams I'll be taking 00:49:24.780 --> 00:49:27.500 over for the Dutchies. Please make sure you bring 00:49:27.500 --> 00:49:31.059 those double chocolate ones, Chris. 100%, I will 00:49:31.059 --> 00:49:34.119 do. And I'll make sure the stroopwafels come 00:49:34.119 --> 00:49:37.940 your way as well. Excellent. Thanks, folks. And 00:49:37.940 --> 00:49:39.760 until next time, we will see you next time. Thank 00:49:39.760 --> 00:49:41.739 you very much. Bye bye, thanks for listening.