Link to home
Start Free TrialLog in
Avatar of Mark
Mark

asked on

Why does Outlook ask for my IMAP server password when my domain password changes?

The Windows domain requires me to change my password every 90 days. When I do this, and open Outlook, I get a message prompting me to enter my IMAP server password -- even though it has not changed and has nothing to do with my AD password. To open Outlook I have to enter the IMAP server password, not the AD password. Why do I have to do this?

This is a rather painful and annoying step, and is confusing to me an other users because we have to remember that we're not entering our new Windows password, but rather the old email password. If the email server password is not changing, why do we have to do this? Is there a way to NOT make this redundant dialog appear?
User generated image
Avatar of REIT
REIT

Is this affecting anyone else in your environment? Have you tried re-creating the mail profile for outlook?
Avatar of Mark

ASKER

I believe this affects everyone in the office. Profiles have been re-created many times. Whenever someone changes their AD/Domain profile they have to re-enter their Outlook password, even though they are different.
Avatar of Mark

ASKER

I've requested that this question be deleted for the following reason:

Need to do more research on my end.
Avatar of Mark

ASKER

Sorry, I do want to cancel the delete request. I thought I had asked the wrong question, but after further research, this *is* what I need to know. Thanks
Avatar of Mark

ASKER

more information ... I've checked some websites, including some Microsoft sites, which mention deleting credentials. The WIN7 computer I am testing with has no credentials saved, so that's not the problem.
Your setup is such that the authentication between the client, outlook, and the server is based on username/password versus an authentication token as one would have when tge connection is between outlook and exchange.
When a user changes the password, the saved credentials in the client are no longer valid, thus the prompt. Once the new valid password us entered it is saved and no further prompting (besides if outgoing auth is needed and not using the incoming)until the password is changed again.

If this is one of different setups, check the type of account.  If this client has an on premises exchange, or using office365....
you have to set up some sort of password sync between your domain and the email server i.e. with office 365 one would use dirsync
David based on the question the issue is not with synchronization, but with the client, outlook account does not have the new password.
I think I understand your question and that you're mail server has no connection with the ad password which I think some people have misunderstood but have not come across this before.

Thinking about it though the sires I deal with that use IMAP mailboxes quite likely don't change their passwords and in some cases don't use domain logins.

can I suggest rather than letting outlook prompt for the IMAP password you go into the account settings and enter it there and see if any different as one will be the password set on the account and the other saved later?

will try it on one of the IMAP clients later if I can.

Steve
Avatar of Mark

ASKER

Steve Knight: Yes, exactly, the mail server has no connection with the AD password. So, here's the scenario if I wasn't clear ...

We have a Windows AD domain and client workstation users log in using their AD username and password. The mail server is in-house, not Outlook.com, Office 365, gmail, etc. The email server is Dovecot/IMAP. The attached image shows a typical Outlook setup. The Outlook password is verified against a password file on the Dovecot server. It has absolutely nothing to do with the AD password (unless the user happens to set them to the same value). When the AD password is changed, the Outlook "Enter your user name and password for the following server" pops up, and the user has to be sure to enter the email password, not the new AD password. In other words, the user has to enter the password that is already configured in Outlook! This is confusing and unnecessary.

As I mentioned, I've checked the Credential Store and there is nothing there, so I don't know where this "password file" is that the password is saved to when I check the box.

Seems to me it should not be asking this question at all. It does not do this on a non-AD domain workstations. Is this possibly some kind of domain policy?
OutlookSetup.jpg
Can the dovecote system query. TheAD?

Double check whether idovecat validates credentials against the AD, with local being last.
Avatar of Mark

ASKER

arnold:
Can the dovecote system query. TheAD?

Not really, it can authenticate with the AD on its end via LDAP and a customizable checkpassword mechanism, but it's going to use the password passed to it from Outlook which is the password saved in the Outlook settings. To have Outlook pass the AD credentials Outlook has to be set to use "Secure Password Authentication (SPA)" and Dovecot needs to use the NTLM mechanism -- this combination DOES NOT WORK.

Therefore, Outlook will send its configured password for authentication. That's all I've got to work with!

