Multiple Windows domains, where the clients are in one or more domains and the Content Platform Engine server is in another, can be made to work with Kerberos if you take into account some special considerations. The first is that the domains (or realms in Kerberos terminology) must accept the identity established in another domain. This means that one domain trusts another.
There are three major ways that Windows systems have of establishing this domain to domain trust:
Domain forests were introduced in Windows 2000 Server and allow one or more hierarchical domain trees with parent/child relationships. In the forest, the trust is transitive in that one domain trusts another domain no matter where it is in the forest. Windows 2003 Server went one step further and allowed transitive trusts from one forest to another, although these inter-forest trusts are only available if both forests have been promoted to Windows 2003 mode. External trusts originated in Windows NT and are explicit trust links that are set up between one domain and another that are not transitive in that if domains A and B trust each other and domains B and C trust each other, then this does not imply that A trusts C or C trusts A. Two-way external trusts mean that each domain trusts the other (one-way external trusts are not supported by Kerberos).
These different type of domain to domain trusts work well with Kerberos authentication, although each domain must have its directory configuration set up in the GCD and the application server must have LDAP providers set up for each domain.
The second consideration for cross-domain Kerberos is that the SPNs will most often need an “@” qualifier, such as FNCEWS/myce01@MYDOM.EXAMPLE.COM. The shorter, unqualified SPN, like FNCEWS/myce01, can also be used in some cases, but might have problems if the server name myce01 is ambiguous as that name appears more than once in a forest or if that shorter form is used with an external two-way trust or transitive two-way trust. If the shorter SPN does not work, then the .NET client will likely get The network path was not found error.
Administration Console for Content Platform Engine also needs special handling for cross-domain Kerberos authentication as it tries to derive the SPN from the configured Content Platform Engine server URL. There will often be cases where the URL will need a fully qualified domain name to get the correct SPN. For example, a Content Platform Engine URL of http://myce01.mydom.example.com:9080/wsi/FNCEWS40MTOM will be turned into an SPN of FNCEWS/myce01@MYDOM.EXAMPLE.COM, which should work. A shorter, unqualified URL such as http://myce01:9080/wsi/FNCEWS40MTOM would produce an SPN of FNCEWS/myce01, which might not work. Additionally an SPN like FNCEWS/myce01.mydom.example.com could be used but this might not work in certain domain trust setups whereas FNCEWS/myce01@MYDOM.EXAMPLE.COM will work.
The Administration Console for Content Platform Engine handling of fully qualified DNS names works in the case where the Content Platform Engine system is in the same domain as the SPN identity account, but has problems when the Content Platform Engine system is either in a different domain or a Windows workgroup or is a UNIX system. The problem is that the DNS name, say myce01.mydom.example.com, will not automatically be defined as it is for systems that are members of the mydom.example.com domain. The solution is that a DNS entry must be manually added to map myce01.mydom.example.com to myce01's IP address and this new DNS entry must be available to clients.
A third note is that the Active Directory domain that the SPN identity user account is a member of is the domain/realm that should be defined in the krb5.ini (or krb5.conf) Kerberos configuration file on the Content Platform Engine server. It is not necessary to configure all of the potential client domains/realms in that configuration file.
A final note is that the client's domain from Kerberos's point of view is the domain of the logged on user, which will not necessarily be the domain of the client system. For instance, a client system is in domain NORTH that trusts the domain SOUTH and the user as logged onto the system as Frank@SOUTH; in this case Kerberos will use SOUTH as the client's domain.