Question
If a Microsoft Active Directory (AD) account that is currently not synchronized with OpenDesk/USC is synchronized, which mailbox will be assigned to that account?
A customer has a Microsoft Active Directory account that is currently not synchronized with OpenDesk/USC. During the migration process, the shared mailbox “Librarian” (Librarian@univention.int) has already been migrated and exists as a functional account.
The customer would like to know what happens if the AD account is synchronized afterwards:
- Will the synchronized user be associated with the existing “Librarian” mailbox?
- Or will a new mailbox (for example,
Librarian1@univention.int) be created?
Answer
During the initial synchronization, the AD Connector creates the user object in the Nubus for Kubernetes LDAP directory by performing a UDM create operation.
During this process, all attributes supported by the AD Connector are read from Microsoft Active Directory and synchronized. These attributes are passed to the UDM create operation so that the newly created LDAP object contains the corresponding values from Microsoft AD.
The mailPrimaryAddress attribute is unique and is typically generated from the user’s first name, last name, and the configured mail domain. If the user object in Microsoft Active Directory already has a mailPrimaryAddress assigned and the corresponding mail domain exists in Nubus for Kubernetes (LDAP), this attribute is synchronized and assigned to the newly created LDAP user object.
To the best of our knowledge, shared mailboxes (functional accounts) are not synchronized or automatically assigned by the standard AD Connector synchronization process.
Instead, access to a shared mailbox is typically configured after the user object has been created. This can be achieved using one of the following methods:
- A UDM CLI modify command
- A custom UDM hook
- Another post-processing mechanism
In Open-Xchange, access to an existing shared mailbox (functional account) is granted by adding the user as a uniqueMember of the functional account.
Example
The following example demonstrates a functional account named Librarian. The LDAP object contains two uniqueMember entries, indicating that the users Administrator and mirac.erde have access to the shared mailbox.
kubectl exec -n $NAMESPACE ums-ldap-server-primary-0 -- ldapsearch -x \
-D "$(kubectl get -n $NAMESPACE configmaps ums-ldap-server-primary -o json | jq -r '.data.ADMIN_DN')" \
-w "$(kubectl get -n $NAMESPACE secrets ums-ldap-server-admin -o json | jq -r '.data.password' | base64 -d)" \
-b "$(kubectl get -n $NAMESPACE configmaps ums-ldap-server-primary -o json | jq -r '.data.LDAP_BASEDN')" \
"cn=Librarian" -LLL '*' '+'
Output
dn: cn=Librarian,cn=functional_accounts,cn=open-xchange,dc=swp-ldap,dc=internal
cn: Librarian
mailPrimaryAddress: librarian@erdemiroglu-opendesk.univention.dev
oxQuota: 10
oxPersonal: Support
univentionObjectIdentifier: ce58d1ff-0fa0-4b24-84aa-2862aead5ce2
uniqueMember: uid=Administrator,cn=users,dc=swp-ldap,dc=internal
uniqueMember: uid=mirac.erde,cn=users,dc=swp-ldap,dc=internal
objectClass: univentionObject
objectClass: top
objectClass: oxFunctionalAccount
univentionObjectType: oxmail/functional_account
structuralObjectClass: oxFunctionalAccount
entryUUID: b867679c-f46f-1040-9e08-191b5ad89d26
creatorsName: uid=administrator,cn=users,dc=swp-ldap,dc=internal
createTimestamp: 20260604144505Z
entryCSN: 20260604144505.681358Z#000000#001#000000
modifiersName: uid=administrator,cn=users,dc=swp-ldap,dc=internal
modifyTimestamp: 20260604144505Z
entryDN: cn=Librarian,cn=functional_accounts,cn=open-xchange,dc=swp-ldap,dc=internal
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE
The corresponding LDAP user object contains its own unique mailPrimaryAddress and is independent of the functional account.
kubectl exec -n $NAMESPACE ums-ldap-server-primary-0 -- ldapsearch -x \
-D "$(kubectl get -n $NAMESPACE configmaps ums-ldap-server-primary -o json | jq -r '.data.ADMIN_DN')" \
-w "$(kubectl get -n $NAMESPACE secrets ums-ldap-server-admin -o json | jq -r '.data.password' | base64 -d)" \
-b "$(kubectl get -n $NAMESPACE configmaps ums-ldap-server-primary -o json | jq -r '.data.LDAP_BASEDN')" \
"uid=mirac.erde" -LLL dn givenName sn mailPrimaryAddress
Output
dn: uid=mirac.erde,cn=users,dc=swp-ldap,dc=internal
givenName: Mirac
sn: Erde
mailPrimaryAddress: mirac.erde@erdemiroglu-opendesk.univention.dev
Conclusion
Synchronizing a previously unsynchronized Microsoft Active Directory account creates a new LDAP user object with its own mailPrimaryAddress based on the synchronized AD attributes. The AD Connector does not automatically associate the user with an existing shared mailbox (functional account), nor does it automatically grant access to one.
Access to an existing shared mailbox must be configured separately by adding the user to the functional account (for example, by creating a uniqueMember entry using UDM CLI, a custom hook, or another post-processing mechanism).