Azure Master Class v2 - Module 2 - Identity

Hey everyone, welcome to the identity portion of the master class and the V2 version of this. Identity is critical. When we think about the world today using resources, our digital identity, well, that is the security perimeter in modern systems. Most of the applications we access no longer live in the confines of our network. They're on someone else's network. They're out there accessed over the cloud. And so it's the identity that is the key to opening up our access. So identity is more important than. Ever, when we think of any kind of modern computing and we think of identity, it's not just users, it's devices, it's applications. We're going to explore all of the different areas of that. So think about what are some of the basics around identity and then what is Active Directory domain services versus Azure Active Directory? Thinking about authorization, controlling access to applications that trust our Azure Active Directory through things. Conditional access. How can I have strong authentication with multifactor authentication MFA and passwordless? How can I get permission just in time? So I want to remove credentials and permissions that I'm not using and only get them when I actually need them. And we'll look at some other things as well. Things about hey how Azure AD relates to subscriptions, Federation, access, reviews, just them all up understandings of identity. So why do we need identity? Well, for any service, wherever I'm accessing, being SharePoint or exchange or Azure or third party SAS applications, I have to be able to apply a principle of least privilege. I only have permission to do the things I absolutely have to do at that moment in time to perform my function. And again when we talk about. The service, the principle. This could be a user, it could be a machine, it could be an IoT device, it could be an application. Doesn't matter what it is. I want to be able to uniquely identify the principle that's performing some action now. Don't like shared accounts? We've shared accounts. I get no visibility into, well, who actually performed that action. I can't audit and I can't be granular because if I'm sharing. Account. That account has to have the sum of the permissions of all the different actors that may be using it. So I want this least privilege which means every. Principle. Every actor has to have their own unique identity. And then what I'm going to do is I'm going to give certain actions, and typically we take actions or permissions and we group them together into roles. And I want to assign that to specific security principles via user, a group, A device, an application. At a certain scope, so we don't just think least privilege in terms of what I can do, we think of least privilege in terms of what I can perform those actions against. Now we're going to focus on the security principles when we talk about Azure Active Directory, where those identities actually live. Any act to remember should be uniquely identifiable. That's a core tenant of everything we're doing. And if I think about, well, I need identities. I have to have some central storage of where those identities live and then where those identities live. Would be responsible for making sure some actor is allowed to use that identity? Or is that identity through maybe knowing some secret or having some private key associated with certificate and then controlling, well, what it can then access? So if I think of those things together. I could think, well I need an identity provider, so I have the idea of an identity provider. And they're identity provider is responsible for storing. Those credentials I'm going to have credentials. That has some way to authenticate I prove I am that credential. Maybe it's got some secret like a password? We're used to that idea. And then what will happen is various applications. Will trust that identity provider. For its. Control of access. So hey, I'm gonna trust the identities in this identity provider. And then once that's told me, ohh here's a token for this person. I trust his identity provider to have done a good job. They've got a token, I know it did the right checking, and then I can control what can it actually do. Some roles within this so this identity. Would then have certain roles for this particular application and then that person. Or device or application? Would authenticate I prove they are allowed to act as that identity by knowing this secret by having that private key? And then the identity provider will give them a token. So it will give them a token because they've proved. They're allowed to use this identity and then. They will give this token. To the application that trusted identity provider. And that's the key idea when we think about this and I drew one application, but what you're typically going to find is you have many applications. Trusting the identity provider. So this is the key point. I need this central identity provider that's going to have all the identities that. Actors, users, devices, apps will be able to authenticate against to get tokens to then use to authenticate, and then be authorized for different sets of permissions against apps that trust our identity provider. So the whole thing here is I have to have this central identity provider. Well, there's actually some movement when we think about this, because what's happened is, do I really need an identity provider? There's a whole decentralized identity movement happening right now. It's really gaining a lot of momentum. The idea really is is the user. Becomes the center of that picture. If we go back to that whiteboard, what's in the middle? What's in the middle is the identity provider. It holds all the power. It holds the identity. So technically it could delete that identity. And then I lose access to all my apps and all my data. You could give it to someone else, it could do a poor job and leak my credentials, and then someone else could do things with it. It controls maybe what the other apps can see. So do I have great control of my information about me and my data? Maybe not as good as I would like it to be. And so the idea of decentralized identity is it puts the user in the center of that picture. So the idea becomes the user or the other entity doesn't have to be a user, it could be an organization. But the entity owns their own identity. It controls the information shared and then other entities can issue. Verifiable credentials 2. That identity they would be the subject that the subject can then choose to present to other entities. They would be verified receiving parties, but they can control as the owner of that identity the user can control. Maybe what identities it wants to share, it can control maybe which parts of that. So maybe it doesn't expose how much I earn, but it can expose. Yes I am employed by this company. It can expose, yes this person is over 21 but doesn't expose their date of birth. So we can do a lot of things with this. And this is all rooted in some kind of trust system because when you take away the IDP because the IDP was the trusted party. If there's no direct relationships, how does that receiving party, the verifier, know well this verifiable credential? This attestation from some issuer really came from them. How do I know you are really you? Says a whole trust system that forms the foundation of this. So this is all built around an IDP if I think about decentralized identities. The whole point of decentralized identity is in the middle. Is the actor, so I'll say me so in a lot of ways I am my own identity provider. But the whole problem with this is. No one trusts what I say about myself. People trust other organisations. They trust government, they trust banks, they trust educational institutions. So if I just tell some verifier, Oh yeah, I'm this age, they don't trust you. Same in the real world. It's not really what I say about myself, it's about what some trusted party, my driving license says. That's what people trust. And so the point here is we have the same idea of some company, some government. Institution, but they are the issuer. And all of these different parties, we're going to have something be called. A distributed, sorry, decentralized identifier, it did. So everyone has this decentralized identifier. So this is not a decentralized identity as a difference between what these things mean. So decentralized identifier and what's happening is there's some trust system. Now the actual trust system can vary. Some of them are built on blockchain, some of them are built on combinations of layers of interplanetary file systems. Which is then routed in a blockchain, some of them based on owning a certain domain. And there's different ways to do this, but they're all rooted in some trust system. And now what will happen is this issuer. Well, they will create a verifiable credential, that verifiable credential they create. They will make some claims. About the subject, remember the subject is me, so I am the subject. And they are the issuer, so they're the issuer of this. Then they give it to me, so they give me this. And I will then store this in my digital wallet. And now when I want to use it, there's some verifier. Maybe it's someone I'm trying to get a job at. Maybe it's. Doesn't matter. It's a coffee shop. They're going to challenge me. And they're gonna want a verifiable presentation so I can now pick which of these verifiable credentials are in my wallet do I want to share with them. So I now have all the choice. I can say, well, I'll present this one. I'll sign it with my. Credentials that I have my decentralized identifier and what they can do is they have a did as well, so they have a did. Which is rooted in the trust system and when they get this credential they can go and consult the trust system to look up this. Did look up my, did verify they have to write cryptographic materials and validate, hey this really did come from this issuer. I really am me. So this idea of decentralized identity is using decentralized identifiers and did documents as a whole set of things around this. I did an hour and a half video all about verifiable credentials, but this puts. The actor in the middle, not the identity provider. I have complete control now over my identity, so this is a direction this is happening. It is gaining a lot of momentum, so overtime you definitely will start to see more and more about this idea of hey verifiable credentials. So this is what it is. There is no centralized IDP. I have my wallet which is just some user agent, some application on a device. It might be backed up to the cloud, but I maintain the control of the identity and that's the key part. So just a little bit of a segue just to make sure you understand that typically what we do think about essentialized identifier identity provider and that is what Azure AD is, but realize this decentralized identity movement is happening. But we're not really going to focus on that anymore. Microsoft Entra does have a solution. For those verifiable credentials, both issuing and verifying them and we'll we'll see bits of entra as we go through this module, but we are going to focus on this module. Around a centralized identity provider. So if you want to think about a centralized identity provider. Enter Azure Active Directory. Now I will say I mentioned the word entra. Microsoft are moving a lot of their identity solutions under this Microsoft ENTRA umbrella. So Azure Active Directory, if I think about the verifiable credentials, some of the identity governance solutions, more and more things that are identity related are going under entra. They purchased cloud knox and there's an entra permissions management set of solutions. So if you hear Entra, it's an umbrella for a lot of identity related. Microsoft Technologies, so this is the idea. But Azure ID is the identity provider for, well, Microsoft clouds, yes? So if I'm using Azure if I'm using Microsoft 365. So exchange online, SharePoint online teams if I'm using dynamics 365. It all trusts a specific Azure AD instance that I have for my company, but also third party SaaS applications software as a service apps. It could also be applications I write. So many, many things now will leverage these. Identity providers for the cloud. Now before I go into I guess more detail about this, it's important to understand Azure AD is not Active Directory domain services in the cloud. It is completely different. I think marketing said, oh, people like Active Directory, we'll use that name. But it's not. If I think for a second, if I actually look at Active Directory, so the Active Directory we know and love. So if I think of Active Directory. And it's full name is Active Directory domain services. So what do we have with Active Directory domain services? Well, it speaks. Protocols like NTLM, it speaks Kerberos. If I want to interact and query it well, I can use things like LDAP. It uses a huge vast range of different ports to communicate because it's designed to run on a certain network, so I'm not that worried about ports I might need for this to actually function. It supports organizational units, so I have OUs, so I have a structure. And I can apply group policy object, I can do delegation at those levels. And that's great for when I'm on premises, when I have that. But if I then start to think about, well there are those cloud workloads, so I am starting to use. Some SaaS application I don't want to have to have a separate identity, so one of the things I could do is I could set up some kind of federation solution. For example ADFS but they have a third party ones and I could federate. And what federate lets me do is now this application will trust tokens generated from this federation service. It typically will be SAML or WS fed if it's more Microsoft focused. It's trusting this for the authentication and then it would give the user some token that it would use, but it's a fair amount of work for this. I have to maintain this ADFS infrastructure. I have to maintain certificates with the people I have federations with. I have to have Internet facing services. So this although is a solution and it definitely avoids me having to have separate credentials on these SaaS apps. There's a lot of work to maintain these federations. So. If I think in this new world of cloud applications and wanting to, hey, use the cloud for things. The solution is therefore Azure AD, so when Azure AD does. I think of Azure AD. And it is not. AD in the cloud? Forget about that. Azure ID is all based around HTTP. HTTPS. So it speaks web protocols. It speaks things like. Open ID connect for authentication, it speaks off 2 for authorization. For delegation, it's speaks SAML, it speaks WS fed. So these are all great to use over the Internet where maybe only have port 443 open. To me it's designed to speak cloud and that's really the key point around all of this. So it's speaking cloud and then when I think about all these other cloud applications. This could be Azure, this could be Microsoft 365 and dynamics 365, whatever that is third party SaaS they all. Contrast the Azure Active Directory. There were thousands of apps, both Microsoft and 3rd party that trust Azure AD. So now it's very very easy for just me as a user. Hey I just I just communicate to my Azure AD. I get tokens from Azure AD and I can use any app that might administrators have set up to be available to me. So I have a huge amount of control with that. And this is really the key goal around this cloud service now. It doesn't have organizational units. There's no hierarchy I can leverage in there. I can add my own. Applications. I can even publish on premise applications via Azure AD, so there's a huge amount of things I can do with this. But this is the key point of. A cloud identity provider. It speaks cloud and it's making it really easy for me as an organization to make these cloud services available to all the people in my company. Now when I think of Azure Active Directory. There are different skews. There's licensing associated with it. If we quickly had a look at this, come on, open up. And we go, so if we look at the licensing for a second. I'll just jump over. Ohh. doh, it's great where does this new big screen thing, but it behaves weirdly sometimes. So we'll see. There's actually this idea of a P1 and a P2 license. There's also free, so if we look at the. Different SKU's available, it will show us the features. So absolutely I can just do 3. There's also the idea of, well, there's free and if I'm a global administrator, I I have all permissions over that Azure AD instance, then there's the idea. Well, maybe I have Office 365 deployed and I'm using Office 365 applications. Then we have this Azure AD premium P1 and P2. And it's really those P1 and P2 features that start to get you a lot of the enterprise functionality now. You'll see. Even with free, if I have this thing called security defaults, I can still do things like MFA using a special Microsoft AUTHENTICATOR application. Global administrators could also use a phone call as a second factor, or SMS. But it's when I get to the Azure AD premium one and two skews. I get a lot of the power. I get the ability to do things like conditional access. That's a huge one we're going to talk more about. And then the P2 is really those enterprise scenarios where I think about, well, risk based, so identity protection, understanding the context of what something's being done so I can use that for conditional access. I get information about risky sign INS or risky users. I can do access reviews to check or do I need this app? Do I need this group membership? Do I need this role? Giving sets of entitlements via packages just in time elevation. So two gives me additional functionality. Beyond. Just the basic how am I going to do MFA? I want to do some basic conditional access. And so we have those different licenses and when the way I use those licenses is actually at a per user level. So for each user. And I could do it by a group as well. So I think my Azure AD has users in there, it has groups in there, it has devices in there. At a per user level I set the license so I might have some user. That is P1, I might have a different user. Well, they need a P2 license. Now, I could grant those licenses directly to the user. I could grant them via group memberships. How you in this group you'll sign a license to the group and then the people will just get those. There's different ways I can think about organizing it, but Azure AD becomes that central identity provider. Now how do you get it off? This is Azure AD. How do you get Azure ID? Well, you probably have it already if you're running Office 365, Microsoft 365, Dynamics 365, you're using Azure. You have Azure ID because Azure ID is the directory service for those clouds. There is no office. Azure ID there is no dynamics Azure ID. It's using Azure ID so you have it already. I can manage the objects through the Azure portal. I can actually manage it through the entra portal as well. I should really update this slide. I cannot manage aspects of it through the office portal. If I'm mainly an office organization, it does expose a lot of the aspects of it through the office portal as well. I can create additional Azure AD tenants, I can really create as many as I want. By default they'll have a something on microsoft.com name, but I can add a custom name as well. So if I think about I drew this idea of Azure AD. Well, the reality of this actually is your Azure AD is some tenant specific name, so you create an instance a tenant of Azure AD. And it would be I would pick the name, it would be my organizational name. So maybe I would pick for example I just I'll just say tenant so I have tenant dot on Microsoft. Dot com. I can optionally. Add custom DNS names. SavillTech.net, savilltech.com, whatever you want to do because then the users well, their usernames. Will have this domain name at the end of it. [e-mail] I don't want it to be John at Savile Tech dot on microsoft.com so I can go and add custom names to my tenant. So if we jump over for a second. Now there are two portals. Now I can go in the Azure portal. So you can see I'm in the Azure portal, I mean portal.azure.com here at the top. And I could go and select Azure AD from the menu bar. I'm in Azure AD and I can see the basic overview information of my tenant. And one thing I will say why I'm looking at this overview, pay attention to your secure score. If you're starting out, remember identity is the new security perimeter, so you want to get your identity as rich and as full features as possible. So go and look at your secure score. It will give you things. That impact your score and it will help you do it. So I can go and click on it and it will tell me how I should implement this steps to do it. So if you're not sure where to start, hey go and look at the identity score, go and look at the things that have the biggest impact to improve your score and think about all how do they fit into my plans. So I can use the Azure portal, but there is also. This entra portal, so if I go to entra.microsoft.com it brings together all of the identity related services. So if I go home you can see what it's got. The Azure Active Directory, it's got the entry permissions management which was Cloud Knox. It has entra verified ID which is about the issuance and validation of verifiable credentials. It has workload identities. And that workload identity lifecycle workflows, so I can actually do things automatically. Identity governance actions. So it has a whole set of these services just available through this nice new portal and I can go through here. I can see an overview, Oh yeah, I can see information and the same thing, it's the same information. But if I was just to jump back for a second to the Azure portal and just go home and create a resource. If I search for Azure active. Directory. Now it's. We can see Azure Active Directory. If I go and click Azure Active Directory, I could go and create a new Azure Active Directory. And it's going to say, is it Azure AD or is it Azure AD? B to C we're going to come to the B to C later on, but this is you would create it the same way there's going to want a name. What's my company name? Or I'll say Savill tech? What is the initial domain names? This initial domain name? It's telling me whatever I type is going to be. Then dot on microsoft.com and then once I create it I could then go and give it a custom name. And the way we do the custom names is once I've created my Azure AD, I'm just going to go to entra. As part of my Azure AD. Go to all of my different settings I have available to me. But look at my settings. I have domain names so I extend it out settings and then domain names. I'll be very honest I'm still finding my way around some of the entra things so I may struggle occasionally. But I can go to my domain names and I can add. So you can see here I added savilltech.net. Now the way you add one of these is you say hey I want to add a custom domain you type in whatever it is on board to azure.com. I'll click add now after I do this I will then have to verify I really own that domain O what it would make me do is go and create one of these two records. And then it will go and check did I actually create that record, because if I can create the record. It proves that I own that other name, so I can't just go and add any name I want. If I want to add a custom name, Microsoft want to know I actually own that domain name. So it's like, well if you own it, you'd be able to go and create this record for me. So go and create this record. If you can create the record. I trust you, you are who you say you are. So that's the key point. So I can create additional Azure AD instances. Most of the time you'll have one Azure AD instance. For your main organisation. Now, you may create a second instance maybe for experimentation of certain things, but I'd be careful of having too many because I want to try and avoid having lots of different identities for my users. So typically we'll have this one identity even across maybe production and development. And I'd only really have a second Azure ID. For experimentation purposes, I want to try out this new feature or do this new thing. And I'll have a very small subset of users on there. So how do we get Azure AD? You probably have it already. Now within your Azure AD you have objects. Now we talk about identities and identity. Is any object to which I can authenticate against I can prove I am or have the right to be that object. There's also things that I have a certain data available so we have users. Users are obvious. Human being. And I can have those in my Azure Active Directory. See if I go to my Azure AD over here. I can go and look at my users. And I can see and I could absolutely go and create a new user. Now it might be I want to create a user actually in the Azure AD, it might be I want to invite a user from an external company. So I don't want to invite an external user or create a user unless I want to create a user and then I would just hey type in information notice. Their name can be either that custom name I added or that default name. But I set my default as my custom, which is why it's doing that. By default. I'd give it some information. I could give it a certain group memberships. I'd give it certain roles, enter information about that user and then create them. That's one option. Maybe I need to bulk create, so you'll also see this idea of bulk operations. And we've bulk operations, I can bulk create, bulk invite I external people and bulk delete. If I was to say bulk create, what it's going to do is give me a template for a CSV file into which I would then add the attributes of the users I want to create and then I would upload the file and it will bulk create all of those different accounts. So it makes it very easy to do those bulk type operations. Now as we're going to talk about most of the time you're users probably come from Active Directory on premises, but I may still have some cloud only we have groups. Groups can be assigned or dynamic. So what does that mean? So assigned is where I'm specifically putting. Identities into the group John, Bob, Bill. Dynamic is I'm going to have a rule and the rule says, well if this matches, maybe it's an attribute on the user, then you're a member. So if I want to look to groups. Supposed to say new group. Well, first there's two different types, so security. This I can use as part of access control list, IE permissions to resources, give it access to an application, give it access to assign a license. I could put users, devices, service principles, other groups as members of security or. I could create it as type Microsoft 365. There's Microsoft 365. It's there for collaboration purposes to office resources. Hey, I want to share this SharePoint site. Hey I want to collaborate on this calendar, this folder and then only users can be members. So most of the time we'll be creating security groups and then I have the membership option. Assigned I'm going to put people in it or dynamic user or dynamic device and if I select dynamic well then I enter a query which will govern who is added into the group. So it might be based on, hey the city you live, maybe I have these geographical different groups that access different resources, maybe it's a menu for a certain cafeteria in that region, maybe I have departmental and I could say well if you equal this value. Then your Member of this group and you can see I've done this. So if I looked at my groups. You can see I have the group types and then I have. Is it dynamic? On this right hand side, or is it assigned? So if I look at my dynamic group, all cloud PCs, that's fine, a slightly different one. There's another dynamic 1. IOS Devices, Justice League. So my Justice League. Well, I can see there are members. And the dynamic role. Was if their job title. Matched hero wild cards. It could be hero or heroine. Even one of those, hey, if you're a hero. Then you're added to this group and notice I could then assign things like licenses. So I don't have to individual ad licenses to users, I could say hey if you're a hero you get Azure AD premium P1 or EMS E5 or whatever ones I have in my tenant. I could then go and assign to those individual. Or assign by the group itself, so we have different options around that. So different types of groups. We have enterprise applications, Azure Resources I service principles and this is going to be very very common. So we always think about users and groups, but the reality is these applications. Well, if I. Have this federation relationship in my tenant I they're trusting me those applications will actually have a service principle inside my Azure AD, so applications have their own. Object as well. Azure Resources in my Azure subscription can have something called a managed identity. So it's an identity that lives in the Azure AD that is maybe unique to that individual resource if it's system assigned or different Azure resources could share a certain user assigned managed identity. But those identities are just service principles and they live in the Azure Active Directory, so I may absolutely have applications in my identity provider my Azure AD. As well. So managed identities devices. This is becoming more and more common as well. So I drew the idea of a person. But absolutely we have devices. Now these devices can run in different modes. It could be registered. If it's registered, it's known to the Azure AD, which means it could be then managed by. Things like intune. Some mobility solution to actually perform management of the device. We call the mobile device management MDM solutions. So I could use MDM solutions, but I cannot authenticate or log on to that device as an Azure AD user, so I'm going to authenticate. We sent like a Microsoft account. Or I could join it now if I join it. Well, now I can actually auth. As Azure AD accounts. Register would be useful for bring your own device. It's the user's own device. Hey, they're gonna access corporate resources, so I wanna be able to apply mobile device management, make sure it's not jail broken, make sure it's patched, et cetera, et cetera. But I can't really join it because it's it's their device, whereas join hey, it's an actual corporate owned device. Registered would work with Windows 10 Devices, iOS devices, Android devices, Mac OS devices, Ubuntu 20 and above devices. Joined is only going to work with Windows 10 and above devices and Windows Server 2019 if it's an Azure VM and if I'm running a certain extension. So the joint is a lot more locked down because it's becoming part of that Azure AD. Well, there's also a hybrid option. With hybrid, the device is actually joined to your regular Active Directory. But then you have a certain process we'll talk about that's going to synchronize and therefore register. Your device with Azure AD as well and then I can get those MDM and some of those other benefits there as well. So there's different options available to us. And then additionally. Stuff metadata about applications. And what we will see is most of the time your users and groups are just going to come from Active Directory O how do they come from Active Directory? So we have Azure Active Directory connect, Azure AD connect. AD is always the source of truth and this is really important to understand in all of these relationships. When you have a did and you have Azure AD, it often gets confusing and people will say, hey, how do I replicate objects from Azure AD to AD? You don't. Active Directory is always. The source of truth. The flow of objects is that away. Now there are a few things I can hybrid exchange. There were certain password right back capabilities, wait, it will flow that way, but 99.9% of what's happening is that away even if I attach. HR system and the HR system connects to the Azure AD provisioning service to create objects. What actually happens is the Azure AD provisioning service then talks to the replication engine to create the object in ad, which then syncs into Azure AD. So AD is always this source of truth. This is really the key point. And what's really happening with this Azure AD connect? I can think of. It runs in a VM or it runs on OS Windows OS instance? And there's a sandwich. There's a connector space. Which represents the objects in my Active Directory. In fact, I do it that way. There's a connector space that represents the objects in Azure AD and then there's a meta bus where they joined together. And let's say there is a very minimal flow that way, but it's very very small. Most of the flow is that away. So this is Azure AD connect. There is also. A cloud version now there's also an idea. Of Azure AD connect. Cloud sync and that takes this engine and runs it in the cloud and all I have to do is install these very lightweight agents on a few machines on premises. That's just so it can access and read things, but most of the actual processing and the power is done in the cloud. So it removes me having to maintain this Azure AD connect that can sometimes be thought of a single point of failure because. And Azure AD, we'll only talk to one Azure AD connect instance. Well, it can also talk to a staging like a fullback that I would have to manually promote up, but for the most part there's just this one instance, whereas with Azure AD Connect cloud sync, so it's one of them. Or the engine runs in the cloud and I have multiple agents on Prem that it can use to go and communicate with. Now they've all some different models for how I can use this. So Azure ID's was the source of truth. And Azure ID instance can only sync from one Azure AD connect instance. An optional staging, but what is interesting now. One AD can now sync to multiple Azure AD instances. So what this means is from a topology perspective, imagine I had multiple Azure AD tenants, it used to be I couldn't handle it, but if we now look, there's a new scenario. Where I can actually run multiple. Azure AD connect instances. Each instance only talks to one Azure AD, so the same rules still apply as an Azure AD will only talk to one Azure AD connect. But I could actually now sync to multiple Azure AD instances by using multiple instances of Azure AD Connect. Now only one Azure AD connect can write back. That's why it's only one green arrow going from Azure AD to AD. But what's really nice is those Azure AD's could be in different clouds. Now what does that mean? What does different clouds mean? We talk about Azure all of the time. But Azure is made-up of really regions. There were different groups of regions. There's the Azure commercial cloud that we all think about. There's also a Gov cloud that only government agencies are allowed to use. It's completely isolated data centers. It's a completely isolated set of Azure AD instances. There's also Azure China. So there are different clouds of Azure. It's just we typically think of commercial. But what I could do is if I had a Gov tenant as well, I did work for the government or I am a government agency, I might have my regular commercial Azure AD tenant and I might have a Gov Azure AD tenant where my Gov Azure Resources or Gov SAS applications trust. But now MY one AD could sync to both of them. So that is now an allowed scenario. So that's a very nice thing. So we have our Azure AD connect. And cloud Sync provides that cloud based version of that. We can quickly see these. So I actually have both running. Now the way I have both of them running is you can't replicate the same object. If I look at my Azure AD connect. We can see my Azure AD Connect is enabled. But what I did, I excluded a specific OU from replicating with Azure AD Connect. And then what I did with cloud sync. Is I only sync that one OU with cloud sync so I could technically use them together? But what's important is you can't have the same object syncing through two different means O only the objects in the cloudy OU sync using Azure AD Connect cloud sync and cloud is explicitly. Missed an excluded from my regular Azure AD connect. So that's the key point. So I have both of them running just so you can kind of see the but. Azure AD Connect is that engine. I can see different capabilities that I may have enabled, but I can see hey, my last sync was less than an hour ago. I'm using password hash sync which will mean more in a second and I mean I'm pretty good shape. So you got Azure ID, we've got AD. They're connected. What I do that? We have authentication, we have authorization. Authentication or auth N is about proving who you are. I prove who I am because I know something like a password. I prove who I am by something I have. Maybe it's my phone, maybe it's a USB token. I prove it by something I am, a biometric, a fingerprint, a 3D face scan and iris detection. Now, once I've proved who I am, authorization or auth Z is what I can do, what I can access, what actions I can perform, and both of those things are critical. Now for Azure AD, there's both cloud authentication, so cloud. Nothing against Azure AD directly and it's supports federation. So the first one we can think about is password hash sync or the password. I mean the point of this is the password exists in the cloud. So how does this look? So if we jump over. And we'll start a new little whiteboards. We'll come over here. So we have Azure Active Directory. So I've got my Azure AD. And remember what happened is let's say we had. Our on premises Active Directory. Oh oh Green, we had our on Prem ad. I'm going to get lazy. I'll just write AD but mean AD domain services. I remember I had a user. The user. I had a user and I'm syncing that user using Azure AD Connect or Azure Connect cloud sync. And so the user has an object up here. Now in Active Directory, that user has a password hash. That's how the authenticate you type in your password. It goes through a hashing algorithm and it's compared against the hash stored in AD. So what I can do is one of the options is I can turn on. Hash of the hash replication. So it takes the hash, runs it through. Individual thoughts. 1000 iterations of Shaw. I can't reverse. It creates a hash of the hash and then I can replicate that up as well. So now there's a hash of the hash of the password in AD. So that would now let me do as the user. Is if I'm here. Well. I can send. My credential to Azure AD, so doing cloud authentication. Because Azure AD is performing that check of I am who I say I am because it's comparing the credential that I send with the credential it has stored in itself. So this is called. When I'm doing this, it's password hash sync because I'm syncing. The hash of the hash now realize as well. If it was a cloud user, I just created them directly in Azure AD. They're not syncing, but they would have a password. They'd have their own hash up here, so I'd still be doing cloud authentication there as well. So that's one option. This is the nicest option. It's using cloud scale, it's not relying on anything else. It's gonna be the most performant. And there's a lot of benefits in having this hash of the hash in Azure Active Directory. There's things it can do to check. To make sure it's not been some link, there's not been some bad thing happened to my credential. Now another option, I'm going to run through these now we go back to the slides, is I have domain controllers that represent this Active Directory. They're what power the actual Active Directory. So I have these DCS. Maybe I still want my authentication to happen against my on Prem domain controllers. There's a few things that password hash sync doesn't handle. Exactly the same way as on Prem logon hours, for example. Or maybe there's a scenario of well. I don't want hashes in Azure ID, but that's not a good reason and we'll come back to why that's not a good reason. Maybe there's also things like password expired I want to be enforced, maybe account lockout, so I want the authentication to happen against my domain controllers. So what I can do here is I can turn on something called pass through. Authentication through pass through authentication. I'm still setting the credential against Azure AD, but then Azure AD writes that authentication request to a service bus. There were then agent sitting here that polled this. And we'll take that request. They'll check it if it's good. Yep, that's the correct password it will send back. That success. Azure ID will then create the token and they're authenticated, so authentication still happening against the cloud. I'm sending my credential to the cloud, but it does involve that on premises as well. The other option is. Maybe running some federation service? This could be ADFS. Could be a third party, whatever that is. It's now a different flow. Now what happens is I actually send my credential. To my federation service. It will then go and check. And get authentication against whatever my identity provider is, it will generate a token like a SAML token. It will then give me that token back and then I take that token. And I would use that to then get a token from Azure Active Directory. So in all of these scenarios ultimately happens is Azure AD creates multiple tokens and gives it to me that I then use with applications. But how I do that initial authentication can vary. So those three options we have this password hash sync. We have passed through authentication. And this well, is federation. It just depends on where I'm sending that credential for the initial authentication request to go through. Now I did them in a certain order, which is really the recommended order. Password hash sync is the better option. If I do have concerns over that, well, I can't lock out or some of those scenarios, or I don't want the password hash in Azure, well then I could use password authentication. Federation is really just not recommended today because it doesn't buy you very much. We'll see later on that what's really happening is. Yes, there these benefits, but when I was federation it's only used for that initial authentication. After the initial authentication, when I actually get is I'm going to refresh token which is then used for every other authorization to every other application. So Federated services only used for that initial authentication. It's they're not used for any other access I want to do with things. It's probably not doing what I think it's doing anyway. Now. I said. Send the password hash sync anyway. And the reason is when the password hash exists in Azure AD, there are things that Azure AD can do. For example. Yes, possible hash things required for cloud authentication, but also Azure ID is going and looking for linked credentials. It's scaling the dark web. If it has this hash of the hash, even if I'm not using it for authentication, maybe I'm using pass through, maybe I'm using federation? I can still opt to send the password hash to Azure AD. And then if it has this, if it finds elite credential on the dark web, it can compare it to that hash of the hash and say, hey, you're credentials actually leaked, it's actually your password is there on the dark web and it could alert you. It could maybe force an MFA and it will stop a breach replay attack where they're trying to reuse that credential. It's also a good break glass, disaster recovery authentication. If one of these break, maybe my Federation service breaks or my domain controllers have some availability issue I can switch. To use cloud password hashing authentication as a backup authentication mechanism. There are various smart lockouts. They're these automatic defences where it would lock out the Azure AD account before it would log out. Maybe an on premises account. So there's a lot of benefits I get from doing this. So it's always recommended to send the hash of the hash and it is a hash of the hash even if I'm not authenticating with it. I can perform. Um. Uh, a staged rollout if I was using federation. I can move group by group to go to a cloud native and all of these methods can use seamless. Or single sign on. And what that really means is if you think about my users at a certain device with federation. I'm authenticating against my regular on premises Active Directory for example. So I already have a Kerberos token for on Prem, so I can obviously access on Prem resources and what single sign on does because Azure AD is trusting this. For the authentication, well, it's just automatic generating me a token I give to Azure AD so I get a single sign on experience. I'm never prompted for another credential, so I get a single sign on. But if I'm using. Password hash sync or pass through authentication. They're called seamless sign on and what this does is behind the scenes and it works in two different ways, but for older clients. Azure Active Directory actually pretends it's a Kerberos client. It goes and gets this special Azure AD single sign on account object in your ad and so I actually authenticate using Kerberos to Azure AD which seems bizarre but it trusts the token from Kerberos or for newer machines I actually get primary refresh token. But whatever the scenario for all three of these for the user if I have line of site to Active Directory on Prem and want to corporate join machine. I get transparent access to both on Prem trusting resource and cloud based resources and we can see I've got that in my tenant. So when I go and look. We can see I've got seamless sign on. Enabled. So even though I'm using password hash sync if I'm on a domain joined machine. My on premises domain name. I can seamlessly access, I won't get prompted for credentials. I just get this very nice sign on experience. And you you want to enable this because you really do want to give users a great experience and make sure you go and enable seamless sign on. But again as you start to move to Windows 10. Windows 11 devices that can have these hybrid. I actually get primary refresh token for Azure AD, so it doesn't even have to go and use the old Kerberos based authentication method at all. So there's some really nice things I can do there. So password hash sync. Always recommended if I'm using something else, which ideally get away from get to the cloud native Azure AD even if you are. Hey, have it enabled. Helps give me that identification of leaked credentials. Helps give me protection, helps be that backup auth method if my primary has some kind of problem. Now authorization is always against Azure Active Directory and we're going to see more about that. But if I think about no matter how I'm authenticating, however I'm proving who I say I am. Whether it's setting the credential to Azure AD, whether it's sending it to a federation service once that initial authentication is done. The actual control of what I'm then allowed to use. It's always Azure ID. Doesn't matter. Once I've got that initial token, everything is now through. Azure Active Directory. Now. Those administrative units. Many built-in roles exist for both Azure AD for Microsoft 365 services. And then roles can be given to users and potentially a special type of group. So the whole point here is I want to I've proved who I say I am, but now I need to do certain things. So, OK, great. How do I do that? Complex applications may have thousands of permissions and different types of actions. I don't want to individually grant permissions and actions to individuals. Instead, what we think about doing is we create roles. So in my Azure AD. Have roles. And evolve is really. Set of permissions. Whole set of permissions. And what I'm going to do is to a certain identity in that Azure Active Directory, so with certain. User, but it's primarily users. There is a special type of cloud group that does allow me to grant roles for Azure AD regular Azure. Roles I can give to groups, but Azure AD roles normally I cannot assign to a group, I have to assign it to individual security principles identities. But there is a special cloud group that I'll show you that does let me assign. So I have a user or I have an identity. Or a cloud group which has got people assigned. It cannot be dynamic. People have signed into it. And that role? I assign. Two, that security principle, but the key point is when I assign that role. Well, I want to assign it with a certain scope. Traditionally, the scope was global. It was the entire Azure AD tenant. That's all I could do, so it was global. But we do now have the choice or. We have single administrative units. So I have a role, I grant it, and it's set at a certain scope. Again, by default that scope is going to be global. It's everywhere. So if we look at this quickly. I can see I'm going to go back to Entra. I can go and look at roles, so I'm down here. I can see my roles and admins. And I can see there's lots of built-in roles. There's all these different roles, some of them are Azure AD, some of them are related to office, some of them are teams. You can see here. I can create custom roles. So if I look at a role. I think it's assigned to. If I look at the description, these are all the individual permissions. You can see now why I wouldn't want to manually grant permissions. So that way I need these 47 over here. Nope. I'll group them into roles that have a nice logical name, then I'll assign the role to a security principle. And by default this is assigning it at the Azure AD level. So whatever permissions this role has, well. It's all of those matching objects within the entire Azure AD. I can create custom roles if the roles that are there don't meet my exact needs, or I can go and create a custom role where I can specify the exact permissions I want it to have. Now today custom roles are limited. They only apply. Around application registrations and enterprise applications. It's not general purpose, so this is fairly limited today. But if those are the scenarios I want to focus on, maybe I want to limit the type of enterprise app or Pacific actions. Hey, I could create a custom role around that. And then with these roles. I assign it. And as you'll see if I come out of that for a SEC. Ohh. If I. Just pick it and do add an assignment. When I select the target. It's showing me all my users. But it's not showing me groups. Except for, well, it did show me. This group is showed me one group and I have a lot of groups. The reason is, as I mentioned groups. You can't assign roles to unless it's this super special type of group. So when you create groups if it's a security group. You'll see this option. Azure AD roles can be assigned to this group. If I turn this on, notice the membership type is currently a drop down. If I turn it on, it has to be assigned, it can't be dynamic anymore. It's individuals I have to put into it, but then I could assign a role to this, which is that one group that showed I created it of that particular type. That cloud group role demo. So I could then assign it actual roles. I don't know she granted any to it, but I could do it to that group. So that's how I do those role assignments. So this is global. This is assigning to everything there. Maybe I don't want to do that. Maybe I want a more granular assignment. So that's where we have administrative units. So the whole point of administrative units are I can create these administrative units. And into those administrative units I can place specific users. Could place groups. I could place devices. And then I could give security principles like a user a role, but the scope would be only for the objects inside the administrative unit. The scope would not be global anymore. There's a few really really important things about this. So. I can't nest them, so there's no nesting. I can't put an administrative unit in an administrative unit. It's not for ACLs. I cannot give this permission to some resource. This is only for administrative purposes. If I want to give these things access to a resource, I create a group. When I add a group into administrative unit, I am not giving this role permission to act on the members of that group. And that's really important and you wouldn't want that. So if this group had 10 users in it. I don't get this role permission to the users in the group. I would have to add the user specifically as members of the administrative unit. Why is it like that? Well, if I got the role for the members of the group. I would just add users into the group so I could get permission to manage them. I might add an administrative user into the group just so I could then go and change their password. So it's very specific. I don't inherit the members of the group. I can manage the group name for example. I can do attributes of the group, but doesn't give me management of the Members. The people in the group I don't then get to manage them, I have to explicitly add. The people into it. So if for example a group had a whole bunch of users in it, so if there was that user in it, and that user in it and that user in it. Et cetera, et cetera. I can't manage any of them. I would have to add the particular user into the administrative unit, so then I could manage the orange user. But even though all of them are members of the group that I can manage, I can't manage the yellow or the really orange or the purple one. I'd have to add them into the administer unit. Users, groups, devices can be members of multiple administrative units. There's no problem doing that whatsoever. List of roles that I can assign are not the complete set. If we go and look at it we can see. Hey, I'll go and look at my administrative units. I could look at. Now I could do different membership types if I added administrative unit. I give it a name test. I could assign it certain roles and it's a subset notice. There's only a steady, small list of roles compared to the massive list that's normally available. But then what I can have here is I can have a dynamic membership rule. So this one for example is maybe I have office administrators so I could say well if the city. Is this city, add them into this administrative unit and then I would give someone the ability to manage only the people in this administrative unit. Or maybe I've departmental so I would do if the department equals a certain value or. I could just do static. I just assigned the people into it and then I assign the roles. Of that group. So I could give someone, maybe make them a password administrator for the people, maybe the help desk. They could be password administrator for this administrative unit and they could reset the passwords only for that. In terms of licensing, I need a P1 license if I'm doing the administration. Of an AU, but I don't need a special license to be managed by an AU. So in create custom roles, normally I always think least privilege no matter what I do, only give them the permission I absolutely have to have to do the job. Again, we talked about the scopes. Normally it's global, but I can use administrative units as well. There's also a my staff site, so if I do have these lesser permissions, well, I probably want to use the Azure AD portal. The entry portal it's a bit overkill. Maybe I'm just a basic helpdesk or departmental admin. I don't understand all that stuff. So what my staff does? It's a real scale down site that will only show me the administrative units that I have permissions on. And then I can do very basic things. For the objects within that administrative unit. I could reset the password, I could add a phone number. But that's it. It's very limited based on what my role is. So this my staff site is really nice for some very basic interactions that I might want to do. So it's worth noting that's there. So you can go and play. Around. OK. So hopefully that makes sense. Always think just enough permission. Which brings us to privileged identity management. Because those roles I was giving, I was giving this role, you'd have it all the time. I don't like that we don't like Windows. With Windows, we have that whole user elevation user access control. Hey, I'm trying to do something that needs a powerful permission. It prompts you, hey, do you want to do this? People hated it in Vista because it prompted you every four seconds. It's got a lot better, but the idea is I'm an admin on my local machine. But it hides my higher permissions until I need it, and then if a needs to do something that needs those high permissions, it prompts me to elevate U. To that higher set of permissions. Just in the context of that action. And then hey, I lose them again. So this is the same idea. Enables me to elevate up to an Azure AD role or an Azure resource manager I Azure role for a finite amount of time when I need it. I can also use it maybe to elevate myself into a group membership and that group has certain roles for finite amount of time. I have to pre assign the roles. Basically what's happening here is I'm saying I'm going to give you this role to be available to you that you can then elevate up into. So the whole point here is instead of me just having the role assigned all of the time what I'm now saying if I use. PIM. So I now have privileged identity management. And the whole point of there is is a just in time solution. Now my user. Actually. Is given the right to elevate up so I have my user? I'm still assigned a certain role. So I'm given the role to have the right to elevate up. I don't have it by default when I want to use it. When I actually have to do is I have to activate. The role and when I activate it, it's time bombed. Maybe it's for two hours so it's time limited. I can then do tasks associated with that higher role. And I lose it again. So this is really powerful. This just in time capability and. This is really what is encouraged as much as possible if we actually go and look at this for a second. So from here, and actually it's driving me nuts that I've got this other window up going to kill that super, super quickly. You just killed this window. Because it's bugging me. There we go. So. If I go back to my entra for a second. So privileged identity management, this is AP2 feature and you'll see all of the P2 features are under identity governance. So I mean entron and I'm going to go to privileged identity management. And now it breaks into different areas. I can think about Azure AD roles. Azure roles and then this privileged access group, there's an Azure AD role why can do different things? Firstly, I can configure how each role works. So for billing administrator. I can say notice is eligible assignments and active assignments. So there's different ways I can assign. These roles. Eligible. Eligible means let's go to role settings that make it easier to see. So you see the assignment options. I can do allow permanent eligible assignment, so eligible means it's there and I can elevate you to it. I can also just make it active so I'm actually granting it to them so they don't have to elevate you. Maybe I'm still using PIM so I can track it. I can maybe limit the amount of time, but it's just going to be available. If I do edit here we can see activation. It's available for up to maximum 24 hours or I could reduce it and notice I could say look when you activate you have to do an MFA. I'm going to make you do a strong authentication. If you've already done a strong authentication, it won't make you do it again. But if I haven't, it's going to make me do a stronger authentication. I can require approval. I have to enter a reason. I'm doing it so there's an audit track maybe I have to enter a ticket number OI can select information about when I want to activate I can say do I want to allow permanent either don't have to. So permanent active, it's just gonna, they're gonna have it. If I do that, hey, it can only be active for six months. Allow permanent. Eligible assignment if I turn that off. Then when I make them eligible to elevate up, it's only gonna be available for maybe a year or six months. But I want it to always be eligible, allow permanent. Now I don't want to let people have it permanently. So this is where it's active. They don't have to elevate up. But they'll only have it for six months. So I can give different informations and configurations for each of those and then I would assign the roles to people and when I assign it such as pick someone. I pick and my assigning it as eligible. So again eligible means that have to go into PIM. And say I want to elevate and activate that role and then it will be eligible available for them for two hours or 4 hours then it will automatically be removed again if I say active, they don't have to elevate up, it's just going to be assigned to them. And I could say, well, it ends at a certain time. I have to enter a justification, so maybe it's a contractor. They need these permissions day in, day out. It makes no sense to make them keep elevating. But they're only on this project for three months, so I'm going to give them this role for this project for three months and then it's automatically going to go away because normally we forget and people just grant more and more permissions over time. So PIM can either, hey, you're eligible. You can activate up to it, or hey, it's active but I can time bomb it. So they're Azure AD roles. I can do the same for Azure. Now for Azure, the way we're going to do this by default is going to show me subscriptions and this would be the scope I'm assigning the role. If I in step one to assign a role a resource group or management group, I can change the resource type, even individual resource. And then what I would do is I would select whatever that scope I want to assign the role at. So in this case maybe I say too many here but be able to select for example or resource group. And then once I've selected the resource group, I would be able to, let's say I'll pick this resource group and then whatever role I select here, they would elevate up just at that RG bicep demo resource group level and I have the same settings. I can go through. And I could configure various things once it's actually shows up. I think it's tired this morning. I could also see the various roles that available at that resource group level that I could grant, and I could change the configurations on those. I don't know where we go, so I could just pick a certain role. Again, we have eligible assignments, active assignments. I could change the settings. Of this particular role and once again we get the types of activation types of assignment. I can edit how I want to make those. Available. Do I allow permanent eligible? Do I allow permanent active assignments so I have all of those controls available to me? And then the the user experience of all of this. Is they would go into PIM. Look at my roles. They would see a role they have and they would say, hey, I want to activate it. So over here I say, hey, I could activate this role right now. I could say, do I want to start it in the future? Or not do it right now I have to give a reason. And I would say activate and it's going to go through, it's going to give me that role, we're going to get it for an hour in a refresh my token and then I've just got it and then I can start doing teams related things. And that's PIM. The whole point of this is for Azure AD roles, for Azure roles and I could also elevate into a certain group. Is going to give me that for that time window only when I need it. That's that's the typical use. Again, I can just do an active assignment, but even then I can time bomb it. No, it's it's refreshing. It's getting me a new token that now has that permission. I can see it's active. Like my active assignments. And notice when I look at active it shows me. Both the ones that are activated via PIM. And it show me ones I just had permanently assigned to me. So I get that full view of all of those. So the whole point of PIM. Hey, give me stuff when I need it. That's all it's about. So users elevate on demand or set it for a future time. I know I'm going to need it then. It isn't Azure AD P2 feature, so I need a P2 license to actually leverage this. So we have entry permissions management. So if Azure AD PIM is all about the idea of really it's premeditated. I know at some point in the future these users are going to elevate up to this role, so I'm going to give them and pre assign these roles. Entra permissions management which was which was Cloud Knox, and I've got a deep dive video on this is more ad hoc. I need these specific permissions. Right now someone goes and. Gives permission to it. Authorizes it. And again, it's time windowed. It goes and creates a custom role for these particular permissions and then deletes it. So this is really about this more ad hoc on demand elevation. Bit super granular. It doesn't use regular rolls, it can do, but I can actually check individual as thousands of permissions, I can check individual ones that I actually want, and I can create my own custom templates in entra for particular sets of permissions I might want to make easily available to those ad hoc elevations. It was across clouds. So it is Azure, it's AWS, it's GCP, Google Cloud platform. But one of the things it does that's really nice is it will actually analyse usage. So it will see I have these roles. I've used these permissions. I've never used these permissions or you have these permissions. These are really considered high provision, you probably shouldn't have them and it write size it will recommend right size in creating custom roles with just the permissions you actually use or just the permissions you should safely have and fix up my environment. Because again, over time if you think about typical user. Think of a typical users life in any regular company. So I'm a user. And I start a job. So I I get roll one. Well, role one adds me these permissions and these access OK then I change role, I get role 2. Ohh well they add some other permissions access and they had some other permissions. Ohh they add some licenses as well and then I get another role. How many times does your company go back and remove the things? It's really not done very often, so overtime we just get these ever ballooning set of permissions, which is what PIM is designed to address and entra is designed to address. So that that's really the goal of a lot of what we're doing, to try and avoid just this bloat happening to the environment and to trim down into just the things I actually need and the things that I should safely have. So that's the goal around what's trying to happen. It is a separate license and the license is based on the resources it's scanning. It's not a per user license, it's one of the resources that it needs to go and look at to see, well, what permissions you have. Let me have access reviews. And this is really taking a different approach. If PIM is designed to say, hey, only keep what you have when you need it, access is reviews are designed to say that same picture I just drew. You get these constantly added membership of groups, access to application roles. They just grow over time. Access review site you know what? Let's let's review those permissions. Let's review the apps you've got assigned. Do you still need this app? Let's review this group membership do you still need to be a member? Let's review this app assignment. So roles, apps, group memberships and it could be the user self attests. Yes, I still need to be in this. It could be some delegated person, they do a check, it could be some manager. I've different controls on who's doing the checks, but I create these access reviews to review those things. Group memberships, app assignments, role assignments. And there's different people who can do that with you. But the whole point is to validate. Do you still need this stuff? It's not just ballooning out and I can set them to automatically run every three months. So again, it's AP2 feature. It's under that identity governance. But now we have access reviews. And there are three different types, remember, so I see them in slightly different places. So for new access review from this screen I can review group memberships or application assignments. If I want to do a role access review, I have to go to Ridge identity management. And then pick. Azure AD or arm and then I can see an access review. And then I can create an access review for a particular role. So they are done in two different places depending on is it a role or is it an group or assignment. And then I just configure what it is who's doing the review. So I select who are the reviewers I can select? Hey, is it a recurrence? So is it one time or is it some? Annual recurrence. How many times or how many occurrences or when does it end? Who's in scope of this? What's the role or a or group it's checking? And then whoever is delegated, be it the user, be it the manager, be it some delegated person, they go and do the review. And they can have actions to the action might be well, if you don't respond, you lose it. It could be you don't do anything, but you have control to go and now do that validation. So this is a very very powerful feature to help try and keep things in check. So that's really the point of this. OK, MFA. So passwords on their own. Are not good. We we don't like passwords on their own. Passwords on their own make us basically sad. So what we're thinking about here, remember, is the whole point of authentication. That's really our focus. So if I shift over to the board for a second, let's come over here. If I think. We should I draw? Let's go over here. I'm me. I can't remember. I keep joining me as different colors. We've drawn me as orange this time, so I'm me. And if I think about authentication. Ohh. Authentication. How do I prove I am who I say I am? Well, it's something I know, a secret password, a pin. It's something. I have my device, I have my phone. I have my PC which has got a trusted platform module in it. I have a USB key, USB key. I have hardware one time, password, token. Or something I am. Facial recognition, 3D map, thumbprint, iris detection. And if we think of the methods I can use to actually authenticate, we could just be a password. And I could think about just being a password. And we're sad. And we're really sad because that's terrible. Possible on its own. I'm just opening myself up to misery. There's going to get compromised. People are very bad at choosing good passwords, so we don't like passwords on their own. If I enable multi factor authentication just straight away. It blocks a lot of the lazy attacks, the dictionary attacks, etc. It's about 99.9% of attacks. Now there are things to stop easy passwords on their own. There are things to say block simple passwords. So I can't use password. I can't substitute an S for A5, it stops those things. I can add custom passwords, so in Azure AD P1 or above I can add my own custom passwords to not allow. So they've asked things I can do. If I do multi factor authentication, it's so much better. Now multi factor authentication is. A combination of those things. So the whole point here is. What is MFA or MFA is? Two or more. Some multifactor authentication is multiple out of these things. Is typically two or more of those things. So you could absolutely be. Password and let's do some various colors here. It could be password. Plus a text message. Or a phone call. Phone call is better than SMS because there's some other interaction and this is OK. So we'll have a fairly stoic face, and I'll deal with the eyes there is driving me nuts as fix my my eyes. So I'm sad. There's my sad face. As soon as I add in password and something else, hey it's better. I mean, I guess maybe I should be a bit happier, but maybe I'm a slightly smiling now. Go right little little smile there. Or I can use things like. Authenticator application. Or some kind of one time passcode software or hardware. Now I'm happy we like these. So that's that's another option, but you do need to use them sparingly. One of the things we'll see and we'll talk about is the idea that. If you constantly ping someone for MFA. They'll just click yes. They'll get a muscle memory of clicking yes. And it's useless. At that point you've lost because you prompt them so many times. They just click yes. They're not paying any attention. It's why the user access control and Vista was so poor because it prompted you constantly. So you didn't care. So I was asking me, yes, yes, this virus needs administrative permissions. Yes, just please don't show me this dialogue again. Same thing with MFA. If you constantly prompt a user for everything, they're not going to think about it. What I want is to jar the user. They're not used to seeing prompts. It's like, wait, why am I being asked for this? Am I doing something? It snaps their attention because I'm intelligently using MFA. Hey, I'm doing something that's a higher privileged activity, prompt them for MFA. I've detected something unusual about the behavior. The risk is increased. Let's make sure it really is I'm snapping their attention. They're not getting fatigued because I'm constantly, constantly prompting them all of the time around this. Now, I do have control around the methods that we make available for our organization. If I was to go and look. And uh my, let's jump over here. So I'm under entra. It's going to protect and secure authentication methods. And I can see policies about what I allow. So I've got all these different methods. That I can enable for different groups of the population. So Authenticator app, that's a fantastic one. But also Fido 2 security keys. Also certificate based authentication. There are other options available to me and we're going to come back and talk about these in a second. But. There's different things I can do and leverage in the organization. But that MFA fatigue. Is a real problem. So there are things we can do to block it. So firstly you should be intelligent about when you prompt. Ideally you're using some risk based detection before you go and say hey you need to MFA, you don't prompt, never do user enforced MFA where it prompts them constantly. MFA should be driven by some intelligence, ideally conditional access, maybe security defaults if I don't have premium licensing, but never just enforce it on a user. It's a terrible, terrible experience. It's not going to work very well. I want some high risk. But I'm concerned about that fatigue. So one of the nice things we can actually do is I can give a context to the user. So are they just popping up on their phone, say MFA? Yes. It can give them the application that's requesting it, it can give them the location, and then they can't just type yes. They actually have to. Well. When it prompts for MFA. It will say there's a number. Please type this number into your application and then on the Authenticator app it will actually show me. So on the Authenticator app what's confirming I am who I am? But it's saying well the app that's asking is this app, this is the location and then I have to type in that number and this does a number of things, so obviously as the user. I like where I'm not in Russia. That's odd. It's probably not me. I'm not using that app, that's probably not me, and even if I was still so didn't care. I'd have to not care enough that someone trying to attack me on the attackers screen. It's showing them a number. I have no chance of guessing that the odds will be astronomical if I guess the same number. They deserve to get in because luck is in their favor. They deserve it mean kidding. But the whole point is it's gonna make it very hard for an attacker. I'm not gonna accidentally type in the number that they have to have typed in now. That being said. If it's a really targeted attacker. This is still a possible target for a phishing attack. So a phishing attack is where this bad actor is actually maybe communicating with the user, and they're tricking them. It's like, hey, I'm from your company. I don't believe you are who you say you are. I'm going to send you a challenge. I'm going to send you a challenge. And I need you to type this number to prove you are who you say you are. And the user's like, oh, OK, I'm in trouble, OK, I need you to type 13 to prove who you are. They go, OK, 13 and then attack is like fantastic. So this is where user education is important as well. This is not phishing resistant. Some of the other ones we're going to talk about are phishing resistant. This one is not, because they're still human as part of the interaction, they're still the chance that the human could be tricked. By some bad actor who's here on this screen and is telling them to type in that number. So it's always good to educate users about. Or hey look, if someone calls you and says they're from the IT department and then they're trying to get you to type, don't. Um, separately. Communicate not via the means in the e-mail or what they're telling you. Go and look up for a different means to get direct communication and validate that communication. So this is like an alternative to people asking for the password. People say hey I'm gonna I I need you to prove you who are who you say you are, type in this number for me. So it's not phishing resistant but this is really powerful and so this is going to be turned on by default. But right now in my Azure AD tenant if I look at these authentication methods and look at Authenticator and go and look at configure. I can see these. Hey I've acquired number matching and I could do it for different groups and users. I'm going to show the application name. And also I'm going to show their geographic location. So I do have full control. I've turned it all on in mine, but I think by default Microsoft is just going to be rolling this out to everyone. So this is a fantastic thing and should really help with that MFA fatigue and help reduce some of those phishing. But again, this is still. Possible to be attacked because they're still is a user as part of the interaction anytime there's a user or the chance the user can be tricked. So. Super useful. I do need Azure ID P1 to use MFA. Now I did say before on free I can use the Authenticator app. Global administrators I think could also have that other SMS option. Um, it's free if I use security defaults. So security defaults is an option that says, hey, I don't have premium P1, but I still would like to get some basic MFA available to me and so in my tenant if I have a free tenant, I can't get PS1 or anything else. What I can actually do in my tenant is via the properties of my Azure AD and there's every chance I am not going to be able to find it in the entra screen. Because I don't think I've ever tried to find it, let's look at settings which I'm going to go. I should look this U but if I go to my Azure AD and look at properties. You know it's at the bottom there's this link manage security defaults. So here I can turn on security defaults. So what that will do is it would open up that basic MFA for users. I get no control on where they're prompted, but Microsoft will make a decision, hey, you're accessing the portal or the CLI, it's going to make them do an MFA. So it's better than nothing. But they can only use the Authenticator app. They can't do SMS, text or phone, but I think global admins can. That's all in that document that goes through those exact options. But right I don't want to use security defaults. If I have P1 I want to use conditional access, but that's there and available. Password list is the best. Let's get rid of the password completely. So if I think about this picture again, my other option and we're going to go to the. If I use the universal pen, it means I love this thing. The other thing is no password at all. Now no password could be hello for business. So hello for business is using that trusted platform module in your machine. So it's something I have because I've got the machine and then I have to unlock that with maybe a pin something I know or biometric something I am. So it's two factors. It's a strong authentication. It could be I'm using a Fido 2 key. A physical key I have to put in the machine. It requires proximity, maybe I have to unlock it or something. It could be certificate based authentication. I have a smart card with a certain I have to insert in the machine. Notice all three of those. What was common in that factor? It was the machine performing the authentication. It was the TPM in the machine. It was a key inserted into the machine. It was a smart card inserted into the machine. So these three are considered phishing. Resistant. Because with these a bad actor phoning up the user, there's not an easy way for them to say, hey, ship me your key and I'm going to put it in my machine. It doesn't work remotely. Now the bad actor had software on the users machine, but there's things they could do but it's a much more targeted and much harder attack. So these are considered phishing resistant. The other password list is the Authenticator app, but as I talked about in the last screen. Because it's a user type in a number. Technically they could be tricked, but this no password. This is like just joyous rapture scenario, hands in the air, whoopee saying yippee, this is what you really want to be doing. And when I talked about these strengths and I talked about there's a difference between those, these are actually now exposed in Azure Active Directory. So I was to go and look at my Azure AD. One of the things we actually now have oops, didn't mean that. Sorry, I've got the wrong screen. One of the things we actually have is this ability. Let's see if I can find it. Is I get these different authentication strengths that are available to me. And once again, I didn't actually look at where this is in entra. See if I can quickly go see, we can see it really quick. While under conditional access maybe? Yeah, there it is authentication strengths So I have. Authentication strengths And they were built in ones. So I think there's three built in. And what you'll see here is just multifactor authentication. That's the basic. One, then there's password lists. OK, that's nice we talked about. And then phishing resistant and you'll see for multifactor. There's 17 options and we can look at it. And it's everything. Hello for business Fido Key CBA Authenticator app temporary access pass. But also password and SMS password and voice. Loads and loads of different options available to us. So lots of different things I can do here. But if I looked at password list MFA. Now it's only four. The four that we draw on the board. And then there's fishing resistant. Well, now it's dropped the Authenticator app for the reason I explained. So we have all of the control around this. I can create my own. I could add my own authentication strength with just the methods I want to allow. So I have a lot of control and what we do with these, we can then use them in Saint called conditional access, which I'm about to talk about. But this is really, really powerful for us. Now one other thing I did want to talk about when we talk about password less. Well, how do I initially set up my machine? And So what we actually have is this thing called a temporary access pass. So I can generate a temporary access pass. This is a could be a one time I can configure how this works. I could generate a temporary access pass. And maybe give it to the manager of the person who would give it to the user. They would bootstrap they authentication process with that temporary access pass. So I could generate a temporary access pass just for a particular user. I'm sure who I've created that for, but if I look at authentication methods. Switch to that. I could add 1. I could create a temporary access pass for them. And then I would give that to the user and they would use that one time maybe onboard their machine to then go and set up for example hello for business. So temporary access pass is really useful in that scenario. So that's be how can bootstrap and get that initial configuration if they don't have a password, so there's no password, how do I get started doing anything so temporary access pass can bootstrap that experience. Now one of the challenges we have is OK. I want multi factor authentication. How does the use of initially give the phone number? Register the Authenticator app. Why are they doing that from so there's always a concern about that initial registration. So what we can now do is we'll firstly MFA registration is combined with self-service password reset. There's a site you can go to and it's one registration for both. Hey I forgot my password, I want to reset or hey the methods to use for MFA. But there is that chicken and egg problem. Where do I register this? So I have to initially set up this information. And as a company I'm like, well, I don't want that being set up from anywhere because it could be the bad actor because that initial setup is maybe in a weakened security state, they're not set up MFA yet. Then a temporary access pass helps because somehow I had to give it to the user, but maybe it was intercepted. So what I can say is I can use conditional access which helps control how I can do things to say when I want to do security registration. I'm going to enforce these particular requirements on it. And there's actually a website to do the password reset, so will that conditional access lets me do is find look at conditional access, which we're about to talk about in more detail. But. I could actually create a new policy and I can target applications, but I can also target. A particular type of user action. And I want to target. Registering security information so I could create a policy just targeted of registering security information and what I could say is that, well, I'm going to grant it. But well, maybe I'm going to acquire the device to be marked as compliant, so it has to be a corporate device. Maybe I'd require also. Uh, certain location. Maybe it has to be on a corporate network. I could do that. So that's the way we can now bootstrap in a secure way, just that initial onboarding of the secure information, because before it was pretty difficult. I could really get in that chicken and egg situation. So conditional access, this is phenomenal. This is what gives a huge amount of power to Azure ID the control of. What apps you can use it and when, what security? What configuration we have so conditional access is always used. Doesn't matter how I'm authenticating it, if I'm using federation, doesn't matter, it's still going to use Azure AD conditional access to be authorized to get to some app or service that trusts my Azure AD instance. Gives me a lot of rich controls around users and roles and the app and the environment. Before I can get access, but it is an Azure AD P1 feature. And the way this is going to work, and it's really important you understand this, all right, what color do I use for user? Orange. Orange user? We're going to try and be a little bit consistent. So I have the user. And obviously we also have. Azure AD which is our identity provider. And then we have some app. I want to talk to. Say at one. Now the way it works is. I might say, hey, I want to talk to you, please. Hey. It's going to say I'm saying I want access. It's going to say I don't know who you are. No idea who you are. I need a token. So then the user. We'll go to Azure AD and it's gonna authenticate now. If it's using. Possible authentication if it's using password hash sync. If it's a cloud native user, they're sending the credentials to Azure AD. If they're using federation, they sent their credentials to the Federation service who gave it the SAML token, and they're sending the SAML token now to Azure AD. But no matter what it is, they're now authenticating to Azure AD, and Azure AD is going to check that. And assuming that's good, Azure AD is going to create something called a refresh token and saying called an access token and the Access token is specific to A1. And it sends these. Back to the user. The user now takes that access token. For app one. And gives it to at one. And that one says, Yep, I trust that you're good. You have access, but the whole problem is that time passes. Access tokens cannot be revoked in any normal way. Now there isn't called continuous access Evaluation CA and we're continuous access evaluation does is the application has a relationship with the identity provider, it's bidirectional. The identity provider Azure ID can tell the app, hey, the user's been locked out, there's been disabled, the password has been reset, invalidate that access token that they were using and it can also send the app policies about location. Hey, this token is good for this location, but if you see the user changes location, don't trust the token anymore. If I do that now, I can revoke the token, we can make the access token longer lived and I've got more information about this in other videos. But if not, because I can't revoke it. Typically, access tokens are time bombed. They're typically good for one hour and then it expires. So what happens is after that one hour will the user takes their refresh token. That's good for much longer period of time, goes back to Azure AD and says hey new one please. Azure ID generates a refreshed refresh token that's got that the time can vary, but it's a long time, it's weeks, months and it gives them a new access token which is good for another hour for app one and sends these back. Ohh, that means to do that. What happened? Now let's get back to my board. That was weird. It goes back and now I can give the new access token back to the application if I wanted to access app to. This is why it's really interesting. If there was, I think it's really interesting. You think I'm sad if there was an app 2? I don't have to go back to my Federated service if I want to talk to App 2. I take my refresh token and I ask Azure AD. Hey I now want to token for app two and it will create an access token for app two and give it to me. I don't have to go back to that other initial authentication. My refresh token can be used for everything. That's why we have a primary refresh token on our Windows devices that are joined our phones if we have the Azure Authenticator app. That has a primary refresh token as our identity, so any apps that integrate in with the Authenticator app, I get single sign on to those. So that's why it's really powerful. But the key point here is. Now is everything. Every app access is going via Azure AD and conditional access. Surrounds that. Every authorization request, every ask for a token, goes through conditional access. And so now I can think about. And I've got other videos. I'm not gonna go into detail, but a policy as we saw, I give it a name, I can target particular users. I can target particular groups. I could target just guess. I could target particular roles, particularly users, particular groups. I could exclude certain users and groups. It's always good to have a little bit of an emergency, especially when you start including everyone. Maybe exclude certain administrators. At least you have a break glass if something goes terribly wrong and you don't lock out your organization. I can target. All as I could target particular apps. So I could target maybe just a certain office application, any application that is registered in my Azure AD tenant, any enterprise app that I have. I could target with a particular policy and then I can have conditions. I can use that user risk which is another Azure AD P2 feature that looks at the type of behavior and then it has a risk level for the user and the individual sign in. Or I can use those risks here. I could evaluate the users risk either overall health and risk standpoint based on real time and offline factors, but I can also evaluate. The individual sign in. I can look at the device platform, both included and excluded. If it's Windows Phone, it's guaranteed to be something bad. I can create locations based on actually a number of different things. If I actually come out conditional access for a second. We can define locations. And I can define locations based on both IP address and GPS. So if I'm on a mobile device for example, hey, I can actually track my location not based on the IP address, but on what the GPS is telling where I actually AM. Or I could set my own sets of IP ranges so I can use all of those. I can also define terms of use which are PDF documents. I have different things I can do here. If I go back to a policy again so I can set all these different conditions, I could target particular apps. I could target particular devices. Maybe it's got a certain property, maybe it's a saw machine. And then I have controls. I don't want to grant it while I'm going to grant it. But you must do an MFA or not boring old MFA. You have to hit a certain strength. So I want passwordless MFA. I don't want SMS, I don't want phone. I want, I want hello for business, I want CBA, I want Authenticator app. This is why I can use those custom strengths that I define. Hey, the device has to be marked as compliant according to the MDM solution, IE Intune has to be hybrid joined must be approved client app. I need an app protection policy again, an MDM. I've acquire you to change your password, I've acquire you to have accepted a terms of use those PDF documents and I want all of them or I've acquire one of them. I can have control. Over those things. And I could just block access. There's also session controls. These might apply to things like hey, I want to use a CASB solution I want to lock down. Periodic sign in we authentication. I want to use that continuous access evaluation I talked about. So I have longer lived access tokens because, hey, I'm going to have that communication. Maybe I don't want to use it. I could disable it. There's a whole bunch of things I can configure and the point is you would go through and create these policies for your particular applications. That match the requirements you have in your actual company. So these are very important things. So conditional access, fantastic. OK, moving on. So B2B & B2C very often I have My Azure AD tenant for my company. But I want to collaborate with partners, people that don't work for my company. So they don't have an account in my Azure AD and I don't want to add an account in my Azure AD that that's bad for me because now I'm having to maintain credentials in my Azure AD. I have to then maybe help desk if they forget their password. It's bad for the user because they have to now remember a different credential. And it's bad for their company because if they left the company or their company is now scrambling to try and deactivate the account on my directory because I don't want them to access things. So no one wants multiple accounts. And so I can invite them into Maya Azure AD. As a guest. So the way this now works is I can think that scroll back over this way. So I've got my Azure AD. This is my for my company. Remember, my Azure AD has my users and my groups and all the applications that I use. All those software as a service. First party and third party apps, Azure, all of those other things all trust my Azure AD instance. But now I've got partners. I've got these external people. I want to collaborate with. I want to collaborate in SharePoint, exchange online, Azure Resources, third party apps. Now they have their own Azure AD. Or they have Microsoft accounts, or they have a Gmail account. Or they have maybe Facebook. Well, they have their own custom Federation service. Well, maybe they have none of them and then they go one time passcode I can do where I basically e-mail them a passcode they used to authenticate and I can add these. Using B2B so they show up as an external identity in my Azure AD. I can then add them to groups, I can grant them roles. It works the same way, but the key part is the authentication. Is happening here. Well it's happening here for those one time passcode, I have to e-mail them the passcode from my Azure AD but the authorization. Well, that's happening here. And so that's a big difference. They don't have a separate credential. They'll authenticate against their home identity provider. But the authorization if I want strong authentication what I'm driving that I have all the policy, I control those things now I do have control now over hey who I can be. To be clearer, there was thing called cross tenant access settings. So cross tenant access settings let me control who from my company can be added to as guests in other companies and also control which other companies can be invited to be guests in my. Company and do I trust their strong authentication? So that done an MFA already or password list, they have a strong off. I'm not going to make them do it again. I'm going to trust they did a good job on that. So I now have control of all of those things. If I jump over. So firstly. I can go and look. At my let's go over here. Let's see if I can find it in entra. If I can't, I got external identities. There we go. So an external identities. Well firstly. I can do the identity providers. And you'll notice these are the ones that I have. So I've enabled obviously Azure AD and Microsoft account, one time passcode, Facebook and Google. But I could also go and add some custom SAML or WS fed so they're all the types of guests I can have. But then I can have cross tenant access settings. So there's default configuration, there's just default settings, and my default is basically I'm allowing collaboration to external users and apps direct. Effect is used by teams today and that's all blocked and there's no trust for inbound outbound. All are allowed as well, but I can then add. For specific organizations. Different settings so here for on board to Azure for inbound. For trust. I'm going to trust MFA. Compliant and hybrid. So maybe they are a company I've purchased. They have different Azure AD, but I actually trust all of their checks they're doing. So now I'm not going to make them redo authentication against my tenant if they're added as a guest. Likewise. I might say for certain organizations. I'm blocking it so I allow everyone except this dodgy looking company so I'm not going to let. Then be added as guests if they're from this company, so I'm specifically blocking those. Likewise I might say outbound access. I'm blocking outbound to this so my users cannot be added as a guest to this organization. So in that gives me a lot of control using those cross tenant access settings. So there's some nice things this opens up to us. So that's B2B the people I want to collaborate with and they just show up. I should have shown this, sorry, they will just show up in my Azure AD. So I've added a bunch of guests. Now they will show up as a guest by default. So you'll see this Member type is guest. Just those different types of tracking I can do. So you can see here I've got a Yahoo, Yahoo, Yahoo, Yahoo account. Well that's going to use identity as a mail, so it's using one time passcode. It will e-mail them each time, but I've got other guests will some of them. Is an external Azure AD, some of them are a Facebook identity. I've got some that will be. There's another man was a Google down here. One of them is using phone, so you get a text message. That's not guest, that's actually a member of my own. It's a different things I can do. But we can see I've got all these different types now I could make a guest. Remember they don't have to be guests again. It could be I've purchased this company but there were different Azure ID tenant. I haven't merged them together yet. But I want to treat them as if they're one of my company. Then it's B2C, B2C at my customers. I'm writing an app. Customers want to be able to use my app, but most of the time they have their own social identity already. They want to use that social identity, don't want a different identity. Or maybe they don't have a social identity they trust me to share. They want a local account, but I do not want them in my. Azure AD. So we can create a separate. Azure ID instance of B to C and we saw that when we tried to create an Azure AD earlier. Now I will say there's a lot of unification happening here. I don't know if over time they'll merge, but more and more features of B to C for example are coming into B to B like user flows to control the flow of the onboarding that's coming into Azure AD regular now as well. But what I would do with B to CB to C is. They're my customers. They're not people I'm collaborating with, and the customers have their social identity. Well, I create a completely separate. It's specifically of a Type B to C. And with B to C there's social identity gets added in using B to C or they can create a local account. That's a facility of B to C It lets me customize every pixel. I can have all these flows about it and if we jump over. What I'll need to do here? Is I'll have to change. Two my B to C instance. And what we'll see. Is. So I mean now in my B to C. My authentication methods. I have this whole idea. Hold on. Policies, sorry. And the policies. I have identity providers and there is a lot of them. Notice it's very different from B to B. It's all based around these social identities. So I can say which one of these I want to allow with B to C but notice there is also a local account, so if they don't have a social identity or don't want to share it with my store my app, I can let them just sign up for local account directly in my environment. But I can create user flows. This whole sets of capabilities around all of this functionality. So this is where I could then create my BTC instance. My app would trust this BTC instance and users can just happily use their own. Social identity. There's also entitlement management, there's lifecycle workflows and entitlement management is all about. I can create access packages that consist of group memberships, that consist of applications that consist of SharePoint sites. And what I can say is only certain people can request that package or maybe the package is assigned to them. So this is app two feature. Again, let's just switch back to my regular. Azure AD not my B to C. And under my entitlement management I can just create access packages and these are just groups of resource roles. And you can see I can add groups, applications, SharePoint sites. And then I can create policies around who can request it. How long does this last? So I can have who can request it in my directory, not in my directory I can say particular domain names. I could get information that I'm going to want from them. Is it time bombed for an amount of time? I get this package for. Does it require an access review? There's whole things I can do. I can require approval before this goes through, so these entitlement management is a great way to assign things that are a large level. Two groups of people. And then we have lifecycle workflows. So these are automate tasks about onboarding people. And then off boarding people since those two scenarios today, see if I jump back over here again, we'll see this idea of lifecycle workflows. And we'll see it has templates so I can create a workflow based on joiner so before they join. The day they join. And then termination before someone leaves, as they leave. After they leave. And for each of these, there's different types of tasks I can perform, so there's a prehire. Maybe my task is just to create a temporary access pass and send it to the manager? But there's other tasks I could add. As well, send the welcome e-mail, add a user to a team, removed, enable account says all these different types of tasks I can just select and these will then automatically trigger. This workflow based on a filter that I can define on who it applies to. So lifecycle workflows again help with that idea of there's stages people go through. And it helps automate that removes the human element having to perform those things. So the final thing. What about Active Directory in Azure? So good old old fashioned Active Directory, not Azure AD, but I've got. Azure virtual networks. I've got resources that want to use Active Directory, so how do I use that? In my AD environment now. Active Directory probably not going anywhere for a really really long time. What if you don't have Active Directory? But I need regular Active Directory in Azure. So it's thing called Azure AD domain services. It provides a managed Active Directory that does sync from Azure AD. Now this is the only time you can do this. Because it's managed, it's synchronized objects from a Azure AD into an ad. There's very limited flow the other way though. So now it doesn't flow from this managed AD to Azure AD and I can have replicas. I think I have 5 replicas in total on five different virtual networks where it can have these managed domain controllers, but they all must be meshed. I have to have complete peering between all the virtual networks, but it then provides me with NTLM, it provides me with it, provides me with LDAP. There's limited control. Over these has limited administrative capabilities, but it would provide me an Active Directory in Azure that I don't really have to do much management around. So that service exists. It is definitely there, but if I had my own ad already, typically what I'll do is I'll just extend it into Azure and I can even automatically join machines to that. Active Directory, if he exists through extensions to the virtual machine. So what this would look like if I actually go back to my original picture here? So you've got your regular Active Directory. Imagine I've then got my Azure subscription, so I'll do it over here and I've got a space. This is not just Azure. And what I have in Azure is a virtual network, so I've got a vnet. Now remember a vnet is IPV 4 cider range. It's a set of IP addresses. Now, providing I've got some connectivity, I've got a tunnel. That tunnel could be a site to site VPN. It could be express route, private peering. An IP path between them. Well this is just a location. Remember this is its own IP before range. So this Active Directory and these domain controllers, well they sit on their own side of range side of two. If I connect these networks together, what I could do is on this virtual network I could configure its DNS to be custom. And it could point to the IP addresses of these domain controllers. So I could just point my DNS that away to use these. Or I might extend my Active Directory in. I might actually create some domain controllers. In here. So then I'd point my DC. To those domain controllers. Now if I was to do this, one thing I definitely want to do is for my Active Directory I would add a new site. Sites are defined by cider ranges remember? So add this side arrange that represents this vnet as a site Azure South Central and then create a site link based on this connection between these. So the ad replication would work correctly, but I could absolutely just extend my. Active Directory by adding domain controllers if I have a lot of things in Azure that are using Azure AD. Sorry regular ad. I probably want to extend my ad into Azure. And that was it. So that was our identity. I know obviously we covered a lot. And I can. I've got deep dive videos in the channel about all of this stuff. But uh. Yeah, that's the end. Of this module. Thank you.

Channel: John Savill's Technical Training

Views: 55,792

Keywords: azure, azure cloud, microsoft azure, microsoft, cloud

Id: 6Vm-h_3nKjc

Length: 136min 30sec (8190 seconds)

Published: Tue Dec 20 2022