Microsoft Virtualization Discussions
Microsoft Virtualization Discussions
I have a powershell script that runs perfectly if i am logged on as the administrator account of the domain, querys the netapp etc, if i log on with a second domain administrator account sysadmin the script errors. Both the administrator and sysadmin account are both domain admins and if i look at the security on the netapp all(administrator, sysadmin and domain admins) are memebrs of the netapp local administrators group.
When i run the script i am passing the same arguments to the filer -filer xxx.xxx.xxx.xxx -admin root - pass XXXXXXXX
all the audit log says is for the account that doesnt run is no error messages
Fri Nov 12 10:09:08 NZDT [rshd_0:debug]: root:START:rsh shell:[127.0.0.1_19244]
Fri Nov 12 10:09:08 NZDT [rshd_0:debug]: root@[127.0.0.1_19244]:IN:rsh shell:RSH INPUT COMMAND is priv set -q admin ; version
Fri Nov 12 10:09:08 NZDT [rshd_0:debug]: root@[127.0.0.1_19244]:END:rsh shell: Fri Nov 12 10:09:08 NZDT [Java_Thread:debug]: root:API:in:<storage-shelf-list-info/>
Fri Nov 12 10:09:08 NZDT [Java_Thread:debug]: root:API:in:<system-get-info/>
Fri Nov 12 10:09:08 NZDT [Java_Thread:debug]: root:API:in:<system-get-version/> Fri Nov 12 10:09:08 NZDT [Java_Thread:debug]: root:API:in:<iscsi-service-status/>
but the ps window has heaps of errors
starts with
Connect-NaController : API invoke failed.
How does the security around api calls work since i am passing the root username and password and also have the account in the netapp local group is there some account mapping i aslo ahve to do with the root and sysadmin account?
cheers
Alan
Solved! See The Solution
Thanks, Alan. There is nothing wrong with your script. You're using HTTP/HTTPS connections, and in my environment I am able to run the script with root, domain admin, and alternate domain credentials as defined previously, regardless of the account with which I am logged into Windows 2008. Trying on Windows 7 also works with all credential sets.
If you'd like to investigate further, I suggest you reproduce the connection failure by manually invoking Connect-NaController. Then when you get the "API invoke failed" error, see if there is any further info by entering $error[0].Exception.InnerException
Hello, Alan. You didn't say whether you are using RPC or HTTP. But in either case, the first thing to check is whether you can log in to the controller console (i.e. telnet or ssh) using the desired credentials. If that works, the same credentials should work with the PowerShell Toolkit.
I tried the same experiment here:
That all worked here. If it helps, I'm using Windows 2008 R2 (client), Data ONTAP 7.3.3, and Windows 2003 (domain controller).
Hi Clinton
I see my error now,
This is what i was doing
Logging on to a Windows 2003 server as sysadmin so the powershell context is that of sysadmin and passing thought the netapp root username and password as arguements for the script
eg powershell -command c:\NetappListVolumesandLuns.ps1 -filer 192.168.0.10 -admin root -pass XXXXXXXXX. (this errors for me)
Changing it based on your example to be the actual NT account works
eg powershell -command c:\NetappListVolumesandLuns.ps1 -filer 192.168.0.10 -admin testdomain\sysadmin -pass XXXXXXXXX (this works for me)
Howerver if the server is logged on as administrator
powershell -command c:\NetappListVolumesandLuns.ps1 -filer 192.168.0.10 -admin root -pass XXXXXXXXX. works
so i suspect there must be some mapping on the netapp that allows the administrator account to passthru root and for the script to work for administrator and not sysadmin,
So i guess i have my fix i need to explicily use the domain credentials for my script and drop using the root credentials
Cheers
Alan
Alan, could you share the portion of your script where you are calling Connect-NaController? I'd like to see how you are mapping the credentials you pass into the script to the arguments of Connect-NaController.
I ask because you should be able to specify any credentials that the controller recognizes. If you are using RPC (i.e. not specifying credentials to Connect-NaController), then you will be authenticated as the currently logged on Windows user, and that only works if the account is known to both the domain and to ONTAP. But if you are using HTTP/HTTPS (i.e. using the -Credentials parameter of Connect-NaController), then the current Windows user context should be irrelevant. In other words, using the controller's root userid/password should *always* work regardless of the Windows account in use. That also holds true for any other local controller user account, unless that user doesn't have sufficient privileges to call ONTAP APIs.
Hi Clinton here is the ps file, i modified a script file i found here on the forum(http://communities.netapp.com/docs/DOC-6349) and change the the script to output the results to a text file and to pass in credentials so i could use this on multiple filers
------------------------------------
Param ([string]$filer, [string]$admin, [string]$pass)
# NetApp Data ONTAP PowerShell Toolkit
$exist = $false
foreach ($modulePath in ${env:PSModulePath}.Split(";"))
{
if ((Test-Path ($modulePath + "DataONTAP\DataONTAP.dll")) -and !$exist)
{
Write-Host "Adding NetApp DataOnTap PowerShell" -ForegroundColor Green
$exist = $true
Import-Module DataONTAP
}
}
#$filer = "***.***.***.***"
$spass = ConvertTo-SecureString $pass -AsPlainText -Force
#$admin = "****"
$cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $admin,$spass
Connect-naController $filer -credential $cred
$aggrlist = Get-NAAggr
$file = "C:\fujitsuit\test.txt"
#Remove-Item $file
New-Item $file -type file -force
Foreach ($aggr in $aggrlist){
[double]$AggrOverSub=1
$aggrInfo = "Aggr Start: " + $aggr.Name + " : Aggr Size = " + ([Math]::Round(($aggr.SizeTotal/(1024*1024*1024)),1)) + "GB" + " : Used Size = " + ([Math]::Round($aggr.SizeUsed/(1024*1024*1024),1)) + "GB" + " : % used = " + $aggr.SizePercentageUsed + "%"
Add-Content $file $aggrInfo
#Add-Content $file "`r"
$LunList = Get-NaLun
$Vollist = Get-NaVol
ForEach ($volume in $Vollist)
{ [double]$VolOverSub=1
$vol = (get-navol $volume.name)
[single]$perc=100 * ([single]($vol.SizeUsed) /[single]($vol.SizeTotal))
$perc=[math]::Round($perc,2)
if ($aggr.name -eq $vol.containingaggregate )
{ $volInfo = " Vol : " + $vol.Name + ": Vol Size = " + ([math]::round(($volume.SizeTotal/(1024*1024*1024)),1))+ "GB" + ": Used Size = " + $perc + "%"
Add-Content $file $volInfo
foreach ($LUN in $LunList)
{ $Sour=$LUN.Path
$spath = $Sour.Split("/")
if (($spath[2].equals($vol.name)) -or ($spath[3].equals($vol.name)))
{ [single]$perc=100 * ([single]((get-nalunoccupiedsize $LUN.path)) /[single]($LUN.Size))
$perc=[math]::Round($perc,2)
$luninfo = " LUN: = " + $LUN.path + " : Size = " +([Math]::Round(($LUN.size/(1024*1024*1024)),1))+ "GB" + " : Used = " +([Math]::Round( ((get-nalunoccupiedsize $LUN.path)/(1024*1024*1024)),1))+"GB" + " = " + $perc + "%"
Add-Content $file $luninfo
$VolOverSub=$VolOverSub+[double]$LUN.Size
}
}
}
}
$aggrinfo2 = "Aggr End : " + $aggr.Name
Add-Content $file $aggrinfo2
}
--------------------------------
Thanks, Alan. There is nothing wrong with your script. You're using HTTP/HTTPS connections, and in my environment I am able to run the script with root, domain admin, and alternate domain credentials as defined previously, regardless of the account with which I am logged into Windows 2008. Trying on Windows 7 also works with all credential sets.
If you'd like to investigate further, I suggest you reproduce the connection failure by manually invoking Connect-NaController. Then when you get the "API invoke failed" error, see if there is any further info by entering $error[0].Exception.InnerException
Hi Clinton
Sorry was away for the weekend so this is my first chance to test this out so this is my error
when trying to connect as root under the sysadmin account
The remote server returned an error: (407) Proxy Authentication Required.
Set my IE under sysadmin not to use the proxy server and hey now i can connect as root via the powershell script.
Hmm interesting, i assume then to get around this i probably should change to using RPC connection method so that when i push this script out to mulitple sites i dont have to worry if the proxy server has been set for the account i am using.
So now to find i need to check the SDK help to see how to change this to RPC connection method
Cheers
Alan
Hi, Alan. That explains why some user accounts could not connect; they must have different HTTP proxy settings.
Two other Toolkit users hit this last week:
http://communities.netapp.com/thread/11891
The workaround, until I adjust the Toolkit, is to add this to the top of your script:
[System.Net.WebRequest]::DefaultWebProxy = $null
Toolkit 1.3, posted today, does not use the system HTTP proxy settings. Hence the workaround should no longer be necessary.
naConnect is not possible, but ssh works.
> $cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $admin,$spass
> $l1=Connect-NaController lannapfs9001.eu.adglob.net -Credential $cred
Connect-NaController : Could not connect to lannapfs9001.eu.adglob.net on port 80 for protocol HTTP.
Bei Zeile:1 Zeichen:25
+ $l1=Connect-NaController <<<< lannapfs9001.eu.adglob.net -Credential $cred
+ CategoryInfo : InvalidResult: (lannapfs9001.eu.adglob.net:NaController) [Connect-NaController], NaConnectionException
+ FullyQualifiedErrorId : HttpConnectionFailed,DataONTAP.PowerShell.SDK.ConnectNaController
> $error[0].Exception.InnerException
Timeout für Vorgang überschritten
> telnet lannapfs9001.eu.adglob.net 80
HTTP/1.1 400 Invalid request
Server: NetApp/7.3.1.1P9
Date: Wed, 02 Feb 2011 10:02:57 GMT
Content-Length: 114
Content-Type: text/html
<HTML>
<HEAD>
<TITLE>Error</TITLE>
</HEAD>
<BODY>
<H1>Error 400</H1>
Invalid request
</BODY>
</HTML>
Verbindung zu Host verloren.
P> Invoke-NaSsh -Controller lannapfs9001.eu.adglob.net -Credential $cred df -g vol45imx -verbose
AUSFÜHRLICH: SSH invoke: df -g vol45imx
AUSFÜHRLICH: SSH user: jwippel
AUSFÜHRLICH: SSH client version: SSH-2.0-SharpSSH-1.1.1.13-JSCH-0.1.28
AUSFÜHRLICH: SSH server version: SSH-2.0-OpenSSH_3.4p1
AUSFÜHRLICH: SSH cipher: 3des-cbc
AUSFÜHRLICH: SSH MAC: hmac-sha1
AUSFÜHRLICH: SSH host: 10.188.45.57
AUSFÜHRLICH: SSH host key type: ssh-rsa
Filesystem total used avail capacity Mounted on
/vol/vol45imx/ 79GB 76GB 2GB 96% /vol/vol45imx/
/vol/vol45imx/.snapshot 0GB 0GB 0GB ---% /vol/vol45imx/.snapshot
Please also tell me how to use SSH host key type: ssh-dsa !
Hello, wippel. When you say "naConnect is not possible", are you reporting a regression from an earlier Toolkit release? Please double-check your HTTP options settings.
Regarding ssh-dss host keys, the Invoke-NaSsh cmdlet supports both DSA and RSA keys, but RSA is encoded as the preferred choice. As a test, I deleted the RSA host keys from a controller's /etc/sshd directory and restarted sshd. This caused Data ONTAP to present its ssh-dss key:
PS C:\Software\Toolkit\1.3.0> invoke-nassh aggr status -Verbose
VERBOSE: SSH invoke: aggr status
VERBOSE: SSH user: root
VERBOSE: SSH client version: SSH-2.0-SharpSSH-1.1.1.13-JSCH-0.1.28
VERBOSE: SSH server version: SSH-2.0-OpenSSH_3.4p1
VERBOSE: SSH cipher: 3des-cbc
VERBOSE: SSH MAC: hmac-sha1
VERBOSE: SSH host: 10.61.167.60
VERBOSE: SSH host key type: ssh-dss
Aggr State Status Options
aggr0 online raid_dp, aggr root
redirect
aggr1 online raid_dp, aggr snapshot_autodelete=off
aggr2 online raid_dp, aggr
But I don't know what other repercussions might arise from this change, so proceed with caution!
PS R:\> Get-NaOption *http*
ClusterConstraint Name
----------------- ----
none httpd.access
none httpd.admin.access
none httpd.admin.enable
none httpd.admin.hostsequiv.enable
none httpd.admin.max_connections
none httpd.admin.ssl.enable
none httpd.admin.top-page.authentication
none httpd.autoindex.enable
none httpd.enable
only_one httpd.log.format
none httpd.method.trace.enable
none httpd.rootdir
only_one httpd.timeout
only_one httpd.timewait.enable
PS R:\> Get-NaOption *hosts*
ClusterConstraint Name
----------------- ----
none httpd.admin.hostsequiv.enable
same_required trusted.hosts
PS R:\>
Please also tell me, where to put the DSA client keys.
Please also tell me, where to put the DSA client keys.
We did not implement key-based authentication in Invoke-NaSsh, at least not in Toolkit 1.3. Since the Toolkit already requires credentials for HTTP/HTTPS connections, and given that we added the credentials cache in 1.3, we chose to stick with password-based authentication (and an earlier release date!). Key-based authentication is already logged as a potential future enhancement.
wippel wrote:
PS R:\> Get-NaOption *http*
ClusterConstraint Name
----------------- ----
none httpd.access
Your HTTP options values aren't shown, but I would ask that you try inspecting the connection error values that others reported earlier in this thread using:
$error[0]
$error[0].Exception
$error[0].Exception.InnerException
It would also help to know your ONTAP version, whether your connection issues are a regression in Toolkit 1.3, and any other details you think might be relevant. You can also enable full Toolkit debug output by following the instructions in this thread.
RPC tells me "Access denied" if trieing to connect by name, but connecting by address works.
The reverse lookup by address shows an other domain, that seems to be the problem!
I'm looking forward for key-based authentication in ssh...