[icingaweb2 uses SHA] OpenLDAP Authentication config successful, but unable to login

This forum was archived to /woltlab and is now in read-only mode.
  • It's able to connect to the ldap server and read the groups and users, however, after finishing with the wizard, you're not able to log in



  • Anything in the logs of ldap server and icingaweb2?

    I had to figure out how to enable logging. slapd logging is set to "olcLogLevel: stats"


    I'll have to find the icingaweb2 logs, which isn't anywhere to be found, and syslog is empty, so I'm thinking I need to edit rsyslog.conf the same way I had to do for slapd


    Logging in with "eric":


    Logging in with "uid=eric,ou=people,dc=icinga":

  • Anything in the logs of ldap server and icingaweb2?

    /var/log/icinga2/icinga2.log:

  • Warning: i do not know openldap at all; the below may be complete bullshit.

    Jul 28 00:19:26 ldap slapd[967]: conn=1033 op=3 BIND dn="uid=eric,ou=people,dc=icinga" method=128
    Jul 28 00:19:26 ldap slapd[967]: conn=1033 op=3 RESULT tag=97 err=49 text=

    From the above, we can say that username = eric is the way to go (because the DN is correct only in that case).

    From http://www.openldap.org/lists/…ical/201010/msg00279.html , we can tell

    that the password is wrong as we already *know* that the DN is fine (referring to the provided screenshot of user 'eric').


    So, slapd gets the request but refuses to authenticate, not icingaweb2.


    From the screenshot refered above, we see that the password is set as a SHA-512 hash.

    For me, it seems that this might be a problem with how icingaweb2 provides the password.


    It may be helpfull to authenticate using the commandline tools first, as described in post 2 of that thread:

    https://serverfault.com/questi…ldap-via-the-command-line

  • You're right, as it looks wrong with the full DN ("uid=uid=eric,ou=people,dc=icinga")


    That's a great catch with how the password would be sent from icingaweb2, as I haven't tried how the password would be hashed, I assumed it was polished enough to handle all cases


    I suppose I could try to find the part of the code that handles the ldap password


    If ldap is saying it's getting the wrong password, I think it's safe to say icingaweb2 isn't completely off the hook. As you said, icingaweb2 is probably giving the wrong password to ldap

  • Warning: i do not know openldap at all; the below may be complete bullshit.

    Hahah there are so many versions of versions of services, no one really knows all of them


    Also, with ldap, I had to set the rsyslog.conf to also configure it for "local4.*". I'm not getting any icingaweb2 logs, where would it's logs be? All I could find are icinga2 logs, and apache2 logs

  • Hahah there are so many versions of versions of services, no one really knows all of them


    Also, with ldap, I had to set the rsyslog.conf to also configure it for "local4.*". I'm not getting any icingaweb2 logs, where would it's logs be? All I could find are icinga2 logs, and apache2 logs

    Should be normal go to syslog

  • I'm not getting any icingaweb2 logs, where would it's logs be

    As icingaweb2 is running from the webserver, you need to read the apache / httpd ) logfiles, in special these regarding php.

    The post was edited 1 time, last by sru ().

  • be aware that if you run php-fpm, php errors will not show in those logs, you have to enable those logs seperately in the pool configuration.

    Linux is dead, long live Linux


    Remember to NEVER EVER use git repositories in a productive environment if you CAN NOT control them

  • Guys, icingaweb2 uses SHA-1 for password hashing

    Not sure about that:


  • Not sure about that:


    Changing to a SHA hashed password, authentication works. I'm still digging to see what part of icingaweb2 relates to ldap authentication



  • As icingaweb2 is running from the webserver, you need to read the apache / httpd ) logfiles, in special these regarding php.

    Even though when setting up icingaweb2 it asks you to specify logging type and logging level? From the looks of the configuration wizard, I would think it would be logged to syslog, but /var/log/syslog remains zero bytes


  • Not sure why it does not log to syslog, then.

    My RHEL Machine logs to the file messages.

    My debian logs to te file syslog.

  • Not sure why it does not log to syslog, then.

    My RHEL Machine logs to the file messages.

    My debian logs to te file syslog.

    I'm running it in a Ubuntu LXC image, could be maybe why. And the ldap container didn't start logging unless I had "local4.* /var/log/ldap.log" added to /etc/rsyslog.conf