Procedure to join AD domain with NS7

NethServer Version: V7.4 final
Module: Samba4 AD Account provider
I am a bit puzzled on the ‘best practise’ when adding a NS7 Server to a remote AD or Samba4 domain.
My problem is as follows: When a new NS7 is installed, we give it a FQDN. We can find the FQDN in ServerManager under Configuration / Server name
This must be a FQDN. In my ignorance I named it as server.domain.tld, which represents the situation on my LAN.
Now I want to add the server to the domain so the services configured on the server can be used by domain users. I go over to Configuration / Account provider and hit the Active Directory button and after that the ‘join domain’ button.

Then I get back the following error:
Failed to join Active Directory (Failed to enroll machine in realm: Already have domain ad.domain.tld in sssd.conf config file)

All quite logical, but what would be the best practise in this case?
Rename the server to some imaginary FQDN and then join the domain. This works, but then i am stuck with a FQDN that is different from the actual domain.

If I try to rename the server again, I get the error:
Fully qualified domain name
Users and groups provider already configured

Any more elegant solution?

Additional to this: can the data from configuration / organization contacts be copied over during/after domain join? It would make sense to me anyways.

If I remember correctly, it worked for me by just trying again. First time the error is thrown, second time it works.

2 Likes

That is correct. I had the same issue and question. First time you get an error about the Realm already being defined in sssd, you then just do the exact same thing, and it will pass.

Tested on fully updated and not-updated versions.

2 Likes

Good to know, but it gives a sloppy impression (to me it does anyway)
@davidep: is there a way to improve this behaviour?

Sounds like a bug to me :rolling_eyes:

How to reproduce it on a clean NethServer:

  • given the AD domain adtest.net with DC 192.168.1.200
  • set machine DNS to 192.168.1.200
  • change the server name to server2.adtest.net
  • join the adtest.net domain from accounts provider page (leave blank DNS field)
Dec  5 16:44:29 server2 realmd: * Resolving: _ldap._tcp.adtest.net
Dec  5 16:44:29 server2 realmd: * Performing LDAP DSE lookup on: 192.168.1.200
Dec  5 16:44:29 server2 realmd: * Successfully discovered: adtest.net
Dec  5 16:44:29 server2 realmd: * Required files: /usr/sbin/oddjobd, /usr/libexec/oddjob/mkhomedir, /usr/sbin/sssd, /usr/bin/net
Dec  5 16:44:29 server2 realmd: * LANG=C LOGNAME=root /usr/bin/net -s /var/cache/realmd/realmd-smb-conf.QL8TAZ -U administrator ads join adtest.net
Dec  5 16:44:30 server2 realmd: Enter administrator's password:
Dec  5 16:44:30 server2 realmd: Using short domain name -- ADTEST
Dec  5 16:44:30 server2 realmd: Joined 'SERVER2' to dns domain 'adtest.net'
Dec  5 16:44:30 server2 realmd: * LANG=C LOGNAME=root /usr/bin/net -s /var/cache/realmd/realmd-smb-conf.QL8TAZ -U administrator ads keytab create
Dec  5 16:44:31 server2 realmd: Enter administrator's password:
Dec  5 16:44:31 server2 realmd: ! Failed to enroll machine in realm: Already have domain adtest.net in sssd.conf config file


Workaround

Try again


@robb did I understand correctly?

2 Likes

Reason:

The hostname-modify event causes the /etc/sssd/sssd.conf template to be expanded, thus the realm procedure fails because it requires sssd.conf to be absent.

2 Likes

Effect: Windows admin assumes that the FQDN of the server prior to promoting can not use the AD domain name, and creates a mess. True story :blush:

4 Likes

Exactly what I encountered…

What is going to be done about this? Is there a way to patch this behavior or a warning in the (official) documentation?

Who wants to file a bug on github? /cc @stephdl @mrmarkuz @davidep

1 Like
6 Likes

Testing package online:

yum install --enablerepo=nethserver-testing nethserver-sssd

3 Likes

Great team! @mrmarkuz + @davidep + @nethbot

1 Like