Univention Bugzilla – Bug 43216
Adapt univention-ad-connector(-exchange) to recent Exchange versions
Last modified: 2020-07-09 10:40:29 CEST
univention-ad-connector-exchange adds some extended attributes, LDAP schema and activates additional mapping via UCR to enable the sync of certain attributes that are relevant to MS Exchange. The mapping itself is provided by univention-ad-connector. This mapping does not work for recent Exchange versions (at least 2013 and 2016), more specifically the mapping of 'mail' and 'proxyAddresses'. The mapping is currently as follows: | OpenLDAP | Active Directory | |-----------------------------------------------------------| | univentionADmsExchHomeServerName | msExchHomeServerName | | univentionADhomeMDB | homeMDB | | univentionADmailNickname | mailNickname | | mailPrimaryAddress | mail | | mailAlternativeAddress | proxyAddresses | |-----------------------------------------------------------| 'mailNickname', 'mail' and 'proxyAddresses' are used for both users and groups while 'homeMDB' and 'msExchHomeServerName' are only used for users. Recent Exchange versions do not seem to use the 'mail' attribute for anything Exchange related. It is initially set when creating a mailbox for a user, but apart from that it's only a contact information just as the 'mail' attribute in UCS. Older Exchange versions seem to have kept 'mail' and the main address from 'proxyAddresses' in sync, so our mapping worked. But recent Exchange versions obviously stopped to sync those attributes so they might differ. Exchange uses the 'proxyAddresses' multi-value attribute to store the mail adresses that are related to the user's mailbox. There can be at least two types of values, one starting with uppercase 'SMTP:' and another starting with lowercase 'smtp:' Example: SMTP:mary.somerville@example.org smtp:mary@example.org smtp:ms@example.org Yes, Microsoft decided to differentiate between the two types by upper and lower case. The uppercase one is the primary address that is used as sender address. There MUST be only ONE mail address with leading uppercase 'SMTP:' The lowercase ones are the alias or alternative addresses and there can be multiple ones. Regarding all this, a more accurate mapping for univention-ad-connector would be: | OpenLDAP | Active Directory | |---------------------------------------------------------------------| | mailPrimaryAddress | proxyAddresses (uppercase SMTP:) | | mailAlternativeAddress | proxyAddresses (lowercase smtp:) | | mail | mail | |---------------------------------------------------------------------| We should adapt the mapping accordingly to make univention-ad-connector usable with recent exchange versions. See also: https://msdn.microsoft.com/en-us/library/ms679424(v=vs.85).aspx http://www.msxfaq.de/exchange/admin/proxyaddresses.htm (german)
Ok, I have built an adjusted version of the mapping. Advisory: univention-ad-connector.yaml Now we map (mailPrimaryAddress, mailAlternativeAddress) <-> proxyAddresses instead of (mailPrimaryAddress <-> mail, mailAlternativeAddress <-> proxyAddresses) Currently this leaves the "mail" attribute unsynchronized, we need to discuss what to do about that, see: https://blogs.technet.microsoft.com/exchange/2005/01/10/fun-with-changing-e-mail-addresses/ "mail" is single-valued in the AD-Schema.
Well, in an AD member mode environment the content of the AD attribute mail should be synchronized with the LDAP one too. Since on the LDAP side there can exist more than one value, at first the connector should check wether the value exists. If yes the process should be canceled - if no the attribute should be synchronized and added.
Additionally the sync mode should be configurable via UCR variable (see bug 42618) so the customer can decide wether to sync the mail attribute or not.
We have different semantics of OpenLDAP:mail and AD:mail, so I guess we have to treat them separately: 1. Sync OpenLDAP:mail <- proxyAdresses 2. Sync mailPrimaryAddress -> AD:mail (both single-value) I don't know if the second point is relevant with current Exchange versions, see http://serverfault.com/questions/724223/difference-between-proxyadresses-and-mail-attributes-in-active-directory > at first the connector should check wether the value exists. If yes the process should be canceled I guess we would sync anyway, shouldn't we? Stopping in case of a value exists would add a totally new behavior to the connector. That would be "write once". > Additionally the sync mode should be configurable via UCR variable (see bug 42618) so the customer can decide wether to sync the mail attribute or not. Yes, we would add a variable analogous to connector/ad/mapping/user/alternativemail, so it can be turned off or on.
Well maybe I wrote it misunderstandable... If the contents of the AD mail attribute exists at the OpenLDAP side the address can be overwritten but should NOT be deleted in OpenLDAP. Also other existing values of the OpenLDAP mail attribute should not be deleted during the sync process.
Ok, as discussed, we will postpone the merge from AD:proxyAddress to OpenLDAP:mail, that's split off as Bug 43447. To stay compliant with the AD/Exchange spec I've now additionally implemented: > 2. Sync mailPrimaryAddress -> AD:mail (both single-value) Test case 55_adconnector/130sync_user_mail_attributes has been adjusted to the new behavior. Advisory: univention-ad-connector.yaml
Well, just to be safe: in AD member mode for an Exchange activated user the following attributes are synced: AD: ProxyAddresses with SMTP:<abc@example.com> -> OpenLDAP: mailPrimaryAddress AD: ProxyAddresses with smtp:<def@example.com> -> OpenLDAP: mailAlternativeAddress AD: mail -> OpenLDAP: mailPrimaryAddress or OpenLDAP: mail (see Bug 43447) The last sync can be disabled via UCR. Is this right?
> AD: mail -> OpenLDAP: mailPrimaryAddress It's the other way round: OpenLDAP:mailPrimaryAddress -> AD:mail But in AD member mode that's not active (connector/ad/mapping/syncmode=read). OpenLDAP:mail is not touched, I explicitly covered that in our test case.
Jenkins tests: OK Changelog: OK UCS 4.2 merge: OK Code review: OK Tests: OK, it works as expected.
<http://errata.software-univention.de/ucs/4.1/386.html>