Bug 14621 - "password hash userPassword schemes = CryptSHA256" does not seem to work with samba-tool
Summary: "password hash userPassword schemes = CryptSHA256" does not seem to work with...
Status: ASSIGNED
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB (show other bugs)
Version: 4.13.3
Hardware: All Linux
: P5 normal (vote)
Target Milestone: ---
Assignee: Joseph Sutton
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-01-28 02:03 UTC by Sergio Durigan Junior
Modified: 2021-07-05 09:39 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sergio Durigan Junior 2021-01-28 02:03:39 UTC
Hello,

The downstream version of this bug can be found at:

https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1912750

This problem happens when one is using "samba-tool" to provision a domain member to an AD DC while using "password hash userPassword schemes = CryptSHA256" in smb.conf.  The bug is easy to trigger:

# mv /etc/samba/smb.conf /etc/samba/smb.conf.bkp
# samba-tool domain provision --use-rfc230 --realm="EXAMPLE.COM" --domain="EXAMPLE" --adminpass="FooBar123@" --server-role=dc --host-ip=10.166.183.55 --option="password hash userPassword schemes=CryptSHA256"

After running the command above, I get:

...
INFO 2021-01-28 01:59:27,859 pid:1110 /usr/lib/python3/dist-packages/samba/provision/__init__.py #1570: Setting up well known security principals
INFO 2021-01-28 01:59:27,880 pid:1110 /usr/lib/python3/dist-packages/samba/provision/__init__.py #1584: Setting up sam.ldb users and groups
ERROR(ldb): uncaught exception - setup_primary_userPassword: generation of a CryptSHA256 password hash failed: (Numerical result out of range)
  File "/usr/lib/python3/dist-packages/samba/netcmd/__init__.py", line 186, in _run
    return self.run(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/samba/netcmd/domain.py", line 487, in run
    result = provision(self.logger,
  File "/usr/lib/python3/dist-packages/samba/provision/__init__.py", line 2341, in provision
    provision_fill(samdb, secrets_ldb, logger, names, paths,
  File "/usr/lib/python3/dist-packages/samba/provision/__init__.py", line 1952, in provision_fill
    samdb = fill_samdb(samdb, lp, names, logger=logger,
  File "/usr/lib/python3/dist-packages/samba/provision/__init__.py", line 1585, in fill_samdb
    setup_add_ldif(samdb, setup_path("provision_users.ldif"), {
  File "/usr/lib/python3/dist-packages/samba/provision/common.py", line 55, in setup_add_ldif
    ldb.add_ldif(data, controls)
  File "/usr/lib/python3/dist-packages/samba/__init__.py", line 230, in add_ldif
    self.add(msg, controls)

I ran tests with the samba package from Ubuntu hirsute (current development version), which is the latest samba in Ubuntu's repositories (version 4.13.3+dfsg-1ubuntu1), and also on Fedora 33, using samba version samba-4.13.3-0.fc33.x86_64.  I could also confirm this bug in Ubuntu Focal, which is using samba version 4.11.6+dfsg-0ubuntu1.6.

Initially, the reporter of the downstream bug believed that the problem was related to Bug 14424, but after some testing I confirmed that the patches used to fix that bug don't affect this one.

A quick search for "samba" "password hash userPassword schemes" does not show me very useful results.  In fact, it doesn't offer many hits, which may also mean that this option is not much used in the wild.

Please, let me know whether you need more information about this problem, and I will be happy to provide it.
Comment 1 Andrew Bartlett 2021-02-09 03:44:12 UTC
I'm working with a new contributor to investigate this.  We know why this happens etc.

The best option for now would be to set the option after provision, but we will try to fix this because I think we should make this the default.
Comment 2 Samba QA Contact 2021-04-07 10:25:13 UTC
This bug was referenced in samba master:

05d70f92b633284044d1cd14314eadb3645c1e09
88b3d3443b3a581ec301430346b3e9bf05d81b5e
609ca657652862fd9c81fd11f818efb74f72ff55
0730b936d7a8f55389873d72cb0996ab941f15d7
e656d8b1ad4c70a7c85a66945d7c7d807fce9b6c
de28d915d7f135c43c35cf2b5167f9603e99b1f6
Comment 3 Andrew Bartlett 2021-07-02 20:18:30 UTC
Joseph,

If you still have the information in your browser history, can you add some detail on the upstream libxcrypt change that broke us here, so others can connect the dots in the future?

Thanks!
Comment 4 Joseph Sutton 2021-07-05 09:39:25 UTC
This commit from 2017 introduced CRYPT_MAX_PASSPHRASE_SIZE with a value of 512:
https://github.com/besser82/libxcrypt/commit/4856729bd75c78e4e1e4e35ab5afd7cef6c66afc

This commit from 2019 introduced range checking on the size parameter:
https://github.com/besser82/libxcrypt/commit/34f216caaefbc1af599ec7a7b75cb21718eceaba
Prior to this commit, "longer passphrases would either be silently accepted, silently truncated, or the library would crash, depending on the hashing method."