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