Two Way Forest Trust from One Side Access Denied

Starting with my first in 1996, I've created countless Windows domain and forest trust relationships over the years.  The only thing that has ever caused a problem for me when creating trust relationships is network connection issues, firewall, routing, etc.  This week, what was planned to be a routine forest trust didn't work.

In this scenario, I was to create a trust in a forest where I am an Enterprise Administrator and a remote forest where I have no access but they had already created their side of the trust and shared the trust password with me.  Using Active Directory Domains and Trusts and using the same procedure I've always used, and had just used in my lab, verified with Microsoft's guidance from TechNet: Create a Two-Way, Forest Trust for One Side of the Trust I was prompted for a username and password at a point where I'd never been asked for a username and password before, after entering the name of the remote forest (step 4 in the linked procedure) and before being prompted to select the trust type (step 5 in the linked procedure).  This was a problem since I wasn't going to get an account or access in the remote forest.

Thinking that it could have just been some sort of GUI anomaly and that it may work in the command line or at least give me some more diagnostic information, I switched to PowerShell.

$targetforest = "contoso.com"
$trustpw = "password"
$Trustdir = "Bidirectional"
$localforest = [System.DirectoryServices.ActiveDirectory.Forest]::getCurrentForest()
$localForest.CreateLocalSideOfTrustRelationship($targetforest,$Trustdir,$trustpw)

Exception calling "CreateLocalSideOfTrustRelationship" with "3" argument(s): "Access is denied."
At line:1 char:1
+ $localforest.CreateLocalSideOfTrustRelationship($targetforest,$Trustdir ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : UnauthorizedAccessException 

It still didn't work, and essentially, I got the same error message.  After scouring the event logs on the local forest domain controller I found nothing to indicate what I was being denined access too.  I was still hesitant to blame the remote forest with what I had so far, but I started suspecting it.  Without access, it was hard to know for sure.

I used a combination of the Microsoft Message Analyzer and Process Monitor to get a better idea of what was going on.

Process monitor was really all I needed, here's the event:

High Resolution Date & Time: 1/26/2018 12:25:00.8212215 PM
Event Class: File System
Operation: CreateFile
Result: ACCESS DENIED
Path: \\devfardc01.contoso.com\PIPE\lsarpc
TID: 2152
Duration: 0.0005023
Desired Access: Generic Read/Write
Disposition: Open
Options: Non-Directory File
Attributes: n/a
ShareMode: Read, Write
AllocationSize: n/a
Impersonating: NT AUTHORITY\ANONYMOUS LOGON

Message Analyzer also had an access denied entry that was helpful

Source	Destination	Module	Summary
devdc01.tailspintoys.com	10.1.1.38	SMB2	Negotiate, Status: Success, ClientGuid: {xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx}, DialectRevision: SMB 3.0.2
devdc01.tailspintoys.com	10.1.1.38	SMB2	SessionSetup, Status: STATUS_MORE_PROCESSING_REQUIRED, NTLM, Flags: 0
devdc01.tailspintoys.com	10.1.1.38	SMB2	SessionSetup, Status: Success, NTLM v1 with extended session security, Flags: 0
devdc01.tailspintoys.com	10.1.1.38	SMB2	TreeConnect, Status: Success, Path: \\devfardc01.contoso.com\IPC$, TreeID: 0x00000001, Capabilities:
devdc01.tailspintoys.com	10.1.1.38	SMB2	Create, Status: STATUS_ACCESS_DENIED, FileName: lsarpc

These tools were more of a verification of what was happening with a little more detail to help find out why.  Process Monitor was telling me that the anonymous logon couldn't connect to lsarpc, but that is pretty standard.  Could it be that the remote forest EA has removed lsarpc from the anonymous access pipes?  I checked some standard security templates, which still had the lsarpc pipe accessible by the Anonymous Logon, but I thought it could still be a possibility so I tested it in my lab.

I removed lsarpc from their NullSessionPipes values under HKLM\system\currentcontrolset\services\lanmanserver\parameters on the domain controller representing the remote forest and rebooted.  This can also be done with group policy by removing lsarpc from the list in GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options Network access: Named Pipes that can be accessed anonymously. For the first time, I was able to reproduce the problem in my lab environment.

I tested two solutions to the problem, the first being returning the lsarpc entry to the NullSessionPipes values and the second was to use an enterprise admin account in the remote forest, and both allowed the trust to be created successfully.

This was kind of a strange issue and I wasn't able to find the answers with some in depth internet searching.  A lot of folks have trouble creating trusts in some way, but usually it is an easy problem like DNS, a firewall, or they aren't using an admin account, etc.