Hello and welcome back. My name is Tyler McMinn, and this is the Aruba Network Security Basics course Part 2 and Lab 3, hardening the mobility controller. In this second task, we're going to be configuring external admin authentication on our mobility controller. Let's jump on it. Now, that we trust our browser connection to our server, the next thing we want to do is we want to establish that as an administrator when I log into this browser or if I log in using SSH or whatever that I can authenticate against clear paths. Right now I have to use a local admin account to make changes to this mobility controller. What I'd like to do is use the same username and password against ClearPass as when I log in to my switches or and when I log into my controller, so that same network admin, whatever 14, that's in Active Directory or in ClearPass, I want to authenticate this centrally. Let's set that authentication app. We'll first log in to the MC. Again, I'm going to have to use my local admin here account just to get in. Once I'm in, then from there we can go to configuration, we can go down to our authentication, and we can set up an authentication server that we want to use. Right now, our authentication servers include just basically a default and internal server setup, no clear paths or anything like that. I'm going to create a group of servers, ClearPass, TACACS, or something like that. Doesn't really matter what the name is and then once I select that group and I looked down, there's no members to it just quite yet. Let's add a new server group to it, to the server list and the default is the internal, that's an existing server. Let's click and add a new server and then we'll put in the name, but you might notice here is the names really not that important, but the IP address is, that definitely needs to match the IP address of my ClearPass server. If I look at my design here, the controller once it receives a request from an administrator, it's going to bounce that request against this ClearPassed 10.0.254.1.23 server address. I can choose the type RADIUS, LDAP TACACS, Windows, whatever. Let's leave it at TACACS. You might notice that there's no port change or shared secret or anything like that just quite yet, that's coming up. Let's submit it and we should now see that the server name, the type, and the address has been added to the list. Let's now click the server and a new set of options pops up below. There is where I can put in the correct key, and I could change the port number, the timeout to transmit. I can also set session authorization, submit, and it looks like a ticket. Then let's configure one other thing before we apply our [inaudible] changes here. Let's go down to config, system, and an admin options. We were here in the previous task, where we went in and we set our authentication options to change the web UI to use our mobility controller server assert that PFX file that we had imported. In this case, we're going to change the Admin authentication options where if clear path does not tell us what our role is, then we just give it the root access. This could be a little dangerous because that's full access to everything. It's a best practice to either set a role as deny all or a very restrictive role like guess provisioning or something like that and will enable this, and then we can set MSCHAP for the username and password and set the server group. The server group that we had set up before, ClearPass TACACS is now available, so I think we are looking good. Let's go and submit that change. I need to leave this clear, my mistake. Let's go and submit the change no, MSCHAP, and then apply our opinion changes. This is going to save the changes so they are persistent. At this point, we can test our login and I could do this from SSH connection, I can log out and log back in. Within the controller though, you do actually have an option here to go down to diagnostics on the left-hand side, and under diagnostics, there's a AAA server test that we could run. Let's go to Tools and there it is, AAA server test and choose the server, this ClearPass server that we added in with TACACS you want to change your authentication method from MSCHAP, to PAP I had left it in MSCHAP and had to fix it. Let's not make that mistake again, it will log in with the network admin log in that I should be using everywhere. Then just simply a test, so long as I have a service that matches this, which I do, it is successful. That should have shown up on the ClearPass access tracker when I go to check this as well, and so I'm going to ClearPass and just validate that real quick. ClearPass go to my access tracker, and there we go. We have the network manager authentication that passed. This was just a quick request to just validate that it was working. Otherwise, there's no remote IP address there. Looking good, verify the test was successful, which it was, and now I can actually log out of my controller from this local admin account and log in as everyone should be doing with their own uniquely identifiable username and password. This way you're not blamed for something someone else does, it could change management, and look at that we've logged in successfully. What we want to validate now is what is the actual role that gets pushed out here? If I check at this updated login I can see that authentication did indeed pass, and if I look at the policies tab, it allowed me to log in as root Admin. The profile that it kicked was this TACACS Root Access, told the controller anyway that I should have that root level access to it, and that's it. We now have set up remote authentication.
