Procedure "Change the FQDN" from manual doesn't work

NethServer Version: NS 7.4 B1
Module: NS-DC

I tried to change the FQDN with the procedure in the manual (local AD):
But this doesn’t work. Tried it on an upgraded machine and on an fresh installed one.
To leave the realm and clear it, works. After that it’s possible to chance the FQDN, but you can’t join the realm again, because there is no more realm to join.
With realm join -U administrator $(hostname -d) you get realm: No such realm found
I think there is something missing in this procedure.

So I tried to manually set the db values for realm, workgroup and provider and did
expand-template /etc/samba/smb.conf
systemctl restart smb
systemctl restart realmd
and was joind to the new realm.
So far so good, but I still have no connection to the ldap server and got stuck.
signal-event nethserver-sssd-save and a reboot do not help also.
Can someone give me a hint which is the right order of commands to do this? :blush:

TIA Ralf

o.k. I spent some time with that and now I found a procedure that worked for me

  1. signal-event nethserver-sssd-remove-provider (this causes backups of users and groups)
  2. change FQDN in GUI
  3. reinstall AD from GUI
  4. rpm -qd nethserver-sssd
  5. in /usr/share/doc/netsherver-sssd-1.3.0/scripts you find the scripts to import users and groups. Copy the files in that folder to /var/lib/nethserver/backup (only for easyness)
  6. in /var/lib/nethserver/backup you find the backups users.tsv and groups.tsv
  7. perl import_users users.tsv and perl import_groups groups.tsv

Now I have a new FQDN and all my users and groups are back.

@dev_team Can someone confirm this procedure to work in other cases?
So could be updated.


There’s something wrong under “Leave and Re-Join Active Directory” section. I should fix it, thank you @flatspin

That procedure should allow changing the host name (SystemName) only. The domain must be the same.

BTW your procedure should work because AD is completely removed and reinstalled with a new domain. It’s a different use case.


Worked here, but that wasn’t easy. Take care :

  • File server module was removed somewhere in the procedure, probably at step 1. Dunno why.
  • It has to be reinstalled BEFORE reinstalling the AD. I had to retry some times to get AD and File server installed correctly.
  • Password policy was reset to “Strong password required” at some point
  • Just in case somebody wonders : Groups have to be restored AFTER users.
  • Permissions were lost on shared files, I had to “Reset Permissions”
  • All password were wrong after import, maybe because at some point (after having exported the user.tsv file) I did a yum update for some bad reason.

All in all, it might be easier to reinstall completely to change the FQDN because this change is really huge and currently error prone.

1 Like

Just tried again on another server which had the AD Domain incorrectly set.

  • UI > Accounts Providers > Uninstall
  • UI > Accounts Providers > Reinstalled AD
  • perl /usr/share/doc/nethserver-sssd-1.3.3/scripts/import_users users.tsv
  • perl /usr/share/doc/nethserver-sssd-1.3.3/scripts/import_groups groups.tsv

Result :

  • Passwords lost
  • Administrator and Admin accounts not restored (may be a feature)
  • Samba and shares not lost in the procedure (great)
  • Need to “reset permission” on each Samba share.
  • Nextcloud authentication screwed up (all UUIDs changed, ghost users seen using the occ ldap:show-remnants command

For what it’s worth:

I just did the following on fully updated servers:

  1. starting situation: > ad server > neth member server with SOGo installed > neth member server for filesharing and ftp > neth member server with website > neth member server with wip alfresco installation

For all these servers their FQDN at server installation was set to
For unknown reasons I could not at the time create the ad domain and thus went with the domain The FQDN of these servers was server#.MYDOMAIN.COM
The fileserver was an exception, I had been playing with that. It’s FQDN was already effortlessly changed after unbinding, to and then succesfully rejoined to after some persuasion.

  1. unbind 5 member servers from the AD domain: AD.MYDOMAIN.COM
  2. set FQDN for server3 back to
  3. make sure that FQDN on domain server is
  4. reset samba to factory defaults
  5. create the domain on server1
  6. set admin passwords
  7. rejoin servers to domain

During this I changed the FQDN on 1 server, 3 times in a row with rebinding and unbinding in between, and even completely recreated the domain. This went all with just one error which did not repeat when the same action was tried again (bind the fileserver to the domain).

I did not try to restore the users or the groups, as I had none that mattered. I recreated the same users, and all the configuration on the other servers started working again.
This included SOGo mailboxes still working, still containing the test mail, etc.
This also includes the home-shares.

During testing of having the same FQDN as the domain you are trying to create, I first changed the FQDN from server1 to and recreated that domain succesfully, and then reverted back to to create domain

So the FQDN of the Nethserver running the samba container, was changed as well.

There is very little custom config in there, so the process outlined two posts back seems to have improved.

Not tested where custom ACL’s set through the UI or custom righst set through RSAT.

password of users are the same, data are still there ?

I say that because it is a pain that you cannot change the fqdn of the server once the openldap or sambaAD is configured

To be able to give you an answer, I repeated the procedure.

Mixed result on the first look:

Some users seem to have a password, some are shown as locked. Befroe all user had a pasword and non were locked!

But,…no user can login with the old password. :disappointed: So all passwords has to be changed manually.
In my case not that big problem with 15 users. In a bigger company it would be a big problem.

Note: In this test I changed also the domain. I’ll test with only changing the FQDN and will report later.

Did the procedure again with only changing FQDN.
Same result as before, but this time some other users are locked.
Tried to login with old password and standardpassword, but non worked.

So all-in-all in a realistic scenario it’s not really possible to change the FQDN, because all passwords are gone or messed in some way.

1 Like

Ok thank flatspin