Azure Information Protection Scanner

It has been a while since I last wrote about the Azure Information Protection Scanner. I still love the functionality, although there’s always some room for improvement.

Not too long ago Microsoft released the Unified Labeling client which supported using the scanner. So now you can use the scanner to scan, classify and protect documents on your on-premises file shares, NAS and SharePoint environments using the Microsoft 365 sensitivity labels.

For those of us who have not seen or used the scanner, I decided to create a little video on this. I hope you enjoy 🙂 But I also want to share some more information.

Terminology

As you can see in the figure above, there’s a couple of specific components used when configuring the scanner. Let’s take a look.

This server is the scanner itself (also called a Node). When you’re going to configure the scanner, you will need some components. For one, you will need a Windows Server. On this server you will install the Unified Labeling client. Using PowerShell you install (or upgrade) the scanner itself. When installing the scanner for the first time, a SQL database is created to store the policies. During the installation process, a Windows Server service is created, called Azure Information Protection Service, which runs using an Active Directory account.

You can have multiple servers or nodes, which are all part of a Cluster. This cluster is configured to use a  Content Scan Job. A content scan job contains the overall policy settings of the job (it’s run schedule for example) but also the content repositories to be scanned by the cluster.

Components required

In order to get the scanner to work, you will need several components. Most are straight forward:

• Windows Server
• SQL Server of Express
• An Active Directory account, with access to the repositories
• An Azure Active Directory account with the Azure Information Protection licence
• An Azure Application registration with the required permissions
• Azure Information Protection UL client

More information: https://docs.microsoft.com/en-us/azure/information-protection/deploy-aip-scanner-configure-install

Scanner service account

Some quick notes on the account. There are three ways of configuring the account which runs the scanner. All of these require the account running the scanner to have access to the repositories.

1. The preferred method is using an Active Directory account which is synched to Azure AD and has the AIP license;
2. The alternative (example below) is to use an Active Directory account which is not synched to Azure AD that works “on behalf off” a separate account in Azure Active Directory;
3. The last alternative is to use a local machine account that works “on behalf off” a separate account in Azure Active Directory. But this will not work for SharePoint on-premises repositories.

On the Windows Server, the scanner service account requires the Log on locally (for installation and configuration). This right can be removed when the scanner is working properly.  The Log on as a service is provided automatically during installation and is required throughout.

For the two alternatives you require an Azure Application Registration (or app registration) for the scanner to work in the background (unattended). This app registration will need specific access to Azure RMS and Microsoft Information Protection.  You will use a PowerShell cmdlet to connect this app-registration, the Azure Active Directory account and the scanner service account:

Set-AIPAuthentication -AppId <ID of the registered app> -AppSecret <client secret sting> -TenantId <your tenant ID> -DelegatedUser <Azure AD account>

For example:

$pscreds = Get-Credential CONTOSO\AIPScanner
Set-AIPAuthentication -AppId “77c3c14e-8b2b-4652836c8c66” -AppSecret “OAkk+rnuYc/u+]ah2kNxL4” -DelegatedUser AIPScanner@contoso.com -TenantId “9c11c87a-ac8b-46a3-8d5c-f4d0b72ee29a” -OnBehalfOf $pscreds

This should return a value of:

Acquired application access token on behalf of CONTOSO\AIPScanner.

But this cmdlet can only be run when other steps have finished. So let’s take a look at these.

Steps required

These are the steps to create the scanner:

1. Configure the scanner in the Azure portal (cluster, content scan job);
2. Install the scanner on the Windows Server;
3. Configure the app registration in order to get an Azure AD token (if needed);
4. Configure the scanner (finetune the content scan jobs).

Installing the scanner

When you install or update the scanner on the Windows Server, it will connect to a specific cluster – at which time it will download the content scan jobs into the SQL database. If the server isn’t connected to the internet, you can export the cluster and import this into the scanner using PowerShell.

For this installation process, you will use this PowerShell cmdlet:

Install-AIPScanner -SqlServerInstance <name> -Profile <cluster name>

For example:

Install-AIPScanner -SqlServerInstance SQLSERVER1 -Profile AzureIPScanCluster1

By the way: all the cmdlets in this post are included in the Azure Information Protection client installation 🙂

Now the scanner should be up and running and will appear in the Azure Information Protection dashboard – under Nodes. You can check if the Windows service Azure Information Protection Service is running. You can also use several PowerShell cmdlets to check this, for example:

• Start-AIPScannerDiagnostics
• Get-AIPScannerStatus

In all – if you have on-premises repositories you want to scan and classify, and you have the relevant licenses :-), then please check out the scanner.