Visualizing AWS Logging Data in Azure Monitor – Part 1

Posted on July 5, 2019 by mattfeltonma

Hi folks!

2019 is more than halfway over and it feels like it has happened in a flash. It’s been an awesome year with tons of change and even more learning. I started the year neck deep in AWS and began transitioning into Azure back in April when I joined on with Microsoft. Having the opportunity to explore both clouds and learn the capabilities of each offering has been an amazing experience that I’m incredibly thankful for. As I’ve tried to do for the past 8 years, I’m going to share some of those learning with you. Today we’re going to explore one of the capabilities that differentiates Azure from its competition.

One of the key takeaways I’ve had from my experiences with AWS and Microsoft is enterprises have become multicloud. Workloads are quickly being spread out among public and private clouds. While the business benefits greatly from a multicloud approach where workloads can go to the most appropriate environment where the cost, risks, and time tables best suit it, it presents a major challenge to the technical orchestration behind the scenes. With different APIs (application programmatic interface), varying levels of compliance, great and not so great capabilities around monitoring and alerting, and a major industry gap in multicloud skills sets, it can become quite a headache to successfully execute this approach.

One area Microsoft Azure differentiates itself is its ability to easy the challenge of monitoring and alerting in a multicloud environment. Azure Monitor is one of the key products behind this capability. With this post I’m going to demonstrate Azure Monitor’s capabilities in this realm by walking you through a pattern of delivering, visualizing, and analyzing log data collected from AWS. The pattern I’ll be demonstrating is reusable for most any cloud (and potentially on-premises) offering. Now sit back, put your geek hat on, and let’s dive in.

First I want to briefly talk about what Azure Monitor is? Azure Monitor is a solution which brings together a collection of tools that can be used to collect and analyze the large abundance of telemetry available today. This telemetry could be metrics in regards to a virtual machine’s performance or audit logs for Azure Active Directory. The product team has put together the excellent diagram below which explains the architecture of the solution.

Credit – https://docs.microsoft.com/en-us/azure/azure-monitor/overview

As you can see from the inputs on the left, Azure Monitor is capable of collecting and analyzing data from a variety of sources. You’ll find plenty of documentation the product team has made publicly available on the five gray items, so I’m going to instead focus on custom sources.

For those of you who have been playing in the AWS pool, you can think of Azure Monitor as something similar (but much more robust) to CloudWatch Metrics and CloudWatch Logs. I know, I know, you’re thinking I’ve drank the Microsft Kool-Aid.

While I do love to reminisce about cold glasses of Kool-Aid on hot summers in the 1980s, I’ll opt to instead demonstrate it in action and let you decide for yourself. To do this I’ll be leveraging the new API Microsoft introduced. The Azure Monitor HTTP Data Collector API was introduced a few months back and provides the capability of delivering log data to Azure where it can be analyzed by Azure Monitor.

With Azure Monitor logs are stored in an Azure resource called a Log Analytics Workspace. For you AWS folk, you can think of a Log Analytics Workspace as something similar to CloudWatch Log Groups where the data stored in a logical boundary where the data shares a retention and authorization boundary. Logs are sent to the API in JSON format and are placed in the Log Analytics Workspace you specify. A high level diagram of the flow can be seen below.

Credit – https://docs.microsoft.com/en-us/azure/azure-monitor/platform/data-collector-api

So now that you have a high level understanding of what Azure Monitor is, what it can do, and how the new API works, let’s talk about the demonstration.

If you’ve used AWS you’re very familiar with the capabilities CloudWatch Metrics Dashboards and the basic query language available to analyze CloudWatch Logs. To perform more complex queries and to create deeper visualizations, third-party solutions are often used such as ElasticSearch and Kibana. While these solutions work, they can be complex to implement and can create more operational overhead.

When a peer informed me about the new API a few weeks back, I was excited to try it out. I had just started to use Azure Monitor to put together some dashboards for my personal Office 365 and Azure subscriptions and was loving the power and simplicity of the analytics component of the solution. The new API opened up some neat opportunities to pipe logging data from AWS into Azure to create a single dashboard I could reference for both clouds. This became my use case and demonstration of the pattern of delivering logs from a third party to Azure Monitor with some simple Python code.

The logs I chose to deliver to the API were logs containing information surrounding the usage of AWS access ids and keys. I had previously put together some code to pull this data and write it to an S3 bucket.

