LDAP, Passwords, Die

[Linwood]

I have been experimenting and I think I know how this works, but would appreciate confirmation.

Scenario: Using LDAP for authentication and account sync as primary, followed by local database.

LDAP has a "die" option available, which I think means "if the LDAP connection is not available, do not proceed to the local database". So if DIE is not turned on, then failure to contact the LDAP server means that the password is checked against the local database.

If you go in and set the local database (Admin->Agents) password, then disconnect LDAP (e.g. put in a bad IP in the config), without DIE set, you can log into the agent account with that pre-set password (which can be different from the LDAP password, or the same).

Thus "Die" is set up to permit one to protect the integrity of LDAP access (or more importantly prohibition of access) by requiring its visibility; or conversely "Die" being not set is to permit fallback access.

Is that about correct?

Here's the important question -- is there any process or circumstance where the password entered during the LDAP authentication process is cached or saved inside of the local database, whether hashed or not? From experimenting I think the answer is No.

And now that I've written all that -- one other side effect -- if Die is set, then truly local accounts (not created from LDAP) are also disabled if the LDAP server is not reachable, i.e. the "Die" is not specific to accounts normally authenticated by LDAP, correct?

[crythias]

What's the effective goal with regard to this thread? Do you want fallback/fall through or do you not?

[Linwood]

Call me OCD, but before I deploy a system with network authentication, I just want to understand all the failure modes thoroughly.

The normal scenario I've seen with AD (LDAP) is that management depends on inactivating accounts in LDAP being effective to turn off access to any number of remote systems. The larger the number of such systems, the less likely the organization is to thoroughly go back and disable or delete accounts inside of them.

So a desirable goal might be for OTRS to permit local account fallback with LDAP off, but from my perspective it should be with specific accounts specially set up for that, not the normally LDAP accounts.

If LDAP accounts can fall back to the local database, it permits them to remain behind and become back doors when those employees may have been invalidated. An attack scenario (admittedly a stretch that someone would care or try) is then for the disgruntled employee to arrange a DOS attack against the LDAP server(s), effectively making them unavailable, and then use his 4 year old local database password to gain access, while management believes them to be long terminated and made inactive.

Again... OTRS is not exactly an exciting target, and good design of LDAP servers to prevent DDOS (inside vs. outside for example) might mitigate this.

But I want to understand the implications of DIE being on, or off.

I THINK the implication of it being OFF is that old accounts inactive in LDAP become active again if LDAP is unavailable (absent explicitly setting them invalid).

I THINK the implication of it being ON is that there is no fallback, even for non-LDAP accounts. One would have to get in via shell and change Configure.pm (or restore LDAP obviously).

And I THINK by experimentation that there is no saving of the LDAP password inside of the local database, at least I do not see any fields changing that would be likely to be it. Now that -- if it did save them -- would be a very serious security issue as those are SSO passwords likely to be good for other systems. The other two scenarios maybe are not the most desirable but either is workable so long as you understand them.

[Linwood]

Since the above is a bit rambling let me be more clear.

From my mind the most desirable approach (and what I've used in other Radius/LDAP environments) is:

A few local accounts for emergency access, rarely used, known only to a trusted few (who if terminated require explicit deletion in all systems).

All other accounts are LDAP, and if LDAP is not available, they cannot get in, period, but local accounts can.

I am not saying I have to have that -- but if there's a trick to getting that, it would be nice.