Cifs setup using powershell

[#1]

I'm having a very rough time with the cifs setup.

my goal is to take the 8.0.1 simulator and configure it as part of a cifs workgroup

my script so far looks like this

$password = ConvertTo-SecureString '1$netapp' -AsPlainText -force

$cred = New-Object -typeName System.Management.Automation.PsCcredential -ArgumentList "root:,$password

$ss1filer = Connect-NaController ss1.netapp.local -Credential $cred -https -timeout 10000000

Add-NaLicense -Controller $ss1filer bslrltg dndcbqh anleazl dzdachd nqbyfjj elnrltg bqoeazl dfvxfjj xjqivfk dndcbqh zyicxlc pvoivfk zoprkam pdxmqmi mtvvgaf

Enable-NaIscsi -controller $ssfiler1

New-NaCifsGroupFile -Controller $ss1filer

New-NaCifsPasswordFile -Controller $ss1filer

it all works fine until until it gets to the New-NaCifsPasswordFile command.  when entered above it prompts for a password and if i enter 1$netapp it says it changes the password but it won't let me log in using the username root with the password 1$netapp.

if i use the "-password 1$netapp" switch it says it changes the password but i can't log in using root/1$netapp

If use the "-password $password" switch it errors out.  it seems that i can't use the $password variable i'm setting earlier in the script.

I'm lost and can really use some help with this.

in case you are curious about the abnormally long timeout, i had a lot of issues with thee 8.0.1 simulator.  it seems to have random connectivity issues. 7.3 didn't have this.  i have putty disconnect issues in the 8.0.1 version and script connectivity issues that i didn't have in 7.3.  but the script issues were fixed by just making a long timeout.

[#2]

Hi Ken,

Does the password you are using have a "$" dollar sign in it?  PowerShell is automatically trying to expand that part of the string as a variable.  So your password is probably set to just "1":

PS C:\> "1$netapp"
1

You can use the backtick "`" (top left, with "~" on US keyboards) to escape it like this "1`$netapp":

PS C:\> "1`$netapp"
1$netapp

Also, the $password variable won't work because it is a SecureString object rather than a clear text string.

[#3]

Didn't work.

given this:

$password = ConvertTo-SecureString '1$netapp' -AsPlainText -Force
$cred = New-Object -TypeName System.Management.Automation.PsCredential -ArgumentList "root",$password
$ss1filer = Connect-NaController ss1.netapp.local -Credential $cred -https -timeout 10000000
$ss2filer = Connect-NaController ss2.netapp.local -Credential $cred -https -timeout 10000000

Add-NaLicense -controller $ss1filer bslrltg dndcbqh anleazl dzdachd nqbyfjj elnrltg bqoeazl dfvxfjj xjqivfk dndcbqh zyicxlc pvoivfk zoprkam pdxmqmi mtvvgaf
Enable-NaIscsi -controller $ss1filer

New-NaCifsGroupFile -controller $ss1filer
New-NaCifsPasswordFile -Password "1`$netapp" -controller $ss1filer

when i tried to log in to ss1 using root/1$netapp  it failed

I thought "maybe i should just eliminate the $" so I then tried

New-NaCifsPasswordFile -Password "netapp" -controller $ss1filer

it changes the password, but then i can't log in.  not sure what it sets the password to

i then tried

New-NaCifsPasswordFile -Password netapp -controller $ss1filer

it changes the password, but then i can't log in.  not sure what it sets the password to

i know it changes the password, because i log in to the machine and watch the console messages and i see a passwd change as successful.

so, i'm still lost.

[#4]

Hi Ken,

I haven't forgotten about you... It's just required a little more testing than I anticipated.  It seems the ZAPI command that New-NaCifsPasswordFile uses doesn't work quite like the console "cifs setup" command.  In particular it won't actually create a new root user for the filer, and it doesn't actually update the root user's password. At least in my testing I was still able to log in fine with the "old" password.

The other gotcha I ran into was setting up cifs for workgroup authentication.  I had to dig around a bit to discover that the "-Domain" parameter ("domain-info" in ZAPI) is used to specify the workgroup like this:

PS C:\> set-nacifs -cifsserver cifs_server -AuthType workgroup -SecurityStyle ntfs -Domain myworkgroup
PS C:\> get-nacifs

ADSite            :
AuthType          : workgroup
DCConnection      :
DNSDomainname     :
LDAPConnection    :
NetBIOSDomainname : MYWORKGROUP
NetBIOSServername : CIFS_SERVER
SecurityStyle     : ntfs
WindowsType       : NT4

Let me know how that works!

-Eric

[#5]

the workgroup setup part was next after the file creation.  My total script is actually pretty long, I was just pasting in the parts up to the failure.  here is the script up to the line that you are talking about adding.

$password = ConvertTo-SecureString '1$netapp' -AsPlainText -Force

$cred = New-Object -TypeName System.Management.Automation.PsCredential -ArgumentList "root",$password

$ss1filer = Connect-NaController ss1.netapp.local -Credential $cred -https -timeout 10000000

$ss2filer = Connect-NaController ss2.netapp.local -Credential $cred -https -timeout 10000000

Add-NaLicense -controller $ss1filer bslrltg dndcbqh anleazl dzdachd nqbyfjj elnrltg bqoeazl dfvxfjj xjqivfk dndcbqh zyicxlc pvoivfk zoprkam pdxmqmi mtvvgaf

Enable-NaIscsi -controller $ss1filer

New-NaCifsGroupFile -controller $ss1filer

New-NaCifsPasswordFile -Password "1`$netapp" -controller $ss1filer (fails or changes the password to an unknown string)

Set-NaCifs -controller $ss1filer -CifsServer ss1 -AuthType workgroup -SecurityStyle multiprotocol -Domain NETAPP (fails because missing /etc/passwd file, or fails because it does change the passwd and now i don't know what it is)

here is the problem. on a new storage system that nas never been set up before there is no /etc/group or /etc/passwd file.  so if you try to run the "Set-NaCifs -CifsServer" command it fails because the files are missing.  so i added the two previous lines to add the files.  the /etc/group file creation works fine.  the /etc/passwd file creation is a mess.  i'm tempted to call it a bug at this point.

if i cheat and run cifs setup on a controller, then unlicense cifs i can run the entire script including the "Set-NaCifs -CifsServer" command and everything works like a champ (i remove the New-NaCifsGroupFile and New-NaCifsPasswordFile commands).  i'm tempted to do that but i'd prefer to start with a system thats totally new, never been touched.

[#6]

I was able to reproduce the issue after disabling "security.passwd.rules.enable" and it looks like a problem with the toolkit (or at least one we can fix in the toolkit).  We are not encoding the password information correctly for the New-NaCifsPasswordFile command.

Until we can get a fix in, there is a quirky little workaround/special case I found where you can use an empty password:

PS C:\> New-NaCifsPasswordFile ''  

Here's the weird part. At this point if you have password rules enabled, your password did not change because it silently failed validation.  If you had password rules disabled, your password is now empty/blank.  You can reconnect and set your password back with Set-NaUserPassword.  Either way the file gets created and it doesn't really matter if the root password in that file is correct.

I tested this on 8.0.1, I'm not sure if it will work the same way on 7.3x.

Thanks for bearing with me.  Let me know how your script turns out.

-Eric

[#7]

This will be fixed in the next release of the toolkit (1.5).  In addition, the password parameter will be optional.  If you omit it (which I'd recommend) it will create the file without changing the root password.

[#8]

About when will 1.5 be out?  ballpark.

[#9]

I don't believe there is a target date set yet.  But, the big picture goal is to put out one release approximately every quarter.  Since 1.4 just came out a few weaks ago, I expect 1.5 will follow in a few months.

If you want a very similar workaround today, you can create the passwd file yourself like this:

PS C:\> $pwdFile = @"
>> root:*:0:1::/:
>> pcuser::65534:65534::/:
>> nobody::65535:65535::/:
>> ftp::65533:65533:FTP Anonymous:/home/ftp:
>>
>> "@
>>
PS C:\> $vol = (Get-NaVolRoot).Name
PS C:\> write-nafile "/vol/$vol/etc/passwd" $pwdFile

The "*" for the root password is an invalid hash, which will basically disable root access for the very few access schemes that authenticate against the file (e.g. CIFS configured for "passwd" authentication, PCNFS, or FTP with unix security & file authentication).  Most of the time that file is ignored or only used to map Unix IDs to user names.

Cheers,

Eric