AZ-304 Microsoft Azure Architect Design – Design Authentication Part-2

1. Intro to Authentication

So in this section of the course we’re going to be talking about authentication. Now one of the key concepts of the exam in terms of identity is understanding the difference between authentication and authorization. Now authentication is proving who you are. So if you are able to show your driver’s license and the picture matches you, then you are authenticated. In the case of a computer system, obviously you are going to provide what is usually a user ID and password. Typically you’re going to have to have some type of password policy in place so that passwords are not easily guessable. Maybe the password has to be changed from time to time and the complexity of the password and the reusing of the password, et cetera. Types of policies for an extra layer of authentication. Sometimes companies require multifactor authentication.

Now multifactor authentication is a feature of Azure Active Directory and what that is is basically proving that you have access to something else, whether it’s access to your email account, an SMS message or an application installed on your phone. It’s basically another factor that is going to prove that you are who you are in addition to your user ID and password. Now sometimes you don’t do the authentication where your application is.

You basically what’s called federate that to an external service. So if you’ve ever used an application where you use Facebook to log in, but it’s not Facebook or you use Google LinkedIn. Microsoft has its own authentication as well. Any third party application that uses one of these other services could be said to be federating the identity to that other service. So the application developer is trusting that the other service will prove that you are who you say you are. They return a token or some other way to approve that you are and then they trust that that token. Now that’s authentication.

Now authorization, it’s related but it has to do with what level of access you are authorized to get access to. So within Microsoft Azure, we’re typically talking about three levels of access. At the top level. Now authorization can be so complicated. There are literally dozens and 100 plus built in roles that you can assign and you can even create custom roles. But at the top level, the core of it all is you’re either going to have read only access to something, you’re going to have contributor access or you’re going to have owner access. Now read only is fairly self explanatory.

You’re able to view the resource, check on the status, but you’re not able to modify, delete or otherwise change the resource in any way. With contributor access you basically have full rights to start, stop, delete creates within that resource. But the owner access is the person who’s able to grant rights to other people. So a contributor can’t create other contributors, but an owner can create other owners and also create other contributors.

Now, like I said, there are literally 100 plus built in roles, and we’re going to see that in a second within Azure. And so for each of the top level resources within Azure when it comes to storage accounts and virtual machines and networks, and all of those hundreds of resources that Azure gives you access to, they also have built in roles for read only, contributor owner level access to those individual resources. Now, when you’re setting up users, let’s say, outside of Azure in your own systems, how detailed do you want to get in terms of granting someone access? Now, many applications simply treat all users with the same level of access. So once you have logged into an application and the application accepts your credentials, you are in and there’s no further credential checking, there’s no levels of access within the application. That’s quite common. But some applications do grant special permissions to some people and not to others. There might be an administrative section of your app. There might be the It folks have their own system, the reporting system. You’re going to see some granularity to that. And that’s basically a decision you’re making on design. Now, I briefly mentioned that Microsoft has an authentication service called Azure Active Directory. So instead of building your own user ID and password system within your applications, you can allow Azure Active Directory to manage your users and their passwords.

And you don’t have to have that code. Now, if you need a profile or you need a user page, you would still have to do that part. But in terms of collecting a user ID and password, letting them change their password, letting them register for an account if they don’t have one, handling the issues of people trying to log in that are not authorized to count lockouts, all of these things are handled within Azure Active Directory. And so that saves you a lot of development time and gives you more features than you might otherwise have. We can look at Azure Active Directory. This is a very high level look at Azure Active Directory. Basically, you can enforce these sophisticated password complexities. So it has to be a minimum length. It has to have certain characters, letters, numbers, uppercase, lowercase symbols. It also synchronizes with your corporate Active Directory.

So if you already have an existing store of users, then you just simply synchronize with Active Directory. And all of those users now have a cloud authentication available to them. What that does is allows single sign on to exist, which is your application can use your same corporate user ID and password that the users use to log into their desktop at work, and so they don’t have to memorize additional passwords. We briefly talked about multi factor authentication, and Azure Active Directory does allow you to enforce multifactor authentication.

