Using PowerShell Endpoints in WFA

[markweber]

I'm just throwing this out there in case someone finds it useful.

I had a need to do several non-NetApp, Windows specific steps as part of a workflow (DFS, ACLs, etc) and I found several pointers in the community site but most seemed to need the WFA service account changed to an AD domain account that had rights to perform the desired action. That left me feeling uneasy - I would probably end up with some monster account that had permissions all over the place.

While playing around with different options, I ran across @sinhaa LDAP workflow: http://community.netapp.com/t5/OnCommand-Storage-Management-Software-Discussions/Has-Anyone-got-AD-groups-into-WFA/m-p/109583/highlight/true#M19318 and that got me thinking about using non-priveleged credentials in WFA to connect to constrained endpoints.

so this is how I set it up for creating DFS links:

create two AD accounts:

DFS_privilege_account - delegate DFS rights to this account

DFS_nopriv_account - standard account

add DFS_nopriv_account to the WFA credential store with name: dfs and type: Other

create constrained PowerShell endpoint (could be on WFA server or any Windows server you can remote to and can communicate with the DFS servers):

• install DFSN powershell module
• create <path>\DFSConstrainedSession.ps1 ( https://gist.github.com/mrkwbr/319c4552e623783fe308b1eb1493d1b7 )
• Register-PSSessionConfiguration -Name DFSConstrainedSession -RunAsCredential 'DFS_priviledge_account'  -StartupScript '<path>\DFSConstrainedSession.ps1' -Force
• Set-PSSessionConfiguration -Name DFSConstrainedSession -ShowSecurityDescriptorUI
• add DFS_nopriv_account with full control (optionally remove the other groups)

write your WFA commands to use the endpoint - this is my "Create DFS link" command - which has hard coded computername and configurationname, but those could easily be turned into params:

param (
  [parameter(Mandatory=$true, HelpMessage="DFS Credentials")]
  [string]$DFSCredentials,
  [parameter(Mandatory=$true, HelpMessage="DFS TargetPath")]
  [string]$DFSTargetPath,
  [parameter(Mandatory=$true, HelpMessage="DFS Path")]
  [string]$DFSPath
)

if ($PSVersionTable.PSVersion.Major -le '2') {
    throw('Minimun PowerShell version required is 3.0')
}

$DFSCreds = Get-WfaCredentials -Host $DFSCredentials
if (!$DFSCreds) {
    throw('No credentials added for DFS')
}

$DFSNModule = Get-Module -ListAvailable -Name DFSN
if (!$DFSNModule) {
    throw('No DFSN module found')
}

Get-WFALogger -Info -message $("Testing DFS link: " + $DFSPath)

Get-DfsnFolder -Path $DFSPath -OutVariable DFSPathCheck -ErrorAction SilentlyContinue
if ($DFSPathCheck) {
    throw('DFS Path already exists')
} else {
    Get-WFALogger -Info -message $("DFS link: " + $DFSPath + " not found")
}

Get-WFALogger -Info -message $("Creating DFS link: " + $DFSPath)

# Create DFS link
[string]$cmd = "New-DfsnFolder -Path $DFSPath -TargetPath $DFSTargetPath"
[ScriptBlock]$scriptblock = [ScriptBlock]::Create($cmd)
$session = New-PSSession -ComputerName localhost -ConfigurationName DFSConstrainedSession -Credential $DFSCreds
$results = invoke-command -session $session -scriptblock $scriptblock

Get-WFALogger -Info -message $("New-DFSNFolder results: " + $results)

I'm sure i'm missing some details (I'm defintely assuming that remoting already works) but hopefully it is enough to get you started.

mark

[sinhaa]

@markweber

The code works and I like the idea of self-remoting and providing the credential at execution time. Good one.

But, the premise to the solution i.e. having an non-privileged credentials to do this is NOT right. The cmdlet

New-DfsnFolder

doesn't take any credential but the credential are validated implicitly as the user who is executing the the cmdlet. This is where running the WFA server service as a user account is needed. Its not a WFA requirement but a windows security requirement. To identify itself as who is executing this cmdlet.

Any user who can do remoting to windows doesn't mean he can get to execute all cmedlets and even this.

So in the end  when doing Invoke-Command you have to provide a credential of a User who is privileged to run this. Ya this method allows multiple users to provide their own credentials. One of these credentials can be used in Server account too. Its user choice as both these methods have their advantages.

sinhaa

[markweber]

that is why the remoting endpoint is setup to run as a specific account (DFS_privilege_account in my example) - anyone that can successfully authenticate to the endpoint has the privileges necessary to run new-dfsnfolder since it will be running as DFS_privilege_account - does that make sense?

[sinhaa]

@markweber

Got it Mark. Thanks for sharing the idea. Let's see the other side.

Will every users who is executing the workflow will have DFS_privilege_account credentials available to him. I could run into a problem of sharing a credential with multiple WFA workflow executors. Will I be okay to share the DFS_privilege_account credentials with everyone who would execute this workflow. 

This is where the WFA Server service accout solution comes in use. The person who is proviledged can provide the credentials into the WFA service account, The workflow now doesn't need any credentials at all. So any user can execute this workflow without having to worry about the credentials, and no credential share is needed either.

Now as I type this message, I see that there is a third mid-way alternative as well.

You don't want to start the WFA service as User Account, and you don't want to share credentials or have workflow executors give credentials during execution.

Save the DFS_privilege_account  credentials of 'localhost' in WFA as type 'Other' and in your command you can 

$creds = Get-WfaCredentials localhost

that's all.

sinhaa