The PFE Exchange https://docs.microsoft.com/archive/blogs/schrimsher/feed.xml Tips and tricks relating to Exchange and Office 365 Fri, 29 Dec 2017 19:34:27 GMT en-US hourly 1 Guest Author Series: Securely Publishing EAC https://docs.microsoft.com/archive/blogs/schrimsher/guest-author-series-waller-securely-publish-eac Tue, 26 Sep 2017 19:06:02 GMT https://blogs.technet.microsoft.com/schrimsher/?p=106 Good day, everyone!  A common question we hear from customers is "How do I selectively disable access to the Exchange Administrative Center (e.g. from the Internet or well known internal URLs) while still allowing the /ecp virtual directory for features needed by standard users?"  A long time friend of mine (and one of the smartest geeks I know) wrote some content a while back that has been critically acclaimed by his customers and I wanted to share it here.

Without further ado, ladies and gentlemen, let's hear it for Butch Waller!

The formal guidance for disabling administrative access to the EAC for users coming in from the Internet is found here - https://technet.microsoft.com/en-us/library/jj218639(v=exchg.150).aspx. In that guidance, the suggestion is that the only method of achieving this is to "install a separate CAS server and configure it to only handle internal requests". While this is certainly an expeditious way to accomplish the task, it brings with it additional Exchange and Windows Server licensing along with the extra servers to update. Based on a modified version of the advice we have given Exchange customers over the years to create a second OWA virtual directory to accommodate FBA authentication behind an ISA/TMG firewall, I believe we can accomplish the desired outcome without the need for additional servers. Henrik Walther (who has worked for Microsoft for the last couple of years now) published a great series of articles on that original guidance I mentioned above on MSExchange.org - https://www.msexchange.org/articles-tutorials/exchange-server-2010/management-administration/enabling-forms-based-authentication-external-internal-owa-2010-users-exchange-2010-published-using-forefront-tmg-2010-part1.html. It is a great idea to digest that information before proceeding. Here are the steps I have processed through in my lab to accomplish administrative separation in the ECP website:
  • Add a second internal IP address to the CAS
    • If you have an unused NIC on the server, leverage it to add a second internal IP address
    • If no second NIC, add a second IP address in the advanced properties of Ipv4 on the NIC
  • Determine the internal only name you want to give the new website - e.g. contoso.com
    • Create an A record in DNS to point the new internal website name to the second IP address
  • On each server with the CAS role, open IIS Manager and create a new website. Any site name is acceptable.
  • Run the commands to create the new virtual directories
    • New-OWAVirtualDirectory -Server CON-E2013CAS -WebSiteName "IntECP"
    • New-ECPVirtualDirectory -Server CON-E2013CAS -WebSiteName "IntECP"
  • Add the new name to the Exchange server certificate that will be assigned the IIS service
  • Run the EMS command to disable full administrative access to the original ECP virtual directory in the Default Web Site
    • Set-ECPVirtualDirectory "CON-E15CAS\ecp (Default Web Site)" -AdminEnabled $False (users will still be able to access their mailbox options page via this site)
  • Verify access to the following:
With this in place, you can notify all Exchange admins in the environment about the new admin URL. Since this is only published inside the corporate network, administrative access will only be accomplished while on the LAN locally or via VPN, but the threat of compromised admin credentials is greatly reduced!  ]]> Counting and/or identifying unique instances of things in PowerShell https://docs.microsoft.com/archive/blogs/schrimsher/counting-andor-identifying-unique-instances-of-things-in-powershell Mon, 11 Jul 2016 12:46:52 GMT https://blogs.technet.microsoft.com/schrimsher/?p=35 did a good write up of that specific case (counting how many subfolders existed in each public folder in the hierarchy) back in 2009. Now, let's get the simplest case out of the way first before we make it harder.  :)  To simply count the number of things in a collection (and/or get Average, Max, and Min for numeric properties), pipe them to Measure-Object.  But that's not what this post is about...  If you're dealing with "pure" .NET or PowerShell objects and just want a quick and dirty way to get a count of things grouped by a certain property of the PowerShell object, there's a super simple way to do it: it's called Group-Object.  (This will be super familiar to any of you familiar with T-SQL and the 'GROUP BY' clause).  For example, to see how many files of various extensions are in my Downloads folder: 
PS C:\Users\Chris\Downloads> dir | Group-Object Extension
Count Name
----- ----
   24 .pdf
   14 .zip
    4 .mp4
...
I only put the "Count" and "Name" columns here, but for each one, PowerShell handily gives you a collection of objects matching that criteria.  Other use cases come to mind pretty easily... { Get-Service | Group-Object StartType } to show how many services are configured for each startup type, { Get-Process | Group-Object ProcessName } to see how many instances of processes are running (think svchost, wmiprvse, or MicrosoftEdgeCP), etc. This is all well and good for very simple scenarios.  But what if you need to do some calculations?  Or if you need to group by something that isn't a property of a well-formed PowerShell object? (We'll examine this case in detail in a moment...)  Hash tables to the rescue! Hash tables basically let you store a bunch of values together as a collection of sorts and index into it by name.  For example, 
PS C:\> $NewHashTable = @{}  #This is how you create a new hash table
PS C:\> $NewHashTable["42"] = "the answer to life the universe and everything"
PS C:\> $NewHashTable["MyName"] = "Chris"
PS C:\> $NewHashTable

