search

ltb-project / self-service-password

Web interface to change and reset password in an LDAP directory
https://self-service-password.readthedocs.io/en/latest/
GNU General Public License v3.0
1.13k stars 319 forks source link

Possible incompatibility with Windows Server 2022 #918

Open unquietwiki opened 2 weeks ago

unquietwiki commented 2 weeks ago

Hey all. Currently having trouble authenticating against Active Directory on a Windows Server 2022 instance; worked with a previous 2012 instance. Using "openssl s_client" to poll the LDAPS port, I was getting a TLS v1.3 response; figured that was an issue, so I disabled it. However, while I'm getting a TLS v1.2 response now, I think it's still not matching the ciphers being used by the server.

Requested Signature Algorithms: RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1:RSA+SHA512:ECDSA+SHA512
Shared Requested Signature Algorithms: RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:ECDSA+SHA256:ECDSA+SHA384:RSA+SHA512:ECDSA+SHA512

Currently using version 1.6 of SSP on Debian Bookworm. Thanks!

coudot commented 2 weeks ago

I don't see why you disable TLSv1.3.

Configure your SSL layer on your server to match ciphers from AD. This is not linked to Self Service Password.

Try to connect to AD with openssl s_client

unquietwiki commented 2 weeks ago

@coudot Thank you for clarifying the issue wasn't TLS 1.3; that was something I know is an issue with a lot of software out there. Is there good documentation or code reference regarding getting SSP to use whatever TLS ciphers Windows is trying to use? I saw some documentation, but it was pretty sparse.

coudot commented 2 weeks ago

I don't know what is the correct SSL configuration for Windows. The SSL settings are outside Self Service Password configuration, but you can override system settings by putting this on your config file:

putenv("LDAPTLS_CIPHER_SUITE=HIGH:MEDIUM");

Check the documentation of OpenSSL for correct configuration of cipher suite.

unquietwiki commented 2 weeks ago

Thank you for that. Running into a completely different issue now: it's saying my new password is "insufficient quality". Using same complexity rules I had in SSP 1.5; guess that's a separate issue altogether.

BTW, I truly appreciate your prompt responses on this stuff; it helps!

unquietwiki commented 1 week ago

@coudot wanted to give you an update. I rebuilt the config file against the new version, and then began tweaking things.

Below is the full error message I get from Nginx's error log. The audit.log file has a much more truncated "ldaperror" message that doesn't say what the exact issue is.

2024/06/24 21:14:01 [error] 643334#643334: *2344 FastCGI sent in stderr: "PHP message: Module Zxcvbn successfully loaded; PHP message: PHP Warning: ldap_bind(): Unable to bind to server: Can't contact LDAP server in /usr/share/self-service-password/vendor/ltb-project/ldap/src/Ltb/PhpLDAP.php on line 36; PHP message: LDAP - Bind error -1 (Can't contact LDAP server); PHP message: PHP Deprecated: Creation of dynamic property Smarty_Internal_Template::$compiled is deprecated in /usr/share/php/smarty3/sysplugins/smarty_internal_template.php on line 719; PHP message: PHP Deprecated: Creation of dynamic property Smarty_Internal_Template::$compiled is deprecated in /usr/share/php/smarty3/sysplugins/smarty_internal_template.php on line 719; PHP message: PHP Deprecated: Creation of dynamic property Smarty_Internal_Template::$compiled is deprecated in /usr/share/php/smarty3/sysplugins/smarty_internal_template.php on line 719; PHP message: PHP Deprecated: Creation of dynamic property Smarty_Internal_Template::$compiled is deprecated in /usr/share/php/smarty3/sysplugins/smarty_internal_template.php on line 719; PHP message: PHP Warning: Undefined array key "msg_changehelpextramessage" in /var/cache/self-service-password/templates_c/f6b50b13b91599a6d59a20cb1147ad5af3c8d817_2.file.change.tpl.php on line 43; PHP message: PHP Warning: Attempt to read property "value" on null in /var/cache/self-service-password/templates_c/f6b50b13b91599a6d59a20cb1147ad5af3c8d817_2.file.change.tpl.php on line 43; PHP message: PHP Deprecated: Creation of dynamic property Smarty_Internal_Template::$compiled is deprecated in /usr/share/php/smarty3/sysplugins/smarty_internal_template.php on line 719; PHP message: PHP Deprecated: Creation of dynamic property Smarty_Internal_Template::$compiled is deprecated in /usr/share/php/smarty3/sysplugins/smarty_internal_template.php on line 719; PHP message: PHP Deprecated: Creation of dynamic property Smarty_Internal_Template::$compiled is deprecated in /usr/share/php/smarty3/sysplugins/smarty_intern

