In Part 1 of this blog post, I described the deployment of a production ready AVI Controller Cluster. You can find it here:

In this post (Part 2), I will describe how to replace the GUI certificate and integrate with Active Directory.

Replacing the GUI certificate

In a production environment, self signed certificates should be replaced by „real“ certificates. In this example we will use a Microsoft CA that is trusted by all employee systems. 

In order to replace the GUI certificate, go to Templates -> Security -> SSL/TLS Certificates, click CREATE and Controller Certificate.

In General, enter a Name and select CSR as the Type:

Fill in all fields and make sure to add the proper Subject alternate Names. In this example, we use the following SANs:

• avi01.sclabs.net
• avi02.sclabs.net
• avi03.sclabs.net
• avicl01.sclabs.net

Click SAVE. You will now see your CSR in the list of SSL/TLS Certificates. The column Valid Until will display Awaiting Certificate.

Click the pencil icon of your CSR and copy the content of the field Certificate Signing Request. Submit the CSR to your CA and import the certificate file or copy the Base64 content into the open popup window and click SAVE again. Using the standard Web Server template in case of a Microsoft CA is perfectly okay.

After refreshing your browser, you will see a warning that says that the issuer certificate is missing. In order to import your CA certificate, click CREATE -> Root/Intermediate CA Certificate and import your issuer certificate by importing a base 64 encode file or pasting the content.

Click VALIDATE and then click SAVE. Refresh your browser again, the warning should have disappeared.

Now go to Administration -> Settings -> Access Settings and click the pencil icon. Delete anything under SSL/TLS Certificates and add your certificate. Click Save.

In case your system/browser trusts your CA you should no longer get a certificate warning. You might need to close your browser tab or even close the browser completely.

Integrate with your Active Directory

Although you can create local users on your controller cluster, using Active Directory is quite common. I’ve seen customers where the AVI admins share a single account. This is not a good idea, since the event logs will never tell you who actually performed an operation.

In order to integrate with AD, you first need to create a profile. Go to Templates -> Security -> Auth Profile and click CREATE.

Fill in all fields like in the following example:

You can add multiple LDAP servers.

In this example, using the AD Domain vdi.sclabs.net, the following settings are important:

Base DN	DC=vdi,DC=sclabs,DC=net
Admin Bind DN	CN=ldap service,CN=Users,DC=vdi,DC=sclabs,DC=net
User Search DN	DC=vdi,DC=sclabs,DC=net
Group Search DN	DC=vdi,DC=sclabs,DC=net
Group Filter	(objectClass=group)
User ID Attribute	userPrincipalName

It’s best practice to create a service account and not use a Domain Admin Account. Just create a user with minimal permissions.

Click SAVE. At the right of your Auth Profile, you can click an icon with a question mark in order to do some verification.

In the next step, need to go to Administration -> Settings -> Authentication/Authorization. Click the pencil icon and select Remote and your Auth Profile. For emergency reasons, it might be a good idea to leace Allow local user login enabled. In case your controllers loose AD connectivity you would still be able to log in with a local account.

Last step is to create one or multiple mappingsfrom LDAP groups to AVI roles. For the sake of simplicity, I only add a group AVIAdmins and provide Super User permissions to the group members:

You can now logout and try to log in as an AD user. This user needs to be a member of the AVIAdmins group of course. Try logging in with a different account that is not a member of the group – you should get a message that you have no priviledges.

Congratulations! Your users now trust the controller certificate and can use an AD account to log in to the controller cluster.