Back in December 2008, I wrote an article for Technet Magazine called “Understanding Proxy Authentication in AD LDS”. In this article I explained how proxy authentication works, walked through a couple of network traces, and took you through setting up your own proxy authentication lab that you can experiment with. Since then, I’ve received quite a few emails about this article and one of the common questions I’ve been asked is “Does this work across trusts?”.
The answer is yes, this does work across trusts. Here’s the scenario looks:
In this scenario, the LDS directory with the proxy objects are in the Contoso domain. However, the users that you want to proxy are in the Fabrikam domain. So even though the user account that you are proxying authentication to through AD LDS doesn’t exist in the same forest as LDS, you can still tie that user to an LDS userProxy object. The concept is simple, but this works in the opposite way that you would expect. What do I mean by this? In the most common scenarios, you might have a forest for user accounts and a separate forest for resources. The account forest is typically trusted by the resource forest. This is so the resources in the resource forest (e.g. a file share) can give the account in the account forest permissions. In the example of a file share, that account in the account forest has its SID added to the share’s ACL. This common configuration is illustrated in the figure below.
However, this is not how it works in proxy authentication. If you had LDS installed in the scenario above, you would probably consider the LDS directory to be a resource and include it in the resource forest. If you have the trusts configured in this manner, where the LDS forest trusts the forest with the user objects that you are proxying authentication to, your userProxy authentication will not work across that trust. The reason for this is because LDS isn’t treated as a resource in this scenario. Rather, LDS is storing the SID of the account in the account forest and telling the account forest to do the work of authenticating the user. Therefore, the resource forest needs to be trusted by the account forest and not the other way around.
So going with my example above, the Contoso domain needs to have an Outgoing trust to the Fabrikam domain, and the Fabrikam domain needs an Incoming trust from Contoso. After that, you can use the normal process for configuring userProxy objects, which I outlined in my article that mentioned earlier. You can check out that article by clicking here.