No Domain joined PC will create a MAPI account

Question asked by Karl Jones - 9/7/2021 at 5:33 PM

Answered

I have posted about this before https://portal.smartertools.com/community/a93900/cannot-create-mapi-user-in-local-domain.aspx the problem is still ongoing so i thought i would put this out to the community.

I don't want this to be a novel so will try to explain concisely. I am an independant contractor and the network Admin for a few clients.

I have been using Smartermail for several years, activesync and IMAP are used. Autodiscover DNS and SRV are setup and works for them.
I decided to try out MAPI. Activated the trial and a setup my own account from my (non domain joined) home/office laptop to connect to a AD server account. This was immediately successful so tried to add a user at my clients office LAN, all these computers are all domain joined.
FAILED, not able to create the MAPI account. Fiddler traces show 401 unauthorised user errors although all credentials are correct. All those same users can create and use Activesync and IMAP accounts.

Along with smartertools support and developers i have tried to diagnose the problem.

Recreated all DNS enries. Local split DNS reconfigured.

Fiddler traces show the correct sequence of autodiscover events and correctly communicating with the smartermail server (logs in the previous thread although not the newest ones)

I had new computers to install for new users so before i added the computer to the domain i created an outlook account.. BAM! straight away connected and works. Fiddler traces all great.
Added the computer to the domain, rather than create a new profile decided to logon with local computer profile and opened outlook that had previously worked.

FAILED! kept asking for user credentials but always failed

Tried the domain users profile, same result.

I am able to create a httpMAPI MAPI account in outlook on a non AD domain joined computer, as soon as i add it to the domain it fails, even on the previously added and working account. I can add a MAPI account to external devices, such as my cellphone and office laptop.

I have investigated GPO settings but can't seem to see what would effect the domain joined PC's. I have looked into LSA settings in the AD server registry but not seeing anything there either.

I have IISCrypt installed and best practises configured on the server. I use a LetsEncrypt SSL cert. I can connect from an external source and can connect from a LAN based PC but cannot connect from a domain joined PC.

Does anyone have any clue as to what is preventing the creation of the accounts? We are fairly sure it's returning a 401 unauthorised user even though correct credentials are supplied.

12 Replies

Reply to Thread

Douglas Foster Replied

9/8/2021 at 5:30 AM

To be certain that I understand the configuration:

Outlook on a PC joined to domainA cannot connect using MAPI to a SmarterMail system in domain B.

There is no trust relationship between domainA and domainB.

The most likely answer is that Outlook is invoking a Microsoft API which only talks to the joined domain and trusted domains. If this is correct, there is no workaround.

There is a slim chance that the issue is really an Autodiscover problem masquerading as a login problem, since Outlook seems to run Autodiscover on every startup. It is a slim chance because I would expect your Fiddler logs to have exposed this already.

We can hope that by playing with the Autodiscover registry settings, you can escape the problem. PreferLocalXML requires a local XML file, and gives you the most control. At minimum, I would start by excluding the O365 lookup. A fuller explanation is at the end of my post about "Streamlining Autodiscover" in this forum. The registry items are:

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Autodiscover]
"PreferLocalXML"=dword:00000000
“ExcludeLastKnownGood”=dword:000000
"ExcludeExplicitO365Endpoint"=dword:00000001
"ExcludeScpLookup"=dword:00000001
"ExcludeHttpsRootDomain"=dword:00000000
"ExcludeHttpsAutodiscoverDomain"=dword:00000000
"ExcludeHttpRedirect"=dword:00000000
"ExcludeSrvRecord"=dword:00000000

Karl Jones Replied

9/8/2021 at 6:47 AM

Thanks Douglas for the reply.
to be precise, "Outlook on a PC joined to domainA cannot connect using MAPI to a SmarterMail system in domain A".
There is no domain B but a LAN connected workstation, not joined to the domainA can create a MAPI account in Outlook.

I have already tried the registry entries you suggested as well autodiscover test tools that generally pass testing. Autodiscover does not seem to be the problem as all other implementations of autodiscover correctly pass MAPI, just not on a domainA joined PC.

