Amazon AWS Certified Security Specialty – Domain 4 – Identity & Access Management part 12
- Understanding Active Directory
Hey everyone and welcome back to the Knowledge Pool video series. And in today’s lecture we’ll have a highlevel overview about Active Directory. Now, I am very sure that most of you have heard about Active Directory because it is generally used in most of the organizations, specifically the enterprises. So let’s look into the Active Directory with a simple use case. So let’s look into a traditional way where you have an organization and within the organization you have different applications. So let’s assume this is AWS. Then you have application Two and then you have an application three. And here you have the users which are part of the organization. Now, if user wants to log into each of these applications, what would have to be done is that in each and every application you would have to configure the users manually.
Like if you’re using AWS, then you have to go to IAM, you have to create Im users. So if you have an application two, you again have to create manual users. If you have application three, again you have to create manual users over here. And if someone leaves the organization, you go to the AWS, you delete the Im user, then you go to the application two, you delete the Im user there, you go to the application user. Application three, you delete the user there. So if you see this is quite a big pain and typically when you talk about enterprises, you would have like 2030 users maybe joining, maybe leaving the organization. And for a system administrator, doing this on a regular basis for 2030 users is a very big pain. And this is the reason why there is a need for a central authentication.
So when you talk about a better way, what we basically have is you have a central server and what you have is you create all the users in this central server and then you connect the central server with all of the applications which are present within the organization. And thus all the user has to do is user just have to log in once and he can access all these services or he can log into each of these services with the credentials which are stored in the central server. So this central server can be Active Directory. It can be other services as well, like identity management which is provided by Red Hat. So this central server is what we will call as an Active Directory. Since this is an Active Directory lecture, now things becomes much more simpler because if you want to remove the user, you can remove the user from the Active Directory itself.
You don’t really have to go to each and every application and remove the user. Same goes with adding the new user. So when you talk about Active Directory, active Directory is one of the most popular directory service developed by Microsoft. Now the server running the Active Directory service is called as the domain controller. And it can authenticate and authorize the users and computers which are associated with it. So within the active Directory, on the left hand side, you see you have the users, and within the users, you can have various users which you can create, and you can change the password of the users from here. You can delete the user, you can add the user, et cetera, et cetera. And then you can configure the users to access each of these services.
Like if you want user one to if you want user one to only access the AWS, then you can configure the policies accordingly. So this is a very high level overview about the active Directory. I hope you understood in a high level overview on what active Directory is and what are the things that we can achieve with the help of active director.
- Deploy our first SimpleAD based directory service
Hey everyone and welcome back. Now in the earlier lecture we had a small demo related to how we managed to log into the easy to instance with the users which were part of the directory service. So what will be doing in in today’s and in next lecture will actually set up the entire infrastructure that allows us to do exactly what we had seen in the demo demo. Now in the demo we were using a directory which is based on the simple ad type. Now let’s do one thing. Let’s go ahead and create a new directory. So I’ll click on the setup directory and as you see there are various types of directory service available. You can choose Microsoft Ad but again you’ll have to pay for a price. Simple ad is quite good enough for the basics operations.
So click on simple ad and within this it will ask you for a specific configuration related details. So let me call it a simple ad. In fact I’ll just use the same domain name. I’ll use this domain and I’ll set up the directory. So let’s try this out. I’ll say simple ad my domain name. So you can choose any domain name. It is not necessary that you should choose a domain name which is in drought 53. In fact, let me just show you. I’ll just say KP labsordon. Okay? Now within the administrator password, just select any random administrator password. So I just say password one, two, three hash. Let’s try this out. Password one, two, three hash. In case I just forget, I’m quite bad at remembering things. So again within this you have the directory size as small and large.
I’ll just select small because this is where we are testing for and you have to create this ad must be created within the VPC. So I’ll just select the VPC which is present in this region and I’ll go for the next step. So if you look into the next step, it basically says that you can try out a double directory service at no additional charge through the directory service 30 day limited free trial. So this is quite good enough because the directory service 30 day limited free trial provides you with 1500 hours of use. So this is quite good enough because will not be charged for using this directory service. So let’s go ahead and create a simple ad. So one important thing to remember is that this can take up to ten minutes for getting created. It does take a good amount of time for the directory to be created.
So now if I go to the directory, I have the directory of simple ad dot kplabs dot in as a directory name which is getting created. So let’s do one thing. Let’s wait for few minutes for this to be created. Perfect. So it took around five minutes and our simple ad is now created. So if I just go into the simple ad it will basically give you the details related to the active directory which is created. Perfect. So this is what we actually needed. Now, in the upcoming lecture, what we’ll be doing is we’ll be creating an EC two instance and we’ll be domain joining that EC two instance with this active directory so that the users which are part of this active directory can log into the EC two instance directly. So this is it, about this lecture.
Go ahead and try this out. Since this is a free tire, we don’t really have to pay, and in the upcoming lecture we’ll do something interesting stuff. So this is it, about this lecture, and I look forward to seeing you in the next lecture.
- Domain Joining EC2 instance with Directory Service
Hey everyone and welcome back. Now, in the earlier lecture we went ahead and we had created a directory service based on the simple ad type. So in today’s lecture, what we’ll do is we’ll be doing a domain join between this simple ad and the EC to instance. So I have an easy to instance which is created. So this is to be domain join. So this is the easy to instance which is created and we will join this EC two instance to the simple ad. And then we’ll log in with the user which is present into the simple ad to the EC two instance. Perfect. So let’s try this out. So I’ll connect to the EC to instance over here. So let me just I’ll do my EC to user at the rate perfect. So I’m logged in. So I’ll do a pseudo suphen. So I’m connected to Root.
Now, there is a small guide that I have written over here and this guide will help us in doing the overall process. So you see it is quite simple to achieve this. So let’s try this out. The first is the installing of triple SD realm D as well as KRB five workstation. So let’s install these packages. So I’m using the Amazon Linux machine and the steps which are mentioned are for the Amazon Linux machine. Perfect. So once these are installed, next you will do is you will have to make sure is that when you create a simple ad, you see it has given the DNS address and basically this simple ad kplabs in or whatever domain that you give, this will be resolvable from these DNS address only. So let me just show you. If I do a simple Nslookup on simple ad, you see it is not able to find the relevant IP address.
However, let me try to give the IP address. This time I’ll copy the IP address. It seems to be giving a perfect answer. So let’s do one thing. I’ll go to etc resolve con f. I’ll just comment the earlier entry out and I’ll create a new entry name server followed by the first IP address name server followed by the second IP address which is given over. Perfect. So now that we have proper entry, let’s try to do anslookup on simple ad kplabs in. I’ll press Enter and now I am able to get the perfect response back. Great. So once that you have done this, then you can go ahead and do a realm join. So let me just copy this command. I’ll copy this up and let me just clear the screen and I’ll press Enter.
So when you do a rand join, basically you will have to give the password. So this password is the one that you had given while you were creating the simple ad instance. So in my case it is password one, two, three, hash. Now it basically asks you for the password one more time and one of the funny things is that it is shown in the clear text. So once you enter this, just wait. Perfect. So you see the command has executed and this is the last output that you should find which is successful and rolled machine in the realm. Now, I believe this is one of the bugs where it asks you to enter the password again. When I had entered the password, now you see, it is asking that password one to three hash command is not formed. So this is something that needs to be fixed anyway.
So currently the machine is successfully enrolled with the realm of simple ad. So now this part is done. The next part that we must do is that we have to modify the SSH config to enable the password authentication. So let’s do that. So I’ll do a BITC SSH SSHD underscore config and I’ll just search for password authentication and from no I’ll put it as yes. So once you have done this, there are two services that we’ll have to restart at the end. One is the triple SD and one is the SSHD. So let’s verify if the triple SD is started or stopped. So it is started. So I’ll just do a triple SD restart. And now there are a few important things that you must do. First is the etc pseudos and paste the command which is present over here.
I’ll copy this up and a little down, I’ll paste it and I’ll save it. So once you have done this, just restart the AAA SD and restart the SSD service. Perfect. So now that you have done it, let me just log out of this machine. And earlier we were using key to log into this specific server. This time we’ll be using the credentials of our active directory. Let me just show you. So we use this command. Now we’ll replace the IP address of the EC two instance with the IP address of the new EC to instance. And currently, let me just replace the things. So we are using the administrator alterate ad simple ad kplabs in. So we know what this is and this is the user. So when you press Enter, it is asking for the password of the administrator. So I’ll use the password which is password one, two, three hash. Okay, so let’s try that out again. Oops, we did a small mistake, I believe.
So we took the domain wrong. It is simple ad kplabs in. This is where we were doing mistake. So let’s do it again. It is asking for the password. I’ll do a password one to three hash and this time it will log me in. So now, if you do an ID, you see in the G ID, it is saying it is from the domain users at simple ad kplabsertan. So basically, this user, this administrator user is part of the simple ad directory service. So in this directory service, if we add more user. These users will be able to log into any EC, to instance which are joined with this simple ad directory service. So this is it. About this lecture. I hope this has been informative for you and I’ll be posting this guide in the forum section so you can go ahead and write this out and look into how it really works. So this is it. Thanks for watching and I look forward to see you in the next lecture.
- Trusts in Active Directory
Hey everyone and welcome back. Now in today’s video we will be discussing about trusts in Active Directory. Now, this is an important topic for example, because you might see a question or two related to this specific topic. So let’s go ahead and understand more about this. Now, in order to understand trust relationship, let’s keep it very simple. Now, in AWS, if you remember, we can create a trust relationship for Im role so that we can have a cross account Im access. Now, during the video of delegation, one of the initial steps that we do is we add the account number of the source account through which the role will be assumed. So this trust relationship is between two accounts. The first account is the source account through which the role will be assumed and second account is the actual account where the cross account role is created.
So this is related to AWS. Now, even in Ad you have a concept of trust. Now in Active Directory, domain to domain communication can occur through trusts. Now what happens in trust is that once you have the trust established, you can have a secured authenticated communication channel between multiple entities within your Ad domain. Now, trust also enables you to grant access to resources like users, groups and computer across the entities which are part of the trust. In this diagram you will see that there are two active directories and you have a trust which has been established between both of them. So this is a very simple diagram. Now, few important part to remember is that trust can either be one way or two ways. So there can be a single way trust or a two way trust. Now in a two way trust domain from either side can access the other side.
So that is only possible with a two way trust. Now, the question is what will it do by accessing the other side? So we already discussed that by accessing the other side you can get information related to the users, to the groups and computers across the entities. Now, in the following diagram you have a single way trust from your domain one kplabs internal. So this is the direction of the trust. So domain one is basically trusting the production and once that trust is established, then any users or any groups which are stored will be accessible from the other entity. Now, for the AWS workloads, there are a few important parts to remember here. Now, let’s say that you have an AWS Active Directory which is currently running here and you can have various workloads. Like you can have workloads related to Management Console, you can have easy to instances, you can have applications, et cetera.
Now you can because let’s say that you want to enable AWS Management Console login via Active Directory. This is something that can be done in a very straightforward way. Generally what happens is that we create Im user, then we share in the sign in link, et cetera. Now, instead of doing that, you can just create a user within the Active Directory and your user can log in via the ad credentials instead of creating the Im user in your AWS account. So that is as far as the Amazon console is concerned. Then you can also integrate Linux as well as Windows instances with Active Directory. Now, for Linux instances, we have already seen on how we can make use of the ad credentials to log in to Linux servers via SSH. Now, even for Windows it is pretty straightforward. So that is the second part. Now the third part is the applications.
Now there can be applications like SQL Server, let’s say, where you have Adaware workloads. So Adaware workloads here are basically the applications which are aware about ad and you can go ahead with the authentication related aspects with ad. So let’s say that you want to log into a SQL Server here, then you can log in the other ad credentials. You do not really have to maintain a separate SQL Server credentials here. Now, one important part here, if you will see in this diagram, your Microsoft ad has a trust with the onpremise Active Directory. So this is a one way trust which has been established from your cloud Microsoft ad to your on premise Microsoft ad. And if you’ll see over here the on premise Microsoft ad has the on premise user credentials which are stored over here.
So let’s say that if a user wants to log into an AWS Management Console, or if a user wants to log into EC two instance, or if a user wants to log into a SQL Server, what can happen is the user can make use of their Active Directory credentials to log into any one of them. Now, all of these workloads, if you see let’s say, management Console, Linux instances, SQL Server, all of them will be connected to your AWS Microsoft ad directory, all right? So all of them will be connected to this specific directory and this directory has the trust with the on premise ad where all of your users and their credentials are stored. All right? So this is the trust where authentication and authorization can happen. Now, one important part to remember is that since there is a communication that needs to be established between your ad and on premise, you need to have a VPN connectivity, specifically when your on premise ad is within the private subnet.
All right? So I hope you understood at a high level overview what this diagram is all about. Now, few important part to remember specifically for the exams, that if you already have an ad infrastructure and want to use it when migrating Adaware workloads to the cloud, you can use the ad trust to connect the AWS Microsoft ad to your existing ad. So this is very similar what it basically says that this Adaware workloads that you see in point number three. So if you want to migrate these adaware workloads from your on premise to AWS, then you can connect them to the Microsoft ad which is running in AWS, and also establish a trust between your AWS ad and the Onpremise ad. When Onpremise ad has all the user credentials which are stored.
Now, once the trust has been established, then users can access the ad aware applications as well as AWS specific services with their Onpremise Active Directory credentials without needing for you to synchronize users groups or passwords. So that basically means that once that trust is established between your AWS ad and on premise ad, you don’t really have to do a full sync. Trust is good enough where the authorization and the authentication can be verified with the on premise ad where the user credentials are stored. So that’s the high level overview about the trusts within the Microsoft Active Directory. Do remember the concept of trust, specifically the One Way trust, and also remember on how exactly this configuration looked like at the architectural perspective.