Created attachment 10722 [details] smb.conf This problem shows up on both Linux and Solaris. I am going to attach the logs from a Fedora 2.6.25-14.fc9.i686 machine. We are using 'security = domain' with a Windows 2000 domain controller. We are setting 'password server = starfish2' dispite the fact that the documentation says that this in not necessary as we have found it to be necessary. We are setting 'workgroup = adi'. I installed Samba 4.2.0rc4 in the same location as a previous 4.1.7 installation after removing everything in bin, sbin & lib. We are running just nmbd and smbd. I will attach our smb.conf file and the two log files created with debug level 5. One of the more common errors seen is NT_STATUS_BUFFER_TOO_SMALL.
Created attachment 10723 [details] Log file log.192.168.2.23 Log file log.192.168.2.23
Created attachment 10724 [details] Log file log.tetra
I find that switching to security=ads makes it work. On the Linux machine it just worked. On the Solaris machine I had to re-join the domain first. But, I had to revert to Samba 4.1.16 to get a net command that would work. The Samba 4.2.0rc4 net command produced the following output: ./net join member -Wadi -Uadministrator -Sstarfish2 Enter administrator's password: ads_setup_sasl_wrapping() failed: The request is not supported. kinit succeeded but ads_sasl_spnego_krb5_bind failed: The request is not supported. Failed to join domain: failed to connect to AD: The request is not supported. ADS join did not work, falling back to RPC... Enter administrator's password: ads_setup_sasl_wrapping() failed: The request is not supported. So there is a problem there. Also, I would think that you would need to support security=server for people who have Domain Controllers that do not support Active Directory. The log files I attached may not be complete as I think that they hit the log file size limit. If any log files are needed later, I will increase that limit.
In the previous comment I said security=server when I meant to say security=domain. So here is the corrected line. I would think that you would need to support security=domain for people who have Domain Controllers that do not support Active Directory.
From the WHATSNEW.txt in 4.2: Finally, the default for 'client ldap sasl wrapping' has been set to 'sign', to ensure the integrity of LDAP connections. Set 'client ldap sasl wrapping = plain' to disable. So "client ldap sasl wrapping = plain" may restore the old behaviour for you?
> So "client ldap sasl wrapping = plain" may restore the old behaviour for you? I just tried that and it did not help. I did not try logging at an elevated log level, so I don't know if the error messages are the same or not.
Some of the errors that are logged that unfortunately do not show up in the logs that I attached are: NT_STATUS_BUFFER_TOO_SMALL NT_STATUS_INVALID_PARAMETER
Created attachment 10760 [details] better log file log.192.168.2.23 Here is a better log file that contains the error messages that look like the important ones. I increased the max log size so that I got the whole log and reduced the debug level to 4. Also I removed most of the shares to remove that clutter. I tried connecting twice and the first pop up box said: The API return buffer is too small. The second pop up box said: The parameter is incorrect. The attached log shows both errors.
Success in getting it to work with security=domain. If I set "client ldap sasl wrapping = plain" AND run winbindd then 4.2.0rc4 will authenticate with a Windows 2000 DC. Also, with "client ldap sasl wrapping = plain" set, the net join command will work. The first time I try to connect after starting the servers, my PC says that the service is not started, but if I immediately retry the connection succeeds. With security=ads, winbindd does not have to be running and "client ldap sasl wrapping = plain" does not have to be set, but without "client ldap sasl wrapping = plain" being set the net join command does not work. So, there does seem to be a bug in the authenticate code in smbd for the case when security=domain is set. At least in the case where a Windows 2000 DC is being used. The last log file attached is for this case.
Somewhere between 4.2.0rc4 and 4.2.3 this problem went away. So closing this bug. Net join also works although it wants the realm set even with security=domain. But it gives a clear message stating that requirement, so not really a problem.