Kyle Kerst Replied

9/8/2021 at 2:06 PM

Employee Post

@Doug: Hey there! I had suggested Karl post here as this looks to be a GPO/domain policy level issue as best we can tell. Fiddler traces show the same series of steps being taken autodiscover-wise on both a working (non-domain joined) and non-working (domain-joined) machines, and at no point do we find a hard error indicating why the account set up fails. I'm stumped, and at this point the only thing we can think of is that there may be an auth method or protocol version being disallowed somewhere in the domain policies. Just wanted to add some additional context here. Hope this helps!

Kyle Kerst IT Coordinator SmarterTools Inc. www.smartertools.com

Karl Jones Replied

9/10/2021 at 10:31 AM

Is there anyone out there that has a suggestion about what registry or GPO locations on the AD server that can be checked that would affect a domain joined computer and would cause a 401 Unauthorised user error. Would it even be a setting in IIS that gets changed for a domain computer...??

Douglas Foster Replied

9/11/2021 at 9:41 AM

Nothing specific. Here are some general ideas.

1) Assume the problem is related to the policies on the client device:

Determine all policies that apply to the PC. I infer that the problem is not user-sensitive, but if this is in doubt, also create a test user and determine all policies that apply to the user (including loopback processing.)

Create an OU called "Policy Exempt". Move the problem PC and the test user into that OU

In Group Policy Management, configure the OU to Block Inheritance. (This will be overridden if a higher-level policy is set to "Enforce" mode, so it would be helpful if Enforced policy could be non-enforced during testing.)

Test to see if the problem goes away. If so, then incrementally apply policies until the problem reappears.

2) Time Sync

Verify that time sync is working everywhere on your domain, including the problem PC. Time sync problems cause a multitude of issues.

3) Security Tokens

AD uses either Kerberos or NTLM, but I don't understand much of the details of that plumbing. As a long shot, I am wondering if one of those modes is disabled in your domain, but needed for MAPI. If the problem is there, the policy will be buried in your Domain Controller Policy, and nothing done on the PC side will matter.

4) The Big Guns

It might be worth dropping $500 on Microsoft support if they would take the case. Open it as an Office/Outloiok problem. But they may refuse to help when they find out that the back end is not their product.

Karl Jones Replied

9/13/2021 at 10:09 AM

> 1) Assume the problem is related to the policies on the client device:

The client device is only affected once joining the domain. As far as i know GPOs and AD server registry entries are the only choices for searching as they are the only items to affect a domain joined PC.

> Create an OU called "Policy Exempt". Move the problem PC and the test user into that OUIn Group Policy Management, configure the OU to Block Inheritance.

Funny you mention this. i was about to go down this route to determine if it was a GPO or some other setting from the AD server.

> 2) Time SyncVerify that time sync is working everywhere on your domain, including the problem PC. Time sync problems cause a multitude of issues.

Time sync is set on all the computers whether domain joined or not and all are correctly within the 5 min default setting.

> 3) Security TokensAD uses either Kerberos or NTLM, but I don't understand much of the details of that plumbing. As a long shot,

This is another area i was looking into, in fact the first area because i remember that this 2012 AD was migrated from an older SBS2003 server and i'm sure some security tweaks were done on it to changes LM, NTLM and Kerberos settings back in the day and i wonder if those settings were migrated. Not found anything yet but i'm not an expert on the guts of registry and GPO's

> 4) The Big Guns

I'd sooner rebuild the network.... :-)

Karl Jones Replied

9/21/2021 at 5:45 PM

So I removed the computer and User from the GPO's and resultant policy shows it was disabled. Still not able to create the MAPI account so it doesn't appear to be a GPO causing the problem. Unless it was created at the time the computer was joined to the domain and is permanent although no settings are inherited or enforced.

Seems to me that it is IIS authentication or a registry setting in server 2012 that overrules any GPO settings.

Back to the drawing board..!!!

Kyle Kerst Replied

9/22/2021 at 3:45 PM

