Showing posts with label ActiveSync. Show all posts
Showing posts with label ActiveSync. Show all posts

Wednesday, February 18, 2015


Auditing mailbox actions for security and accountability

I was facing with a challenge. A company VIP with a few secretaries, and a few mobile devices was facing a serious issue. Calendar items were changing by themselves. Updates were sent to attendees but something changed the meeting date / time on the owner mailbox.
I was asked to find out what is the root cause.

In order to do that, there are two tools:

  1. The Microsoft Exchange Troubleshooting Assistant (Extra.exe) which will allow you to gather the information, but you will have to open a case with MS in order to get the results.
    The process requires to start the tool on the mailbox server of the effected user and target the user mailbox to perform a trace up until the issue occurs
    .
  2. Enable Mailbox Audit on the Exchange Server (2010)

    This will be the path we will investigate


    Enabling mailbox auditing is something that you can do by yourself. The audit can be used for security reasons (see who is abusing his/her assigned permissions to do something that they are not supposed to do), this includes Admins as well as Delegates, but also you can configure to audit the mailbox owner actions which can help with troubleshooting.

    The Audit is enabled per user mailbox and is saved as a part of the mailbox.
    The audit log needs to be enabled, the amount of days to save the audit can be specified (90 days by default), and most importantly, you must configure what to audit.

    In my case, the default owner audit setting did not include all types of operations so it was difficult at first to track the problem. (which was discovered by the trace due to the lack of information). However, after enabling additional audit items on the mailbox owner, it enabled tracking all actions and associating specific calendar actions with a specific ActiveSync mobile device.
    This eventually was found to be the cause of the above problem.

    So... Lets start this thing:

    First, log on with a user with administrative rights to the Exchange server to enable auditing for the user mailbox you would like to investigate.

    Now, Enable auditing on the mailbox with the command:

    Set-Mailbox UserName -AuditEnabled $true

    This command will enable auditing for Admin actions as will as Delegate actions, but not for mailbox owner actions.

    If you run the command Get-Mailbox UserName | select *audit*
    you will see exactly what is audited and what is not:

    AuditEnabled     : True
    AuditLogAgeLimit : 90.00:00:00
    AuditAdmin       : {Update, Move, MoveToDeletedItems, SoftDelete, HardDelete, FolderBind, SendAs, SendOnBehalf, Create}
    AuditDelegate    : {Update, SoftDelete, HardDelete, FolderBind, SendAs, Create}
    AuditOwner       : {}

    You may notice that by default the mailbox owner is not edited.

    If you will run the command: Set-Mailbox Username -auditowner $true
    you will see that the AuditOwner setting changes to:

    AuditOwner       : {Update}

    This is nice, but may not be enough to get all the information you want.

    Lets enable auditing for all options for both Admin, Delegate and owner:

    Set-Mailbox UserName -AuditEnabled $true -AuditAdmin Update,Move,MoveToDeletedItems,SoftDelete,HardDelete,FolderBind,SendAs,SendOnBehalf,Create -AuditDelegate Update,SoftDelete,HardDelete,FolderBind,SendAs,Create
    -AuditOwner Update,Move,MoveToDeletedItems,SoftDelete,HardDelete,Create

    Of course this will consume more space, however you only need to enable this when you need to investigate an issue or on a regular basis for specific users.

    Now, allow some time for the information to be collected.

    When you want to investigate, you will need to view or export the information in order to filter them more easily.

    The command that is used to retrieve the data is:
    Search-MailboxAuditLog UserName -ShowDetails

    This will give you tons of lines if information on every every action performed on every item.
    You can either use powershell to filter the output sent to the screen, or you can more easily send everything (filter or unfiltered) to a CSV file later to be opened in Excel or your favorite spreadsheet.

    Search-MailboxAuditLog UserName -LogonTypes Admin,Delegate,Owner -ShowDetails | export-csv c:\UserName.csv -Encoding utf8

    Please note that you can specify all type of logon types (as shown in the command above) or just specific logon type such as Delegate if you only want to get data about actions performed by the delegates.
    The command -Encoding utf8 will allow exporting of characters that can be identified for non-English (in my case Hebrew) in the item subject.

    You can additionally filter based of available properties, for example, add the following pipe between the Search section and the Export section in order to filter audit items in the calendar folder only | where {$_.FolderPathName -like "\calendar"} | 
    If English is NOT your default folder language you will need to modify the folder name based on your folder language.

    In the CSV file you will get all the detailed information on the actions performed.
    The information also include the client type, such as Outlook and even ActiveSync.
    The ClientInfoString provides the full Device information so you will be able to tell which device performed the action (this is very helpful in case that a few devices are user to sync with the same mailbox).

    Another option to view and filter audit logs for a specific mailbox is using the Exchange Control Panel (ECP) on your exchange server. For example user https://yourserver/ecp



    However, based on available options, it doesn't seem you can view owner actions using this interface.

    I hope this article will provide you with valuable information for troubleshooting.
    If you like this article you are welcome to drop me a line at: liranzamir@gmail.com

     


