The Evolution of AD RMS to Azure Information Protection – Part 4 – Preparation and Server-Side Migration

The Evolution of AD RMS to Azure Information Protection – Part 4 – Preparation and Server-Side Migration

The time has finally come to get our hands dirty.  Welcome to my fourth post on the evolution of Active Directory Rights Management Service (AD RMS) to Azure Information Protection (AIP).  So far in this series I’ve done an overview of the service, a comparison of the architectures, and covered the key planning decisions that need to place when migrating from AD RMS to AIP.  In this post I’ll be performing the preparation and server-side migration steps for the migration from AD RMS to AIP.

Microsoft has done a wonderful job documenting the steps for the migration from AD RMS to AIP within the migration guide.  I’ll be referencing back to the guide as needed throughout the post.  Take a look at my first post for a refresher of my lab setup.  Take note I’ll be migrating LAB2 and will be leaving LAB1 on AD RMS.  Here are some key things to remember about the lab:

  • There is a forest trust between the JOG.LOCAL and GEEKINTHEWEEDS.COM Active Directory Forests
  • AD RMS Trusted User Domains (TUDs) have been configured on both JOG.LOCAL and GEEKINTHEWEEDS.COM

I’ve created the following users, groups, and AD RMS templates (I’ve been on an 80s/90s movies fix, so enjoy the names).

  • GEEKINTHEWEEDS.COM CONFIGURATION
    • (User) Jason Voorhies
      • User Principal Name Attribute: jason.voorhies@geekintheweeds.com
      • Mail Attribute: jason.voorhies@geekintheweeds.com
      • Group Memberships: Domain Users, GIW Employees, Information Technology
    • (User) Theodore Logan
      • User Principal Name Attribute: theodore.logan@geekintheweeds.com
      • Mail Attribute: theodore.logan@geekintheweeds.com
      • Group Memberships: Domain Users, GIW Employees, Information Technology
    • (User) Ash Williams
      • User Principal Name Attribute: jason.voorhies@geekintheweeds.com
      • Mail Attribute: ash.williams@geekintheweeds.com
      • Group Memberships: Domain Users, GIW Employees, Accounting
    • (User) Michael Myers
      • User Principal Name Attribute: michael.myers@geekintheweeds.com
      • Mail Attribute: michael.myers@geekintheweeds.com
      • Group Memberships: Domain Users, GIW Employees, Accounting
    • (Group) Accounting
      • Mail Attribute: giwaccounting@geekintheweeds.com
      • Group Type: Universal Distribution
    • (Group) GIW Employees
      • Mail Attribute: giwemployees@geekintheweeds.com
      • Group Type: Universal Distribution
    • (Group) Information Technology
      • Mail Attribute: giwit@geekintheweeds.com
      • Group Type: Universal Distribution
    • (Group) GIW AIP Users
      • Group Type: Global Security
    • (AD RMS Template) GIW Accounting
      • Users: giwaccounting@geekintheweeds.com
      • Rights: Full Control
    • (AD RMS Template) GIW Employees
      • Users: giwemployees@geekintheweeds.com
      • Rights: View, View Rights
    • (AD RMS Template) GIW IT
      • Users: giwit@geekintheweeds.com
      • Rights: Full Control
  • JOG.LOCAL CONFIGURATION

    • (User) Luke Skywalker
      • User Principal Name Attribute: luke.skywalker@jog.local
      • Mail Attribute: luke.skywalker@jog.local
      • Group Memberships: Domain Users, jogemployees
    • (User) Han Solo
      • User Principal Name Attribute: han.solo@jog.local
      • Mail Attribute: han.solo@jog.local
      • Group Memberships: Domain Users, jogemployees
    • (Group) jogemployees
      • Mail Attribute: jogemployees@jog.local
      • Group Type: Universal Distribution

