<div dir="ltr">I found the solution here <a href="https://docs.evolveum.com/connectors/resources/active-directory/active-directory-ldap/">https://docs.evolveum.com/connectors/resources/active-directory/active-directory-ldap/</a>:<br><br><div>"Objects can easily have attributes that are not defined in any object classes that they have. E.g., a normal user (the user object class) may have an info attribute. If such extra attributes are used in your AD instance, then the best way is to configure them as operational attributes in the connector configuration and define them explicitly in the Resource Schema Handling (see MID-3379)."</div><div><br></div><div>I'm not sure what exactly is meant by "define them explicitly in the Resource Schema Handling", but that step was not needed in my case.</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Jan 12, 2026 at 3:06 PM Orlandis Brown <<a href="mailto:brownolb1@gmail.com">brownolb1@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Our AD team populates eduPerson attributes for accounts, but apparently does not provision them with the eduPerson object class. In order to read from the eduPerson schema in midPoint, eduPerson needs to be an auxiliary object class of the account object type. During synchronization, midPoint attempts to modify the AD account with eduPerson object class. I would like to override this behavior somehow, since the LDAP account used to bind does not have permission to modify the object class.</div><div><br></div><div>How can I read eduPerson schema attributes without modifying the object class of the source account?</div></div>
</blockquote></div>