Actually, I think I missed something very very early on, and I apologize for lost time:
>From the credentials caching page of mod_auth_kerb: "Sometimes there is need to keep the ticket file or credential cache around after a user authenticates, normally for cgi scripts. If you turn on KrbSaveCredentials, the tickets will be retrieved into a ticket file or credential cache that will be available for the request handler. The ticket file will be removed after request is handled." That last sentence...that's the kicker. Apache wakes up, services your first request after getting credentials (in this case, getting the basic tree layout), and then intentionally deletes the credentials cache that provides the ability to perform an ldap_sasl_bind. Any subsequent attempts will, of course, fail miserably. That's why phpldapadmin fails to work. It doesn't have the necessary credentials to do GSSAPI authentication. The real kicker here is that as far as the GSSAPI is concerned, this operation is correct. We don't want a credentials cache to lay around, and we don't want phpldapadmin to cache a username and password in "plain text" (even if in memory). So, at this point, I think the way phpldapadmin/apache works + the GSSAPI == mutually exclusive systems, assuming we don't care to break the intended design of each application... So yeah...I might need to find another way around this...perhaps some other authentication method... 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 > > > > ------------------------------------------------------------------------------ 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
