Mail continuously fails with Exchange

[Ccrew]

Looking at the current login screen, the current server is running Exchange 2010.

The screen shots you have posted, the login screen for the web interface in these is exchange 2007, so you can see the difference.

So it should work fine with mail since the backend is not Exchange 2003 or earlier.

But it's running 2010 behind Forefront TMG, so it's potentially not going to talk through. Depends on what they have set up in TMG. I don't run TMG, but I run a 2010/365 Hybrid Coex and for mine you have to be on VPN to hit the internal server with a client, or go through OWA. He could have something similar.

 

[scfc]

Mac mail can no longer access Exchange 2007 in combination with TMG

Hallo Petvas, and others

My company has just changed something in TMG which has caused all Mac user's to lose accessibility to Exchange: Both Mail and Outlook 2011 applications. Until that moment we could connect without a problem.

According to the system administrators they changed the following keys on TMG:
HKLM\System\CurrentControlSet\Control\SecurityProviders\SChannel\ Create a new DWORD value called AllowInsecureRenegoClients set to 0
HKLM\System\CurrentControlSet\Control\SecurityProviders\SChannel\ Create a new DWORD value called DisableRenegoOnServer set to 1

This seems to be related to disabling SSLv2 and enabling SSLv3

I was wandering if you have came across this issue? and if you point me to any relevant documentation or solution?


Kind regards,

Daniel

 

[hunterdg]

Exchange EWS CAS misconfiguration?

The administrator's answer is plain ridiculous.
In order to make Exchange work with Mac from the Internet you need the following things:

• The externalURL value on the Exchange CAS Servers has to be configured with the url of the published servers.
• The CAS Servers should be published (by using a reverse Proxy like TMG or an equivalent application firewall) to the internet
• The publishing platform has to use a valid public certificate, pointing to the name, as configured in the ExternalURL property of all CAS Servers.
• The EWS virtual directory should be configured with basir or/and Windows authentication.
• Autodiscover has to be properly published. It is always autodiscover.smtp.domain of the company. This name should point to the publishing platform, which in turn publishes the Exchange CAS Servers
  

I have hundred of customers and I have configured many Exchange Servers and had zero issues with Mac Mail.
This is easy stuff for any Exchange consultant!

Hello - I joined this forum just so i could ask you this question:

I'm a field IT/Systems/Automation engineer but lack expertise with Exchange.. I also use a Mac. The Corp IT guys hired a consultant to migrate us from Exchange 2003 to 2010, and I'm thinking he might not have done things the right way..

1 - we switched from NTLM to kerberos authentication and now remote clients are prompted to enter their passwords when opening Outlook - previously their workstation credentials were passed through.

2 - users receive the 'the exchange administrator has made a change to the server... you must restart outlook" message every time they change network connectivity (wired>wireless, wifi hotspot 1>wifi hotspot2.. etc)

3 - (my issue) - if I manually configure Mac Mail to use one of our two load-balanced exchange servers, it works fine, but 'Reminders' doesn't work.. If i allow Mac mail to auto-configure itself, it properly identifies the internal CAS server and the external OWA server, but fails to 'connect' with the SSL error message described above. Nothing i do, short of changing the server, works. I have 'trusted' the SSL certificate.

For what it is worth, my email address suffix is different from the primary dns suffix, because we are a subsidiary of the main company. This doesn't really cause any problems as far as i can tell.

any suggestions why connectivity through CAS fails from Mac mail? MS outlook in windows has no problems.

your help/suggestions are greatly appreciated!

 

[petvas]

Hello - I joined this forum just so i could ask you this question:

I'm a field IT/Systems/Automation engineer but lack expertise with Exchange.. I also use a Mac. The Corp IT guys hired a consultant to migrate us from Exchange 2003 to 2010, and I'm thinking he might not have done things the right way..

1 - we switched from NTLM to kerberos authentication and now remote clients are prompted to enter their passwords when opening Outlook - previously their workstation credentials were passed through.

2 - users receive the 'the exchange administrator has made a change to the server... you must restart outlook" message every time they change network connectivity (wired>wireless, wifi hotspot 1>wifi hotspot2.. etc)

3 - (my issue) - if I manually configure Mac Mail to use one of our two load-balanced exchange servers, it works fine, but 'Reminders' doesn't work.. If i allow Mac mail to auto-configure itself, it properly identifies the internal CAS server and the external OWA server, but fails to 'connect' with the SSL error message described above. Nothing i do, short of changing the server, works. I have 'trusted' the SSL certificate.

For what it is worth, my email address suffix is different from the primary dns suffix, because we are a subsidiary of the main company. This doesn't really cause any problems as far as i can tell.

any suggestions why connectivity through CAS fails from Mac mail? MS outlook in windows has no problems.

