Thank you for reading about my nightmare. I can already feel the love.
There has been some chatter centered around offering Outlook Anywhere up to users not on our domain. However, the chatter is more centered around the BIG-IP performing some SSO in the process so that Outlook Anywhere users can be prompted for their Smart Card credentials and then those credentials are passed back to the Exchange Server. Outlook Anywhere is configured to use NTLM.
Has anyone been successful or even a little insane to try this out? I am familiar with the on-demand cert auth and grabbing the certification info but the SSO piece, I have not had the pleasure of attempting.
Any advice is appreciated!
If the user does not provide the password in the frontend authentication you can only use kerberos as sso method. This provides a great user experience, look for kerberos constrainted delegation in the apm documentation.
We're reviewing the following document that describes what we're looking for but I'm not really following the "Machine Account" piece. Do you or anyone know what that is? Purpose?
NTLM auth terminates on the BIG-IP, for the BIG-IP to do Keberos authentication against the Exchange server it requires that Machine Account and to be joined to AD>
Im not sure this will help you very much though. As you seem to want to add smartcard (client certificate) authentication to NTLM authentication?
Where is the authentication done now? Directly to Exchange?
Im not quite sure how the Outlook fat client will handle a sudden certificate request. It seems possible on Exchange itself. But doing that on something in between is different.
For an idea look at this, but remember that is for a browser, not an Outlook client.
It doesn't currently exist in the environment. I just keep getting screenshot of iApp question and answer and no where does it just allow me to user Kerberos. It always says "NTLM" and only talks about the machine account in addtion to Kerberos.
The current environment is just using the BIG-IP to proxy traffic to the exchange servers. I guess my confusion is around the NTLM Machine account. Is that something created in AD? And then put on the BIG-IP?
Which documentation are you now working from?
In the one you posted earlier it shows you were you create the account. You do this from the BIG-IP and afterwards it exists in AD.
Configure a machine account You configure a machine account so that Access Policy Manager (APM) can establish a secure channel to a domain controller. On the Main tab, click Access Authentication > NTLM > Machine Account A new Machine Account screen opens.
Do you perhaps have an F5 partner or such who can help, getting this worked out through a forum is tricky.
We'll reach out to support on any hangups. I'm mainly just trying to understand how this works. It's not everyday you try to configure NTLM authentication through the BIG-IP, you know.
We're working through this: https://techdocs.f5.com/en-us/bigip-16-1-0/big-ip-access-policy-manager-authentication-methods/ntlm-...
Which explains a good part of it I believe.
To do NTLM authentication on the BIG-IP you need to have it domain joined. That is just a requirement, similar for other products that want to allow NTLM authentication from clients, like a web proxy, see:
Now we can join the domain by providing a Domain Administrative user name and password (one with permissions to perform domain joins).
BTW: I said earlier you require the machine account for the Kerberos authentication, that is my bad, but NOT the case. You need the machine account to do the NTLM authentication.