This is fine, really. All that means is the email password is not the same as the AD password (nor do the usernames have to be the same for that matter). I just want Outlook to stop re-asking for its own, non-AD, unchanged email password when the AD password changes.
I'm going to try and re-create though won't be until next week as can't make it do it on a non-domain PC connecting to IMAP.  Only a handful of machines at one site are domain AND IMAP mail and I know one of those is a 2010 one and I need to go on it Mon or Tues probably so will be interesting to see what happens.

Interesting to see the password box is blanked out too, not ***'s in it with a "wrong" password it has remembered.

I know there used to be lots of weird things we had with Outlook 2003 forgetting passwords when the users changed their passwords but that I think was down to them having saved their password then it losing them and was generally OK going to put the password back in the actual account settings box instead.

Steve
Avatar of Mark

ASKER

Thanks Steve - please let me know what you discover. I'm beginning to think a Domain Policy is behind things. Note that this also happens with Outlook 2013, so it's not restricted to 2010.
Mark,

The user client outlook passes username/oldpassword
Your dovecot uses the username/password pair against AD which returns a mismatch prompting the user for password.
Enable debugging on the dovecot IMAP side.
Create an account in outlook. and test it.
Update the AD user password
and see what dovecot reports in the IMAP connection transaction.
I think what happens is that the username is uniform i.e. you can not distinguish between local users in /etc/passwd, LDAP based user and tdb if that is what your backend DB is.
The outlook credentials did not validate against the chain meaning was prompted that the password was incorrect and please provide the correct one.
Do some users us username@AD or someusername@yourdomain.com as the username.

That needs to be confirmed using a username that only exists on the dovecot, and there is no AD depended account, Directory, etc/.
Avatar of Mark

ASKER

arnold - yes, I've done all that; been doing those experiments for months. The Dovecot server does not currently authenticate with the AD password. It is set to 'plain login' and the password file used by Dovecot is /etc/shadow where I've hand-entered the IDs and passwords.

Dovecot has 3 mechanisms that could authenticate against the AD credentials: LDAP, checkpassword and NTLM. However, LDAP and checkpassword will use the ID/password configured in the Outlook settings as shown in the image from my posting ID: 41002423. I know this for certain because the checkpassword mechanism is essentially a program I had to write conforming to a defined interface. I was able to plain-text display the password sent from Outlook to Dovecot. It was always the Outlook configured password, never the domain password, and yes, I did set them to different things and tried with a variety of user ID and password combination. So, LDAP will work great ... as long as your Outlook configured password is the same as your domain password.

The only way to get Outlook to send the AD credentials is (supposedly) to check "Log on using Secure Password Authentication (SPA)" in which case the mechanism is NTLM: https://en.wikipedia.org/wiki/Secure_Password_Authentication. However, after several months of testing and interaction with the Dovecot Listserver people I have determined that the Dovecot NTLM mechanism simply doesn't work.

Therefore, the only Outlook authentication mechanism I am left with is using the password configured in the Outlook settings. AND THIS IS OK! REALLY! I'll leave that set to the same thing for the next thousand years while changing the domain password every 90 days. I just want Outlook to NOT ask me to re-enter this unrelated Outlook password when my domain password changes. It is certain, I have to enter the old Outlook password at this dialog, not the new domain password. I can assure this is true because my first instinct, as with the other users, is to enter the new domain password I just created moments ago into this dialog, which fails. Because? Oh yeah, this is the Outlook password, not the domain password!
I think we are mixing things up.

Outlook to dovecot exchange of info and response of authorized and here is your data or info incorrect, confirm username/password.


The second part is the validation of credentials provided to dovecot
1) it can use the files /etc/passws and /etc/shadow
2) it can validate the credentials provided to it via the LDAP/samba
3) you have a DB style backend.

With that said, the outlook account has incoming mail server IMAP, username, password plain text over either secure on insecure IMAP.
Dovecot gets the username/password in plain text, it validates against the first which happens to be LDAP, the username exists in LDAP but the password does not match, the response is invalid password. Dovecot responds to outlook authentication rejected bad password, the user is prompted for the correct info.

