WFA - Conditional Approval Point - filter by Users role or AD group

[Greg_pebkac]

We have a workflow for creating LUNs to be attached to our ESX environment which has an approval point at the beginning so that new storage requests generated by our VMWare team are authorised before being executed.

I would like to set a condition on the approval point to test if a Storage Engineer is using the workflow and skip the Approval process.

I was thinking of doing this by checking the Users Role or their Active Directory group but I cant find a way of retrieving this information from within the workflow.

I have considered duplicating the workflow without the approval point but that would require maintaining 2 sets of code when we make changes.

Have looked into using a fucntion to call Get-WFARestParameter but couldn't see if it returned the role or AD group.

We are currently using WFA 4.1.

Fairly new to WFA so any suggestions would be appreciated. 

[NICKBARTON]

Greg, 

There is a locally defined variable $_WFAUser you define as a userinput and then reference to determine the current username who executed the workflow. It won't really give you any properties about group memebership just the username but with that you could then reference against a table of our choosing, potentially a custome table you create in the playground to determine if approval is requred or not. You could then set the condition of your approval step in your workflow based on the resultes of that filter.

There have been requests around since WFA 2 to allow more user based control within a workflow but I haven't seen anythign new get added in that regard. 

Hope it helps, 

Nick 

[Greg_pebkac]

Thank you for the feedback.

The use of an authorised users table could be a very simple solution since we have only a small group of authorised users.

In regards to the AD command I like that idea and will be investigating whether it can work in our environment - would depend on whether our AD administrators allow us to use a 'WFA' user to retrieve user details.

[mbeattie]

Hi Greg,

Yes that would also be an option however to build an authorised users table (assuming you wanted to perform a local database query, not an LDAP query) you'd need to create a WFA datasource to enumerate the membership of an AD group which would be cached locally on the WFA server. There is an example of one such datasource here:

http://www.wfaguy.com/2017/01/active-directory-datasource.html

All datasources use a schedule and therefore should be considered a cache. By configuring the WFA services to run as AD service account\user and using ADSI within your command to perform an LDAP bind, you are assured that the results are real-time during workflow execution. This avoids the scenario where a user may have been removed from an AD group but is still cached in the datasource. If the cache is used as the basis for authorization then a user may have authority to approve\invoke workflows until the datasource is updated as per its schedule (that might not be ideal depending on your security requirements).

In general it can be useful to run the WFA services as an AD serivce account. By default the WFA services run as Local System and therefore have no network access. Configuring an AD service account and delegating permissions appropriately in your enviroment enables a multitude of new automation possiblities and itegration with AD and other applications on your network. EG you can develop WFA workflows ot create AD sites\subnets\groups\computers and add\remove users from groups etc. IE anything you can do via .NET\ADSI\LDAP or PowerShell can be ported into WFA and integrated in your automation processes and invoked via a REST API.

Note: There are no special AD permissions required for an AD user to perform an LDAP bind or query.

Hope this helps. Please let me know if you have any questions

/Matt

[sinhaa]

@Greg_pebkac @mbeattie @NICKBARTON

I have a great solution to this requirement.  I wanted to post the logic last week itself but I thought let me also give a working prototype for you.

The logic:

Approval point condition has only be executed during workflow planning. So solutions which require command code execution will not work here.

So I need my user information available in WFA DB. I have no access to WFA users, BUT I have APIs which provide me this information. Eureka!. 

WFA can acquire data from absolutely any source, including itself. I have used WFA's self acquistion in many places and they work magical. A great example Slow WFA getAllWorkflows WSDL SOAP command

My requirement is:

EX: Approval point should appear only when members of Group 'G2'  role Operator execute this workflow. When members of other Group 'G1' role Admin execute this workflow, then NO approval point should appear.

So first I create a new scheme, new dictionary with the required columns and a new DataSource script which can use these WFA apis to acquire the required data into WFA db.

Scheme: wfadb

Dictionay: wfa_db_users

DataSource Type: WFA AD Users

I add a new Data Source for this Data Source Type and Let it acquire. 

For credentials I provide that of a WFA Admin users. Only Admins have access to API /users

Once acquired I have the user data with me.

Now at workflow.

I have a constant defined to select which Group should be allowed pauseless execution.

