Questions[trust-relationship](server)

I have two AD in which two-way trusts relationship(forest and transitive) exists. Trusted domain are trust1.com and trust2.com.

I created a AD-User(TEST1) in trust2.com using administrator credentials of trusted domain (trust1.com). But I am not able to rename the computer username from TEST1 to TEST2 using administrator credentials of trust1.com.

I can see ldap_rename is giving the error insufficient access of the user. The confusion here is the user can add using trusted domain credential, but not able to rename.

Parameters passed to ldap_rename function is 
int ldap_rename_s( ld, dn, newrdn, newparent, deleteoldrdn, sctrls[], cctrls[] );
dn : CN=TEST1,CN=Computers,DC=trust2,DC=com
newrdn: cn=TEST2
newparent: CN=Computers,dc=trust2,dc=com
deleteoldrdn = 1

Do I need to do anything else before doing this operation?

Setup

All computers running Windows Server 2019.

Domain A

Domain B

Forest Trusts

• DomainA.local trusts DomainB.local
• DomainB.local trusts DomainA.local

Scenarios

I present two scenarios below. Scenario A works as expected. I have a question about Scenario B.

Scenario A

[email protected] logs into WorkStation.DomainB.local and then from the Run prompt tries to open \\FileServer.

Q: Which FileServer will appear?

• a) FileServer.DomainA.local
• b) FileServer.DomainB.local

A: (b) [obviously -- we are using a DomainB user on a DomainB workstation]

Scenario B

[email protected] logs into WorkStation.DomainB.local and then from the Run command prompt tries to open \\FileServer.

Q: Which FileServer's shares will appear?

• a) FileServer.DomainA.local (because we are logged in with a DomainA username)
• b) FileServer.DomainB.local (because we are logged in to a DomainB computer)

A: None of the above. Instead an error message will appear:

\\FileServer is not accessible.  You might not have permission to use this nework resource.  Contact the administrator of this server to find out if you have access permissions.

The target account name is incorrect

Question

Can someone explain technically why Scenario B fails? Specifically:

1. How does the string "\\FileServer" translate to a particular computer?

   • Is DNS used? If not, what is used?
   • Does it resolve to FileServer.DomainA.local or FileServer.DomainB.local?

2. How SPN is related, specifically the fact that setspn -L FileServer shows non-fully-qualified names such as HOST/FileServer as well as fully-qualified entries such as HOST/FileServer.DomainB.local

My Guess

1. DNS (and arguably common sense) resolves FileServer to FileServer.DomainB.local
2. However, \\FileServer (CIFS/double-back-slash) resolves to FileServer.DomainA.local.
3. SPN (whatever that is) is "resolving" to FileServer.DomainB.local
4. The DomainA/DomainB mismatch in (2) and (3) is the source of The target account name is incorrect

Overview

We log into Gucamole with a User from DomainA where we select a rdp-connection to a server from DomainB.

Trusts

DomainA to DomainB and vice versa:

• Type: External
• Kerberos AES Encryption support: no
• Direction: two-way
• Transitivity: no
• Authentication: Domain-wide

Permissions

User from DomainA has been joined to the local Remote Desktop Users group on the Server from DomainB. Have temporarily also tried with the local Administrators group.

Guacamole

The whole setup was not done by me and i don't have a lot of insight since it is managed by another team. What I know is that it works fine with a User from DomainA to a Server from DomainA. Users log into it with the upn and use 2FA by OpenOTP. If you guys think it would help to share some configurations of Guacamole let me know what you want to see and I check with the team.

Connections on Guacamole

• protocol: rdp
• hostname: ip of server from DomainB
• port: 3389
• username: ${GUAC_USERNAME}
• password: ${GUAC_PASSWORD}
• domain: blank
• security mode: NLA
• disable authentication: no
• ignore server certificate: yes
• everything else is set to default / not configured

Of course have we tried multiple different settings.

Symptoms

Now here is what happens.

• I log into Guacamole with the User from DomainA
• receive OpenOTP push and confirm
• am logged into Guacamole and select the connection to the server of DomainB
• receive error message:

The remote desktop server is currently unreachable. If the problem presists, please notify your system administrator, or check your system logs.

• after a few retrys I sometimes get this message:

This connection has been closed because the server is taking too long to respond. This is usually cuased by network problems, such as a spotty wireless signal, or slow network speeds. Please check your network connection and try again or contact your system administrator.

• and now comes the funny part that drives me crazy: I am able to log into the server of DomainB with the User from DomainA via direct rdp and if I do so, keep the connection open and start the connection on Guacamole, I am able to take over the session!!

Logs

Guacamole Logs show absolutely nothing useful.

Windows Security Log shows this event on the login error:

EventID 4625, Logon
An account failed to log on.

Subject:
    Security ID:        NULL SID
    Account Name:       -
    Account Domain:     -
    Logon ID:       0x0

Logon Type:         3

Account For Which Logon Failed:
    Security ID:        NULL SID
    Account Name:       User (correct)
    Account Domain:     DomainA (correct)

Failure Information:
    Failure Reason:     An Error occured during Logon.
    Status:         0xC000005E
    Sub Status:     0x0

Process Information:
    Caller Process ID:  0x0
    Caller Process Name:    -

Network Information:
    Workstation Name:   f7054e3b9dd7
    Source Network Address: Guacamole-Server-IP
    Source Port:        0

Detailed Authentication Information:
    Logon Process:      NtLmSsp 
    Authentication Package: NTLM
    Transited Services: -
    Package Name (NTLM only):   -
    Key Length:     0

This event is generated when a logon request fails. It is generated on the computer where access was attempted.

The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

The Process Information fields indicate which account and process on the system requested the logon.

The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request.
    - Transited services indicate which intermediate services have participated in this logon request.
    - Package name indicates which sub-protocol was used among the NTLM protocols.
    - Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

Troubleshooting

Now at this point I don't know where to set my next focus. We have tried multiple settings on the Guacamole rdp connection. Did a lot of research online but were not able to find examples with information where someone tries the same thing as we do. Since regular rdp works fine we think our trusts and permissions should be fine.

Can you guys give me any hints in which direction I should investigate?

Does someone use Guacamole in a similar setup?

Edit Additional Event Viewer info suggested from User Swisstone:

RemoteDesktopServices-RdpCoreTS
08:38:23 Info: The server accepted a new TCP connection from client *Guacamole-IP*:53494.
08:38:23 Info: Connection RDP-Tcp#78 created 
08:38:23 Info: Interface method called: PrepareForAccept
08:38:23 Info: Interface method called: SendPolicyData
08:38:23 Info: PerfCounter session started with instance ID 78
08:38:23 Warning: TCP socket was gracefully terminated
08:38:23 Info: Interface method called: OnDisconnected
08:38:23 Info: The server has terminated main RDP connection with the client.
08:38:23 Info: During this connection, server has not sent data or graphics update for 0 seconds (Idle1: 0, Idle2: 0).
08:38:23 Info: Channel rdpinpt has been closed between the server and the client on transport tunnel: 0.
08:38:23 Info: Channel rdpcmd has been closed between the server and the client on transport tunnel: 0.
08:38:23 Info: Channel rdplic has been closed between the server and the client on transport tunnel: 0.
08:38:23 Info: The disconnect reason is 14

TerminalServices-LocalSessionManager
nothing during this time

TerminalServices-RemoteConnectionManager
nothing during this time

Forgot to mention, the Server is 2019 Version 1809

Edit2

Ok, I got it working now by changing the security mode on the connection to tls. I remember having tried tls before when it was not working. Maybe some of the changes I did during the whole troubleshooting process made the difference. By now I can't tell what it was.

I came to this "solution" by randomly trying different options to connect using freerdp after I discovered that it is used by guacamole for rdp connections.

Does someone see any concerns in using tls instead of nla in this case?

I've created AWS managed AD and try to create trust with my on-prem. After a lot of tries and solid research on the internet I keep getting this error :

The remote domain ***** is not reachable. Please ensure your security group settings are correct and your conditional forwarder is configured properly.

Security groups looks good, conditional forwarder too, all prerequisites are fulfilled. I'll be grateful for tips and help in solving the problem

I am trying to set up a forest trust and use ADMT to migrate users using this set of instructions; ADMT Instructions . I am having issues getting the two-way trust to work. Domain A (testad.domain.org) is not allowing me to add users to the builtin/Administrators group on domain B (target.migrate.org). I can select domain A trust as a location, but when I go to search for a user it says it cannot find it. Additionally when I attempt to add Domain A as a nav node in AD Admin Center it says I do not have permissions. I am able to verify the two way trust without issues.

I've read that firewall may be an issue so I disabled it on both sides temporarily and still the same behavior.

I set up a one-way incoming trust on domain A to domain B. I was able to add a domain A user to domain B's administrator group, but I was prompted for credentials for a user on Domain A to access the trust. I can also add domain A as a nav node in AD admin center on domain B. When I convert the trust to a two-way, it breaks again.

I was able to work through the entire set of instructions on two clean domains, so I know they work. Additionally, I was never prompted for credentials when adding users to the builtin/Administrators group through the trust both ways.

I'm thinking there is some configuration on domain A (testad.domain.org) that is cuasing the issue. I can't seem to pinpoint where it would be.