Now, you can do this quite selectively. Maybe only administrative users have it, or maybe certain users or users who are exhibiting strange, unusual login habits like logging in from outside your office or even logging in from outside your country. One of the central tenets of the authorization element. So we’ve talked about authentication. Authorization is role based access control. Role Based Access Control is that reader Contributor owner model where you have roles assigned to people. Azure Active Directory also supports this external federation, effectively working with social media accounts.

And so there’s quite a number of external systems such as LinkedIn, Microsoft, Facebook, Google Plus that it supports. And it’s also particularly good if you have partners that you don’t want to add to your own Active Directory. So if you have contractors or partner agencies that you don’t want to be part of your organization, but you still need to give them selective access to some of your applications, you can use Azure Active Directory to synchronize with them.

2. AD Synchronization

So we’re continuing to talk about authentication and in this video, we’re going to talk more about the feature of Azure ad we talked about in the last video called Single Sign On. Now, to remind you, Single Sign on is the ability for users who already have corporate user ID and passwords to use those same accounts to log into your a custom application that runs in Azure. The way that this works is for you to synchronize your user IDs and passwords using your on premises Active Directory with Microsoft Azure Active Directory ad. And this is done through a piece of software called Ad Connect. Ad Connect is effectively an agent that you download into your corporate network.

You authorize it and connect it to your On Perm ad and it will synchronize the selected user IDs and hashes of their passwords into Microsoft Azure ad. You set up the filter so that not all the information is synchronized if you don’t need it to be. So this allows your corporate users to use their username and password everywhere. So they use it within their workstation to log in and they use it in the cloud. And what’s pretty cool is if the password changes. So let’s say you have a password policy and the user has to change their password.

There’s basically a synchronization that happens every 15 minutes or so where those updated passwords will get pushed out to the cloud as well. The same happens when users are deauthorized. So if you have a user who departs your organization, you simply deactivate their account within your on premises Active Directory. And again, as long as your synchronization is working within those 15 minutes or so, you can basically assure that they no longer have access to their online apps as well. So, as you can see, there are a lot of advantages to Single Signon. Something you should look into if you’re implementing applications in Azure.

3. *NEW* Azure AD Connect Cloud Sync

So one of the new requirements added to the AZ Three or four exam is to understand Azure Ad Connect Cloud Sync. So Azure Ad Connect still exists and now there is a companion product called Cloud Sync, which does a lot of the same features for slightly different purposes. So in this video, we’re going to examine Ad Connect Cloud Sync, examine the differences with Ad Connect. Now. Ad Connect Cloud Sync is really a Cloud hosted version of Azure ad Connect. As you know, Ad Connect is a piece of software. It’s an agent that you download and install inside of your on premises and it can connect to your on premises Active Directory and synchronize those users and groups into the cloud. Ad Connects cloud Sync works in the cloud. So all of the configuration and the work, if you will, happens in the cloud. And there’s a very lightweight agent that’s required to connect to your on premises ad, but all it does is facilitate the communication. It’s a bridge.

So if we look at the Azure documentation for Ad Connect and Ad Connect Cloud Sync, we can go down this list and we can see that there is a lot of overlap where Ad Connect Cloud Sync shines, seems to be in connecting with multiple on premises ad forests. So instead of having to install Active Directory Connect on each of them and then having to worry about connectivity and how you’re going to get these things all centralized, you are just basically doing that all centrally. So that makes sense, that the logic and the work is done in a central location and you’ve basically got your spokes going out to various AV fours. It does have the lightweight model, so the installation isn’t too heavy, and it does support multiple active agents. And so you can have multiple conversations going on at once. The synchronization for multiple ads happening all at the same time. And so this is really where the cloud part of it shines. It still synchronizes single on premises ads as well.

It could handle multiple on premises ads. It does not work well with LDAP only, obviously, over the Internet. LDAP does not work outside of the corporate firewall. And so that’s going to be a miss on the cloud element. But it handles users, groups, contacts, it does not handle devices. As we go down, we can see there’s a lot of overlap still. There’s some customization around directory extensions. On the traditional Ad Connect side, the Ad Cloud does not support pass through authentication. As you know, pass through authentication is where a user logs into an application and instead of the Cloud Active Directory handling that authentication, it actually just passes the request over the wire down to your on premises.