Let’s take a look at the design of the solution. I had a few goals I wanted to make sure to hit if possible. My first goal was to keep the code simple. That mean limiting the usage of third-party modules and avoid over complicating the implementation.

My second goal was to limit the usage of static credentials. If I ran the code in Azure, I’d need to setup an AWS IAM User and provision an access id and secret key. While I’m aware of the workaround to use SAML authentication, I’m not a fan because in my personal opinion, it’s using SAML in such a way you are trying to hammer in a square peg in a round hole. Sure you can do it, but you really shouldn’t unless you’re out of options. Additionally, the solution requires some fairly sensitive permissions in AWS such as IAM:ListAccessKeys so the risk of the credentials being compromised could be significant. Given the risks and constraints of authentication methods to the AWS API, I opted to run my code as a Lambda and follow AWS best practices and assign the Lambda an IAM role.

On the Azure side, the Azure Monitor API for log delivery requires authentication using the Workspace ID and Workspace key. Ideally these would be encrypted and stored in AWS Secrets Manager or as a secure parameter in Parameter Store, but I decided to go the easy route and store them as environment variables for the Lambda and to encrypt them with AWS KMS. This cut back on the code and made the CloudFormation templates easier to put together.

With the decisions made the resulting design is pictured above.

I’m going to end the post here and save the dive into implementation and code for the next post. In the meantime, take a read through the Azure Monitor documentation and familiarize yourself with the basics. I’ve also put the whole solution up on Github if you’d like to follow along for next post.

See you next post!

Capturing and Visualizing Office 365 Security Logs – Part 1

Posted on January 30, 2019 by mattfeltonma

Welcome back again my fellow geeks!

I’ve been busy over the past month nerding out on some pet projects. I thought it would be fun to share one of those pet projects with you. If you had a chance to check out my last series, I walked through my first Python experiment which was to write a re-usable tool that could be used to pull data from Microsoft’s Graph API (Microsoft Graph).

For those of you unfamiliar with Microsoft Graph, it’s the Restful API (application programming interface) that is used to interact with Microsoft cloud offerings such as Office 365 and Azure. You’ve probably been interacting with it without even knowing it if through the many PowerShell modules Microsoft has released to programmatically interact with those services.

One of the many resources which can be accessed through Microsoft Graph are Azure AD (Active Directory) security and audit reports. If you’re using Office 365, Microsoft Azure, or simply Azure AD as an identity platform for SSO (single sign-on) to third-party applications like SalesForce, these reports provide critical security data. You’re going to want to capture them, store them, and analyze them. You’re also going to have to account for the window that Microsoft makes these logs available.

The challenge is they are not available via the means logs have traditionally been captured on-premises by using syslogd, installing an SIEM agent, or even Windows Event Log Forwarding. Instead you’ll need to take a step forward in evolving the way you’re used to doing things. This is what moving to the cloud is all about.

Microsoft allows you to download the logs manually via the Azure Portal GUI (graphical user interface) or capture them by programmatically interacting with Microsoft Graph. While the former option may work for ad-hoc use cases, it doesn’t scale. Instead we’ll explore the latter method.

If you have an existing enterprise-class SIEM (Security Information and Event Management) solution such as Splunk, you’ll have an out of box integration. However, what if you don’t have such a platform, your organization isn’t yet ready to let that platform reach out over the Internet, or you’re interested in doing this for a personal Office 365 subscription? I fell into the last category and decided it would be an excellent use case to get some experience with Python, Microsoft Graph, and take advantage of some of the data services offered by AWS (Amazon Web Services). This is the use case and solution I’m going to cover in this post.

Last year I had a great opportunity to dig into operational and security logs to extract useful data to address some business problems. It was my first real opportunity to examine large amounts of data and to create different visualizations of that data to extract useful trends about user and application behavior. I enjoyed the hell out of it and thought it would be fun to experiment with my own data.

I decided that my first use case would be Office 365 security logs. As I covered in my last series my wife’s Office 365 account was hacked. The damage was minor as she doesn’t use the account for much beyond some crafting sites (she’s a master crocheter as you can see from the crazy awesome Pennywise The Clown she made me for Christmas).

The first step in the process was determining an architecture for the solution. I gave myself a few requirements:

The solution must not be dependent on my home lab infrastructure
Storage for the logs must be cheap and readily available
The credentials used in my Python code needs to be properly secured
The solution must be automated and notify me of failures
The data needs to be available in a form that it can be examined with an analytics solution

