Bug 11098 - 4.2.0rc4 Can't authenticate against a Windows 2000 DC
4.2.0rc4 Can't authenticate against a Windows 2000 DC
Status: RESOLVED WORKSFORME
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services
4.2.0rc4
All Linux
: P5 major
: 4.3
Assigned To: Samba QA Contact
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-02-13 18:52 UTC by Tom Schulz
Modified: 2015-08-07 15:57 UTC (History)
1 user (show)

See Also:


Attachments
smb.conf (5.07 KB, text/plain)
2015-02-13 18:52 UTC, Tom Schulz
no flags Details
Log file log.192.168.2.23 (250.81 KB, text/plain)
2015-02-13 18:57 UTC, Tom Schulz
no flags Details
Log file log.tetra (87.78 KB, text/plain)
2015-02-13 18:59 UTC, Tom Schulz
no flags Details
better log file log.192.168.2.23 (63.93 KB, text/plain)
2015-02-20 19:14 UTC, Tom Schulz
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Schulz 2015-02-13 18:52:08 UTC
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.
Comment 1 Tom Schulz 2015-02-13 18:57:52 UTC
Created attachment 10723 [details]
Log file log.192.168.2.23

Log file log.192.168.2.23
Comment 2 Tom Schulz 2015-02-13 18:59:40 UTC
Created attachment 10724 [details]
Log file log.tetra
Comment 3 Tom Schulz 2015-02-18 20:06:11 UTC
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.
Comment 4 Tom Schulz 2015-02-19 15:29:35 UTC
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.
Comment 5 Stefan Metzmacher 2015-02-20 08:00:45 UTC
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?
Comment 6 Tom Schulz 2015-02-20 15:30:07 UTC
> 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.
Comment 7 Tom Schulz 2015-02-20 15:50:31 UTC
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
Comment 8 Tom Schulz 2015-02-20 19:14:56 UTC
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.
Comment 9 Tom Schulz 2015-02-23 20:54:35 UTC
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.
Comment 10 Tom Schulz 2015-08-07 15:57:34 UTC
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.