|
| 1 | +# Built-in Scripts |
| 2 | + |
| 3 | +This folder contains PowerShell scripts used in the built-in Microsoft Active Directory (AD) connector for HelloID Provisioning. These scripts are automatically triggered during specific actions such as Create, Enable, Update, Disable, and Post-actions. You can customize them to reflect your internal structure and logic. |
| 4 | + |
| 5 | +--- |
| 6 | + |
| 7 | +## Scripts |
| 8 | + |
| 9 | +### `uniquenessCheck.ps1` |
| 10 | +- **Description:** Checks if key user attributes like `sAMAccountName`, `userPrincipalName`, `mail`, and `proxyAddresses` are unique in Active Directory. |
| 11 | +- **Use Case:** Use when HelloID's default uniqueness check isn't flexible enough—for example, when you want to sync `sAMAccountName` and `cn` separately from `mail` and `UPN`. |
| 12 | + |
| 13 | +> [!NOTE] |
| 14 | +> The built-in uniqueness check should not be used together with this script. You must choose one or the other. If you opt to use this script, make sure to deselect all the fields from the "unique fields" section that you want to check with the script. |
| 15 | +> |
| 16 | +> While it’s technically possible to use both, for example, by selecting `userPrincipalName`, `mail`, and `proxyAddresses` for the built-in check and using this script for `commonName` and `sAMAccountName`, it's recommended to use only one method. This ensures greater clarity and simplicity in your configuration. |
| 17 | +
|
| 18 | + |
| 19 | +--- |
| 20 | + |
| 21 | +## `orgUnit` Folder |
| 22 | + |
| 23 | +These scripts determine which Organizational Unit (OU) a user should be placed in during specific lifecycle events. |
| 24 | + |
| 25 | +### `initialContainer.ps1` |
| 26 | +- **Description:** Calculates the OU where a user account should go when it is created. |
| 27 | +- **Use Case:** Place new accounts in different OUs based on department or other person attributes. |
| 28 | + |
| 29 | +### `enableContainer.ps1` |
| 30 | +- **Description:** Calculates the OU where a user account should go when it is enabled. |
| 31 | +- **Use Case:** Useful when enabled users need to be placed in active OUs that differ per department. |
| 32 | + |
| 33 | +### `updateContainer.ps1` |
| 34 | +- **Description:** Calculates the OU where a user account should go when it is updated. If the account is enabled, it goes to the active OU; if disabled, to the disabled OU. |
| 35 | +- **Use Case:** Keeps users in the correct OU based on their current status and department. |
| 36 | + |
| 37 | +### `disableContainer.ps1` |
| 38 | +- **Description:** Calculates the OU where a user account should go when it is disabled. |
| 39 | +- **Use Case:** Useful when disabled users need to be placed in active OUs that differ per department. |
| 40 | + |
| 41 | +### `orgUnit.DefaultOUFallback.ps1` |
| 42 | +- **Description:** Calculates a target OU based on department and graduation year. If no specific OU is found, it falls back to a default OU. |
| 43 | +- **Use Case:** Use this when OUs are structured by department and year, and you want to ensure a fallback OU exists. Especially useful in education or large organizations where users are grouped by year or department. |
| 44 | + |
| 45 | +### `orgUnit.Disable.DynamicLocation.ReferenceExample.ps1` |
| 46 | +- **Description:** Calculates the OU based on user location when the account is disabled. Resolves a base OU and searches for a specific OU inside it. |
| 47 | +- **Use Case:** Useful in organizations where disabled accounts are organized by geographic location. |
| 48 | + |
| 49 | +### `orgUnit.Enable.DynamicLocation.ReferenceExample.ps1` |
| 50 | +- **Description:** Calculates the OU based on user location when the account is enabled. Works the same way as the disable variant but for active accounts. |
| 51 | +- **Use Case:** Use when enabled users must be placed in location-specific OUs. |
| 52 | + |
| 53 | +### `orgUnit.Update.DynamicLocation.ReferenceExample.ps1` |
| 54 | +- **Description:** Calculates the OU based on both location and account status (enabled or disabled) when the account is updated. |
| 55 | +- **Use Case:** Use this when user OU placement depends on both geographic location and whether the account is active or not. |
| 56 | + |
| 57 | +--- |
| 58 | + |
| 59 | +## `postAdAction` Folder |
| 60 | + |
| 61 | +These scripts run after the main AD action has been completed (Create, Enable, Update, or Disable). |
| 62 | + |
| 63 | +### `postAdAction.create.UpdateADAccountMsExchHideFromAddressLists.ps1` |
| 64 | +- **Description:** Updates the `msExchHideFromAddressLists` attribute after account creation. |
| 65 | +- **Use Case:** Hide a user’s mailbox from Exchange address lists when not using the built-in Exchange integration or when the options of the built-in Exchange integration do not suffice. |
| 66 | + |
| 67 | +### `postAdAction.disable.UpdateADAccountDescription.ps1` |
| 68 | +- **Description:** Updates the `description` field in AD after the account is disabled, appending a timestamp and reason. |
| 69 | +- **Use Case:** Useful for audit trails or tracking when and why an account was disabled. |
| 70 | + |
| 71 | +### `postAdAction.enable.ResetPassword.ps1` |
| 72 | +- **Description:** Generates a new random password and resets it for the user after the account is enabled. |
| 73 | +- **Use Case:** Provide a fresh password as part of the enablement process, making it available for the notifications. |
| 74 | + |
| 75 | +### `postAdAction.enable.UpdateADAccountDescription.ps1` |
| 76 | +- **Description:** Updates the `description` field in AD after the account is enabled, appending a timestamp and reason. |
| 77 | +- **Use Case:** Add clarity to AD records by documenting HelloID enablement. |
| 78 | + |
| 79 | +### `postAdAction.update.UpdateADAccountNames.ps1` |
| 80 | +- **Description:** Updates the `sAMAccountName`, `userPrincipalName`, and `email` if the user's first or last name changes. |
| 81 | +- **Use Case:** Use when updates should only be performed if specific properties, such as givenName or surName, have changed, and should not trigger updates when other properties, like department or title, are modified. |
| 82 | + |
| 83 | +--- |
| 84 | + |
| 85 | +## Getting Started |
| 86 | + |
| 87 | +To use these scripts: |
| 88 | +- Make sure your HelloID Provisioning environment is properly configured. |
| 89 | +- Customize the logic to reflect your organization's structure. |
| 90 | +- Test in a non-production environment before deploying to production. |
| 91 | + |
| 92 | +--- |
| 93 | + |
| 94 | +> ⚠️ Note: These scripts are templates and examples. Review and adapt them to your specific environment before use. |
0 commit comments