Name   Value
----   -----
42     the answer to life the universe and everything
MyName Chris
Now, what does this have to do with counting, you might ask?  Well...  Since everything in PowerShell is an object, the values referenced at the keys (or "indexes") you define are strongly typed, therefore you can directly manipulate the results just like you would any other variable.  So...  I can do something like this: 
$count = @{}  #Create the hash table
foreach ($myObject in $myCollection)
{
    if ($count[$myObject.Whatever] -eq $null) # If this is the first time we've seen this [whatever],
                                              # meaning if the indexed value is $null...
    {
        $count[$myObject.Whatever] = 1;       # ... then we create an entry for this [whatever] and
                                              # set it to 1 (for the 1st time we've seen it).
    }
    else   # If it's not $null, that means we have seen it before, and the value there is how many times 
           # we've seen it...
    {
        $count[$myObject.Whatever]++;  # ... so since we're seeing it again, we just increment it.
    }
}
Now in this example, it would certainly have been simpler just to write { $myCollection | Group-Object Whatever } which would do the exact same thing.  But sometimes it's not that easy, and again, those cases aren't the primary purpose of this post.  For example, one of the things I use this for most frequently is looking for certain things in log files.  If, for example, I need to know a list of unique client IP addresses or how many times each URL was hit in a given IIS log file, I can't use Import-Csv and Group-Object because of the way the file/field headers are stored (the first few lines start with #, and the field headers aren't until line 4).  But, I can:
  1. Pull the log file into a variable using Get-Content
  2. Loop through the lines of the file with foreach
  3. Split each line by commas and store that line's "fields" in an array
  4. Index into that array by column number to retrieve the values I want from a given column
  5. Using those values to index into my hash table.
So, modifying my above example for an IIS log file: 
$uniqueIPs = @{}    #Create the hash table
$logFileContents = Get-Content E:\iis_logs\u_20160711.log   #Read the log file
$columnNum = 5 #I'm making this up for this example, but let's assume what I want is in the 6th column
               #No, that's not a typo -- indexes are 0 based so the 1st column is index 0, so the 6th column is index 5.  :)

