Ews Client For Mac And Exchange 2010
Edit: This is not a question about DDOS, but a question about how to resolve a technical issue impacting only Mac clients of Outlook Anywhere.
Problem and solution are are now known, but I cannot link it here for some stupid reason of stackexchange limits. I can suggest googling : 'outlook anywhere We Get to Use Commandlets' and you should find the problem and solution described at charlietree.com
Fellow MVP Glen Scales has created a really nice example of the power of Exchange Web Services (EWS) to build an Exchange 2010 email client that you can run through a PowerShell script (for more details of the script, see Glen’s blog). I like this code a lot because it allows you to run an email. This article describes how to set up your Microsoft Exchange 2010 email account with Mac Mail. Note: Exchange 2010 runs only on Mac OS X version 10.6 or later. If you’re unsure about which OS X version you’re running, click the Apple icon located in the top-left corner and select About This Mac. Outlook 2010 access (focusing on Mailtips, OOF and freebusy, which all use EWS) Outlook for Mac (everything uses EWS) Blackberry (calendaring can use EWS). Then try to connect the offending applications, and see if they are successfully blocked.
Original question follows...
I'm not a Mac user, nor the Windows Admin, so forgive me if I don't have thethe nomenclature correct, but I'm trying to help another admin.
We run Active Directory and Exchange 2010. The name servers for our Internettop level domain are Linux with Bind. A subdomain like ad.example.comis the domain for AD, Exchange, etc.
In an attempt to prevent the DNS service on AD from being abused withDNS reflection DDOS attack method, port 53 was blocked at the firewall.It has the effect of blocking off site users with Mac Outlookfrom syncing with Exchange.
Blocking port 53 seemed the only way to go because disabling recursionon the Windows DNS causes failures to access the outside world, and unlikeBind, there is no feature like views.
Are other sites finding this is a problem, or does it hint of a configuration problem?
The admin mentioned that when traced, the connection information (perhapswith autodiscovery) came back with the address like exchange.ad.example.com,while the exchange server is also known as an address like exchange.example.com.He isn't sure if there is some place in the configuration to fix that. The ideabeing if we can get the 'ad' out of the host name, the Mac Outlook client would not need to talk to the DNS on AD.
Our Goal: to block AD's DNS servers from DDOS abuse.
Our problem: Mac Outlook clients require access to AD's DNS when off site.
Michael Hampton♦1 Answer
I'm still a little lost as to your explanation of why you are doing what you are doing with the port 53 block. Your internal DNS within your firewall should have no reason to be exposed to the internet, so you are right to block inbound port 53 to it on your firewall. Your external DNS should provide name resolution for your external (internet facing) domain name, including autodiscover.domain.com.
I think you are overly complicating things.
Exchange can be setup to handle Mac clients running Outlook 2011 easily, using the same autodiscover methods that Outlook Anywhere and smartphones use.
You'll simply setup the proper cert, make sure the internal and external URLs for Outlook Anywhere are correct, and make sure that the proper ports (80/443) are allowed through the firewall to the Exchange server, and that the authentication is setup for Outlook Anywhere.
Once you've done this, and you can confirm via test on www.testexchangeconnectivity.com that all is setup correct, then you should have no problems configuring a Mac client running Outlook at that point.
Some URLs to help you along:
TheCleanerTheCleaner
Not the answer you're looking for? Browse other questions tagged active-directoryexchange-2010macddosoutlook-anywhere or ask your own question.
-->Last modified: September 24, 2010
Applies to: Exchange Server 2007 | Exchange Server 2010
Administrators can manage access to Exchange Web Services (EWS) by using the Exchange Management Shell to limit access either globally for users and applications, for individual users, or for individual applications. Access control for EWS is based on domain accounts. When a connection is made with credentials that are authenticated by the local security authority, an error that indicates that only domain accounts can connect to the server is returned.
Configuring Access Control
Administrators can configure application access control for the clients that are used to connect to EWS in the following ways:
By blocking all client applications from connecting.
By allowing specific client applications to connect.
By allowing any client application to connect except for those that are specifically blocked.
By allowing any client application to connect.
Applications are identified by the user-agent string that they send in the HTTP Web request.
| Security Note |
|---|
Application-level blocking is not a security feature – the user agent string is easily spoofed. If an application is allowed access to EWS, the application must still present credentials that the server authenticates before the application is allowed access. |
Administrators can also configure application access control for mailbox owners that connect to EWS in the following ways:
By blocking or allowing an entire organization.
By blocking or allowing a group of users identified by a role-based authentication scope that excludes mailbox owners that do not have access to EWS.
By blocking or allowing an individual mailbox owner.
Specific access control settings override general access control settings. For example, if an organization allows EWS access but an individual mailbox owner is denied application access, the individual setting prevails and access is denied.
What Is Exchange Ews
Delegation and Access Management
Delegate users who do not have access to EWS will not be able to access the principal user's mailbox by using EWS, even if the principal user has EWS access.
If the delegate user has EWS access, the delegate will be able to access the principal user's mailbox through EWS even if the principal user does not have EWS access.
Impersonation and Access Management
Client applications that connect to EWS on behalf of mailbox owners might not be able to use the EWS settings of the mailbox owner. For example, an application that archives e-mail for a company has to connect to EWS no matter what the mailbox user's settings are. Other applications, such as mail clients, do have to use the mailbox owner's EWS settings.
Administrators should create an impersonation account for each application or application class that they use on their server. This will enable the administrator to configure the role-based access control scope for all uses that do not have EWS permissions.
To enable impersonation accounts, the administrator should do one of the following:
Add the Authenticated Users group to the 'Pre-Win2K Compatible Access Group.'
Add the 'Exchange Servers' group to the 'Windows Authorization Access' group.
Exchange Management Shell Cmdlets for Access Management
Administrators use the following Exchange Management Shell cmdlets to configure EWS access controls: