Best Practices for NSO RBAC and AAA Deployment

I Hello, good morning. My name is Fernando Alberto and along with my colleague George Mira, today we are going to deliver our 3rd session.00:01Of our NSO journey?00:20Today we will talk about the NSO R back and AAA, and during this session you will have to be free just to ask any question that you want. So before we begin, let me just start. Perfect. So, as we were saying just the very beginning eh, today we're going to take a look at.00:22The R back and AAA deployment and best practices. So today with me we have David Kissada and myself Fernando Viro, we are customer success specialist in the internet and massive scale infrastructure.00:42The topics for today that we will review is the NSO access control triple AAA overview, the NSO authentication, the authorization, and the demo. And as a, as a reminder that we have here, every time that you have any comment or any question on the on the right side left, on the right side but.00:56Bottom bottom of the Webex, you will have the chances to start chatting with us. If you have any comment or any question, you will be have the answers there.01:15Now, for the very beginning, let's talk about the NSO access control. The user is logged into the NSO through the CLI, the netconf, through the SNMP or via the web UI.01:26Now in either case users can need to be need to be authenticated. That is a user needs to present the credentials such as a user and password or maybe a public key just to gain the access. As an alternative for restconf, users can be authentic.01:41Created via the token validations.02:01Now, question that we will need to do is how am I going to group these users? What are the actions that they are going to have? Which is the type of access that they are going to have allowed to to go to the, to the NSO? Every time that we're going to talk about this, the 1st thing and the 1st.02:04Just the entrance to the.02:24To the NSO and the basics of triple aaa, it's authorization, it's authentications. Now, once a user is authenticated, all operations performed by that user need to be authorized. That is certain users maybe allowed to perform certain tasks, whereas others are not.02:26Now this is called authorization. We differentiate between the authorization of commands and the authorization of data access. In this case we can see here that we have the planning, up cooperation, engineering cooperations, and edge operations. Each one of those groups, it's going to be a.02:45Allowed to perform certain type of actions. It does not mean that they are only going to access to the device or only just to perform a certain type of configuration changes.03:05Meaning that they also will have access to a specific data. Now we can start talking about the AAA, authorization, authentication, and accounting. Before we go into deep in these, we need to define them.03:16What is what? Authentication. Authentication it's the time when I need just to validate who I, who am I And this is going to be by a username and password, the username and a public key, maybe using a token.03:33Or using external authentication. Then once I am authenticated, I the access that I am going to gain, I will need to be defined which type of actions am I authorized.03:50In this case we can have here the NICM groups and rules and also the external authentication made previously in the in the step of the authentication side. On the NICM groups and rules, we can also have here the actions that I can perform at my.04:06At my NSO instance. Last but not least, we have here the account ability. Here's where we're going to find the audit.log, the syslog and the internet log processing. Accountability means that I am already authenticated, I am already authorized, and I am performing actions, meaning that any action and every action.04:25That I am doing, it's going to be locked. However, on the NSO, which type of interfaces am I going to be able to access to? Now NSO has two northbound interfaces intended for human usage. We have the CLI and the web UI.04:44Now these interfaces are described in NSO CLI and web UI interface respectively. Now there are also programmatic java, python, and airline APIs intended to be used by applications integrated with the NSO itself.05:03In this specific case here we have the netconf, when we are going to run through TCP, SSH, the one that it's building or the open SSH. In the case of we will send HTTP requests.05:20In SNMP, we are working with version one, version two C version three, and also the alarm on the mibs. And last but not least, we have the mapping, the username password and the mapping authenticate too. From previous sessions we were seeing we were watching that the mapping is going to as the name says.05:35Map all the, the logins that we are going to have with the username and password and given them this into the access to the NSO. So we were just talking about the triple AAA model and now it's time to start talking about the authentication.05:54We will start talking of the NSO authentication by the methods that we currently support in the NSO. 1st of all, we have the username and password. Username and password is the one that they can be defined and used in the CLI.06:13Netconf, restconf, SNMP, web UI, the external authentication, PAM, and also the local authentication. Now here's gonna be a note that I just made. Now the authentication order is going to be done in the nCS.com.06:30File. On the triple AAA and the authorization order, you will need to define which is the order that you want to follow. The ones that is at the beginning is the one that you are going to be the 1st one to jump in.06:50Then we have the public key. Public key is going to work with the CLI and the netconf methods. Last but not least, we have the token validation which is going to going to apply into the.07:02There are also another ways that we can just start talking about the authentication, which is the IPC port access. Now these are, we need to be defined some kind of libraries that they are connected. We have the NCS CLI, the NCS load, the network subsystems, and etc.07:20Now users with the users with shell access are trusted. However, users must be in a Linux group which is allowed. There are certain type of rules that we are going to define before that we are accessing these type of users.07:37Also everything that we need to do, it's need to be done by the path that we are going to give them. In this case the configuration options, we have this path and we are going to define how they are going to how they are going to be invoked invoked. We can also restrict some IP access.07:52And eh, it is also useful that we are going to have these allow allow these, these users and also to, to block them in the sense that we are going to define which are the parameters in the IPC port access. How important does I know that we have here?08:10If this is set an IPC access check is disabled, client connection will fail. We need to be aware which type of authentication method we are going to use and how we are going to define. During today's session, we will talk about this local authentication.08:30Now we're going to define some best practices here. 1st of all local authentication is going to be, it is local authentication is practical in test environments. It is also useful when we want to have one set of users that are allowed to log in.08:47To the host with normal shared access and another set of users that are only allowed to access the system using the normal encrypted, fully authenticated northbound interfaces of the NSO, meaning that this type of local authentication, it should be more just to add it in the in the.09:03And that we are working in a test and controlled environment.09:23But the 1st thing that we need to know is that I need to define how am I going to access locally into DNS. So we previously saw in sessions that we have a file called called the nCS.com.09:28File. This NCS.com file or as we call it the blueprint of the so is the one where you are going to define how am I going to access which interfaces are allowed to interact with the users normal, and also how am I going to start the engine of the.09:43NSO.10:03So, if we are talking about local authentication, the 1st thing that we need to do is just to allocate ourselves in the triple A sorry in the AAA environment. Here we can see in this screen that we have an extract of the output of the NCS dot.10:05From five. As you can see on brackets we have the late initiate and the finish of it.10:24Then we can see here that we have PAM, external authentication and local authentication. As you can see, I have here PAM, is it enabled? True? External authentication, is it enabled?10:31False, local authentication if is it enabled? True. So this is how we are going to define which type of method we are going to use to authenticate ourselves in the NSO, and the question maybe rise here.10:47No.11:07Why do you have both in true and when do you have one in false? Is it going to be any conflict? Not at all. It does not mean that I am only going to use one type of authentic of authentication. It means that I am allowed to to use multiple and it does not matter if you are going to depend on only one of them.11:07Now, how does it looks like? If I access into the NSO CLI and I do a show CONFIGURATIONA authentication users user in this case admin which is one of the users that we currently have, here we have the, the user ID.11:30The group ID.11:50The password encrypted and also the SSH key directory along with the home directory. These type of variables are going to be defined per user that we are going to consult. So in this specific case, we have an instruct that we have the user admin and the user opera.11:51And as you can see the SSH key here and the home directory, both of them, they are just going to be pointed to the specific user. So once that we talk about the local authentication, it's time to talk about the external authentication.12:11Now a common situation is when we wish to have all authentication data stored remotely, not locally, e.g., on remote radios or LDAP server. So this remote authentication server typically not only stores the users and their passwords, but also the new.12:32Information.12:51Or if we wish to have not only the users but also the group information stored on a remote server, the best option for NSO authentication is to use the external authentication. Also, we will need to have this type of configuration made in the nCS.com file, just like I showed you previously.12:53And we also in the external authentication phase, we can use a package authentication.13:12But how's it going to work? Now, if this feature is configured, NSO will invoke the executable configured in the NCS config triple AAA external authentication executable in the nCS.com.13:19And pass the username and clear the text password on STDN using the string notation, user, and password. Now let's face, let's let's say that we are going to create a scenario here. E.g..13:36If the user Bob attempts to log in over SSH using the password secret and external authentication is enabled, NSO will invoke the configure executable and write Bob secret.13:51On the STDI, on the STDIN stream for the executable, the task of the executable is then to authenticate the user and also establish the username to groups mapping. Now, e.g., the executable could be a radios client which utilizes some pro.14:06Vendor attributes to retrieve the groups of the user from the radio server.14:27Now if authentication is successful, the program should write, accept, followed by a space separate list of groups that the user is a member of. An additional information is described here on the right side of the diagram.14:33Again, assuming that Bob's password indeed was secret and that Bob is a member of the admin and the lemmers group, the program, the program should right accept admin lamors UID, group ID, supplementary group IDs.14:49Home on index in the standard output on then the exit. This is the process that we are going to use this external authentication. We are not validating inside the NSO, however, we need to validate that we are sending this information to be validated into an external system.15:05So, this is the format of the output for an external authentication program when authentication is success is successful should be like this. If authentication failed, the program should write reject or abort possibly followed by a reason or forth.15:24The rejection and trailing new line, e.g., I don't know reject but password or just simply abort.15:43When we're just comp, authenticated correctly, what we are going to have is this. This is the output that we are, that we are looking for. 1st of all, we have the accept, meaning that we are already correctly authenticated.15:52But then we have the groups. A groups is a space separated list of the group names the user it's a member of. Now the UID is the Unix the Unix integrate user ID that NSO should use as a default when executing commands for this user.16:07Now the group ID is the Unix integrated group ID that NSO should use at default when we're using this user. Now the supplementary group IDs this is going to be a possible there or is going to be empty.16:24It is also going to allocate which type of group IDs am I inside in the, as, as the user I am authorized. And then we have home. This is the directory that should be used as home for this user when NSO executes commands on behalf of this user.16:42Now we are going to talk about the package authentication, which is something that previously I was mentioning to you. Now the package authentication functionality allows for packages to handle the MSO authentication in a customized fashion. Authentication data can in example be stored remotely.17:03And a script in the package is used to communicate with the remote system.17:23Now compared to external authentication, the package authentication mechanism allows specifying multiple packages to be invoked in the order they appear in the configuration. NSO provides implementations for LDAP.17:29SMLB two and TACACS plus protocols with packages available in the NCS directory package authorized. Now additionally, you can implement your own authentication packages. Authentication packages are NSO packages with the required content of a.17:44Executable files scripts to authenticate.18:04Now this executive basically follows the same API and limitation as the external authentication script, but with a different input format and some additional functionality. Now, other than these requirements, it is possible to customize the package arbitrarily.18:08Here in this snapshot that I just took from the NCS.com file that I previously showed you. It's the one that I I, here we can detect that we have the external authentication and I have a script in this case is an executable, which is my test out.18:26Authorization.sh.18:46Now when a user's logs in over netconf, in the CLI using the built in SSH server with a public key login, the procedure is as follow. 1st of all, if the SSH key authentication is set to local and the SSH key is in the path that we are just matching.18:50If this is going to be matched, then the authentication succeeds. Now, otherwise, if the SSH SSH key authentication is set to system, local authentication is enabled and the SSH keys.19:09Are going to match with the presented ones, the user authentication succeeds. Otherwise, if we are going to, have the pop key authentication is in the system and the user does not exist.19:26But the user does exist in the OS password database, then the authentication succeeds. Otherwise the authentication fails. This is how the method of the public key login is going to work. As you can see here we have three types of different scenarios that they.19:42They can match and they can authenticate the users. We only need to know which type of scenario we are going to fall in.20:02After we were just mentioned about the authentication, let's say that now we are completely authenticated. Bob is currently able to access the NSO, then we need to know which type of action is Bob going to be allowed to perform.20:13That's why we need to do a step here. Let's, before we go, what user are we talking about? Now, what is authorized to do? Which group does it belongs and which actions can and cannot do?20:34These are the questions that we need to start asking. Every time that we are going to authorize someone to access into my NSO, meaning that I am not only going to give access to the, this person, but I need to define certain type of rules, groups, and.20:50Actions to be performed by this user. That's why we will talk about now of NS NACM in the NSO.21:10So the process is pretty simple. We are going to synthesize it, what we are going to find here is that we find users, those users are going to be allocated in some group users, and I am going to apply a certain time of rule list.21:18That they will allow this person to perform certain type of actions. On the NSO, what we can find here on the right side, what we can see is that we have the AAA users, we have the NECM groups, we have the NECM rule list and the rule structure that we can have. As I told you at.21:38The beginning, we need to enable which type of action we are going to perform. We have the rule list and also we have the path statements, meaning that I am not only going to be able to execute any command, meaning that I can be allowed.21:58Or blocked to access certain type of devices that I currently have. Now, this slide illustrates the three sets of objects defining a rule. 1st we have the action type options.22:14From the very beginning, this is just a binary selection. Do I permit or deny an action? Then we have the access operation options, where I can find here the CRUD type of actions which are create.22:31Create maybe a new data node, read a data note, modify an existing data node, delete a data node, and also execute an operation. And then we have the rule type options.22:49Which is protocol operations, control access to remote procedure called RPC operations. Then we have the notification which is the control access to notification and the data note, control access to data nodes in the using the X part.23:04It comes to my mind here that we the type of action that we can define. It's that maybe Bob, it's only going to be allowed to execute and perform actions in the iOS type routers. While he's not even allowed to perform any action on the iOS XR routers.23:23However.23:43He can have read actions to those iOS XR routers. That is how we are going to play with it in the sense of the rule type options that we have on the NSO. Also, I wanted here to show you how these principles they are going to do in this.23:44Diagram. Implement R back as listed. So 1st of all, I am going to authenticate the users.24:04Previously we saw that they are already authenticated. Then I am going to map the users to the groups and then I am going to assign roles. In this case, these are the rule list to the groups. Then I will assign privileges to the roles.24:12It's just the role, the rule list that I am going to apply. On this slide we can see the relationship between the various objects that are part of the AAA and R back. So, users and members of one or more groups.24:31Group is referenced by the rule list. Rule list references several individual rules and the rules provide access to individual actions. Everything is involved and.24:46Even though it sounds kind of complicated, we do have three entities that we need to map, the user, the, the user group, and the rule list. Now, this is an example that we will have about authorization.25:01Let's assume that we have two groups, the admin and the upper. We want admin to be able to see any the XML three route at-triple a, but we do not want users members of the upper group to even see the triple AAA three.25:17We will have the following rule list and rule entries. Now that we use the XML data from to exemplify. This example applies to all data for all data models loaded in the system.25:36On top of that, we have the rule list and it's going to be applied to the group admin. So here we can see that if we go through the path and then we start with the access operations, they will have the CRUD operation.25:52And the action is going to be permit. Read, create, update and delete the admin group. In the rule list they are allowed to do it. And then we can see that we close a rule list and then we open a new one, which is the rule list for upper group.26:11If we go to the access operation, the CRUD operations are there, read, create, update, and delete, but the action it's going to be deny. Now assume that we have these two groups, the admin and the upper, and we want admin to be able to see the XML three rooted at the.26:30Dash AAA.26:50But we do not want users who are members of the other group to even see the triple aaa. Or we were just what we were just mentioned before. So what I will need to do is just to spell it out, the above defines four elements to match. Now if the NSO tries to perform a netconf operation, which is the operation edit config.26:52And the user who runs the command is a member of the upper group.27:12And finally, it is an execute. We have a match. If there is so, the action is going to be denied. How are we how are we going to do this? Because if we can see here on this snapshot of the of the XML file, here we have that we made some modifications for.27:16The route list in the upper group.27:361st of all, we are adding here the contexts the rule name edit config RPC name edit config. And then we have the X D the path where we are going to be matching HTTP, tailleft.com Jan ACM netconf. In this case, we.27:40Need to also define the access operation which is the execute.27:59And which is the response that I am going to get a deny. All of these needs to match in order so the rule will apply. Now if we want or explicitly specify parts into the XML three using the expert syntax, this is how it's going to look.28:04Now this explicitly allows the admin group to change the password for precisely the user when the user is using the CLI.28:24Had path being triple A authentication, users, user password, the rule would apply to all password elements for all users. Since the path leave completely identified the notes that the rule applies to, we do not need to give tail triple AAA for the model name.28:33Lift. Here we're going where where we are going to match it's exclusively for the user, the CLI, he only, he will have access to read and update and the action is going to be permit.28:53So as you can see, we can do, we can go as far as far as we want every time that we are just creating a user and also we can limit or give the, give the actions that we want to any type of users.29:09So, here we can find the documents for the NSO AAA infrastructure. I believe that Mike we can put this information here. Just a second, sorry.29:25On the chat, I will just put this information here I will put it on the chat.29:46George, maybe you could.30:10Pass it by. Sure, I will paste it. Let me just pass it to you. Here you go.30:12Okay, yeah? And now it's time to take a look a little bit of how can I take advantage of these capabilities inside a local installation of the NSO.30:35So now I'm going to prepare the demo. I'm pretty sure that now you can see my screen here and then we will start with this. So, we're just going to access.30:52With the username and password, of course, we're using here local authentication. So the username and password, there it is yeah so as we previously saw here we have all the devices that they are currently this is the menu that we, that we have here in the so eh.31:11Then if I go here and take a look at the devices.31:31Well, before we go, we go here on the upper right side corner, we have here that we are logged in as admin, we can just log out and well we can just choose the theme that we, that we like if it's light or if it's dark, whatever. But the main thing is that we are, we can see who is accessed here on the admin.31:37On the admin side. It's working here at the same time for the, for the, for the type of user that you are going to, to, to use. Then.31:58Here we also have the device management, the device group, and also the authorization groups. If we go here into authorization groups and we go to the group default, here we can see which are the users that they are mapping into this authorization group. We can see that we have the admin user.32:14The upper user and the read user. So these are the ones that they are allocated here so they can as they are in this default authorization group, meaning that they can, they they are inside the the NSO. But if we go here on the left side.32:33We have home devices services and if we go to the config editor and we click here, we can see all the models that they are available in the NSO. The one that they are going to, we are going to take a look today is the one that it says AAA.32:53So if I click on triple A here we have authentication and then I have users. As we are just in the configuration mode, we can see that these are the type of users that we currently are working in the NSO.33:08So, here what we can see is that we have admin, upper private, public, and the read user. And you can tell me Fernando I saw previously in the authorization groups that you have the admin upper and read user. Why don't we have private and public?33:24We can add it, we can add it here and just be allowed to perform the actions on the authorization group of the NSO. If we go back home, then we will have to find another model that we saw on our session that is the NACM. NACM here is when we are going to default.33:41Find the groups and the rules.34:01Here we can see that we have the rule list and if I click on the information icon, it's going to tell me this is the rule list, the path that I have, and also the access that currently has to the access to the rule list, ok? And if I go and take a look and take a look.34:04But the group it's going to be the same.34:24So group NACM, NACM groups group, ok? Here what can we find that we are currently using these two groups, the admin group and the upper group. If I click here in edit config, this is what I am going to get.34:26Now, for our purpose, what do you think is going to be more fun? If we create above user, I believe so. If we go here to the AAA and I go to authentication and then I go to users, simply as that I am going to position myself in this addition button and then I will start creating my.34:47Bye.35:07New user. In this case we are going to use Bob user, ok? You the user ID, I can just map it with the number one, sorry, then here are the number one, I am going to select another password for, for Bob.35:07Let's not complicate ourselves. Now here on the SSH key directory. Every time that we are going to create a new user, something that we saw previously is that we need to map it to the unique key directory and home directory.35:28Remember we need to define it here.35:48Like bar NCS, homes, and we have Bob and then/dot SSH. This is with the SSH key directory that I am going to have. And if I am going to.35:50Do the home directory, what I'm just going to to to take here is select it without the SSH, ok? This is it. This is how it's going to look like. This is my new user and this.36:10Are all the settings that we, that we have. So now I'm going to click here in confirm.36:30And as you can see here we have the new user, Bob, and along with the UUID, the group ID, password SSH key, and so on and so on. So if I just go here to the commit manager and take a look at the config, this is how am I, what I am going to get.36:35Which is the the what is the type of information that I am going to commit here is that I'm creating a user Bob along with the user ID, group ID and everything. So I just go and click in commit, ok? Just commit. Commit finished successfully at.36:56At the timestamp that we have here, ok? And if I go and I go to the configure the configure editor here I have Bob in my, in my users, but if I go into the authorization groups, it means that I do not have this user Bob here, ok?37:15But 1st things 1st 1st I need to check out if I can, I if I can access as Bob into the NSO. So I am going to do a logout, and then I will start doing the username and password, guess what it is.37:34So, great. Now I'm back and I am allowed to access here into the NSO, ok? So as I just did this check, now what I am going to do, it's back to the admin user and then.37:52I will add the Bob user into the authorization group. Here we have, which is the local username, it is going to be Bob.38:12Now, the remote the remote user is going to be a remote name. The remote name we are going to have it here like admin, the remote authentication is going to be a remote password, of course.38:29And here we are going to to put the, the, the password that we have. Then I am going to put here and add it. See, now we have Bob here on our.38:46Sorry, on our default authorization group, we have admin, we have both, we have opera, and the read user. This is what I wanted to show you that if rather than we have here in the configuration editor, another user's created, we need to select which one.39:03If I am going to you to allow them to the.39:22To the authorization group. Now, so far what have we, what have we saw it means that I already created a user and I can authenticate it, but I need to start creating some authorization actions, meaning that I need to go.39:27To the configuration editor up editor NO. Sorry, yeah. I was just going too fast.39:47We're just going to click here on authorization groups and the and the changes will be done. Now if I go to the configuration editor, then I will need to start allowing this into the NACM rules, ok? So if I am going to, into the NACM.40:03The rules. Now I need to create, let's create a group for Bob, yeah. So Bob it's only going to be in the list of the read users, ok? Which is.40:22That's what we are going to find here. We are going to create a rate group. Okay.40:42So we click in confirm. Now read group. In this case we are going to assign the group ID number one and then the user name. In the username, what we will do is just to add Bob.40:49Okay, now these are the intentions that we have here on the, sorry or the we are assigning and creating a new group just to make sure that we are applying these whole rules that we saw because we we on the.41:07On the presentation, we saw that we have the users, we have the group users, and then we have this set of rules. So we are just applying two of them here that it is.41:26That we have the, the rules and sorry the the user and the user group. Now, if I need to apply the last one where I am going to find is I need to go back to the NACM.41:38And then here I have the rule list. So, now what I need to do here is that I need to add an sorry here and we are going to use the read.41:54Rule, ok? And then confirm. Yeah, here it is. Now, something that we saw previously is that we can just go here and we need to apply these rules to a group.42:11So which group am I am I going to to apply this? It's going to be the, sorry, the group read group, ok? Here we click on confirm.42:30Yeah, and then I need to create a rule for them. So this rule it's going to be named the read sorry the read rule.42:46Action. It's going to be a permit or deny. It depends which is the type of action that I am going to to use. We are going to choose the deny and then I click on confirm.43:05Okay, so here is the rule. Readful. Here it is that the action that I am going to use is ah deny. And then what I am going to do is which type of action is this guy going to be denied?43:20If I click here again we can see that this is the path of the sorry of the of the rule type that I am going to create which is NACM and a released in this case where rule, read rule, and the path that I am going to create.43:36Here for our purposes, what we are going to deny to Bob is that he will not be able to do a device sync from, ok? So this is the type of action that we are going just to.43:54Ask to the.44:14Sorry, to, to Bob. I go here, then I can just go back. Yeah, now which other action can I put to Bob over here? Well, I can also just deny the configuration domain into the.44:16Into with both. So, this is going to be a deny config domain, ok? Deny deny config domain.44:36And here, what we are going to do is that it's also going to be denied. Now the access operation that we will going to deny this guy it's going to be create read.44:54Update, and delete, ok? And the and the path that we are going to do this is that maybe I am going to tell him that the device on devices, sorry, device.45:10And let's let's say that all of the of the devices they are not going to to is not going to access to config and stash.45:27Yeah yes ok now after this we can see that we have these two rules apply. Just let me.45:44Let me just yeah oh let's go back. Here we have my two rules that I just created for these purposes, ok? Now these are only going to be applied into Bob.46:03Because we are just creating these rules to that specific group, ok? Now, how does it looks like, how does it looks like if I am going into the commit manager? Let's go here. 1st of all, what we just created, it was a read group.46:18We're the only one user that we have here, which is Bob. Now after that I just create a rule list and this root list is going to be into the read group and we created two rules. The read rule that it's going to not let him to perform a sync from and then.46:34Deny configuration domain, ok? Now if I go and I click in commit, so told me yeah you did correctly. It was great. Okay, so if I go back and I do a logout and I just log in as.46:55The Bob user, here it is, this is my soul, I go to devices and I select all the devices and I choose anction and I deny the same from. So this is the result that we are going to have from Bob.47:14Over here. And then if I go into any device, e.g., this iOS zero zero, and if I try to do an edit configuration here, I am not going to be able to change any configuration on any devices because of the NACM, sorry, oh yeah.47:33Of the NACM rules that I just applied. A quick one over here.47:54We can see here that I, as I am accessing as the Bob user, I cannot access to DNACM rules. Why? Because I am not an admin user, so I cannot change myself my own permissions and just deploy the actions that I just going to, to.47:59To, to do it. So if I just go back here and I log out and I access at the admin admin, then of course that I will just have here the NACM rules.48:17And I can have here that I have the read rule into the read group and all the.48:36I'm sorry and all the changes that I just performed and they are going to be applied into the persons of this read group sorry let me just go back. Yeah, read group and the username both.48:45So, any comments or any questions? I hope that in the chat that you are going to be able to, to, to reply it. But before we leave, let me just let me just share with you.49:00So finally, what is going to be the next steps here is that you may receive a survey after this event, so it's only going to take 2 min. It's just a really it's really useful that we have these feedback from your side because it makes us to create new content and also it has.49:22Help us just to improve the type of sessions that we are going to give.49:41So, this is everything from my side. Thank you very much for coming here today to this AAA and R back session. My name is Fernando Miro, just as a reminder, I'm here with my colleague George Midda and Somy Lubay. We wish you the best on this, on this Thursday.49:47Thank you very much and see you later.50:06