Glen's Exchange and Office 365 Dev Blog

This is a follow-on from my last post on  Modifying your EWS Managed API code to use Hybrid Modern Authentication against OnPrem Mailboxes  . If instead of the EWS Managed API you are using EWS Proxy Code (generated from the EWS WSDL) and you want to migrate it to using Modern Authentication for Office365 and/or Hybrid here's a method you can use using the MSAL Authentication library . Unlike the EWS Managed API the WSDL generated proxy classes and specifically the ExchangeServiceBinding class doesn't have any provision to use Token Credentials. One way of implementing this in .NET is to take advantage of  Polymorphism and create a new class that is derived from the ExchangeServiceBinding class and then override the method GetWebResponse from this class (which is actually derived from the SoapHttpClientProtocol class which contains the actual method we are going to override  https://docs.microsoft.com/en-us/dotnet/api/system.web.services.protocols.soap...

In this post I'm going to look at what you need to do in your EWS Managed API code to support using Hybrid Modern Authentication where previously you've been using Basic or Integrated Authentication (both of which are susceptible to password spray attacks). If you don't know what  Hybrid Modern Authentication   is put simply it brings to Exchange OnPrem email clients the security benefits of Modern Authentication offered by Azure AD to Office365 tenants. If your already using OAuth to connect to Office365 you have most of the work already done but you will still need logic to ensure you have the correct Audience set in your token when that code is used against an OnPrem Mailbox.  Prerequisites  You need to be using Hybrid Exchange or more specifically  Hybrid Office 365 tenant is configured in full hybrid configuration using Exchange Classic Hybrid Topology mode ref  https://docs.microsoft.com/en-us/exchange/clients/outlook-for-ios-and-android/use-hybr...

To round out the Vcard export scripts as many people are still running Exchange 2010 here's a Remote powershell script that will allow you to export Mailboxes (or contacts) from Active directory to Vcards and also include the GAL Photo from the AD thumbnail property if set.  The script uses the Get-User Exchange Management Shell cmdlet to get all the Mailboxes details to include in the Vcard file and also use LDAP to read the AD thumbnailPhoto (if its been set). before you run this script make sure you set the following variable to the directory you want the vcards exported to $exportFolder = "c:\temp\" You need to run this script from within the Exchange Management Shell or a Remote Powershell session I've put a download of this script here the code looks like $exportFolder  =  "c:\temp\"   $Mailboxes = Get-User -RecipientTypeDetails UserMailbox    foreach($Mailbox in $Mailboxes){    ...

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...

If you have been administrating mail systems for a while (and then some) then you have probably had to do a bulk update or two of one or more AD properties like phone numbers and address information. Depending on the time you have and your skill at building scripts you may have had some good and not so good experiences at this. The frustrating thing can be a script you build for one problem maybe be completely useless for the next and you may find yourself again spending time you don’t have building another script. Well because I’ve had to do this one too many times I came up with the following little script that allows dynamic matching of columns in a CSV file to import data into Active Directory. The other thing this script does is actually checks the current value within AD as not to update an already existing property and it’s a latched script so doesn’t allow you to update anything without clicking yes. The later could get frustrating but it’s a lot less frustrating then trying to...