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

LDAP account import job queries

GauravJain
Regular Contributor
Regular Contributor

Hi

As part of LDAP onboarding we are trying to reconcile LDAP accounts (full import) where we require suggestion on following items:

  1. Account import job also pulls entitlements for each account which is a default behavior of this import job. Is it correct? or we can customize / configure to pull just accounts? 
  2. Entitlements pulled from account import job are dumped into "ENTITLEMENT_VALUE" field by default. is it correct or we can customize this as well?
  3. Does account import job also considers the configuration present in "groupImportMapping" while pulling entitlements for each account?

Regards

Gaurav

23 REPLIES 23

Manu269
All-Star
All-Star

@GauravJain  did you check this doc?

Understanding the Integration Between EIC and LDAP Interfaces (saviyntcloud.com)

Regards
Manish Kumar
If the response answered your query, please Accept As Solution and Kudos
.

GauravJain
Regular Contributor
Regular Contributor

Hi @Manu269 - thanks for your revert.

Yes, i have already checked it but the details i am asking are not present on this document.

Hi @GauravJain 

  1. Account import job also pulls entitlements for each account which is a default behavior of this import job. Is it correct? or we can customize / configure to pull just accounts? Importing accounts also imports accesses.
  2. Entitlements pulled from account import job are dumped into "ENTITLEMENT_VALUE" field by default. is it correct or we can customize this as well? Yes, this is default
  3. Does account import job also considers the configuration present in "groupImportMapping" while pulling entitlements for each account? Groupimport mapping is considered in access import only.

Also, please go through the below section in LDAP connector guide. 

About This Guide (saviyntcloud.com) --> Importing Accounts and Accesses

 

Regards,

Dhruv Sharma

GauravJain
Regular Contributor
Regular Contributor

Thanks @Dhruv_S for your revert. On #3 my observation is Import account job doesn't consider "groupImportMapping" because i have executed import account job with and without "groupImportMapping" and there is no difference in outcome.

in my understanding, "groupImportMapping" is only considered when we run full/incremental access import job which will pull entitlements metadata. this metadata is not pulled in account import job by default.

Also, incremental access import doesn't work for LDAP onboarding because its not supported (got confirmation from one of Saviynt employees). If that's the case, can you please help update the documentation? 

Introduction (saviyntcloud.com)

Regards

Gaurav

 

Hi @GauravJain 

GroupImport mapping should be considered during account import also. Could you please check the logs and observe what is the difference you are seeing?

Regards,

Dhruv Sharma

GauravJain
Regular Contributor
Regular Contributor

Hi @Dhruv_S No difference in terms of data processing. 

Just the order of events (log lines) and few additional checks are different when executed import accounts job with / without group mapping.

Hi @GauravJain 

As confirmed with the connector team, groupImportMapping is only considered during access import both for LDAP and AD connectors. I have corrected my previous response based on the same.

During AD import also, the account import brings only the value of entitlement and not the associated metadata.

Based on this, the behavior you can observe is expected behavior only.

Regards,
Dhruv Sharma
If the response is helpful, please click Accept as Solution and kudos it.

GauravJain
Regular Contributor
Regular Contributor

Thanks @Dhruv_S for confirmation. 

Can you please also confirm my query on incremental access import's support for LDAP onboarding? is it supported / not supported?

Yes incremental import is supported in LDAP

{
"full": "(&(objectCategory=person)(objectClass=user)(sAMAccountName=*)(!userAccountControl:1.2.840.113556.1.4.803:=2))",
"incremental": "(&(objectCategory=person)(objectClass=user)(sAMAccountName=*)(|(${createDateADattr}>=${lastCreateDateStr})(${updateDateADAttr}>=${lastUpdateDateStr})))"
}

 

Refer https://docs.saviyntcloud.com/bundle/LDAP-v23x/page/Content/Understanding-the-Integration-Between-EI...


Regards,
Rushikesh Vartak
If you find the response useful, kindly consider selecting Accept As Solution and clicking on the kudos button.

Hi @GauravJain 

Incremental access import is supported in LDAP.

Please refer to the documentation for more details.

Understanding the Integration Between EIC and LDAP Interfaces (saviyntcloud.com)

Regards,

Dhruv Sharma

GauravJain
Regular Contributor
Regular Contributor

Hi @Dhruv_S Yes, i am following the same documentation but incremental access import never worked. On top of it, one of the Saviynt employee also confirmed that it's not supported.

Can you please double check with product team before i tell you the configuration and error message i am getting?

Will wait for your revert.

Regards

Gaurav Jain

Hi @GauravJain 

I have confirmed, it is supported. Please let me know if you are getting any errors in the logs.

Regards,

Dhruv Sharma

GauravJain
Regular Contributor
Regular Contributor

Thanks @Dhruv_S for confirmation.

Please note, full access import and account-entitlement mapping is working fine with below given configuration.

Following is the configured for "groupImportMapping":

{
"importGroupHierarchy" : "false",
"entitlementTypeName": "ismemberof",
"groupAccountMappingAttributeName":"uniqueMember",
"performGroupAccountLinking": "true",
"incrementalTimeField": "modifyTimestamp_date",
"advanceGroupFilter":{"ismemberof":{"ou=x_applications,ou=applications,l=global,o=domain.com":["(&(objectClass=abcGroup))"]}},
"mapping": "memberHash:uniqueMember_char,entitlement_value:nameinnamespace_char,description:description_char,DISPLAYNAME:nameinnamespace_char,createdate:createTimestamp_date,updatedate:modifyTimestamp_date,entitlement_glossary:description_char,customproperty1:nameinnamespace_char,customproperty2:cn_char,customproperty3:uniqueMember_char,customproperty4:grouptype_char,customproperty5:objectClass_char,entitlementid:nameinnamespace_char,customproperty6:ismemberof_char,RECONCILATION_FIELD:customproperty1,lastscandate:modifyTimestamp_date,customproperty7:createTimestamp_char,customproperty8:modifyTimestamp_char,customproperty9:abcgroupowners_char",
"entitlementOwnerAttribute":"abcgroupowners",
"tableFieldAttribute":"NAME"

As a pre-requisite, i have created one new ldap group in ldap environment from backend before executing this job and added one member to it. Following is the date format in LDAP  for this newly created group "modifyTimestamp: 20240108103025Z"

Now, when i execute incremental access import, i see this objectclass in logs : "objectclass: (&(&(objectClass=abcGroup))(modifyTimestamp_date>=20231206073003.0Z))".

There is no error in logs but the incremental access import job doesn't pull the newly created group.

Please let me know if you require any further information on this.

 

Hi @GauravJain 

Could you please share the object filter as well.

Also please try with below and let me know if it is working.

{
"importGroupHierarchy" : "false",
"entitlementTypeName": "ismemberof",
"groupAccountMappingAttributeName":"uniqueMember",
"performGroupAccountLinking": "true",
"incrementalTimeField": "modifyTimestamp",
"advanceGroupFilter":{"ismemberof":{"ou=x_applications,ou=applications,l=global,o=domain.com":["(&(objectClass=abcGroup))"]}},
"mapping": "memberHash:uniqueMember_char,entitlement_value:nameinnamespace_char,description:description_char,DISPLAYNAME:nameinnamespace_char,createdate:createTimestamp_date,updatedate:modifyTimestamp_date,entitlement_glossary:description_char,customproperty1:nameinnamespace_char,customproperty2:cn_char,customproperty3:uniqueMember_char,customproperty4:grouptype_char,customproperty5:objectClass_char,entitlementid:nameinnamespace_char,customproperty6:ismemberof_char,RECONCILATION_FIELD:customproperty1,lastscandate:modifyTimestamp_date,customproperty7:createTimestamp_char,customproperty8:modifyTimestamp_char,customproperty9:abcgroupowners_char",
"entitlementOwnerAttribute":"abcgroupowners",
"tableFieldAttribute":"NAME"

 

Regards,

Dhruv Sharma

GauravJain
Regular Contributor
Regular Contributor

Hi @Dhruv_S i have tried this already and getting this error "Unparseable date: "20231115100044Z"".

SEARCHFILTER = domain.com

OBJECTFILTER = (&(objectClass=abcPerson)(objectClass=person)){with some additional user attribute filters}))