If you create a tester username/password that only exist in /etc/passwd and set it up as an account within outlook of userA
Changing userA's password in the AD should not prompt for password update when using outlook.

The authentication/authorization falls through when there is no match, I.e dovecot gets tester/password, it queries LDAP, tester does not exist there, so it tries the next scheme until it hits /etc/passwd and validates.

Does outlook rely on the address book in ldap?

I reread your last post and understand that you finally validate using the old non AD password,
Ntlm auth in dovecot disabled or enabled?
Debug dovecot to determine which auth method is being used and what information is being passed under these circumstances.
Avatar of Mark

ASKER

arnold:
I think we are mixing things up.
Yes, I probably got too detailed. Everything you wrote from there is correct until:
Dovecot gets the username/password in plain text, it validates against the first which happens to be LDAP
No, I am not doing LDAP. I am not doing NTLM. I am not doing checkpassword. I am only doing 'plain login'. Therefore, it does not validate against LDAP. It only validates against /etc/passwd and /etc/shadow.

I don't understand what you are saying in this bit:
If you create a tester username/password that only exist in /etc/passwd and set it up as an account within outlook of userA
Changing userA's password in the AD should not prompt for password update when using outlook.
But, If I create a userA only in /etc/passwd and not in the AD, and create an account for that userA in Outlook on one of the workstations and AD userX is also an account in Outlook on that workstation, then if I change userX's AD password, I am prompted for userX's Outlook credentials, but not the Outlook credentials for userA. So, if that's what you're asking, you are correct, "changing userA's password in the AD should not prompt for password update when using outlook."

As a further test, I used my debug program (checkpassword) to see exactly what is being passed from Outlook to Dovecot. Let say I change user "mark"s AD password to "badWolf". and mark's Outlook configured password is "littleSheep". When I open outlook, the credentials received are --username="mark" --password='littleSheep', so Dovecot is getting the Outlook password which is what is configured in the Dovecot password file. If I enter "littleSheep" in the Outlook dialog (which is what it always was) I can get into Outlook.

Also, I tried the registry setting idea from here https://support.microsoft.com/en-us/kb/940171, but it didn't work.

I'm going to explore further the idea the Dovecot is the problem and see if I can use that checkpassword program to authenticate against both AD and /etc/shadow and see what happens.
Avatar of Mark

ASKER

Progress! In addition to standard authentication mechanism such as plain, login, ldap, ntlm, Dovecot has an authentication mechanism called "checkpassword", http://wiki2.dovecot.org/AuthDatabase/CheckPassword. This mechanism is passed the username and password from the client (in this case Outlook) and expects a 0/1 return status depending on authentication success.

So, for testing, I modified this program to simply return 'success' in all cases. When I did so, I never got the password dialog in Outlook regardless of whether I changed my AD password or not.

This tells me the problem is with Dovecot, not Outlook. Dovecot is sending a failure status to Outlook when the AD password changes, even though I am using the /etc/shadow passdb and it should have nothing to do with AD.

I'll have to post something on the Dovecot maillist and see what they have to say. If I get a response, I'll post back.
I think dovecot behavior is expected when using the pam auth method. It queries the system with the credentials received. When the username passed from the client does not exists anywhere except /etc/passwd the LDAP, and any other query fall through until it hits the /etc/passwd and then the return response is invalid credentials (password, no such user though not sure it generates a distinction.)
The example deals with using an email account on the mail server that does not have a similarly named username in LDAP/AD.

The setup of outlook for someuser would be to use the testuser account from /etc/passwd.  The test deals with whether someuser using testuser username in /etc/passwd will be prompted for outlook credentials when someuser changes their password in AD/LDAP.

I think your use of checkpasswd might get you back on track you were researching.
Avatar of Mark

ASKER

arnold:
[Dovecot] queries the system with the credentials received.
Yes, and to than end I have done more experimenting to see exactly what credentials are received.

I've tested more extensively validating in Dovecot against both the AD and /etc/shadow at the same time. Here's what happens, and it's repeatable:

Let's say my AD Id is "mark" and AD password is "BadWolf"; and the Outlook configured Id is "mark" and password is "littleSheep" and that this is the initial working scenario. In this case the credentials sent to Dovecot are username='mark', password='littleSheep'. Perfect.

