Welcome to the Linux Foundation Forum!

Lab 29.3: monitor decrypted LDAP stream with WireShark

albiurs
albiurs Posts: 51
in LFS207 Class Forum

Hi,

I followed all the steps in Lab 29.3 until step 10, where the line

ldap_tls_reqcert = never

in the file /etc/sssd/sssd.conf should cause the stream to be decrypted.

Firstly, this file doesn't exist on my Ubuntu system, I guess this is a typo. So I edited the file:
/etc/sssd/conf.d/00-sssd.conf

Which was previously edited in step 2 of the Lab. I guess, this is the right one, isn't it?

Further after restarting the serviece with systemctl restart sssd, the ldap stream is still encrypted and I see lots of TLS packages.

So I don't know if I did not understand the point of this exercise or there is something wrong with my configuration. Am I right that the ldap data stream should NOT be encryptd and I should see somewhere the login process with username and password in clear text?

Thanks,
Urs

Answers

  • luisviveropena
    luisviveropena Posts: 1,347

    Hi Urs,

    in the file /etc/sssd/sssd.conf should cause the stream to be decrypted.

    That configuration file is for Red Hat based systems.

    Firstly, this file doesn't exist on my Ubuntu system, I guess this is a typo. So I edited the file:
    /etc/sssd/conf.d/00-sssd.conf

    Yes, that's the one for Debian and Ubuntu systems.

    Further after restarting the serviece with systemctl restart sssd, the ldap stream is still encrypted and I >see lots of TLS packages.

    >

    So I don't know if I did not understand the point of this exercise or there is something wrong with my >configuration. Am I right that the ldap data stream should NOT be encryptd and I should see >somewhere the login process with username and password in clear text?

    Yes, the idea is that you could see data about the user.

    Are you sure that the service sssd was restarted? Perhaps you can stop the service, check on the status of it and start ir again. If there is any issue, you could find something in the system log file /var/log/syslog .

    Regards,
    Luis.

  • albiurs
    albiurs Posts: 51
    edited December 2024

    Hi Luis,

    Thanks.

    After configuration I rebooted the system. This what it looks like:

    root@ubuntu-dt-vm:~# cat /etc/sssd/conf.d/00-sssd.conf 
[sssd]
config_file_version = 2
domains = example.com
services = nss, pam,autofs
[domain/example.com]
enumerate = true
id_provider = ldap
autofs_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_uri = ldap://192.168.122.11/
ldap_search_base = dc=example,dc=com
ldap_id_use_start_tls = true
cache_credentials = True
ldap_tls_reqcert = never
root@ubuntu-dt-vm:~# 
root@ubuntu-dt-vm:~# 
root@ubuntu-dt-vm:~# getent passwd luser1
luser1:*:999001:999001:luser1:/home/users/luser1:
root@ubuntu-dt-vm:~# 
root@ubuntu-dt-vm:~# 
root@ubuntu-dt-vm:~# ssh luser1@localhost
luser1@localhost's password: 
Welcome to Ubuntu 24.04.1 LTS (GNU/Linux 6.8.0-48-generic x86_64)

[...]

    And that is what it looks like in termshark during the ssh login. There are only 2 LDAP packages visible. The LDAP_START_TLS_OID suggest that TLS is used for authentication:

    After/below the two LDAP packages, everything is TCP or TLSv1.3. I guess this is the actual SSH communication stream, which of course is encrypted:

    So it looks as if anything is encrypted even though "ldap_tls_reqcert = never" is in the file /etc/sssd/conf.d/00-sssd.conf, even after a reboot.

    What could be the reason?

    Thanks,
    Urs

  • luisviveropena
    luisviveropena Posts: 1,347

    Hi Urs,

    It took me some time but I was able to reproduce the environment and the "issue". So it's true that some data will be encrypted even if we are instructing the system not to. Anyway I was able to see some sensible data, as the DN for the user, the home directory, the uid and gid.

    So, I found these data with a simpler filter: tcp port 389 , then look for "searchResEntry" and the DN "cn=luser1,dc=example,dc=com".

    We are going to review this item of the lab and will update it.

    Regards,
    Luis.

  • albiurs
    albiurs Posts: 51
    edited December 2024

    Hi Luis,

    Thanks.

    Displaying the ldapsearch command with WireShark is the last step of Lab 29.2 and happens before setting "ldap_tls_reqcert = never" in the /etc/sssd/conf.d/00-sssd.conf . So, the ldapsearch communication is already in plaintext even before changing 00-sssd.conf file.

    Although, my post here is about Lab 29.3.
    As I understand it, the decrypted authentication should be captured by Wireshark during the ssh login to localhost (ssh luser1@localhost), whereas the authentication will be sent to the LDAP server over the network. While the above ldapsearch is transmitted in plaintext, the initiation of the LDAP authentication starts with the LDAP_START_TLS_OID and shifts to TLS, while the communication will still be streamed over port 389 - which is intended to be unencrypted. Hence, the authentication credentials cannot be captured by Wireshark that way:

    Please tell me if I'm wrong.

    Thanks,
    Urs

  • luisviveropena
    luisviveropena Posts: 1,347

    Hi Urs,

    I think you are right. I had the same results as you and I saw the same behavior. In other services like ftp is easier to setup and see the credentials, but for some reason openldap is keeping the credentials in a secure way, which is very good in any case.

    As I mentioned before, we are still checking on this lab.

    Regards,
    Luis.

  • albiurs
    albiurs Posts: 51

    Hi Luis,

    Ok, thanks for the update. Then I read the WireSharks output right.

    Regards,
    Urs

Categories

Upcoming Training