Based upon the requirements I decided to go the serverless (don’t hate me for using that tech buzzword 🙂 ) route. My decisions were:

AWS Lambda would run my code
Amazon CloudWatch Events would be used to trigger the Lambda once a day to download the last 24 hours of logs
Amazon S3 (Simple Storage Service) would store the logs
AWS Systems Manager Parameter Store would store the parameters my code used leveraging AWS KMS (Key Management Service) to encrypt the credentials used to interact with Microsoft Graph
Amazon Athena would hold the schema for the logs and make the data queryable via SQL
Amazon QuickSight would be used to visualize the data by querying Amazon Athena

The high level architecture is pictured below.

untitled

I had never done a Lambda before so I spent a few days looking at some examples and doing the typical Hello World that we all do when we’re learning something new. From there I took the framework of Python code I put together for general purpose queries to the Microsoft Graph, and adapted it into two Lambdas. One Lambda would pull Sign-In logs while the other would pull Audit Logs. I also wanted a repeatable way to provision the Lambdas to share with others and get some CloudFormation practice and brush up on my very dusty Bash scripting. The results are located here in one of my Github repos.

I’m going to stop here for this post because we’ve covered a fair amount of material. Hopefully after reading this post you understand that you have to take a new tact with getting logs for cloud-based services such as Azure AD. Thankfully the cloud has brought us a whole new toolset we can use to automate the extraction and storage of those logs in a simple and secure manner.

In my next post I’ll walk through how I used Athena and QuickSight to put together some neat dashboards to satisfy my nerdy interests and get better insight into what’s happening on a daily basis with my Office 365 subscription.

See you next post and go Pats!

A Comparison – AWS Managed Microsoft AD and Azure Active Directory Domain Services

Posted on September 6, 2018 by mattfeltonma

Update June 2021: I’m surprised I have to say this, but technology changes rapidly in the cloud and this was a comparison of the technologies at a point in time. Please reference the latest official documentation for both products to understand capabilities and features and how they compare at the time you are reading this post.

Over the past year I’ve done deep dives into both Amazon’s AWS Managed Microsoft Active Directory and Microsoft’s Azure Active Directory Domain Services. These services represent each vendor’s offering of a managed Windows Active Directory (AD) service. I extensively covered the benefits of a service over the course of the posts, so today I’m going to cover the key features of each service. I’m also going to include two tables. One table will outline the differences in general features while the other outlines the differences in security-related features.

Let’s hit on the key points first.

Amazon provides a legacy (Windows AD is legacy folks) managed service while Microsoft provides a modernized service (Azure AD) which has been been integrated with a legacy service.
Microsoft synchronizes users, passwords hashes, and groups from the Azure AD to a managed instance of Windows Active Directory. The reliance on this synchronization means the customer has to be comfortable synchronizing both directory data and password hashes to Azure AD. Amazon does not require any data be synchronized.
Amazon provides the capability to leverage the identities in the managed instance of Windows AD or in a forest that has a trust with the managed instance to be leveraged in managing AWS resources. In this instance Amazon is taking a legacy service and enabling it for management of the modern cloud management plane.
The pricing model for the services differs where Amazon bills on a per domain controller basis while Microsoft bills on the number of objects in the directory.
Amazon’s service is eligible to be used in solutions that require PCI DSS Level 1 or HIPAA.
Both services use a delegated model where the customer has full control over an OU rather the directory itself. Highly privileged roles such as Schema Admin, Enterprise Admins, and Domain Admins are maintained by the cloud provider.
Both services provide LDAP for legacy applications customers may be trying to lift and shift. Microsoft limits LDAP to read operations while Amazon supports both read and write operations.
Both services support LDAPS. At this time Amazon requires an instance of Active Directory Certificate Services be deployed to act as a Certificate Authority and provide certificates to the managed domain controllers.
Both services do not allow the customer to modify the Default Domain Policy or Default Domain Controller Policies. This means the customer cannot modify the password or lockout policy applied to the domain. Amazon provides a method of enforcing custom password and lockout policies through Fine Grained Password Policies. Additionally, the customer does not have the ability to harden the OS of the domain controllers for either service so it is important to review the vendor documentation.
Amazon’s service supports Active Directory forest trusts and external trusts. Microsoft’s service doesn’t support trusts at this time.

Here is a table showing the comparison of general features:

Features	AWS Managed Microsoft AD	Azure Active Directory Domain Services
Cost Basis	Number of Domain Controllers	Number of Directory Objects
Schema Extensions	Yes, with limitations	No
Trusts	Yes, with limitations	No
Domain Controller Log Access	Security and DNS Server Event Logs	No
DNS Management	Yes	Yes
Snapshots	Yes	No
Limit of Managed Forests	10 per account	1 per Azure AD tenant
Supports being used on-premises	Yes with Direct Connect or VPN	No, within VNet only
Scaled By Customer	Yes	No
Max number of Domain Controller	20 per directory	Unknown how service is scaled

Here is a table of security capabilities:

Features	AWS Managed Microsoft AD	Azure Active Directory Domain Services
Requires Directory Synchronization	No	Yes, including password
Fine-Grained Password Policies	Yes, limited to seven	No
Smart Card Authentication	Not native, requires RADIUS	No
LDAPS	Yes, with special requirements	Yes, but LDAP operations are limited to read
LDAPS Protocols	SSLv3, TLS 1.0, TLS 1.2	TLS 1.0, TLS 1.2
LDAPS Cipher Suites	RC4, 3DES, AES128, AES256	RC4, 3DES, AES128, AES256
Kerberos Delegation	Account-Based and Resource-Based	Resource-Based
Kerberos Encryption	RC4, AES128, AES256	RC4, AES128, AES256
NTLM Support	NTLMv1, NTLMv2	NTLMv1, NTLMv2

Well folks that sums it up. As you can see from both of the series as well as this summary post both vendors have taken very different approaches in providing the service. It will be interesting to see how these offerings evolve over the next few years. As much as we’d love to see Windows Active Directory go away, it will still be here for years to come.

Until next time my fellow geeks!

AWS Managed Microsoft AD Deep Dive Part 7 – Trusts and Domain Controller Event Logs

Posted on September 3, 2018 by mattfeltonma

Welcome back fellow geek. Today I’m continuing my deep dive series into AWS Managed Microsoft AD. This will represent the seventh post in the series and I’ve covered some great content over the series including:

Today I’m going cover three additional capabilities of AWS Managed Microsoft AD which includes the creation of trusts, access to the Domain Controller event logs, and scalability.

I’ll first cover the capabilities around Active Directory trusts. Providing this capability opens up the possibility a number of scenarios that aren’t possible in managed Windows Active Directory (Windows AD) services that don’t support trusts such as Microsoft’s Azure Active Directory Domain Services. Some of the scenarios that pop up in my head are resource forest, trusts with trusted partners to maintain collaboration for legacy applications (applications dependent on legacy protocols such as Kerberos/NTLM/LDAP), trusts between development, QA, and production forests, and the usage of features features such as selective authentication to mitigate the risk to on-premises infrastructure.

For many organizations, modernization of an entire application catalog isn’t feasible but those organizations still want to take advantage of the cost and security benefits of cloud services. This is where AWS Managed Microsoft AD can really shine. It’s capability to support Active Directory forests trusts opens up the opportunity for those organizations to extend their identity boundary to the cloud while supporting legacy infrastructure. Existing on-premises core infrastructure services such as PKI and SIEM can continue to be used and even extended to monitor the infrastructure using the managed Windows AD.

As you can see this is an extremely powerful capability and makes the service a good for almost every Windows AD scenario. So that’s all well and good, but if you wanted marketing material you’d be reading the official documentation right? You came here for the deep dive, so let’s get into it.

The first thing that popped into my mind was the question as to how Amazon would be providing this capability in a managed service model. Creating a forest trust typically requires membership in privileged groups such as Enterprise Admins and Domain Admins, which obviously isn’t possible in a manged service. I’m sure it’s possible to delegate the creation of Active Directory trusts and DNS conditional forwarders with modifications of directory permissions and possibly user rights, but there’s a better way. What is this better way you may be asking yourself? Perhaps serving it up via the Directory Services console in the same way schema modifications are served up?

Let’s walk through the process of setting up an Active Directory forest trust with a customer-managed traditional implementation of Windows Active Directory and an instance of AWS Managed Microsoft AD. For this I’ll be leveraging my home Hyper-V lab. I’m actually in the process of rebuilding it so there isn’t much there right now. The home lab consists of two virtual machines, one named JOG-DC running Windows Server 2016 and functions as a domain controller (AD DS) and certificate authority (AD CS) for the journeyofthegeek.com Active Directory forest. The other virtual machine is named named JOG-CLIENT, runs Windows 10, and is joined to the journeyofthegeek.com domain. I’ve connected my VPC with my home lab using AWS’s Managed VPN to setup a site-to-site IPSec VPN connection with my local pfSense box.