After my lab was built I performed the following tests:

  • Protected Microsoft Word document named GIW_LS_ADRMS with GEEKINTHEWEEDS.COM AD RMS Cluster and successfully opened with Luke Skywalker user from JOG.LOCAL client machine.
  • Protected Microsoft Word document named GIW_GIWALL_ADRMS with GEEKINTHEWEEDS.COM AD RMS Cluster and GIW Employees template and unsuccessfully opened with Luke Skywalker user from JOG.LOCAL client machine.
  • Protected Microsoft Word document named GIW_JV_ADRMS with GEEKINTHEWEEDS.COM AD RMS Cluster using Theodore Logan user and opened successfully with Jason Voorhies user from GEEKINTHEWEEDS.COM client machine.
  • Protected Microsoft Word document named JOG_MM_ADRMS with JOG.LOCAL AD RMS Cluster using Luke Skywalker user and opened successfully with Michael Myers user from GEEKINTHEWEEDS.COM client machine.
    Protected Microsoft Word document named GIW_ACCT_ADRMS with GEEKINTHEWEEDS.COM AD RMS Cluster and GIW Accounting template and was unsuccessful in opening with Jason Voorhies user from GEEKINTHEWEEDS.COM client machine.

These tests verified both AD RMS clusters were working successfully and the TUD was functioning as expected.  The lab is up and running, so now it’s time to migrate to AIP!

Our first step is to download the AADRM PowerShell module from Microsoft.  I went the easy route and used the install-module cmdlet.

AIP4PIC1.png

Back in March Microsoft announced that AIP would be enabled by default on any eligible tenants with O365 E3 or above that were added after February.  Microsoft’s migration guide specifically instructs you to ensure protection capabilities are disabled if you’re planning a migration from AD RMS to AIP.  This means we need to verify that AIP is disabled.  To do that, we’re going to use the newly downloaded AADRM module to verify the status.

AIP4PIC2.png

As expected, the service is enabled.  We’ll want to disable the service before beginning the migration process by running the Disable-Aadrm cmdlet.  After running the command, we see that the functional state is now reporting as disabled.

AIP4PIC3.png

While we have the configuration data up we’re going to grab the value (minus _wmcs/licensing) in the  LicensingIntranetDistributionPointUrl property.  We’ll be using this later on in the migration process.

In most enterprise scenarios you’d want to perform a staged migration process of your users from AD RMS to AIP.  Microsoft provides for this with the concept of onboarding controls.  Onboarding controls allow you to manage who has the ability to protect content using AIP even when the service has been enabled at the tenant level.  Your common use case would be creating an Azure AD-managed or Windows AD-synced group which is used as your control group.  Users who are members of the group and are licensed appropriately would be able to protect content using AIP.  Other users within the tenant could consume the content but not protect it.

In my lab I’ll be using the GIW AIP Users group that is being synchronized to Azure AD from my Windows AD as the control group.  To use the group I’ll need to get its ObjectID which is the object’s unique identifier in Azure AD.  For that I used the Get-AzureADGroup cmdlet within Azure AD PowerShell module.

AIP4PIC6

Microsoft’s migration guide next suggests come configuration modifications to Windows computers within the forest.  I’m going to hold off on this for now and instead begin the server-side migration steps.

First up we’re going to export the trusted publisher domains (TPDs) from the AD RMS cluster.  We do this to ensure that users that have migrated over to AIP are still able to open content that was previously protected by the AD RMS cluster.  The TPD includes the Server Licensor Certificate (SLC) keys so when exporting them we protect them with a password and create an XML file that includes the SLC keys and any custom AD RMS rights policy templates.

AIP4PIC7.png

Next we import the exported TPD to AIP using the relevant process based upon how we chose to protect the cluster keys.  For this lab I used a software key (stored in the AD RMS database) so I’ll be using the software key to software key migration path.  Thankfully this path is quite simple and consists of running another cmdlet from the AADRM PowerShell module.  In the first command we store the password used to protect the TPD file as a secure string and use the Import-AadrmTpd cmdlet to pull it into AIP.  Notice the resulting data provides the cluster friendly name, indicates the Cryptographic Mode was set to 1, the key was a Microsoft-managed (aka software key) and there were three rights policy templates attached to the TPD.

Keep in mind that if you have multiple TPDs for some reason (let’s say you migrated from Cryptographic Mode 1 to Cryptographic Mode 2) you’ll need to upload each TPD separately and set the active TPD using the Set-AadrmKeyProperties cmdlet.

AIP4PIC8.png

Running a Get-AadrmTemplate shows the default templates Microsoft provides you with as well as the three templates I had configured in AD RMS.

AIP4PIC9

The last step of the server side of the process is to activate AIP.  For that we use the Enable-Aadrm cmdlet from the AADRM PowerShell module.

AIP4PIC10

At this point the server-side configuration steps have been completed and AIP is ready to go.  However, we still have some very important client-side configuration steps to perform.  We’ll cover those steps in my post.

Have a great week!

The Evolution of AD RMS to Azure Information Protection – Part 1

The Evolution of AD RMS to Azure Information Protection – Part 1

Collaboration.  It’s a term I hear at least a few times a day when speaking to my user base.  The ability to seamlessly collaborate with team members, across the organization, with trusted partners, and with customers is a must.  It’s a driving force between much of the evolution of software-as-a-service collaboration offerings such as Office 365.  While the industry is evolving to make collaboration easier than ever, it’s also introducing significant challenges for organizations to protect and control their data.

In a recent post I talked about Microsoft’s entry into the cloud access security broker (CASB) market with Cloud App Security (CAS) and its capability to provide auditing and alerting on activities performed in Amazon Web Services (AWS).  Microsoft refers to this collection of features as the Investigate capability of CAS.  Before I cover an example of the Control features in action, I want to talk about the product that works behind the scenes to provide CAS with many of the Control features.

That product is Azure Information Protection (AIP) and it provides the capability to classify, label, and protect files and email.  The protection piece is provided by another Microsoft product, Azure Active Directory Rights Management Services (Azure RMS).  Beyond just encrypting a file or email, Azure RMS can control what a user can do with a file such as preventing a user from printing a document or forwarding an email.  The best part?  The protection goes with the data even when it leaves your security boundary.

For those of you that have read my blog you can see that I am a huge fanboy of the predecessor to Azure RMS, Active Directory Rights Management Services (AD RMS, previously Rights Management Service or RMS for you super nerds).  AD RMS has been a role available in Microsoft Windows Server since Windows Server 2003.  It was a product well ahead of its time that unfortunately never really caught on.  Given my love for AD RMS, I thought it would be really fun to do a series looking at how AIP has evolved from AD RMS.   It’s a dramatic shift from a rather unknown product to a product that provides capabilities that will be as standard and as necessary as Antivirus was to the on-premises world.

I built a pretty robust lab environment (two actually) such that I could demonstrate the different ways the solutions work as well as demonstrate what it looks to migrate from AD RMS to AIP.  Given the complexity of the lab environment,  I’m going to take this post to cover what I put together.

The layout looks like this:

 

1AIP1.png

On the modern end I have an Azure AD tenant with the custom domain assigned of geekintheweeds.com.  Attached to the tenant I have some Office 365 E5 and Enterprise Mobility + Security E5 trial licenses  For the legacy end I have two separate labs setup in Azure each within its own resource group.  Lab number one contains three virtual machines (VMs) that run a series of services included Active Directory Domain Services (AD DS), Active Directory Certificate Services (AD CS), AD RMS, and Microsoft SQL Server Express.  Lab number two contains four VMs that run the same set as services as Lab 1 in addition to Active Directory Federation Services (AD FS) and Azure Active Directory Connect (AADC).  The virtual network (vnet) within each resource group has been peered and both resource groups contain a virtual gateway which has been configured with a site-to-site virtual private network (VPN) back to my home Hyper-V environment.  In the Hyper V environment I have two workstations.

Lab 1 is my “legacy” environment and consists of servers running Windows 2008 R2 and Windows Server 2012 R2 (AD RMS hasn’t changed in any meaningful manner since 2008 R2) and a client running Windows 7 Pro running Office 2013.  The DNS namespace for its Active Directory forest is JOG.LOCAL.  Lab 2 is my “modern” environment and consists of servers running Windows Server 2016 and a Windows 10 client running Office 2016 .  It uses a DNS namespace of GEEKINTHEWEEDS.COM for its Active Directory forest and is synchronized with the Azure AD tenant I mentioned above.  AD FS provides SSO to Office 365 for Geek in The Weeds users.

For AD RMS configuration, both environments will initially use Cryptographic Mode 1 and will have a trusted user domain (TUD).  SQL Server Express will host the AD RMS database and I will store the cluster key locally within the database.  The use of a TUD will make the configuration a bit more interesting for reasons you’ll see in a future post.

Got all that?

In my next post I’ll cover how the architecture changes when migrating from AD RMS to Azure Information Protection.