View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0011322||Tine 2.0||Tinebase||public||2015-09-15 16:14||2018-03-22 17:38|
|Product Version||Elena (2015.07.3)|
|Target Version||Fixed in Version|
|Summary||0011322: Mailserver credentials seems to be lost after password change of user account in Active directory|
|Description||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!
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
|Tags||No tags attached.|
|We had the same issue again. Are there any updates about it?|
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.
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.
|is this still happening with 2017.02.3?|
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!
|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?|
|No, the users create their own account. This is necessary because the mailserver does not authenticate against Active-Directory.|
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 :(
|we'll discuss this problem in the team. maybe the others have an idea how to fix this.|
|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?|
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?
> 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.
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.
yes, we should allow different hashing methods here to fix this problem. the user pw should only be used as default.
|Any updates on this issue?|
|no, sorry - nothing new here.|
|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|