Bug 11632 - [4.3.2] - On Windows 10 OS it is not possible to create a POP / IMAP account in Outlook when using a domain user account
Summary: [4.3.2] - On Windows 10 OS it is not possible to create a POP / IMAP account ...
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB (show other bugs)
Version: unspecified
Hardware: x64 Windows 10
: P5 major (vote)
Target Milestone: ---
Assignee: Andrew Bartlett
QA Contact: Samba QA Contact
Depends on:
Reported: 2015-12-03 01:46 UTC by Pancho
Modified: 2016-02-18 15:52 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Pancho 2015-12-03 01:46:22 UTC
A first note is that this problem occurred on 4.1.4 so tonight I created a new 4.3.2 domain controller and tested again ...sadly it persists

I purchased a new laptop which came with Windows 8.1 and the free upgrade to Windows 10. I took advantage of this and upgraded to Windows 10 as a local laptop user. I then installed Outlook 2013 and tried to create an external POP email account. It worked 100%. I then joined the laptop to a Samba domain (as I have done many times before) and connected to the domain using a domain user MYDOMAIN\someuser

I then tried to create an external POP email account as I had before - and I was very surprised when the the login failed. I could visually see that the username was correct in the little failure popup so I retyped the password. At this point the connection fails with error message something like: 

Log onto incoming mail server (POP3): Your e-mail server rejected your login. Verify your user name and password for this account in Account Settings. The server responded: -ERR [AUTH] Authentication failed.

followed by....

Send test e-mail message: Cannot send the message. Verify the e-mail address in your account properties. The server responded: 550 Submission must be authenticated.

Naturally I thought I'd mistyped the password so I tried again ..and again ..and again, without success.

I then thought it was a Microsoft problem and engaged with Microsoft support and they couldn't work out what was wrong. 

I then tried engaging with my ESP (email service provider) and they confirmed that the connection was coming through, but being rejected at the authentication stage in line with what I was seeing. 

I rolled the machine back to factory settings on 8.1, re-upgraded to windows 10, and tried again thinking that maybe something had gone wrong with previous upgrade. Everything worked perfectly ...until I joined the machine to the domain and logged in as MYDOMAIN\someuser and tried to create a POP account.

I then downloaded Thunderbird mail client, tested it on the Windows 10 laptop with exactly the same account details as I was trying to use in Outlook, and it succeeded - I was able to send and receive mail 100%.

I tried creating the exactly same account in Outlook 2013 on my colleagues machines running Windows 7 - it worked perfectly.

At this point I was tearing my hair out as our users are on our domain but we use an external mail provider as we aren't interested in managing our own mail servers. I then thought ....I wonder if this may be a Samba related problem, so I searched the web and found this: http://www.eenyhelp.com/samba-office-365-windows-10-samba-ad-help-215792145.html?follow

which is pretty much exactly the problem I'm seeing. Sadly I couldn't find a bug logged regarding this so I thought may have been reported fixed by now, which is why I upgraded Samba to 4.3.2 but it has been of no help at all.

I would like to mention a few things in case not clear from above - this is not a mistyped password; I am very familiar with setting up POP and IMAP accounts - This is likewise not an account configuration mistake on my part, I know this area well and have tried and retried and retried. The error is reproducible 100% reliably.

I hope this provides what is required but if more information is needed, please let me know as soon as possible as due to time pressure, we are at the point of going out and purchasing MS AD - which is something I would really prefer not to do.
Comment 1 Andrew Bartlett 2015-12-03 02:11:25 UTC
Try this:

Comment 2 Pancho 2015-12-03 08:34:57 UTC
Hi Andrew, 

Thanks - sorry it's not looking positive but this is not something I've every done before. After a bit of reading about here is are the 2 commands I've run:

root@dc2:~/samba-4.3.2 # wget https://forge.univention.org/bugzilla/attachment.cgi?id=5986 -O 0001-s4-backupkey-Ensure-RSA-modulus-is-2048-bits.patch

root@dc2:~/samba-4.3.2 # patch -p1 < 0001-s4-backupkey-Ensure-RSA-modulus-is-2048-bits.patchpatching file source4/rpc_server/backupkey/dcesrv_backupkey.c
Hunk #1 FAILED at 759.
Hunk #2 FAILED at 776.
2 out of 2 hunks FAILED -- saving rejects to file source4/rpc_server/backupkey/dcesrv_backupkey.c.rej