your help/suggestions are greatly appreciated!

The Mac Mail App doesn't support Kerberos, unless your Mac is joined in the AD Domain of your company. If it works as a standalone machine, then it is normal that you get auth dialogs..
The Exchange consultant should configure NTLM as a fallback mechanism too.
This is how I would set that up:
• Create an Alternate Service Account as type “Computer”: ASAEXC
• setspn.exe –A HTTP/mail.domain.com Domain\ ASAEXC$
• setspn.exe –A HTTP/powershell.domain.com Domain\ ASAEXC$
• .\RollAlternateServiceAccountPassword.ps1 -ToEntireForest -GenerateNewPasswordFor Domain\ASAEXC$
• Set the correct authentication method for all servers:
Get-OutlookAnywhere –Server <Exchange_SERVER> -ADPropertiesOnly | Set-OutlookAnywhere -InternalClientAuthenticationMethod Negotiate -IISAuthenticationMethods NTLM, Negotiate

If you are using a different email suffix as the main one, then you will probably get a warning that the autodiscover certificate doesn't match your domain, or that your client needs to be forwarded to a different autodiscover server (autodiscover.smtp.yourdomain). You can probably configure your Mac client manually, or suppress the warning.

 

[hunterdg]

Thanks for your response..
let me clarify a few things..
I misspoke when i said Kerberos - instead, i have been told that NTLM direct connection (RPC) has been deprecated in favor of Basic authentication and RPC-over-HTTPS/SSL proxy (outlook anywhere). I guess this is what prevents automatic domain credential passthrough authentication for remote (internet based) clients. I assume password prompts in this scenario are normal now.

First, regarding my Mac Mail client -
if i manually enter one of our two exchange servers into the 'server' field.. the mail client works well.

If i let it auto discover (which it does correctly i believe.. finding our 'CAS' server for 'internal' and our 'OWA' server for 'external')... then my Mac mail client is unable to connect.

this does not appear to be related to auto discover or domain suffix..

does this mean that the exchange servers are using NTLM and the CAS is not? or maybe something else that I'm not thinking of?

can i use domain\username syntax for basic authentication or must i use username@domain.com?

 

[petvas]

Thanks for your response..
let me clarify a few things..
I misspoke when i said Kerberos - instead, i have been told that NTLM direct connection (RPC) has been deprecated in favor of Basic authentication and RPC-over-HTTPS/SSL proxy (outlook anywhere). I guess this is what prevents automatic domain credential passthrough authentication for remote (internet based) clients. I assume password prompts in this scenario are normal now.

First, regarding my Mac Mail client -
if i manually enter one of our two exchange servers into the 'server' field.. the mail client works well.

If i let it auto discover (which it does correctly i believe.. finding our 'CAS' server for 'internal' and our 'OWA' server for 'external')... then my Mac mail client is unable to connect.

this does not appear to be related to auto discover or domain suffix..

does this mean that the exchange servers are using NTLM and the CAS is not? or maybe something else that I'm not thinking of?

can i use domain\username syntax for basic authentication or must i use username@domain.com?

Is your client connecting through your company's local area network or is it connecting via the Internet?
Your client should be able to resolve autodiscover.smtp.domain, otherwise it won't be able to configure itself successfully.

 

[hunterdg]

Is your client connecting through your company's local area network or is it connecting via the Internet?
Your client should be able to resolve autodiscover.smtp.domain, otherwise it won't be able to configure itself successfully.

Connecting via LAN. Neither my mac nor a domain-joined windows machine can resolve autodiscover.smtp.domain.com obviously i am replacing 'domain' with my domain DNS suffix

For what it's worth, Windows Outlook clients auto configure correctly, whether on AD-joined or not.

my Mac is NOT on the domain, but it does 'discover' the correct internal cas.domain.com and external owa.domain.com servers. unfortunately this fails to connect. I have to manually change internal server to vmail1.domain.com (one of our exchange servers) and then connection succeeds

 

[petvas]

Connecting via LAN. Neither my mac nor a domain-joined windows machine can resolve autodiscover.smtp.domain.com obviously i am replacing 'domain' with my domain DNS suffix

For what it's worth, Windows Outlook clients auto configure correctly, whether on AD-joined or not.

my Mac is NOT on the domain, but it does 'discover' the correct internal cas.domain.com and external owa.domain.com servers. unfortunately this fails to connect. I have to manually change internal server to vmail1.domain.com (one of our exchange servers) and then connection succeeds

If your email address is test.com, then you should be able to resolve autodiscover.test.com
Windows Outlook Clients use the SCP published in AD for autodiscover, but non domain joined clients use DNS, so that means that Autodiscover seems to be working ok.