Skip to Content
avatar image
Former Member

Updating single AD attribute using to LDAP Pass

Hi guys, I have a question that I'd be interested to hear your thoughts on.

Many thanks in advance.


Problem statement:

When IdM sends data to a directory (e.g. Active Directory) all attributes defined in the pass are sent to the directory regardless of whether they have changed. This results in an issue with one of our reported tools as the attribute is modified even though the value hasn't changed.


The last name of a person changes and the updated identity attribute is updated in IdM. This results in a modifyADuser being called. All attributes defined in the pass are sent to Active Directory even though only the MX_LASTNAME attribute has changed.


I believe this is the standard behaviour of SAP IdM as coded in the corresponding jar file so don't believe it's possible to change through configuration but would be interested to hear of any ideas of how this might be achieved, or if anyone else has looked into this before.

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

2 Answers

  • Feb 27, 2018 at 07:33 AM

    Hello Patrick,

    hmm, we also have an AD attached to our IDM, but if even if the connector pass pushes all fields to AD, since most of them aren't changed, why would it register as a "modify" in AD?
    We have a monitoring application that watched the IDM AD-account for AD things (meaning it watches for changes in the active directory by a specific ad-account and sents emails to notify about them) and I only get "field was modified" for fields, that actually changed. I thought this was the normal behavior?

    Matt Pollicove: You have more experience with different installations. Does the LDAP connector really modify every field in the connector, no matter if the value is different? oO




    Add comment
    10|10000 characters needed characters exceeded

    • This is a very interesting question. I think the key here is the monitoring tool being used. I guess the only way to really check would be to disable all but the relevant attributes while making sure that there is a key / lookup attribute (dn or objectGUID)

      The basic answer is yes, IDM would be writing all of the attributes though. You could restrict it somewhat by using the . prefix which says to write the attribute only if this is a new entry.

      When an Active Directory attribute is updated the uSNChanged attribute for the entry is updated which is how we can track changes (at the end of the job / task update uSNChanged to a variable and then make it part of the filter for the next run as shown in the PF)

      I'm not aware of any tool that is watching changes / updates to each AD attribute, so a definitive answer would depend on someone who really knows the innermost workings of AD or the monitoring tool in question.

      The only ways I could really see preventing this would be to assign an update task to each attribute that would update only that attribute in AD. Possibly using the Delta functionality would work as well. However, I'm not sure that I would ever go to this extreme or advise it to anyone. But of course, if those ARE the requirements...

      In any event, I would be interested in hearing what happens with this.


  • avatar image
    Former Member
    Mar 19, 2018 at 02:05 AM

    Thanks Steffi. This particular AD monitoring tool used to work in the same way (only recording actual changes in attribute values). Since an upgrade it is behaving differently and picking up on every actual LDAP operation. When performing the LDAP operation defined in the ModifyADSUser pass it sends the whole AD user object with all attributes [as defined in the destination tab of the pass], regardless of whether the attribute has changed. I can see this when turning the dispatcher up to debug (refer

    I believe that this (the standard IdM behaviour) is a common way to make the LDAP call (send all attributes rather than just the change) but we just wanted to explore all options of how we might address this issue.

    Thanks for your time!

    Add comment
    10|10000 characters needed characters exceeded