User import from Active Directory not importng user information

[krecpond]

I am trying to get the sAMAccountName and UPN from AD to CP41 and CP42 respectively. I have the USER_ATTRIBUTE mapping as follows:

[
CUSTOMPROPERTY41::userPrincipalName#String,
CUSTOMPROPERTY42::sAMAccountName#String
]

The User import job is configured as follows:

Import from Saviynt Connect = No

Export Data to Saviynt Cloud = No

External Connection = Name of the AD connection

Job Type = Full Import

Allow User Operation = Update Only

User Not In Feed Action = No Action

Generate Systemusername = No

Generate email = No

Zero Day Provisioning = No

Expire password for new user = No

Check Rules = No

Build Users Cache Map = Yes

Reconciliation field = blank

When the job is triggered, the CP41 and CP42 are not getting populated. There is no error in the logs.

Any idea what other configuration is required to make the user import from AD retrieve data?

[rushikeshvartak]

Please share full mapping 

The Saviynt USERNAME is a mandatory parameter for user Import.

If there is no USERNAME in the USER_ATTRIBUTE, then import might complete successfully but will not update any record in Saviynt.

If you map USERNAME to a random attribute from AD, say "cn" , in the USER_ATTRIBUTE, then import will end up updating the Saviynt USERNAME to the "cn" value for the records which matched based on the Reconciliation parameter.

[krecpond]

What is "reconciliation parameter" that you are referring to?

[avinashchhetri]

The reconciliation parameter has to be something which is consistent in both the systems and preferably something that doesn't change.

For e.g if your organization creates users with a unique/immutable employeeID then you could map employeeID as the reconciliation parameter.

If the samAccountName change always happens from Saviynt to AD (and not vice versa), you could use that as the reconciliation parameter.

During Import, if the reconciliation parameter matches, it updates else it creates (dependent on "Allow User Operation" in the import config)

[krecpond]

We are evaluating the possibility of migrating user lifecycle processes from the existing IGA system to Saviynt on SaaS. Currently the birthright processing and writeback of email and network ID to HR source is completely managed by the legacy IGA solution. For now, Saviynt is simply getting the network (to systemUserName of user object) and email ID (to email of user object) from the HR source for new users coming into Saviynt (as they would have already been processed by the birthright process in the legacy tool).

I was trying to first get the writeback functionality done in Saviynt but as you mentioned this depends on an immutable recon attribute, there is no such attribute currently available. The legacy tool does not populate employee IDs to the newly created AD accounts. Additionally, we have around 70 domains and in each domain the employee ID attribute is used differently and not just to store the employee ID attribute. If I have to decouple just the writeback functionality from the legacy tool, the legacy tool will need to populate the employee ID on all newly created AD accounts. The subsequent user import from HR will then source the network and email ID to systemUserName and email respectively.

Is there any other way to decouple the writeback from the legacy IGA solution?

[avinashchhetri]

Im not quite clear on what you are trying to achieve.

As I understand, the Legacy IGA tool is reading data from HR Source, creating new users (network id/email) and creating accounts on AD amongst others and writing back the network id/email to the HR Source.

Now you are looking to import users from AD to Saviynt ? Does Saviynt already have these users and thats why you are running the  import in "Update Only" mode ?

[krecpond]

Like I mentioned before, I am thinking of a phased migration of the existing capabilities to SSM. I am thinking of getting the writeback functionality done once the legacy tool has provisioned new network and email ids.

Yes - we already have a live connection to AD and are doing regular imports. So these users are already in Saviynt. We don't want to use AD as another source of truth to "create" users in SSM but only get the birthrght information provisioned by the legacy tool into SSM and then write that back to HR source.

[avinashchhetri]

During a user Import, The mapping of the UserName attribute is Mandatory.

Since the NetworkID, perhaps a SamAccountName on the AD, is mapped to your systemUserName and not userName will be a concern. What value is stored on the Saviynt side under userName field ? 

[krecpond]

username contains the employee ID from HR source. But this employee ID is not populated always by the existing IGA tool on AD when new accounts are created.

Looking at all these scenarios, I might just have to migrate the birthright process over to Saviynt instead of just trying to do a writeback to HR source.

[avinashchhetri]

Yes,  it will not be possible to update select users in your scenario.

[BW]

You need to differentiate between importing users (Legacy/HR) and importing accounts (AD).

You need a reconciliation field otherwise every time you import, it will try to create duplicate users.  It recognizes that field is unique (e.g. employeeid) and won't create another user.