Bug 49954 - AD connector: Make userPrincipalname mapping from UCS to AD mappable
AD connector: Make userPrincipalname mapping from UCS to AD mappable
Status: NEW
Product: UCS
Classification: Unclassified
Component: AD Connector
UCS 4.4
Other Windows 7
: P5 enhancement (vote)
: ---
Assigned To: Samba maintainers
Samba maintainers
https://github.com/univention/univent...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-08-02 08:57 CEST by Mathieu Simon
Modified: 2020-07-07 17:26 CEST (History)
4 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 2: Improvement: Would be a product improvement
Who will be affected by this bug?: 1: Will affect a very few installed domains
How will those affected feel about the bug?: 2: A Pain – users won’t like this once they notice it
User Pain: 0.023
Enterprise Customer affected?: Yes
School Customer affected?: Yes
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional): External feedback
Max CVSS v3 score:
best: Patch_Available+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mathieu Simon 2019-08-02 08:57:06 CEST
Hi

Currently, if a user is created from UCS to AD that does not exist (or has no UPN) yet in AD, the default is construct a valid userPrincipalname for AD based on uid@[ucr variable connector/ad/mapping/kerberosdomain].

This has the disadvantage of having only one possible UPN suffix on the AD side. While AD not only perfectly supports multiple UPN suffixes, in some situations it can actually be very useful to map an existing attribute (like mailPrimaryAddress) from UCS to AD. I wouldn't enable this by default as it should be up to the person configuring the AD connector to check if the source attribute is both single-valued and compliant with RFC 822. (Source: https://docs.microsoft.com/en-us/windows/win32/adschema/a-userprincipalname)

I'll be sending in a merge request as proposal, consider it WiP, but has already seen some testing with the connector set to write mode. One thing I couldn't test is how this would potentially behave if the UPN is changed in sync mode on AD side. I don't think that that the UPN is ever looked up in AD and then written to UCS.

Regards
Mathieu
Comment 1 Mathieu Simon 2019-08-02 10:38:29 CEST
Since I initially messed up the URL on Github to the wrong Bugzilla issue, for cross-reference the correct Github MR URL: https://github.com/univention/univention-corporate-server/pull/13

I've removed the relation to bug 47259 as they are not actually related.
Comment 2 Mathieu Simon 2019-08-03 13:41:08 CEST
Hi

Arvid Requate over on Github looked interested and suggested that "briefly" (not so briefly unfortunately) explaining the use case like a in a "user story" might be helpful:

Short story ahead: Unfortunately there is software around that only reliably works with Windows AD, where Samba AD isn't compatible enough yet. One being Azure AD connect (i.e. https://lists.samba.org/archive/samba/2017-June/208890.html, but that is not the only issue). There are valid reasons where AAD connect is preferred over the UCS O365 app (see mail to feedback@ from 03.07.2019).

AAD connect heavily relies on the use of userPrincipalName (UPN). Not only for AAD connect MS and others recommend having mail to be the same as the UPN. The main reason being that most user cannot tell apart a UPN from a mail as they use the same format. Beyond visuals during logins, AAD connect runs/imposes additional technical limitations where UPN cannot be used as identity in Azure AD and UPN is != mail (Details out of scope for this bug, I can share them if you are interested)).

Current behaviour: When the UCS AD connector creates a user n AD, the UPN is derived from uid@[connector/ad/mapping/kerberosdomain]. This happens, if connector/ad/mapping/sync/userPrincipalName is true (which is the default). Mapping the mail address is already possible through connector/ad/mapping/user/primarymail based on mailPrimaryAddress (default: false).

In UCS domains, where mail addresses of users are on different (sub-)domains, the current options lead to situations, where mail = UPN is not achievable. If we allow defining a source attribute to be defined via ucr, it becomes possible to get mail and UPN to be identical for that use case i.a. using mailPrimaryAddress in that case. (It would also allow you to achieve custom UPNs if there is a specific need for it.)

While tinkering with the AD connector's code, I came up with a initial, still small patch  that could achieve that. So I thought I could bring up that merge request. The intention is to not modify the current default behavior, but to provide an additional way to map the UPN based on an existing attribute in UCS. I wouldn't want to make it a a predefine/fix attribute though.

Regards
Mathieu
Comment 3 Mathieu Simon 2020-01-09 17:12:27 CET
Hi

The interest to discuss this pull request is still present and I'd really like to see how you folks think about this extension. It would definitely ease things for us and remove some hacks that are currently required here internally to work around this missing configuration knob.

I've checked that the patch still applies on top of the current 4.4-3 branch and tried to re-base it onto the current branch.

How can this best be discussed? I haven't heard objections from your side except that we both want to avoid breaking changes and to not bother existing setups (as in the pull request by Arvid over on Github.

Regards
Mathieu Simon
Comment 4 Mathieu Simon 2020-02-04 15:15:30 CET
Hi

Another month has passed without an update from Univention's side, I've also mentioned our merge request to Ingo Steuwer during the Univention summit.

If there are tests required, questions on your end that are holding up our merge request - or even product design decisions speaking against integration of our patch - please let us know.

Our interest is definitely present and lack of that configuration knob is actually causing us increasing headachess. All in all the AD connector does lack other mapping capabilities, but the UPN is definitely a central config knob that is currently missing to us.

Regards
Mathieu Simon, IT Services Gymnasium Neufeld
Comment 5 Ingo Steuwer univentionstaff 2020-02-05 10:20:33 CET
As discussed during the Univention Summit I fully understand the idea and the need in your environment.

While I appreciate the pull request, there are more things to do to have this in the product. The most important task is to have an automated test that ensures that this feature will work in future releases. The current tests for the AD Connector can be found here:
https://github.com/univention/univention-corporate-server/tree/4.4-3/test/ucs-test/tests/55_adconnector

These tests are very UCS specific, so it's not that easy to contribute here (we have to work on documentation etc. on Univention side....). Usually we at Univention write these tests for pull requests, but to do so we need some time in the development team which is the current bottleneck here.
Comment 6 Mathieu Simon 2020-02-06 13:06:42 CET
Hi Ingo

I appreciate your time for the feedback and pointing out the location for these tests, I fully understand the need for test coverage.

While my own time is also limited, I'll see if I can bootstrap a minimal environment and try to see if ucs-test can be run by someone who is not as familiar with the UCS codebase than you people at Univention.

Regards
Mathieu