Authentication chaining

#1

Greetings,

I have icinga web 2 installed, working and logging at DEBUG level. I set up database authentication first and that worked fine. Then I set up AD authentication and while that works fine, now IW2 seems to ignore the users that exist only in DB authentication.

I tried removing the AD and changing the order of auth types authentication.ini and restart, but in any order, when I check the log file, I don’t see any evidence that IW2 ever tries database authentication. Previously I would see a logged message like:

2019-06-25T13:54:18-04:00 - DEBUG - Groups found in backend “icingaweb2_db” for user “local_only”: Administrators

However that seems to be after a successful auth, not the auth attempt itself. Now I see nothing logged during a login attemp. On the UI I get “Incorrrect username or password” for all DB users. I also tried deleting and recreating the local users.

In the UI, both the User and User Group backends validate. However I can only run that validation with AD login active, as I can’t login as the local admin user.

Two questions:

  1. How can I have it log attempts to authenticate to the database?
  2. The install documentation says chaining authentication types should work. Is there more to it then simply two entries in authentication.ini (assuming each work individually?)
#2

Hi,

can you share which version of Icinga Web 2 you’re using, and the corresponding content of authentication.ini? Typically if one auth doesn’t work, there’s a fallback.

Cheers,
Michael

#3

Thank you.
It is a fresh install of Icinga Web 2 Version 2.6.3

[ABC-AD]
filter = “(memberOf=CN=admin,OU=Some_Roles,OU=Some-Groups,DC=AD,DC=ABC)”
backend = “msldap”
base_dn = “OU=PEOPLE,DC=AD,DC=ABC”
resource = “ABC-AD”
domain = “ad.abc”

[icingaweb2_db]
backend = “db”
resource = “icingaweb_db”

#4

The user you’re testing is only available in the database backend, not in AD, right?

#5

Yes that’s right. I have 2 local-only users, and the names do not exist at all in AD.

If I could only get some logging going on DB auth. The logging for AD was brilliant, giving me the ldapsearch to try.

#6

Hm, I’m not sure if the fallback is from availability/reachability or for errors. Maybe @nilmerg can share his expertise on the matter.

#7

It’s for both cases. If a user is not found in the backend the next is tried, silently. Though, if an error occurred and the login was not successful it’s not just Incorrect username or password but also Not all backends were available due to errors, check the log. (or something similar)

If this doesn’t appear, it’s really just a wrong user/password.

1 Like
#8

Thank you.

I’ve recreated both local users in the db backend. I see the AD auth fail in the log (as expected) and nothing in the logs about the DB backend. On the UI I do see Incorrect username or password , but I know it’s not incorrect because I just recreated it and just typed in the same password. I don’t see any of the Not all backends message logged, ever.

Again I request how to turn up debugging to see what the DB auth backend is really doing.

#9

You can’t go further than DEBUG. Try changing the password of the db user in the UI while logged in with AD. Then try the login again with the DB user. This ensures the database entry is properly inserted (especially the password hash)

#10

I made some progress. I turned on mysql query logging, and found the problem, or a problem, but not the solution.

When logging in as database resource user “user_local”, which does not exist in AD, the query comes in for:

SELECT icingaweb_user.password_hash FROM icingaweb_user WHERE (name = ‘user_local@ad.abc’ AND active = ‘1’)

The username in the database is just ‘user_local’ with no @ad.abc. So the select fails to return any rows (confirmed at the mysql command line) and the local user isn’t logged in.

If I remove the “ad.abc” contents of Configuration->Application->General Tab->Default Login Domain then local users are working! But then AD users can’t log-in.

The goal is to have just a few local db authenticated users, in case the connection to AD is not working.

#11

As a workaround, I created a database auth’d (non-AD, in MySQL) user with the same Domain suffix, user_local@ad.abc. That works for UI login, and the user can login with either that Domain suffixed username or just user_local .

#12

@nilmerg Maybe those domain aware settings could be enhanced with resource specific overrides e.g. for local db auth?

#13

It’s working as it should. The default login domain is exactly what it is: The domain that’s assumed when none is defined.

If non-domain and domain-aware backends get mixed the default domain should not be set. Instead the users of the domain-aware backend are supposed to login with their full id (name@domain). Or what @Ken did: All non-domain users get the default domain as suffix for their ids in the backend’s data.

I wouldn’t enhance this imho. For me it’s perfectly ok to assume that users of the domain-aware backend define their proper domain in addition. Once multiple domains come into play this even becomes mandatory.

#14

Ok, thanks, I’ll get your point. Then this topic at least helps with problems in configuring just that :slight_smile: