We have just upgraded all our servers to Leap 42.1 in the hopes of Samba version 4.3 introducing support for SMB 3.1.1 would fix the problems we have getting our Windows computers to join our domain. We have Samba running as our primary domain controller. When we try to join our domain, we get the error that “The specified domain either does not exist or could not be detected”. We have to apply to following changes to each and every computer before they can find the domain:
And finally with Windows 10, we have to limit it to only running SMB 1.0.
It’s probably not relevant, but even after applying these fixers, the computer still fails to find the domain on the first try. On the second try, it finds it and joins it.
In our Samba logs, we can see that it can run SMB 2 and 3 just fine with various Windows 7/8 computers already on the domain. But as we wish to roll out Windows 10 to everybody, it would be a lot of work manually applying these fixes to every computer, plus SMB 1.0 is slower than more recent versions.
Next time before you add a machine to a Domain,
Simply configure a Hosts file entry pointing to your DC.
It’s been my tried and true solution for adding machines to all types of Domains for years.
Is based on the idea that until a machine has joined a Domain and is able to utilize the Domain’s superior directory services, a machine may need to be precisely told where that first DC is for registration (new join). DHCP client configuration may not be sufficient, and broadcasts are notoriously unreliable so you need that Hosts file entry.
You can remove the Hosts file entry after joining so that it won’t over-ride what DNS provides although realistically your DC should never change its network settings.
You mean, edit the host file on each and every computer before joining the domain? That’s just a workaround like the other things I mentioned, that won’t help. Actually it’ll be even more work if I have to remove it again after joining.
If you’re using DHCP, it’s also possible to configure it to distribute a custom Hosts file if you’re adding a very large number of new Hosts to the Domain.
It’s not really a workaround… It addresses the fundamental problem directly (Before a machine joins the Domain, it might not be able to identify and do the name resolution necessary to connect to the correct machine which is a DC).
You don’t have to remove the entry afterwards… In most cases the DC never changes its IP address and the Hosts entry should be identical to what would be acquired from DNS. But, on the very rare chance that some emergency in the future might cause the “never happens” scenario to happen (like a DC crash and re-build with a new IP address), removing the entry avoids a nasty surprise in that case.
I’ll try creating a host file, but I don’t think that’s our problem, since the machine can find the DC just fine if we force it down to SMB 1.0. Also, if I put in a bogus domain name, it just says it can’t find it, while if I give it the correct domain name, it says it cant find/connect to it.
I have now tried writing an LMHOSTS file on a laptop computer, following https://support.microsoft.com/en-us/kb/314108 but it still doesn’t work. I get this error when I try to connect:
The domain name "NEUROBIO" might be a NetBIOS domain name. If this is the case, verify that the domain name is properly registered with WINS.
If you are certain that the name is not a NetBIOS domain name, then the following information can help you troubleshoot your DNS configuration.
An error occurred when DNS was queried for the service location (SRV) resource record used to locate an Active Directory Domain Controller (AD DC) for domain "NEUROBIO".
The error was: "No DNS servers configured for local system."
(error code 0x0000267C DNS_ERROR_NO_DNS_SERVERS)
The query was for the SRV record for _ldap._tcp.dc._msdcs.NEUROBIO
I have no idea if the problem lies in Windows, Opensuse or Samba… all help would be appreciated.
I’ve typically found that for both Windows adding to a SAMBA domain and adding a Linux to an AD (which is the other way around) that it’s better to create the User and Machine accounts first (as a SAMBA Admin, of course), then join the machine to the Domain. When you do this, then the new machine is auto recognized and things “just work.”
Otherwise, what you’re doing is to create the machine account on the fly and I’ve found that to be subject to possible failures.
As the machine has already been on the domain, it already has an account.
To make my previous posts clear: It seems that the laptop can find the Domain Controller, but not the domain.
It only asks for domain admin username and password if I type the correct domain name, but then it says the domain is nonexistant/unreachable.
Editing previous posts is only possible for a limited amount of time. If that time passes you will not be able to edit it again. As far as I remember that time is a few minutes after initially posting.
Seems like the same problems we’re having. If we upgrade an existing Windows 7 machine to Windows 10, it will not be able to log on, giving the “No logon servers to service the request” error until we’ve bumped the machine down to SMB 1.
This is annoying, there must be other companies than us with this problem…
I have similar problem with Win10. However, I can join Win7 without any problem to my Linux SAMBA+LDAP PDC following procedure from Samba wiki, but when I try to join Win 10, I got error that I do not have DNS. After that I added
_ldap._tcp.dc._msdcs.
into my DHCP, and now I get error:
*However no domain controllers could be contacted.
Common causes of this error include:
Host (A) or (AAAA) records that map the names of the domain controllers to their IP addresses are missing or contain incorrect addresses.
Domain controllers registered in DNS are not connected to the network or are not running.*
I disabled IPv6 on my Windows 10 machine (i have found instruction on google) but without success.
consider migrating to a Samba Active Directory (AD) to avoid problems if a future update from Microsoft disables or removes the unsupported NT4 features.
The migration from an NT4-style domain to Active Directory is one way! This means that once your clients contact your migrated AD Domain Controller, they will never be able to access the NT4-style domain again - even if you roll back your changes!
It’s highly recommended, that before you do the migration, you should test the upgrade process in a separate network from your production! This enables you to avoid unnecessary downtime through unpredictable problems and it won’t have any effect on your existing network.
