3
No Domain joined PC will create a MAPI account
Question asked by Karl Jones - 9/7/2021 at 5:33 PM
Unanswered
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.

7 Replies

Reply to Thread
1
Douglas Foster Replied
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


   


0
Karl Jones Replied
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.
1
Kyle Kerst Replied
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
Technical Support Specialist
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
Karl Jones Replied
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...??
0
Douglas Foster Replied
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.

0
Karl Jones Replied
> 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.... :-)

0
Karl Jones Replied
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..!!!

Reply to Thread