Christos Polydorou

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

The trigger to write this article was a troubleshooting session with a client that had built an automation process to deploy Windows Server and RedHat Enterprise Linux virtual machines on Azure. One of the steps of the provisioning process was to join the machine to the IaaS Active Directory Domain that was deployed on Azure and for this, an Active Directory account was required.

Following the least previlege principle, the account used in the automation processes to join machines to the domain was a plain account that could indeed perform this operation. After some successfull joins however, the process started encountering errors when trying to join machines to the domain.

As it turns out, the architects and security engineers had missed the fact that plain Active Directory accounts have the ability to only join a specific number of machines to the domain. When the automation reached that number, the process started to fail.

To further troubleshoot the issue, we tried to join the ma…

The Azure Instance Metadata service is an Azure service that provides more information about Azure Virtual Machines that is invoked from the machine itself. This way, the administrators of the machine - that in most cases have no access to the Azure Portal - are able to get more information and troubleshoot potential issues.

Let's use a linux virtual machine to get information from the metadata service!

To get the data from the service, a simple HTTP call is all that is required. However, there are a couple of things to keep in mind.

First, although we are using Automatic Private IP Addressing, we have to include the "Metadata" header so that the service won't mistake our call for a call that may be the result of a redirection.

Second, the version of the API to use must be provided in every request. To get the allowed values, simply call the service without the "api-version" parameter and it should return a list of values:

curl -H Metadata:true "http://…

When operating relatively big and complex environments, the ability to have all the operational information available as quick as possible is one of the key factors that protect you from downtime and breached SLAs and allow you to have a full view on the environment to act proactively.
There are many cloud and on premises solutions that can be of assistance but there are some cases that require a more customized approach. Don't get me wrong, Azure OMS and other solutions like it are great for maintaining the control and reporting on your services. However, there are some organizations with needs that cannot be covered by OMS, such as really long retention periods, log file formats that cannot be directly parsed, etc.
So what we need is a place to store the files and a very fast way to query them. This is where Azure Data Lake comes into play. Uploading your log files to Azure Data Lake or directly feeding the Data Lake using Azure Stream Analytics will give you the ability to ana…

Active Directory query. Every Windows administrator has had the need to get a list of objects using some kind of criteria to create a report or update them in one batch.

Fortunatelly, Microsoft provides a PowerShell module to interact with Active Directory as part of the RSAT tools and this module is installed by default on the Domain Controllers. The commands in this module interact with the Domain Controller using the Active Directory Web Services.

But what if you are not logged on to a Domain Controller or you don't have RSAT installed? There is a way to query the Domain Controller and get the information you want, without the limitations of the Web Services and in a much faster way using .NET.

First, we have to create a DirectorySearcher object and configure it's LDAP filter. Calling any of the find methods will return the results for the specified filter. On the following example, I'm using FindOne() to get my account.


Keep in mind that you can configure the Directory…

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 domain with admini…