 Welcome to the second part of securing servers with Okta. In the previous video, we just had a quick introduction about what we want to do and why. In this video, we're going to actually start configuring our solution. The first thing we're going to do is get an Okta developer in advanced server access accounts. The Okta developer free account gives you the ability to secure your own apps, as well as apps you can share with your development team, such as advanced server access. Then we're going to configure our first project and actually integrate with the server so we can have that login without requiring keys. So to remember how this is going to work out and the reason why we are setting up things this way is that traditionally, when a user needs to access a server, they would already have a key that was set up, for example, in AWS or GCP, that key will have a very long expiration time. In the meantime, until that key gets expired, many things can happen. That key may be lost or disclosed or accidentally shared with someone that it shouldn't. And the solution actually makes those things not possible. So instead of having a preset key for accessing the server, the user has an agent lightweight running his own desktop that when he types in SSH into a server, it will route this user to login at Okta. And only after the user gets the appropriate authentication and authorization, they get a short live type disk key, which will be used to negotiate that encrypted access with the server. From there, the server has an agent that also establishes that trust and connection. And then the server will also audit this information for the future in case the security administrator wants to see what happened without having to log individually into those boxes to take that information. Okay, enough of going through this layout diagram, let's actually start this configuration. So first, we're going to get the developer free account and you can follow along, by the way, if you would like to head over to developer.okta.com, hit sign up here, enter your data and finish this form. You're going to get an email in your inbox. You just click link and it will lend you here. Feel free to pause this if you need some time to follow along as well. So as soon as you are in this page, this is the place at Okta where you will set up your applications which you want to integrate and have authentication or authorization from Okta. You can use Jots and OAuth, but in this case here, I'm going to integrate my servers. Again, Okta can be used for securing your own applications as well other applications your team collaborate or work around together. So if I'm working with my developer engineers and engineers probably I would like to share within or work within on my AWS account which I can have here configured or GitHub. So if we have a team on GitHub, we can all collaborate around the same place. One of those places again is advanced server access which is an additional module that secure servers for you. I'm going to add it over here. Oh, and as soon as I'm done here, I'm going to assign this to a group. For now with the group is everyone. Typically the best practice here will be creating a group called let's say ops or developers and having just the right people assigned here with appropriate access to the servers. I'm starting from everyone just for the sake of completing this tutorial. Everyone is in the full group at Okta which brings the user that subscribed to Okta plus anyone else that you can create in the directory. Cool. Now that I have this done here, I can follow the step-by-step instructions provided to associate my Okta account of the developer with advanced server access but I know these steps from hard. So I'm just going to execute here. You can follow along if you want to. First thing I'm going to sign up to advanced server access. There's a link here down below if you would like to do so as well. And I'm going to pick a team for me. The team is basically the name of your tenant. So for me, it's going to be Fred security dash death. So I'm going to use this one for development purposes, saving this information. And then I'm going to start copying information over to Okta. First information I'm going to copy is this base URL which is used by Okta to know where we're going to connect in advanced server access. The second the audience restriction. Cool. Now I'm going to hit save here in after I hit save. That's very important. Hit save first. I'm going to click to copy this metadata information, paste it over here and hit my authenticate with Okta. Okay. So what happened here is that I got these two products talking to each other. So now my Okta developer tenant knows advanced server access exists. And this advanced server access will provide or interface access to my servers. So even if I log in here straight from the Okta dash from the Okta admin console and I go to my dashboard, I can actually go here, open advanced server access and go straight to that place you just saw. Cool, right? So this completes the first step. Now we need to configure our first project. So we have a server, we have a client and having that SSH connection without requiring keys. So let's do this. For this task, I need to stay in my advanced server access and create a project. A project is a place where you can have many servers together. And usually it represents either an environment or a place where you have your servers, a data center, an AWS region. It's really up to you to think about what would make most sense for you. For me here, it's gonna be the test project. And then I'm just gonna hit submit here. I'm not gonna play around with these settings, but we're gonna see those later. And from here, one thing I'm gonna get is something called an enrollment token. What an enrollment token does, it allows a server to securely subscribe to a project when that server comes up or when that server is first launched. It's a way we establish truth, trust, sorry. So we have that single sign-on for the server. So I'm gonna provide here server token and copy this information, which I'm pasting over on my own notes. But again, when a server comes in and wants to have that authentication from Okta, when the server starts with the agent, the agent would use that secret to establish a secure connection with your servers here. Beautiful, fantastic. So let's go to the previous slide and continue this. Now that I have that enrollment, let's actually set up the server. And you're gonna see that I'm gonna use that enrollment token. So to set up the server, for sure you need to connect using an SSH key because it's not yet integrated to Okta. So let me grab the server I brought over today. So this is a server on AWS as you can see. So it's an Amazon AMI, but we integrate with any other Linux servers. So for doing this setup, I'm gonna use a series of notes I have. Let me find those. I'll make sure of having those available as well for you in the notes so you don't need to know these four hearts. So let me take off my notes. So to install the server, the first thing I'm gonna do is just, actually download an RPM and run an installation here using sudo. Okay, so this will give me something installed here, which is the server agent called SFDG. It's already installed, beautiful. Now I'm gonna have my enrollment token here, which remember is that secret I need just to do that connection. So let's patch that up, okay. Now I need to just enter this information here. One thing very interesting is that you can also set something we call canonical name, which is basically the name of the server that people will know in order to access. If you don't add that people when they access the SSH, they can call that the host name. So they would use the server host name, but I wanna use my name myself here. So it's gonna be my engine next one, because maybe I want to install engine next here. I can set up this in a file. Let me paste that over here. You know, I just need to restart my service. Okay, cool. Now that I'm done with that, if I head over here and I did everything right, my server also enrolled in a project test. If I go here to my project, I can see the server listed. So everybody who's associated with this test project can actually access the engine next server. Actually, by the way, let me add my group everyone here. To the server. So my users that belong to this group again will have access to the server. That includes myself. Okay, fantastic. Now that we installed the server agent, as you could see, I just used bash scripts here, bash command, so this could be automated any way you wanted. Now it's time to do my side, the client side. So let me exit here. So this is my computer. And remember, in order to access my server without keys, I need an agent. So to install this agent, I can go to the downloads page of that, or I can use actually pre-commands or utilities like a brew or brew cask in order to get this set. So let me remember where's my note. I lost it here. Bear with me. Okay, where is my... Oops, right over here, sorry. So let's go and do that. So the first thing I do is brew, install, octave and server access minus cask. And that again is installing the client. So let's wait a few seconds until it's done. Okay, now that I'm done, I just need to enroll my server. Let's do this. Here I'm gonna enter the name of my team. As you can see, I already have all their teams. I'm working on, but I can enter my name here of the team and I'll be required to log in as well. So, okay, when I do that, I'm required to establish trust between my device. And as soon as I'm done here, you will see that I'm gonna get that approval and enrollment is completed. So what it means is that as a user, I'm tied up to this machine and I can actually get the access to the servers only through this machine and no other place. Okay, now that I'm done with this configuration, I just need to access my system. So let's do this. I can do two things. First, I can just do an SSH config. So I can use SSH directly or I can use the command SFT, which is basically that client. So what I'm gonna do right now is list all the servers I have. So I need to log in as you can see. Okay, approve that request. And you can see that I can access my engine X1. So if I do an SFT, SSH, engine X1, that will grant me access to that Linux box I wanted to. So as you can see now, I no longer need a key to access my server. And not only that, all my access is audited. So my administrator can see that I access this server at a certain time, a few seconds ago, using a secured client, which is this one, which we installed using brew, in using a fingerprint key here, which is ephemeral and tightly scoped. Also another benefit of using advanced server access for this use case is that the accounts are individualized in the server. So if I go and show, you'll see that I have my own user here. This user, by the way, doesn't have a password in this computer. All this access is always done through those ephemeral certificates. So back to it, what we did, we got the Octa developing an advanced server access account set. After that, we configured our first project, installed the server and client agent, and we ended up by logging in our user.