1. Overview of Azure Identity Services
Identity, governance, privacy and compliance features and is worth 20% to 25% of the exam score. Now, identity as a concept is very important in the world of cloud computing. This is how you identify who people are and what access privileges they have to you, both your application and to Azure. But at the same time we’re also going to be talking about governance features and privacy and compliance. So in this first section we’ll talk about the concept of identity. So what do we mean when we’re talking about identity in general within the world of computing? The identity is this digital representation of a person, or it could be an application or a device.
So sometimes you have programs that are running on servers and they need to act as if a person was running them, but there isn’t a person running them. And so applications have their own identity and they’re going to have their own permissions. Maybe they’re going to be very limited in permissions, hopefully similar to the people within your company. Some people have very limited permissions. Some people are considered super users or administrators and they’ll have a lot of permissions. And even the devices that like the mobile phones and apps and things like that also have identities that are granted permissions. So on screen is a few examples of what you might consider. Identity could be the person like Johnny Stowe, the email that they use could be their identity as well.
The application that runs in the background processing payroll needs an identity in the system as well. Or even if you’re sending print jobs to the printer on the 6th floor. That printer is a device and it has an identity on the network. In order to authenticate as a person, you usually require a password. So there’s a user ID and password. Sometimes you can use a key, what’s called a security certificate perhaps, or a public key, private key situation, something to prove that you are who you say you are. There are applications you can use that don’t require you to prove who you are. For instance, if you go to order food in a restaurant and they have a kiosk, then you just go, you tap the food that you want to use your credit card to pay. And you don’t have to prove who you are.
Obviously the credit card requires proof for payment and authorized payment. But in order to use the application, it doesn’t require proof. But most other applications we deal with require you to log in so that you are authorized to do what you’re attempting to do. So if we look at the way that identity is traditionally handled outside of the role of cloud computing, you have some type of application on the left. It could be a mobile app or an app that’s installed on your computer or even through a web browser. On the other end of the communication is some kind of server and you pass in a user ID and password which is unique to you, which you’ve not shared with anyone else. And there’s a database of some sort where you can look up the password.
Now, in modern times, we don’t store passwords in plain text. There’s a hashing function, a one way hash that we use to store passwords, and then we have the same function on the password being passed in and we compare the hashes. This is without the use of an external identity system. An application can control its own identity by storing the password or a hash of the password in the database. And again, without these other systems, the programmer can just choose to write their own application, their own formula for hashing, store it in their own database, in their own field. It’s not so unusual, especially before modern authentication systems became so widespread. If you look back through some of the biggest hacks, if you will, then some of these things happen to be not using the most popular identity systems.
They happen to be, just as I described, where people are storing a password in a database and either they stored it plain text or they are not. Even if they hash it, they hash it with a common function like MD Five, which is easily hacked, or they don’t use salts, and even the salts are not randomized, et cetera. So plain text, MD Five, storing the salt alongside with the data, or letting people have their passwords unchanged for years and years, or having password as your password, or 12345 as your password.
These are some of the old school flaws within homegrown password systems and led to some pretty big hacks. Now, if you’re using a computer at work, oftentimes maybe a Windows computer, you’re using what is called Active Directory authentication, use your user ID and password that’s been given to you by your company. And there’s an external system, like an Active Directory server running somewhere on the network that keeps track of that, will authenticate the password and will allow your computer to log you in. And this is how you can then if you lock yourself out, call into the help desk, they can let you log in again, et cetera. Now, in the cloud environment, there is a version of Active Directory in Azure called Azure Active Directory. This is sometimes abbreviated as Azure ad or even further AAD.
It’s important to realize that the version of Azure Active Directory is not the equivalent software as what you would have running in your network in terms of Windows Active Directory. So they share a name and there is some overlap in terms of functionality. But it’s not like it’s just a cloud hosted version of Active Directory. It’s a totally different piece of software. And there’s some things that Azure ad doesn’t do that a traditional ad does. So for instance, the traditional ad, Windows ad, uses protocols that don’t work over the Internet. So we’re talking about something like LDAP, which is a lightweight directory access protocol, works within your own environment, but kind of breaks when you look over ISPs and Http and you need something more web friendly.
Azure ad does provide what is called identity as a service. So you can use in your own applications, you can use Azure Active Directory to do the user ID and password function and more and not have to write that code yourself. So you just interact with the identity provider. And Azure ID is one choice of identity providers. And this saves your team from having to reinvent the wheel, having to write password, checkers reminders for people to change their password, the functionality for them to change their password, if the person forgot their password to get that reminder, and the ability to reset their password. All of those features are provided by Azure ad, and you don’t have to code them. And of course, security is a massive thing in the cloud environment in It today.
And so anytime you create your own authentication system, you’re basically giving yourself a risk of having a bug, something that you didn’t realize a bad value can bypass the system. All that has been tested with Azure ad. So in the Azure ad model, there’s now a middleman. So your application, instead of going to the server and looking up the password in the database, there’s an identity provider living in the middle, which is Azure ad. And the client application goes to the server. The server says, oh, hold on, I pass you off to my identity provider. Identity provider does the work and then it passes back a token through the client, back to the server saying yes, he or she has logged in successfully. There are some open standards in terms of the authentication methods that work over the Internet. SAML is one standards, a tokenized access standard, open ID and WS Federation. So that’s sort of my brief overview of Azure ad, but we’re going to continue off in the next video.
2. Benefits of Azure Identity Services
So in this video, we’re going to look at some of the benefits of Azure Ad. Why would you use Active Directory in the cloud as opposed to either not using it at all or creating the features yourself through your own programming? So the first and most obvious reason is the security of it. Azure ad has hundreds of thousands of clients using the product and millions of users that are authenticating through it. And that’s basically been proven. So relying on the fact that so many people have used this product, all of the major bugs have been found. Hackers have been trying to break into this thing. Microsoft is spending millions of dollars to harden it against any kind of intrusion. And so you’re getting the benefit of that through the security.
I mean, imagine if the Azure Active Directory has been hacked into. It’d be a huge black eye for Microsoft, and so they work very hard on preventing that from happening. To add to that, you’re also saving time and money. So if you have an application, a development project, you’re going to have to devote so many weeks of your development time to the user ID and password authentication, giving people access rights, whether they’re read only users or contributors, or higher level administrator rights. All of those features that come with Azure ad, you’re getting them at a fraction of the cost of developing them. All you need to do is integrate your app with Azure and you get them.
And that should be a lot simpler than creating them yourself. And on top of that, even beyond the basic authentication features, azure ad contains a dozen plus features that you could use to enhance the security of your application. Everything from multifactor authentication, user access, reviews just in time, elevation of privileges, and conditional access. And all of these things Microsoft has built into the product.
You get those features and you may not even have been worth it for you to develop it yourself, but you’re getting them as part of using that application. With Azure ad, you get a centralized dashboard. You can get logging and reporting. You can grant people access and take their access away. There’s API, so you can write scripts and things like that to do this. It is basically an administrator portal for managing control and access to your application. Whereas with your own application, unless you put the time and energy into creating such a portal yourself, you’re doing this all in the code. You’re doing this in the database. You have to go talk to the developer to grant access or to remove access from somebody. You can give somebody the ability to control the security who is not necessarily developer, and you don’t have to change the code or change the databases. One of the big benefits of Azure Ad is its integration with the Windows Active Directory inside of your corporate environment. Until you can enable such a cool feature like single sign on where you’re using the same employee user ID and password you do to log into your desktop, to log into all of your applications that can use Azure ad.
So there’s optional synchronization, but it exists between on premises and the cloud. And so if they change their password in one spot, it’s reflected back into the other, et cetera. Azure ad is also giving you ability to integrate with other Azure services. This means that you can grant people access to storage accounts and SQL databases using their Windows, user ID and password as well. So the same single signon can be used for Azure services. Not only that, you’ve programmed within your own application. So we can see that there’s lots of benefits for using Azure ad. I do believe Active Directory is the most popular management platform out there in enterprises today. So using Azure Active Directory seems to be a nobrainer as far as most applications are concerned.
3. Azure AD Conditional Access
So one of the fundamental concepts in security and authentication is the difference between authentication and authorization. So authentication is basically a user proving who they are, right? So usually it’s done by user ID and password. But it’s basically just a way for you to say, hey, my name is John Doe and I can prove it because I know John DOE’s password. The corollary to that is the author authorization. So once you’ve established who John Doe is, the real question is what can John Doe do? Now, this isn’t as simple as it sounds because in some systems, not every user have the same privileges. And so you might be a reports user, you might be the database user, you might be controlling the virtual machines, being able to stop and start them, all sorts of different levels of privileges.
I think there’s been a general trend, at least in some larger applications, to move away from this concept of all users having the same privileges or all users being administrators. What you want to do is start to introduce finer grain control and to say, well, not all users are the same. We have the operations team and they need to have this type of access. But if you’re not on the operations team, you can actually do some damage if you accidentally stop a VM when that’s not your responsibility to do that, or if your account gets compromised, which can happen in this day and age. Well, we don’t want we want the administrative privileges to be rare. We don’t want the administrative privileges to be common. And so it reduces your attack surface for people getting access to hacking inactive accounts, etc. So let’s talk more specifically about what is Azure Active Directory? So Azure Active Directory is the preferred solution for identity management.
So if you see a question on the exam asking which of the following Azure services performs user and Access control? While Active Directory should be the first thought when you’re looking through those answers, azure Active Directory is actually the back end to not only your own authentication, but Microsoft Azure actually uses it. So when you log into the Azure Portal, you’re actually validating through an Active Directory instance. Skype Outlook, Office 365, Xbox. They all use Active Directory instances behind the scenes. So when you log in through your user on whatever platform that is, you’re going through Active Directory. That’s what I mean by there being hundreds of thousands of clients and millions of users because all of these services use Azure ad. So if you are talking about users and groups and applications and permissions, it’s basically a complete solution for that. I mentioned in the last video that it does power single sign on.
So if you want to do some type of synchronization with your corporate Active Directory, it certainly can do that. Another feature it supports is something called conditional Access. So conditional access is basically an intelligent feature of Azure ID. It’s optional, but you can enable it. That can basically detect unusual activity and require somebody to take some extra measures to prove who they are if something falls outside of that norm. So let’s say you have a user and every single day that user logs into the application from their desk at the office. And so Azure ID just accepts their user ID and password and they get access to the application. Another user actually tries to log into the application, but they haven’t logged in for months. They seem to have been inactive. And then suddenly out of the blue, they attempt to log in. That could be something that’s a little bit suspicious.
And conditional access can kick in and say, well, we have to do some extra authentication on this user. You could have a situation like this where you have an administrator level user, so somebody who’s got super privileges and suddenly they’re trying to use their phone to access the website. So the device they’re using is not what they normally use or another administrator. Suddenly you have a user halfway around the world trying to log in as that person and it’s nowhere geographically close to where you would expect them to be. So conditional access allows you to treat certain users as being routine access and not worthy of extra scrutiny and some types of access as requiring additional proof.
This diagram is attempting to say, you’ve got a number of criteria that can basically signal that this is a normal or abnormal thing. So the location of the user, the privilege level of the user, how long it’s been since they logged in, these are all signals. Then you have some intelligence in the middle that makes the decision that says, oh, wait a second, this person is doing something that we’re not expecting them to do. And you can either allow them in, you can make sure that they have to go through multi factor authentication. You can allow them in with only limited privilege.
So the administrator user that’s trying to log in from their phone logs in as a regular user and basically it prevents them from anything bad from happening. Or you can simply just block their access. And of course, there’s reporting and notifications. And you can go in as an administrator, monitor this type of action, and look to see maybe your criteria is too tough or a user is doing something unusual. And then you can disable their account until you get them on the phone and say, hey, did you get act? We’re going to pause the video now. We’re going to talk in the next video about the concept of multifactor authentication.
4. Multi-Factor Authentication (MFA)
So the final topic we’ll talk about in the terms of authentication is the concept of multifactor authentication. Now you may have heard this term before, or maybe this is the first time you’re hearing it, but Azure does support MFA or multifactor authentication. The whole concept of it is that you sometimes have to provide more than two or more pieces of identification in order to prove who you are. So these are called factors. Now the factors themselves should be distinct from one another. So for example, a password is something you know. And so if I asked you for two different passwords, they’re not distinct from each other and they wouldn’t count as multifactor authentication.
It has to be distinct in the sense that it’s something you know, something you have or something you are. And that would be like a biological element in the last bit. And so that’s why some apps text you a code. They use SMS to send you a short term code that’s going to expire in a few minutes and then that’s the second factor in the multifactor. So your password is something you know and that counts as one factor in most applications that are not. Maybe some applications aren’t serious or important enough.
That’s sufficient. But passwords can get copied, passwords can get stolen, passwords can be reused between sites. And so if you’re using the same password on 15 different sites, if any one of them was to get hacked, then the hackers would have your authentication credentials to 14 other sites. So password is just one factor. So sometimes you do need a second factor. Now this could be a code. You’re going to be a text, a code, it’s going to show up in your email or there are applications. Now Google has the authenticator app. Other companies have authenticator apps as well.
So these are various ways that you can have as your second factor. Now sometimes in more advanced applications you’re going to need to provide a fingerprint or retina scan or some other type of thing, which is something that you are. I’ve had a laptop in the past where it had a fingerprint reader built into the laptop. Some applications could take advantage of that factor in liu of sending you a code. But the more factors you have, of course, the harder it is to be hacked and the more secure the authentication is and the more sure you are of the person who is who they say they are.
