Forum Discussion
azinser_7642
Nimbostratus
NimbostratusNTLM/ Outlook Anywhere/ Big-IP APM
We're using NTLM for Outlook internally. We wanted to use the APM to force clients to manually authenticate externally. NTLM worked internally, but when we took the Outlook client external we would get login box pop up over and over again with this error on F5 APM:
Feb 2 13:30:03 local/tmm3 debug tmm3[13431]: 01490000:3: Not basic authentication. Ignore received auth header
If we manually changed the Outlook client to Basic Auth it would work external through the APM (though it wouldn't work internal with the NTLM CAS). If we made a local hostfile entry for Outlook Autodiscover externally then every fourth or so time the log in box popped up it would be from Autodiscover and the client would reconfigure itself as Basic Auth. Then when we took the client internal it would have to be opened and closed a couple times to get back to NTLM. Not desirable issues for users.
Here's what we got from F5 support:
"The BigIP-APM only supports Basic Authentication from the Outlook Client. That's why it keeps on prompting for Basic Auth, whenever the client sends NTLM. Although the frontend is Basic, the Authentication on the backend (bigip -> exchange) is done on NTLM. "
-----------------
My question:
Has anyone had a smoother ride with this sort of set up? Any advice?
Michael_Koyfma1Cirrus
Is configuring internal users to go through an internal APM-enabled VIP an option? Also, is there a reason you have clients internally that are not using direct MAPI RPC and are using OutlookAnywhere both internally and externally? Please post more details, and we'll definitely help you find the right solution to this deployment snag.
azinser_7642To give you a bit more architecture overview: Internally our servers are being load balanced by a Cisco ACE module in a Cat6509 chassis. We're using the the F5s with APM/ASM to load balance into the DMZ. In the case of the CAS servers, internal users go straight to the ACE vIP and get load-balanced to the servers. External users hit the F5 which has a vIP for "loadbalancing" (reverse proxying in this case really) that points over to the single ACE vIP and then to the CAS servers.
This is a centralized solution and we're using OA as access over the WAN.
NTLM is being used internally so that users don't have to sign in to computer and then also e-mail. This was a selling point of Exchange2010 over our current Notes environment.
It was designed that internet users would still have to log in manually through the APM as security prior to them ever touching an actual server. This login does get relayed to the internet user.
It was designed that the F5 would exchange NTLM with the CAS farm. This proves to work as the CAS farm won't accept anything less and internet users configured for Basic -can- get connected.
It was designed that users wouldn't have to manually switch their devices between NTLM when internal and Basic when external... this did not work so well. If the client is configured as NTLM the F5 logs the error in my previous posts and just repeatedly prompts the user for name/password. Apparently the APM doesn't speak NTLM on client side, only server side? This makes no sense either because our deployment isn't the standard anticipated deployment and we have something bass ackwards... or because the F5 APM is not intended for this service. As it stands, if we were to change the CAS to Basic, there'd be no value in having the F5 able to use NTLM on the backend / with the CAS as NTLM there's no value in having the F5 able to use NTLM on the backend and -not- able to recieve it on the front end.
brad_11480I"m sure there must have been a solution for this. I had the same question today.. could we have a CAS farm where users would enter either NTLM or Basic depending on various conditions.. what subnet (external or internal), perhaps what hostname, etc. Thanks all.