Now, I change my AD password to "BlackBear", and do nothing else.

I log into the workstations with ID "mark", PW "BlackBear". No problem.

Now, I open Outlook. The credentials sent to Dovecot are now: username='mark', password=''

The password is empty! Neither AD PW "BlackBear", nor Outlook PW "littleSheep" are sent. I am REQUIRED to enter the Outlook password "littleSheep" in the Outlook dialog or I cannot get into Outlook.

Putting the AD password back to "BadWolf" doesn't help. Once the AD password has been changed, Outlook will send a blank password to Dovecot until the Outlook password is re-entered.

It does not do this if the user/pw is not a domain user.

THEREFORE, I can only conclude that Outlook knows that the configured user is a domain user and sends a blank password for authentication to the email server until the Outlook password is re-entered.

It has to be on the Outlook end and has to be yet another misguided Microsoft attempt at security.

I could work around this by a) having a different Outlook ID than AD ID, but for numerous reasons I don't won't to do that, or b) use a different email client on the Windows workstations, like eMclient (I have tested with eMclient and confirmed that it DOES NOT send a blank password to Dovecot when the AD password changes). But right now Outlook is the office standard.

So, back to square-one. Is there any way (registry setting?) to prevent Outlook from sending a blank PW when the domain PW changes?
Double check which mode of ceredential exchange method used between dovecot and outlook.  How/when is the AD credentials changed versus being used by outlook?
Avatar of Mark

ASKER

I stand corrected on one statement I made: "It does not do this [ask for Outlook password on change of domain password] if the user/pw is not a domain user." This isn't true. I created an account, smithtest, that is not a domain user. When I changed the domain login for the workstation's user (mark), Outlook DID ask me for the password for smithtest. So, it appears that upon change of domain passwords, Outlook (or GPO?) blanks all passwords for all Outlook accounts on that workstation.
Double check which mode of ceredential exchange method used between dovecot and outlook.  How/when is the AD credentials changed versus being used by outlook?
Outlook is not using AD credentials, period. It is either normally sending the ID/PW configured in Outlook, or sending a blank password if the Workstation's AD user's AD password changes. You still seem skeptical about this. How can I prove it? Dovecot log showing mechansim (PLAIN):
Sep 28 00:41:25 auth: Debug: client in: AUTH    1       PLAIN   service=imap    session=f65aT8cg+ADAqAA6      lip=192.168.0.2  rip=192.168.0.58        lport=143       rport=58360     resp=AHNtaXRodGVzdAB0cnVzdF9ubzE= (previous base64 data may contain sensitive data)

Open in new window

Here is the ID/PW received by Dovecot for the non-AD user I created for the normal case:

username="smithtest"
password='trust_no1'

Here is what Dovecot receives for the same user account when I changed the AD password for domain user 'mark', and logged into the workstation as 'mark', and opened Outlook for account smithtest:

username="smithtest"
password=''

These are actual printouts from Dovecot debugging. After receiving and trying to authenticate the last example, Dovecot returns a failed status to Outlook which then prompts with the user name/password dialog shown in the initial post. Upon entering "trust_no1" in the password field, outlook opens.
SOLUTION
Avatar of arnold
arnold
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Mark

ASKER

arnold:
Which version of outlook is in use 2007, 2010, 2013?
2010 and 2013.
Dealt with firms that have an AD and email external to them, the password change did not flush.
Was the AD also the email server? Was the server IMAP? Was the client Outlook? As I mentioned, non-Outlook clients (e.g. eMclient) do not re-ask for credentials. Only Outlook.
How does the user change password?
There are 3 ways the password gets changed:

