This article looks at the Quick Start menu for APIC GUI.
One thing I really like about the ACI (Application Centric Infrastructure) APIC (Application Policy Infrastructure Controller) GUI is how helpful it is. There are several products out there that have used the idea of putting a Quick Start within their product on the welcome pages such as VMware SRM and Zenoss, and now the APIC GUI has that as well as shown below.
Figure 1
When you click on the links under the Quick Start guide you get a tutorial on how to do it, as well as an optional video to watch. To the right of the Quick Start is a list of words and concepts that will help you familiarize yourself with networking concepts in general and ACI specifically.
In this article I’m going to deep dive on the second step Configuring User Accounts. Also, the first Quick Start step is toInitialize the ACI Fabric which I’ve already covered here. Much like the initial Quick Start, we have more Quick Starts that are specifically detailed for a certain subject. So, when we click on the ADMIN tab we’ll see the guide below.
Figure 2
Though we don’t always need everything included here, it’s important to understand it all so that we know what we do need in our environment. There are often default settings already configured for some of these options, such as key rings.
For those not familiar a key ring is much like its physical counterpart.
Figure 3
It literally holds passwords or certificates for you. To create a new key ring we’ll first create a certificate authority. Again, there is a default key ring, so this is not absolutely necessary, but will make for a more secure environment.
Figure 4
We can select whether we allow remote logins or if we should specify a certain role to allow people remote login. We can also select the Default Authentication. If we plan on using local users, or users the admin creates within the APIC, then keep it on the Local Realm. If not, you can select LDAP, RADIUS, or TACACS+ (using LDAP for Active Directory connections as well). The same can be done for Console Authentication.
If we expand the AAA Authentication object we see Login Domains. There is a default Login Domain called fallback which connected to the Local Realm and is there in case admins lock themselves out using external accounts somehow. However, we can create new Login Domains and associate users to them. These login domains can be connected to the Local Realm or LDAP, RADIUS, or TACACS+. They help keep the security objects and users more organized as well. For more information see the Cisco Documentation here.
Create a Security Domain:
Figure 5
We can assign users to these roles, or we can create custom roles from more granular permissions within each of these roles. We can specify whether we only want users to be able to read or read/write as well. Like most of the other tasks mentioned in this blog, in order to create a new role we simply need to highlight Roles and then use the Actions menu to create new ones. The roles/permissions will be available in a selectable menu for us to assign to the new custom role.
Configure Local Users:
Figure 6
Creating remote user accounts is similar to what we’ve all most likely seen in the past. If we’re creating an LDAP account, then we need to configure the LDAP provider first. Meaning, we need the IP address or host name of the LDAP server, the port it uses to communicate, and any other relevant information that will allow us to connect to that server. The same is true for RADIUS and TACACS+. We can then optionally configure groups from which it’s allowed to read data and grab it for the purposes of selecting which remote users will get access to the ACI network.
Figure 1
When you click on the links under the Quick Start guide you get a tutorial on how to do it, as well as an optional video to watch. To the right of the Quick Start is a list of words and concepts that will help you familiarize yourself with networking concepts in general and ACI specifically.
In this article I’m going to deep dive on the second step Configuring User Accounts. Also, the first Quick Start step is toInitialize the ACI Fabric which I’ve already covered here. Much like the initial Quick Start, we have more Quick Starts that are specifically detailed for a certain subject. So, when we click on the ADMIN tab we’ll see the guide below.
Figure 2
Though we don’t always need everything included here, it’s important to understand it all so that we know what we do need in our environment. There are often default settings already configured for some of these options, such as key rings.
For those not familiar a key ring is much like its physical counterpart.
Figure 3
It literally holds passwords or certificates for you. To create a new key ring we’ll first create a certificate authority. Again, there is a default key ring, so this is not absolutely necessary, but will make for a more secure environment.
Configure Certificates and Key Rings
- Under the ADMIN tab, expand Public Key Management.
- Click on Certificate Authority.
- Click on the Actions Pull Down Menu and select Create Certificate Authority.
- Give the certificate authority a name, description, and certificate chain then click Submit.
- Click on Key Rings and you’ll see the default key ring in there.
- Click on the Actions Pull Down Menu and select Create Key Ring.
- Give it a name, description, certificate, select a modulus for the certificate, and choose which certificate authority with which you’d like to associate it.
Figure 4
We can select whether we allow remote logins or if we should specify a certain role to allow people remote login. We can also select the Default Authentication. If we plan on using local users, or users the admin creates within the APIC, then keep it on the Local Realm. If not, you can select LDAP, RADIUS, or TACACS+ (using LDAP for Active Directory connections as well). The same can be done for Console Authentication.
If we expand the AAA Authentication object we see Login Domains. There is a default Login Domain called fallback which connected to the Local Realm and is there in case admins lock themselves out using external accounts somehow. However, we can create new Login Domains and associate users to them. These login domains can be connected to the Local Realm or LDAP, RADIUS, or TACACS+. They help keep the security objects and users more organized as well. For more information see the Cisco Documentation here.
Advertisement
Security Domains
The third action item in this particular Quick Start is to create Security Domains. There are already three domains that exist: All, Common, and Mgmt. The All security domain usually includes everything within the Management Information Tree. Common is usually used when there is a need for shared resources between tenants, and the Mgmt security domain is obviously for management which, for example, is probably where your fabric admins lie. You can add security domains as necessary. For example if you’d like to have a multi-tenant environment you would create a security domain for each tenant. We can then create users and assign them to certain security domains, or tenants.Create a Security Domain:
- Expand Security Management in the navigation pane on the left.
- Click on Security Domains.
- Click on the Actions Pull Down Menu and select Create a Security Domain.
- Give your security domain a name and an optional description.
Roles
ACI uses RBAC, or Role Based Access Control. This is a very common way to implement security in a solution. Essentially it means you have administrators that have permissions to manage everything within the solution, in ACI this is the Fabric Administrator (admin). They can assign permissions, or roles, to other users that give them granular access to certain things. There are default roles within ACI as shown below.Figure 5
We can assign users to these roles, or we can create custom roles from more granular permissions within each of these roles. We can specify whether we only want users to be able to read or read/write as well. Like most of the other tasks mentioned in this blog, in order to create a new role we simply need to highlight Roles and then use the Actions menu to create new ones. The roles/permissions will be available in a selectable menu for us to assign to the new custom role.
Configure User Accounts
ACI can have local users manually entered by an admin, or use something like LDAP, RADIUS, Active Directory, or TACACS+ to specify users that will be allowed to manage certain parts of the ACI network.Configure Local Users:
- Click on the ADMIN tab at the top.
- Click on AAA Authentication in the navigation pane on the left.
- Ensure Local is specified as the Realm. If not, specify it and click Submit.
- Click on Security Management in the navigation pane on the left.
- Select the Actions drop down list and click on Create Local User.
- Specify any security information that’s necessary and click Next.
- Select the roles you’d like to give to this user, such as Read/Write for admin or tenant admin, etc. and click Next.
- Specify login information for the user as shown below and click Finish.
Figure 6
Creating remote user accounts is similar to what we’ve all most likely seen in the past. If we’re creating an LDAP account, then we need to configure the LDAP provider first. Meaning, we need the IP address or host name of the LDAP server, the port it uses to communicate, and any other relevant information that will allow us to connect to that server. The same is true for RADIUS and TACACS+. We can then optionally configure groups from which it’s allowed to read data and grab it for the purposes of selecting which remote users will get access to the ACI network.