Cloud Sync happens in more of a disconnected manner and not so much in terms of real time logins. So now we can see going down things like a password writeback and group writeback and things like that also not used in the Cloud Sync model. Adds isn’t supported, but the limits are pretty much the same in terms of 150,000 objects, 50,000 users, and there are some pros and cons. So obviously the on premises model has a lot more features, but you do have to do more of that work on premises, whereas the cloud model is a little lighter but can handle multiple threads.

A lot of stuff happening at a time. Disconnected ad forests from other organizations. Even so, that is the difference between ad cloud sync and ad connect. Now, if you want to explore this a little bit more, you go into your App Ad Tenant, and on the left you go under Azure Ad Connect and this is where you can find the agent. And you can also set up your Azure ad. Cloud sync So both the ad connect sync and the cloud sync are managed within the ad connect blade of your azure ad Tenant.

4. Protecting Authentication

So the next topic of this course is going to still talk about authentication, but something that’s extremely important and that is security. So how do we ensure that users are not getting access to things that they are not entitled to? Well, there’s many different ways we’re going to be talking about to implement that. And the first thing we’ll talk about is what’s called IPsec, which is a security protocol that runs within the network stack. It’s called the IP layer. Now, IPsec is effectively encrypting the contents of the data packets and then it uses authentication header signing. So basically there’s a secure signature attached to the header of the packet and the contents of the packet are encrypted. And so data can travel over a network from point to point, but the contents of that traffic are encrypted, so you have something at the application layer.

So SSL and Https operate at the application layer, high level, part of the networking stack. Well, IPsec actually operates at a lower level, so it isn’t restricted to only Http type traffic. Any traffic that can be transferred over TCP IP can be encrypted, even if it’s not Http traffic. Now, IPsec is pretty common for virtual private networks. When you have network gateways communicating with each other in an encrypted form, they’re not passing Http traffic, they’re passing raw data in packets. And that can be done with IPsec security. Now, another type of security that you’ll be interested in is the site to site VPN. So where IPsec is one of the security protocols to connect to network gateways, site to site VPN is what
you end up with when you have two network gateways connected to each other in a secure fashion. This diagram shows an Azure virtual network on the bottom right that has a VPN gateway installed on it. And then you can have your on premises network which could be working within your company. It has its own physical gateway connecting to the virtual gateway that is a secure connection, encrypted traffic traveling through it. Many people are familiar with point to site VPNs where they have to work from home and they use a VPN software to connect their laptop or their remote device into the corporate network. Well, site to site VPNs connect entire networks together. They usually require separate devices. So the gateway on your premises is usually a physical hardware that you’ve purchased that supports it. So that’s another way of securing basically the authentication between sites. Now, we talked about this multi factor authentication which is abbreviated as MFA. Now, MFA is a way of ensuring that somebody is who they say they are.

We all know that the Internet is full of hacked user IDs and passwords. You can go onto the dark web, purchase millions of user IDs and passwords for a few dollars. And so companies these days very wisely have said, well, user ID and password is fine, but for a really secure system, it’s clearly not enough. Humans are just too human. They’re too fallible. They reuse passwords. They make passwords easy to guess. Even if they change their passwords, a human will most likely just change one number. So you have your password, one password, two passwords, three, et cetera.

Whenever we see these dumps of passwords, the most common passwords are always password 12345. Very simple stuff. So multi factor authentication is a way of getting around the humans who are fallible when it comes to Microsoft Azure. When you do use a multi factor authentication, the user is going to see that they’re going to have to approve the sign in. So they’re going to try to log into your application, and then it’s going to either send them an email, send them an SMS message to their phone, or in some cases, they’ll have to use an application or they get a phone call to get a secret code. And so they have to respond to that request in order to proceed. So those are just some of the ways that Microsoft Azure Active Directory allows you to secure your authentication.

• Category: Uncategorized