0011322: Mailserver credentials seems to be lost after password change of user account in Active directory

[Gloirin]

Reported by estradis on 15 Sep 2015 14:14

Version: Elena (2015.07.3)

One user reported that he isn't longer able to use email in tine after he was forced to change his password by active directory.

I verified on the mailserver that tine servers ip address were attempted to auto ban multiple times, but it where revoked to ensure that tine won't be blocked globally.

I run the select statment below on the database to see whether there are credentials stored. Although I got encrpyted credentials the mailserver logs said that no login name were transmitted and therefore 535 had been replied and tine was disconnected.

I requested screenshots from the user, but all settings were made correct.

I adviced the user to re-enter his username and password, but it changed nothing.

I tried to reproduce that behavior with one of our test accounts, but I didn't succeed. This seems to be an individual problem.

The user isn't still able to use email in tine!

Our configuration:
Authentication: ldap (Active Directory)
Backend: sql (mysql on same host)
User can change password: No
Use password policy: No
Only ASCII: No
Minimal length, upper/lower case, digits, symbols: 0
Deny part of username in password: No
Redirect for login: No

Mailserver configured by the users

Select statement I used to see whether there are credentials stored:

select u.login_name, u.last_login,f.name as 'mail_name', f.host as 'mail_host', f.port as 'mail_port', f.ssl as 'mail_ssl', mc.cache as 'mail_cache',f.smtp_hostname as 'smtp_hostname', f.smtp_port as 'smtp_port', f.smtp_ssl as 'smtp_ssl', sc.cache as 'smtp_cache',mc.creation_time as 'credentials_creation_time', mc.valid_until as 'credentials_valid_until'from tine20_accounts as u, tine20_felamimail_account as f, tine20_credential_cache as mc, tine20_credential_cache as scwhere login_name like 'loginname%' and u.id = f.user_id and mc.id = f.credentials_id and sc.id = f.smtp_credentials_id;

Result 1 line with encrypted credentials

[Gloirin]

Comment posted by estradis on 20 Jun 2016 11:48

We had the same issue again. Are there any updates about it?

[Gloirin]

Comment posted by estradis on 10 Feb 2017 09:39

Meanwhile and some versions later, this issue is still alive but the behavior had changed.

Now when the user changes its password in AD and logs on into Tine, it seems hat Tine has lost the mailserver credentials as well. When the user now changes its password back to the previsious one in AD and logs in to Tine afterwards, all works fine as if there never had been any trouble before.

AND

It's not longer affecting one user - it appears to all users now.

As a workaround we disabled forced password change for all users in active directory until this bug is (hopefully soon) fixed.

[Gloirin]

Comment posted by pschuele on 27 Apr 2017 13:01

is this still happening with 2017.02.3?

[Gloirin]

Comment posted by estradis on 5 May 2017 06:40

In 0012994 I installed the newest version 2017.02.3 then I proceeded with these steps:

1. Logged off from all opened tine sessions
2. Forced change of user in Active-Directory
3. Changed user password on local machine
4. Logged on into Tine => IMAP was on error state, credentials were requested
5. Logged off from Tine
6. Changed back the original password of user directly in Active-Directory
7. Logged on into Tine => IMAP works fine now

So yes, this is still happening with version 2017.02.3!

[Gloirin]

Comment posted by pschuele on 5 May 2017 07:23

are you using "system accounts" in Felamimail that are created automatically for the users with common mailserver settings or do you have user defined mail accounts?

[Gloirin]

Comment posted by estradis on 8 May 2017 07:16

No, the users create their own account. This is necessary because the mailserver does not authenticate against Active-Directory.

[Gloirin]

Comment posted by pschuele on 8 May 2017 11:30

ok, understood. this is quite difficult to fix, as tine encrypts the mail passwords with the user password. and if the user pw changes "out-of-tine", it is no longer possible to decrypt the mail pw...