Employee Post

Hey Karl! Sorry to hear you're back to square one on this one. A good test might following the response on this page:

https://superuser.com/questions/79566/whats-the-easiest-and-fastest-way-to-compare-2-registry-files

The user suggests configuring process monitor to watch for registry changes only, then monitor that for the condition that introduces your issues. So, you might be able to hook this up beforehand, connect it to the domain to see what its doing in the registry and related areas, then remove it from the domain and see if any of the changes don't get un-done.

You could also try comparing an export of the registry before/after the domain add using the steps also noted here. This might point out a difference in the registry that wasn't there before.

Kyle Kerst IT Coordinator SmarterTools Inc. www.smartertools.com

Douglas Foster Replied

9/22/2021 at 5:34 PM

About the account you are using for MAPI: is it now, or was it EVER configured as a domain admin? As I remember, Active Directory / Exchange has some hooks designed to prevent admin accounts from being used for email. I ran into this years ago, do not recall all the details from back then. But something tattooed the account that was difficult to work around.

It may only happen if your domajn has been used for Exchange, because we are not having the problem now.. Our current domain has only been used for SM, and we have admins using MAPI without problems.

Karl Jones Replied

9/22/2021 at 7:43 PM

That's a good point Douglas. I had a few different non domain admin accounts i was trying and they failed but the GPO exemption i was using my account and i am also a domain admin. The whole server 2012 was migrated in 2016 from a SBS 2003 which was using exchange. Only MAPI on SM is causing me this pain, everything else is working normally whether domain user or admin. I was told that many users have migrated from SBS 2003 or newer and they don't have this problem, although i tend to think that a registry entry migrated is what is causing this ussue, i have no idea what or where it is...!!!

Karl Jones Replied

9/22/2021 at 7:56 PM

Kyle i already have a registry comparison software on the test computer but the problem is that it works on the profile you are using... I can't make good use of that because i create a new domain user profile when i join the domain and the software does not complete its before and after because after a reboot you are logging into a new profile. Maybe i use the wrong software but i'll take a deeper look into the options brought up in that thread.

Karl Jones Replied

10/20/2021 at 10:02 AM

Marked As Answer

I am happy to report that I have, apparently, fixed the problem. Having enabled all auditing for Kerberos and NTLM authentications I set about using the test email accounts and using fiddler and the windows event logs on the server and client computer I was able to notice that all authentications were successful in the windows server and client computer logs and Kerberos tickets were properly exchanged but the MAPI account creation always failed. For obvious reasons, this seemed incongruous so once again I started digging into the GPO’s and Registry entries relating to system control sets and security and authentication.
I removed Restrict NTLM: Incoming NTLM traffic and Restrict NTLM: Incoming NTLM traffic from the HKLM LSA registry even though they were set to disabled.
Set LAN Manager authentication level to 4

Set Do not allow anonymous enumeration of SAM accounts to 1

I was still being frustrated and couldn’t create a MAPI account although all the test software said “success” and audit trails logs all seemed to give a success result

I was now noticing that on some of the audit logs I was seeing <username>@domain.local as a login credential and could not understand why it was not showing as <username>@domain.com.

I finally decided to look at the account settings, including the UPN option to the domain/forest. the Domain was originally setup as a .local domain (as are many company networks) but at some point in the past an additional UPN entry was made to add domain.com and each users account was created using that dropdown UPN. I changed that entry back to domain.local, saved the account settings and once again tried to create a MAPI account…… SUCCESS!

So from what I can gather the UPN setting in the user account settings which had been set for years and correctly gave the Outlook or other network software prompt to login by default as <username>@domain.com and worked for everything but Outlook, now needs to be set to UPN domain.local so when Outlook tries to prompt for credentials it defaults to <username>@domain.local and you have to click the change button to make the username <username>@domain.com and then input the password and then everything works and the MAPI account is created.

Confused, but glad i finally figured it out.

Back to Community Threads

Please leave this box unchecked

12 Replies

Reply to Thread

Tags

Related Knowledge Base Articles