Outstanding Contributor.
Outstanding Contributor.

Issues with flow operations on Active Directory

We are developing a mildly complex set of flows which as one of the steps should create a new user in Active Directory. The OO version is 10.20, with Central running on Windows, and AD is 2012.

We have created a domain user with permissions to create such users in the required OUs and have verified that such user can indeed perform those tasks.

Now, when implementing that operation on the flow (using the java version of "Create User", from the "base" content pack) we are getting this error:

{returnCode=-1;returnResult=[LDAP: error code 19 - 00002082: AtrErr: DSID-03151817, #1:
0: 00002082: DSID-03151817, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att b (ou):len 166
];Result=-1;sessionId=;exception=javax.naming.directory.InvalidAttributeValueException: [LDAP: error code 19 - 00002082: AtrErr: DSID-03151817, #1:
0: 00002082: DSID-03151817, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att b (ou):len 166
]; remaining name 'cn=testOOuser'

We have verified as well that the user we are trying to create doesn't already exist in AD, we have tried different user names, and we have tried different passwords with varying complexity.

That's issue 1, which is seriously blocking us.


Issue 2 is that, as an attempt to workaround that problem (just in case it was a java issue), when trying to use the .Net version of "Create User" the operation is marked as "The operation this step links to has problems".

The test flow is a simple "Create User" step linked to "Resolved" and "Error" steps, so I'm not sure about what's the step that has problems and what those problems would be.

Is there any kind of extra requirement to be able to add .Net steps to a flow?



Labels (1)
4 Replies
Super Contributor.
Super Contributor.

I have had issues in the past with the .Net and used the JAVA operation for a while, but eventually had issues with that to. In my testing environment we play with 2003-2012 so I have resorted to either using exchange to create the user/mailbox concurrently or creating a powershell mod to create the account like so. With more tags you can add them to the group etc.. I like using the built in operations but when problems arise casued by patches, GPO's, STIGS etc.., sometimes its faster and easier to go pure powershell. Create your sub-flows from scratch.

$password=ConvertTo-SecureString -String '${apass}' -AsPlainText -Force; New-ADUser -Name ${auser} -AccountPassword $password -Enabled $true -UserPrincipalName ${auser}@${domainName};

Hope this helps

Outstanding Contributor.
Outstanding Contributor.

Thanks, going powershells sounds like a good and cleaner idea, although that would require remote execution of PS scripts on the AD server and a user with privileges to do so.

We would have to take a different security approach to achieve that, as currently we just have a service account only allowed to perform the required tasks on AD.

Super Contributor.
Super Contributor.

Yes it does require privileges and if your RAS is not part of the domain you have the doublehop problem. I deal primarily in cyber testing environments so I have the flexibility of privilege escalation, however, when tests requires lockdowns I accomplish this by applying GPO's to open up automation and then after I am finished I apply a GPO that locks it back down, turning off remote execution, etc..

An example of privilege user problems is when you are trying to install exchange remotely Windows 2012 and below from a non-domain RAS. Because of the level of privileges, you simply can't run a script remotely so I generate a script on the ras, transfer it and then run it remotely. The ps then opens locally on the end node and generates an escalated ps session on itself that has the necessary privileges like so

$pass=ConvertTo-SecureString -String "${domainPassword}" -AsPlainText -Force
$cred=New-Object -TypeName System.Management.Automation.PSCredential -argumentlist $user, $pass
$r=new-pssession -computername $server -Authentication Credssp -credential $cred
invoke-command -session $r -scriptblock {......}

Outstanding Contributor.. Outstanding Contributor..
Outstanding Contributor..

Yes, I agree with PowerShell it would effective, we have in a case that once the server is unprovisioned from CSA / OO server Ad-Computer account need to be disabled and move t another OUand customer wouldn't give direct access to Active Directory so the only solution was to do remote PowerShell with specific user account that does disable Computer account in AD, so what we have done is Adding Active Directory PowerShell Module in OO server and do flow that run on OO server itself and do action


Example Script  : 

Import-Module ActiveDirectory

$userName = "${username}"

$secure_string_pwd= convertto-securestring "${password}" -asplaintext -force

$cred = new-object management.automation.pscredential $userName,$secure_string_pwd


$Adaccount = Get-ADComputer ${vm} ActiveDirectory\Disable-ADAccount $Adaccount -credential $cred


ActiveDirectory\Move-adobject $Adaccount -targetpath "OU=Disabled,ou=Servers,ou= Computers,dc=domain,dc=local" -Credential $cred Get-ADComputer ${vm}



That might be taking a time to develop any scenario in mind it's just a matter of getting it work.



Mostafa Hassan
If my post helped you, kindly click the 'Kudos' button.
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.