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

[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 · Accepted solution]

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

[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:\>