The connectivity is fine. The cross realm credentials actually work just fine for OWA. What they are not working for is Outlook Anywhere RPC over HTTPS access.
Can’t say for sure if this is supported config for OA. However can you try running your OA test in the link below using the credentials of the Kerb5domain and post what test it fails for?
11130 Sunrise Valley Drive, Suite 300
Reston, VA 20191
I have a configuration in which I have a Cross Realm Trust between a Windows 2008 Domain and an MIT V5 Kerberos Domain. If I attempt to login via OWA using: user@xxxxxxxxxxxxxxx then I am successfully logged onto OWA. However if I attempt to log onto Outlook Anywhere from an Outlook 2007 Client then the logon is unsuccessful and the following event is generated on the exchange mailbox server (not the CAS server). If I attempt the same logon using the user@xxxxxxxxxxxxx then the logon is successful.
In addition if the client computer is actually a member of the Windows Domain you can you use either the Windows or MIT Kerberos credentials to logon even when logged onto a local (non domain) user account.
What I am trying to accomplish is: A non-member workstation logon to Outlook Anywhere using the MIT Kerberos Server as a Authentication Source. The goal is to have the end users log on using their existing MIT Kerberos Principles. The MIT K5 Principles are mapped to Windows User Accounts using the Security Identity Mapping Applet from Active Directory Users and Computers.
An account failed to log on.
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@xxxxxxxxxxxxxxx
Failure Reason: Unknown user name or bad password.
Sub Status: 0xc0000064
Caller Process ID: 0x0
Caller Process Name: -
Workstation Name: WS1
Source Network Address: 192.168.80.128
Source Port: 1546
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.