coudot commented 1 week ago

"insufficient quality" error went away when I used the default password restrictions; there may be an issue there I can report in a separate post.

I don't understand where is the issue. If you provide a low quality password to AD, it will be refused.

Since this is an AD environment, I had to delegate the service account to reset + create/delete both regular and inetOrg users to get rid of error 50 messages. You may have run into that as a separate issue before.

This is written in documentation https://self-service-password.readthedocs.io/en/stable/config_ldap.html#active-directory

If I set the program to try calling port LDAPS/636 on one server, and LDAP/389 on another, it appears to skip using the LDAPS server, and respond against the LDAP server. It will also refuse to reset the password in this configuration. If I set it to just use the LDAPS server alone, it will come back with an LDAP error.

Because your SSL configuration is not correct. SSL is required by AD to change password. No issue here.

Using the "putenv" you provided, as well as changing it to the requested cipher suite, appears to have no effect on the LDAP error.

You need to find the expected values for you Active Directory

unquietwiki commented 1 week ago

Thank you for the follow-up on this. I see in the documentation that there were additional delegate rules I should have in place; I will make that correction on my end. And sorry if I wasn't more clear on the 636/389 error: I understand its correct behavior, and was intending to highlight that the LDAPS connectivity was still being refused.

Regarding the low-quality password error, it was occurring before submitting to LDAP; it seemed to be based on the PHP logic that was checking password quality against the configured rules, and setting the limits in the config file to "0" nullified the error. I had rules in place with version 1.5, so I'm curious why it'd be an issue now.

Returning to the original LDAPS error, it's certainly not generating an extended error message (and I do have that enabled in the config), as the code indicates I should be getting. If I could get it to tell me exactly why the cert connection isn't working, then it'd be easier to troubleshoot this problem. I might dig around the code some and see if there's a way to better express the exact error return.

coudot commented 6 days ago

Regarding the low-quality password error, it was occurring before submitting to LDAP; it seemed to be based on the PHP logic that was checking password quality against the configured rules, and setting the limits in the config file to "0" nullified the error. I had rules in place with version 1.5, so I'm curious why it'd be an issue now.

Indeed, if there is a behavior change between 1.5 and 1.6, it could be a bug. Be sure to use the correct config.inc.php from the package and use config.inc.local.php for your settings.

Returning to the original LDAPS error, it's certainly not generating an extended error message (and I do have that enabled in the config), as the code indicates I should be getting. If I could get it to tell me exactly why the cert connection isn't working, then it'd be easier to troubleshoot this problem. I might dig around the code some and see if there's a way to better express the exact error return.

First check with openssl s_client that you can connect to AD, and verify the certificate chain.

unquietwiki commented 4 days ago

Exported the CA cert to a PEM file, and ran openssl s_client -CAfile ...

CONNECTED(00000003)
---
Certificate chain
 0 s:
   i:DC = loc, DC = redacted, CN = CIUSSJCA01
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jun 18 00:46:55 2024 GMT; NotAfter: Jun 18 00:46:55 2025 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
REDACTED
-----END CERTIFICATE-----
subject=
issuer=DC = loc, DC = redacted, CN = CIUSSJCA01
---
No client certificate CA names sent
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1:RSA+SHA512:ECDSA+SHA512
Shared Requested Signature Algorithms: RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:ECDSA+SHA256:ECDSA+SHA384:RSA+SHA512:ECDSA+SHA512
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: ECDH, secp384r1, 384 bits
---
SSL handshake has read 2042 bytes and written 497 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: B11C000008A62D2540D7EC149FEB5027080C6F4B45EF4C91574CDF4391A79E06
    Session-ID-ctx: 
    Master-Key: 71D15B4CCB1BEE2AEA1931962C346789FA3A15A8E6C18089CBBDE3F53E04200826CBF6EDED6D665A8CC6DFA9523969A6
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1719954538
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: yes
---
coudot commented 3 days ago

So configure this CA cert on your system so that PHP will trust it

unquietwiki commented 3 days ago

Okay...

  1. Dropped the CA into /usr/local/share/ca-certificates as a .crt file.
  2. Ran update-ca-certificates -v -f to ensure the CA was loaded properly.
  3. Checked the OpenSSL cipher list with openssl ciphers -v TLSv1.2
  4. Verified the cert was actually loaded into /etc/ssl/certs/ca-certificates.crt by step 2.
  5. The following below is in /etc/ldap/ldap.conf , and I also added as putenv variables to config.inc.local.php
TLS_CACERT      /etc/ssl/certs/ca-certificates.crt
TLS_REQCERT     allow
TLS_CIPHER_SUITE TLSv1.2

Unfortunately, I still get an "LDAP error" when attempting to reset the password.