In USER_ATTRIBUTE, i have defined "CREATEDATE::createTimestamp#customDate--yyyyMMddHHmmss'Z',UPDATEDATE::modifyTimestamp#customDate--yyyyMMddHHmmss'Z'".

Also, in ACCOUNT_ATTRIUTE, i have configured "CREATED_ON::createTimestamp#customDate--yyyyMMddHHmmss'Z',UPDATEDATE::modifyTimestamp#customDate--yyyyMMddHHmmss'Z'".

 

Let me know if you require any further information.

Hi @GauravJain 

Object filter should have something like below. I can't see that incremental condition based on date filter in the one you have provided. Please check and confirm.


{
"full": "(&(objectCategory=person)(objectClass=user)(sAMAccountName=*)(!userAccountControl:1.2.840.113556.1.4.803:=2))",
"incremental": "(&(objectCategory=person)(objectClass=user)(sAMAccountName=*)(|(${createDateADattr}>=${lastCreateDateStr})(${updateDateADAttr}>=${lastUpdateDateStr})))"
}
}

Regards,

Dhruv Sharma

GauravJain
Regular Contributor
Regular Contributor

Hi @Dhruv_S Is it a mandatory configuration for incremental access import?

As i mentioned earlier, with whatever configuration i have shared so far, our full/incremental import of Users & Accounts and full import of access is just working fine?

with your suggested change, i am assuming it wont impact the above working functions?

Also, for variables lastCreateDateStrlastUpdateDateStr, do we have to hardcode some static value? would be good if you can share an example or link to proceed further.

 

Regards

Gaurav

Hi @GauravJain 

All these configurations are mentioned in documentation. Please refer the documentation for more details.

Understanding the Integration Between EIC and LDAP Interfaces (saviyntcloud.com)

Regards,

Dhruv Sharma

GauravJain
Regular Contributor
Regular Contributor

Hi @Dhruv_S i have gone through the documentation twice but don't see any relevant information on how to define these two parameters lastCreateDateStr & lastUpdateDateStr. Any idea whether i need to define static values or programmatically define a real-time value as well?

Static config like this :

OBJECTFILTER = (&(objectClass=abcPerson)(objectClass=person))(|(createTimestamp>=20240109000000Z)(modifyTimestamp>=20240109000000Z))))

 

Please try with the same filter I have mentioned above and see if it is working. Please collect the logs and share the error snippet if you get an error with the same. 

Also, if you are seeing anything missing or not clear in the documentation you can give feedback to the documentation and doc team will update it. 

For any feedback in the documentation, you can click the "Feedback" button on the documentation page, that feedback goes directly to the Documentation team

Feedback.jpg

Regards,

Dhruv Sharma

GauravJain
Regular Contributor
Regular Contributor

Hi @Dhruv_S i have tried your suggestion w.r.t OBJECTFILTER and executed incremental access import job. It didn't give any error in logs and completed successfully but it didn't pull the newly created group from LDAP.

Following is the objectclass printed in logs "(&(&(objectClass=abcGroup))(modifyTimestamp_date>=20240108103025.0Z))"

and the actual modifyTimestamp value in LDAP is "20240109111530Z". 

Is it happening because of different timezone format or do you see any other issue?  

Please let me know in case you require any further information from logs.

Regards

Gaurav

 

Hi @GauravJain 

The object filter is applicable to account filter hence it is not required for access import. So you can remove the object filter I mentioned above. It is not required.

To troubleshoot the issue further we need to do detailed analysis of logs, hence I have opened a FS Ticket #INC-2014521 on your behalf. Please run the incremental access job with the existing config you have and share the logs and complete JSONs on the ticket.

Regards,

Dhruv Sharma

GauravJain
Regular Contributor
Regular Contributor

Thanks @Dhruv_S , i will share required details on ticket.