Welcome back to the deep dive. So today we're we're kind of tearing down the walls literally literally. For decades, it security it was simple geometry, right, You had an office, you had a firewall, and you know, anyone sitting inside that perimeter was considered safe. But the cloud has just completely dissolved that and the source material we're exploring today it makes us claim that honestly feels like a rallying cry. It says identity is the new firewall.
It's a massive shift, isn't it. I mean, if you can't control who the person is, it just doesn't matter how strong your encryption is or how locked down your servers are. If I have your identity, I am you, and once i'm you, the firewall doesn't care.
That is a terrifying thought to kick things off with. To help us navigate this, we're looking at a very specific tactical guide Microsoft Ayured Administrator Exam Prep AZ one O four by Lullett Rawat. We're focusing on the first three chapters. Now, I know exam Prep can sound a bit dry.
Oh yeah, flashbacks to late note cramming exactly.
But what stood out to me about Rowlet's approach is that he treats the exam criteria as a a survival guide for the actual job.
That's the best way to look at the AZ one O four. It's widely considered one of the harder associate exams because it's not just theory, it's asking which button do you click when the CEO can't get their email?
Or how do you fix this sink error before the nine am meeting?
Exactly. Rad does a great job balancing that necessary memorization with the the day to day reality of being an Azure admin.
So our mission today is to build a mental model of this identity firewall. We're going to break this down into three big chunks. First, the population problem. How do we manage thousands of users without losing our minds?
A classic?
Second, the bridge? How do we connect our dusty old on prem servers to the shiny new cloud? And finally, the keys to the kingdom role based access control.
Sounds like a solid roadmap.
Okay, let's start with that population explosion managing users in groups chapter one. Now, creating a single user in Azure is is. It's trivial. You click new user, you tad Bob done. But Rod throws us into a scenario that I think gives most admin's heartburn bulk operations.
Ah, the summer intern scenario.
Or the we just acquired a competitor scenario. HR sends you a spreadsheet with two hundred names on Monday morning and says these need to be live by.
Lunch, right, and you are not clicking new user two hundred times railway and if you do, you're not only gonna make mistakes, you're gonna hate your job by noon. This is where the bulk create feature comes in. Okay, it sounds simple. You just upload a CSV file, but Rowat points out some very specific gotchas in that file that you really need to know.
This is the kind of detail I love. You'd assume a CSV just needs what name and email.
That's what you'd think, But there are mandatory fields that really catch people off guard. The one that always trips people up is the block sign in column.
Block sign in. Why would that be mandatory? Wouldn't you just want them to sign in right away?
Well, think about the workflow. You might be provisioning accounts for employees who don't start for another two weeks. You need the account to exist so you can assign a license, set up their mailbox, maybe grant them access to a SharePoint site. So it's already for day one.
But you definitely don't want that account to be active yet.
Exactly, you don't want someone guessing the temporary password before the employee even walks in the door.
So the system forces you to make a security decision before the user even exists. I like that. So we've got our two hundred users, but we can't manage two hundred individuals. We need groups.
And this is where azure AD or you know, Microsoft entra ID as it's often called, now gets a little more nuanced than the old active directory people might be used to. 'watt distinguishes heavily between security groups and Office three sixty five groups.
I feel like this is a distinction that gets blurred a lot in practice, but for the exam it's black and white. How should we think about them?
It really just comes down to intent. Are you trying to control access or are you trying to help people work together? Okay, if you need to lock down a firewall, roll or give permissions to a database, you use a security group. It's a boundary. Think of it like a key card to a specific floor of a building.
Right, security equals boundaries and the other one.
If the goal is, hey, we need a shared calendar, a shared inbox, and a place to dump files for the marketing team, that's an office three sixty five group. It creates that whole collaboration workspace for you.
Got it. So security groups are for the admins to manage control Both three sixty five groups are for the users to get work done.
Broadly speaking, Yeah, but the real magic isn't the group type. It's how people get into the group. If you're manually adding Bob to the marketing group, you're probably doing it wrong.
This has to be dynamic membership. I found this fascinating. You're basically writing a logic statement for your.
User list exactly if department equals it add to the it security group. And it sounds great because it's set it and forget it. Yeah, but rewat hindset a risk here. This kind of automation relies on.
Clean data, garbage in garbage.
At Precisely, If HR spells information technology as it on one form and I don't know infotech on another, your dynamic rule breaks.
And Bob can't do his job.
He's calling you, right, so while dynamic groups are a huge time saver, they actually force you to be much more disciplined about your data entry standards.
That's a great insight. Automation doesn't fix messiness, it just scales it. Okay, before we leave users, we have to talk about the people who don't work for you, the guests.
B to B business to business.
The modern workplace is so fluid, isn't it. You've got consultants, vendors, partners. In the older days, you just make them a fake employee account.
With a complex password written on a post.
It note exactly. But Azure handles this differently.
Much differently. You're inviting their existing identity, if they have a Gmail account or a corporate Outlook account from their own company. You invite that. You're not managed their password. You're just managing their access to your stuff.
But there is a gatekeeper the source mentions. Not just anyone can send these.
Invites correct by default. You need the user administrator role, and this is important. Inviting a guest is essentially punching a hole in your perimeter. You're letting an outsider in.
So you want someone with an administrative oversight making that call.
You do not just a random user who wants to share a doc with their friend.
Let's move on to our second bucket, quality of life, because let's be honest, and admin's life is mostly dealing with tickets, and the number one ticket is always I forgot my password every single time.
It's the bane of every IT department. It just consumes so much time that could be spent on actual engineering.
So rollbot highlights self service Password Reset SSPR as the solution, but he knows it's not just to switch you flip.
No, there's a configuration journey. First, you need global admin rights just to turn it on. But the real configuration is about the challenge when Bob forgets his word, how does he prove he's really bobbed right?
The authentication methods the book lists things like the mobile app, email, SMS.
The usual suspects, But the gotcha that always catches people is the registration requirement.
This is where the human element fails. The technology isn't.
It It is? You can enable SSPR today, but if your users haven't logged in and set up their security questions or linked their mobile phone, the feature is useless.
They get locked out, They click reset and the system says sorry, I.
Don't know who you are exactly, which is why SSPR isn't just a technical rollout, it's a communication rollout. You have to pester your users to register before they need it.
You can enforce it right, which.
Is what most smart admins do. You make it mandatory. You cannot check your email until you set up your recovery phone number.
Smart. Now, alongside user identity, we have device identity. The book talks about as your ad join, why does the cloud care about my laptop?
Well, it goes back to that identity is the firewall idea. Knowing who you are is step one. Knowing what device you are using is step two. If you're logging in from a managed corporate laptop with all the latest antivirus, maybe I let you in. If you're logging in from some unknown iPad at an airport, maybe I block you.
So we join devices to azure ad so the cloud can trust the hardware precisely. And there was a specific note about licensing here that seemed like a classic exam trap, the.
P two license. Yeah, if you want to do the advanced stuff like auto and rolling devices into Microsoft Intune for management as soon as they sign in. Rabot points out that you often need the Azure ad Premium P two license. The basic free tier just won't cut it.
Always check the licensing. Okay, let's get into the heavyweight section of this deep dive segment three Hybrid. Most companies aren't born in the cloud. They've got servers in a basement.
Somewhere, racks and racks of them running old school active directory, and they will for a long long time. The bridge between those two worlds is a tool called Azure ad Connect.
And the goal here is single sign on, right. I don't want a password for the basement and a different password for the cloud.
That's the holy grail. But getting there is surprisingly technical. Rawa outlines three distinct architectures for this, and it's really crucial we separate them. The exam loves to try and confuse you on these.
Let's walk through them. First up, Password hash synchronization PHS.
This is the most common and probably the most robust. You take the user's password on your local server, you hash it, which basically means putting it through a mathematical blender, so it's just gibberish, okay, and you send that string of gibberish up to Azure. When the user logs into Office three sixty five, Azure checks their password against that stored hash.
So, in this case, the authentication actually happens in the cloud. Azure has a copy of the.
Answer key, a mathematical copy yes, correct.
Yeah, okay, next pass through authentication. How's that different?
This is for the paranoid or the highly regulated. Some organizations have policies that say password data, even hashed, can never leave physical building.
Okay, so what do they do?
Well? When the user types their password into the cloud login page, Azure puts it in a secure envelope and sends it down to a little software agent running on your local server. Your local server checks the password and just sends back a simple yes or no.
So the cloud never sees the key. It just asks the local server to unlock the door for it.
Exactly. But think about the risk there. If your internet connection to the office goes.
Down, nobody can log into the cloud bingo.
With password hash sync. If your office loses power, people can still get their email from Starbucks because the cloud has the hash with pass through. If the office goes dark, the cloud goes dark.
That is a critical distinction for disaster recovery okay. And the third one federation.
That's the big iron ADFS Active Directory Federation Services. That's for when you have really complex needs, like using smart cards or integrating with other identity providers. It requires you to build and manage a whole farm of servers.
So unless you have a very specific reason.
You usually try to avoid that complexity.
Now, Rawat gives a really specific warning about setting up Azure ad connect. He talks about the upn suffix. It sounds super technical, but he says it breaks everything if you ignore it.
It's the classic dot local problem. So many older internal networks were named something like company dot local, but dot local isn't a valid domain on the public Internet. You can't route email to it.
So if my username is Bob at company dot local and I sink that to.
The cloud, Azure just looks at it and says I can't use this, so it renames you to something like Bob at company dot on Microsoft dot com. It works technically, but it's ugly and Bob is confused because his login name just changed.
So the fix is to add your real public domain DASH like company dot com dash to your local server before you sink.
Exactly align the names before you build the bridge.
Speaking of the bridge, there's a feature called password right back. It sounds like it reverses the flow.
It closes the loop, rememberspr if Bob resets his password in the cloud on Sunday night, his computer in the office needs to know about that new password on Monday morning. Right right back pushes that change from Azure down to the local server.
And the source mentioned a really specific security benefit with firewalls here. Usually security teams hate letting the cloud push things into their network.
They do because that usually means opening an inbound port on the firewall, which is a security risk. It's like leaving a window open.
But right back is different.
Right Rowatt points out that password right back uses an outbound connection on port four four three. The local server reaches out to the cloud every few seconds and just asks, hey, any.
Updates for me some no open holes in the firewall.
Correct, it's firewall friendly. It pulls the changes down. Nothing is pushed in without permission.
That's a really elegant solution. Okay, populated or users, we've synced our hybrid identity. Now the final piece who gets to do what? Second four role based access control or RBA.
This is the keys to the Kingdom part and the golden rule here which route really hammers home is least privilege, which means give people exactly enough permission to do their job and not one inch more. You do not make everyone a global admin just because it's easier. That is just asking for a disaster.
The book highlights the big three built in roles, owner, contributor, and reader. Reader's obvious look but don't touch right. But the owner versus contributor battle is where the exam in real life gets tricky.
It is the most common point of confusion. A contributor is extremely powerful. They can build virtual machines, delete databases, wipe storage accounts. I mean, they can do almost anything to the technology itself.
But there's one thing they can't do.
They cannot give anyone else access. They cannot hand out keys. Only the owner can do that.
I like the analogy of a contractor renovating a house. The contractor the contributor can tear down the kitchen wall, install a new sink, paint the ceiling.
Yeah, that's perfect. They can do all the work inside the house.
But they can't just give a copy of the front door key.
To their friend exactly, and that separation is vital. You want your developers to be able to build fast, but you don't want them bypassing your security governance, by just granting access to unauthorized people.
And these roles don't just exist in a vacuum. Rawat talks about scope. It's not just what role you have, but where you have it.
Think of scope like a set of nesting dolls. You have the subscription on the outside, that's the big container. Then you've got resource groups inside that, and then individual resources like a specific VM inside that.
So if I'm an owner at the top, at the.
Subscription level, you are the god of everything inside that subscription. Yeah, every resource group, every database. But if I only make you an owner of one specific resource group, you can't touch the one next to it.
So permissions flow down, yes.
Which is why you should always assign permissions as low down the hierarchy as possible. Don't give subscription level access if someone only needs to manage one database.
Finally, what happens when the built in roles just aren't enough? The source mentions custom roles.
Sometimes you have a weird requirement like I need a user who can restart a virtual machine, but cannot delete it. There's no built in role.
For that, so you have to make your own.
Exactly, you write a custom role using JSON. It lets you pick and choose specific actions from the Azure library.
And there was a piece of trivia here that felt important, a hard limit on how many of these you can make.
Five thousand. You can create five thousand custom roles per tenant.
That sounds like a lot.
It is. If you need five thousand custom roles, you probably have a management problem, not a technical one.
You're making things too complicated, right.
But interestingly, Rowat notes that for sovereign clouds like Azure China or Azure Germany, that limit drops to two thousand.
Just a little detail to keep in the back of your mind if you're working globally.
It shows that even the cloud has physical limits and different rules based on the region.
So let's bring this all together. We've gone from a blank CSV file, populated it with users, sink them across a hybrid bridge, and finally lock them down with RBAC policies.
It's the full life cycle of identity. And what I like about this source material is that it really emphasizes these aren't just exam topics. This is the daily bread and butter of an admin. This is what keeps the lights on.
It really reinforces that idea we started with in twenty twenty six. You aren't configuring ports and switches as much as you're configuring people and permissions.
Absolutely, the identity is the perimeter.
Now, before we sign off, I want to leave the listener with the thought. We talked a lot about automation today, dynamic roots, self service, password resets.
It's all about speed, speed versus security.
Exactly if you automate access, say you set up a dynamic rule where everyone in the engineering department automatically gets contributor access to your production environment. What happens when HR types the wrong department into a new hires file.
You've just automated a security breach. You've given the keys to the kingdom to the wrong person instead without a human double checking it.
Right. As we automate more, the blast radius of a simple typo just gets bigger and bigger. It's something to chew on as you build out your own policies. Trust, but you know, verify.
Your automation couldn't a set a better myself.
That's it for this deep dive into the gatekeepers of the cloud. Thanks for listening, and we'll catch you on the next one.
Goodbye everyone,