The email address of the AD user (NETH8) in Nextcloud does not match the email address stored in NETH8

Dear community,

Here is a question for the Nethserver 8, ActiveDirectory and Nextcloud specialists (in this combination) including you @Andy_Wismer:

Until now, the AD connected to Nextcloud always displayed the actual email address of the user in Nethserver (7) as the email address in Nextcloud.

So, for example, “username@domain.tld”

If an “old” AD is moved to the new Nethserver 8, this remains the same.

However, if a new AD is created in Nethserver 8 (bare installation), it is displayed in a connected Nextcloud as follows: “username@ad.domain.tld”.

I noticed this during test installations many months ago, and I had hoped that this behavior would be corrected.

In SOGo, the account is displayed correctly under Settings/Email/IMAP accounts.

Based on the fact that the behavior is different for new and migrated ADs, this is probably due to the way the AD is set up. But why is it like this now and not like before? Is this a mistake or is it the new way? And can it be changed later? And what would be the intended way to do this so that it doesn’t change again with an update etc.?

In the LDAP/AD integration (Nextcloud plugin) under special settings, I have “userPrincipalname” under “Email field” for the migrated AD. I also entered this in Nextcloud on a new AD, but it doesn’t change anything. What do you suggest to generally correct this for new users?

The behavior affects externally connected Nextclouds, in my test installations it also affected the internal Netcloud (I haven’t tested it since then).

Greetings
Yummiweb

Addendum:
I’m not sure if this is a reliable solution, especially since it was from a fairly early stage of NETH8:

Hi @yummiweb

This is a correct, working solution.
AD was there long before NS7 or NS8, and is still there. Samba and whatever still have to respect Windows definitions for AD, and this is one of them.

The difference in handling between NS7 and NS8 is probably due to the fact that the NS7 AD was a container / jail, but still “integrated” with AD (and probably mail too!). A Migration takes these settings over to NS8.

However, a new NS8 AD will not have these yet, so “rolling back the sleeves” as in “manual work” is the motto of the day.

RSAT and a XL sheet or whatever list to tick off done is your friend!

My 2 cents
Andy

Dear Andy,

Thank you for your answer.

It’s good that existing or changed settings are retained, that’s how it should be.

I just don’t understand why this should now require rework for every new user. If it was correct before (for whatever reason), it should work now too.

There may be tools to correct this manually or automatically, but why a special solution (or even an RSAT if you don’t have a Windows environment) when it could be a default setting in the AD? Can it be adjusted when creating the AD?

I understand that you no longer want to specify @domain.tld for the AD user name, because the AD should be independent of the mail domain actually used. But then the “@ad.domain.tld” shouldn’t be there in this field by itself, but rather nothing at all, right?

Would there be any typical Windows peculiarities that speak against the “correct” email address being there by default?

It seems clear to me that in environments where AD is more than just a user administration for mail services etc. you have to make more specific settings (script or folder paths, for example), but that may not be as important for pure Nextcloud or other app users. In this respect, I would say that the standard settings should be kept as practical as possible for small user environments, as for large environments you will be making changes in many different places anyway.

@yummiweb

Maybe you need to say thank you to certain uyers, like the now kicked LazyLow…
His famous statements: I’ll never need AD, I’m on a VPS…
And a lot of similiar crap from him probably pushed the devs to the loudest users…
And the most important feature for SMB clients, AD, was relegated to a third class seat in the luggage wagon… :slight_smile:

As you can still see, there’s still no WSDD on any NS8 Samba. It seems all other Linux Samba implementatios include that now, only NS8 still is waiting.

It doesn’t matter to me, if the next “NS8 milestone” doesn’t finally fix Samba (AND finally add WSDD!!!), I will be forced to stop using NS8 Samba, and without Samba, any use of NS8 doesn’t make sense in a different environment.

My 2 cents
Andy

One of the reasons I plan on spinning up a AD based on an independant Debian VM.
Two such containers, with Sysvol and Netlogon sync integration, and I do not need NS8 any more for any Samba services. OMV could take over that task.

3 Likes