ServiceNow- Microsoft Active Directory INTEGRATION: Unable to change userPrincipalName (UPN)
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
16m ago - last edited 12m ago
Description:
We are using the Microsoft Active Directory v2 Spoke (IntegrationHub) to provision new AD user accounts via a ServiceNow Flow. We have identified two separate gaps in the spoke's available actions and need guidance or a fix for both.
Issue 1: userPrincipalName (UPN) not settable
- The "Create User" and "Update User" actions in this spoke do not expose any field for setting userPrincipalName (UPN).
- Our organization's AD forest uses two different values: the AD domain is ckrcorp.com, but user accounts need their UPN set explicitly to <username>@ckr.com (a registered alternate UPN suffix).
- Accounts created via this spoke default to UPN <username>@ckrcorp.com, which is incorrect for our use case.
- We reviewed the full list of actions available in this spoke (via Action Type Bases) and found no action (e.g., "Update Object," "Set Attribute") that can write this attribute either during or after account creation.
Issue 2: PasswordNeverExpires not available
- Our organization's requirement is for newly created AD accounts to have the "Password never expires" account option enabled at creation.
- We searched the "Additional Fields" dropdown on both "Create User" and "Update User" actions (which lists other AD attributes such as City, Company, Country, Department, Description, Home Directory, Mobile Phone, Office Location, Sam Account Name, State, Street Address, Title) but could not find any field corresponding to "Password Never Expires" or the underlying AD attribute (userAccountControl / PasswordNeverExpires).
- This means we currently have no way to set this option through the spoke.
What we need for both issues:
- Confirmation on whether the AD_v2 Spoke supports setting these attributes through any existing action we may have missed, or
- Guidance on the supported way to extend/customize this spoke to add this capability (e.g., via a custom PowerShell-based action, similar to how Create User/Update User execute PowerShell under the hood)
0 REPLIES 0
