How to troubleshoot LDAP authentication?

Icinga Web 2
1

I’ve managed to configure LDAP as ressource and a user backend as well as a user group backend for authentication. Validation for all 3 objects are ok and I’m able to query AD users as well as AD groups via icingaweb2.

Trying to login as AD user (with or without domain) fails though (incorrect username or password). And no entries in the logs even with log level DEBUG.

However, when I login via local user admin I even find something like this in the logs:

Feb 24 05:34:20 icinga icingaweb2[6109]: Issuing LDAP search. Use 'ldapsearch -P 3 -H "ldaps://example.com:636" -D "queryuser@example.com" -W -b "DC=example,DC=com" -s "sub" -z 3 -l 0 -a "never" "(&(objectClass=group)(member=*))" "member" "objectClass"' to reproduce.
Feb 24 05:34:20 icinga icingaweb2[6109]: Ambiguity query returned 3 results

Any hints?

1 Like
2

Hi,

can you show us your resources.ini and authentication.ini configuration (please mask sensitive information)?

Since you mention AD (Active Directory) I assume you are using a Microsoft Active Directory as authentication backend? I remember when I was configuring it in the past that you have to explicitly use msldap as backend type.

Example:

# vim /etc/icingaweb2/authentication.ini

[auth_ad]
backend  = msldap
resource = my_ad

https://icinga.com/docs/icingaweb2/latest/doc/05-Authentication/#active-directory

Which notation did you use? Did you used username@domain.example or DOMAIN\username? If I remember correctly you must use the first one. Hint: Later on when the authentication works you can set a default domain, so you don’t need to type the full domain name every time. Have a look here: Authentication - Icinga Web

Best regards
Michael

3

Yes, it’s Microsoft AD.

# authentication.ini

[example.com]
backend = "ldap"
resource = "example.com"
user_class = "user"
domain = "EXAMPLE"
user_name_attribute = "sAMAccountName"
base_dn = "DC=example,DC=com"
filter = "!(objectClass=computer)"

# resources.ini

[example.com]
type = "ldap"
hostname = "example.com"
port = "636"
encryption = "ldaps"
root_dn = "DC=example,DC=com"
bind_dn = "icinga@example.com"
bind_pw = "***"
timeout = "5"

I’ve also tried it with msldap in authentication.ini.

Maybe my assumption is wrong: We’ve created a dedicated AD group and all their members shall be allowed to login to icingaweb2. Therefore, I’ve created a new role in icingaweb2 having this group in Groups.

4

Hi,

to allow login only for users that are members of specific AD groups, you should use LDAP filter like this:

&(objectClass=user)(|(memberOf:1.2.840.113556.1.4.1941:=<DN of Group1>)(memberOf:1.2.840.113556.1.4.1941:=<DN of Group2>))(!(UserAccountControl:1.2.840.113556.1.4.803:=2))

The numbers used in within filter expression takes care of nested groups and filter out disabled users.

You can additionally use LDAP groups for assigning roles to users, i.e. use a simple filter expression like
CN=IcingaWeb* to get all AD Groups starting with name IcingaWeb.

Cheers
Manfred

1 Like
5

Many thanks for this info, however, it’s still not working.

So I’ve played around as I’m out of ideas: Simply tried different notations and recognized surprisingly results:

user@example.com -> no log entries
user@example -> about 20 log entries
example\user -> about 20 log entries
user -> no log entries

The log entries contain ldapsearch but it don’t includes the password. So I copied this command, executed it manually, entered the password and it worked.

6

This topic made me to configure LDAP/AD authentication for our Icinga Web 2 instance.

I was able to authenticate with the following configuration:

# vim /etc/icingaweb2/resources.ini

[AD]
type = "ldap"
hostname = "server.domain.local"
port = "636"
encryption = "ldaps"
root_dn = "DC=domain,DC=local"
bind_dn = "icinga-ldap-user@domain.local"
bind_pw = "TopSecretPassword"
timeout = "5"

# vim /etc/icingaweb2/authentication.ini

[AD Users]
resource = "AD"
filter = "!(objectClass=computer)"
backend = "msldap"
domain = "DOMAIN"
base_dn = "OU=IT-Service,DC=domain,DC=local"

In the first place I used only LDAP (encryption = "none" and port = "389"), since I had trouble to build up a connection using LDAPS. The CA certificate that signed the LDAPS certificate must be imported on your Linux host in order to establish a connection.

I was able to login using the following credential notation: DOMAIN\username.

Maybe you view the event viewer on your domain controller and have a look there why a request is denied.

Which version of PHP LDAP do you use?

Best regards
Michael

1 Like
7

or just disable certificate validation putting

TLS_REQCERT never

into /etc/ldap/ldap.conf

To me it’s curious that icingaweb2 is issuing ldapsearch with the option W and its man page tells “Prompt for simple authentication. This is used instead of specifying the password on the command line.” So how could that work at all?

@mcktr could you please verify your logs if your ldapsearch looks similar?

8

Ah thanks, wasn’t aware of this option. :+1:

I’ve turned on debug logging into syslog and this the result if I authenticate with a wrong password:

Feb 26 09:10:07 SERVER icingaweb2[58967]: Connect using LDAPS
Feb 26 09:10:07 SERVER icingaweb2[58967]: LDAP query result does not provide the requested field "###"
Feb 26 09:10:07 SERVER icingaweb2[58967]: LDAP query result does not provide the requested field "###"
Feb 26 09:10:07 SERVER icingaweb2[58967]: LDAP query result does not provide the requested field "###"
Feb 26 09:10:07 SERVER icingaweb2[58967]: LDAP query result does not provide the requested field "###"
Feb 26 09:10:07 SERVER icingaweb2[58967]: Capability query discovered the following attributes:
Feb 26 09:10:07 SERVER icingaweb2[58967]:  namingContexts = ["###"]
Feb 26 09:10:07 SERVER icingaweb2[58967]:  defaultNamingContext = ###
Feb 26 09:10:07 SERVER icingaweb2[58967]:  schemaNamingContext = ###
Feb 26 09:10:07 SERVER icingaweb2[58967]:  configurationNamingContext = ###
Feb 26 09:10:07 SERVER icingaweb2[58967]:  supportedControl = [###]
Feb 26 09:10:07 SERVER icingaweb2[58967]:  supportedLDAPVersion = [###]
Feb 26 09:10:07 SERVER icingaweb2[58967]:  supportedSaslMechanisms = [###]
Feb 26 09:10:07 SERVER icingaweb2[58967]:  dnsHostName = servername.domain.local
Feb 26 09:10:07 SERVER icingaweb2[58967]:  supportedCapabilities = [###]
Feb 26 09:10:07 SERVER icingaweb2[58967]:  supportedExtension = [###]
Feb 26 09:10:07 SERVER icingaweb2[58967]:  nETBIOSName = DOMAIN
Feb 26 09:10:07 SERVER icingaweb2[58967]: Capability query attribute listing ended.
Feb 26 09:10:07 SERVER icingaweb2[58967]: Issuing LDAP search. Use 'ldapsearch -P 3 -H "ldaps://servername.domain.local:636" -D "username@domain.local" -W -b "###" -s "sub" -z 0 -l 0 -a "never" "(&(!(objectClass=computer))(&(objectClass=user)(sAMAccountName=USERNAME)))"' to reproduce.
Feb 26 09:10:07 SERVER icingaweb2[58967]: Testing LDAP credentials (###) failed: Invalid credentials

(I’ve reducted sensitive information.)

If I use my correct credentials the log message are identical except for the last line.

As far as I can tell the LDAP implementation does not use ldapsearch to authenticate a user. This is just a troubleshooting help telling you how to reproduce the query which is made internally using php-ldap. The password is reducated for security reasons.

You can find the code here:

https://github.com/Icinga/icingaweb2/blob/b8975b256a744644e9af91d622fb3e09381da81a/library/Icinga/Protocol/Ldap/LdapConnection.php#L1254

Best regards
Michael

1 Like
9

Ups, I missed to answer that question:

# dpkg -l | grep ldap
ii  ldap-utils                           2.4.44+dfsg-5+deb9u3              amd64        OpenLDAP utilities
ii  libaprutil1-ldap:amd64               1.5.4-3                           amd64        Apache Portable Runtime Utility Library - LDAP Driver
ii  libldap-2.4-2:amd64                  2.4.44+dfsg-5+deb9u3              amd64        OpenLDAP libraries
ii  libldap-common                       2.4.44+dfsg-5+deb9u3              all          OpenLDAP common files for libraries
ii  php-ldap                             1:7.0+49                          all          LDAP module for PHP [default]
ii  php7.0-ldap                          7.0.33-0+deb9u7                   amd64        LDAP module for PHP

Which versions do you use?

10 
# dpkg -l | grep ldap
ii  ldap-utils                           2.4.47+dfsg-3+deb10u1         amd64        OpenLDAP utilities
ii  libldap-2.4-2:amd64                  2.4.47+dfsg-3+deb10u1         amd64        OpenLDAP libraries
ii  libldap-common                       2.4.47+dfsg-3+deb10u1         all          OpenLDAP common files for libraries
ii  php-ldap                             2:7.3+69                      all          LDAP module for PHP [default]
ii  php7.3-ldap                          7.3.11-1~deb10u1              amd64        LDAP module for PHP

I’m on Debian 10 (buster). I don’t think that your version is problematic, since it is still supported.

Another idea that come to my mind: Can you check your user object in Active Directory and ensure that the attribute sAMAccountName is set. AFAIK it is possible in AD to create a user without a set sAMAccountName and only use the userPrincipalName attribute.

11

Ok, got it working. Unfortunately, I don’t know exactly why.

One strange thing (at least to me) is when adding default domain, I’m no longer able to login as local user (admin). Or am I’m doing something wrong?

Second, Username is not valid as expected:

user@example.com -> failed !?
user@example -> ok
example\user -> ok
user -> failed

Is that intended behavior?

1 Like
12

Hi,

its intended i think:

https://icinga.com/docs/icingaweb2/latest/doc/05-Authentication/#default-domain

1 Like