How does cross domain authentication work in a firewalled environment?

This is a simplification and the names have been changed to protect the innocent.

The assets:

Active Directory Domains
corp.lan
saas.lan

User accounts
[email protected]
[email protected]

Servers
dc.corp.lan (domain controller)
dc.saas.lan (domain controller)
server.saas.lan

A one way trust exists between the domains so user accounts in corp.lan and log into servers in saas.lan

No firewall between dc.corp.lan and dc.saas.lan

server.saas.lan is in a firewalled zone and a set of rules exist so it can talk to dc.saas.lan

I can log into server.saas.lan with [email protected] - But I don't understand how it works. If I watch firewall logs, I see a bunch of login chatter between server.saas.lan and dc.saas.lan

I also see a bunch of DROPPED chatter between server.saas.lan and dc.corp.lan. Presumably, this is because server.saas.lan is trying to authenticate [email protected] But no firewall rule exists that allows communication between these hosts.

However, [email protected] can log in successfully to server.saas.lan - Once logged in, I can "echo %logonserver%" and get \dc.corp.lan.

So.... I am a little confused how the account actually gets authenticated. Does dc.saas.lan eventually talk to dc.corp.lan after server.saas.lan can't talk to dc.corp.lan?

Just trying to figure out what needs to be changed/fixed/altered.

You don't really give us enough detail to answer this question with certainty. For instance, you don't give us any information about the exact nature of the traffic that is being blocked, what kind of traffic it is, forest or external trust, what ports are allowed between members of each domain, how exactly you are attempting to connect to the server, (Remote Desktop? Drive mapping?), etc. etc.

I'll take a stab anyway. Let's assume I am trying to use the Remote Desktop Client to connect to the server in the other forest. So we know that at least TCP port 3389 must be allowed between client and server.

(For reference, This document is basically the bible for how Active Directory uses Kerberos. One of the best TechNet articles on the web, IMHO. Here is another extremely relevant TechNet article about AD trusts for you to bookmark.)

During authentication using Kerberos, one of the final steps is that the client sends its service ticket and authenticator directly to the remote service that it is trying to access. (KRB_AP_REQ, and then an optional KRB_AP_REP back from the server to the client). If that cannot happen because of ports being blocked, then Kerberos authentication cannot happen. If I get a TGS referral back from my DC that directs me to your DC, and I cannot directly query your DC, I can't use Kerberos.

Perhaps that is some of the traffic that you are seeing being dropped.

So, what happens when Kerberos fails? The client typically falls back to the next security provider, e.g. NTLM. You can pass NTLM-protected credentials to the server right over the same port 3389. At this point the server just needs to validate your credentials. Please refer the section named "NTLM Referral Processing" in the second article that I linked.

NTLM Referral Processing

If the client uses NTLM for authentication, the initial request for authentication goes directly from the client to the resource server in the target domain. This server creates a challenge to which the client responds. The server then sends the user’s response to a domain controller in its computer account domain. This domain controller checks the user account against its security accounts database. If the account does not exist in the database, the domain controller determines whether to perform pass-through authentication, forward the request, or deny the request by using the following logic:

• Does the current domain have a direct trust relationship with the user’s domain?

  ◦ If yes, the domain controller sends the credentials of the client to a domain controller in the user’s domain for pass-through authentication.

  ◦ If no, go to the next step.

• Does the current domain have a transitive trust relationship with the user’s domain?

  ◦ If yes, pass the authentication request on to the next domain in the trust path. This domain controller repeats the process by checking the user’s credentials against its own security accounts database.

◦ If no, send the client a logon-denied message.

So ultimately, given the limited information that you've supplied to us, that is the process that I believe you are witnessing when you authenticate to a service in the other domain.