When I enabled AD, it asked me for the AD domain.
Since my domain was mydomain.com, I set the AD domain to be local.mydomain.com.
I assumed that my server name would remain the same (for DC purposes).
Let say it was myserver.mydomain.com, internally it would become myserver.local.mydomain.com.
But when I check domain info, it shows as: nsdc-myser45a5d.local.mydomain.com
Is there a reason it is named like that?
I don’t recall such a restriction in Windows DC machines.
ALSO NOTE: In Cockpit I found no way to check the LDAP server IP! (then one we set when enabling domain services) It can only be seen in NethGUI “domain accounts”.
We need to set an hostname for the underlying Linux Container that runs the DC service. The DC host name is obtained by prepending nsdc- to the main host name. If the resulting name is more than 15 chars it is hashed, like yours.
I’d like to implement a “DC host rename” function. I understand that to administrate the DC a mnemonic name would be appreciated. In the meanwhile it is possible to ask the DNS to discover it:
Since we cannot change DC hostname afterwards (without risking a ton of issues), it is important to be able to set it when LDAP is enabled.
QUESTION: Why not use the existing hostname? I don’t remember ever a requirement to prepend “nsdc-”.
(I think Zentyal does use the existing hostname… just the domain changes, which is also not a requirement)
Is the problem stemming from using a container for Samba? Does Zentyal implement Samba differently?
Since we are at the subject, if things are to be improved, also a note to USE DC IP AS DNS for clients, is important to pop up, when LDAP/AD is enabled.
Is a post in “Features” needed for the above two things to be considered?
We need to set an hostname for the underlying Linux Container that runs the DC service
It must be different from the main host name.
Yes probably they don’t need a Linux Container because they have different requirements and different resources (Ubuntu).
We always encourage to set the dnsmasq IP (which runs with the main host IP) as LAN DNS (and DHCP) because it is more consistent with past and present NethServer configurations and deployment choices. Also dnsmasq overridden records are honored.
However this does not follow AD recommendations. What happens is that the Win clients cannot send DNS UPDATE requests through dnsmasq. This is not required to make the AD authentication work, because dnsmasq can forward DNS requests to the private AD domain when needed.
If you have a large network, with many subnets and hosts and you’re planning for multiple DCs it could sound wrong, but it works perfectly in small (class C?) networks.
Please share the DNS requirements for your network. As you’re new to the NethServer world there can be nice ideas coming from them and maybe we find a better setup
For my home setup there are no serious DNS requirements.
I am used to having complex DNS scenarios though, when using VPN, when I make domain trusts etc.
Having a local DNS actually mirror content of a remote internal DNS or implement a stub is many times needed and cannot be covered by just allowing the client (through dnsmasq) go “outside” and query an FQDN (or service), where the public DNS of the remote will reply with public resolved destinations (instead of using the VPN).
In those cases we need to intercept and handle the request on our own.
Simple A records won’t cut it.
Also I understand that Win clients will still be able to authenticate by using the generic dnsmasq, but domain DNS update (and also definition of PTR record?) is a Nice Thing To Have ™ for a clean AD.
If this thing cannot change for the lifetime of NS7, it MUST be considered for NS8 (you’ve already seen I already made a post about it).
