back

Microsoft Azure Security Technologies (AZ-500) (Updated 2021)

Microsoft security in the cloud & on-premises26 H 48 M

Just you? Training a whole team? There's an ITProTV plan that fits.

Start Training Today
Episodes
Episodes
  • Manage Azure Active Directory Identities
    • Configure security for service principals
    • Manage Azure AD directory groups
    • Manage Azure AD Users
    • Manage Administrative Units
    • Configure Password Writeback
    • Configure Authentication Methods
    • Transfer Azure subs between Azure AD tenants
  • Configure secure access by using Azure AD
    • Monitor Privileged Access
    • Configure Access Reviews
    • Activate Privileged Identity Management
    • Implement Conditional Access policies
    • Configure Azure AD identity protection
  • Manage application access
    • Create App Registration
    • Configure App Registration permission scopes
    • Manage App Registration permission consent
    • Manage API access Azure subscriptions, resources
  • Manage access control
    • Configure Subscription and Resource Permissions
    • Configure Resource Group Permissions
    • Configure Custom RBAC Roles
    • Identify the Appropriate Role - Least Privilege
    • Interpret Permissions - Check Access
  • Implement advanced network security
    • Secure the Connectivity of Virtual Networks
    • Create, Configure Network, App Security Groups
    • Steps to Create and Configure NSGs and ASGs
    • Create and Configure Azure Firewall
    • Implement Azure Firewall Manager
    • Create and Configure Azure Front Door Service
    • Configure a WAF on Azure Application Gateway
    • Configure Azure Bastion
    • Configure Resource Firewalls
    • Implement Service Endpoints
    • Implement DDoS
  • Configure advanced security for compute
    • Configure Endpoint Protection
    • Configure system updates for VMs in Azure
    • Authentication for Azure Container Registry
    • Implement Vulnerability Management
    • Configure Isolation for AKS
    • Configure Security for Container Registry
    • Implement Disk Encryption
    • Configure SSL/TLS certs
    • Configure Authentication
    • Configure Automatic Updates
  • Monitor security by using Azure Monitor
    • Alerts - create, customize, review and respond
    • Configure Azure Monitor
    • Configure Diagnostic Logging and Log Retention
  • Monitor security by using Azure Security Center
    • Configure Vulnerability Scanning
    • Harden VMs in Azure
    • Centralized policy management in Security Center
    • Evaluate for Compliance Using Security Center
  • Monitor security by using Azure Sentinel
    • Create and Customize Alerts
    • Configure Data Sources to Azure Sentinel
    • Evaluate Results From Azure Sentinel
    • Configure a Playbook
  • Configure security policies
    • Configure Security Settings Using Azure Policy
    • Configure Security Settings Using Azure Blueprint
  • Configure security for storage
    • Configure Access Control for Storage Accounts
    • Configure Key Management for Storage Accounts
    • Azure AD Authentication for Azure Storage
    • Configure Azure AD DS auth for Azure Files
    • Create and Manage Shared Access Signatures (SAS)
    • Shared Access Policy for a Blob or Blob Container
    • Implement Storage Service Encryption
    • Configure Azure Defender for Storage
  • Configure security for databases
    • Enable Database Authentication
    • Enable Database Auditing
    • Configure Azure Defender for SQL
    • Implement Database Encryption
    • Implement Azure SQL DB Always Encrypted
  • Configure and manage Key Vault
    • Manage Access to Key Vault
    • Manage Certificates
    • Manage Secrets
    • Configure Key Rotation
    • Spotlight Key Vault Soft Delete, Purge Protection
    • Configure Azure Defender for Key Vault

Configure security for service principals

19 M

itprotv course thumbnailitprotv course thumbnailitprotv course thumbnail
  • Episode Description
  • Transcript

Don and Adam link the concept of an Azure Active Directory registered application to the use of a security principal, and show you how security principals provide secure role based access capabilities for Azure Applications.

