2

I have a cluster resource of type "file share" but when I try to configure the "security" parameter I get the following error (excerpt):

Set-ClusterParameter : Parameter 'security' does not exist on the cluster object

Using cluster.exe I get a better result, namely the usual nothing when the command worked. But when I check in Failover Cluster Manager the permissions have not changed. In Server 2003 the cluster.exe method worked.

Any ideas?

Update:

Entire command and error.

PS C:\> $resource=get-clusterresource testshare
PS C:\> $resource

Name                          State                         Group                         ResourceType
----                          -----                         -----                         ------------
testshare                     Offline                       Test                          File Share


PS C:\> $resource|set-clusterparameter security "domain\account,grant,f"
Set-ClusterParameter : Parameter 'security' does not exist on the cluster object 'testshare'. If you are trying to upda
te an existing parameter, please make sure the parameter name is specified correctly. You can check for the current par
ameters by passing the .NET object received from the appropriate Get-Cluster* cmdlet to "| Get-ClusterParameter". If yo
u are trying to update a common property on the cluster object, you should set the property directly on the .NET object
 received by the appropriate Get-Cluster* cmdlet. You can check for the current common properties by passing the .NET o
bject received from the appropriate Get-Cluster* cmdlet to "| fl *". If you are trying to create a new unknown paramete
r, please use -Create with this Set-ClusterParameter cmdlet.
At line:1 char:31
+ $resource|set-clusterparameter <<<<  security "domain\account,grant,f"
    + CategoryInfo          : NotSpecified: (:) [Set-ClusterParameter], ClusterCmdletException
    + FullyQualifiedErrorId : Set-ClusterParameter,Microsoft.FailoverClusters.PowerShell.SetClusterParameterCommand
Andrew J. Brehm
  • 1,611
  • 7
  • 37
  • 57
  • I'd say a quiet failure isn't a better result than a verbose failure when troubleshooting, but to each their own :) – Chris N Aug 07 '12 at 16:16
  • Can we see your whole command line? Feel free to obfuscate the cluster name or whatever you'd like. Also, if you use the Get-ClusterParameter command what does it return (similarly obfuscated). – Chris N Aug 07 '12 at 16:19
  • Added entire command history to question. In 2003 the parameter to modify was "security" and using cluster.exe it worked. In 2008 modifying the same parameter with cluster.exe has no effect on the share and gives an error when done with Powershell. – Andrew J. Brehm Aug 08 '12 at 08:25
  • Could you be looking for the Grant-ClusterAccess cmdlet instead? – Chris N Aug 08 '12 at 13:32
  • Also, to see the available properties to set, do this: Get-ClusterResource TestShare | Get-ClusterParameter | fl * and see if it yields a list of params and their current values. – Chris N Aug 08 '12 at 13:33
  • Grant-ClusterAccess: No. That appears to grant access to the cluster, not specifically to clustered file shares. – Andrew J. Brehm Aug 08 '12 at 14:26
  • Get-ClusterParameter: That's the point. The only security-related parameter is "Security Descriptor" which is a byte array and it is not obvious whether this is the parameter I want and how to add permissions for accounts to it. – Andrew J. Brehm Aug 08 '12 at 14:28
  • Well, it's not working because parameter doesn't exist as a valid parameter for the cluster object. Can you set the NTFS permissions or share permissions on the file or share objects instead? Seems like an easier approach. If not, take a look at the following link, which may be helpful. http://blogs.msdn.com/b/clustering/archive/2010/07/09/10036201.aspx – HopelessN00b Aug 15 '12 at 20:34
  • NTFS permissions don't appear to be an issue. How can I set share permissions on the share objects? That's what I want to know... – Andrew J. Brehm Aug 15 '12 at 20:39
  • I don't use share-level permissions because they're a pain in the ass and better handled with NTFS permissions IMO, so I can't tell you how to do it from personal experience with PowerShell (here's something that looks like it would work: http://emptygarden.info/2011/06/06/using-powershell-to-get-share-and-ntfs-permissions-2/), but I think you're actually wanting to use the `Security Descriptor` parameter. Link describing what each byte in the array does: http://msdn.microsoft.com/en-us/library/aa394402%28VS.85%29.aspx Let me know if that's what you're after, I'll make an answer of it. – HopelessN00b Aug 15 '12 at 21:16
  • But NTFS permissions have no effect on the cluster share permissions (and vice versa). – Andrew J. Brehm Aug 15 '12 at 21:35
  • Your linked articles don't mention clusters or cluster shares. – Andrew J. Brehm Aug 15 '12 at 21:37
  • Well, do they work? Securities apply to more than just clustered shares, so they're not going to mention everything they apply to. – HopelessN00b Aug 15 '12 at 22:35
  • No. NTFS and non-cluster file share permissions do not apply to cluster shares. – Andrew J. Brehm Aug 16 '12 at 07:07

1 Answers1

1

I found an easy-to-use and obvious answer. It's so simple one might not believe it's a Microsoft solution.

$permissions is an array of permissions containing an account (domain\user), a permission (fullcontrol) and a type (allow).

# create access rule based on permissions
$rule = new-object system.security.accesscontrol.filesystemaccessrule $permissions

# get an acl, remove access rules, add our rule
$acl = get-acl "c:\" # need to get acl from root of drive to avoid inheritance
$acl.access | foreach-object {$acl.removeaccessrule($_)}
$acl.setaccessrule($rule)

# get security descriptor from acl and convert to binary security descriptor
$sddl = $acl.sddl
$sdhelper = [wmiclass]"win32_securitydescriptorhelper"
$binarysd = ($sdhelper.sddltobinarysd($sddl)).binarysd

# get cluster resources from registry
$resources = get-childitem "hklm:\cluster\resources"

# ...with paths that powershell will understand
$resources = $resources | foreach-object {$_.pspath}

# find clustershare resource path
$resource = $resources | where-object {(get-itemproperty $_ name).name -eq $clustershare}

# derive path to resource parameters
$parameters = "$resource\parameters"

# configure security descriptor
set-itemproperty $parameters "security descriptor" $binarysd

It really is that simple.

Only problem is, this only works for one node and has to be repeated on every node. It does survive failovers (and the permissions set on a node will reappear when the share fails back to the node). Plus it only works for "fullcontrol", not for "read" or other permissions. Don't know why.

I won't accept this as an answer because it really isn't. But it appears to be the closest to a solution to this problem with in Windows Server 2003 simply didn't exist (cluster.exe could set share permissions) and that Microsoft don't seem to address ANYWHERE.

Andrew J. Brehm
  • 1,611
  • 7
  • 37
  • 57
  • The extra .binarysd and .name after functions that are supposed to return a binarsd or name respectively are because Powershell returns an object with a field that contains what was asked for. It's an annoying habit of Powershell's. – Andrew J. Brehm Sep 04 '12 at 07:51
  • All that replaces PART of the functionality of a one-line cluster.exe command in Server 2003! – Andrew J. Brehm Sep 04 '12 at 07:51