Not sure if I'd call this one a bug, but I'm leaning that way. The LDAP I'm talking to has an attribute that needs the inverse of Login Disabled (called accountEnabled). So true is false, false is true, and all is topsy turvey. But, ok, fine, a quick policy to invert the value, and away we go. Or not. This accountEnabled can only be set after the object exists. So on an <add>, I need a following <modify> to set it. Again, easy, just change to when="after", and ... it fails.

The LDAP shim insists that a <modify> must have an <association>. Because this is generated from a do-set-dest-attr-value in a policy processing an <add>, with when="after", there is no association. I don't recall any other shim requiring an association to process a <modify> this way. It has a perfectly good dest-dn in the <modify>, so it should be able to do its job without. But, it won't.

According to the LDAP shim, this is not a valid document:

Code:
    <modify class-name="User" dest-dn="uid=Foo,dc=users,dc=bigcorp,dc=com"  event-id="pwd-publish:ac89399f-2533-49ea-988a-9f3989ac3325" qualified-src-dn="O=bigcorp\OU=users\CN=foo" src-dn="\TREE\bigcorp\users\foo" src-entry-id="43847">
      <modify-attr attr-name="Login Disabled">
        <remove-all-values/>
        <add-value>
          <value type="string">ENABLED</value>
        </add-value>
      </modify-attr>
    </modify>
but this is:

Code:
    <modify class-name="User" dest-dn="uid=Foo,dc=users,dc=bigcorp,dc=com"  event-id="pwd-publish:ac89399f-2533-49ea-988a-9f3989ac3325" qualified-src-dn="O=bigcorp\OU=users\CN=foo" src-dn="\TREE\bigcorp\users\foo" src-entry-id="43847">
      <modify-attr attr-name="Login Disabled">
        <remove-all-values/>
        <add-value>
          <value type="string">ENABLED</value>
        </add-value>
      </modify-attr>
      <association>uid=Foo,dc=users,dc=bigcorp,dc=com</association>
    </modify>
So another quick policy to clone @dest-dn to <association> and it works, but I don't think I should have to do that.