This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ARS 6.9 Script Execution Policy

Hi, I have ARS 6.9 and I need to add script execution policy to current policy which does the following:

  • Displays dialog box with Yes/No question (Create an user account in domain B?)
  • If answer to question is Yes
    • displays dialog box to enter credentials for other domain B
    • displays form from which user selects appropriate OU in domain B
    • creates user account and puts it into selected OU in domain B

NOTE: Current policy creates new user account in domain A and goal of adding script execution policy as last step is the following: If answer to question is Yes user with the same First Name, Last Name, SamAccountName, Display Name will be created in domain B using entered credentials with required permissions.

For some reason script module below has not been executed. Is ARS capable of executing scripts which deal with GUI elements? Also here I have implemented dot source technique since Choose-ADOrganizationalUnit function is inside C:\script\ChooseADOrganizationalUnit.ps1 script. I am very familiar with PowerShell but newbie in ARS.

 

function onPostCreate($Request)
{
Import-Module ActiveDirectory
Add-Type -AssemblyName PresentationFramework
Add-PSSnapin Quest.ActiveRoles.ADManagement
Connect-QADService -Proxy

$dn=$DirObj.Get(“distinguishedName”)

$givenName=Get-QADUser $dn | Select-Object -ExpandProperty FirstName
$surName=Get-QADUser $dn | Select-Object -ExpandProperty LastName
$samAccountName=Get-QADUser $dn | Select-Object -ExpandProperty SamAccountName
$name=Get-QADUser $dn | Select-Object -ExpandProperty Name
$displayName=Get-QADUser $dn | Select-Object -ExpandProperty DisplayName
#$userPrincipalName=Get-QADUser $dn | Select-Object -ExpandProperty UserPrincipalName


$toCreateUserinDSC = [System.Windows.MessageBox]::Show('Would you like to create a user in B domain?','New User','YesNo','question')

if($toCreateUserinDSC -eq "Yes") {
$cred=Get-Credential
. "C:\script\ChooseADOrganizationalUnit.ps1"
$ou=Choose-ADOrganizationalUnit -HideNewOUFeature
New-ADUser -GivenName $givenName `
-Surname $surName `
-SamAccountName $samAccountName `
#-Description $user.Description `
-Path $ou.DistinguishedName `
-Name $name `
-DisplayName $displayName `
-UserPrincipalName ($samAccountName + '@domainB.local') `
-AccountPassword (ConvertTo-SecureString -AsPlainText (-join (33..126 | ForEach-Object {[char]$_} | Get-Random -Count 10)) -Force) `
-Enabled $true `
-ChangePasswordAtLogon $true '
-Server dc1.domainB.local '
-Credential $cred
}
}

  • To me, sounds like a job for the ARS Sync Service. Boolean on your create user page "Check box to sync this account to Domain B" - Sync would queue off that change using credentials you configure the sync service to use. We do something a little less grandiose to ensure Domain A PIV related info is synced to Domain B.
  • Yep - or Active Roles consultant.
  • Dyannic, the sync service would be fine too but Bojan would need to come up with some kind of rule to automate the OU selection because there's even less opportunity for prompting the user there.
  • Please consider the following points:
    #A. ARS is AD-centric Domain-centric solution and does not have Metadirectory (like OIM and other IM solutions), therefore OOB ARS does not have ability to bridge cross-AD-domains.
    #B. You may consider Workflow (via custom Policy Script and/or on-Demand Workflow):
    1) OU=NewCreatedStagedDisabledUsers,DC=A – create all new A\users here (Disabled, random pwd, Attributes to be populated from outside “HR” (Company, Depart, manager, etc…)
    2) Workflow (script/on-Demand), same Company is “decision” mark attribute:
    3) IF Company –eq DomainB THEN Create New B\user and copy all attributes from A\user
    4) ARS Policy against B-domains: Populates the rest of group membership and attributes (if needed)
    5) IF Company –eq DomainB THEN Enable A\user and Move to OU=MyAccounts,DC=A
    6) ARS Policy against A-domains: Populates the rest of group membership and attributes (if needed)
    If you are not familiar with ARS engine, you will need PSO. PS1 knowledge is huge help here to support the proposed solution.