Monday, September 30, 2013

Testing your Exchange Server ActiveSync



Back in the old days, it was possible to download a kind of virtual Windows Mobile device which you could use to test your Exchange ActiveSync. Today you got more options.

Microsoft Remote Connectivity Analyzer
First, everybody must get to know Microsoft's Remote Connectivity Analyzer found here .















Microsoft did a great job with this tool which continues to evolve over time, providing more and more testing tools, from ActiveSync, to Autodiscover, Web services, Outlook Anywhere, POP/SMTP, Lync and OCS and even the Microsoft  cloud (Office 365).

This online tool often provides detailed information regarding the steps taken and what went wrong.


MobilityDojo.net - EAS - MD Tool
One of my favorite ActiveSync testing tools for some time is MobilityDojo.net 's EAS-MD tool. Click here
The tool, which is also updated by it's creators, supports Exchange 2007/2010/2013.
Unlike Microsoft's Remote Connectivity Analyzer, EAS-MD puts it's focus on ActiveSync and Autodiscover (partially since it still will not analyze Service Connection Point (SCP) data from Active Directory).

However, the thing I like most about this tool, is that it is simple to user, and you can use it anywhere on your network or the Internet.

before we go into a few screenshots, let me give you examples regarding how I put this tool to use:

  • Testing "Before" or "After" your proxy/router  When your infrastructure includes a reverse proxy / TMG server / firewall / router, and you want to troubleshoot ActiveSync connectivity "before" the device or server (on your LAN), or "after" the proxy (in your DMZ or Internet).

    Running synchronization tests with the tool in both locations (something you will usually not be able to do with a real device because of DNS name resolution and networking restrictions) will help you find out if the problem is with the Exchange server, proxy server or even with your ISP.

  • Testing specific CAS servers in a CAS Array 
    Without a direct testing tool, checking each CAS (Client Access Server) in a CAS Array for ActiveSync problems (independent of Exchange's own built in tests and logs), can be very challenging. Using the tool you can simply configure the individual CAS server you want to test.

  • Testing specific user connectivity issues
    If you administer Exchange servers, you probably know the case... A user cannot sync a device, and you have to help him as well as provide proof that your precious Exchange server is not refusing service to the user. All you need to do is have the user enter his credentials into the tool and basic ActiveSync connectivity tests will be performed with his / her mailbox.

  • Creating Fake devices
    Strange... but in an upcoming post I will show you that having too many ActiveSync devices partnered to a specific mailbox can cause you a and your users a lot of headache.
    Before removing real device partnerships (using the upcoming article), you can use the EAS-MD tool to create "Fake" devices with your test mailboxes so you can test the procedures of deleting device partnerships without really using multiple phones or tablets.

  • Checking your SSL Certificates
    The tool can also query and provide information regarding your SSL certificates. The information can also be copied as text for later troubleshooting.

I'm sure that other reasons can be found to use this tool, so lets have a look.

First download the small ZIP file containing the tool from here
The web site states the version as 1.6, but it is actually 1.7. The site also states that Windows 7/2008 are required, but I had no problem running in on Windows XP SP3.

Testing connectivity and Synchronization



The fist screen of the application is usually the one you need for ActiveSync testing.
In the connection parameters enter your (mailbox to be tested) domain credentials, the CAS server name
(This can be from the Internet or from inside your LAN), select to use SSL (who doesn't), and version of Exchange server.

On the upper right, select Trust all certificates. This will have you bypass sync issues that will likely happen when you are testing on your LAN (such as using self signed certificate which you did not bother to install the CA certificate to your test computer, testing a specific CAS server internal FQDN which is not a part of the certificate's Subject Alternate Name, and so on).

Now click Basic Connectivity Test to perform... basic test :-) this test will show you that you are able to talk to the CAS server over ActiveSync and authenticate.

Now you can click Clear Output to clean the screen.

Click Full Sync Test to re-authenticate and actually see a synchronization of the mailbox folders.


Testing AutoDiscover



This test is somewhat disappointing as it still cannot query Active Directory for SCP (Service Connectio Point) which is the source of AutoDiscover information for domain joined workstations.
However, if you rely on DNS records (internal or externally to your network), the tool will query them and show you if it was successful or not and what it found. Use the information for troubleshooting incorrect settings.

Testing the certificate chain


Unless you are using a self signed certificate, the SSL certificate on your Exchange server or proxy server came from a Certificate Authority (CA).
Certificate Authorities are servers which issue digital certificates to other CAs and/or the final SSL certificates (this is a very loose explanation). In order for a certificate to be trusted or "believable" by devices such as ActiveSync devices, web browsers and mail clients, the entire "Certificate chain" must be known and trusted.
Use this tool to query the certificate chain of your Exchange / TMG SSL certificate when the certificate may be the root of the connectivity issues.

Hope this makes sense...

Post your feedback. Please !