Issue With Re-Used Email Addresses

[pdolloff]

Hello

We have come up against one roadblock in implementing Piler as our Email Archive solution.

Our organization re-uses email addresses. If an employee leaves, there is a time period where their username is reserved, but then it is deleted and can be assigned to another.

Of course, this causes issues with the new user being able to see the old user's email.

The obvious fix is for us to never re-use accounts, but would there be another way to prevent the new user from seeing the old user's email without purging the old user's emails?

I was thinking of a table that has the user's start date, and using that in the search query?

[Janos SUTO]

It's indeed odd to assign the same email address to someone else, especially if the left employee had some private emails in the archive as well. I assume you won't change this corporate policy.

Hacking the search query is possible, but I don't know where to store such a timestamp for the mentioned start date. What authentication method do you use for the piler gui?

[pdolloff]

I have used the SSO option with Active Directory.

[Janos SUTO]

OK. The solution to your problem involves multiple steps.

1. Add CUSTOM_EMAIL_QUERY_FUNCTION hook to the check_ntlm_auth() function
2. Create the function specified for CUSTOM_EMAIL_QUERY_FUNCTION which sets a variable for the 'reanimated' account having a timestamp assigned to it as the start date
3. Fix the search query to honor this variable

[pdolloff]

That is great, thank you!

Also, I never answered your previous question, but I am not sure if I can convince anyone to change the corporate policy, but at least this removes a potential roadblock to our implementation.

[Janos SUTO]

I think it's ready to test. Edit config-site.php, and add something like the following (feel free to use a better function name):

$config['CUSTOM_EMAIL_QUERY_FUNCTION'] = 'aaaa';

function aaaa($username = '') {
   if($username == 'some_sso_user') {
      $session = Registry::get('session');
      $session->set('not_before_date', '2016.03.30');
      syslog(LOG_INFO, "adding not before 2016.03.30 to " . $username);
   }
}

The above function adds 2016.03.30. to the user called 'some_sso_user'. Use this function (it might be pretty complex if you will) to assign an artificial start date to whatever user it's necessary.

Note: this affects only the search results. If the given user can figure out a valid message serial id before this date, and he may be able to view it or download it.

To try the feature, checkout the reanimated_account_fix_for_sso branch, see https://bitbucket.org/jsuto/piler/branch/reanimated_account_fix_for_sso or go to the download area to get the zipped tarball. Let me know how it works for you.

[pdolloff]

Hello

I tried that code and it worked. I had to add the following lines to auth.php, since I am using mod_auth_kerb for authentication, and it sets REMOTE_USER to the form username@DOMAIN:

$u = explode("\\", $_SERVER['REMOTE_USER']);

      if(isset($u[1])) { $sso_user = $u[1]; }
      else {
        $u = explode("@", $_SERVER['REMOTE_USER']);
        if (isset($u[0])) { $sso_user = $u[0]; }
        else { $sso_user = $_SERVER['REMOTE_USER']; }
      }

I changed your code slightly to use the value of whencreated from the LDAP query to automatically set the value of not_before_date:

$whencreated = substr($a['whencreated'],0,4) . '-' . substr($a['whencreated'],4,2) . '-' . substr($a['whencreated'],6,2);
            if (CUSTOM_NOT_BEFORE_START) {
               $custom_not_before_start = CUSTOM_NOT_BEFORE_START;
               if (strtotime($whencreated) > strtotime($custom_not_before_start)) {
                  $session = Registry::get('session');
                  $session->set('not_before_date', $whencreated);
                  syslog(LOG_INFO, "adding not before " . $whencreated . " to " . $sso_user);
               }
            }

I used CUSTOM_NOT_BEFORE_START to only set not_before_date if whencreated was before an arbitrary date (in our organization's case, the date accounts were migrated; any users before that date may have older emails that were moved over from the old domain, and accounts were not re-used on the old domain):

$config['CUSTOM_NOT_BEFORE_START'] = '2014-01-01';

Does that look okay?

[Janos SUTO]

Yes, it looks fine.

I've merged the fix to the master branch, including an additional fix to check for user@domain if domain\user does not work out. I'd like you to get model/user/auth.php from https://bitbucket.org/jsuto/piler/commits/c1c5c3042315997b52e8caf518347fe2d990ce46 and test it.