CentOS 7, SSSD against LDAP: finds user but will not log them in, "Authentication failure" when trying to su
5:14 p.m.
Hi,
I am trying to get SSSD to authenticate against an OpenLDAP directory. I have
"debug_level" turned up to 10 but have not been able to figure out what the
problem is based on the log.
On an Ubuntu 22.04 system I have found that something with TLS is broken when it tries to
connect to OpenLDAP, which is why it has failed on that system -- I think this is related
to the OS moving to OpenSSL 3 but have not been able to figure out how to fix it.
On this CentOS 7 system, you can see that it can find the user, can get properties from
the user, but still fails the user login without, as far as I can tell, explaining why.
I have pasted our sssd.conf below, and here is a link to my Nextcloud instance where I am
hosting the relevant portion of the log (it was too big for me to be able to paste it into
Pastebin): https://checkwithscience.com/index.php/s/e7mXKAzcq87q6HD
<https://checkwithscience.com/index.php/s/e7mXKAzcq87q6HD>
Hoping someone can help us get to the bottom of this.
Thanks.
Here is our sssd.conf:
[sssd]
services = nss, pam
config_file_version = 2
domains = default
certificate_verification = no_verification
[nss]
[pam]
offline_credentials_expiration = 60
[domain/default]
debug_level = 10
ldap_id_use_start_tls = False
cache_credentials = True
ldap_search_base = ou=users,dc=clab,dc=lab
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
access_provider = ldap
ldap_uri = ldaps://10.8.8.60:636
ldap_default_bind_dn = cn=admin,dc=clab,dc=lab
ldap_default_authtok = definitelyverysecurepassword
ldap_tls_reqcert = allow
ldap_tls_cacert = /usr/local/share/ca-certificates/mycacert.crt
ldap_tls_cacertdir = /usr/local/share/ca-certificates
ldap_tls_cert = /etc/ldap/ldapserver00_slapd_cert.pem
certificate_verification = no_verification
ldap_search_timeout = 50
ldap_network_timeout = 60
ldap_access_order = filter
ldap_access_filter = (objectClass=posixAccount)
override_homedir = /home/%U
override_shell = /bin/bash
ldap_user_name = uid
auto_private_groups = true
sudo_provider = none
ldap_account_expire_policy = nds
ldap_passwd_policy = shadow
12:50 a.m.
New subject: CentOS 7, SSSD against LDAP: finds user but will not log them in, "Authentication failure" when trying to su
Am Tue, Dec 06, 2022 at 05:14:34PM -0600 schrieb Jarett DeAngelis:
Hi,
I am trying to get SSSD to authenticate against an OpenLDAP directory. I have
"debug_level" turned up to 10 but have not been able to figure out what the
problem is based on the log.
On an Ubuntu 22.04 system I have found that something with TLS is broken when it tries to
connect to OpenLDAP, which is why it has failed on that system -- I think this is related
to the OS moving to OpenSSL 3 but have not been able to figure out how to fix it.
On this CentOS 7 system, you can see that it can find the user, can get properties from
the user, but still fails the user login without, as far as I can tell, explaining why.
I have pasted our sssd.conf below, and here is a link to my Nextcloud instance where I am
hosting the relevant portion of the log (it was too big for me to be able to paste it into
Pastebin): https://checkwithscience.com/index.php/s/e7mXKAzcq87q6HD
<https://checkwithscience.com/index.php/s/e7mXKAzcq87q6HD>
Hi,
there is no authentication attempt covered in the log file. Are you sure
pam_sss.so is included in your PAM configuration and called for the
specific user?
bye,
Sumit
Hoping someone can help us get to the bottom of this.
Thanks.
Here is our sssd.conf:
[sssd]
services = nss, pam
config_file_version = 2
domains = default
certificate_verification = no_verification
[nss]
[pam]
offline_credentials_expiration = 60
[domain/default]
debug_level = 10
ldap_id_use_start_tls = False
cache_credentials = True
ldap_search_base = ou=users,dc=clab,dc=lab
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
access_provider = ldap
ldap_uri = ldaps://10.8.8.60:636
ldap_default_bind_dn = cn=admin,dc=clab,dc=lab
ldap_default_authtok = definitelyverysecurepassword
ldap_tls_reqcert = allow
ldap_tls_cacert = /usr/local/share/ca-certificates/mycacert.crt
ldap_tls_cacertdir = /usr/local/share/ca-certificates
ldap_tls_cert = /etc/ldap/ldapserver00_slapd_cert.pem
certificate_verification = no_verification
ldap_search_timeout = 50
ldap_network_timeout = 60
ldap_access_order = filter
ldap_access_filter = (objectClass=posixAccount)
override_homedir = /home/%U
override_shell = /bin/bash
ldap_user_name = uid
auto_private_groups = true
sudo_provider = none
ldap_account_expire_policy = nds
ldap_passwd_policy = shadow
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
2:10 a.m.
New subject: CentOS 7, SSSD against LDAP: finds user but will not log them in, "Authentication failure" when trying to su
Hi Sumit,
Thank you! You made me realize I never updated PAM using authconfig. `sudo authconfig
--enablesssdauth --enablesssd --updateall --enablemkhomedir` took care of it.
Do you have any insights as to what is going on with the newer (Ubuntu 22.04)
machine's attempts to authenticate? SSSD logs are pretty clear that there is an
"unknown error" with TLS communication despite the OpenLDAP server appearing to
communicate normally -- OpenSSL 3.0 freezes, basically, while trying to connect, as seen
here:
(2022-12-07 7:17:24): [be[default]] [check_if_online_delayed] (0x2000): [RID#1010] Trying
to go back online!
(2022-12-07 7:17:24): [be[default]] [fo_reset_services] (0x1000): [RID#1010] Resetting
all servers in all services
(2022-12-07 7:17:24): [be[default]] [set_server_common_status] (0x0100): [RID#1010]
Marking server '10.8.8.60' as 'name not resolved'
(2022-12-07 7:17:24): [be[default]] [fo_set_port_status] (0x0100): [RID#1010] Marking
port 636 of server '10.8.8.60' as 'neutral'
(2022-12-07 7:17:24): [be[default]] [fo_set_port_status] (0x0400): [RID#1010] Marking
port 636 of duplicate server '10.8.8.60' as 'neutral'
(2022-12-07 7:17:24): [be[default]] [dp_attach_req] (0x0400): [RID#1011] DP Request
[Online Check #1011]: REQ_TRACE: New request. Flags [0000].
(2022-12-07 7:17:24): [be[default]] [dp_attach_req] (0x0400): [RID#1011] Number of active
DP request: 1
(2022-12-07 7:17:24): [be[default]] [fo_resolve_service_send] (0x0100): [RID#1011] Trying
to resolve service 'LDAP'
(2022-12-07 7:17:24): [be[default]] [get_server_status] (0x1000): [RID#1011] Status of
server '10.8.8.60' is 'name not resolved'
(2022-12-07 7:17:24): [be[default]] [get_port_status] (0x1000): [RID#1011] Port status of
port 636 for server '10.8.8.60' is 'neutral'
(2022-12-07 7:17:24): [be[default]] [fo_resolve_service_activate_timeout] (0x2000):
[RID#1011] Resolve timeout [dns_resolver_timeout] set to 6 seconds
(2022-12-07 7:17:24): [be[default]] [get_server_status] (0x1000): [RID#1011] Status of
server '10.8.8.60' is 'name not resolved'
(2022-12-07 7:17:24): [be[default]] [set_server_common_status] (0x0100): [RID#1011]
Marking server '10.8.8.60' as 'resolving name'
(2022-12-07 7:17:24): [be[default]] [check_if_online_delayed] (0x2000): [RID#1010] Check
online req created.
(2022-12-07 7:17:24): [be[default]] [set_server_common_status] (0x0100): [RID#1011]
Marking server '10.8.8.60' as 'name resolved'
(2022-12-07 7:17:24): [be[default]] [be_resolve_server_process] (0x1000): [RID#1011]
Saving the first resolved server
(2022-12-07 7:17:24): [be[default]] [be_resolve_server_process] (0x0200): [RID#1011]
Found address for server 10.8.8.60: [10.8.8.60] TTL 7200
(2022-12-07 7:17:24): [be[default]] [sdap_uri_callback] (0x0400): [RID#1011] Constructed
uri 'ldaps://10.8.8.60:636'
(2022-12-07 7:17:24): [be[default]] [sssd_async_socket_init_send] (0x4000): [RID#1011]
Using file descriptor [21] for the connection.
(2022-12-07 7:17:24): [be[default]] [sssd_async_socket_init_send] (0x0400): [RID#1011]
Setting 60 seconds timeout [ldap_network_timeout] for connecting
(2022-12-07 7:17:24): [be[default]] [sss_ldap_init_sys_connect_done] (0x0020): [RID#1011]
ldap_install_tls failed: [Connect error] [unknown error]
(2022-12-07 7:17:24): [be[default]] [sss_ldap_init_state_destructor] (0x0400): [RID#1011]
calling ldap_unbind_ext for ldap:[0x560819ad2470] sd:[21]
(2022-12-07 7:17:24): [be[default]] [sss_ldap_init_state_destructor] (0x0400): [RID#1011]
closing socket [21]
(2022-12-07 7:17:24): [be[default]] [sdap_sys_connect_done] (0x0020): [RID#1011]
sdap_async_connect_call request failed: [5]: Input/output error.
(2022-12-07 7:17:24): [be[default]] [sdap_handle_release] (0x2000): [RID#1011] Trace:
sh[0x560819af04f0], connected[0], ops[(nil)], ldap[(nil)], destructor_lock[0],
release_memory[0]
(2022-12-07 7:17:24): [be[default]] [_be_fo_set_port_status] (0x8000): [RID#1011] Setting
status: PORT_NOT_WORKING. Called from: ../src/providers/ldap/sdap_async_connection.c:
sdap_cli_connect_done: 1633
(2022-12-07 7:17:24): [be[default]] [fo_set_port_status] (0x0100): [RID#1011] Marking
port 636 of server '10.8.8.60' as 'not working'
If you look at it with `openssl s_client`, it freezes right here:
root@ldapclient:/home/sysop# openssl s_client -connect 10.8.8.60:636
CONNECTED(00000003)
Can't use SSL_get_servername
depth=1 CN = CompanyInternal
verify return:1
depth=0 O = CompanyInternal, CN = ldapserver00.clab.lab
verify return:1
---
Certificate chain
0 s:O = CompanyInternal, CN = ldapserver00.clab.lab
i:CN = CompanyInternal
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA384
v:NotBefore: Nov 1 22:06:32 2022 GMT; NotAfter: Oct 29 22:06:32 2032 GMT
1 s:CN = CompanyInternal
i:CN = CompanyInternal
a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA384
v:NotBefore: Nov 1 22:04:14 2022 GMT; NotAfter: Oct 29 22:04:14 2032 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIERzCCAi+gAwIBAgIUN7zSoFEoRKwSie9d3DoobHH60x4wDQYJKoZIhvcNAQEM
BQAwEjEQMA4GA1UEAxMHQmlvVGVhbTAeFw0yMjExMDEyMjA2MzJaFw0zMjEwMjky
MjA2MzJaMDIxEDAOBgNVBAoTB0Jpb1RlYW0xHjAcBgNVBAMTFWxkYXBzZXJ2ZXIw
MC5jbGFiLmxhYjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKBtDPgT
e8wr/sxg+oUiMDvyuROnxEMDvF8LRwhQianBxqQuwuZulvVLXBgWyVRyNjInUDXU
q1Hbf2JVXVkMufO/VjRIlF4lRPC/sgu1srxUdRvddBEO9t8inAMlJ0dvGOaZBwS7
fKK3+YeIRSleRbXS6ta2shvwxrDTWhiEPL4dgdeD+7J9ll4cbbuHW0YZJvlRJ9xD
VHy70qcZn6ZyDXQt83Mbf78RLioK78S0dKW6eOACKHHSexIGcP8bZOX43XTZJHME
Y7jFSBaMVF+pa0eRj6pTA6U2sFg4puWC1Xkt++1Wpnq9YdB9CqOII3UvdlPVoOHH
oGQ6CmDmIR908kUCAwEAAaN1MHMwDAYDVR0TAQH/BAIwADATBgNVHSUEDDAKBggr
BgEFBQcDATAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0OBBYEFHKk9dZu3nxATWKqJlXK
0ekuoRfkMB8GA1UdIwQYMBaAFCTD8jhauoaHVQBgCHanPoW83kRxMA0GCSqGSIb3
DQEBDAUAA4ICAQCUA72TzDR5evZpTbZAoxZ4O3Xr+gKphB7HHQ4BNZ+zW/AV/rEW
DLTnm3XQ+KPp/1jb1uSsKGqLqQ462rzzYQ5SU98/GxZM8xRxWyTq+wjLFcaUZ93V
HVSm38Y77aK+uhw2qpiMeiKzW/M4UwUYQM4trKMSzBiQz46UPKkzihL5JR/TCcKj
LrT+OhYcbIDfdnf0+jvB75eiWiQXrsX1B0VRVnFR4FqJSH8kD71OLWno9UlTpmWB
xkDrWTW5xJAb+lJT12PRRg8cMRg/GtQSIo8PAPdrm/D6aBQsRtGm8KvIleBgo5FR
htlMVzNyfq35ck8WhjyMQBwegJEbMBDSpYootdNrs5sOtv+CA6qDH6CsatYKr/ke
bu3s167q0x/RAAROcdA6+7eMyrrVyZjv4tqPzfYdLvOg6o7m3kBy1BL56flbd+je
wX4RJvNoQKGrZxKRsfKgS7cJCo3QEoV/RbOzTof3QZ4G+lLE15lI9v9Ad6aaX+Gt
oLHAqxIE1Wld/fmBTBgLL9K5NFfvfINczNLJw/+X3f6e6IjQgT743oJZ4BaNyGn6
3YT5EgDAz5hgM4BhOMovUBVgcFsUdZkH3dHrX9OrdgmP737IXlp7tuo8/J0DMPgr
e2I0qGBqCu03PBYl8G4iwF/7UKFy6cyB1srefQPoVQ0//iPQIB5p6LOhUQ==
-----END CERTIFICATE-----
subject=O = CompanyInternal, CN = ldapserver00.clab.lab
issuer=CN = CompanyInternal
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2932 bytes and written 373 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: 21BBA066E20DCEE0C99DA1EF0EA17A9F474DCB10993529D776A053A32EEDB728
Session-ID-ctx:
Resumption PSK:
6AC936C1645C80A5DDE93B179632FE59A4AEB15D3E3876B4385C01F769087C6D409E818BE582E550B3261CEED468423B
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - 60 81 05 60 76 ea 36 36-e4 97 99 63 43 38 8a 2b `..`v.66...cC8.+
0010 - 24 95 56 e5 af 76 a6 d2-60 82 fa d4 72 91 53 b5 $.V..v..`...r.S.
0020 - 4e fc 0d 13 b8 52 97 2a-40 13 83 7d cf 3f 51 aa N....R.*@..}.?Q.
0030 - 96 f5 76 ca 14 c1 e7 e4-1d b7 39 53 d9 ee 19 89 ..v.......9S....
0040 - fd eb e0 d9 9f 8d 33 3b-97 cd 1d 0d 8c a4 f4 f4 ......3;........
0050 - 6f ab c2 49 59 b4 1c 67-78 b9 4c 93 03 2d 5c ff o..IY..gx.L..-\.
0060 - a9 19 c8 36 a8 23 1b 3c-45 5e 6e 69 f7 8c c4 bb ...6.#.<E^ni....
0070 - d9 d2 a9 86 92 f0 98 94-68 aa eb f2 18 ab ef 59 ........h......Y
0080 - 55 96 43 ad 64 06 26 93-c1 41 8c 2b ce db bb fa U.C.d.&..A.+....
0090 - 9d 9f b3 71 fe cc ec d1-f5 e0 02 a8 70 b9 10 3c ...q........p..<
00a0 - 42 32 60 d4 ac 94 ce 76-89 3a 0e 6c 95 43 22 e4 B2`....v.:.l.C".
00b0 - 89 a4 11 a9 24 a3 9a b4-3e 85 ee bb 1f 07 2f e0 ....$...>...../.
00c0 - bf 45 a2 2e 78 a4 51 9f-34 0e e4 87 a8 b4 c3 2a .E..x.Q.4......*
Start Time: 1670399902
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: BBCD67A75D02D4E8A29FC1BC72AF66A58F589AABA8DCF321B809AEDC2F1100EE
Session-ID-ctx:
Resumption PSK:
2B9BBE1D73BEA62DBB0CDAFE6D25B09FB69F9D53DB02645AA889674CA7D28FF66C8D025F5ECE2015EE228AB9C1A178E9
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - 60 81 05 60 76 ea 36 36-e4 97 99 63 43 38 8a 2b `..`v.66...cC8.+
0010 - 82 ee b5 24 8c 46 a1 ce-81 14 07 fa 50 57 67 78 ...$.F......PWgx
0020 - da 6a b0 d8 df 43 d8 fd-74 67 13 61 37 36 e5 ab .j...C..tg.a76..
0030 - cd 3d 32 95 95 55 a0 47-f1 d8 4a 7c 27 aa 64 7d .=2..U.G..J|'.d}
0040 - 26 0d 60 8e 29 9c a9 40-6d 6f 59 c1 ab 6a e3 d4 &.`.)..@moY..j..
0050 - cb cb 96 05 51 46 48 f8-6b 67 53 10 47 30 36 24 ....QFH.kgS.G06$
0060 - f4 ea 62 f7 ac dc 64 b9-10 4e 62 17 75 3a 55 c9 ..b...d..Nb.u:U.
0070 - 73 98 41 c6 68 6e ee b9-62 e5 19 71 a1 df 05 62 s.A.hn..b..q...b
0080 - 7d 1a 30 dc 46 77 b3 c6-5b b6 fa 4f 2f 34 31 fa }.0.Fw..[..O/41.
0090 - bf 1e 9e 26 b8 ff 95 d3-69 7b de c3 91 34 06 6a ...&....i{...4.j
00a0 - 9e 2c ee 36 08 9f db 1f-28 44 ef 21 07 74 a8 9b .,.6....(D.!.t..
00b0 - bd 55 f6 8b cb 11 bb 5f-7f 71 ba eb 15 1e 1e 70 .U....._.q.....p
00c0 - 36 3e 9d ce 42 2c 60 6d-d0 7f de 60 4a a9 80 da 6>..B,`m...`J...
Start Time: 1670399902
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
^-- it stops there. I understand hanging and waiting for further communication is normal
behavior , but I don't think this is where it's supposed to stop.
Obviously, CentOS 7 with its older version of SSL has no trouble connecting. One
difference is that on CentOS 7 it says "Secure Renegotiation IS supported."
TIA for any help.
Thanks,
Jarett
On Dec 7, 2022, at 12:50 AM, Sumit Bose <sbose(a)redhat.com>
wrote:
Am Tue, Dec 06, 2022 at 05:14:34PM -0600 schrieb Jarett DeAngelis:
> Hi,
>
> I am trying to get SSSD to authenticate against an OpenLDAP directory. I have
"debug_level" turned up to 10 but have not been able to figure out what the
problem is based on the log.
>
> On an Ubuntu 22.04 system I have found that something with TLS is broken when it
tries to connect to OpenLDAP, which is why it has failed on that system -- I think this is
related to the OS moving to OpenSSL 3 but have not been able to figure out how to fix it.
>
> On this CentOS 7 system, you can see that it can find the user, can get properties
from the user, but still fails the user login without, as far as I can tell, explaining
why.
>
> I have pasted our sssd.conf below, and here is a link to my Nextcloud instance where
I am hosting the relevant portion of the log (it was too big for me to be able to paste it
into Pastebin): https://checkwithscience.com/index.php/s/e7mXKAzcq87q6HD
<https://checkwithscience.com/index.php/s/e7mXKAzcq87q6HD><https://c...
<https://checkwithscience.com/index.php/s/e7mXKAzcq87q6HD>>
Hi,
there is no authentication attempt covered in the log file. Are you sure
pam_sss.so is included in your PAM configuration and called for the
specific user?
bye,
Sumit
>
> Hoping someone can help us get to the bottom of this.
>
> Thanks.
>
> Here is our sssd.conf:
>
> [sssd]
> services = nss, pam
> config_file_version = 2
> domains = default
> certificate_verification = no_verification
>
> [nss]
>
> [pam]
> offline_credentials_expiration = 60
>
> [domain/default]
> debug_level = 10
> ldap_id_use_start_tls = False
> cache_credentials = True
> ldap_search_base = ou=users,dc=clab,dc=lab
> id_provider = ldap
> auth_provider = ldap
> chpass_provider = ldap
> access_provider = ldap
> ldap_uri = ldaps://10.8.8.60:636
> ldap_default_bind_dn = cn=admin,dc=clab,dc=lab
> ldap_default_authtok = definitelyverysecurepassword
> ldap_tls_reqcert = allow
> ldap_tls_cacert = /usr/local/share/ca-certificates/mycacert.crt
> ldap_tls_cacertdir = /usr/local/share/ca-certificates
> ldap_tls_cert = /etc/ldap/ldapserver00_slapd_cert.pem
> certificate_verification = no_verification
> ldap_search_timeout = 50
> ldap_network_timeout = 60
> ldap_access_order = filter
> ldap_access_filter = (objectClass=posixAccount)
> override_homedir = /home/%U
> override_shell = /bin/bash
> ldap_user_name = uid
> auto_private_groups = true
> sudo_provider = none
> ldap_account_expire_policy = nds
> ldap_passwd_policy = shadow
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
<mailto:sssd-users@lists.fedorahosted.org>
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
<mailto:sssd-users-leave@lists.fedorahosted.org>
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
<https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
<https://fedoraproject.org/wiki/Mailing_list_guidelines>
> List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
<https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
<https://pagure.io/fedora-infrastructure/new_issue>
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
<mailto:sssd-users@lists.fedorahosted.org>
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
<mailto:sssd-users-leave@lists.fedorahosted.org>
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
<https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
<https://fedoraproject.org/wiki/Mailing_list_guidelines>
List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
<https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
<https://pagure.io/fedora-infrastructure/new_issue>
4:34 a.m.
New subject: CentOS 7, SSSD against LDAP: finds user but will not log them in, "Authentication failure" when trying to su
Am Wed, Dec 07, 2022 at 02:10:23AM -0600 schrieb Jarett DeAngelis:
Hi Sumit,
Thank you! You made me realize I never updated PAM using authconfig. `sudo authconfig
--enablesssdauth --enablesssd --updateall --enablemkhomedir` took care of it.
Do you have any insights as to what is going on with the newer (Ubuntu 22.04)
machine's attempts to authenticate? SSSD logs are pretty clear that there is an
"unknown error" with TLS communication despite the OpenLDAP server appearing to
communicate normally -- OpenSSL 3.0 freezes, basically, while trying to connect, as seen
here:
(2022-12-07 7:17:24): [be[default]] [check_if_online_delayed] (0x2000): [RID#1010]
Trying to go back online!
(2022-12-07 7:17:24): [be[default]] [fo_reset_services] (0x1000): [RID#1010] Resetting
all servers in all services
(2022-12-07 7:17:24): [be[default]] [set_server_common_status] (0x0100): [RID#1010]
Marking server '10.8.8.60' as 'name not resolved'
(2022-12-07 7:17:24): [be[default]] [fo_set_port_status] (0x0100): [RID#1010] Marking
port 636 of server '10.8.8.60' as 'neutral'
(2022-12-07 7:17:24): [be[default]] [fo_set_port_status] (0x0400): [RID#1010] Marking
port 636 of duplicate server '10.8.8.60' as 'neutral'
(2022-12-07 7:17:24): [be[default]] [dp_attach_req] (0x0400): [RID#1011] DP Request
[Online Check #1011]: REQ_TRACE: New request. Flags [0000].
(2022-12-07 7:17:24): [be[default]] [dp_attach_req] (0x0400): [RID#1011] Number of
active DP request: 1
(2022-12-07 7:17:24): [be[default]] [fo_resolve_service_send] (0x0100): [RID#1011]
Trying to resolve service 'LDAP'
(2022-12-07 7:17:24): [be[default]] [get_server_status] (0x1000): [RID#1011] Status of
server '10.8.8.60' is 'name not resolved'
(2022-12-07 7:17:24): [be[default]] [get_port_status] (0x1000): [RID#1011] Port status
of port 636 for server '10.8.8.60' is 'neutral'
(2022-12-07 7:17:24): [be[default]] [fo_resolve_service_activate_timeout] (0x2000):
[RID#1011] Resolve timeout [dns_resolver_timeout] set to 6 seconds
(2022-12-07 7:17:24): [be[default]] [get_server_status] (0x1000): [RID#1011] Status of
server '10.8.8.60' is 'name not resolved'
(2022-12-07 7:17:24): [be[default]] [set_server_common_status] (0x0100): [RID#1011]
Marking server '10.8.8.60' as 'resolving name'
(2022-12-07 7:17:24): [be[default]] [check_if_online_delayed] (0x2000): [RID#1010] Check
online req created.
(2022-12-07 7:17:24): [be[default]] [set_server_common_status] (0x0100): [RID#1011]
Marking server '10.8.8.60' as 'name resolved'
(2022-12-07 7:17:24): [be[default]] [be_resolve_server_process] (0x1000): [RID#1011]
Saving the first resolved server
(2022-12-07 7:17:24): [be[default]] [be_resolve_server_process] (0x0200): [RID#1011]
Found address for server 10.8.8.60: [10.8.8.60] TTL 7200
(2022-12-07 7:17:24): [be[default]] [sdap_uri_callback] (0x0400): [RID#1011] Constructed
uri 'ldaps://10.8.8.60:636'
(2022-12-07 7:17:24): [be[default]] [sssd_async_socket_init_send] (0x4000): [RID#1011]
Using file descriptor [21] for the connection.
(2022-12-07 7:17:24): [be[default]] [sssd_async_socket_init_send] (0x0400): [RID#1011]
Setting 60 seconds timeout [ldap_network_timeout] for connecting
(2022-12-07 7:17:24): [be[default]] [sss_ldap_init_sys_connect_done] (0x0020):
[RID#1011] ldap_install_tls failed: [Connect error] [unknown error]
(2022-12-07 7:17:24): [be[default]] [sss_ldap_init_state_destructor] (0x0400):
[RID#1011] calling ldap_unbind_ext for ldap:[0x560819ad2470] sd:[21]
(2022-12-07 7:17:24): [be[default]] [sss_ldap_init_state_destructor] (0x0400):
[RID#1011] closing socket [21]
(2022-12-07 7:17:24): [be[default]] [sdap_sys_connect_done] (0x0020): [RID#1011]
sdap_async_connect_call request failed: [5]: Input/output error.
(2022-12-07 7:17:24): [be[default]] [sdap_handle_release] (0x2000): [RID#1011] Trace:
sh[0x560819af04f0], connected[0], ops[(nil)], ldap[(nil)], destructor_lock[0],
release_memory[0]
(2022-12-07 7:17:24): [be[default]] [_be_fo_set_port_status] (0x8000): [RID#1011]
Setting status: PORT_NOT_WORKING. Called from:
../src/providers/ldap/sdap_async_connection.c: sdap_cli_connect_done: 1633
(2022-12-07 7:17:24): [be[default]] [fo_set_port_status] (0x0100): [RID#1011] Marking
port 636 of server '10.8.8.60' as 'not working'
If you look at it with `openssl s_client`, it freezes right here:
Hi,
I think your 'openssl s_client' output looks ok.
I would assume that you are not only using a newer version of OpenSSL
but a newer version of OpenLDAP as well which might be more picky when
it comes to TLS and certificates.
First I would suggest to not use the IP address of the LDAP server in
sssd.conf but the fully qualified name ldapserver00.clab.lab, the one
from the CN of your certificate.
If this does not help, please add 'ldap_library_debug_level = -1' to the
[domain/...] section of sssd.conf to get the full OpenLDAP debug output
which might help to better understand what is missing.
Additionally you can check if the new option TLS_REQSAN is set in
ldap.conf on the client to 'demand' or 'hard' which would make the
client require a SAN (subject alternative name) in the certificate which
yours does not have.
HTH
bye,
Sumit
root@ldapclient:/home/sysop# openssl s_client -connect 10.8.8.60:636
CONNECTED(00000003)
Can't use SSL_get_servername
depth=1 CN = CompanyInternal
verify return:1
depth=0 O = CompanyInternal, CN = ldapserver00.clab.lab
verify return:1
---
Certificate chain
0 s:O = CompanyInternal, CN = ldapserver00.clab.lab
i:CN = CompanyInternal
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA384
v:NotBefore: Nov 1 22:06:32 2022 GMT; NotAfter: Oct 29 22:06:32 2032 GMT
1 s:CN = CompanyInternal
i:CN = CompanyInternal
a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA384
v:NotBefore: Nov 1 22:04:14 2022 GMT; NotAfter: Oct 29 22:04:14 2032 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIERzCCAi+gAwIBAgIUN7zSoFEoRKwSie9d3DoobHH60x4wDQYJKoZIhvcNAQEM
BQAwEjEQMA4GA1UEAxMHQmlvVGVhbTAeFw0yMjExMDEyMjA2MzJaFw0zMjEwMjky
MjA2MzJaMDIxEDAOBgNVBAoTB0Jpb1RlYW0xHjAcBgNVBAMTFWxkYXBzZXJ2ZXIw
MC5jbGFiLmxhYjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKBtDPgT
e8wr/sxg+oUiMDvyuROnxEMDvF8LRwhQianBxqQuwuZulvVLXBgWyVRyNjInUDXU
q1Hbf2JVXVkMufO/VjRIlF4lRPC/sgu1srxUdRvddBEO9t8inAMlJ0dvGOaZBwS7
fKK3+YeIRSleRbXS6ta2shvwxrDTWhiEPL4dgdeD+7J9ll4cbbuHW0YZJvlRJ9xD
VHy70qcZn6ZyDXQt83Mbf78RLioK78S0dKW6eOACKHHSexIGcP8bZOX43XTZJHME
Y7jFSBaMVF+pa0eRj6pTA6U2sFg4puWC1Xkt++1Wpnq9YdB9CqOII3UvdlPVoOHH
oGQ6CmDmIR908kUCAwEAAaN1MHMwDAYDVR0TAQH/BAIwADATBgNVHSUEDDAKBggr
BgEFBQcDATAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0OBBYEFHKk9dZu3nxATWKqJlXK
0ekuoRfkMB8GA1UdIwQYMBaAFCTD8jhauoaHVQBgCHanPoW83kRxMA0GCSqGSIb3
DQEBDAUAA4ICAQCUA72TzDR5evZpTbZAoxZ4O3Xr+gKphB7HHQ4BNZ+zW/AV/rEW
DLTnm3XQ+KPp/1jb1uSsKGqLqQ462rzzYQ5SU98/GxZM8xRxWyTq+wjLFcaUZ93V
HVSm38Y77aK+uhw2qpiMeiKzW/M4UwUYQM4trKMSzBiQz46UPKkzihL5JR/TCcKj
LrT+OhYcbIDfdnf0+jvB75eiWiQXrsX1B0VRVnFR4FqJSH8kD71OLWno9UlTpmWB
xkDrWTW5xJAb+lJT12PRRg8cMRg/GtQSIo8PAPdrm/D6aBQsRtGm8KvIleBgo5FR
htlMVzNyfq35ck8WhjyMQBwegJEbMBDSpYootdNrs5sOtv+CA6qDH6CsatYKr/ke
bu3s167q0x/RAAROcdA6+7eMyrrVyZjv4tqPzfYdLvOg6o7m3kBy1BL56flbd+je
wX4RJvNoQKGrZxKRsfKgS7cJCo3QEoV/RbOzTof3QZ4G+lLE15lI9v9Ad6aaX+Gt
oLHAqxIE1Wld/fmBTBgLL9K5NFfvfINczNLJw/+X3f6e6IjQgT743oJZ4BaNyGn6
3YT5EgDAz5hgM4BhOMovUBVgcFsUdZkH3dHrX9OrdgmP737IXlp7tuo8/J0DMPgr
e2I0qGBqCu03PBYl8G4iwF/7UKFy6cyB1srefQPoVQ0//iPQIB5p6LOhUQ==
-----END CERTIFICATE-----
subject=O = CompanyInternal, CN = ldapserver00.clab.lab
issuer=CN = CompanyInternal
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2932 bytes and written 373 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: 21BBA066E20DCEE0C99DA1EF0EA17A9F474DCB10993529D776A053A32EEDB728
Session-ID-ctx:
Resumption PSK:
6AC936C1645C80A5DDE93B179632FE59A4AEB15D3E3876B4385C01F769087C6D409E818BE582E550B3261CEED468423B
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - 60 81 05 60 76 ea 36 36-e4 97 99 63 43 38 8a 2b `..`v.66...cC8.+
0010 - 24 95 56 e5 af 76 a6 d2-60 82 fa d4 72 91 53 b5 $.V..v..`...r.S.
0020 - 4e fc 0d 13 b8 52 97 2a-40 13 83 7d cf 3f 51 aa N....R.*@..}.?Q.
0030 - 96 f5 76 ca 14 c1 e7 e4-1d b7 39 53 d9 ee 19 89 ..v.......9S....
0040 - fd eb e0 d9 9f 8d 33 3b-97 cd 1d 0d 8c a4 f4 f4 ......3;........
0050 - 6f ab c2 49 59 b4 1c 67-78 b9 4c 93 03 2d 5c ff o..IY..gx.L..-\.
0060 - a9 19 c8 36 a8 23 1b 3c-45 5e 6e 69 f7 8c c4 bb ...6.#.<E^ni....
0070 - d9 d2 a9 86 92 f0 98 94-68 aa eb f2 18 ab ef 59 ........h......Y
0080 - 55 96 43 ad 64 06 26 93-c1 41 8c 2b ce db bb fa U.C.d.&..A.+....
0090 - 9d 9f b3 71 fe cc ec d1-f5 e0 02 a8 70 b9 10 3c ...q........p..<
00a0 - 42 32 60 d4 ac 94 ce 76-89 3a 0e 6c 95 43 22 e4 B2`....v.:.l.C".
00b0 - 89 a4 11 a9 24 a3 9a b4-3e 85 ee bb 1f 07 2f e0 ....$...>...../.
00c0 - bf 45 a2 2e 78 a4 51 9f-34 0e e4 87 a8 b4 c3 2a .E..x.Q.4......*
Start Time: 1670399902
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: BBCD67A75D02D4E8A29FC1BC72AF66A58F589AABA8DCF321B809AEDC2F1100EE
Session-ID-ctx:
Resumption PSK:
2B9BBE1D73BEA62DBB0CDAFE6D25B09FB69F9D53DB02645AA889674CA7D28FF66C8D025F5ECE2015EE228AB9C1A178E9
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - 60 81 05 60 76 ea 36 36-e4 97 99 63 43 38 8a 2b `..`v.66...cC8.+
0010 - 82 ee b5 24 8c 46 a1 ce-81 14 07 fa 50 57 67 78 ...$.F......PWgx
0020 - da 6a b0 d8 df 43 d8 fd-74 67 13 61 37 36 e5 ab .j...C..tg.a76..
0030 - cd 3d 32 95 95 55 a0 47-f1 d8 4a 7c 27 aa 64 7d .=2..U.G..J|'.d}
0040 - 26 0d 60 8e 29 9c a9 40-6d 6f 59 c1 ab 6a e3 d4 &.`.)..@moY..j..
0050 - cb cb 96 05 51 46 48 f8-6b 67 53 10 47 30 36 24 ....QFH.kgS.G06$
0060 - f4 ea 62 f7 ac dc 64 b9-10 4e 62 17 75 3a 55 c9 ..b...d..Nb.u:U.
0070 - 73 98 41 c6 68 6e ee b9-62 e5 19 71 a1 df 05 62 s.A.hn..b..q...b
0080 - 7d 1a 30 dc 46 77 b3 c6-5b b6 fa 4f 2f 34 31 fa }.0.Fw..[..O/41.
0090 - bf 1e 9e 26 b8 ff 95 d3-69 7b de c3 91 34 06 6a ...&....i{...4.j
00a0 - 9e 2c ee 36 08 9f db 1f-28 44 ef 21 07 74 a8 9b .,.6....(D.!.t..
00b0 - bd 55 f6 8b cb 11 bb 5f-7f 71 ba eb 15 1e 1e 70 .U....._.q.....p
00c0 - 36 3e 9d ce 42 2c 60 6d-d0 7f de 60 4a a9 80 da 6>..B,`m...`J...
Start Time: 1670399902
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
^-- it stops there. I understand hanging and waiting for further communication is normal
behavior , but I don't think this is where it's supposed to stop.
Obviously, CentOS 7 with its older version of SSL has no trouble connecting. One
difference is that on CentOS 7 it says "Secure Renegotiation IS supported."
TIA for any help.
Thanks,
Jarett
> On Dec 7, 2022, at 12:50 AM, Sumit Bose <sbose(a)redhat.com> wrote:
>
> Am Tue, Dec 06, 2022 at 05:14:34PM -0600 schrieb Jarett DeAngelis:
>> Hi,
>>
>> I am trying to get SSSD to authenticate against an OpenLDAP directory. I have
"debug_level" turned up to 10 but have not been able to figure out what the
problem is based on the log.
>>
>> On an Ubuntu 22.04 system I have found that something with TLS is broken when it
tries to connect to OpenLDAP, which is why it has failed on that system -- I think this is
related to the OS moving to OpenSSL 3 but have not been able to figure out how to fix it.
>>
>> On this CentOS 7 system, you can see that it can find the user, can get
properties from the user, but still fails the user login without, as far as I can tell,
explaining why.
>>
>> I have pasted our sssd.conf below, and here is a link to my Nextcloud instance
where I am hosting the relevant portion of the log (it was too big for me to be able to
paste it into Pastebin): https://checkwithscience.com/index.php/s/e7mXKAzcq87q6HD
<https://checkwithscience.com/index.php/s/e7mXKAzcq87q6HD><https://c...
<https://checkwithscience.com/index.php/s/e7mXKAzcq87q6HD>>
>
> Hi,
>
> there is no authentication attempt covered in the log file. Are you sure
> pam_sss.so is included in your PAM configuration and called for the
> specific user?
>
> bye,
> Sumit
>
>>
>> Hoping someone can help us get to the bottom of this.
>>
>> Thanks.
>>
>> Here is our sssd.conf:
>>
>> [sssd]
>> services = nss, pam
>> config_file_version = 2
>> domains = default
>> certificate_verification = no_verification
>>
>> [nss]
>>
>> [pam]
>> offline_credentials_expiration = 60
>>
>> [domain/default]
>> debug_level = 10
>> ldap_id_use_start_tls = False
>> cache_credentials = True
>> ldap_search_base = ou=users,dc=clab,dc=lab
>> id_provider = ldap
>> auth_provider = ldap
>> chpass_provider = ldap
>> access_provider = ldap
>> ldap_uri = ldaps://10.8.8.60:636
>> ldap_default_bind_dn = cn=admin,dc=clab,dc=lab
>> ldap_default_authtok = definitelyverysecurepassword
>> ldap_tls_reqcert = allow
>> ldap_tls_cacert = /usr/local/share/ca-certificates/mycacert.crt
>> ldap_tls_cacertdir = /usr/local/share/ca-certificates
>> ldap_tls_cert = /etc/ldap/ldapserver00_slapd_cert.pem
>> certificate_verification = no_verification
>> ldap_search_timeout = 50
>> ldap_network_timeout = 60
>> ldap_access_order = filter
>> ldap_access_filter = (objectClass=posixAccount)
>> override_homedir = /home/%U
>> override_shell = /bin/bash
>> ldap_user_name = uid
>> auto_private_groups = true
>> sudo_provider = none
>> ldap_account_expire_policy = nds
>> ldap_passwd_policy = shadow
>
>> _______________________________________________
>> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
<mailto:sssd-users@lists.fedorahosted.org>
>> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
<mailto:sssd-users-leave@lists.fedorahosted.org>
>> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
<https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
<https://fedoraproject.org/wiki/Mailing_list_guidelines>
>> List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
<https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
>> Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
<https://pagure.io/fedora-infrastructure/new_issue>
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
<mailto:sssd-users@lists.fedorahosted.org>
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
<mailto:sssd-users-leave@lists.fedorahosted.org>
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
<https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
<https://fedoraproject.org/wiki/Mailing_list_guidelines>
> List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
<https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
<https://pagure.io/fedora-infrastructure/new_issue>
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
8:39 a.m.
New subject: CentOS 7, SSSD against LDAP: finds user but will not log them in, "Authentication failure" when trying to su
Off the top, the LDAP server can not resolve in DNS, so it's setting the LDAP server
name to the IP, the IP is not in your cert as a SAN that I can see.
On 12/07/2022 12:10 AM Jarett DeAngelis
<starkruzr(a)gmail.com> wrote:
Hi Sumit,
Thank you! You made me realize I never updated PAM using authconfig. `sudo authconfig
--enablesssdauth --enablesssd --updateall --enablemkhomedir` took care of it.
Do you have any insights as to what is going on with the newer (Ubuntu 22.04)
machine's attempts to authenticate? SSSD logs are pretty clear that there is an
"unknown error" with TLS communication despite the OpenLDAP server appearing to
communicate normally -- OpenSSL 3.0 freezes, basically, while trying to connect, as seen
here:
(2022-12-07 7:17:24): [be[default]] [check_if_online_delayed] (0x2000): [RID#1010]
Trying to go back online!
(2022-12-07 7:17:24): [be[default]] [fo_reset_services] (0x1000): [RID#1010]
Resetting all servers in all services
(2022-12-07 7:17:24): [be[default]] [set_server_common_status] (0x0100): [RID#1010]
Marking server '10.8.8.60' as 'name not resolved'
(2022-12-07 7:17:24): [be[default]] [fo_set_port_status] (0x0100): [RID#1010]
Marking port 636 of server '10.8.8.60' as 'neutral'
(2022-12-07 7:17:24): [be[default]] [fo_set_port_status] (0x0400): [RID#1010]
Marking port 636 of duplicate server '10.8.8.60' as 'neutral'
(2022-12-07 7:17:24): [be[default]] [dp_attach_req] (0x0400): [RID#1011] DP Request
[Online Check #1011]: REQ_TRACE: New request. Flags [0000].
(2022-12-07 7:17:24): [be[default]] [dp_attach_req] (0x0400): [RID#1011] Number of
active DP request: 1
(2022-12-07 7:17:24): [be[default]] [fo_resolve_service_send] (0x0100): [RID#1011]
Trying to resolve service 'LDAP'
(2022-12-07 7:17:24): [be[default]] [get_server_status] (0x1000): [RID#1011] Status
of server '10.8.8.60' is 'name not resolved'
(2022-12-07 7:17:24): [be[default]] [get_port_status] (0x1000): [RID#1011] Port
status of port 636 for server '10.8.8.60' is 'neutral'
(2022-12-07 7:17:24): [be[default]] [fo_resolve_service_activate_timeout] (0x2000):
[RID#1011] Resolve timeout [dns_resolver_timeout] set to 6 seconds
(2022-12-07 7:17:24): [be[default]] [get_server_status] (0x1000): [RID#1011] Status
of server '10.8.8.60' is 'name not resolved'
(2022-12-07 7:17:24): [be[default]] [set_server_common_status] (0x0100): [RID#1011]
Marking server '10.8.8.60' as 'resolving name'
(2022-12-07 7:17:24): [be[default]] [check_if_online_delayed] (0x2000): [RID#1010]
Check online req created.
(2022-12-07 7:17:24): [be[default]] [set_server_common_status] (0x0100): [RID#1011]
Marking server '10.8.8.60' as 'name resolved'
(2022-12-07 7:17:24): [be[default]] [be_resolve_server_process] (0x1000): [RID#1011]
Saving the first resolved server
(2022-12-07 7:17:24): [be[default]] [be_resolve_server_process] (0x0200): [RID#1011]
Found address for server 10.8.8.60: [10.8.8.60] TTL 7200
(2022-12-07 7:17:24): [be[default]] [sdap_uri_callback] (0x0400): [RID#1011]
Constructed uri 'ldaps://10.8.8.60:636'
(2022-12-07 7:17:24): [be[default]] [sssd_async_socket_init_send] (0x4000):
[RID#1011] Using file descriptor [21] for the connection.
(2022-12-07 7:17:24): [be[default]] [sssd_async_socket_init_send] (0x0400):
[RID#1011] Setting 60 seconds timeout [ldap_network_timeout] for connecting
(2022-12-07 7:17:24): [be[default]] [sss_ldap_init_sys_connect_done] (0x0020):
[RID#1011] ldap_install_tls failed: [Connect error] [unknown error]
(2022-12-07 7:17:24): [be[default]] [sss_ldap_init_state_destructor] (0x0400):
[RID#1011] calling ldap_unbind_ext for ldap:[0x560819ad2470] sd:[21]
(2022-12-07 7:17:24): [be[default]] [sss_ldap_init_state_destructor] (0x0400):
[RID#1011] closing socket [21]
(2022-12-07 7:17:24): [be[default]] [sdap_sys_connect_done] (0x0020): [RID#1011]
sdap_async_connect_call request failed: [5]: Input/output error.
(2022-12-07 7:17:24): [be[default]] [sdap_handle_release] (0x2000): [RID#1011]
Trace: sh[0x560819af04f0], connected[0], ops[(nil)], ldap[(nil)], destructor_lock[0],
release_memory[0]
(2022-12-07 7:17:24): [be[default]] [_be_fo_set_port_status] (0x8000): [RID#1011]
Setting status: PORT_NOT_WORKING. Called from:
../src/providers/ldap/sdap_async_connection.c: sdap_cli_connect_done: 1633
(2022-12-07 7:17:24): [be[default]] [fo_set_port_status] (0x0100): [RID#1011]
Marking port 636 of server '10.8.8.60' as 'not working'
If you look at it with `openssl s_client`, it freezes right here:
root@ldapclient:/home/sysop# openssl s_client -connect 10.8.8.60:636
CONNECTED(00000003)
Can't use SSL_get_servername
depth=1 CN = CompanyInternal
verify return:1
depth=0 O = CompanyInternal, CN = ldapserver00.clab.lab
verify return:1
---
Certificate chain
0 s:O = CompanyInternal, CN = ldapserver00.clab.lab
i:CN = CompanyInternal
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA384
v:NotBefore: Nov 1 22:06:32 2022 GMT; NotAfter: Oct 29 22:06:32 2032 GMT
1 s:CN = CompanyInternal
i:CN = CompanyInternal
a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA384
v:NotBefore: Nov 1 22:04:14 2022 GMT; NotAfter: Oct 29 22:04:14 2032 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIERzCCAi+gAwIBAgIUN7zSoFEoRKwSie9d3DoobHH60x4wDQYJKoZIhvcNAQEM
BQAwEjEQMA4GA1UEAxMHQmlvVGVhbTAeFw0yMjExMDEyMjA2MzJaFw0zMjEwMjky
MjA2MzJaMDIxEDAOBgNVBAoTB0Jpb1RlYW0xHjAcBgNVBAMTFWxkYXBzZXJ2ZXIw
MC5jbGFiLmxhYjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKBtDPgT
e8wr/sxg+oUiMDvyuROnxEMDvF8LRwhQianBxqQuwuZulvVLXBgWyVRyNjInUDXU
q1Hbf2JVXVkMufO/VjRIlF4lRPC/sgu1srxUdRvddBEO9t8inAMlJ0dvGOaZBwS7
fKK3+YeIRSleRbXS6ta2shvwxrDTWhiEPL4dgdeD+7J9ll4cbbuHW0YZJvlRJ9xD
VHy70qcZn6ZyDXQt83Mbf78RLioK78S0dKW6eOACKHHSexIGcP8bZOX43XTZJHME
Y7jFSBaMVF+pa0eRj6pTA6U2sFg4puWC1Xkt++1Wpnq9YdB9CqOII3UvdlPVoOHH
oGQ6CmDmIR908kUCAwEAAaN1MHMwDAYDVR0TAQH/BAIwADATBgNVHSUEDDAKBggr
BgEFBQcDATAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0OBBYEFHKk9dZu3nxATWKqJlXK
0ekuoRfkMB8GA1UdIwQYMBaAFCTD8jhauoaHVQBgCHanPoW83kRxMA0GCSqGSIb3
DQEBDAUAA4ICAQCUA72TzDR5evZpTbZAoxZ4O3Xr+gKphB7HHQ4BNZ+zW/AV/rEW
DLTnm3XQ+KPp/1jb1uSsKGqLqQ462rzzYQ5SU98/GxZM8xRxWyTq+wjLFcaUZ93V
HVSm38Y77aK+uhw2qpiMeiKzW/M4UwUYQM4trKMSzBiQz46UPKkzihL5JR/TCcKj
LrT+OhYcbIDfdnf0+jvB75eiWiQXrsX1B0VRVnFR4FqJSH8kD71OLWno9UlTpmWB
xkDrWTW5xJAb+lJT12PRRg8cMRg/GtQSIo8PAPdrm/D6aBQsRtGm8KvIleBgo5FR
htlMVzNyfq35ck8WhjyMQBwegJEbMBDSpYootdNrs5sOtv+CA6qDH6CsatYKr/ke
bu3s167q0x/RAAROcdA6+7eMyrrVyZjv4tqPzfYdLvOg6o7m3kBy1BL56flbd+je
wX4RJvNoQKGrZxKRsfKgS7cJCo3QEoV/RbOzTof3QZ4G+lLE15lI9v9Ad6aaX+Gt
oLHAqxIE1Wld/fmBTBgLL9K5NFfvfINczNLJw/+X3f6e6IjQgT743oJZ4BaNyGn6
3YT5EgDAz5hgM4BhOMovUBVgcFsUdZkH3dHrX9OrdgmP737IXlp7tuo8/J0DMPgr
e2I0qGBqCu03PBYl8G4iwF/7UKFy6cyB1srefQPoVQ0//iPQIB5p6LOhUQ==
-----END CERTIFICATE-----
subject=O = CompanyInternal, CN = ldapserver00.clab.lab
issuer=CN = CompanyInternal
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2932 bytes and written 373 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: 21BBA066E20DCEE0C99DA1EF0EA17A9F474DCB10993529D776A053A32EEDB728
Session-ID-ctx:
Resumption PSK:
6AC936C1645C80A5DDE93B179632FE59A4AEB15D3E3876B4385C01F769087C6D409E818BE582E550B3261CEED468423B
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - 60 81 05 60 76 ea 36 36-e4 97 99 63 43 38 8a 2b `..`v.66...cC8.+
0010 - 24 95 56 e5 af 76 a6 d2-60 82 fa d4 72 91 53 b5 $.V..v..`...r.S.
0020 - 4e fc 0d 13 b8 52 97 2a-40 13 83 7d cf 3f 51 aa N....R.*@..}.?Q.
0030 - 96 f5 76 ca 14 c1 e7 e4-1d b7 39 53 d9 ee 19 89 ..v.......9S....
0040 - fd eb e0 d9 9f 8d 33 3b-97 cd 1d 0d 8c a4 f4 f4 ......3;........
0050 - 6f ab c2 49 59 b4 1c 67-78 b9 4c 93 03 2d 5c ff o..IY..gx.L..-\.
0060 - a9 19 c8 36 a8 23 1b 3c-45 5e 6e 69 f7 8c c4 bb ...6.#.<E^ni....
0070 - d9 d2 a9 86 92 f0 98 94-68 aa eb f2 18 ab ef 59 ........h......Y
0080 - 55 96 43 ad 64 06 26 93-c1 41 8c 2b ce db bb fa U.C.d.&..A.+....
0090 - 9d 9f b3 71 fe cc ec d1-f5 e0 02 a8 70 b9 10 3c ...q........p..<
00a0 - 42 32 60 d4 ac 94 ce 76-89 3a 0e 6c 95 43 22 e4 B2`....v.:.l.C".
00b0 - 89 a4 11 a9 24 a3 9a b4-3e 85 ee bb 1f 07 2f e0 ....$...>...../.
00c0 - bf 45 a2 2e 78 a4 51 9f-34 0e e4 87 a8 b4 c3 2a .E..x.Q.4......*
Start Time: 1670399902
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: BBCD67A75D02D4E8A29FC1BC72AF66A58F589AABA8DCF321B809AEDC2F1100EE
Session-ID-ctx:
Resumption PSK:
2B9BBE1D73BEA62DBB0CDAFE6D25B09FB69F9D53DB02645AA889674CA7D28FF66C8D025F5ECE2015EE228AB9C1A178E9
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - 60 81 05 60 76 ea 36 36-e4 97 99 63 43 38 8a 2b `..`v.66...cC8.+
0010 - 82 ee b5 24 8c 46 a1 ce-81 14 07 fa 50 57 67 78 ...$.F......PWgx
0020 - da 6a b0 d8 df 43 d8 fd-74 67 13 61 37 36 e5 ab .j...C..tg.a76..
0030 - cd 3d 32 95 95 55 a0 47-f1 d8 4a 7c 27 aa 64 7d .=2..U.G..J|'.d}
0040 - 26 0d 60 8e 29 9c a9 40-6d 6f 59 c1 ab 6a e3 d4 &.`.)..@moY..j..
0050 - cb cb 96 05 51 46 48 f8-6b 67 53 10 47 30 36 24 ....QFH.kgS.G06$
0060 - f4 ea 62 f7 ac dc 64 b9-10 4e 62 17 75 3a 55 c9 ..b...d..Nb.u:U.
0070 - 73 98 41 c6 68 6e ee b9-62 e5 19 71 a1 df 05 62 s.A.hn..b..q...b
0080 - 7d 1a 30 dc 46 77 b3 c6-5b b6 fa 4f 2f 34 31 fa }.0.Fw..[..O/41.
0090 - bf 1e 9e 26 b8 ff 95 d3-69 7b de c3 91 34 06 6a ...&....i{...4.j
00a0 - 9e 2c ee 36 08 9f db 1f-28 44 ef 21 07 74 a8 9b .,.6....(D.!.t..
00b0 - bd 55 f6 8b cb 11 bb 5f-7f 71 ba eb 15 1e 1e 70 .U....._.q.....p
00c0 - 36 3e 9d ce 42 2c 60 6d-d0 7f de 60 4a a9 80 da 6>..B,`m...`J...
Start Time: 1670399902
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
^-- it stops there. I understand hanging and waiting for further communication is
normal behavior , but I don't think this is where it's supposed to stop.
Obviously, CentOS 7 with its older version of SSL has no trouble connecting. One
difference is that on CentOS 7 it says "Secure Renegotiation IS supported."
TIA for any help.
Thanks,
Jarett
> > On Dec 7, 2022, at 12:50 AM, Sumit Bose <sbose(a)redhat.com
mailto:sbose@redhat.com > wrote:
>
> Am Tue, Dec 06, 2022 at 05:14:34PM -0600 schrieb Jarett DeAngelis:
>
> > > > Hi,
> >
> > I am trying to get SSSD to authenticate against an OpenLDAP
directory. I have "debug_level" turned up to 10 but have not been able to figure
out what the problem is based on the log.
> >
> > On an Ubuntu 22.04 system I have found that something with TLS is
broken when it tries to connect to OpenLDAP, which is why it has failed on that system --
I think this is related to the OS moving to OpenSSL 3 but have not been able to figure out
how to fix it.
> >
> > On this CentOS 7 system, you can see that it can find the user, can
get properties from the user, but still fails the user login without, as far as I can
tell, explaining why.
> >
> > I have pasted our sssd.conf below, and here is a link to my
Nextcloud instance where I am hosting the relevant portion of the log (it was too big for
me to be able to paste it into Pastebin):
https://checkwithscience.com/index.php/s/e7mXKAzcq87q6HD<https://check...
> >
> > > > Hi,
>
> there is no authentication attempt covered in the log file. Are you sure
> pam_sss.so is included in your PAM configuration and called for the
> specific user?
>
> bye,
> Sumit
>
>
> > > > Hoping someone can help us get to the bottom
of this.
> >
> > Thanks.
> >
> > Here is our sssd.conf:
> >
> > [sssd]
> > services = nss, pam
> > config_file_version = 2
> > domains = default
> > certificate_verification = no_verification
> >
> > [nss]
> >
> > [pam]
> > offline_credentials_expiration = 60
> >
> > [domain/default]
> > debug_level = 10
> > ldap_id_use_start_tls = False
> > cache_credentials = True
> > ldap_search_base = ou=users,dc=clab,dc=lab
> > id_provider = ldap
> > auth_provider = ldap
> > chpass_provider = ldap
> > access_provider = ldap
> > ldap_uri = ldaps://10.8.8.60:636
> > ldap_default_bind_dn = cn=admin,dc=clab,dc=lab
> > ldap_default_authtok = definitelyverysecurepassword
> > ldap_tls_reqcert = allow
> > ldap_tls_cacert = /usr/local/share/ca-certificates/mycacert.crt
> > ldap_tls_cacertdir = /usr/local/share/ca-certificates
> > ldap_tls_cert = /etc/ldap/ldapserver00_slapd_cert.pem
> > certificate_verification = no_verification
> > ldap_search_timeout = 50
> > ldap_network_timeout = 60
> > ldap_access_order = filter
> > ldap_access_filter = (objectClass=posixAccount)
> > override_homedir = /home/%U
> > override_shell = /bin/bash
> > ldap_user_name = uid
> > auto_private_groups = true
> > sudo_provider = none
> > ldap_account_expire_policy = nds
> > ldap_passwd_policy = shadow
> >
> > > >
> > > > _______________________________________________
> > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
mailto:sssd-users@lists.fedorahosted.org
> > To unsubscribe send an email to
sssd-users-leave(a)lists.fedorahosted.org mailto:sssd-users-leave@lists.fedorahosted.org
> > Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
> > Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
> >
> > > > _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
mailto:sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
mailto:sssd-users-leave@lists.fedorahosted.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
> Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
>
> >
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
506
days inactive
507
days old
sssd-users@lists.fedorahosted.org
4 comments
3 participants
participants (3)
-
Jarett DeAngelis -
patrick.hush＠comcast.net -
Sumit Bose