Glen's Exchange and Office 365 Dev Blog

There has been a lot of information of late from security researchers and Microsoft themselves about Inbox rules being used to compromise workstations and for use in more pervasive security breaches. One of the more interesting one is is  https://blogs.technet.microsoft.com/office365security/defending-against-rules-and-forms-injection/ Which has a pretty nice EWS script  https://github.com/OfficeDev/O365-InvestigationTooling/blob/master/Get-AllTenantRulesAndForms.ps1 for enumerating Rules, specifically they are looking for a Client side rule exploit so this script is enumerating all the Extended Rule Objects in the FAI collection of the Inbox. In Exchange you can have Server side rules which run regardless of the connection state of any client or Client only rules which only run when the client is connected for more information see https://support.office.com/en-us/article/server-side-vs-client-only-rules-e1847992-8aa1-4158-8e24-ad043decf1eb .  So what the above...

First a little news about Exchange Identifiers that you may have missed (its not often that something like this changes so its rather exciting) When you access an item in an Exchange Mailbox store whether its OnPrem or in the Cloud you use the Identifier of the particular item which will vary across whatever API your using. Eg MAPI - PR_EntryId eg NameSpace.GetItemFromID(EntryId) EWS -  EWSId eg EmailMessage.Bind(service,ewsid) Rest -   RestId  eg  https://graph.microsoft.com/v1.0/me/messages('restid') The advice over the years has always been its not a good idea to store these Id's in something like a database because they change whenever and Item is moved. Eg if an Item is moved from the Inbox to a Subfolder in the Inbox it will received a different Id so whatever you have stored in your database suddenly becomes invalid and its not easy to reconcile this. However a new feature that has appeared in Exchange Online in Beta with the Graph API is imm...

The default Access Control Entry ACE in an Exchange Mailbox Folder DACL controls the rights that all authenticated users have to a particularity mailbox folder. Generally from a security perspective its something you don't want users to use as they may not understand when then set this ACE they are giving all people access to certain information. Eg Giving the default user reviewer rights to your Inbox means everyone in the Exchange org can now read mailbox in you Inbox which may not provide much privacy to your email. The following script will enumerate the permissions on every folder in a Mailbox and then produce a report of the folders where the default ACE isn't set to none. For most users the only folder that should show up in the report in the calendar folder. This script uses EWS but you could also use the Exchange Management Shell Get-MailboxFolderPermission cmdlet. To run this script you need to feed is with a CSV file that contains the SMTPAddress of the Mailboxes y...

Although there are a few better methods of doing this these days this is still handy to have especially if your running older versions of Exchange or you want to audit the raw ACE's that are being added by RBAC in Exchange 2010. Extended rights get used for a number of things EWS Impersonation is one, SendAs is another anyway here's an old C# sample I tripped over today. using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Collections; using System.Security.AccessControl; using System.DirectoryServices; namespace showImpRights { class Program { static void Main(string[] args) { DirectoryEntry rootdse = new DirectoryEntry("LDAP://RootDSE"); DirectoryEntry cfg = new DirectoryEntry("LDAP://" + rootdse.Properties["configurationnamingcontext"].Value); DirectoryEntry exRights = new DirectoryEntry("LDAP://cn=Extended-rig...

An interesting and useful new feature of Exchange 2010 is Administrator audit logging where each time a EMS cmdlet is run in the Exchange in the EMS, EMC or ECP this is logged. Within ECP you can do a search of the admin Audit logs and have the result emailed to you and what you receive in your inbox is an email with an a attachment called searchresult.xml. While this file contains a lot of great information there are a few problems with this format for administrators firstly is that OWA and Oultook will usually block the XML attachments so it can firstly be hard to get to the attachment. Secondly XML isn't the most readable format when it comes to trying to intemperate what was going on especially if you search across a larger number of days. So what I've put together is a GUI that first uses the EWS Managed API to find these any of these emails within your inbox and then gives you the option of exporting the raw xml or converting the XML to a CSV file or lastly using a sep...

Great strides have been made since Exchange 2007 SP2 with the introduction of more advanced audit levels into Exchange which have again improved in Exchange 2010 and again with 2010 SP1. Auditing however relies on a few things that after the fact of an event you may have wished to audit (or more likely a Superior wanting to know what mailboxes where accessed) . But like footprints in the sand when you walk along the beach many of the actions we do in Outlook do leave marks that the majority of people may not realize. One such mark in the sand that happens in your mailbox when using Outlook 2010 or OWA 2010 is when you access another users folder eg calendar, contacts etc is a wunderbar link gets added to the Common Views Root folder. What you can do with this little bit of information is deduce what other mailboxes a particular user has been access by enumerating the wunderbar links in the users common view folder. These wunderbar links are FAI (folder associated Items) so live in th...

Change is one of the universal constants that we all must constantly deal within our working lives, another one is poor communication and dysfunctions HR departments bit like death and tax's really. This often leads to us hapless mail administrator wondering why when company staff numbers remain stable the number of mailboxes seem to grow exponentially over time. Those that seek to find unused mailboxes are often confronted with a somewhat challenging task because of the nature of the challenging environment we work in for example sickness, maternity (and paternity leave), gap years and a number of other flexible work scenarios where mailboxes may appear to be unused but should not be deleted. Over the last decade I've had a few cracks at writing scripts to do this at first just looking at the number of unread email, the looking at both send and received and then finally looking at all of these and then the last logon time while all shared some modicum of success at time they f...

One of all the more useful reasons to learn scripting is the ability to turn information that is recorded in one format in a seemless useless rable of bits, into a format this is more useful to ordinary humans in everyday situations. One the examples of this are the IIS logs which in Exchange contain information about users accessing OWA, Accessing ActiveSync and Outlook Anywhere. Like everything in IT there are a few ways of tackling how you go about turing log information into something useful, one of the more popular ways to do this is using the Log parser which is a brilliant tool for those that aren't comfortable doing a lot of coding. You cant beat this tool for speed and efficiency and if your parsing logs often you should learn to use it. More recently the exLogAnalyser has been released which is interesting and it looks like a really great piece of coding that lacks a very very important ingredients for a tool like this. The documentation is spartan and it was written ...