1. I change it on the AD/DC using `samba-tool user setpassword username

2. I change it in RSAT, Users and Computers

3. The user's 90 day expiration period is up and the user is required to change his/her password.

All three ways of changing it results in Outlook asking for new credentials. (If there is a web bases way to change passwords, I'd love to know how)
does the user have a effectively a roaming profile?
Yes, I believe this is true. Users can log onto any workstation with the domain credentials and their desktop follows them.
Was the location where outlook stores the various files changed
No, the mail itself resides on the IMAP server. The calendars and contacts are in a .pst file on the NAS server so it can be accessed from any workstation. Don't know where the "profile" is stored or where the "password file" is. If there is something stored in appdata other than auto-completes, I don't know what it would be. Shouldn't much matter in this case as we are talking the same user on the same workstation when that user's Domain password changes.
I'm [not] aware of any GPO that would flush the credentials.
I haven't found anything either. Is it possible that if Outlook is not set up for Exchange it simply and unalterably blanks all Outlook account passwords?
Yes, outlook is being used 2007,2013.
The email server is external to the firm. No it is not part of the AD and does not server any internal AD function.
I remember your setup.

Outlook setup to get the email with the password saved. (is the password saved as part of the account creation, or as part of the prompt when user checks the email?)
tools accounts, new email account is the password provided here and saved?  Or is the account created without a password and when send and receive is triggered, the user provides their password and checks the save password option?

If the password is not saved as part of the account creation, when the user saves the password at the prompt it might only last until .... the AD password is changed.

Try the following. expire a test user's password. (RSAT ADUC user much change password on next login)
On login, change the password. Logout. Login. and see whether this also flushes the password when it is saved as part of the account creation.  Testing whether there is a difference where and when the password is set on the client side. i.e. while being reflected as saved subsequently, it might be "recorded" "saved by reference" that is "temporary" i.e. token depeneded on the AD password.

The other issue is that with IMAP, there are two or three tasks for the same account, synchronize the folder listing/subscription and their header contents.

the local/local settings (in the older versions pre vista/7)  is transient and is not replicated back to the share when user logs out. If not mistaken, the PST is commonly is stored in %userprofile%\local\Roaming\microsoft\outlook
Have you had a look in the registry as a matter of interest to see what is stored there for the passwords...

http://securityxploded.com/outlookpasswordsecrets.php

It would be interesting to see (well not post unless bogus info!) a before and after snapshot and what has changed.  e.g. one profile I have for a customer IMAP account is in a key like this for a 2013 Outlook:

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook\9375CFF0413111d3B88A00104B2A6676

Changing my user password (local account on this not domain) doesn't have any effect on remembered IMAP passwords for Outlook 2013 profiles here.

Steve
Avatar of Mark

ASKER

arnold:
is the password saved as part of the account creation, or as part of the prompt when user checks the email?
The password is saved as part of the account creation. See my image in message ID 41002423: https://www.experts-exchange.com/questions/28715152/Why-does-Outlook-ask-for-my-IMAP-server-password-when-my-domain-password-changes.html?anchorAnswerId=41002423#a41002423
Or is the account created without a password and when send and receive is triggered, the user provides their password and checks the save password option?
No. Account is created with a password. The user never has to re-enter this password when opening Outlook ... until they change their AD password.
Try the following. expire a test user's password. ... (etc)
Same thing. Did it two ways: 1) Expired via ADUAC, entered the new password, logged off and back on and opened Outlook. 2) Expired again, entered the new password, logged on and opened Outlook without logging off. In both cases I was prompted to re-enter the Outlook password.
If not mistaken, the PST is commonly is stored in %userprofile%\local\Roaming\microsoft\outlook
Normally, but I've moved the PST to a shared folder on NAS server. Otherwise, the user wouldn't be able to use Outlook from another workstation:
User generated imageSteve Knight: Whoa! Hats off to whoever squandered their summer navigating that labrynith! I checked that 9375CFF... key and sure enough, the IMAP information was there for account mfoley@ohprs.org in sub-key 00000013. As you suggested, I did a snapshot after changing AD password and before opening Outlook, and another after opening Outlook and re-setting the password. Disappointingly, Both snap-shots are identical. I also did a snapshot after opening Outlook, but before resetting the Outlook password. It too was identical to the other two.

Whatever is triggering Outlook to ask for this password (or more precisely, whatever is triggering Outlook to send a blank password to the IMAP server), it's not defined in this particular registry key.

Are we all out of ideas yet?
Do all three accounts have the same behavior When the password is reset/changed for the pictured account (you forgot to mask your public domain)?
Don't like to be beaten, it's not over yet!  

Apologies if already been suggested but... to discount any policies or anything else.  Have you got a new stock PC or rebuildable / virtual machine with just Windows & Office on it and not on your domain. Is that effected.

The other thing that gets right in the way of passwords is sometimes things that come bundled with the PC -- classic annoying one at a few places is the Lenovo Password manager but anti-virus apps also "help" of course with email scanners, firewalls etc intercepting IMAP and Pop comms etc.

None of that sounds right for your case though.  Sounds a bit like when a local password is changed forcibly from computer management rather than by the user and loses saved passwords etc. though havn't tried to see if that loses the Outlook one.

Steve
Avatar of Mark

ASKER

arnold:
Do all three accounts have the same behavior When the password is reset/changed for the pictured account?
Actually, only 2 accounts are used the mark@shouldhavemasked.org is the original  default pst created when the IMAP account was initially set up. I immediately pointed that to the pst on the X: drive (NAS) which held calendar and contacts exported from the original Exchange .ost. I never bothered to remove the initial .pst file. smithtest is the dummy account I set up as part of this question which is NOT associated with a domain user. To answer your question, yes, when domain user 'mark's AD password is reset I do have to enter the Outlook password for both Outlook accounts.
(you forgot to mask your public domain)
Yes, it was late and I was getting lazy.

Steve Knight:
Have you got a new stock PC or rebuildable / virtual machine with just Windows & Office on it and not on your domain. Is that effected.
Thanks for your persistence! Good question. I know that non-domain web clients such as webmail and iPhone/Android mail are not affected, nor are non-Outlook clients on the domain workstation such as eMclient, but I haven't tried connecting from Outlook from a non-domain computer. I'll give that a shot. Unfortunately, the only such computer I currently have has Outlook 2003, but I'll give it a shot anyway and post back.
Sounds a bit like when a local password is changed forcibly from computer management rather than by the user and loses saved passwords etc.
Well, actually, if you look at my testing in ID: 41015315 it doesn't matter if the user changes the password or if the AD Administrator changes the password. Now, if by "user changes the password" you mean via CTL-ATL-DEL or Start > Windows Security > Change a Password, then no, I haven't gone that route to test. I'll try that too.
Avatar of Mark

ASKER

arnold - well, sure, go ahead and delete it if you can. It was just for you to see the various Outlook datafiles. It's not critical to the discussion.
Avatar of Mark

ASKER

Tested with non-Domain workstation. Did not ask for Outlook credentials when I changed the AD password. Makes sense really. With no connection to the domain, and the workstation user not a domain user, how would it know? (although the Outlook User Name *is* the same as the domain AD user name) This workstation was also not on the local LAN/domain. I'll try that on Friday when I have direct access to the LAN. I suspect that won't be a problem either since iPhones connecting to the LAN in the office (and hence on the AD Domain) don't have the problem either -- although they don't use Outlook.
Change the login password to see whether the outlook password .....
Avatar of Mark

ASKER

yes - did that. Outlook did not ask for password. Sorry if that wasn't clear. Will try the same test this afternoon while connected to the domain LAN.
Double check, dovcote to make sure ntlm is disabled.
Another thing to try, when ad password changed, look at outlook account settings the save password option is unchecked and the stored password being empty before checking/connecting to the server.
I know you looked in that registry keys earlier but to make sure nothing there is what is being changed:

Export the whole HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook\ key using regedit.
Change your password and see that outlook has lost password
Export the whole key again to another reg file

fc reg1.reg reg2.reg > differences.txt
and look at differences.txt

I couldn't repeat this with changing passwords btw, though I can't get to domain PC that has IMAP account etc. until later in the week.

Steve
Avatar of Mark

ASKER

Steve Knight: were you ever able to test this on your domain PC with IMAP account?

I'm going to try the registry export/compare thing one more time tomorrow, but am not hopeful. Unless anyone has some new ideas I'm going to consider that it is a "feature" of Outlook that when the domain user PW is changed it auto-expires the Outlook PW if Outlook is not connecting to Exchange.
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Mark

ASKER

No solution, Thanks to arnold and knight for working with me