Microsoft Cloud App Security


Have you ever wondered what is going on within the SaaS services your organization is using?

Are you curious about what unsanctioned SaaS apps employees may be storing company data in?

Do you want to know where and when sensitive data is stored in the cloud?

Do you want to know who’s accessing sensitive data in the cloud?


If you’re like me, those questions are top of mine when create a new cloud subscription and giving up control is sometimes difficult to do.  However, with Microsoft Cloud App Security you don’t have to give up control or visibility into SaaS based services anymore.


What is Cloud App Security?

Microsoft Cloud App Security is a comprehensive service that provides deeper visibility, comprehensive controls, and improved protection for your cloud applications. Cloud App Security is designed to help you extend the visibility, auditing, and control you have on-premises to your cloud applications.

Cloud App Security is a critical component of the Microsoft Cloud Security stack. It is a comprehensive solution that helps organizations take full advantage of the promise of cloud applications while maintaining control with improved visibility into activity. It also increases protection of critical data across cloud applications. With tools to help uncover Shadow IT, assess risk, enforce policies, investigate activities and stop threats, organizations can safely move to the cloud while maintaining control of critical data.



The architecture of Cloud App Security is shown in the image below:


Image Source:


Getting started with Cloud App Security

In the past, setting up security solutions required hardware and software, firewall configuration, etc. All things that require time and money to implement. However, with Cloud App Security setting it up is straight forward. Simply logon or start a trial of Office 365 and enable a trial of Cloud App Security from the O365 admin tenant.

More details here:


Using Cloud App Security

Once the Cloud App Security subscription is live, login to the admin portal and get a feel for the interface.

A fresh Cloud App Security interface won’t have any data in it, however mine does, as shown below:


The dashboard provides an overview of activities, alerts, and violations. Select any of the items to drill down for more information. On the left we see apps that are sanctioned and threat detections (I’ll cover this later in the post).


Application Discovery

Most organizations I speak with want to know who’s using what cloud applications and how much corporate data is being stored in sanctioned and unsanctioned cloud applications. Cloud App Security offers a method to manually or automatically (via log collectors), import traffic logs from network devices. By ingesting traffic logs into Cloud App Security you’ll gain visibility of cloud application and data usage.

See a list of supported network devices here:

Here’s an example of what Cloud App Security found when I uploaded a network log file:


Based on the log file, Cloud App Security discovered 512 applications in use across the organization with only 7 of these sanctioned by the admin within Cloud App Security. In other words, 98% of the cloud applications discovered are unsanctioned applications. Let’s see how many of those applications are risky.

Notice on the left the term “Score”, the lower the score the riskier the application. So if an application has a score of 1 it’s potentially bad, but if it has a score of 10, the app is general well known, and marked as safer.  The scoring takes the information provide in the application and averages it.

Also, by looking at the results I can see that there are two cloud storage providers in use, OneDrive and Box. So as a company, a decision will need to made on what cloud storage provider to standardize on, then monitor usage in Cloud App Security over a period of time to make sure users are moving to the sanctioned cloud storage provider.



Looking at a risky application we see the following information. Compare a risky application with that of an application that have a higher score. Note that with the riskier application, little is known about the vendor and this application clearly does not meet any compliance regulations. However, if you find something to be incorrect, the setting and scoring can be manually changed.



What about off network devices?

If you’re interested in agent based application discovery that is integrated with Azure Active Directory, please visit: – completely separate from Cloud App Discovery at this time.


Application Integration via API

