Hello everyone, in the upcoming upgrade of the OX-Connector for K8s, we are moving to the new provisioning API verison, so we the connector no longer has access to the entryUUID of the objects, instead we will rely on the univentionObjectIdentifier.
This change will reduce the difference between the Appcenter version of the ox-connector and the k8s implementation. As the Appcenter version already uses the univentionObjectIdentifier since v.3.0.0, which was released last year (30/09/2025).
What will change in the connector?
The connector will continue to work as it was before, the only significant change is on how the functional accounts generate their login string. Before this upgrade the login string was formed by the concatenation of the entryUUID of the functional account and the username of the user. E.g: {fa_entry_uuid}{username}.
After the upgrade, the new login strings generated by the connector will be formed by the contatenation of the functional account uoi and the username. e.g. E.g: {fa_univentionObjectIdentifier}{username}.
How can that affect me as an operator?
If you have deployed your ox-connector in k8s, everything will continue to work but your users won’t be able to access new created functional accounts. To fix this issue, you will have to adapt the configuration of your dovecot service.
This is an example of what you should change to keep being able to login into the functional accounts.
@@ -145,7 +145,7 @@
=userdb_home=/srv/mail/%0.2L{ldap:entryUUID}/%L{ldap:entryUUID}/ pass_filter = (& \
(univentionObjectType=oxmail/functional_account) \\
- (|(mailPrimaryAddress=%Ld)(entryUUID=%0.36Lu)) \\
+ (|(mailPrimaryAddress=%Ld)(univentionObjectIdentifier=%0.36Lu)(entryUUID=%0.36Lu)) \\
(uniqueMember=%{passdb:userDN}) \\
) ldap-primary.conf.ext: |2