Unable to Launch Active Directory Users and Computers (ADUC) from Blue Prism

[Sudha_RPA]

Hi Community,

We have an automation requirement to automate Active Directory Users and Computers (ADUC) using Blue Prism.

ADUC opens successfully when launched manually via Run → dsa.msc, however we are facing failures when trying to launch it from Blue Prism.

Configuration Used in Application Modeller

Application Path:
C:\Windows\System32\mmc.exe

Command Line Parameters:
C:\Windows\System32\dsa.msc
(or) dsa.msc

Options Enabled:
tick Disable invasive techniques

Despite this, Blue Prism is unable to launch ADUC.

Looking for guidance on:

• Any special configuration required to launch MMC snap-ins (dsa.msc) from Blue Prism

• Possible 32-bit vs 64-bit or System32/SysWOW64 considerations

• Permission or Run-As requirements

• Recommended best practices for automating ADUC

Has anyone faced a similar issue or found a reliable workaround?

Any inputs would be greatly appreciated.

Thanks in advance,
Sudha

 

[rabbanir]

Hi Sudha,

I'm not sure if this will be of help but we also have a process that uses ADUC however a requirement is that the bot must log into an an account with elevated privileges in AD, I achieved this by getting blue prism to launch a batch file, it then enters the password into the cmd prompt that appears. This then launches ADUC which I then get blue prism to attach to:

 start process action to run batch file:

Batch file itself contains the following command:
runas /netonly /user:username@domain"mmc %SystemRoot%\system32\dsa.msc"

this launches a cmd prompt which the bot attaches to and enters the password for the account with elevated access. ADUC is launched and it attaches:

Kind regards,

Raheel

[Sudha_RPA]

Thanks for the reply but somehow the method I mentions Above Worked.

[jordan.harvey.norfolkcc]

We automate quite a lot within Active Directory, from access control to device management. A long time ago the console was used to interact with AD, however it proved rather slow to maintain. Instead I'd recommend looking at the System.DirectoryServices namespace within a code object which is the Microsoft supported way to automate Active Directory within the dotnet stack.

https://learn.microsoft.com/en-us/dotnet/api/system.directoryservices?view=windowsdesktop-10.0&viewFallbackFrom=netframework-4.7.2-pp

In terms of credential and security management, I would highly recommend ensuring your AD service accounts you use follow the principal of least priviledge. If they only need to modify a set of objects in a specific OU, then limit them to that OU and only the permissions needed to perform those actions.

I define my processes with whitelists of objects that they can modify, this ensures that a given process can only manipulate certain pre-approved groups, and anything outside of that is sent for manual review.