We are planning to launch a service account campaign and we were advised to set Account Type attribute to 'Service Account'.
we have around 1000+ account and doing it through CSV upload is very time consuming also we are looking for a way that will ensure this attribute is set for future accounts.
It's AD based Connector.
Solved! Go to Solution.
Option 1 - Perform account import on Saviynt for Saviynt DB connection to update the account type for AD application for the accounts starts with 's-' (hope this is the naming convention for the service accounts)
Option 2 - Perform account import on Saviynt REST connection to update the account type for AD application for the accounts starts with 's-' (hope this is the naming convention for the service accounts) --> Saviynt Recommended
could you elaborate the second option a little bit more? The account import for the AD security system is already using AD connection. I don't quite get how we can update the same account object in Saviynt by using the account import of another connection.
@Enakshi we are facing the same issue for personal accounts. In our case primary and admin. The mentioned field is not set on the request form, but we have dedicated endpoints for every account type:
Endpoint1: AD Primary
Endpoint2: AD Admin
We also have dedicated AD on premise attributes, that define the account type.These values are set during provisioning in AD.
The issue is, that the wording should be different in AD on prem and in Saviynt. For example the values for the primary account would be:
Is it possible to transform those values via import or is it possible to automatically write the account type afterwards to the accounts considering a the AD on prem attribute?
1. First do AD accounts import
2. Write Sav to Sav to change the account type based on your logic/requirement. Below is the sample of the Sav to Sav. You can use this as base and modify it as per your requirement.
<![CDATA[Select a.name as name, s.SYSTEMNAME as securitysystem,e.ENDPOINTNAME as endpoint,
WHEN a.endpointkey=30 THEN 'Primary Account'
WHEN a.endpointkey=70 THEN 'Disabled Account'
WHEN a.endpointkey IN(200,210) THEN 'Service Account'
WHEN a.endpointkey IN(80,90,100,110,120) THEN 'Privileged Account'
END) as accounttypename
from Accounts a
inner join endpoints e on e.endpointkey=a.endpointkey
inner join securitysystems s on s.systemkey=e.SECURITYSYSTEMKEY
where a.endpointkey IN(30,70,130,80,90,100,110,120,200,210)]]>
<mapper description="This is the mapping field for SAviynt Field name" deleteaccountentitlement="true" ifusernotexists="noaction">
<mapfield saviyntproperty="accounts.name" sourceproperty="name" type="character"></mapfield>
<mapfield saviyntproperty="accounts.accounttype" sourceproperty="accounttypename" type="character"></mapfield>
<mapfield saviyntproperty="endpoints.endpointname" sourceproperty="endpoint" type="character"></mapfield>
<mapfield saviyntproperty="securitysystems.systemname" sourceproperty="securitysystem" type="character"></mapfield>
3. When you schedule jobs , first run the account import job and post that run your Sav to Sav DB import job.
Hope this helps!
Hi @dgandhi ,
was finally able to test it and it was working so can confirm, this is a valid solution.
Nevertheless I would still have a query as we already have an AccountsImport xml existing.
How can we integrate the existing xml with the new requirement.
SQL query and mapping should only be used for one case.
Case 1: Update Sav4Sav account based on sql-query and perform mapping based on mapping description
Case 2. Update Active Directory accounts on sql-query and perform mapping based on mapping description
Let me know, if you need additional input.