Using the dataontap 4.4 powershell toolkit to try to connect to a cDOT cluster/vserver and I have it working but one question.
Is there no way to tell the command to use the currently logged on user token? Do I have to prompt for the users credentials even though they are right there in the windows address space to use?
When I use the connect-nacontroller, I only need to supply the -name parameter and it uses the currently logged on user.
The -Credential parameter of the "Connect-NcController" cmdlet has a mandatory value of False and can be used with cached credentials.
See "Get-Help Add-NcCredential -Full"
NAME Add-NcCredential SYNOPSIS Save login credentials for a clustered Data ONTAP controller. SYNTAX Add-NcCredential [-Credential <PSCredential>] [-SystemScope] [<CommonParameters>] Add-NcCredential -Controller <NcController> [-Credential <PSCredential>] [-SystemScope] [<CommonParameters>] Add-NcCredential [-Name] <String> [-Credential <PSCredential>] [-SystemScope] [<CommonParameters>] DESCRIPTION Save login credentials for a clustered Data ONTAP controller. The cached credentials are available to Connect-NcController, Invoke-NaSsh, and other Toolkit cmdlets. The saved credentials are encrypted for safe storage. By default, a set of credentials is saved using the current user context, so that only the same Windows user can retrieve them. If an application of the Toolkit must utilize the cached credentials while running under some other context, specify the -SystemScope parameter. This saves the credentials such that any process or user on the local system can access them, so this option should only be used on a system with limited user access. Any number of Toolkit users may store credentials for a given storage controller in the cache, but a user will only be able to see and utilize credentials saved using his account identity or the system identity.
I'm trying to avoid having the user provide their password at all. Are you trying to tell me that add-nccredential will use the current context and avoid having to supply the currently logged on user credentials?
Yes that's correct. You can cache the credentials you want to use for the current logged on user then connect to the cluster without providing credentials as they can be retrieved from the cache if not provided to connect-nccontroller cmdlet. EG
PS C:\> Add-NcCredential -Name cluster2.testlab.local -Credential $(Get-Credential -Credential admin) Name Credential HostUser ---- ---------- -------- cluster2.testlab.local System.Management.Automation.PSCredential TESTLAB\mbeattie PS C:\> Connect-NcController -Name cluster2.testlab.local Name Address Vserver Version ---- ------- ------- ------- cluster2.testlab.... 192.168.100.3 NetApp Release 9.1: Thu Dec 22 23:05:58 UTC 2016
Your example highlights my fear.
You are still at least one time using this argument ...
-Credential $(Get-Credential -Credential admin)
I am trying to avoid using it at all, like connect-nacontroller does.
I am not using local users either, I will be using Active Directory accounts.
add-nccredential populates the local logged in user's credentials cache. So get-nccredential will show you the contents of your particular on disk local credentials cache. You can add-nccredential for a system using an AD account but it would only be in your credentials cache and if the user account you supply isn't the currently logged in user it would prompt you one time for the password for that AD account. once it's in the cache, you wouldn't have to use the password again. you can then connect-nccontroller as you expect.
Mostly this would work without you needing to manage the credentials cache. If the currently logged in AD account has admin role on the cluster (or an appropriate assigned role) and you do $mycontroller1 = connect-nccontroller cluster_hostname it will log in without prompting for you AD password even once. I tend to supply -Controller $mycontroller to all cmdlets explicitly when I'm working with powershell because I am usually working across more than one controller, eg get-ncvol -controller $mycontroller1 .
you can use add-nccredential as he already shown to populate the cache on a machine. So you can do add-nccredential -controller cluster_name -credential (get-credential) and simply supply your AD login and password at the prompt. get-nccredential will then reflect this added cached credential and a subsequent call to connect-nccredential to the same "controller" already contained in the credentials cache will connect without password prompt. This will persist across reboots as the credentials cache is encrypted on disk. get-help add-nccredential -detailed and the related cmdlets for more info
Bottom line sounds like with cDOT and Powershell, a person has to supply the AD account password once.
Imagine yourself as the user of a script and you know you are already logged on to the machine where you plan on running the script from and when you run the script, you get prompted for password?
My first impression would be "why in the hell don't they just use the windows cached token and pass that in?"
connect-nacontroller has no issue in this area and that is how connect-nccontroller should have been designed.
no. That's not the case. IF the user is logged in as an AD user that has the right role on the cluster an the cluster is appropriately configured to use RBAC roles with AD accounts then connectiion to the filer will not prompt for password.
If you are getting prompted for a password when you connect to the controller with connect-nccontroller I would expect one of two possibilities
https://library.netapp.com/ecmdocs/ECMP1368701/html/GUID-BC7B1934-DDE6-4AFB-A319-6C85D1ADACB6.html is 8.2.x . There have been changes from 8.2.x to 8.3 and beyond with regards to active directory configuration and access to cluster management.
You would be diggining in to release notes primarily. The documentation for different versions for System administration also. Docs for 8.3.x release notes are here
it talks briefly about the udpated actived directory support for cluster and svm adminsitrators and then directs you to the detailed system administration guide. I don't believe there are changes between 8.3.x and 9.x with regards to this but as I recall (from personal memory so take with a grain of salt) there were changes between 8.2.1+ and 8.3.x .