2015-06-24 02:22 AM
I note when connecting the cDOT cluster e.g.
I am prompted for credentials even though I am logged (to the Windows AD Domain on my Windows 7 PC) as the same user which I will using to connect to the cluster.
In 7 mode when connecting to a filer as long as I was logged into Windows which an account which also had rights to the filer it would not prompt me for credentials.
I am a Windows buy rather than a NetApp guy. The NetApp team have setup a mapping file on the cluster which basically says ADDomain\ADAccount (to map my Windows account to cluster login). However I would image the cluster could be configured for Kerberos authentication (rather than this mapping file) and thereby I would not be prompted to login again to the cluster.
Any advise most welcome.
2015-06-24 04:34 AM
I think this behavior is as per design; there is no missing configuration on your filer.
In 7-mode, when connecting to a filer the default protocol was RPC. RPC uses AD based authentication, and so Windows session credentials was picked up when no credentials are provided.
In cDOT default is HTTPS, with fallback to HTTP (RPC connection is no longer supported by cDOT controllers, AFAIK). So the toolkit no longer automatically picks up the Windows session credentials. If you force a HTTP(S) connection on a 7-mode controller (using the -HTTP or -HTTPS switch), you will notice identical behaviour.
To avoid the annoyance of typing in credentials every time, you can use "Add-NcCredential" cmdlet and add your credentials to the Toolkit cache.
Hope this helps,
2015-06-24 07:35 AM
I am posting this reply again incase (as not sure if it took the first time around)
Thanks very much for the comprehensive reply Aparajita
Can you please tell me if the "Toolkit cache" persistant (e.g. stores securely in the regsitry or a file) so it will still be available between PowerShell sessions and Server reboots? or is the cache a memory cache only?
2015-06-25 02:39 AM
Yes, the cache is persistent across PowerShell sessions and server reboots.
One thing to note is, only the Windows user who added the credential to the cache can use it - even though the toolkit is shared between multiple users. For sharing credentials with all users on the machine, the "SystemScope" parameter must be specified.
Hope this helps,
2015-06-26 05:39 AM
There is also a nice custom PS module that you can add to your Powershell path that will help as well. I wrote a blog post where I use the custom module in scripting to remove exactly what you are seeing. If you are interested here is the blog post that details the script I wrote - https://threewhistlesfulltime.wordpress.com/2015/06/01/do15-mmc-like-management-via-powershell-script-part-1-create-delete-a-cifs-share/ . The script itself is not likely what you are looking for, but the use of the module I found might be useful depending on your environment.
If you are just interested in the custom module details, you can skip to the section "Let's get started...Storing Credentials" in the above blog post. It essentially uses the Windows Credential Manager to help with connecting w/o the need for a password. It works great and I use it quite a bit. Obviously that isn't a NetApp provided module so explore/use at your own risk, but it is very handy nonetheless.
2015-06-26 07:38 AM
Thanks very much for taking the time to reply Aparajita and Marc, and thanks for the link to the blog post Marc I will take a look.