...which doesn't look very happy.

There are 2 other files also on the univention page, vis a vis:

-  check_backupkey.sh
-  check_backupkey_ucs4.sh

and I'm not at all sure what do with these if anything.

Is there any possibility you could let me know if I'm doing something wrong, and if so, what I should be doing?

thanks very much in advance!
Comment 3 Andrew Bartlett 2015-12-03 08:44:56 UTC
To be clear, you need to run:

ldbdel -H ldapi:///usr/local/samba/private/ldap_priv/ldapi
"CN=BCKUPKEY_PREFERRED Secret,CN=System,DC=mydom,DC=com"

All the patches from univention are already in Samba 4.2 and 4.3.
Comment 4 Pancho 2015-12-03 09:50:28 UTC
Not good news I'm afraid...

On the domain controller server I ran this exact statement

root@dc2:~ # ldbdel -H ldapi:///usr/local/samba/private/ldap_priv/ldapi "CN=BCKUPKEY_PREFERRED Secret,CN=System,DC=originsystems,DC=local"

Sadly I didn't save the response, but it looked successful and said something like "key deleted" as I recall

I rebooted the server and ran ".../samba" manually after startup

To be sure of no residual client issues, I manually created a new domain user via windows using mmc and the domain snap-in.

I then connected as that new user on the windows 10 pc belonging to the domain and tried to create an Email Service Provider remote POP email account in Outlook, and it will still not recognise the password.

The thunderbird mail client connects perfectly (on the same laptop for the same domain user - I assume it ignores the domain info completely)
Comment 5 Pancho 2015-12-03 10:34:15 UTC
just a quick update with the exact command again, and the associated response that I forgot to record in the previous comment....

root@dc2:~ # ldbdel -H ldapi:///usr/local/samba/private/ldap_priv/ldapi "CN=BCKUPKEY_PREFERRED Secret,CN=System,DC=originsystems,DC=local"
Deleted 1 record
root@dc2:~ #
Comment 6 Pancho 2015-12-03 13:17:24 UTC
Hi Andrew, my apologies for bothering as I know I have no rights in this regard but we are under huge pressure to get this sorted out this side as I've already spent roughly 10 (unexpected and unplanned for) days trying to configure a single client laptop. The reason that it is so critical is that we are a small business and we are planning to upgrade another 3 laptops to Windows 10 x64 (and have already purchased 4 copies of Outlook 2013 to put on them). I am under pressure to make a call on whether to discard Samba as an AD controller, return the laptops, change our mail infrastructure, change our mail client etc etc - none of which are options I relish so am trying to delay the decision  ...but I'm out of time now.

So yes this is critical to me, but I don't know how critical it is seen to be from a Samba "must fix" perspective, and would therefore very much like to some idea as to the level of interest there is at Samba regarding understanding and fixing this problem. This will allow us to make appropriate business decisions.

As a side note, I should also say that if you need more information from me or you would like to webex onto the windows 10 machine and see the issue for yourself please do let me know.

With this in mind, are you possibly in a position to provide me a rough indication as to the Samba team's level of interest and a rough idea of complexity and thus delivery eta?

