Password reset failing

No? You have to import them? Did I miss an important section in the documentation?

@SpiceDenver

Well, what you mentionned above implies that the AD was there before NethServer, so it can’t be part of the NethServer installation…

Something BIG is missing here… ( scratch, scratch… ) :slight_smile:

Maybe a word of explanation HOW that AD got together with NethServer, which makes it’s AD during install (post install with Account Provider, actually) would help us ignorants understand your situation a bit better.
And with understanding - help isn’t too far away!

Andy

My AD Enterprise had a couple DCs on Server 2016. These were up and running as healthy AD servers before installing Neth, which is joined to the domain through the Users & Groups as a remote AD. It was very straightforward. Users and groups — NethServer 7 Final

Now, the main (primary) AD is NethServer or still the Windows 2016?

@SpiceDenver

Understanding is dawning…

With AD users as you have from MS, they are missing AFAIK a few fields in LDAP/AD that MS doesn’t use normally, like the shell field (bash, csh, etc). NethServer uses these, and also set’s stuff…

That’s one of your “Gotchas”, there are more…

MS created users also tend to have a dot in the username ( firstname.lastname ), wheras in NethServer a dot in the username is - AFAIK - not legit.

My 2 cents
Andy

Do the usernames of the users not working contain special characters?

I have no problem using my user. It only contains special characters in name. Not in username as it is set as ertan

I am not sure if that was what you wanted to know though.

1 Like

I just mentioned your thread as an example.

They do contain a dot in the username. We use a full name with a dot.
Would the older password reset tool work to get around that?

It was just an idea. Could it be because of some char in the passwords?

To use the old server manager for changing password:

https://NETH_IP:980/en-US/UserProfile

Alternative:

https://wiki.nethserver.org/doku.php?id=userguide:self-service-password

I tried it now and dots in usernames are no issue with remote AD to Nethserver. I am going to test with Win Server 2016…

EDIT:

I can confirm the issue.
It seems not possible to login to cockpit/user-settings with remote AD users from Windows Server 2016. It shows “Wrong user name or password”.
It’s the same in old server manager. It shows “Invalid credentials”.
As regards apps, Nextcloud is working, Roundcube is not.

AFAIK self service password works with Windows Server 2016 DC.

image

Sorry I edited my post. The part after EDIT is important.
Here is the explanation of using old server manager for password change.
It was not possible for users to login to neither old or new server manager in my tests with Win Server 2016.

Are the apps logins (roundcube, nextcloud) working in your environment?

You may use SSP as a workaround until we fix this issue.

1 Like

cc @davidep @giacomo @edoardo_spadoni

a weird issue with remote AD and dot inside full name

Dot in username.

1 Like

just tested on a local nethserver samba AD, it works as expected, hopefully I have no microsoft AD, I cannot test here

@all could you test ?

Testing with a remote samba AD, the server bound to the remote samba AD can change the password through the user-setting page. I tested with a dot in the username : firtsName.lastName@nethserver-test.org

@stephdl

Salut Stéphane

The problem only exists against a MS-AD 2016 or higher, AFAIK…

I checked, but my clients with a MS 2016/2019 Server are all using NethServer-AD.
Those are only “Member” Servers…

Maybe @mrmarkuz has access to such a server to test.

Sorry…

Andy

1 Like

I already tested it with 2016 AD and confirmed the issue. I’m going to test with 2019 AD asap…
I test with the MS evaluation version, hopefully this is not the problem…

3 Likes

MS Server 2019 just worked tough it uses same 2016 AD, username with dot could login to user settings or roundcube without issues.
I’m going to recheck Server 2016 now…

1 Like

Are you testing with a user that’s not part of the Domain Admins group?