View Issue Details

IDProjectCategoryView StatusLast Update
0011322Tine 2.0Tinebasepublic2018-03-22 17:38
ReporterestradisAssigned To 
PrioritynormalSeveritymajorReproducibilityalways
Status confirmedResolutionopen 
Product VersionElena (2015.07.3) 
Target VersionFixed in Version 
Summary0011322: Mailserver credentials seems to be lost after password change of user account in Active directory
DescriptionOne 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
TagsNo tags attached.
mwticket

Relationships

related to 0011826 resolvedpschuele Felamimail crashes when tried to set credentials for email account. 

Activities

estradis

estradis

2016-06-20 13:48

reporter   ~0018214

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

estradis

2017-02-10 10:39

reporter   ~0019522

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.
pschuele

pschuele

2017-04-27 15:01

administrator   ~0019938

is this still happening with 2017.02.3?
estradis

estradis

2017-05-05 08:40

reporter   ~0020028

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!
pschuele

pschuele

2017-05-05 09:23

administrator   ~0020030

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?
estradis

estradis

2017-05-08 09:16

reporter   ~0020044

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

pschuele

2017-05-08 13:30

administrator   ~0020048

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 :(
pschuele

pschuele

2017-05-08 13:33

administrator   ~0020054

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

pschuele

2017-05-11 10:36

administrator   ~0020066

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?
estradis

estradis

2017-05-16 17:21

reporter   ~0020104

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?
pschuele

pschuele

2017-05-17 09:47

administrator   ~0020108

> 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.
estradis

estradis

2017-05-17 14:33

reporter   ~0020120

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.
pschuele

pschuele

2017-06-15 11:58

administrator   ~0020330

hi estradis,

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

estradis

2018-02-26 15:55

reporter   ~0021456

Any updates on this issue?
pschuele

pschuele

2018-03-22 17:38

administrator   ~0021560

no, sorry - nothing new here.

Issue History

Date Modified Username Field Change
2015-09-15 16:14 estradis New Issue
2016-06-20 13:48 estradis Note Added: 0018214
2016-07-07 13:29 pschuele Relationship added related to 0011826
2017-02-10 10:39 estradis Note Added: 0019522
2017-04-27 15:01 pschuele Note Added: 0019938
2017-04-27 15:02 pschuele Assigned To => pschuele
2017-04-27 15:02 pschuele Status new => feedback
2017-05-05 08:40 estradis Note Added: 0020028
2017-05-05 08:40 estradis Status feedback => assigned
2017-05-05 09:23 pschuele Note Added: 0020030
2017-05-05 09:23 pschuele Status assigned => feedback
2017-05-08 09:16 estradis Note Added: 0020044
2017-05-08 09:16 estradis Status feedback => assigned
2017-05-08 13:30 pschuele Note Added: 0020048
2017-05-08 13:30 pschuele Target Version => known bugs
2017-05-08 13:33 pschuele Note Added: 0020054
2017-05-11 10:36 pschuele Note Added: 0020066
2017-05-11 10:37 pschuele Assigned To pschuele =>
2017-05-11 10:37 pschuele Priority high => normal
2017-05-11 10:37 pschuele Reproducibility unable to reproduce => always
2017-05-11 10:37 pschuele Status assigned => confirmed
2017-05-16 17:21 estradis Note Added: 0020104
2017-05-17 09:47 pschuele Note Added: 0020108
2017-05-17 09:48 pschuele Assigned To => pschuele
2017-05-17 09:48 pschuele Status confirmed => assigned
2017-05-17 09:48 pschuele Target Version known bugs => 2017.02.4 Community Edition
2017-05-17 14:33 estradis Note Added: 0020120
2017-06-15 11:58 pschuele Note Added: 0020330
2017-06-15 11:58 pschuele Assigned To pschuele =>
2017-06-15 11:58 pschuele Status assigned => confirmed
2017-06-15 11:58 pschuele Target Version 2017.02.4 Community Edition =>
2018-02-26 15:55 estradis Note Added: 0021456
2018-03-22 17:38 pschuele Note Added: 0021560