Prior to setting up the trusts there are a few preparatory steps that need to be completed. The steps will be familiar to those of you who have established forests trusts across firewalled network segments. At a high level, you’ll want to perform the following tasks:

Ensure the appropriate ports are opened between the two forests.
Ensure DNS resolution between the two forests is established

For the first step I played it lazy since this is is a temporary configuration (please don’t do this in production). I allowed all traffic from the VPC address range to my lab environment by modifying the firewall rules on my pfSense box. On the AWS side I needed to adjust the traffic rules for the security group SERVER01 is in as well as the security group for the managed domain controllers.

To establish DNS resolution between the two forests I’ll be using conditional forwarders setup within each forest. Setting the conditional forwarders up in the journeyofthegeek.com forest means I have to locate the IP addresses of the managed domain controllers in AWS. There are a few ways you could do it, but I went to the AWS Directory Services Console and selected the geekintheweeds.com directory.

On the Directory details section of the console the DNS addresses list the IP addresses the domain controllers are using.

After creating the conditional forwarder in the DNS Management MMC in the journeyofthegeek.com forest, DNS resolution of a domain controller from geekintheweeds.com was successful.

I next created the trust in the journeyofthegeek.com domain ensuring to select the option to create the trust in this domain only and recording the trust password using the Active Directory Domains and Trusts. We can’t create the trusts in both domains since we don’t have an account with the appropriate privileges in the AWS managed domain.

Next up I bounced back over to the Directory Services console and selected the geekintheweeds.com directory. From there I selected the Network & security tab to open the menu needed to create the trust.

From here I clicked the Add trust relationship button which brings up the Add a trust relationship menu. Here I filled in the name of the domain I want to establish the trust with, the trust password I setup in the journeyofthegeek.com domain, select a two-way trust, and add an IP that will be used within configuration of the conditional forwarder setup by the managed service.

After clicking the Add button the status of the trust is updated to Creating.

The process takes a few minutes after which the status reports as verified.

Opening up the Active Directory Users and Computers (ADUC) MMC in the journeyofthegeek.com domain and selecting the geekintheweeds.com domain successfully displays the directory structure. Trying the opposite in the geekintheweeds.com domain works correctly as well. So our two-way trust has been created successfully. We would now have the ability to setup any of the scenarios I talked about earlier in the post including a resource forest or leveraging the managed domain as a primary Windows AD service for on-premises infrastructure.

The second capability I want to briefly touch on is the ability to view the Security Event Log and DNS Server logs on the managed domain controllers. Unlike Microsoft’s managed Windows AD service, Amazon provides ongoing access to the Security Event Log and DNS Server Log. The logs can be viewed using the Event Log MMC from a domain-joined machine or programmatically with PowerShell. The group policy assigned to the Domain Controllers OU enforces a maximum event log size of 256MB but Amazon also archives a year’s worth of logs which can be requested in the event of an incident. The lack of this capability was a big sore spot for me when I looked at Azure Active Directory Domain Services. It’s great to see Amazon has identified this critical use case.

Last but definitely not least, let’s quickly cover the scalability of the service. Follow Microsoft best practices and you can take full advantage of scaling horizontally with the click of a single button. Be aware that the service only scales horizontally and not vertically. If you have applications that don’t follow best practices and point to specific domain controllers or perform extremely inefficient LDAP queries (yes I’m talking to you developers who perform searches using front and rear-facing wildcards and use LDAP_MATCHING_RULE_IN_CHAIN filters) horizontal scaling isn’t going to help you.

Well folks that rounds out this entry into the series. As we saw in the post Amazon has added key capabilities that Microsoft’s managed service is missing right now. This makes AWS Managed Microsoft AD the more versatile of the two services and more than likely a better fit in almost any scenario where there is a reliance on Windows AD.

In my final posts of the series I’ll provide a comparison chart showing the differing capabilities of both AWS and Microsoft’s services.

See you next post!

Journey Of The Geek

The chronicles of a Bostonian tech geek navigating through life and technology

Tag Archives: security

Visualizing AWS Logging Data in Azure Monitor – Part 1

Capturing and Visualizing Office 365 Security Logs – Part 1

A Comparison – AWS Managed Microsoft AD and Azure Active Directory Domain Services

AWS Managed Microsoft AD Deep Dive Part 7 – Trusts and Domain Controller Event Logs