Auto-populate AD OU's

Question

Is there a way to auto-populate AD group membership without specifying a separate condition statement for each group? I was hoping to pass the 'department' value by reference after the user is created and then have the membership assigned to the referenced group accordingly.

Answer 1

Hello,

Yes it is possible using a script. Here is a sample one:

Import-Module Adaxes
# Bind to a group. The distinguished name of the group depends on the Department property of the user.
$myGroup = Get-AdmGroup "CN=%department%,CN=Users,DC=company,DC=com"
# Add the user to the group
Add-AdmGroupMember $myGroup "%distinguishedName%"

To use the script, you need to install the Adaxes PowerShell Module on the computer, where the Adaxes service is running. Adaxes PowerShell Module is installed with the same installation package as used to install Adaxes service.

For more details, please see Automatically Change Group Membership Using Scripts.

Comments

Hi Eugene,

This script isn't working, it keeps creating the user in the 'AD Users' container versus, for example, the IT OU.

Something I noticed is my PowerShell doesn't have a Get-AdmGroup or a Add-AdmGroupMember command. I'm I missing something here?

Thanks.

---

Sorry, nevermind, I didn't copy the entire thing. I'll let you know when it works . . .

---

Ok, it's definitely not working. I'm trying to create the user(s) in an OU (department) within another OU (Business Line). No matter what I do, it places the user in AD Users. Here's the DN: OU=IT, OU=ABC_Line, DC=Contoso, DC=org.

Any help would be greatly appreciated.

---

Hello,

I'm not sure I understand you correctly. The script above adds existing users to groups based on the user's department. But you are trying to create users...

Do you use a script or UI to create users? If you use a script, can you post it here?
Are there any Business Rule that move newly created users between OUs?

---

First, I may have added to the confusion with my original post by using the word "group". I should have stated,
"Is there a way to auto-populate AD OU membership without specifying a separate condition statement for each OU?"

All is not lost however since we will be moving members into specific Security Groups as part of this task. To answer your current question:

We've constructed a Human Resources portal using Adaxes which an HR technician fills in during the new hire process. The portal was built by copying the Adaxes\Admin UI, tailoring it and renaming it to HR. HR uses the portal to specify, for example, the person's name, their city of employment, and their department. Based on the information provided from the HR user-interface, we have a Business Rule which is trying to populate the appropriate Domain (DC), Company (DC), City (OU), and Department (OU) "After creating a User or InetOrgPerson". The scope of the rule is "OurCompany.org". This Business Rule is not performing as we would like because it's placing the new hire into "OurCompany.org/Users" versus "OurCompany.org/City/Department/Users".

---

Hello,

OK, now it's clear. Here is a script that moves users to the appropriate OU based on the Department property of the user account.

Import-Module Adaxes

$department  = "%department%"
$departmentMap = # TODO: modify me
@{ 
  "IT"="OU=IT,DC=company,DC=com";
  "Sales"="OU=Sales,DC=company,DC=com";
}

$targetOU = $departmentMap[$department]

if ($targetOU -eq $NULL)
{
    $Context.LogMessage("No target OU specified for department '$department'", "Warning")
    return
}

Move-AdmObject "%distinguishedName%" $targetOU

You can use the script in your Business Rule that is triggered after user creation.

Before using the script, you need to map department names to DNs of corresponding Organizational Units.
To get the DN of an Active Directory object:

1. Launch the Adaxes Administration Console.
2. Right-click the object you need.
3. In the context menu, open the submenu of the Copy item.
4. Click Copy DN. The DN of the selected Active Directory object will be copied to the clipboard.
   

To use this script, you need to install the Adaxes PowerShell Module on the computer, where the Adaxes service is running. Adaxes PowerShell Module is installed with the same installation package as used to install Adaxes service.

---

Hi Eugene,

I'd like to say this is working, but it is still placing new users into "MyCompany.org/Users". I copied the IT DN and placed it in the code per your suggestion (the IT OU is the only one so far for test purposes).

Here's the modified script:

Import-Module Adaxes

