How to configure 2 forest in Bigip APM

Where are NTLM and Kerberos being used? You said you have them both configured, but where? What authentication method are you using with the Exchange servers?

Ahh, okay. So you're doing NTLM authentication on the client side and Kerberos authentication (SSO) on the Exchange side. From the logs it looks like client side NTLM is working:

Session variable 'session.sso.token.last.username' set to 'w.test'

So it may just be a matter of Kerberos SSO issues between the two domains. Is "w.test" indeed a user in DOMAIN2? Can you put APM SSO in debug mode and try again?

You have a few different things going on here. In the absence of APM, a domain-joined client would attempt to pass NTLM (or Kerberos) credentials to a resource directly. But you've configured the Outlook client to use a different user, so the local credentials shouldn't matter here, only the once configured in Outlook. So you're saying that you're seeing a DOMAIN2 user NTLM authentication when you should be seeing a DOMAIN1 user NTLM authentication?

Well, it looks like w.test@DOMAIN2 is the user performing client side NTLM authentication to APM. If you're expecting some DOMAIN1 user, based on the Outlook profile, to be the one logging in, then you might have something misconfigured in Outlook. In any case, you're getting all the way to the Kerberos SSO functions, so you can be reasonably certain that client side authentication is working. Troubleshooting Kerberos SSO is a bit more involved, so you'll definitely want to enable APM SSO debug logging while you're working on this. That should at least give you more detailed logging. Are you hard-coding a domain name in the session.logon.last.domain session variable? If not, just for testing of DOMAIN2 users, try setting it manually in a variable assignment:

session.logon.last.domain = expo { "DOMAIN2" } 

Well, you're definitely doing client side NTLM. 😉

But you have a completely different error here that you previously described

Authentication with configuration (/Common/mail_Exchange.app/exch_ntlm_combined_https) result: user1@domain1.com (DP25): Fail (STATUS_NO_SUCH_USER)

Is user1@domain1.com the user you have configured in Outlook? Is this a legitimate user?

Okay, let's do this. Since this is an offline test is shouldn't hurt anything to add some static values for troubleshooting. We'll assume that client side NTLM is working, so we'll focus in on server side Kerberos SSO. Kerberos requires as input two populated session variables: by default, session.so.token.last.username and session.logon.last.domain. The first holds a domain user name (ex. bob), and the second holds the domain name (ex. DOMAIN1.COM). For the sake of testing, add a variable assignment agent at the end of the visual policy and hard-code these two values to known good values. For example:

session.sso.token.last.username = expr { "test.w" }
session.logon.last.domain = expo { "DOMAIN2.COM" }

Give that a try. Try it with known good DOMAIN1 and DOMAIN2 values. It won't matter what credentials you're using in the outlook client or what account you're logged in as, as the user values are hard-coded in the access policy. The point of this is to isolate the Kerberos SSO. If the APM log indicates that you get all the way to the SSL but fail, especially if DOMAIN1 values work but DOMAIN2 values don't, then you know for certain that there's something wrong with the SSO. That's where I'd start troubleshooting.

I'll assume that your Kerberos SSO profile uses the default "source" variables: session.sso.token.last.username and session.logon.last.domain. If so, then these are the values that you'll statically assign in the visual policy. You'll want to test with valid DOMAIN1 and DOMAIN2 user/domain information. You'll expect that DOMAIN1 user/domain information works, since it already does. The question then is if DOMAIN2 user/domain information works. Remember, you're hard-coding user information, so your Outlook profile config won't matter. It also means that this should definitely be an offline test, as anyone else accessing this environment could be logging in as the same user.

also dont want that any config has changed for domain1 because it is working.

Well, that's the thing. You can hard-code the user/domain information as I described for (temporary) troubleshooting purposes, or you can leave the config alone and attempt to troubleshoot through logs and captures. I can't tell, from what you've described, where exactly the problem is. I'm guessing that there might be a Kerberos cross-domain issue, so that's why I prescribed the above troubleshooting steps. The alternative is to gather captures from the client side of the BIG-IP (to watch NTLM traffic), from the server side of the BIG-IP (to watch Kerberos traffic), and attempt to correlate all that with APM and LTM logs.

Consider that APM is an authentication proxy. Client side authentication (in your case NTLM) produces a set of session variables if authentication is successful. Server side authentication (in your case Kerberos) consumes a set of session variables to do what it needs to do. Presumably (and again I'm not 100% sure of this), but your client side NTLM authentication is working for at least DOMAIN1 users, and potentially DOMAIN2 users. This produces a set of session variables that you can see in APM and session logs. I'm also assuming that Kerberos is working for DOMAIN1 users, so that information from the client side NTLM is plugging into the Kerberos SSO correctly. And that's where DOMAIN2 user information may be breaking. Of course I could be totally wrong and it's all simply working because DOMAIN1 users are passing NTLM tokens directly through the proxy, but I can't determine that without looking at captures.