3

Given a Web Application with Form-based login and a central directory: using LDAP (fast) bind in an application with the actual user has a number of advantages (opposed to using a service user and doing a password check). It especially means the directory server will evaluate if the login is actually permitted. It can then audit the logins and count failed attempts and the application does not need to know how to compare password hashes or check for account-locks/expires/time restrictions.

However there is the question, on what to do if a login session (for example powered by an http session cookie) persists for a longer time, and the user was meanwhile deleted or locked out.

The simplest approach would be to bind regularly again. This has however the problem that it either annoys the user (as she has to give the password again) or it means I have to keep the password in the users session, so I can re-authenticate for it. Is there another (widely supported) method?

If not, what would be done? Using a service bind to look up the DN and check if it is modified (any attributes changed)? I guess this will not cover "valid-until" type of restrictions.

Is there (if GSSAPI is not used) a way to have a session representing token which can be validated against the LDAP server (and if yes, can I access it from a LDAP client in Java?)

My software product supports all kinds of other alternative methods like SSO with SAML or SiteMinder, Kerberos and so on. But the LDAP method is there for some customers and I want to optimize specifically that part.

Improve this question
7
  • Did you consider using Single Sign On (SSO) like SAML. I think this will solve your problem with session lifetime. SAML can be integrated with Active Directory and there are several open source implementation for SAML. – Ubaidah Apr 4 '15 at 4:40
  • Yes, we also might use SAML, but this problem here is specific to using LDAP with simple bind as an authentication provider. – eckes Apr 4 '15 at 17:18
  • BTW: not sure how does the Web Browser SSO profile of SAML solve the session problem? – eckes Apr 4 '15 at 17:55
  • I think you will integrate SAML with your Active Directory. So any authentication request will be forwarded to IdP/SAML server Then SAML can perfrom Active Directory/LDAP authentication and once the user is authenticated the SAML server send response (authentication token) to the protected resource server ( the server that the user tries to access) Each token has a lifetime or expiration time. You should be able to set the appropriate lifetime for the token that match your needs – Ubaidah Apr 4 '15 at 20:37
  • 1
    Ah the age old question on when to invalidate... – artifex Apr 8 '15 at 7:30
2
+25

From what could perceive, your problem is not Active Directory-specific. You would still have this issue if it were SQL-based or any other kind of authentication backend. What we have to solve is: how do we keep awareness about the logged-in user account status without remembering the account credentials or asking for re-authenticating AND not forsaking security?

The answer is simple: We can't. The only way to make sure the user is still valid is re-checking back at the auth service.

Your only option should be longer timeouts (I think that we do not need to get on the topic of why we should not keep the user's credential, do we?), but that is exactly why you are facing this status-consistency problem.

That is the reason we have a proper vulnerability category for that kind of problem. You simply should NOT enable long session-timeout periods or (in some people's opinion) long-lived sessions.

You may try something about that SSO mentioned by @Abu. But that opens up to another problem about the way Windows authenticates because NTLM is broken and so do default Kerberos configuration, as explained the previous link. Of course, it is possible to configure Kerberos properly so that it does not use the affected crypto, but that also comes with the need for a tight infrastructure management plan (and i'm not even sure that it would invalidate the session at the moment the account gets deleted, blocked, etc.).

Security always come at the expense of usability. Talk with your manager, explain the situation to him and do whatever he chooses to. One way or the other, he will be aware of the pros and cons of his decision, be it lesser security (some hacked or wiped-out servers?) or some emails complaining about reauthenticating (depending on the chosen timeout).

From where i look at the matter, the impact of lesser security in this case far supersedes the impact of the second option.

But only you may tell where it hurts the most.

Improve this answer
7
  • Actually for DB it works quite fine since I normally use a system DB user so I can check every few minutes if the user is not locked or has changed meta data. With LDAP i can do that only when I have a system user, but then I cant use the LDAP server policy enforcing which I get from simple binds. – eckes Apr 7 '15 at 21:05
  • What i meant in my answer was that you would still have to check the user status, which you do as you just said. Now, talking about the initial question, fast binds should allow you to check if the user is still valid as stated here. "Concurrent bind, also known as fast bind, enables an application to determine if multiple users have valid IDs and passwords and if their accounts are enabled." And by the way, fast binds are UNENCRYPTED! That means you have credentials running "wildly" in cleartext all around your network... – DarkLighting Apr 7 '15 at 22:03
  • Hopefully the users use LDAPS if they dont trust the backend network. – eckes Apr 7 '15 at 22:07
  • The documentation says you should be able to check the user status using fast bind. Is it not working for you? What error do you get on that? – DarkLighting Apr 7 '15 at 22:10
  • yes I can check it with fast bind, thats why I like to use it. But I do need to have the password for that. (I have the password at the initial login, but I also need it for re-validation of existing sessions or of rembered sessions, and today I do not have the password handy at those times) – eckes Apr 7 '15 at 22:16
2

Using only a BIND isn't guaranteed to restrict access to desired users. For example, you'll also want to check if the user is locked, e.g. the userAccountControl attribute.

If you are really concerned about storing credentials in memory and want rapid suspention of user rights via LDAP, then you can keep the session open with periodic queries of the appropriate attributes. This has other issues, but will solve this concern.

However, I believe that you are over estimating the need for rapidly kicking a user out of an application when the user's directory information changes. If you really need to rapidly kick the user out, then you should have a mechanism in the application to invalidate the user's session.

I also believe that you are excessively concerned with storing user credentials in memory. This is a relatively hard target, and if user's credentials are that sensitive, then you shouldn't really be using anything that can be stored in memory but rather use something like multi-factor authentication where one of the factors presence is time-bound or cryptographicly secure, e.g. SecurID, or PC/SC.

Improve this answer
1
  • Hm, the directory servers I have worked with all check for locked, expired or restricted accounts on bind (at least for the usual conditions). This is exactly why it is usefull, I do not have to know all the different policies a company might have (based on unknown OIDs). (and the question was not about rapid kicking, its more about "within days" for remember-me type of scenarios. (and I am just mildly concerned about storing credentials just like everybody should). – eckes Apr 9 '15 at 17:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.