Classified

High Degree of Automation

AIP is very practical thanks to two elements that offer a great variety for daily use. On the one hand, scoped policies are only applied to the client if either the user is entered directly in the policy or is a member of an AD group contained there. Other users will not even see the policy's name. The only condition is that the group or user account has an email address in its properties.

The second guarantee of high practicality is the ability to classify documents automatically on the basis of document content, in addition to the manual procedure. The result could be a simple label (e.g., a watermark in a Word document or a header or footer) and can be done automatically if certain character strings appear in the document. If desired, documents can also be encrypted in this context.

In a practical example, it works as follows: Assume you are an administrator and are writing instructions for server installations, in which you might need to document passwords. In this case, the document should have a header that indicates the confidential content, and access to the document should be protected. Because this is a special policy, another requirement is that only administrators should see it.

Creating User Policies

To create user policies, first open the AIP administration page in the Azure portal and create a scoped policy by assigning it a name and selecting Add a new policy . The difference from a default policy is that you can specify a group or user object for which this policy and the terms it contains apply – a kind of filter. For example, you could use an AD group named ROL-Cust-ITAdmins , which is maintained in the local AD and synchronized with Office 365 using AD Connect.

It would be a bit more complicated to manage users and groups directly in Azure AD. In this case, and for the policy, it does not matter where the group comes from; it is only important that an email address is entered in the properties. The scoped policy allows users to see all the terms from this policy on their end devices. What is still missing is a designation within the directive that defines in detail what is to be done. To stick to the example, specify that the document should have a header and activate protection; then, enter two conditions that search for the strings "password" or "confidential" in the text. If these are found when processing documents later, the security settings are applied.

Now you just have to publish the directive. The new terms are displayed at the next update interval on the mobile device or when an Office application starts. The first time a user saves a document that fulfils these conditions, a note indicating the actions taken is displayed. Depending on how the designation is configured, the user has the choice to apply the policy, or it is automatically enabled without the user's intervention. This is a simple example of how AIP works.

One great feature of such policies is that no matter in which Office product the user typed the password string, it is always recognized, and the actions defined in the policy are applied. The client does not distinguish between a PowerPoint presentation or Excel spreadsheet. If you have created confidential files with an application for which there is no AIP client, you can select the file with a right-click in File Explorer and assign a designation from the context menu using the Classify and protect command. If you do this for a folder, all files in it are given the new designation. If the folder already contains classified files, a stricter setting will apply to all files without feedback.

If the protection is weakened, the AIP client alerts you and lets you skip individual files. If you copy files into the folder later on, these files remain unchanged and are not classified automatically. This is different from the familiar process of inheriting rights in the filesystem. It should also be noted that only one designation is used for email and documents. The exception would be if a subordinate designation exists, which you should indicate by using characteristics such as the header; otherwise, it quickly becomes unclear.

Logging On to the AIP Client

The AIP client complements the Office applications with a snap-in. At first launch, the snap-in is initialized and the user needs to enter their login information just once. AIP remembers the login details and acts in this context from that point on, and the policies and designations that are relevant for the user are displayed in the toolbar. Unfortunately, it is not possible to log off and back on to the Microsoft cloud from an Office application. Also, the AIP client does not contain any software that can be called to change the user context.

For example, if the administrator has to work with other user information for test purposes, the TokenCache value under HKEY_CURRENT_USER\Software\Microsoft\MSIP first needs to be removed from the registry. This does not mean the content of the character string; instead, the entire word can be deleted. When the snap-in is initialized at the next launch, the client prompts for login information again and creates TokenCache once again.