Cloud App Security offers several applications that monitored and accessed via a direct API. For example, Office 365 and have API integration directly with Cloud App Security (and there many more apps that have API integration as well, see

The advantage of having direct API integration is gaining visibility and control over the service. Do you recall at the beginning of this post I stated that I don’t like to give up control much? Cloud App Security gives control back.

For example, I have configured with SSO using Azure Active Directory (Azure AD). I also do what’s called user provisioning into with Azure AD, so as users are created in my on-premises AD environment, they are synchronized up to Azure AD. If there is the attribute of “Sales” in the “department” field of the AD user object, those users are automatically added to a Salesforce corporate group I created in Azure AD (this is called dynamic group membership). Once users land in that particular group they’re automatically provisioned into However, I still like to know when users are provisioned and de-provisioned from my SaaS services (e.g. In Cloud App Security I configured a policy that tracks account activity in


Let’s take a look at policies in Cloud App Security

From the Cloud App Security admin portal, at the top select Control and Policies from the dropdown menu:


In my environment I’ve configured a few policies as shown below:



To create a policy, select “Create policy” in blue and select the type of policy you’d like to create:

Let take a moment to learn about the types of polices in the list before creating a new policy:

Activity Policy

Activity policies allow you to enforce a wide range of automated processes leveraging the app provider’s APIs. These policies enable you to monitor specific activities carried out by various users, or follow unexpectedly high rates of a certain type of activity.

Anomaly detection policy
Anomaly detection policies enable you to look for unusual activities on your cloud based on the risk factors you set here to alert you when something happens that is different from either the baseline of your organization or from the user’s regular activity.

App discovery policy
App discovery policies enable you to set alerts that notify you when new apps are detected within your organization.

Cloud Discovery anomaly detection policy
Cloud Discovery anomaly detection policies look at the logs you use for discovering cloud apps and search for unusual occurrences. For example, when a user who never used Dropbox before suddenly uploads 600 GB to Dropbox, or when there are a lot more transactions than usual on a particular app.

File policy
File policies enable you to scan your cloud apps for specified files or file types (shared, shared with external domains), data (proprietary information, PII, credit card information, etc.) and apply governance actions to the files (governance actions are cloud-app specific).



For the purposes of tracking account activity I chose “Activity policy” from the menu. Within the policy creation page, I configured a number of fields as shown below. Basically the policy says, I want to be alerted when users are added to This helps me keep track of who’s using the service without having to log into or Azure AD to find out. It’s a simple policy, but effective and gets me the info I need.


Because this is a fresh policy there is the option at the top to select from a pre-canned list of policy templates or create your own templates as shown below:


More details here:


Once a user is created in an alert is generated that looks like the following:

Note: “Joe Sales” was created via Azure AD automatic account provisioning into



Let’s take a look at a File Policy for DLP

I have files stored in O365 (i.e. SharePoint Online/OneDrive). My policy looks for credit card numbers and alerts me when it finds them. I can also configure the policy to take action automatically such as when it finds credit card numbers in files, remove permissions, quarantine the user who’s accessing them, and so on. If necessary, you can use regular expressions within policies as well. Here, I just use the canned “credit card number” expression and it works well.


When the policy combs through the files in the services configured (i.e. services that have direct API integration with Cloud App Security, in this case OneDrive) they’ll trigger alerts based on what it finds as shown below:


Let’s dig into the alert and see what it came up with:


Based on the screenshot above, Microsoft Cloud App Security used the DLP policy I configured to find the file with credit card numbers I planted in OneDrive. As an admin, I can take manual action or configure automated actions as shown previously during the file policy creation step.

Here’s what manual actions you can take if you need to investigate further:



Those are just a couple examples of application discovery, data loss prevention (DLP), policy creation and enforcement within Microsoft Cloud App Security. Find out what your business requires and configure policies based on those guidelines.


To learn more about Microsoft Cloud App Security please visit:

Microsoft Windows Store for Business and Azure AD Join

With Windows 10 available, many organizations are considering upgrading. There are a lot of reasons to consider upgrading to Windows 10 and if you’re interested in learning more please visit:

If you’re interested in learning more about the Windows 10 Roadmap for Business please visit: 

First I’ll walk through the registration of a Windows 10 device with Azure Active Directory (Azure AD), then I’ll walk through setting up WS4B.  After, I’ll access the Windows Store from a Windows 10 device where the private business store resides.

During the setup process, users will have the choice (if you’re not deploying using MDT or System Center Configuration Manager for auto deployment) to choose how they’ll authenticate. They can either perform a traditional domain join or join Azure AD.

To learn more about the differences between domain join and Azure AD join please visit:

If your devices are Azure AD joined and you maintain an AD forest on premises, then you’ll be interested in learning more about how to writeback the device objects to Active Directory on premises.

For more information on writing back device info to Active Directory please visit:

There’s also the ability to have Windows devices automatically register with Azure AD as they’re domain joined.  Links about automatic device registration across the various Windows OS versions are below:


Joining a Windows 10 Device to Azure Active Directory

One of the advantages to joining devices to Azure AD is single sign-on (SSO) benefits. In traditional domain joined environments typically this is provided by way of a federated identity provider (e.g. Active Directory Federation Services or ADFS). However, when devices are joined directly with Azure AD the direct benefit is SSO to cloud applications such as Office 365 and other SaaS based applications that have a federated trust directly with Azure AD.

Let’s walk through how to join a device to Azure AD. The following walks through the OOBE experience, however devices that are already set up can be joined as well.

Note: if the device is already domain joined, refer to the links above for device writeback and registration.

Install Windows 10 and after Windows 10 has completed the setup process, select “Join Azure AD”


Type in a user name and password (make sure the user is licensed for Intune or EMS via the O365 admin portal). Select “Sign in” to enroll the device with Azure AD:




clip_image010 clip_image012

Once registration is complete I’m asked to set up a PIN:


PIN setup process


There are three methods to verify your identity via Multi-Factor Authentication. Select the method that best suits your needs. I chose to use the Mobile App.


Download or open the Azure Authenticator app on iOS, Android, or Windows Phone and scan the QR code or use the code provided:


Because I used the mobile app, Azure Authenticator has now registered the account:


Back on the Windows 10 device, once the QR code is scanned or entered and register with the Azure Authenticator app, the Next button lights up. Select Next.


Select how you’d like to authenticate; I chose to receive a notification on my phone (via the Azure Authenticator app):



On my phone, I select “Verify” to complete the process:


Lastly I need to select a country and enter my phone number and select Next:


Now I’m asked to provide a PIN:


After a pin is entered I’m logged into the device under the Azure AD credentials I registered with:


To prove I’m logged in as and Azure AD registered user, I open a command prompt and type in “whoami” without quotes:


On the backend, my device auto registers with Microsoft Intune for mobile device and application management. Intune will also deploy the policies I’ve configured such as configuring Windows Update, Windows Defender, Enterprise Data Protection, OS Upgrade, and so on.

For example, the following are the Windows Defender settings from the same device I registered, as you can see the settings are grayed out; that’s because my Intune policy was deployed to the device:


What about group policies?

If the device is enrolled and managed by Intune, I recommend sticking with Intune policies. However, if there are group policies that your organization already uses, then the more restrictive policy will always take precedence (either Intune or GP). The Intune admin console will point any conflicts out as well.


Windows Store for Business

What is Windows Store for Business?

With the new Windows Store for Business, organizations can make volume purchases of Windows apps. The Store for Business provides app purchases based on organizational identity, flexible distribution options, and the ability to reclaim or re-use licenses. Organizations can also use the Store for Business to create a private store for their employees that includes apps from the Store, as well private Line-of-Business (LOB) apps.

Source and more info:

Now that I have my Windows 10 device registered with Azure AD (and enrolled with Intune), let’s take a look at the Windows Store for Business.

Navigate to: and either sign up or sign in with your organizational account.




The first thing I do is connect WS4B to Microsoft Intune. To connect the services, select Settings and then Management Tools:


Select “Add a management tool”


Search for Microsoft Intune and select Microsoft Intune from the list:


Microsoft Intune will be added and activated:


Adding Applications

Select “Shop” in WS4B to view and add applications. This is very similar to a volume purchase program (VPP):


Select an app to add, in my case I selected Foxit MobilePDF. Then select “Get the app” – other apps have online and offline options that you can select as well.


The distribute screen will open and we have a few options to select from as shown below. I selected to assign the app to people, in this case all FTE group I created in O365. Once you’ve selected an option select “Confirm” to add the app to the WS4B inventory.



Now I’m taken to the WS4B inventory page where all of the apps added may be seen and modified. Select an app to see who it’s been assigned to.



Intune Volume Purchase Program (VPP)

Let’s move over the Intune admin portal to view the VPP apps added by WS4B. After I log into Intune I select APPS then Volume-Purchased Apps. Here’s a brief list of some of the apps that came over from WS4B:



Windows Store for Business on the Windows Client

Let’s now look at where to access applications in the private store. To view the published apps search for or open the Windows Store on a Windows 10 machine (I’m using the device joined with Azure AD). From there you’ll see a list of tabs and on the far right there’s a new tab for WS4B as shown below:




In my environment I select “Contoso cbcloudmobility” and see the following apps I’ve published so far:



When I select Sway, I’m provided an option to install:



If you’re wondering if LOB apps can be published, the answer is yes. From the WD4B portal select “Manage” and then “New LOB Apps” from there you can go to the LOB Publishers page to invite publishers.

More details here:



This concludes the walk-through of registering a Windows 10 device with Azure AD and publishing applications via the Windows Store for Business. Try it out to see how it would work for your organization.

Invite external users to access Publically Shared URLs via Power BI using Azure AD

November 2017 update: Azure AD B2B now supports Power BI.  More details here:


With the rapid adoption of Azure Active Directory (Azure AD) and services surrounding Azure AD, we’re seeing more and more customers interested in publishing SaaS apps as well as custom apps to employees, consultants, and business partners.  One of the challenges of granting application access to users is provisioning/maintaining infrastructure, user management, and what technologies to utilize long term.

Azure Active Directory has a feature called the Access Panel (or The panel accessible by employees and business partners who have accounts within Azure AD (think of this as a potential extranet replacement).  Accounts in Azure AD may live in the cloud, synced from on premises identity providers (i.e. using Azure AD Connect), or by inviting users via Azure AD B2B (business-to-business).

Azure AD Access Panel



We’re also seeing rapid adoption of Microsoft Power BI. Power BI takes all that data you have and transforms it into dashboard visuals and/or reports and can be shared out via a link. For more information about Power BI please visit:


In this post, I’ll walk through how to publish an app that points to a published URL from Power BI and assign external users to a Power BI URL using the “Publish to Web” option.


  • Azure Subscription with an Azure AD tenant
  • Power BI subscription – free version works fine for static access to publically shared URLs

Azure AD  does not support publishing the Power BI app to external users, however virtually any web URL can be assigned to external users that includes a publically generated URL of a report in Power BI.

Please refer to the licensing information regarding the sharing of Power BI content:

For this post I take a URL generated using the Power BI sharing feature (alternatively, sharing from Power BI with users accomplishes the same thing) and create an app using the same URL in Azure AD.  I then invite users to access the public URL via an app added to Azure AD.  Access may vary depending on the Power BI features utilized and user licensing.  Please test all scenarios before moving forward with deployment.


Let’s get started

Stage 1 – Invite external users to Azure AD

Inviting external users using Azure AD is a quick process. Log into, locate Azure Active Directory and add a user.

Stage 2 – Log into Power BI using credentials from the same Azure AD tenant where the B2B users reside. Find the report you’d like to share and select File and then Publish to web at the top.  This will provide a URL that is accessible to anyone on the web.  If you’d like secure access to Power BI content please refer to licensing Power BI.


You may be asking, why don’t I just share the public URL via email and move on?  I could, however what I’m demonstrating is how to publish a URL using Azure AD that points to a publicly shared Power BI URL.  Instead of relying on users to keep track of external links, they can log in to the access panel and select the Apps that point to published URLs as well as access other applications you’ve granted them access to (e.g. SharePoint Online, Salesforce, Concur, Workday, etc.)

Note: Azure AD supports user provisioning with select applications (e.g. Workday, Salesforce, Service Now, etc.).  When a user is added to Azure AD, groups can be configured to dynamically look for attributes in the user’s account (e.g. department = Finance) and automatically add them to a group.  That group can be assigned to an app as well.  User provisioning into SaaS apps can occur thereafter if the apps are configured to do inbound provisioning (i.e. create an account in the SaaS apps identity directory). Dynamic membership for groups cuts back on the management of accounts because account provisioning and de-provisioning happens automatically.

Stage 3 – Add an application to Azure AD the points to a URL and assign to users:

Log into the and search for Azure Active Directory.  Drill down into Azure Active Directory and select “App Registrations”


From the blade that opens to the right, select Add and fill in the details about the app/URL you’re adding.  The URL I used is the URL from Power BI that was created to publicly share content (again anyone can access this content so be sure no confidential data is exposed):


Save the app and if needed access it again to change settings such as the logo and so on.

Today the new Azure Portal does not support assigning users to custom apps so we need to access the classic Azure Console to assign access to external users:

Log into the classic Azure Portal: and navigate the Active Directory on the left had side.




Select the application and select “USERS AND GROUPS”. Add users or groups that you want to have access to the application (i.e. Power BI report). For demonstration purposes, I added a B2B user.

Note: for a more automated of adding users to applications, refer to the dynamic group membership discussed in a previous note above.


Stage 4 – Log in as the B2B user to

Test my published URL outside of Azure AD if you’d like to see if it works or not: 

Select the app that is attached to the published public URL and we’re taken to the report via a single sign-on process:





That’s it, we’ve published a Publicly shared static URL from Power BI report via an Azure AD app to an external user using Azure AD B2B in just a few steps.

Microsoft Intune – Mobile Application Management (MAM) standalone

Have you ever been asked the question “…after I enroll my device, what happens to the personal data on my device if I leave the company?” Sound familiar? I’ve heard this many times when I speak with organizations and in the past the answer was “we have the right to delete everything on your device, so you better back it up…” and so on. Not all employees are comfortable with this approach because wiping a device means personal data such as photos, emails, text messages, game data, and so on may be deleted. Especially if company policies restrict devices from saving data to cloud storage services.

Some Mobile Device Management (MDM) vendors have gone as far as building their own applications to segregate email and data, however not all of these MDM vendors specialize in developing and maintaining email and productivity apps and as a consequence those apps may leave a security hole you didn’t anticipate. If you’ve standardized on or your users prefer the use of productivity apps from Microsoft such as Microsoft Outlook app, OneNote, OneDrive, and so on, unfortunately 3rd party MDM vendors cannot apply policies nor do they have control over Microsoft Office apps whereas Microsoft does.

The good news is, managing the device and applying Mobile Application Management (MAM) policies to applications is built into Microsoft Intune, so from the time devices are enrolled, once deployed, MAM policies will begin to flow to MAM enabled applications such as Microsoft Office apps.

Additionally, if organizations want to maintain their current Mobile Devices Management (MDM) solution and use Intune to only apply MAM policies to applications, with the recent release of Mobile Application Management (MAM) standalone service, companies are able to do just that!

Scenarios to consider when planning your MDM and MAM strategy:

  • Microsoft Intune MAM Only with no MDM at all = Yes
  • 3rd party MDM + Microsoft Intune MAM Only = Yes
  • Microsoft Intune for full MDM/MAM = Yes

For a list of Microsoft Intune MAM supported apps please visit:

Walk-Through of Microsoft Intune MAM standalone (w/o MDM)

The following demonstrates the new Microsoft Intune MAM standalone enrollment process without MDM:

Azure Portal experience

Log into

Select “New” and search for Microsoft Intune


Locate Microsoft Intune (Intune (preview)):


Right click on Intune and select “Pin to dashboard”


Intune mobile application management tile will be pinned to the Azure Portal dashboard:


Select the Intune tile to be taken to the management blade (slide out pages are called blades in the new Azure Portal):


The first thing we need to do is create a MAM policy, we can select either iOS or Android. Do this by selecting App Policy, then Add a Policy from the next blade:


Fill in the necessary information and select “Apps”. Select the apps you’d like to apply MAM policies to and then select “Select” at the bottom of the blade.

Note: not all MAM enabled apps are available yet for MAM standalone. If you need to apply MAM policies to additional applications that support MAM policies, consider enrolling devices with Microsoft Intune and rolling out MAM policies from there.


Next we need to configure the setting for the policy. Do this by selecting “Settings”. This is where we can configure MAM policies such as blocking data from being copied or stored outside of MAM managed applications (e.g. prevent cut, copy, and paste outside of Word). When finished, select “OK” at the bottom of the blade.


Select “Create” at the bottom of “Add a policy” blade to create the policy. Once the policy is created, we’re ready to deploy it to users.

Note: Microsoft Intune MAM standalone is deployed to users not devices.

Lastly, we need to target users to deploy the policy to. Do this by selecting “User groups” from the policy blade. Find the group you’d like to add, press “Select” at the bottom of the User group blade (not shown in image):

Note: at this time, only groups can be selected. Best practice is to place the users who will need MAM policies applied into a MAM only group.


That’s all that needs to be done to create and deploy Microsoft Intune MAM only policies.

iOS/Android experience

Now that the MAM policies are created and deployed, let’s walk through how the policy is applied. For this demonstration, I’m using an iOS device and the Word app, however the Android experience is similar.

Find and download Microsoft Word from the iTunes store (if you need to deploy app, consider enrolling devices with Microsoft Intune). Once Word is downloaded, select the Word app and add the account where the user is a member of the Azure AD group added to the MAM policy. Once the user is logged in they’ll receive an alert similar to the image below. Select “OK” to close the app after 5 minutes or “Close” to close immediately. What is happening behind the scenes is the Microsoft Intune standalone MAM policy is being applied and needs to restart the Word app.


Once users re-launch the Word app, they’ll see the following:


To test the MAM policy, create a new Word doc and save it to the corporate O365 account (mine is the top account named


If the policy is set to require a PIN, your users will be asked to enter a pin at this point:

clip_image026 clip_image028

After the PIN is configured, name and save the doc to the corporate OneDrive account:


This concludes the walk-through of Microsoft Intune Mobile Application Management standalone.

Stay tuned for additional updates via the Microsoft Intune Blog:

Microsoft Intune and Apple Mac Management

The Microsoft Intune team recently announced the ability to enroll and manage the Apple Mac. I’m happy to say that the feature has been deployed as part of the recent Intune release. Today’s post will focus on Mac enrollment and management via Intune.

For details you can read more about the update and what management features are offered for Mac here: &


  • A Mac running OS X 10.9 or later
  • An Intune Subscription
  • User(s) assigned an Intune license so they can enroll



Let’s get started

On the Mac navigate to

Log in with an Azure Active Directory (Azure AD) user credential (someone who also has an Intune license assigned):


Notice the customization of the login page, this can all be changed via Azure Active Directory in the Azure portal.


Select “This device is either not enrolled or the Company Portal can’t identify it.”

Note: if you cancel out of the enrollment and go back later and don’t see the option to enroll, clear browsing history and close down Safari then reopen Safari, login, and the option should show up again.


Select “ENROLL” to begin the Intune enrollment process.


Select “Install” to install the Intune management profile.


Select “Show Profile” to view more about the profile being installed and select “Install” to continue with the installation. Depending on your settings you may be promoted to type in your Mac account password.


Another install prompt may appear, select “Show Profile” again to show the new information and rights being deployed. When finished reviewing, select “Continue” and “Install”.


Once the profiles are installed you’ll see a screen similar to the following:



After installation is complete, the enrollment windows in Safari will remain open. Go ahead and close those out and refresh the page that has “My Devices” on it. After the reload is complete, the Mac will show up with a check box.




Select the Mac to view whether or not it’s in compliance:


Once Mac’s are enrolled they’ll download and apply policies whether created before or after enrollment.


Intune Mac Policies

Policies available for Mac in this release are as follows (more info:

To set up a new Mac policy navigate to select Intune –> Device configuration –> Profiles –> Create profile



Select the type of Profile you’d like to deploy:

Overview of Mac OS X configuration policies with Intune:



Note: for custom configuration you’ll need to utilize download and utilize Apple Configurator on a Mac: 


Classic Intune Portal


In addition to the policies above Intune will track and report on Hardware and Software:



Need to deploy apps and go beyond Intune Mac management features?  Have a look at Mac management with System Center Configuration Manager (SCCM).

Need to manage devices beyond Mac? Intune will manage Android, iOS, Windows Phone, and Windows as well. Read more here:

Keep an eye out for new Intune updates here:

Microsoft Advanced Threat Analytics

Tracking down security vulnerabilities has always been a game of cat and mouse. Certain safeguards can be put in place to prevent security vulnerabilities such as blocking firewall ports, requiring multi-factor authentication and so on. Granted, no system can capture every single security vulnerability, however if a layered security approach is taken, there’s a better chance of catching security vulnerabilities and threats.

There’s also those deep vulnerabilities you’ve only read about but don’t have the necessary tools in place to capture or even check if they are occurring inside your network. Did you know that the average time attackers stay in a network before detection is over 200 days? If that is the case, then there is a lot to worry about including stolen passwords, confidential company data, customer data, and much more.

We’ve all seen the news where highly visible companies are compromised where credit card and customer information is stolen, and worse yet, published online. Have you been one of those affected? If not, what if it happened to the company you worked for? Would you be affected then? My guess is probably, one way or another.

What if you had a solution that was simple to deploy and began learning about your environment within minutes? Look no further, Microsoft Advanced Thread Analytics has a lot to offer, even with your existing security systems in place.

What is Microsoft Advanced Threat Analytics (ATA)?

Microsoft ATA is an on-premises solution that begins by learning about your environment, analyzing behaviors, and alerting on anomalous activity, attacks, and threats. Microsoft ATA will also integrate with existing SIEM’s.

How does ATA work?

Microsoft ATA works by capturing network traffic from domain controllers and by using machine learning, learns about behaviors within your network and alerts on abnormal behaviors.

There are four steps ATA takes: 

  1. Analyze – analyzes all Active Directory traffic as well as SIEM events.
  2. Detect – looks for anomalies and known security attacks and issues.
  3. Learn – leans about users and user behavior, devices, and resources then builds a graph mapping common behaviors.
  4. Alert – ATA raises alerts on suspicious activities and provides a timeline of activities of who, what, where, and when.

What types of issues are alerted by ATA?

ATA detects the following:

  • Abnormal user behavior: e.g. Anomalous logins, Password sharing, Lateral movement.
  • Malicious attacks: e.g. Pass-The-Ticket, Pass-The-Hash, Golden Ticket, Bruteforce attacks, remote execution, a much more.
  • Known security issues and risks: e.g. Broken Trust, Weak Protocols, Known protocol vulnerabilities.

What do alerts look like?

The following are a few example of actual alerts:

Reconnaissance Using DNS


Massive Object Deletion (from Active Directory)


Sensitive Credentials Exposed


Pass-The-Ticket Attack


What about architecture?

The architecture of ATA is very simple. It consists of a “Central Server” and one or more “Gateway Servers”.  Both can be deployed to VMs or physical machines. Again, ATA is currently an on premises solution.

  • Central Server: Central admin console (http) and the database (MongoDB).
  • Gateway Server(s): Destination for port mirrored network traffic from domain controllers.

Additionally, ATA uses self-signed certificates to communicate securely from the Gateway Server to the Central Server. Lastly, port mirroring is required from your domain controllers (source) to the Gateway Server(s) (destination).

For example, it took me about 10 minutes to set up, end-to-end, in my environment where I have two domain controllers.

Links to deployment information is under Additional Resource below.

The following is a sample architecture of ATA:


Download and try ATA today, because having more information about attacks, threats, and behaviors across your network is better than guessing.

Additional Resources

Learn more here:

Additional ATA resources such as release notes, deployment guides, operational guides , FAQ’s and more are located here: