If I set a proxyAddress in AD “[email protected]”, upon LDAP login, it creates an alias for that user “[email protected]” in Stalwart. If I then remove that proxyAddress in AD, restart Stalwart, and login with LDAP, the alias does not get deleted in Stalwart.
Expected Behavior
When removing the proxyAddress in AD, upon login, it should also be removed as an alias in Stalwart.
Actual Behavior
Upon LDAP login, the alias that was deleted in AD is still tied to the user account in Stalwart.
Stalwart Version
v0.16.x
Installation Method
Docker
Database Backend
RocksDB
Blob Storage
RocksDB
Search Engine
Internal
Directory Backend
LDAP
I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.
on
I have searched this support forum (open and closed topics) and confirm this is not a duplicate.
on
I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.
This is a helpful test file showing synchronize_account is the mechanism. Let’s find the implementation.
I have enough from the source code to answer confidently.
The synchronization code in synchronize_account only adds aliases from the directory that aren’t already present, it never removes ones that are no longer returned by the directory (the loop only pushes new EmailAlias entries onto updated_account.aliases, there’s no step that drops aliases missing from the LDAP result). So this is expected behavior with the current LDAP/directory sync logic: JIT sync is additive-only for aliases, not authoritative/destructive.
Why this happens: each LDAP login triggers synchronize_account, which reads proxyAddress values and merges any new ones into the account’s aliases list in the registry. There is no corresponding step that compares the full alias set and removes entries no longer present in AD, so once an alias is created it persists until it is manually removed (e.g. via the WebUI or stalwart-cli update account/user <name> --field 'aliases/...').
Workaround: remove the stale alias manually, for example:
or edit the specific index/entry in the WebUI account editor, then re-add only the current ones if needed. There’s no built-in reconciliation that deletes aliases dropped from AD.
For reference on the JIT provisioning/alias merge behavior, see the LDAP backend docs: LDAP Server | Stalwart
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.
Login-time sync adds the aliases it finds in the directory and never removes one. That’s intentional: Stalwart can’t tell an alias that came from AD apart from one an admin added locally (Provisioning models | Stalwart). Remove the stale alias from the account in the web UI or with the CLI; until then it keeps delivering to that user.
If AD should own the aliases, removals included, SCIM provisioning does that. It’s an Enterprise feature and is enabled per domain.