i'm afraid that there isn't a simple solution at the moment :(

[Gloirin]

Comment posted by pschuele on 8 May 2017 11:33

we'll discuss this problem in the team. maybe the others have an idea how to fix this.

[Gloirin]

Comment posted by pschuele on 11 May 2017 08:36

hm, sorry. they have no idea as well. but when the users are asked for credentials and give them, it should be fine again, right?

[Gloirin]

Comment posted by estradis on 16 May 2017 15:21

Sorry for the late reply. Due to "WannaCry" we were alerted the last days. At the moment our operation is normalizing again and we are working on all the processes.

I'm also sorry to say no, it's not alright. The existing account must be deleted to create a new one afterwards. The new one will be working. That's the reason why I decided to disable forced PW changes in AD.

What about this idea?
Create a hash and encrypt credentials with them. Then encrypt the hash with the user password. When the user changes the password then decrypt the hash and encrypt it again with the new password. This way all credentials wouldn't be touched ever and operating on the hash only will be much faster than operating on all credentials, wouldn't it?

[Gloirin]

Comment posted by pschuele on 17 May 2017 07:47

> I'm also sorry to say no, it's not alright. The existing account must be deleted to create a new one afterwards. The new one will be working. That's the reason why I decided to disable forced PW changes in AD.

ok, i wasn't aware of that. the account shouldn't have to be deleted to make this work. we'll have a look.

> Create a hash and encrypt credentials with them. Then encrypt the hash with the user password. When the user changes the password then decrypt the hash and encrypt it again with the new password. This way all credentials wouldn't be touched ever and operating on the hash only will be much faster than operating on all credentials, wouldn't it?

hm, not sure if this works. for decrypting, you would need the old user password but that is already gone.

[Gloirin]

Comment posted by estradis on 17 May 2017 12:33

Yes, you're right. That was stupid!

But what about encrypting the hash with the "sid" or "object-id" from AD? They won't change ever. If an admin changes from AD authentication so somewhat else, the encryption of the hash can be changed as well.

[Gloirin]

Comment posted by pschuele on 15 Jun 2017 09:58

hi estradis,

yes, we should allow different hashing methods here to fix this problem. the user pw should only be used as default.

[Gloirin]

Comment posted by estradis on 26 Feb 2018 14:55

Any updates on this issue?

[Gloirin]

Comment posted by pschuele on 22 Mar 2018 16:38

no, sorry - nothing new here.

[Gloirin]

Comment posted by estradis on 4 Jun 2018 07:28

It is now almost three years since this process was created. What's the problem? If there is a lack of ideas, how about this one?

Tine creates a history of the passwords last used. If the decryption of the mail server credentials does not work after the login, Tine walks through the history until the correct key has been found. Then Tine encrypts with the new password and deletes the old keys, where the new password will be stored into the history.

Another advantage:
This process is independent of the set authentication type. It would also work if the authentication type will be changed.

[Gloirin]

Comment posted by estradis on 4 Jun 2018 07:35

By the way, should this bug be moved into git?

[estradis]

@Gloirin would you be so kind and assign this issue to @pschuele again as it was already done in mantis?

[pschuele]

i would rather qualify this as a feature request. help with this issue would be appreciated - i currently don't have that much time to work on it.

[estradis]

"I don't have time" is a statement I can understand, but making it a feature-request?
Since the functionality is affected, this IS a bug, not a feature-request.

I'd really like to help you, but I'm more a manager than a developer and at present I'm alone because my team has left for customer projects. I'm going to to find some time to get a look. Is there any good dokumentation to join development?

[pschuele]

Since the functionality is affected, this IS a bug, not a feature-request.

ok - i would put the label "minor bug" on this, because it does not affect many people and it can be avoided.

Is there any good dokumentation to join development?

have a look at the CONTRIBUTING guidelines for starting: https://github.com/tine20/tine20/blob/master/CONTRIBUTING.md (still WIP).

and this: https://github.com/tine20/tine20/wiki/EN%3ADevelopment-Setup

[estradis]

We're done with tine. You can close this issue, dump it or whatever you want to do with it. We don't care any more about tine.