• State Suggested Answer
  • Locked Locked
  • Replies 14 replies
  • Answers 1 answer
  • Subscribers 66 subscribers
  • Views 10270 views
  • Users 0 members are here
Options
Related
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

BojanNS

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
}
}

  • 0
    Active Roles is not really capable of producing a prompt like that.

    An option I would suggest is having a virtual attribute added - for example "edsvaUserDomain" and prompting for this in the user creation wizard?

    All you would have to do is:

    1) Add the virtual attribute to the user class
    2) Create a property value generation policy that offers up the domains of in your environment as options.

    User will then be asked to select one of the values - you could set a default in the rule.

    I would be curious as to WHY you are doing user creation this way? Are these "secondary" accounts for existing users?

    It just seems strange that you would go to the trouble of creating a script policy for what is a built-in operation in Active Roles.
  • 0

    No, these accounts will be created in domain A as normal user provisioning and after that if answer to a question is yes user with same properties (samaccountname, firstname,lastname ...) will be created in domain B too (under entered credentials) in selected OU. Domain A and domain B do not "see" each other - they are in different forests and ARS is running on machine in domain A. Domain B can not even be added as managed domain. I know this idea might sound weird but I was given a task to do that. Currently there is a policy for user provisioning with many sub-policies (validation of user attributes, generating strong passwords, creating exchange mailbox ...) so I thought adding script execution policy which would call PS script doing what I mentioned was possible solution. As I said I have never worked with ARS before - PowerShell was my primary tool and GUI was not necessary.

  • 0
    Ah OK - then I would change the the approach slightly.

    Again, create a virtual attribute (for User class) to be used during the user creation process:

    edsva_Needs_DomainB_Account

    Make it Boolean (in the Web UI, that would make it a checkbox (you will need to add it into the New User Wizard) - in the MMC, it will be a dropdown.

    Add a property value generation rule for the above attribute and include a default value of FALSE.

    Then just add this to the top of your script above:

    If $Request.get("edsva_Needs_DomainB_Account") -ne $true {return}
  • 0
    Also, your are going to have to figure out a way to supply a credential to your script.

    You could add virtual attributes to the user create wizard for this as well - maybe something like:

    edsva_DomainB_DA_User

    edsva_DomainB_DA_User_Pwd

    ...within your code, you will need convert the second one to a secure string for passing as credentials.

    You could also look to use credentials stored in a file on the AR server but this a bit more complex to implement and possibly painful to manage.

    It's a pity you can't add the other domain as a managed domain (a trust is not needed) as this would simplify things somewhat.
  • 0
    And what about displaying form to select OU? What is needed for domain B to be "reachable" and added as managed domain?
  • 0
    To make Domain B manageable, you need the same ports open as you would need to be able to use ADUC against it.

    Plus, you would need an account to configure as the "override account" on the Managed Domain. This account would need to be able to read the contents of the domain and in your case, create users.

    Once you get it in place as a managed domain, the OU selection is simple - you can browse the domain and create the user by starting the creation in the right OU.

    Otherwise, you could use another virtual attribute to add to the user creation Wizard - maybe call it edsva_Target_OU In this case, if you specify the "syntax" of that virtual attribute to be a distinguishedname, you get searching for an OU "for free" from Active Roles.
  • 0
    Ok so standard ports listed in admin guide? I doubt security team would be pleased with that but ball is in their yard. It looks like without that selecting OU from some form is impossible to accomplish since PS code for that can not be executed?
  • 0
    You could use some code to enumerate the OUs in the target and populate a virtual attribute with the list.

    Search the ActiveRoles SDK for IEDSEffectivePolicyRequest::SetEffectivePolicyInfo
  • 0
    Hmm list can not display hierarchical tree view and OU can have same name but under different parent OU ... I need user-friendly tree view the most similar to ADUC.
  • 0
    This becomes more and more developers area and I am "only" senior system engineer. :-)