Hi all, I wanted to take a minute to inform everyone of what I discovered:
My bug ended up being in mod_auth_kerb. The 5.x version of this application has a new feature to save the success or failure of a previous kerberos authentication, and will check for this success or failure for subsequent requests that reside within the same apache process. This provides the ability to essentially cache the authentication, reducing load on the KDC. At the same time, the module, upon completion of any request, is designed to delete the credentials cache it wrote out for use by sasl-aware applications (like phpldapadmin). Therefore, the module will authenticate the user on first execution, and write out the credentials cache for use. Upon the completion of that http request, the cache file will get deleted. Subsequent authentication attempts against the same service--and the same server process--will return a successful authentication due to the caching nature of mod_auth_kerb, but the actual authentication never occurs, and a credentials cache never gets written again. Then, sasl-aware applications that use the GSSAPI (which rely on that cache) fail, because it never gets written out. I downloaded the source, commented the sections that try to check the cached authentication, recompiled, and all was well. This does mean my KDC gets hammered more...but at least it works. Thanks, Adam On Mon, Jun 20, 2011 at 8:07 PM, Adam <prozaconsti...@gmail.com> wrote: > On 6/18/2011 7:48 AM, Deon George wrote: > >> Adam, >> >> Since PLA only asks for authentication creditials once (from a user), it >> needs to be able to "cache/store" them for subsequent queries (or know >> where to get them). setLogin() will store the details, so when they are >> needed again getLogin() will return them. When auth_type is 'cookie', >> these details are stored in a cookie, when 'session', its stored in a >> session, etc... >> >> Normally getLogin() and getPassword() will return the stored DN and >> password, so that PLA can "re-authenticate" to the LDAP server for >> subsequent queries (on a subsequent get/post request). (Even when users >> login with an attribute value (eg: email), PLA will query the LDAP >> server first to get the DN, and remember that DN, if the password is >> valid). >> >> Now, you should be able to do all your logic in startSASL(), since it >> should be called again for a get/post. You should also make sure that >> the logic in connect() gets to the startSASL() call to enable the >> ldap_connect() to occur (and the subsequent ldap_sasl_bind()). You might >> be failing at the test of $bind['id'] (in connect() line 146) - ie: its >> NULL - try making it '' to get you through that part. >> >> If you can give me some pointers on how to setup a SASL environment for >> a RHEL/CentOS environment (and its quick for me to do), i'll be able to >> have a look at the work you've done. >> >> ...deon >> >> >> On 18/06/11 02:41, Adam Allred wrote: >>> >>> But, any subsequent action that requires another LDAP query causes an >>> infinite redirect, and the debug output indicates that the >>> successfully bound connection is not located in the cache, and it >>> tries to build a new connection with an invalid DN of 'user'. >>> >>> It seems like the application has a dependence on a bind_dn existing, >>> and if it doesn't then it starts to behave erratically. I've dug >>> through the code trying to find and correct any areas where a bind_dn >>> being null leads to undesired behaviour, and have found a few cases in >>> the connect function in ds_ldap.php, but the problem still persists. >> >> >> ------------------------------------------------------------------------------ >> EditLive Enterprise is the world's most technically advanced content >> authoring tool. Experience the power of Track Changes, Inline Image >> Editing and ensure content is compliant with Accessibility Checking. >> http://p.sf.net/sfu/ephox-dev2dev >> _______________________________________________ >> phpldapadmin-users mailing list >> phpldapadmin-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/phpldapadmin-users > > Hello, > > I applied the patch, and noticed the following in debug output: > > functions(0124-001): app_error_handler: Entered (8|Undefined index: > authz_id|/var/www/phpldapadmin-git/lib/ds_ldap.php|661|a:4:{s:8:"resource";i:0;s:6:"method";s:4:"user";s:5:"fargs";a:2:{i:0;i:0;i:1;s:4:"user";}s:5:"CACHE";a:1:{s:8:"login_ > > That's the ldap_sasl_bind call. In my case, $CACHE['authz_id'] is not > set. It still "works", but puts an error in the debug log...In my case, the > following > call does work with no errors: > > return @ldap_sasl_bind($resource,null,null, > $this->getValue('sasl','mech'), > $this->getValue('sasl','realm'), > null, null, > $this->getValue('sasl','props')); > > > While this may seem nutty, since there's no identifying info there, the > previous kerberos auth via apache + the putenv() calls to populate the > KRB5CCNAME into php provides the ldap_sasl_bind call the necessary info > to pull the kerberos principal out of the credentials cache and > authenticate the user. > > Also, notice that newer versions of php take an extra optional parameter > in to ldap_sasl_bind, the authc_id and the authz_id, that's why I added > an extra 'null' in the call after the realm. > > > After applying your path, I attempted to try again, and still had the > same behavior. The first login is successful, and I see my LDAP server's > tree in the left navigation column. Any subsequent attempts to talk to > the server fail. Below is the output that landed on the page (scrubbed > for identifying info): > > Array > ( > [class] => N/A > [function] => debug_dump > [file] => /var/www/phpldapadmin-git/lib/functions.php > [line] => 700 > [debug] => Array > ( > [Incoming MSG] => Array > ( > [title] => Unable to connect to LDAP server LDAPSERVER > [body] => *Error*: Local error (-2) for*user* > [type] => error > ) > > [existing] => Array > ( > [0] => Array > ( > [title] => Unable to connect to LDAP server > LDAPSERVER > [body] => *Error*: Local error (-2) for*user* > [type] => error > ) > > [1] => Array > ( > [title] => Error > [body] => No such entry (dc=domain,dc=com) > [type] => error > ) > > ) > > ) > > ) > > > And attached is debug output (also scrubbed). Any advice you can offer > would be great. > > Thanks, > > Adam > > > > ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ phpldapadmin-users mailing list phpldapadmin-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpldapadmin-users
