And welcome to the Everyday Defender podcast.
I'm your host Chris Goosen. And as always, I'm
joined by my friend from the Netherlands. How
are you doing, Kos? Hey, Chris, how are you doing?
I'm fine. It's finally getting a little bit.
We get a little bit more hours of light these
days. So I'm already looking forward to some
better weather as well. So going towards summer.
That's awesome for you guys. I live in Australia.
We have great weather most of the time, so it's
pretty good. Even in winter times, right? Yeah.
I think tomorrow we're expecting like 38 degrees
Celsius tomorrow, so it'll be very hot tomorrow
again. um but hey i really can't complain it's
uh you know it's it's pretty good uh we have
no bushfires we have no floods going on at the
moment so hey yeah like i said it's it's very
very good um it's funny to hear what kind of
different problems you have over there as well
well we had some snow recently and the whole
country is derailed literally when we got some
snow in Hey, I was watching the Winter Olympics
last night and the the Dutch are very very good
at the the skiing You know skating stuff, right?
So yes, that's why you guys are skating around
most of the time. So Anyway in today's episode
I am excited about your topic because I really
am excited to hear about pass keys and Kind of
look the current state of pass keys, right? So
excited to kind of dig into that Uh, I have been
thinking a lot about, uh, sec ops and automation
and PowerShell and that type of geeky stuff.
And I kind of thought it'd be good to talk a
little bit about the state of where we are with
PowerShell modules and automation and stuff like
that. Um, and so, um, I'm also touching a little
bit on your nostalgia heartstrings, I guess,
Chris. That's right. That's right. I, I, you
know, I, it's funny how uh long it's been you
know this this this whole thing and uh you know
i guess we'll kick into it straight away um and
and kind of tell the story right so so i've i've
called this module um module wars and if you
picture sort of that star wars theme and maybe
that star wars theme song playing right so um
the history lesson for this is you know a long
time ago in a galaxy far far away um it wasn't
that far away it was it's 2012ish or so It was
far away. Well, you know, that is true. That
is true. I put together a script back then that
when I was just sort of I was doing a lot of
exchange online work, right. And I put together
a script to simplify connecting to exchange online.
And it started off just as a script, you know,
just a basic piece of piece one script. And I
ended up adding a GUI to it because I just want
to see if I could do it. And then Uh, that it
was great. And I used to use this thing. And
after a while, I realized that I shared this
with so many people. Um, and it was all over
the place. Right. And that, that I was like,
you know, I'm going to, I'm going to publish
this thing. And I don't know. I mean, you've
been around long enough. You probably remember
the, the tech net gallery, right? Where we used
to publish our scripts before get help was a
thing. So, so I had it published on, um, on tech
net gallery for a really long time and over time.
And it was called connect EXO back then. Cause
it. really just disconnected you to Exchange
Online. And this was before, you know, widely
deployed MFA even, right? So really all it did
was it would launch a little box that said username,
password, you click okay. And it would launch
into the Exchange PowerShell modules. Obviously
over time, more and more modules became available.
MFA became a thing. There was a whole bunch of
things. And so I, you know, started sort of developing
this tool that became known as Connect 365. And
I, couldn't find exactly when Connect 365 was
was born, but I think it was sort of probably
around 2014 or so. Connect 365 was probably at
least 10 years ago. And it just became a tool
to very easily connect to all the services in
M365. So you could load all the modules and actually
later on I built like a prerequisite checker
so I could even check if the modules were installed
for you. Um, and then you could select all of
the things that if you wanted to connect to exchange
online and Azure AD and all of these things,
connect, you could select all the ones you wanted
to connect to click. Okay. It would, um, log
you in and it would load all of the correct modules
for you so that you had one PowerShell window
and you could go off and do, you know, all the
things that you, you wanted to do. Um, I actually
recognize the screenshot. So you put in the show
notes Chris. So I probably used your tool without
me knowing you back then. So that's funny. That's
funny. Yeah, that's that's cool though. And you
know, over the years, this has just been a it's
been a little passion project of my own where
I've just done things on it just whenever I wanted
to test myself or do something where I you know,
I could I wanted to figure out if I could do
something right. So I you know, at one point
in time, I think maybe 2022 or 2023, I built
my own API so I could do a version check. That
may mean nothing to anyone, but it was just a
fun thing for me to do to be able to build an
API that does something very simple like check
versions. Now, long story short, and the reason
we're going on this whole history is that ultimately,
we were connecting to modules in PowerShell to
do things. Over time, not only has names changed,
Azure AD became Entry ID, and we've had all these
name changes. the way we authenticate to our
modules and our services has changed. MFA has
become a thing. Service principles are a thing.
All of these things have sort of started to take
shape. And so, you know, the world is changing,
right? And I've been thinking a lot lately about
making some changes to Connect 365, bringing
it up to date again. And one of the things that
I kind of realized was there's a lot of just
bad information around, right? I think a lot
of folks seem to believe and think that the graph,
Microsoft .graph or the graph SDK is the only
way to interact with M365 via PowerShell these
days. Now, if you're really, really hardcore,
you're probably just using graph natively. So
you're doing invoke web request or invoke what
have you. Instructing your own headers and bodies.
Right. But for many of us, as cool as that is,
it's not always an efficient thing unless you're
like a developer and this is what you do all
the time, right? And if you're going to go out
and write scripts to do things, you could spend
the time to do that. But if you're just going
to be doing like admin tasks on a day -to -day
basis, maybe that's a little heavy. It's a bit
of a heavy tool to be using. And so what I wanted
to do was sort of talk a little bit about where
we are with modules. for managing M365 and Entra
or Entra ID, right? I'm not really going to widen
this too much because I'm sure there's a bunch
of stuff around there for just Azure. And, you
know, we have those are the AZ or AZ modules
for managing all the Azure service. I'm not really
talking about that today. I'm really just going
to talk about where we are with M365 specifically.
And, you know, as you guessed it, we have the
Microsoft Graph or I think it's technically called
the Microsoft Graph SDK for PowerShell. I think
that's the the real name. That's something that
sort of came about around 2020. Microsoft started
sort of making that public and you'll be familiar
with the sort of MG command that's right. So
get MG user and stuff like that. Whereas if you
think a little bit about some of the historic
way we would connect to, for example, Azure AD.
we first started with something called MSOnline
or the MSOL module, which was, you know, get
MSOL user. Very, very old. That stuff sort of
started getting deprecated in 23 .4 timeframe.
I think we had the Azure AD modules, which actually
use something called Azure Graph, which is an
older version of what is essentially Microsoft
Graph today. and you would be familiar with those
ones with get AAD user and stuff like that. The
evolution of all of those things that came out
of those when they got deprecated in 2024 is
the Microsoft Graph PowerShell SDK or Microsoft
.Graph, which is really just the name of the
package. That's what most people use, I guess,
and that's where most people's heads go when
you talk about automation and, and PowerShell
use for, for M365, but it's a handy tool. Obviously
there's a ton there. Um, and you know, it does
obviously Entra, it does Intune, some teams,
there's some SharePoint in there. It's really,
really good if you want to do reports and you
know, if you want to work in, for example, conditional
access policies, all that type of stuff, like
it's a very deep, uh, tool set, but it isn't
the only tool set. And I personally find it pretty
tricky to use because it's so closely linked
to graph. It doesn't always work the way you
expect, right? You can't just pass in a username
and expect to get a result there. You really
need to be formatting everything correctly, and
you're going to be using GUIDs a lot of the time.
So, you know, it can be a little tricky. But
the good news is that there are still some workload
specific modules that do exist. And actually,
something I recently found that I didn't know
about was the Microsoft Intra PowerShell module.
It's Microsoft .Intra and it's more of a lightweight
for just administration of Intra ID. So if you're
going to be doing stuff with users and groups
and apps and policies and stuff like that, you
don't need to go and use a graph. Now, obviously
you can use graph if it's doing what you want,
but this is a much more lightweight, slightly
easier to use module. that I was very pleasantly
surprised with. And so I thought, you know what,
that's one I definitely want to mention and talk
about here. We still have the Exchange Online
management or Exchange Online tools. Now I think,
and I'm sure there's going to be some, I'm probably
going to get this wrong. Someone's going to correct
me, but I think this is the third version of
the Exchange Online modules. So there was the
original Exchange Online module. then there was
V2, which was very slow and didn't work so great.
And then I think this is the actual third release
of the Exchange online PowerShell module. And
if you're going to do anything with Exchange
Online, and also if you're going to do anything
in the security compliance center, sort of purview
type stuff, that's the module you want to use
for that. And I think what you'll find is folks
who have a sort of a multi -dimensional role
where you're administering M365 as a whole, you're
probably going to have multiple of these things
installed. I do a lot of security assessments
for M365. Usually I have all of these things
installed on whatever machine I'm working on
because I'm connecting to Graph, I'm connecting
to Exchange Online to do stuff, I'm connecting
to Teams and things like that. So the Microsoft
Teams... module still exists. It's still available.
You can still use it. Microsoft SharePoint Online
also has, it's called microsoft .online .sharepoint
.powershell. That module still exists as well.
So really, if we think about what's gone away
and what we've lost, it's only those Azure AD
specific things that have been around for a long,
long time, right? And they don't work anymore.
Actually, I went and found, I have a very old
desktop machine that sits next to me on the floor
here. And this thing is never booted up. Usually
it just sits here. And I plugged it in today,
booted up into Windows 11, because I don't have
a Windows 11 machine anywhere else. And, and
actually tested a bunch of the stuff from Windows
11. So I could, you know, make sure I wasn't
giving false information. And yeah, the MSOL
doesn't work anymore. The Azure AD module doesn't
work anymore. If you connect to it, you get a
very nice error message that says its access
is denied. So those, those have gone away. They've
obviously been deprecated and there's been a
long sort of deprecation story there since, since
I think it's March of 2024, but, um, exchange
online is still there. Teams are still there.
SharePoint is still there. And then there's some
other ones that, you know, you may or may not
use, right? I think these are a little bit lesser
known and then, but probably not something you
would use all the time unless you specifically
work in these areas. There's an AIP service module,
um, for, you know, the, the old AIP or rights
management stuff. There's a couple of modules
for the power platform. So if you dig into sort
of power apps administration, there's some modules
there. Um, and then there's a power BI management
module as well. If you actually are, you know,
a heavy power BI user in your, in your tenant,
in your environment, which is really, really
helpful. So Chris, are these modules now? Um,
because I was encountering the issues with the
Azure AD modules, uh, uh, a while ago when I
migrated to Mac OS because As you know, Mac OS
only runs PowerShell Core. So the newer version,
what is it? Everything beyond, starting from
version six. And the Azure AD module only work
on the classic Windows PowerShell. And I still
get a lot of confusion from that because a sys
admin to which I provide a PowerShell script
will automatically open up Windows PowerShell
on their desktop or server. And they aren't even
aware of PowerShell Core. Are all the modules
you mentioned, are they now also transitioned
into the PowerShell Core world or are some of
them still requiring legacy Windows PowerShell?
So that is a very good question, right? I know
the graph obviously is one that was built for
that. Yes, that's the new one. Yeah, now I have
not tested the, have I tested the Entra one?
I believe I have tested the Entra one. Exchange
works well with PowerShell Core. Yeah, and I'm
pretty sure that teams and SharePoint do as well.
The one that I'm least familiar with is probably
SharePoint, because I don't do a ton of SharePoint
work, right? But what is nice now, now apart
from the fact that they're all named, the naming
standards of these things are all different,
right? Some of them, Microsoft, the Intra, Microsoft,
the Graph, that's cool. Exchange Online Management,
you know, the naming is all over the shop. But
what is nice is that all of these things are
now available through the PowerShot gallery.
So all of them are there. And I think because
of that, we're seeing a little bit more standardization
on using stuff with core. Like you, I'm a Mac
user. And so I also find it very frustrating
when I need to do something and I have to go
and find a Windows machine to be able to test
or do stuff because I don't, you know, I don't
have a Windows machine and I don't run a VM,
Windows VM specifically for just modules. Right.
So not anymore, anyway. Um, so, but now it's
a good, it's a good call out. I do believe most
of them are now cross platform and they also
sort of support, you know, newer releases of,
of, of PowerShell, which is, which is really
helpful. Um, obviously you still get the little
nuances. I get the same problem because in, you
know, in my work environment, I'm one of very
few that uses a Mac. So if I write scripts, the
parts are always messed, messed up because, you
know, I'm using forward slashes instead of back
slashes. Cause I'm on a Mac and everyone else
is using, you know, what, what have you. So.
that gets a little interesting sometimes. So
I got to think about that if I'm going to be
giving scripts to colleagues to run because,
you know. Yeah, maybe also good to point that
out to our listeners since we're talking PowerShell
now. This is not specifically Microsoft security
topic perhaps, but we touch PowerShell regularly,
of course. So Windows PowerShell or PowerShell,
as we all know, was originally a Microsoft closed
source product. up until version 5 .something,
which is the latest version still shipped with
your Windows installation. Microsoft branched
it off into an open source PowerShell afterwards,
and that became PowerShell Core. I also believe
it's built on .NET something. It has a different
architecture under the hood. I don't know the
specifics on that. But starting with PowerShell
6, and we're now up until 7 .something. 7 .5,
I believe. I don't know from the top of my head,
but yeah, so 7 .5. PowerShell Core is the latest
PowerShell, so people please stop using Windows
PowerShell, although it is shipped with your
Windows installation and you have to install
PowerShell Core separately. I don't understand
why Microsoft does not just ship Core with Windows
or makes it a default feature on Windows or whatever,
but you have to install it manually. And also
I see a lot of people still using ISE, right?
Windows PowerShell with ISE. That's so funny.
And I never, you see, I never used ISE. That
was never my part of my workflow. And so it's
really, well, I say that I've obviously, and
I think many of us, you know, back in the day
I've had... time where you log on to a server
for something and then you need to look at a
PS1 and the only thing that's on there is either
notepad or ISE right and and I would usually
just use notepad but yeah we've all opened ISE
by mistake for that on those but no I've never
been an ISE user but you're right it's funny
to see people that that are sort of stuck in
that in that way of doing things Well, I used
ISE with some more complex scripts because you
can add some breaks, for example, in between
and do some more advanced debugging where there
are some issues and you can see the actual values
of your variables while the script was running.
But you can all do that in VS Code nowadays.
A lot of people don't know that, but there are
debuggers in VS Code and you can run PowerShell
there and add breaks and everything. So there's
no need to use ISE ever again. That's right.
And you're right though, as well with, with just,
you know, a normal PowerShell. I think why it's
probably still out there is there's, it's backward
compatibility, right? And if you're going to
be doing, um, anything with, um, and I think
it's so my, uh, Microsoft forms or WPF, PF, where
you have a GUI interface to a script or something
that stuff historically works better on the older
versions of, of, um, uh, of, of PowerShell at,
you know, there's more things you need to do
on, on core to make that work. And for a lot
of us who have written these types of scripts,
we're not hardcore .NET developers where this
is an easy thing for us to transition. So I think
part of it is just that there's a lot of investment.
Folks have put a lot of time into building scripts
and automations and stuff that still rely on
PowerShell 3 or work on PowerShell 3, and they
haven't taken the time. Now, I would say to those
folks, if you're listening, you probably should
start thinking about moving to newer versions
of PowerShell, right? I'm sure there's, apart
from performance and all sorts of other issues,
there's probably security reasons why you'd want
to be doing that as well. And as all the operating
systems go away, it's something to think about.
But I think that's it. I think it's really just
a backward compatibility thing. Yeah, if you're
installing it on Linux or Mac, it's always going
to be cool. So we always get the latest and greatest
when we do that. And also maybe a fun fact, PowerShell
6, so the open source variant, the open source
one, the PowerShell Core, was released in January
of 2018. So it's already eight years ago. So
it's not new anymore. So actually, interesting,
I saw this week that Jeffrey Snowver has retired.
Uh, or retirees retiring. And so for those folks,
Jeffrey's Nova was the person who actually created
PowerShell. Um, and he's a lovely, lovely, lovely
guy. I've met him. I've been lucky enough to
meet him a few times now at a MVP summit and
had some great conversations with him. He's such
a cool guy. Um, just such a smart, lovely, lovely
person. And, uh, yeah, I think it was this week
or last week I read that he was, he was retiring.
Uh, he's had a fantastic career at Microsoft.
So You know, thank you for giving us PowerShell,
Mr. Snow, but we appreciate it very, very much.
So wrapping this up, I guess there's a couple
of things I wanted to kind of call out as well,
or just draw attention to that there's some community
or sort of non -Microsoft official modules as
well that I really think are sort of must haves,
right? Especially if you're doing a lot of automation
and stuff. There's the sort of PMP dot PowerShell,
which is the sort of PowerShell module for managing
M365. I think it really started as a SharePoint
thing, but it's become sort of a much wider.
So, you know, more than 700 commandlets across
sort of SharePoint teams, Planner, Power Platform,
Entra. Really sort of really nice community project
there to kind of build automation and PowerShare
capabilities for managing M365. Really good one.
Import Excel. I mean, you know, if you're going
to do anything with reporting and importing,
exporting, you know, CSVs are good. spreadsheets
are better, right? And being able to import and
export PowerShell spreadsheets, or yeah, Excel
spreadsheets without actually having Excel installed
is pretty cool. I think Doug Fink is the author
of that module, very cool module that I would
say is almost a must have. And then I've got
MSale PS, which is really a wrapper for the MSale
or C authentication libraries in .NET. So this
was really, really useful. If you're going to
be doing things where, you know, we talked about
just using native graph before where you, um,
you know, you do an actual, you know, invoke
web requests to the end point. Well, if you use,
um, the MSAL PS module, you could actually get
your tokens and stuff in a, in a little bit more
simple way. Um, and then you can use those tokens
to sort of onward connect. So it makes it really,
really simple. If you're calling APIs maybe where
there aren't really good PowerShell modules or
PowerShell modules are a little bit incomplete
and you're going to have to rely on the native
APIs. Yeah, this is a great way to kind of handle
and wrap that authentication layer. So definitely
something to check out. So as I said before,
I'm going to be working on some updates to Connect
365 over the next few months. I have some ideas.
One of the things that's always bugged me about
it is that it's because of the web interface
or the graphical interface on it. It's always
been Windows only. I'm going to do some work
now to take it to PowerShell Core and make it
available to Windows and Mac so that it can be
used across and update some of the modules, get
rid of some of the old things that are no longer
available to us, all that type of stuff. If anyone's
listening to this and you have used it or haven't
used it and you heard about it for the first
time today, you know, have a look, reach out
to me on socials or on GitHub if there's any
sort of feedback or feature requests. You know,
it's an old tool. It's been around for, you know,
10 or 12 or something like that years now. And
at one point in time, it was heavily used by
folks. I suspect a lot of people have moved on
to other things, but I want to do my bit and
bring it up to, you know, 2026 standard here
in the next few months. So yeah, feel free to
reach out to me if you've got some ideas. And
because I'm not sure if PowerShell Core does
support any ways to do some UI window creation.
in front, especially because it's running on
multiple platforms. You can always consider doing
some nice ASCII art menus, Chris. I'm a big fan
of those. A TUI, right? We move away from the
GUI to the TUI, the text user interface. TUI's
are all the rage these days. I never heard about
the term TUI, but I'll remember that. Yeah, it's
the new GUI, I would say. Yeah, nice. Thanks
Chris for that for that topic Looking forward
to to your updates coming soon to the community.
I like I like to visit to revisit actually pass
keys So this is not new we talked about pass
keys before actually in our very first episode
and December of 2024 time flies But quite a few
things have changed since then and I believe
now well lately PassKeys became such mature that
I think it's now finally time to start onboarding
this at scale, especially the whole user experience
has improved a lot lately. And there are some
new features being announced in the public preview
lately. I saw some community work on the topic,
so that's why I thought it would be a good time
to revisit PassKeys. Maybe just to start off
with a short recap. A passkey is a passwordless
sign -in method. It uses public key cryptography
instead of typing a shared secret and the device
creates a unique key pair for each website or
service and it keeps the private key safe on
the device and it proves the position with an
unlock like biometrics with your fingerprint
or a pin code. So it's complete multifactor but
it is not vulnerable to any man -in -the -middle
attacks. And I think pass keys matter because
phishing has also gotten more effective by stealing
passwords, but also by performing some real world
man in the middle tricks. We talked about them
before. Evilgenics is a popular example of how
that can be demonstrated in practice. So the
attacker is relaying the user's authentication
through a fake login page. letting the user perform
their actual login and MFA and then the authentication
token can be replayed. But there's also a risk
with traditional MFA called MFA fatigue, where
you get multiple prompts on your MFA device and
in the hope that people just accept it or approve
the request. And that way the attacker has a
successful MFA and they can register an additional
MFA device, for example, to get some persistence
on the account. So fishing resistant MFA methods
like pass keys. break that chain by binding the
sign in to a legitimate site and requiring cryptographic
proof that can't be replayed through a fake login
page. So that's the short gist of it. And again,
quite a lot has changed since we first talked
about this, especially the user experience was
a bit lacking at the start. When Microsoft introduced
pass keys, it was first limited to only physical
pass keys like the Yubi keys, but also the old
user experience was a bit wonky. you were required
to register a traditional MFA through the Authenticator
app as well. And then you can add an additional
MFA device in the form of physical passkey. But
if you really want to require a phishing resistant
MFA across the board, you still had those MFA
Authenticator apps registered and everything.
And the whole user experience, when somebody
logs in for the first time, it wasn't possible
to register a passkey right away. And that's
also recent change. I think that was definitely
helps the onboarding. When I was at Ignite and
I was working at the intro booth, um, that was
a very large complaint from a lot of customers
about adoption of pass keys because they were
like, well, we've got to go through this wonky
process to get folks registered and onboarded.
Then we can only get them to a pass key. And
a lot of people were really complaining about
that. There was, I remember speaking to one,
one gentleman, I think he was from Germany and
he was like, You don't even know how many tens
of hours I've spent trying to work around this
and we just can't. I was like, yeah, I don't
think you can at this point. So this is great
news that this is something that can now be,
you know, has been. updated or at least made
a little bit more user -friendly. I'm not sure
when this was introduced. Apparently after Ignite,
I must admit I'm not into the deep weeds of passkey
development. So I just noticed this because syncable
passkeys is now a thing as well. So at first
we only had device -bound passkey. So the physical
passkeys, I use a YubiKey myself with a fingerprint
sensor on there. Later Microsoft introduced passkey.
through their Microsoft Authenticator app, which
was still device bound. So you register the passkey
on the Authenticator app. But when you were doing
an authentication, a short Bluetooth connection
was set up with the device to verify you were
actually there at the same computer you're authenticating
to. So that made a device bound. And device bound
also means when you lose your iPhone or you lose
your YubiKey, your key is gone. You cannot just
restore an iCloud backup on a different iPhone
and expect the pass keys to return there as well
because it was bound to the original device,
part of the cryptographic proof and the whole
idea of the authentication mechanism. Now with
syncable pass keys, you have the ability to store
the pass key in, for example, like an iCloud
keychain or one password or... Keeper or any
other password vault. We've seen this a lot last
couple of months with other services like GitHub,
Amazon, a lot of websites now ask you to register
a passkey for you and that is obviously better
than just a password because it is MFA built
in actually into the authentication process.
But there is also a downside to that because
your passkey, your cryptographic proof is stored
in a password vault. It might be synced through
an online service. If your computer might be
compromised or maybe your browser plugin is compromised
or there are other scenarios thinkable where
your passkey might belong, might land in the
wrong hands. So that is a security consideration
I will get to later as well. Together with syncable
passkeys and a better onboarding flow and user
experience, we now also have passkey profiles,
which also enables us to limit and set specific
passkey profiles to specific groups of users,
for example. And this is really valuable where
you, for example, say, okay, we have a certain
account. We want that to have syncable passkeys.
Those don't have any, I don't know, high level
privileges where we accept a somewhat less secure.
Well, it's not less secure, but there might be
some additional attack vectors on a syncable
passkey. But we accept that for regular users,
for example, because it's much easier the fact
that they can sync their passkey and they won't
call the service desk any longer when they lose
their physical key, for example, or their phone.
And we accept that risk, that additional risk,
so to speak, and we create a separate passkey
profile for those groups of users. and we allow
syncable pass keys for those and not for any
other high privilege roles. That makes a lot
of sense. So if you wanted to promote YubiKey
use still for your admin users, you could still
make sure that admin users and anyone who has
a PIM role or something like that, an admin account
specific still has to use a YubiKey or some physical
thing. but your frontline workers and information
workers and everyone else in the business, they're
okay to be able to store that thing in their
vault. That's pretty cool. Yeah. And by the way,
now you touch on that topic, there is also something
we call step up authentication. And this was
already possible with your conditional access
policies. And I think it's already a good idea
to consider role -based conditional access policies
where you say whenever somebody is a global administrator
we require a phishing resistant MFA string for
example. So when you log in with your regular
MFA through the Authenticator app you request
a role of the global administrator. Somebody
approves the role, hopefully. I hope it has an
approval step. And then once you get to the global
administrator role, you get a prompt again to
do an additional MFA. And then your authenticator
approval will not cut it any longer. And you
have to take out the UB key or the physical pass
key or the pass key on your authenticator. It's
an interesting scenario you talk about there
because one of the problems with PIM role authentication
or activation is that a lot of organizations
want to go, you know, you have your PIM role,
but I want to force MFA again when the user activates
the role. So you've logged in, you've MFA'd,
you go and activate a role. They want to force
that second MFA again. If you're not stepping
up, that's really difficult to do because the
original MFA that you've just done satisfies
the MFA requirement. And so unless you've been
logged in for a very long time or what have you,
you're not always going to see that sort of second
MFA request, right? Unless you actually are stepping
it up to a higher level or a more secure level
of MFA. So that's definitely one way to do that.
Yeah. And you can also think of the scenario
where a token replay was already used to gain
access to your account and somebody just requests
a PIM role and now they're global administrator
with that same cash to token. You're right. Yeah.
So step up authentication is also important.
So I think for those reasons alone, you should
really look into pass keys and make sure your
high privilege roles and users are protected
better than just with regular MFA nowadays. When
I started using this, I got a little bit confused
about the term attestation. That is something
you can or should enable on those passkey profiles,
which got introduced as well. And attestation,
I had to look it up. It's part of the Web Auth
N protocol, the web standard regarding passkeys.
It's about proving what authenticator created
the credential. again using cryptographic evidence
during the registration. So the relying party,
which is Microsoft Entry ID in this case, can
validate the evidence against trusted metadata
to decide whether to accept that specific authenticator
model. And I read somewhere online people saying,
without attestation, your pass keys are just
regular key pairs. You still get a strong key
based login, but the service cannot reliably
prove which authenticator model or provider generated
the keys or whether claimed identifiers were
actually genuine. So attestation is really important
to enable. So if you're using device bound pass
keys with FIDO keys, for example, or UB keys
or any other, or through the authenticator app,
make sure that attestation is enabled. When Microsoft
started off with... pass keys through the Authenticator
app, you had to disable attestation because back
then, apparently, the whole registration and
the metadata was not in centralized databases
or whatnot. I'm not sure how that works in the
back end. That's also a reason why I think it
was not streamlined a year or more ago. Now you
should enable attestation on your device bound
pass keys. And if preferably, you can also add
an AA GUID, which is, let me see, I put the acronym
in the show notes, I believe. Let me see where
did I put it there. I cannot find it anymore.
I'm not sure what the AA stands for. Attestation
something. Well. I'll look it up. I'll make sure
it's in the show notes. But the AA GUID is actually
a GUID of a PaaSky provider. You can add as an
additional level to put in an allow or a block
list, where you say, for example, we only register
UI keys, for example, or face and physical keys.
And we only put those AA GUIDs in the allow list
to make sure that we enforce the usage of only
those two providers in addition to attestation.
Right. So that also then prevents the use of,
even though you might, let's say you, you, you
only allow Yubi keys, but you don't allow any
of the other branded ones, right? That then you
can't have someone turn up with some other key
that they found on Amazon and use it. If your
policy says only Yubi keys. I've seen some scripts
in the community that either extract or provide
or both a list of what these, cause, cause obviously
the manufacturers have a fixed, you know, AA
GUID, right? Or what have you. So yeah, there's
a lot of information out there about why this
is a good idea as well, which is cool. Yeah,
I did it at our own company a while ago when
we started with passkey registration. We had
a couple of different models because we had some
biometric ones and some pin ones. So we used
Vathion and Ubiqui and I believe even a third
provider. I just registered it without having
the allow list of AA GUIDs. And then I used a
PowerShell module again to retrieve from entry
ID from the graph all the passkey GUIDs from
all the users. And then I had my unique list.
of three GUIDs which are put in the allow list.
And I know as of then, we wouldn't allow any
other vendors. Yeah, very cool. Yeah. But the
thing is with the syncable pass keys, you cannot
enable attestation. So you have to disable that
on the additional pass key profile. And that's
why it's also maybe a little bit more risky in
that regard. So that's why you should really
consider scoping that syncable passkey profile
to a specific set of group with users. Another
consideration you should be aware of is guest
accounts. So Microsoft will not let your guest
users register for a passkey. I'm not sure why
that is. It is in the docs and it is known as
a limitation as of now. So getting your guests
onto passkeys is a little bit less straightforward.
But there's a workaround to this. We at the company
I work for use a lot of passkeys. also in our
managed services towards our customers. And we
want to make sure that everybody logs in with
a passkey, even if they switch. to the other
tenants of the customers we are providing services
to. And a workaround you can use is by going
into the cross -tenant access settings. First
of all, I would always advise you to set up a
conditional access policy to require the highest
authentication strength, so to make sure it's
phishing -resistant MFA for your services. And
then in the cross -tenant access setting, you
can set up your partner, your partner tenant,
where the guest accounts come from. and then
you can trust the inbound MFA claim for those
partners. Because you know it already aligns
with your highest authentication strength, thanks
to the conditional access policy, you are sure
that they can only come in with the highest MFA
and you can trust the claim. So you don't expect
them, you don't require them to do an additional
MFA prompt when they reach your tenant. And this
has multiple benefits because as I said, we have
a managed SOC sort of speak with a lot of security
analysts connecting to over a hundred different
customer tenants. And before they had an MFA
registration with all of these individual hundred
customers. When somebody lost their phone, they
had to re -register MFA for all the different
tenants and they probably had to call the customer.
I have a list of this. MFA registrations from
different customers. Now, I also, I do separate
my, just FYI, I mean, I guess I separate my MFA
stuff. You know, I use Microsoft Authenticator
specifically and purely for work related stuff.
You know, for my own personal use, I have different
things that I use for that. But so at least I
don't have jumbled in there, you know, personal
accounts and work accounts, but I have a very
long list of customer because obviously every
customer that I work with, I have an account,
every account has MFA. You know, yeah, I could
see how this becomes very long list. But those
MFAs are bound to your device. If you lose your
phone and you buy a new phone, even if you restore
a backup from it, the MFA registration should
be done again. And then you have to call up all
your customers again to make sure they reset
the MFA registration. This was a big thing for
us in the past. So now we make sure that every
single customer of ours requires the phishing
resistant MFA authentication strength when we
come into their portal. And in return, we ask
them to trust our MFA claim as a two -way validation
in that regard. And which makes it great because
the physical passkey the security analyst holds
is literally the key to access all the different
tenants. revoke that passkey or if we revoke
their guest account, they don't have any access
anymore as well to all of the different types.
That's a really good way to work that. I put
a screenshot in the show notes where you can
find this actual setting. Obviously, it's a little
bit different if you work with a lot of different
partner tenants with a lot of different guest
accounts, then you might want to exempt them
from the PassKey requirements. But otherwise,
you should definitely look into making sure PassKey
is your new default along the road for MFA. Did
I see Microsoft are actually going to be doing
that as well for you? Did they not announce last
week or the week before that pass keys are going
to become the default MFA for moving forward?
There's a date. I'll have to look it up, I guess.
Okay, great. Well, I missed that news. No, I
think Microsoft are going to be forcing folks
as well to do it, which we can debate. Whether
that's a good or bad thing, I guess you can see
both sides of it. But I do think that they want
folks to adopt it. It makes sense to adopt it
because it is a more secure way to do it. But
a lot of businesses are not. A lot of companies
are still struggling with MFA adoption, right?
So go and now throw pass keys at them. It's just
going to be slightly messy. Yeah. And even with
the syncable pass keys, it's arguably still safer
than allowing replayable MFA requests, right?
And with the AA GUIDs I mentioned before, you
can also require your users that they can only
store that syncable passkey in a vault you approve
of. So for example, when you use LastPass Enterprise
or Keeper for Business or whatever, you can put
those AA GUIDs in the passkey profile so that
the user cannot store it in their personal iCloud
keychain, for example, and can only store it
in the business password vault, for example.
Yeah, that makes sense. I put a lot of links
in the show notes, not only the documentation
about syncable pass keys, the new pass key profiles,
which both are in a public preview right now,
but also some links to Jan Bakker's blogs. You
probably know him, Chris. He's from the Netherlands,
of course. They call him Mr. Paski as well in
the community. He writes a lot about the topic.
He has some good blogs about it with some great
examples and make sure to check that out as well.
Yeah, absolutely. I was going to say, I just
found AAGooid is Authenticator Attestation Globally
Unique Identifier. I just found it in the notes.
Oh, it is in the notes. Well, yes. I knew it
was somewhere. Well, the AA GUID for short. Okay,
thanks. So yeah, with Jan Bakker and also your
PowerShell topic brings us to the community project
of this month. And I actually cobbled together
multiple community products because this month
I saw something really cool happen in the community.
It all started with Fabian Barach, a German security
MVP. We have mentioned before, he's also one
of the contributors of Meister. And I think we
should touch on Meister again in the future as
well, because I saw a version 2 .0 coming by.
But well, let's save that for a later episode.
But Fabian wrote a blog about a tool he created
called Invoke Entry ID Passkey Login. And it
lets you authenticate against the Microsoft Draft
with MFA as a user. but from a script using pass
keys, which is pretty clever stuff because some
of the APIs will not allow you to authenticate
as a machine and only as a dedicated user. So
that's why he had to work around some stuff to
do something in a GitHub action he created. But
then Nathan McNulty, he's an MVP from the US,
picked it up and built a standalone version of
that called passkeylogin .ps1. His version uses
a passkey exported from an Azure Key Vault, which
is already a nice addition. And then Jos Lieben,
he's from the Netherlands again. He said, hold
my beer. And he took it even further. So he created
new FidoKey .ps1, which is a script which can
actually generate the passkeys for an account.
So that's three community members building on
top of each other in a short amount of time.
And I thought that was really cool to see. Using
these methods obviously raises some security
concerns because you're authenticating with a
very secure passkey in an automated way with
scripts storing the passkey locally temporarily
or storing it in a key vault. It has its downsides,
of course. But you can use the new passkey profile
to have maybe a separate automation specific
account in there to allow it only for certain
actions. And while still enforcing the stricter
requirements for your normal interactive logins,
for example. Again, from a security perspective,
You have to be very careful here. You need proper
scoping, secure storage, as I said, of the PASCII
material, and very clear understanding, I think,
of what you're actually doing. But I think when
done responsibly, this can be extremely powerful.
Think about automated environment provisioning,
for example, one -time onboarding of tasks and
other interactions with APIs that would otherwise
require some manual MFA prompts. And beyond the
technical details, I think again, the most impressive
part is how the community came together. Yeah,
people's people spending their spare time creating
tools and just simply giving it away to the rest
of us. Yeah, there's so much cool stuff out there.
That's you know, and I think it's good to good
to see people still putting the putting the effort
in, right? Because I you know, it can be a thankless
job as well. And it's nice that people are still
sort of doing it. And you know, especially these
folks, I, I got to say, I've definitely come
is it Yoss? Is that how you say his name? I've
definitely come across his stuff before. He's
been doing this for a long time. If you look
at his blog, he's got some like articles there
from like 2014 and whatnot. So he's been contributing
and pushing things into the community for a long,
long time. So it's great when we come across
these things where we can kind of give these
guys a little bit of a shout out as well. So
very, very cool. I think it deserves the recognition
and definitely a shout out. helped them get,
I don't know, help other people with the stuff
they built and they made. Yeah. No, very cool.
That's very, very cool, Koos. Thank you for that.
Thoughtful and for stitching those together for
me. I'd seen one or two of them pop up on LinkedIn,
but I hadn't sort of stitched all of them together.
I also did see today, this week or last week,
the Maester V2 come out. I was playing with it
yesterday, actually. I haven't seen, I mean,
There's some changes on the interface and it
looks like they have some settings, a settings
bar now where you can actually make some, do
some settings back into the tenant, which is
interesting. I haven't messed with it too much.
I literally just yesterday, I was updating some
of my automations that use Maester. So played
with it. Let's keep it as a cliffhanger for now.
Yeah, absolutely. Absolutely. I can't believe
we're at the end of, pretty much coming up on
the end of February, right? So we'll be seeing
each other here in a few weeks time again. That's
going to be fun. It's already March. I know.
MVP Summit is coming up for people who might
not be aware. And we'll be doing obviously a
live recording again in Redmet. Yeah, that'd
be very, very cool. And it might be either on
Microsoft campus or in a kitchen at an Airbnb.
We'll see about that when it happens. Or in a
cigar bar somewhere that we find. A cigar bar?
I'll hold you to it. Yes. Thank you, folks, very
much for joining us for another episode. We really
appreciate you spending time with us. And as
always, reach out to us if there's anything that
is troubling you or anything that you'd like
to see us cover or get our commentary on on the
show. Like, subscribe, all those cool things.
I look forward to seeing you next month, man.
I've already started shopping for Tim Tams for
all of the suitcase of Tim Tams I'll be taking
over for the Dutchies. Please make sure you bring
those double chocolate ones, Chris. 100%, I will
do. And I'll make sure the stroopwafels come
your way as well. Excellent. Thanks, folks. And
until next time, we will see you next time. Thank
you very much. Bye bye, thanks for listening.