Tintri PowerShell Toolkit and SSO

Overview

Since version 2.0, the Tintri PowerShell Toolkit has been able to make use of the Active Directory Single Sign-On functionality found in Tintri VMstore 3.2 and later. This article demonstrates its use.

Without SSO, the Connect-TintriServer cmdlet will either prompt for a username/password, or you can pass in a PSCredential object, which may be in-memory or persisted. So why bother with SSO at all?

  • Interactively typing in passwords doesn’t help for non-interactive automation.
  • Persisted copies of passwords are a maintenance hassle when passwords are periodically changed in alignment with many organisations’ security policies.

Active Directory SSO allows the Tintri PowerShell Toolkit the ability to request Kerberos service tickets within the security context of the user currently logged in. These tickets can then be used to make API calls to VMstore as long as the user has been granted permission using VMstore RBAC.

For those that may be familiar with web browsers and HTTP Negotiate authentication for SSO, this works in the same way.

Authentication and Access Control

If you have a VMstore running 3.2.0 or later, SSO support is present. Just as with username/password based authentication (and subsequent Role-Based Access Control), the following need to be configured on the VMstore:

  • Active Directory domain join configured. Only Active Directory is supported at the time of writing.
  • Role-Based Access Control (RBAC) configured to allow your Active Directory SSO users access to VMstore.

These can be configured in the Directory Services and Management Access settings tabs in the VMstore UI. Details on configuring those may be found in the online help or the VMstore Admin guide.

SSO Dependencies

The underlying Kerberos protocol has strict requirements around things like DNS records and Service Principals. These apply to VMstore too:

  • The VMstore’s management hostname should have an associated DNS A record that maps to the management IP address of the VMstore. For example, vmstore01.vmlevel.com resolves to the IP address 203.0.113.75, which is the management IP of the VMstore.
  • A HTTP Service Principal Name (SPN) should have automatically have been set on the AD computer trust account for the VMstore and it should match the DNS hostname above.

The SPN should have automatically been set at the time of domain join, so no further steps need be taken. If SSO doesn’t work for you, given the VMstore’s hostname (vmstore01 in my example), you can verify using the setspn.exe command on Windows:

PS C:\> setspn -L vmstore01
   HTTP/vmstore01.vmlevel.com
   HOST/vmstore01.vmlevel.com
   HOST/vmstore01

If the SPN doesn’t exist, you can add it using the setspn.exe command too:

PS C:\> setspn -S HTTP/vmstore01.vmlevel.com vmstore01

Again, there shouldn’t be any need for this manual intervention around SPNs unless the defaults had been removed.

Using SSO

In the normal case, the Connect-TintriServer cmdlet is passed in a PSCredential object using the -Credential parameter. To use SSO instead of explicitly providing credentials, log in as an Active Directory domain user that has been granted access to VMstore and simply replace the -Credential parameter with the new -UseCurrentUserCredentials parameter and watch SSO happen.

For example:

PS C:\> $ts = Connect-TintriServer -UseCurrentUserCredentials 
   vmstore01.vmlevel.com

A session object should be returned and you should not have had to type in a username or password.

If you experience issues, check that the hostname passed to Connect-TintriServer resolves in DNS and has a matching SPN entry as shown above, and check that the user running the cmdlet has been granted access to the VMstore through Tintri RBAC.
Names and Aliases

In complex environments, it may be that DNS aliases or multiple names in DNS resolve to the same VMstore. For example, vmstore01.vmlevel.com and vmstore.vmlevel.com may point to the same VMstore.

In the default SSO case, only the vmstore01.vmlevel.com name will work, as there is no HTTP SPN matching the vmstore.vmlevel.com name. Common Kerberos canonicalisation may take care of this, but in the case where it doesn’t work, simply adding an extra SPN (see above) with the additional name should cause both to work. No extra configuration on VMstore is required.

Advertisements

2 thoughts on “Tintri PowerShell Toolkit and SSO

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s