Thanks so much
Comment 7 Volker Lendecke 2015-12-03 13:19:04 UTC
(In reply to Pancho from comment #6)

Comment 8 Pancho 2015-12-03 13:42:06 UTC
(In reply to Volker Lendecke from comment #7)
Hi Volker,

Thanks, a bit more information would be very useful regarding the support link you pasted. Specifically, are you saying that this is a mis-configuration on our side rather than a bug? If so then I will happily call a local support company, however if it is indeed a bug then it would seem a bit futile to be engaging externals to look at it.

(if the latter, then as mentioned above, if it would be helpful for me to illustrate the problem live via webex I am more than happy to do so, please just let me know)

Could you possibly let me know which you think the problem is? 

thanks again
Comment 9 Volker Lendecke 2015-12-03 19:22:19 UTC
(In reply to Pancho from comment #8)

It's the urgency that you stated. If you have urgent support requirements, regardless of whether it's a bug or a misconfiguration, you should pay someone to focus on your problem.
Comment 10 Pancho 2015-12-03 19:58:18 UTC
(In reply to Volker Lendecke from comment #9)

Ah I understand where you're coming from now - thanks. 

I'm actually quite surprised that no-one else is hitting this problem as I would have thought that wanting single sign-on and share ability but not interested in dealing with email in-house would be a fairly common config for SMEs like ours, particularly with the trend I am seeing towards Office 365. Anyway, be that as it may, sadly I doubt I will get funding to bring people in to debug our AD environment. It is far more likely that my bosses say "you've wasted enough time on this with no result and we are going to be getting more windows 10 clients in - please investigate ms active directory as an alternative"

Thanks anyway for explaining - and my offer of doing specific tests / visually illustrating the problem still stands should you be interested.
Comment 11 Pancho 2016-01-27 10:43:28 UTC
Just an update that I have now tested this again on a different brand new Windows 10 machine and the problem persists - so it is not restricted to the original machine I hit it on.

A note also that this problem occurs both when <emaildomain> in user@<emaildomain> is the same as <SAMBA domain> and when it is different.
Comment 12 Pancho 2016-02-17 01:22:29 UTC
Just a quick update that I have just installed Outlook 2016 on a brand new Windows 10 x64 PC and face exactly the same problem.

With a hit rate of 3/3 problematic Windows 10 laptops, it's simply astounding to me that no-one else is reporting this.
Comment 13 Pancho 2016-02-17 16:09:53 UTC
Another update on this:

I have just been working for about 2 hours with a Microsoft Office 365 engineer trying to connect to an Office 365 mail account.

The problem manifestation remains identical in that I am able to do so successfully when the laptop is not a member of the Samba domain, but I am not able to do so when it it is a member of the Samba domain.

I did not tell the MS engineer that I was using Samba as the domain controller, and his conclusion was: It is probably caused by some conflict between the domain and the Windows 10 client, or alternatively some problematic group policy setting.

In case useful, with the laptop as a domain member, the connection error I received today when trying to use Office 365 POP3 is as follows:

Log onto incoming mail server (POP3): An unknown error occurred, error code: 0x80004005
Send test e-mail message: Cannot send the message. Verify the e-mail address in your account properties. The server responded: 530 5.7.57 SMTP; Client was not authenticated to send anonymous mail during MAIL FROM

When the laptop is not a domain member, it connects fine.
Comment 14 Pancho 2016-02-18 15:52:19 UTC
OK so an apology for wasting anyone who's read this bug is in order, as this problem is my fault entirely, and I am therefore closing this bug.

Before you start crying with laughter, please bear the following in mind:

1. I am not a network person and have been forced to the coal face through necessity
2. Everything worked 100% until we upgraded to Windows 10

Right, that said - here is an explanation of the problem and resolution:

Our business purchased a domain x.y.z and we have serverA.x.y.z out on the internet, with the appropriate DNS entry pointing to it.
We needed a domain within our office to handle single sign-on and general access, and in my ignorance I used x.y.z - ie. the same domain as we have externally.

Over time, our office has grown and AD has permeated, and while I realised there was a problem in that when we wanted to access our servers on the internet from within our office, because of the internal / external overlap we couldn't use the public dns, but had to replicate the name on our internal Samba DC.

I have been wanting to sort out the problem for some time, but due to the permeation have been putting it off.

...then (completely independently) I installed a Windows 10 client laptop, and Outlook wouldn't work.

Because the exact same version of Outlook had been working 100% to that point on Windows 7, and worked on Windows 10, I assumed the problem was something to do with the domain. Which in fact it was.

Where I went wrong, was that I thought Samba was at fault, rather than in fact my own stupidity and lack of knowledge.

I tried a million things as the trail hopefully illustrates below - and nothing worked. Yesterday, it occurred to me that it may be caused by Windows 10 being "more sensitive" to our internal/external domain name overlap issue, so I created a new internal Samba domain called int.x.y.z

I then connected to the new domain, opened outlook and created the pop mail account, thinking - oh well this is probably yet more time wasted.

Lo and behold - it worked! 

And it was at that moment I realised that the pop and smtp servers provided by our mail provider are pop.x.y.z and smtp.x.y.z  ...which I can only assume in Windows 10 fall prey to the internal / external domain name overlap.

And that is my sad tale - not to bore you with it, but hopefully to save any other poor ignorant souls from going through the same pain as I have.

Again, please accept my apologies - I am closing this bug as invalid