Creating a domain trust across a NAT’d network

According to This technet article, the default intra-tree trust architecture is rooted and transitive, not full-mesh.

My trusty copy of Windows 2000 Active Directory by Lowe-Norris does contain some confusing language that could be misconstrued as implying that a full-mesh trust system is set up, Maybe that's where your confusion is coming from?

I believe what you are seeing in the "Log on to" drop-down box on a member of Domain C, is normal behavior. That drop-down box will only show the domains that are adjacent, (transitive doesn't count,) but that should not prevent you from being able to log in to a DomainC member with a username of DomainA\joeqwerty or joeqwerty@DomainA. If it's very important for you to be able to see DomainA in the drop-down box when you are on a computer in DomainC, you may be able to achieve that with a shortcut trust.

This document has some pretty good nuggets of wisdom in it:

http://technet.microsoft.com/en-us/library/cc773178(v=WS.10).aspx

Such as,

Trust Search Limits

When a client searches out a trust path, the search is limited to trusts that are established directly with a domain and those that are transitive within a forest. A child domain, for example, cannot use an external trust between its parent domain and a domain in another forest. This is because a complete trust path must be constructed before a client can begin to work its way along the path to a requested resource domain. Windows Server 2003 does not support blind referrals; if a client cannot identify a trust path, it will not attempt to seek access to a requested resource in another domain. Child domains cannot identify external trusts or realm trusts to security authorities outside of their forest because the TDOs that represent those trusts are published only within the domain that shares the trust, not to Global Catalogs. Clients are therefore unaware of trusts that their domains share with security authorities other than their parent or child domains, and are thus unable to use them to access resources.

Edit

Based on your edit:

for instance, if I wanted to add a domain C user to the Remote Desktop Users Domain Local group in domain A I can't get there because I don't see domain C in locations in domain A.

This may be pedantic, but I personally would not add a user to the Remote Desktop Users Domain Local group at all. I would only nest security groups in there, not individual users/accounts. The TechNet articles linked to below also recommend using and nesting role-based access control security groups as best practice rather than assigning permissions for individuals to resources.

Anyway, from the TechNet link below:

• Groups with domain local scope can have the following members: accounts, groups with universal scope, and groups with global scope, all from any domain. This group can also have as members other groups with domain local scope from within the same domain.

And,

To group the users from one forest who require similar access to the same resources in a different forest, create universal groups that correspond to the global group roles. For example, in ForestA, create a universal group called SalesAccountsOrders and add the global groups SalesOrder and AccountsOrder to the group.

Two other things to keep in mind that might help you accomplish this goal are Group Policy Restricted Groups to add the desired group to Remote Desktop Users, and the "Allow log on through Terminal Services" user right.

You may not be able to graphically browse the accounts in the other forest by way of a transitive trust, but just type in the fully qualified account name, e.g. GroupInDomainA@DomainA.com or DomainA\GroupInDomainA, etc.

More resources:

http://technet.microsoft.com/en-us/library/cc772808(v=WS.10).aspx

http://technet.microsoft.com/en-us/library/cc776499(v=ws.10).aspx