When deploying an application in Microsoft Azure, you wanna make sure that access to resources in your tenant stays secure. Stay tuned to see how you can use service principles to do exactly that. >> You're watching ITProTV. [MUSIC] >> Welcome back, everybody to the Microsoft Azure Security technology series here on IT pro TV. I'm your host Don Pezet. Here in studio today with Mr. Adam Gordon. And we are jumping into some updated topics for you and the one we're touching on today is configuring security for service principles. So Adam, what are we gonna learn about service principles? >> So when we think about security for service principles, we're thinking about one of the probably most important things we could talk about with regards to Active Directory application workloads. Don and I have spent a lot of time early in the course talking about this exact thing. Microsoft put out a batch of updates, we're calling them the July 2020 updates around the exam objectives. And so in this area of the course, we're dealing with those, in this particular discussion around service principles, takes us back to our conversations around application workloads, registering an app. If you remember we talked about the Don Corp Minesweeper app for instance, we created in register that. And when we did that we actually had a service principle created as part of that registration process. But we didn't really spend a lot of time talking about what the service principle represents. And so we're gonna cover what serves principles are really the idea of how when, when an application is created, we need this additional element that allows us to decide ultimately how access will be governed for that application as it consumed services. >> All right, now Adam, like you mentioned, we did actually cover some of this earlier on in the series, but there's a few extra things that we need to touch on. So to start off, let's just make sure we're all on the same page because it has been several episodes, it was very early in the course. When we talk about a service principle, what exactly are we talking about, when we say managing security with a service principle? >> Sure, so the security part we'll put aside for a second cuz that hopefully makes a lot of sense to everybody by now, right? >> [LAUGH] >> This is of course, the Azure Security Technologies course so skirted piece we'll touch on but it's really pretty straightforward talking about being able to use role based access control, right? To be able to constrain or assign a role to the service principle and allow it potentially to do certain things, maybe block it from doing others. But what more broadly we have to think about with regards to Don's question is what is the service principle? Think of it as an essentially one of the two parts that are created when we register an application. When we create an application and register it, we create the application object, the item that represents the application itself. And then we have the service principle object, which represents our ability to access through the application, the use of the application resources. So you can almost think of it as a user account that the application is gonna have access to, but in such a way that we assign, in this case, one or more roles to it. And constraint access so that when the application is consuming or using resources, it uses this service principle to be able to do so. And this is the identity essentially that the application and habits but it is a per tenant application or excuse me, per tenant ID. Which means that if we have one application, hypothetically the Minesweeper app, and it is going to be our Azure identity for it is going to be registered in our home tenant, then we're gonna have a service principle associated with that when we create the app. If we have a multi tenant app, maybe we have multiple tenants we're managing, we're gonna use this app across those tenants. Each of those tenants is gonna have to have a service principle created to be able to use the app. So a service principle is a per tenant item, whereas the application registration is global across potentially all the tenants that we manage. >> All right, now, Adam, I'm thinking, I'm channeling my inner lazy developer. And I'm thinking man, there's easy ways to do this. I could just hard code an API key or something like that, and have the application jump in and access whatever it needed. So obviously that creates a less ideal situation. So why would I want to go the extra mile and configure it up to use a service principle? >> So it goes back to this idea of security that we were just talking about and the element I mentioned, which is role based access control in particular, right? When we think about having a service principle. We think about this identity that once we opt in, if you remember Don and I talked about sign in and opting in, either accepting on behalf of the user or on behalf of the organization, the elements associated with the use of the application, we actually then episodes that we to show you how to do that. And so when we are able to think about using that thought process combined with role based access control to say for this service principle, we've opted in, and now we're gonna have this role assigned to it. So it's maybe gonna have contributor or maybe read or one of the roles we would specify, as a result, we're specifying we're scoping and tailoring. We're configuring but controlling what level of access this service principle executes with, as opposed to just saying, here's a key or here's your whatever we would use, and it's gonna go off and have full control in theory to whatever it touches. It's giving us some more constrained capability to manage which is very important as we think about accessing an app and the role that it will execute with. >> All right, so Adam, I think you mentioned that when we register an application, it automatically creates a service principle for us. So is there anything we need to configure to actually take advantage of that? >> So in theory, the answer to the question is no, because since it is created for us automatically, there really isn't much we would have to do and we could stop the conversation right here and you would have note of what you need to know- >> [LAUGH] >> For the exam. You'll know, that's not where we're gonna do, if Don's asking the question, I'm talking about it clearly there's a demo somewhere in our future. So we could just do what we did with the Don Court Minesweeper app. And we would be done because we actually have a service principle for that even though we didn't really see it. We don't have ways of seeing this in the GUI directly in the portal cuz it doesn't represent itself. But what we're gonna do is take a step back and go through this process again, but show you how to do this from PowerShell. Because through PowerShell, we can use some specific commands that require us to be able to specify, yes, I wanna serve as principal, but here's the information I wanna associate it with, here's the password, or the secret, that we talked about, that will be used with it for authentication purposes. So I'm gonna step through that with you and show you how that's done, because you may actually be asked about this on the exam in terms of being able to do it, other than just saying, well, I've registered the app, so it's there. And so we want you to see it kinda broken down. So to that end, join me here, if you will, we're gonna go through and take a look at how this process takes place. Now, we're in the portal, we're in the Azure Active Directory blade, because I just wanna to start out there and show you, remind you where we go to see the applications that we register, so you'll know where to go find and them when we're done. Now, as we do when we start out in the Active Directory, I'm just gonna zoom in. You could see Microsoft changed the view a little bit as they often do around the portal. We used to just be able to see this up on the top of the Overview blade, they put the tenant info into a nice little card now on the Overview blade. But we do point out our license Azure AD Premium P2. And you'll see I'm logged in as the Global Admin role, so I have full rights to everything. And I'm gonna go down to manage here. We're gonna go down right below where we are. And we're gonna come down here to app registrations, which is where we went to create the Minesweeper app. And when we go in we'll take a look here, you'll actually see our Minesweeper app is still sitting right over there on the Owned Applications tab. Now, we also have a bunch of other applications. This is a tab interface under all applications, as you can see. And among the applications that are there, this is ITP service 11 app, which we're gonna see in a second is the one I've just created in PowerShell that we're gonna walk through and use. So you'll see it's already there I've already created and register the application. We do see the creation date right there. We do see it certificates and secrets our current green circle white check, meaning we have one or more of them loaded up already and associated with the app. And we'll come back and take a look at the properties after we see how we did this in PowerShell. But I wanted you to see where you would go to find evidence of the application that is created and registered. And as a result indirectly the service principle once we're done. So just reminding you of that. Now I've gone ahead, I've taken PowerShell, I've set it up as we often do have used the Connect AZ account cmdlet to connect in. I've gone to the URL that Microsoft provides Microsoft.com device login, and I have used our challenge code or OTP to be able to authenticate. You'll see the evidence of that there and now set up ready to go. This is all in the show notes in the code that we always provide. And I've gone ahead in this particular episode, and I've used the import module cmdlet to bring in the az.resources module, I need a few of the commands that are supported there. And if you don't already have the module loaded, this demo won't work for you. So I wanted to make sure you saw how to do this, so I've just gone ahead and done that. And once I've done that, I've declared a variable called credentials. So $credentials= and then we set it equal to the new object cmdlet type name and then there's a rather long string here, Microsoft.Azure.commands.ActiveDirectory, it kind of truncates and wraps PSAD. And we'll come back over here PSAD password credential. So this is what I'm getting from the AZ resources module that I've imported. I've specified the property parameter or the parameter for the property excuse me, and I'm using start date and I'm sending that equal to get date, so I want the current date, and then end date and I want the get date cmdlet again. But then I wanna specify the year parameter and specify 2024. So I'm gonna start with the date for what we are currently in, which is towards the end of June of 2020. And I'm specifying an end date for years ahead into the future 2024 and then I'm using password I'm setting it equal to ITPStrong! obviously wouldn't expose this in the real world. We're just doing this as a demo, or you would change it obviously if you let people see what it is. But what I'm doing here is I'm setting a credential variable equal to the password, and the date range that I've specified, right? That's what I've done in this first command that I'm showing you. Then I'm creating a second variable sp for service principle, and you can name it what you want. I like to name variables more or less aligned with what we're doing right cuz it makes it easier to follow them in the script, it also makes it easier when you document it when someone looks at it later. Don and I both talked about this a lot across the course. It makes it easier for people down the road to see what you were doing, understand your thought process and track relatively easily, the functionality you're trying to provide to them, right? If you don't like the person, then change the variable name and make it totally unpredictable. But don't do that unless you absolutely don't like the people you're working with. All right, New-AzAd, right? Azure.d Active Directory Service Principal, this is the cmdlet that does the job for us. This creates the service principal or display name you already saw what I registered, ITPService11, PasswordCredential will call the credential variable that we specified up above. So we've done all that, that's been done, you saw the output of that. And before we go back there, I just wanna show you right? This will all be in the show notes for you. I've done this using this cmdlet and I specify a password right here as we talked about, right? But I could also do this using a plain key credential. And if I wanna do that, I would specify a variable called cert. And instead of a, password or a secret, right? I could use a public certificate, I just have to put the string in as base 64 encoded, whatever that would be, it would be a random alphanumeric string, a block of text you would drop in here. And then you would call that in using the CertValue parameter instead of as we did up above the password parameter. So you can modify the statement very easily bringing in a public certificate probably good to know that for the exam, just in case you get asked. >> Now, when we create these service principles, whether it's a password or a certificate or whatever, would we generally keep it one service principle to one application or other scenarios where you might reuse a service principle across more than one application? >> So no, you wouldn't reuse them. There's a one to one association when the application is created, so the application object. There is an association of the service principals to that particular object. But as I mentioned, there is a need for a service principal per tenant. So if you have multiple tenants, then you would have to have a service principle in each tenant to be able to use that particular ID. So we'd have to think about whether it's a single tenant application or a multi tenant application. In our world, in our examples in what we do here, it's a single tenant. So I create one application object and a service principle we pair them. If you had multi tenant solutions, you'd have to have service principles associated with each one. So you would have a service principle and each tenant that's associated with that application, it would just really depend on the architecture involved. All right, so I can manage a service principle. The other part I just wanna show you once it is set up. We talked about the fact that one of the key value adds here. The reasons we would do this is that we can use our back role based access control to assign an Azure role. We've seen our back in many of the instances in episodes across the course and the new AzRoleAssignment credential or excuse me, cmdlet, as you can see here. Would allow us with the application ID parameter, we'd put in the service principle app ID that generated once a service principle is set up associated with the application. So to Don's point, we know what that association is. And then role definition name parameter, we'd put in the name of one of the predefined roles, reader contributor of the two I mentioned as we were talking earlier. Now, you'll notice that I use the new AZ role assignment cmdlet here to let's say specify the reader role in theory if I had done this, right? But then I can also remove a role using remove AZ role assignment. Again, this is probably important for you to note and be aware of. And notice I'm removing in this case the Contributor role. Now, we start out with contributor traditionally as the role that is assigned for a service principle. And the reason that I wanna create a new role in this case reader it's more narrowly defined reader has less permissions less rights associated with it, if you will than contributor does. But notice the order I did listen, I created the new role first and assign, not created, rather assign the new role, the role already exists. But I assigned it before I removed the existing role that is assigned. The reason we wanna do this is if I unassigned contributor and I have no other role assigned, then the service principal has no access, no capability, no way to do its job. And as a result that can lead to concerns where applications are not functioning correctly, things will go wrong. There is a small delay between these two about 30 seconds approximately as I do them. So it'll be a little bit of a period where the application will not be able to do something with the appropriate role assigned. So we wanna make sure we have a new role there, so essentially, both roles are in play. Then we remove the wider of the two roles constraining us just to whatever the role is, in this case reader. But do you understand the logic of the flow here and understand why we're doing this? Understand contributor would be our default. This is all good information to have for the exam. Specifying and then checking on those changes get AZ role assignment will let us see whatever service principle we target, what the roles are now so it's good to note that as well. And then finally, if you want her to go in, you wanted to sign in using the service principle to Don's point, obviously if we're going to do this we may have a need at some point to use it. We can connect the AZ account as we've done, but specify that a service principal parameters used and specify the credentials for that to allow us to then see the service principal in play. We normally wouldn't log on as a service principal directly but we can validate that it's working, if we wanted to do that. Remember, that's normally gonna be done right behind the scenes for us. Same thing where we have the certificate authentication. We could do that with certificate thumbprint if we're using the service principle to test it, so I've shown you that. And if we wanna reset the credential on the service principle, there really isn't a way to do that in the sense we can go in and mess around with it, reset or change that. Well, we actually have to do is remove the service principle credential, and then create a new one. That's what reset is referred to as, essentially it's a redo and a do over by creating a new one. But you may just wanna know this right as opposed to being asked about it and not being familiar with the process. >> That's like describing a upgrade as format and reinstall. >> It is. >> [LAUGH] >> Technically, it is an upgrade but you're doing a lot of extra work. All right, so you could see here going back to the portal, right? That we do have that application the ITPService11 one that you saw I created in PowerShell, the service principles associated with it. But there really isn't a way to go see the service principle per se, because it's not listed here, right? We don't really see anywhere in here under manage where I can go in and I can, see, here's the blade for service principles and they're listed that doesn't exist in theory. We could go in and we can see the certificate or the secret registration that we've done and we do indeed have the ability to see that. But beyond that there really isn't a way for us to interact. The service principle is a behind the scenes thing. We're not meant to work with it directly, we're not meant to interact with it. It is an object that is used behind the scenes and we just don't really have direct control over it, except if we're working with it through the command line, through PowerShell or the equivalent CLI commands, we chose to do it in CLI. But we're interested since we're here, we can at least go in under Certificates and Secrets. And if we go down here, we chose to do this with a client secret, I did when I did the demo, not a certificate, but we'd see either or both of those listed here. And we can see at the bottom here that we do have a client secret register, the value is hidden we don't see what it is. Remember, it's the ITP, 123 exclamation that we showed you, but we can see the expiration date set to 2024. So we can see evidence of the fact that that's what I did from PowerShell. That's really about all we can see beyond that really isn't much to note. >> Yes, so this is one of those scenarios where it is kind of an easy button for us if we want it to be, that it automatically creates a service principle. Or if we do want to get involved in it, we know that we can jump down to the command line. And that's some of what Adam showed us here in this episode, we had a chance to learn a little bit about what those service principles were and how they were created. And then he walked us through the PowerShell to show us how to actually be able to get that fine grained control of exactly what that service principle is going to be named, the access that it has and the visibility to see what it can do. So all of that is part of managing application security by using service principles. Well, that's gonna be a wrap for this episode. Do Stay tuned, we do have some more Microsoft Azure Security technologies coming up but for this episode, it's a wrap. So signing off for ITProTV, I'm Don Pezet. >> And I'm Adam Gordon. >> And we'll see you next time. >> Take care everybody. [MUSIC] >> Thank you for watching ITProTV. [MUSIC]

Start training today

Just you? Check out our personal plans

Premium

$529 per seat/per year

2

Total seats

Standard

$349 per seat/per year

2

Total seats

Credit card required

This is for your account.
This is for your account.
We will contact you with this phone number about your trial.
We will contact you with this email about your trial.
What is the name of your company?
In which country is your company located?

Step 1 of 2

Get a demo or a start a team trial