Joining a Windows 7 Pro machine to a Samba-3.5.2 domain succeeds - BUT - it generates an error message that is unacceptable to commercial users. This is a request for resolution made by a large managed services provider (MSP) whose customers are most unhappy that when they join their machines to a Samba domain there is an error message. To quote the CEO: "We spend all out lives telling drivers that when the gas meter is on empty and the light flashes its time to fix the problem. I can not with clear conscience tell my customers to ignore the flashing light when they join a machine to a Samba domain." They are facing the music as they update several hundred sites from older 3.0.x to the current version. The MSP asks only that we inform him how to make the error message NOT appear. It causes too much alarm with customers. He understands that this error message can be ignored. Detailed log files are provided.
Created attachment 5614 [details] This is a loglevel 10 log file from Samba 3.5.2 as the Win7 domain join happens.
Created attachment 5615 [details] Wireshark capture of the domain join up to the error message.
Created attachment 5616 [details] This is the error message seen on the Windows 7 machine after domain join.
Created attachment 5617 [details] The Windows 7 NetSetup log file (ASCII format) generated by the join process.
Created attachment 5618 [details] Event Viewer save file for the errors created during the domain join.
Jeremy, Please let me know if you need any additional info. I believe this is more or less what you asked for. Right? - John T.
This is a bug report that ClearCenter would like to see addressed as it affects our customers in a domain environment.
Adding Metze.
Found the following Microsoft KB article that may be helpful: http://support.microsoft.com/kb/257623
Another link that shows this is NOT only a Samba issue. http://social.technet.microsoft.com/Forums/en/w7itpronetworking/thread/1bfac433-463e-4fae-a18f-df69eaca84ce
John - the note here: http://wiki.samba.org/index.php/Windows7 tells me this is Win7 attempting to update it's DNS name on the server using encrypted dynamic DNS, which we can't support in S3 smbd (we're not listening on the port). This thread has much interesting info on registry parameters to do with the domain join DNS resolution. http://old.nabble.com/Windows-7-RC-td23405949.html Jeremy.
John, please ask dochelp@winse.microsoft.com and cc the pfif@tridgell.net and cifs-protocol@samba.org mailing lists. I don't see how this can be fixed in Samba3. I think you should disable port 389 for the ip smbd is listening on, in your capture windows tries to connect to the OpenLDAP server, but I don't think it has a real impact.
As you may know, ClearOS is a multi-protocol, multi-service platform. Is the Microsoft performing a standard DDNS update using TLS here or is it doing something wholly proprietary? I don't understand what messages that it may be trying to send port 389. As you know, 389 is not encrypted so I don't understand what the cause is here and how it relates to 389. Is this a failure to replicate RFC 3645 GSS-TSIG functionality on our part? or some other DNS function? http://en.wikipedia.org/wiki/Generic_Security_Service_Algorithm_for_Secret_Key_Transaction If the solutions is a matter of adding some DNS function that is capable with other open source software like ISC BIND, then please let us know. We have a dramatic update planned for our software in regards to DNS and if this update from the workstation complies with an open standard, we can capture it but I need to know if that is the exact corrective solution or if we are looking at something that must be tightly coupled with Samba like GSS-TSIG appears to be.
Response from Microsoft: After reviewing the logs saved in bug 7340, we found that the Windows is trying to verify the DNS name, which requires locating a domain controller. Windows sets the DC required bit (DS_DIRECTORY_SERVICE_REQUIRED, 0x10) in the DsGetDcName query. Since Samba 3 DC doesn't support AD , it may not respond to clients in this case. This operation in the Windows is probably unnecessary and undesirable because there is no DNS name to verify. Furthermore, this behavior is not controllable by any registry or other configuration settings. Even the domain join itself has succeeded at this point and the error can be safely ignored , we understand that the behavior may mislead end users. As an option, we may change this unintended behavior in the future release of the Windows. [We] filed a request for change.
This issue has been resolved and Microsoft has patches available.