foreach ($line in $logFileContents)
{
    $lineFields = $line.Split(",");
    $interestingValue = $lineFields[ $columnNum ];
    if ($uniqueIPs[ $interestingValue ] -eq $null) 
    {
        $uniqueIPs[ $interestingValue  ] = 1; 
    }
    else
    {
        $uniqueIPs[ $interestingValue ]]++;  
    }
}
Assuming the client IP address (or URI query stem, or HTTP response code, or whatever I'm looking for) is actually in the 6th column, the hash table will now give me both a list of all unique values -- which sometimes is all I care about, and a count of how many times each value occurred -- which may or may not be useful, but hey, it's "free".  So the contents of my hash table might look something like: 
Name        Value
----        -----
1.1.1.1     3,456
2.2.2.2     4,567
Want to make it even more interesting?  Say I'm looking at SMTP Protocol Logs (which I do a LOT to get a list of all unique IPs that are using a Receive connector), where the client IP and port number are in a single field (e.g. "1.2.3.4:5678") but I don't care about port number.  Since I'm running my own code to evaluate each line, no biggie.  I would just change this line: 
$interestingValue = $lineFields[ $columnNum ];
into something like this: 
$interestingValue = $lineFields[ $columnNum ];
$interestingValue = $interestingValue.Split(":")[0];
This, of course, is horrible PowerShell form because there's no error checking etc., but essentially here's what we're doing.  $interestingValue = $lineFields[$columnNum] indexes into $lineFields at $columnNum -- in my case, 5 --which gets the 6th value since it's a zero-based array array containing all of the comma separated values on the line, and stores that in $interestingValue.  Then, we're telling PowerShell to split $interestingValue by ":" and take the first result (e.g. before the ":", which in this example would be IP address). Now, to address the elephant in the room, I'm sure some of you out there are also thinking "Dude, why not just use LogParser?"  And yes, LogParser is definitely a more elegant and powerful solution.  However, in my 10+ years as a PFE and almost never touching the same server twice, I learn to take the "lowest common denominator" approach.  I can't assume that LogParser will be installed, I'm certainly not going to install it on a customer's production server outside of change control, and even though it's on my laptop, I may or may not have network access, and even if I do, I may or may not be allowed to copy a customer's log file to my PC for analysis.  Also, I go back to the point of this post -- this technique is generic and can be adapted to pretty much any scenario and is ubiquitously available. More tk... Chris * PS - I have a photography background, and in photojournalism, "more tk" is frequently short for "more to come".]]> Enabling TLS 1.1 and 1.2 in Outlook on Windows 7 https://docs.microsoft.com/archive/blogs/schrimsher/enabling-tls-1-1-and-1-2-in-outlook-on-windows-7 Fri, 08 Jul 2016 10:53:46 GMT https://blogs.technet.microsoft.com/schrimsher/?p=65 he BEAST attack against TLS 1.0.  :-) Working with this customer in support of a hardware load balancer deployment, their Outlook clients (OL2013 on Windows 7) could not connect to Exchange (EX2013 on Windows 2012 R2) through the load balancer (F5 LTM).  Autodiscover and Outlook Anywhere were both broken.  However, accessing the Exchange load balancer URLs (/owa and /autodiscover/autodiscover.xml) via Internet Explorer on the same Windows 7 clients worked fine, and Outlook on a test Windows 10 VM also worked just fine. We fired up Fiddler on the Win7 client and noticed that the Outlook connection was attempting to use TLS 1.0 (which was odd, since Windows 7 supports TLS 1.1 and 1.2), and that Schannel was returning error 0x80090326 (SEC_E_ILLEGAL_MESSAGE).  This Schannel error maps to several TLS protocol alerts, so we fired up Wireshark and noticed TLS alert 0x40, which is SSL3_ALERT_HANDSHAKE_FAILURE (don't be alarmed, the "SSL3" reference here is just a red herring).  Which means the "server" (the F5 in this case) couldn't accept some combination of options the client was proposing -- TLS protocol version, cipher suites, etc. Looking at the Internet Explorer traffic (which worked), we noticed that it was offering TLS 1.2.  The Outlook traffic on the Win10 PC (which worked) was also offering TLS 1.2 (remember, Outlook on Win7 was only offering TLS 1.0).  Now we were getting somewhere...  We checked with the load balancer administrators and they confirmed that they had proactively disabled TLS 1.0 to be "ahead of the curve" with regard to PCI DSS requirements.  This was harmless since, in their minds, "All of our client OSes support TLS 1.1 and TLS 1.2."  And well, they weren't wrong.  :) So what gives?  Well, I'll spare you the anguish that ensued (including setting Schannel registry keys like DisabledByDefault to 0 and Enabled to 1 for TLS 1.1 and 1.2 Client keys), but I ultimately found the referenced articles at the end of this post.  In summary, Office applications, including Outlook, use something called WinHTTP ("Windows HTTP Services").  Although Windows 7 (via Schannel) supports TLS 1.1 and 1.2, WinHTTP (and therefore applications built on WinHTTP) only support TLS 1.0.  The fix for this resides in KB3140245, released in March 2016.  Quoting the KB,
"This update adds support for DefaultSecureProtocols registry entry that allows the system administrator to specify which SSL protocols should be used when the WINHTTP_OPTION_SECURE_PROTOCOLS flag is used. "This can allow certain applications that were built to use the WinHTTP default flag to be able to leverage the newer TLS 1.2 or TLS 1.1 protocols natively without any need for updates to the application."
So, in summary, here are the steps to enable Outlook on Windows 7 and Windows 8.0 to use TLS 1.1 and 1.2 to communicate with Exchange (the same goes for other apps, i.e. Word, and other servers, i.e. SharePoint):
  1. Determine which TLS versions you want to enable, and determine the corresponding value for DefaultSecureProtocols (which we will add shortly):
    1. For only TLS 1.1 and 1.2, the value will be 0xA00
    2. For TLS 1.0, 1.1, and 1.2, the value will be 0xA80
  2. Install the KB3140245 update, either via Windows Update -- it's available as an Optional Update, or obtain via the Microsoft Update Catalog and deploy as you would any other updates (SCCM, etc.).
  3. Create a DWORD value called DefaultSecureProtocols in both of the following locations and set its value to the value determined in Step 1:
    1. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp
    2. HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp
  4. EDIT: Thanks to Ivan's comment below, I'm adding this step.  Per the TLS-SSL Settings TechNet article, be sure to create the DisabledByDefault DWORD value and set it to 0 in the following locations:
    1. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client
    2. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client
Reboot and you're good to go!  Here are some articles for reference: And some random notes:
  • This behavior only affects Windows 7 and Windows 8.0:
    • Windows Vista didn't include support for TLS 1.1 and 1.2 at all.
    • Windows 8.1 and Windows 10 enable TLS 1.1 and 1.2 for WinHTTP-based applications by default.
    • Windows 7 and Windows 8.0 support TLS 1.1 and 1.2 via Schannel (hence why IE is able to use TLS 1.1 and 1.2) but do not enable TLS 1.1 and 1.2 for WinHTTP-based applications without the aforementioned update and registry values.  Simple, right?  ;-)
One last note.  Although this update makes it possible for Outlook clients to use higher versions of TLS, at this time Microsoft does NOT recommend attempting to disable TLS 1.0 on Exchange servers themselves.  Please see this article for more details. More tk... Chris]]> Welcome! https://docs.microsoft.com/archive/blogs/schrimsher/welcome Thu, 07 Jul 2016 13:50:50 GMT https://blogs.technet.microsoft.com/schrimsher/?p=25