PowerShell: NetApp DataONTAP toolkit credentials management

I’ve had the pleasure of spending the last several days talking to the development team here at NetApp about the DataONTAP PowerShell Toolkit.  As a result we’ve all learned alot, one of the more interesting features they brought to my attention was the credential management solution included with the toolkit.  I found this very compelling, you see embedding credentials within a script is as old as scripting itself.  There was a time not too long ago when it was considered taboo.  However with PowerShell came access to the .net Security.Cryptography encryption/decryption methods.  Scripters have unknowingly been accessing said methods indirectly whenever they would use the credential management funcions that Hal amd BSonPosh wrote long ago.

Which brings me to the DataONTAP toolkit.  The Development team has steped it up a notch and included a full credential management solution with the latest version of the toolkit.  The way it works is first you need to save logon information by using the Add-NaCredential cmdlet to save the credentials for a given NetApp controller onto the local machine.  Then the next time you run the Connect-NaController cmdlet the credentials you previously saved will be used. So how do we use this new feature, and why do you care?

First the how, to get started you simply run the Add-NaCredential cmdlet for every Controller you plan on scriptitng against.  Some of you may notice a SystemScope switch, be aware that when you apply this parameter the credentials are saved in the systemscope.  This paramter is intended to be used in situations were you want to grant the SYSTEM account access to the credential store…. in other words don’t use it unless told explicitly that it’s required as this is inhearently less secure. It was included in an attempt to support any possible senerio…  That said, let’s add a controller to the local store.

Now that the credential have been added to the local store you can connect to the target filer without supplying any credential information.

From a feature and functionality perspective it’s the same as using RPC, but will work with any protocol.   Additionaly because there is a proper PSCredential object embeded in the resulting NaController connection object,  you can also use the Invoke-NaSSH cmdlet without supplying any credentials!  Something you cannot do when connected via RPC.  For good measure the team also included a couple cmdlets to manage the contents of the credential store.

So weather your connecting on the fly or from within a script using the included credential store can significantly decrese the complexity while incresing the security of administering any NetApp infrastructure from a PowerShell prompt.


Leave a Reply