Based on the "normal" ALM workflow "methods" (like bug_move_to, Bug_new), they are all "event-driven".
These two "methods" for example will execute when you create a new defect or "move to" an existing one in the grid.
-- BUT a user needs to do something interactively for them to "fire". In your case, this would need to be executed on an interval.
The USER information is stored and accessed from the Site Administrator API (can be accessed via COM in 11-12.60 and 15.00 and additionally REST with 15.01). It is possible to call on this API from the workflow scripts, but what you need is to run a script from OUTSIDE QC/ALM, perhaps scheduled as a "chron-job" to execute on an interval like once a week. Your logic could use some AD/LDAP check for updates then re-populate the "DN" field for various users with the updated DN/distinguished name AD identifier corresponding to their DN/LDAP userID.
Check these methods:
SetUserProperty - it allows you to update the SA_USER_DOM_AUTH property for an existing user based on knowing the USERNAME
The script would likely need to be executable VB (compiled) or VB-script or other scripting language.
Examples in the API guide are mostly VB/VBA, and some C++ (btw, there is a NEW REST API for the Site Admin API as well as the "old" OTA API in QC/ALM version 15.01). Look at the most used OTA (open test architecture) section which covers the more common activites like working with defects. This link is for API refrences for 12.55 (version can be selected at upper left).
Also, since the DN is stored for each USER in the USERS table of qcsiteadmin, you *could* also possible accomplish the same by updating a particular user's DN string directly in the database with SQL.
OF COURSE, these solutions should be tested in a TEST instance of ALM/QC first!
BULK Direct edits of records in the database are not generally recommended/supported, but if you are careful (backup qcsiteadmin database/schema prior to edits in case something goes wrong), it may work for you.