A client upgraded from 3.2.805 to 3.2.830 recently. Now, some ldap users can log in and others can't. 
https://insight.lindenlab.com/home/

For those that can't, as soon as they enter their credentials, they are re-directed back to the login screen.

Client confirms ldap is fine on their side. Users report no issues with ldap for other systems there.

List of LDAP USERS where it:
Works (example): mitchell, fereshteh, steven, sanghavi 
Doesn't Work (example): venellyn, matias, dee, garry, fan

The issue is a combination of MI defaulting to secure php session cookies in 3.2.812, which get set for a specific domain, and Linden using an apache proxy server for MI. They point browsers to https://insight.lindenlab.com which proxies requests over to the MI machine which lives at https://int.insight.lindenlab.com.

This means that if a user does not have a valid PHPSESSID cookie in their browser (they've never logged into MI, or haven't done so recently) MI will try to set a php session cookie for the domain $SERVER[HOST_NAME], which is int.insight.lindenlab.com. This is a different domain than what's in the web browser, so the web browser ignores it and refuses to set the PHPSESSID cookie. Without a PHPSESSID cookie, MI can still authenticate, but all further pages think that you haven't yet authenticated, throwing the user back to the login page!

The solution then is to turn off SECURE_SESSION_COOKIES so that MI doesn't force the session cookie to be limited to int.insight.lindenlab.com anymore.  PHP will just set a generic PHPSESSID cookie to whatever domain is in the address bar of the URL. This enables a valid PHPSESSID to exist for further MI requests and Linden's proxying works as expected.

To turn off SECURE_SESSION_COOKIES, edit const.php and set SECURE_SESSION_COOKIES = 'N'.

/var/www/iv/engine/config/const.php

(If you want SECURE_SESSION_COOKIES to be enabled and still want to proxy, you'll need to set a ProxyPassReverseCookieDomain directive in the proxy server's mod_proxy configuration.)