Diagnose auth issue on crash-stats admin

RESOLVED FIXED

Status

mozilla.org Graveyard
Server Operations
RESOLVED FIXED
8 years ago
3 years ago

People

(Reporter: reed, Assigned: aravind)

Tracking

Details

(URL)

(Reporter)

Description

8 years ago
Split from bug 528342:

I can't login to crash-stats admin interface on prod or staging.

Aravind found this in the log:
2009-11-12 21:59:02 -08:00 --- debug: Auth Library loaded
2009-11-12 21:59:02 -08:00 --- debug: Authorization Failed for
mail=reed@reedloden.com,o=net,dc=mozilla in group cn=CrashReportsAdmin

My guess is that my member entry in cn=CrashReportsAdmin is wrong.
(Assignee)

Comment 1

8 years ago
You are in cn=CrashReportsAdmin as mail=reed@reedloden.com,o=net,dc=mozilla
(Reporter)

Comment 2

8 years ago
                            if ($this->_authorize($ldapconn, $user_dn, $cn)) {
                                ldap_close($ldapconn);
                                restore_error_handler();
                                return TRUE;
                            }                                   
                            Kohana::log('debug', "Authorization Failed for " . $user_dn . " in group " . $cn);

So, this is the error, which means that I'm authenticating correctly but _authorize() is returning false.

From _authorize():
        $filter = "(&(member=" . $user_dn . ")(${cn}))";

Should come out as "(&(member=reed@reedloden.com,o=net,dc=mozilla)(cn=CrashReportsAdmin))"

        $group_dn = Kohana::config('ldap.group_dn', 'ou=groups,dc=mozilla');

Should be "ou=groups,dc=mozilla"

        $rs = ldap_list($ldapconn, $group_dn, $filter);

Should return a result set.

        if ($rs) {
            $info = ldap_get_entries($ldapconn, $rs);

Should return a multi-dimensional array with entries found.

            if ($info && $info['count'] > 0) {
                return TRUE;
            } 
        }
        return FALSE;

This looks ok, as far as I can tell... Would be nice to differentiate those |if| statements by outputting info to the log based on which one actually failed (whether it was ldap_list() or ldap_get_entries()).

(In reply to comment #1)
> You are in cn=CrashReportsAdmin as mail=reed@reedloden.com,o=net,dc=mozilla

They are all 'member' entries in the group, correct?

Is there some LDAP ACL that is preventing an o=net account from iterating the group in question to see if the dn is a member? That seems like a possible issue. The code does ldap_bind() with my account once the dn has been found, so my o=net account would be what's actually doing the search. If for some reason, o=net accounts aren't allowed to do that, then that would be the problem.
Assignee: server-ops → aravind
Does this belong in Webtools::Socorro now?
Assignee: aravind → server-ops
(Reporter)

Comment 4

8 years ago
(In reply to comment #3)
> Does this belong in Webtools::Socorro now?

No, I don't believe it's an app issue based on my review of the code and the assumption that such code is working for others. I left some comments and questions in comment #2 that will hopefully help lead to the root cause.
Assignee: server-ops → aravind
(Assignee)

Comment 5

8 years ago
Reed, I tested this with another (community) account I made for myself and I am able to query the ldap group just fine.

That said, I am unable to auth to the application as well.  The odd thing is that I don't even see the application hitting ldap for this information.

@Austin:  Is the app using some sort of cached credentials etc?  If so, can we turn off all caching on ldap lookups etc?  LDAP is meant to be hit as often as necessary, its really fast with bind requests and such.

Comment 6

8 years ago
(In reply to comment #5)
No caching expect for your browser.
Try - logout, restarting your browser and then login to see if you see your request hitting LDAP.
(Assignee)

Comment 7

8 years ago
I have never logged into the site before, so I doubt my browser was caching something.  In anycase, I visited /logout and tried it again.  I still didn't see any hits to the ldap server.

Comment 8

8 years ago
(In reply to comment #7)
Other than double checking the ldap.php config file... I don't know what to do here. Is there a test LDAP server that you pointed to in one environment that propagated out to prod?
(Reporter)

Comment 9

8 years ago
Can I get an update on this? I'd like to be able to use the new admin interface for Socorro.
austin/aravind - when's a realistic ETA to get this resolved?  What's it take?
(In reply to comment #10)
I don't have any next steps here. Aravind?
(In reply to comment #11)
Thanks to aravind, we've diagnosed the issue. It was a bad regex that was too restrictive on checking for a valid username.

I've removed this check. Please test your account again 
http://crash-stats.stage.mozilla.com/
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
(Reporter)

Comment 13

8 years ago
(In reply to comment #12)
> (In reply to comment #11)
> Thanks to aravind, we've diagnosed the issue. It was a bad regex that was too
> restrictive on checking for a valid username.

Nope, still broken. The log in comment #0 and my walk-through of the code in comment #2 clearly shows my request getting past _check_valid_user(), so that's not the main issue here. It may be causing issues for other users, but it doesn't seem to be the affecting cause here.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to comment #13)
Reed - I've committed the debugging you asked for in comment #2

It seems that you have access to Stage's logs. Can you wait 5-10 minutes and then try the login and then check the logs to see if ldap_list or ldap_get_entries is failing.

r1588.
(Reporter)

Comment 15

8 years ago
(In reply to comment #14)
> (In reply to comment #13)
> Reed - I've committed the debugging you asked for in comment #2

Cool, thanks.

> It seems that you have access to Stage's logs. Can you wait 5-10 minutes and
> then try the login and then check the logs to see if ldap_list or
> ldap_get_entries is failing.

I don't have access to stage's logs. Comment #0 was from what Aravind said in bug 528342. However, I have tried to log in again, so Aravind should be able to check the logs and see what's up.
Working with Aravind... checking in 
Index: modules/auth/libraries/drivers/Auth/LDAP.php
===================================================================
--- modules/auth/libraries/drivers/Auth/LDAP.php	(revision 1588)
+++ modules/auth/libraries/drivers/Auth/LDAP.php	(working copy)
@@ -230,11 +230,10 @@
      */
     private function _authorize($ldapconn, $user_dn, $cn)
     {
-	// Example "(&(aking@mozilla.com,o=com,dc=mozilla)(cn=sekritCabal))"
-	$filter = "(&(member=" . $user_dn . ")(${cn}))";
-	$group_dn = Kohana::config('ldap.group_dn', 'ou=groups,dc=mozilla');
-	$rs = ldap_list($ldapconn, $group_dn, $filter);
 
+	$filter = "(member=" . $user_dn . ')';
+	$group_dn =  $cn . ',' . Kohana::config('ldap.group_dn', 'ou=groups,dc=mozilla');
+	$rs = ldap_search($ldapconn, $group_dn , $filter);
 	if ($rs) {
 	    $info = ldap_get_entries($ldapconn, $rs);
 	    if ($info && $info['count'] > 0) {


@reed can you try again?
(Reporter)

Comment 17

8 years ago
(In reply to comment #16)
> @reed can you try again?

Yay, "You have successfully logged in."

Your patch looks good, too, especially with the use of ldap_search() over ldap_list(). I'm curious to know why it was working for some people but not others, however.
(Assignee)

Comment 18

8 years ago
Looks good on staging, pushed to prod.

@reed:  Users don't have perms to lookup group names (and dns).  Users can only look at the groups they are members of - The earlier code was trying to get a list of group dns that matched the filters.  The current code looks directly at the group and tries to assert that the user is a member of the group.
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago8 years ago
Resolution: --- → FIXED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.