$department = "%department%"
$departmentMap = # TODO: modify me
@{
"IT"="OU=IT,OU=Office Staff,OU=MyCity,OU=MyBusinessUnit,DC=MyCompany,DC=org";
}

$targetOU = $departmentMap[$department]

if ($targetOU -eq $NULL)
{
$Context.LogMessage("No target OU specified for department '$department'", "Warning")
return
}

Move-AdmObject "%distinguishedName%" $targetOU

It is set to run "If the opeation succeeded then *Run PowerShell script 'Bind user to an OU' for the User"

I also ran this at the server to remove possible network issues.

Any help would be greatly appreciated . . .

---

Hello Mark,

The script looks good.

Please post here a screenshot of your Business Rule (including the Activity Scope section).
Is the operation Execution Log displayed after a new user is created? If yes, please post a screenshot of it here.

---

Hi Eugene,

Activity Scope was the problem. It was limited to one business line. Once I expanded the scope to All Objects, everything fell into place. Now I'm off to adding the rest of the departments, creating home drives, exchange accounts, etc., etc.

Thanks again for your help.

Mark

---

Glad to help ;)

---

I am using the script to do the same function as the topic of this thread. However, I want to prevent any selection or views of the AD tree (selection of an OU) when a user is provisioned via the portal. The only way I know how to do this is to select the option in this box:

How can I utilize the powershell script to place the new user account into the OU while also not allowing the provisioning user to see or otherwise select the targets in AD?

---

Hello Joe,

The Always use this OU/Container option does not override Business Rules. Most probably, it is an Activity Scope issue. Is the operation Execution Log displayed after a new user is created?

Also, take a look at the Activity Scope of your Business Rule. Does it include the OU that you specify in the Container DN field? Can you post a screenshot of your Business Rule (including the Activity Scope section) here?

---

It's good to know the business rule takes precedence. The business rule for user provisioning for us is really long due to the extensive group mapping. However, I believe that the activity scope is correct:

I was able to narrow the scope of the two possible OU's using an LDAP filter. I'd still prefer the provisioning user to not be able to select it. So, I'll test this more.

---

Hello Joe,

The assignments look good, but I cannot see the last two columns. Can you post a bigger screenshot?

---

---

Hello Joe,

Probably, the issue is that the conditions of your Business Rule are not met. Can you also post the actions and conditions of your Business Rule?

---

I'm attempting to use this script and receiving the following error:

Cannot validate argument on parameter 'TargetPath'. The argument is null or empty. Supply an argument that is not null or empty and then try the command again.

This is my modified version of the script:

Import-Module Adaxes
$Office = "%Office%"
$departmentMap = # TODO: modify me
@{
"Dallas"="OU=USA-Dallas,OU=Adaxes,DC=mydomain,DC=local";
"London"="OU=GBR-London,OU=Adaxes,DC=mydomain,DC=local";
}
$targetOU = $departmentMap[$Office]
if ($targetOU -eq $NULL)
{
$Context.LogMessage("No target OU specified for Office '$Office'", "Warning")
return
}
Move-AdmObject "%distinguishedName%" $targetOU

---

Michael,

The value reference for the Office property is not %Office%, it is %physicalDeliveryOfficeName% because the LDAP name for this property is physicalDeliveryOfficeName. Here's the script modified to your needs:

Import-Module Adaxes
$Office = "%physicalDeliveryOfficeName%"
if ([System.String]::IsNullOrEmpty($Office))
{
    $Context.LogMessage("The Office property is not specified", "Warning")
    return
}

$departmentMap = # TODO: modify me
@{ 
    "Dallas"="OU=USA-Dallas,OU=Adaxes,DC=mydomain,DC=local";
    "London"="OU=GBR-London,OU=Adaxes,DC=mydomain,DC=local";
}

$targetOU = $departmentMap[$Office]
if ([System.String]::IsNullOrEmpty($targetOU))
{
    $Context.LogMessage("No target OU specified for Office '$Office'", "Warning")
    return
}
Move-AdmObject "%distinguishedName%" $targetOU

We tested the script in our testing environment and it works perfectly. We didn't manage to reproduce the error that you get.

---

Thank you that did the trick!