Effective December 3, NetApp adopts Microsoft’s Business-to-Customer (B2C) identity management to simplify and provide secure access to NetApp resources.
For accounts that did not pre-register (prior to Dec 3), access to your NetApp data may take up to 1 hour as your legacy NSS ID is synchronized to the new B2C identity.
To learn more, read the FAQ and watch the video.
Need assistance? Complete this form and select “Registration Issue” as the Feedback Category.

Microsoft Virtualization Discussions

Having problems connecting to a filer using network credentials

aschneider146

First off, fantastic work on these cmdlets. Thanks a bunch!

I am trying to connect to my filer over HTTPS using a set of AD credentials that are different than the ones I am logged onto my machine with. For example, I am logged on to my workstation as domain\normalAndy but I need to connect to the filer as domain\adminAndy.Each time I connect, I get "incorrect credentials."

I wrote a function using the .NET API in PowerShell a while back and I think I might know what is going on. I get a System.Management.Automation.PSCredential variable called $credential and then do the following. The trick is the if statement that puts the "domain\" in front of the username when you call the SetAdminUser() method on the NetApp.Manage.NaServer object.

$username = $credential.GetNetworkCredential().UserName
$password = $credential.GetNetworkCredential().Password
$domain   = $credential.GetNetworkCredential().Domain
if ($domain) {$username = "$domain\$username"}

$NtapServer = New-Object NetApp.Manage.NaServer($filer,1,0)
$NtapServer.Port = $port
$NtapServer.TransportType = $transportType                                                                   
$NtapServer.SetAdminUser($username,$password)

return $NtapServer

Any ideas?

Thanks again. fantastic work!

Andy Schneider

http://get-powershell.com

1 ACCEPTED SOLUTION

cknight

Hi, Andy.  Here are a few things that might help:

Since you are using AD authentication, I assume the controller is in the domain and that those credentials are recognized by the controller.

RPC always uses the credentials of the currently running process, so you cannot provide alternate credentials to the Connect-NaController cmdlet when using RPC.  However, you should be able to accomplish this by starting PowerShell using alternate credentials, i.e. "runas /user:domain\userid powershell".

RPC and HTTP/HTTPS are mutually exclusive.  If you don't provide the -Credentials parameter, Connect-NaController uses RPC.  Given -Credentials, Connect-NaController tries HTTPS and falls back to HTTP if necessary.  The -ForceSecure and -ForceUnsecure switches provide more control over HTTP and HTTPS connections; they do not apply to RPC.

I have reproduced your issue in that I cannot connect via HTTP/HTTPS using domain credentials.  I should be able to address that in a patch.  My apologies for the bug.  The workaround for the time being is to use RPC connections, or use non-domain credentials with HTTP/HTTPS connections.


Clinton

View solution in original post

7 REPLIES 7

fjohn

First of all, thanks for your feedback.

Have you tried something like:

$password = ConvertTo-SecureString "p@ssw0rd" -AsPlainText –Force
$cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList "testdom\user1",$password

Connect-NaController SIM1 -Credential $cred

 
I didn't notice the ConvertTo-SecureString in your example.

Happy Scripting

J




aschneider146

I did a little more digging and here's where I am at.

I can connect to my filer using the web interface over https with my domain\admin account, using AD for Auth

I can connect to my filer using Connect-NaController -forceSecure  if I specify the local "root" username and password

I cannot connect to my filer using Connect-NaController -forceSecure using my AD Credentials.

I cannot connect to my filer if I am logged onto a server with my admin account and try to use RPC.

Two questions:

1) Do I need to flip a switch on my filer somewhere to allow auth via RPC?

2) Any idea on how I can get auth via HTTPS working with AD credentials?

Thanks,

Andy

fjohn

HI Andy,

Yes, I can confirm that Https works with a normal domain account as well as with "root" or another local account on the Filer.

It's interesting that your experience is the same on those two points however;

You cannot connect to my filer using Connect-NaController -forceSecure using my AD Credentials.

You cannot connect to my filer if I am logged onto a server with my admin account and try to use RPC.

I have not tried forcesecure yet, or some of the manipulation you've tried with placing the AD Credentials in the structure.  I can however, connect to the filer if logged on to the server with my admin account and I try to use RPC.  RPC is the default connection type, so there's nothing special to do.

Can't connect as an admin when logged on as admin....  What are you UAC setting on the windows server just out of curiosity?

J

cknight

Hi, Andy.  Here are a few things that might help:

Since you are using AD authentication, I assume the controller is in the domain and that those credentials are recognized by the controller.

RPC always uses the credentials of the currently running process, so you cannot provide alternate credentials to the Connect-NaController cmdlet when using RPC.  However, you should be able to accomplish this by starting PowerShell using alternate credentials, i.e. "runas /user:domain\userid powershell".

RPC and HTTP/HTTPS are mutually exclusive.  If you don't provide the -Credentials parameter, Connect-NaController uses RPC.  Given -Credentials, Connect-NaController tries HTTPS and falls back to HTTP if necessary.  The -ForceSecure and -ForceUnsecure switches provide more control over HTTP and HTTPS connections; they do not apply to RPC.

I have reproduced your issue in that I cannot connect via HTTP/HTTPS using domain credentials.  I should be able to address that in a patch.  My apologies for the bug.  The workaround for the time being is to use RPC connections, or use non-domain credentials with HTTP/HTTPS connections.


Clinton

View solution in original post

aschneider146

Hey Clinton,

I got RPC working. Not quite sure what I was doing wrong, but looks solid now. Good to know about AD creds and HTTP. Thanks for all your help. Seriously, I am super impressed with these cmdlets. Fantastic job!

-Andy

cknight

Hey, Andy.  Thanks for the compliment!  I've just posted Toolkit 1.0.1,  which should fix the issue with domain credentials over HTTP connections.

Clinton

aschneider146

No dice. Rather than using ConvertTo-SecureString and building the object manually, I was just using Get-Credential.

To pull the password, I am using the GetNetworkCredential() method on the PSCredential object.

PS C:\> $p = ConvertTo-SecureString "SuperSecretPassword" -AsPlainText -force
PS C:\> $cred = new-object System.Management.Automation.PSCredential('domain\superAdmin',$p)
PS C:\> $cred.GetType().FullName
System.Management.Automation.PSCredential
PS C:\> $cred.GetNetworkCredential()

UserName                                Password                                Domain
--------                                --------                                ------
superAdmin                              SuperSecretPassword                     domain


PS C:\> $cred.GetNetworkCredential().Password
SuperSecretPassword
PS C:\> $cred.GetNetworkCredential().Domain
domain
PS C:\> $cred.GetNetworkCredential().UserName
superAdmin
PS C:\>

Announcements
NetApp on Discord Image

We're on Discord, are you?

Live Chat, Watch Parties, and More!

Explore Banner

Meet Explore, NetApp’s digital sales platform

Engage digitally throughout the sales process, from product discovery to configuration, and handle all your post-purchase needs.

NetApp Insights to Action
I2A Banner
Public