Announcing the Saviynt Knowledge Exchange unifying the Saviynt forums, documentation, training,
and more in a single search tool across platforms. Read the announcement here.
No ratings
sudeshjaiswal
Saviynt Employee
Saviynt Employee

Use Case

  • An Organization got multiple member companies that created due to the nature of business or through acquisition. 
  • Users are onboarded in to SSM from one or more authoritative sources.
  • Each user need to be provisioned with unique AD account & email address across of the member companies.
  • Users can get transferred from one-member company to another, in such a scenario the AD account name should be the same.

Requirements

  1. There are multiple AD domains (one for each member company) and accounts for a new user to be created (as birthright access) in a domain based on the company name details of the user.
  2. The AD account created should be unique across all domains.
  3. Accounts once issued to a user should not be reused for any other user which includes historical records/accounts that were assigned to users earlier and the user left the company.
  4. There are scenarios where a user can have an account in more than one domain, in such scenario the account will be requested by user and account to be created after approval.
  5. Each AD account should have a mapping of line manager's details mapped but if the line manager is CEO or C-Level executive, then manager detail should not be set in AD though SSM receives manager details from HR system/authoritative source.
  6. There are huge number of OUs (based location where the organization operates) in AD and newly created account should be automatically placed in an OU based on location identifier received from HR system (the location code may not be same as OU name)
  7. If user getting transferred from one location to another location, then the user's AD account should be automatically moved the respective OU
  8. If User is getting transferred from One company to another, then birthright AD account created should be disabled and new AD account to be created in an AD domain that belongs to the company where user got transferred.
  9. When user employment gets terminated, AD account should be disabled, moved to a designated disabled users OU and update the AD Account description as 'Disabled due to employment termination'.
  10. When user going on LOA (employment status will be Active & LOA status will be received from HR system), the account should be disabled, moved to the designated disabled users OU and update the description to 'Disabled due to LOA'
  11. If the user did not login/used the AD account for 90 days (employment status will be still active), disable the account, update the description to 'Disabled by SSM due to LOA' but do not move the account to Disabled users OU.
  12. Account will be disabled on Day-0 of termination and deleted on Day-30 of termination.
  13. When a user returns from LOA (LOA status update will be received from HR system), enable the AD account, move from Disabled users OU to a OU based on user's location identifier and update the description with user attribute value.
  14. When a user gets rehired within 30 days, enable the AD Account, move from Disabled users OU to an OU based on user's location identifier and update the description with user attribute value.

Pre-requisites


AD Connections 

Applicable Version(s)


All
 

Solution

 
  1. Achieved using Technical rules and trigger AD account creation tasks based on user attributes like company name
  2. Achieved using system UserName as AD account. System user name will be unique across the users object in SSM
  3. Historical records are imported in SSM and kept the user status as Inactive (for the users already left the company and accounts are no longer in any of the AD domain). For the existing active users, AD account name is updated as system User Name using CSV file import process as one time activity. Status of any user leaving the organization will be updated to Inactive but will not be deleted.
  4. ARS module and approval workflows used.
  5. Refer to Create account JSON and update account JSON included here
  6. Refer to ACCOUNTNAMERULE section in JSON included here
  7. User update rules used to trigger update account tasks which will use UPDATEACCOUNTJSON & ACCOUNTNAMERULE (refer JSON for details)
  8. User update rules used to disable current AD account, generate new email address based on new company name and user object will be run through birthright access rules
  9. User update rules used. Refer to the DISABLEACCOUNTJSON for the details actions
  10. User update rules used. Refer to the DISABLEACCOUNTJSON for the details actions
  11. Actionable analytics report used to generate disable account tasks and DISABLEACCOUNTJSON used for action
  12. User update rules used to generate disable account tasks and future dated tasks are used to delete accounts. 
  13. user update rules, ENABLEACCOUNTJSON & ACCOUNTNAMERULE used
  14. user update rules, ENABLEACCOUNTJSON & ACCOUNTNAMERULE used. Enable the option 'Discontinue Pending Task on User Rehire' under the global configuration section 'Identity lifecycle' 
 
PFA JSON Format file.
 
Version history
Last update:
‎03/30/2023 10:39 AM
Updated by:
Contributors