Office 365 Endpoint IP Address and URL Service

In the era of the cloud, service releases and changes are nearly constant. Microsoft Office 365 could not be an exception, especially with the large and increasing number of services and millions of users.

But some of those changes and releases sometimes cause issues with on-premises infrastructure that is not property configured. Today I am going to focus on the networking side of things and talk about allowing access to Office 365 services from firewall and proxy servers.

The first thing you'll need to permit access to Office 365 services from your on-premises machines is to know the service endpoints and by endpoints I mean IP addresses and URLs. Fortunatelly, this information is available from Microsoft in this  article so the only thing you'll have to do is read through it, get the information for the services you're using and configure your proxy server and firewall.

That's easy, what happens though when that information is updated? This is where the problems start. First of all, you'll have to know that a change is about to happen (or already has) and then update your configuration accordingly. Easier said than done...

In the past, Microsoft published and XML file that contained all the endpoints and their details but for a while now it has been replaced by a web service. You can query this web service and get the latest version of the endpoints and even proxy PAC files.

Let's see how we can get this information using Powershell!

First off, we create a new GUID for the request and then request the data from the service. The responce is in JSON format and in order to make things easier, we convert it to an object.

$clientID = [GUID]::NewGuid()

Invoke-WebRequest -Uri "https://endpoints.office.com/endpoints/worldwide?clientrequestid=$($clientID.ToString())" |
    ConvertFrom-Json

You should get an output similar to the below: 

id:1
serviceArea:Exchange
serviceAreaDisplayName:Exchange Online
urls:{outlook.office.com, outlook.office365.com}
ips:{13.107.6.152/31, 13.107.18.10/31, 13.107.128.0/22, 23.103.160.0/20...}
tcpPorts:80,443
expressRoute:True
category:Optimize
required:True
id:2
serviceArea:Exchange
serviceAreaDisplayName:Exchange Online
urls:{smtp.office365.com}
ips:{13.107.6.152/31, 13.107.18.10/31, 13.107.128.0/22, 23.103.160.0/20...}
tcpPorts:587
expressRoute:True
category:Allow
required:True


Now that we have the array of the endpoints and their information we can automatically update the settings on the networking devices and make sure that our users and systems can reach the Office 365 services they need to.

Now, most of the major networking vendors have already updated their software and are able to access the above information so that you don't have to. Many of them - such as CheckPoint - even provide the services as objects in their configuration tools!

Popular posts from this blog

Domain Controller Machine Password Reset

Image
On my lab environment, I've configured two Active Directory sites since most enterprises have offices in more that one places. My lab however is not running 24/7 and the domain controllers in the second site are rarely turned on in order to save resources. This leads to issues with the Active Directory replication such as the "The target principal name is incorrect" error when I execute:  repadmin /syncall /AdeP. To remedy the issue, we have to reset the machine password of the domain controller that has been offline. First off, we are going to stop and disable the Kerberos Key Distribution Center (kdc) service on the problematic domain controller, in our case DC4. There may be some tickets in the cache so we should also clear them using klist purge Now it's time to change the machine password of the domain controller using the command netdom resetpwd /s:dc3 /ud:lab\administrator /pd:* Replace the "lab\administrator" with an account on your...
Keep reading

Managing Active Directory User Certificates using PowerShell

I first came across user certificates when I was working with email certificates a few years ago and I have to admit that I had trouble updating the certificates on the objects! Most organizations have a Microsoft Active Directory Certification Authority that issues the certificates used internally. When a certificate is issued to a user, the Microsoft Certificate Service saves the public key in Active Directory. The userCertificate attribute is a multi-valued attribute that contains the DER-encoded X509v3 certificates issued to the user. Although we rarely need to pay attention to this attribute, there are cases where we have to update it. To make things easier, I've written PowerShell functions to Get, Remove, Import and Export the certificates on that field. To get the list of certificates for an object, use the Get-ActiveDirectoryObjectCertificate function: PS C:\> Get-ActiveDirectoryObjectCertificate -UserPrincipalName cpolydorou@lab.local DistinguishedName  ...
Keep reading

Configuring a Certificate on Exchange Receive Connector

Today's article is about configuring Exchange receive connectors with specific certificates. Out of the box, Exchange uses self signed certificates to provide TLS secured mail flow. This will definitely be an issue if you expose the SMTP protocol to client computers since they won't trust the certificate. In this article we are going to configure a certificate that was issued by a third part authority to the Client Frontend receive connector. We'll start with getting the thumbprint of the certificate using the Get-ExchangeCertificate cmdlet: [PS] C:\> Get-ExchangeCertificate Thumbprint                               Subject ----------                               ------- 241B864DC82C664FECBA18B8D54987AAFB65B4C2 CN=*.lab.com, ... D4D210886B34E690191A1F008C78FDD0E7325DD4 CN=Exchange2013A 960171662EB26116...
Keep reading