I have no way to know the current logged in users during workflow planning. So I need to ask this from the workflow executor himself. I have a command parameter to ask this information. Once the user has provided his username, I need a way to run a query to fetch his Group name and/or role from the acquired DB. This is where WFA function to run mysql query : The solution come is useful. 

Now this is how my workflow execution looks.

So I'm expected to select my own WFA login name and based on this, the approval point condition will be evaluated.

What if the workflow executor selects other's username? Ex: I am u6 but I select u5. Then the approval point will not come. As said there is no way to get the current username in planning, I can't do anything to catch this imposter during planning phase. BUT My command code can validate this information and fail further execution. So this has been covered.

When I'm logged in as u5 ( admin ) I select u5 from list of available domain users, I don't get any approval point. 

When I'm logged in as u6 ( Operator ), I select the user u6 from the drop-down list, I WILL get an approval point.

See the Approval point condition to understand more on the selection logic. Also see the row execution condition

Attached is a dar file ( WFA4.1 or above ) which is bundled in a WFA pack. A pack is a great way to distribute WFA contents. 

Let me know if you need more details on this.

sinhaa

[mbeattie]

Hi Greg

If you configure the WFA services to run as AD service account and add the account to the local administrators group, then restart the services your WFA server will be capable of use ADSI\LDAP to determine if a user is a member of a group (or you can configure\import the AD powershell module into the WFA powershell profile if you want to avoid ADSI).

Here is the source code for a command that will check to see if the WFA\AD user is a member of an AD group, if so it will suceed and log the results otherwise throw an error:

Param(
   [Parameter(Mandatory=$True, HelpMessage="The Distinguished Name of the active directory group")]   
   [String]$GroupDn,
   [Parameter(Mandatory=$False, HelpMessage="The name of the active directory user.")]
   [String]$UserName
)
#'------------------------------------------------------------------------------
#'Enumerate the current WFA user if the UserName parameter was not provided.
#'------------------------------------------------------------------------------
If(-Not($UserName)){
   [String]$UserName = $(Get-WfaRestParameter "userName")
}
Get-WFALogger -Info -Message "Checking group membership for user ""$UserName"""
#'------------------------------------------------------------------------------
#'Ensure the username syntax is valid.
#'------------------------------------------------------------------------------
If(-Not($UserName.Contains("\"))){
   Throw "The username ""$UserName"" is invalid. The syntax must be 'DomainName\UserName'"
}
[String]$domain = $UserName.Split("\")[0]
[String]$usr    = $UserName.Split("\")[1]
#'------------------------------------------------------------------------------
#'Perform an LDAP bind to the AD group using ADSI.
#'------------------------------------------------------------------------------
Try{
   $ntAccount = New-Object System.Security.Principal.NTAccount($domain, $usr)
   $sid       = $ntAccount.Translate([System.Security.Principal.SecurityIdentifier])
   $user      = [ADSI]$("LDAP://<SID=" + $sid.Value + ">")
   Get-WFALogger -Info -Message $("The SID for user ""$UserName"" is """ + $sid.Value + """")
   Get-WFALogger -Info -Message $("The Distinguished name for user ""$UserName"" is """ + $user.DistinguishedName + """")
   Get-WFALogger -Info -Message $("Performed an LDAP bind to ""LDAP://<SID=" + $sid.Value + """ for username ""$UserName""")
}Catch{
   Throw $("Failed performing an LDAP bind for user ""$UserName""")
}
#'------------------------------------------------------------------------------
#'Add the users group memberships to a hashtable.
#'------------------------------------------------------------------------------
[HashTable]$groups = @{}
ForEach($group In $user.MemberOf){
   [HashTable]$groups.Add($group, "")
}
#'------------------------------------------------------------------------------
#'Check if the groups distinguished name exists in the hashtable.
#'------------------------------------------------------------------------------
If($groups.ContainsKey($groupDn)){
   Get-WFALogger -Info -Message "The user ""$UserName"" is a member of group ""$GroupDn"""
}Else{
   Throw "The user ""$UserName"" is not a member of group ""$GroupDn"""
}
#'------------------------------------------------------------------------------

When configuring the workflow to use the command, enter the distinguished name of the group in quotes. A few ceveats in using this method:

• It assumes the distinguished name of the AD group is known and will not change. If the AD group is moved then the DN will not match
• It's a bit slow, there might be a more efficent method of doing this using the AD powershell module.

Note: If a username is not provided it will use the current WFA user who is authenticated

Hope that gives you a few ideas

/Matt