Securing Your Windows 10 Login With Yubikey

Posted on 2 CommentsPosted in MFA, MVP, security, yubikey

The Yubikey is a small USB connected hardware device that can generate a variety of security codes. Being virtually indestructible and easy to clip to a key ring (Yubikey 4) or leave inside your only device (Yubikey 4 Nano) you can now use this token to login to Windows. Once you have got your token from Yubico (via Amazon or other resellers) for around £40 you start the very simple Windows Hello authentication registration process by downloading the Yubikey app from Windows App Store.  Signing in after a restart requires full credentials (password or PIN), which means a stranger who steals your PC and the YubiKey can’t use it to access your device

Open the Store app, search for Yubikey and click the logo for the app.

image

Click the Get button to install the app then then launch to start it. In a corporate environment you can push the app to your devices with MDM solutions like Intune.

Launch the app. You will need to have a PIN login enabled for the device to work and so you will see a warning if you do not have this enabled.

image

If you need to set up a PIN then close the Yubikey app and type “PIN” in the search box in Windows and choose “Setup PIN sign-in”

image

Scroll down and click Add under PIN. You will need to reenter your password so other people cannot set up a PIN on your behalf.

Enter a PIN and confirm the same PIN

image

You will now be able to use a PIN to sign in. The PIN setup process will continue and you will be asked to confirm your PIN again. You can now use your PIN to sign into your computer, which as it is tied to the computer hardware, is more secure than your password. But we are not stopping there – we can now restart the Yubikey app. Either launch it from the Store app, from the search box on the Start Menu or From the Start menu, select All Apps >Start > YubiKey for Windows Hello

image

Click Register to start the process of pairing your Yubikey to your computer

image

Insert your Yubikey into any USB port on the PC and press Continue

image

Name the Yubikey, as at login it will ask you to insert this named key. Click Continue once you have a name

image

At this point it should register the device and all is good!

If you find that Windows Companion Devices are disabled then you will get this error:

image

It reads “Oh no! An error occurred during registration. Windows companion devices are disabled on this system. Contact your system administrator”. This is because the local security policy on your computer or network via your Active Directory and IT driven polices does not allow companion devices. On systems running Windows Pro or Windows Enterprise systems, you must enable the option to Allow companion device for secondary authentication in the Local Security Policy. If your organization manages your security policy, contact your IT administrator and request this change before installing this app. You cannot change local security policy on systems running Windows Home, however this option is enabled by default. Note that you will also get this on domain joined systems as well, as secondary auth is not supported on domain joined machines (even for individual users) at this time.

To modify local security policy

  1. Open the Local Group Policy Editor. To do this, press the Windows key, type R, and then type gpedit.msc.
  2. In the Local Group Policy Editor, from the top level Local Computer Policy, navigate to Computer Configuration > Administrative Templates > Windows Components > Microsoft Secondary Authentication Factor.
  3. In the right pane, click the link to Edit policy setting. (You can also double-click the setting to Allow companion device for secondary authentication.) The default state is Not configured.
  4. In the setting screen, select the option for Enabled, and click OK. If this option is already selected, your policy is set and you can click Cancel.
  5. Exit the Local Group Policy Editor and the Management Console.

Managing Office 365 Groups With Remote PowerShell

Posted on 2 CommentsPosted in Azure, cloud, exchange, exchange online, groups, IAmMEC, mcm, mcsm, MVP, Office 365, owa, powershell

Announced during Microsoft Ignite 2015, there are now PowerShell administration cmdlets available for the administration of the Groups feature in Office 365.

The cmdlets are all based around “UnifedGroups”, for example Get-UnifiedGroups.

Create a Group

Use New-UnifiedGroup to do this. An example would be New-UnifiedGroup -DisplayName “Sales” -Alias sales –EmailAddress sales@contoso.com

The use of the EmailAddress parameter is useful as it allows you to set a group that is not given an email address based on your default domain, but from one of the other domains in your Office 365 tenant.

Modify a Groups Settings

Use Set-UnifiedGroup to change settings such as the ability to receive emails from outside the tenant (RequireSenderAuthenticationEnabled would be $false), limit email from a whitelist (AcceptMessagesOnlyFromSendersOrMembers) and other Exchange distribution list settings such as hidden from address lists, mail tips and the like. AutoSubscribeNewMembers can be used to tell the group to email all new messages to all new members, PrimarySmtpAddress to change the email address that the group sends from.

Remove a Group

This is the new Remove-UnifiedGroup cmdlet.

Add Members to a Group

This cmdlet is Add-UnifiedGroupLinks. For example Add-UnifiedGroupLinks sales -LinkType members -Links brian,nicolas will add the two names members to the group. The LinkType value can be members as shown, but also “owners” and “subscribers” to add group administrators (owners) or just those who receive email sent to the group but not access to the groups content. To change members to owners you do not need to remove the members, just run something like Add-UnifiedGroupLinks sales –LinkType owners -Links brian,nicolas

You can also pipe in a user list from, for example a CSV file, to populate a group. This would read: Add-UnifiedGroupLinks sales -LinkType members -Links $users where $users = Get-Content username.csv would be run before it to populate the $users variable. The source of the variable can be anything done in PowerShell.

Remove Members from a Group

For this use Remove-UnifiedGroupLinks and mention the group name, the LinkType (member, owner or subscriber) and the user or users to remove.

To Disable Group Creation in OWA

Set-OWAMailboxPolicy is used to create a policy that is not allowed to create Groups and then users have that policy applied to them. For example Set-OWAMailboxPolicy “Students” –GroupCreationEnabled $false followed by Set-CASMailbox mary –OWAMailboxPolicy Students to stop the user “mary” creating groups. After the policy is assigned and propagates around the Office 365 service, the user can join and leave groups, but not create them.

Control Group Naming

This feature allows you to control the group name or block words from being used. This is easier to set in the Distribution Groups settings in Exchange Control Panel rather than via PowerShell. To do this EAC use Recipients > Groups and click the ellipses icon (…) and select Configure Group Naming Policy. This is the same policy for distribution groups. You can add static text to the start or end of name, as well as dynamic text such as region.

Admins creating groups are not subject to this policy, but unlike DL’s if they create groups in PowerShell the policy is also not applied and so the -IgnoreNamingPolicy switch is not required.

Exchange OWA and Multi-Factor Authentication

Posted on 14 CommentsPosted in 2010, 2013, Azure, exchange, IAmMEC, MFA, MVP, owa, smartphone

Multi-factor authentication (MFA), that is the need to have a username, password and something else to pass authentication is possible with on-premises servers using a service from Windows Azure and the Multi-Factor Authentication Server (an on-premises piece of software).

The Multi-Factor Authentication Server intercepts login request to OWA, if the request is valid (that is the username and password work) then the mobile phone of the user is called or texted (or an app starts automatically on the phone) and the user validates their login. This is typically done by pressing # (if a phone call) or clicking Verify in the app, but can require the entry of a PIN as well. Note that when the MFA server intercepts the login request in OWA, there is no user interface in OWA to tell you what is happening. This can result in user disconnect and stops the use of two-way MFA (receive number by text, type number into web application type scenario). Therefore to that end, MFA directly on the OWA application is not supported by the Microsoft Exchange team. Steps for setting up ADFS for Exchange Server 2013 SP1 or later are at https://technet.microsoft.com/en-us/library/dn635116(v=exchg.150).aspx. Once this is in place, you need to enable MFA for ADFS rather than MFA for OWA. I have covered this in a separate post at http://c7solutions.com/2016/04/installing-azure-multi-factor-authentication-and-adfs.

To configure Multi-Factor Authentication Server for OWA (unsupported) you need to complete the following steps:

Some of these steps are the same regardless of which service you are adding MFA to and some slightly different. I wrote a blog on MFA and VPN at http://c7solutions.com/2015/01/windows-rras-vpn-and-multi-factor-authentication and this contains the general setup steps and so these are not repeated here. Just what you need to do differently

Step 1

See http://c7solutions.com/2015/01/windows-rras-vpn-and-multi-factor-authentication

Step 2: Install MFA Server on-premises

This is covered in http://c7solutions.com/2015/01/windows-rras-vpn-and-multi-factor-authentication, but the difference with OWA is that it needs to be installed on the Exchange CAS server where the authentication takes place.

Ensure you have .NET 3.5 installed via Server Manager > Features. This will install the .NET 2.0 feature that is required by MFA server. If the installation of the download fails, this is the most likely reason for the failure, so install .NET 3.5 and then try the MFA Server install again.

The install of the MFA server does not take very long. After a few minutes the install will complete and then you need to run the Multi-Factor Authentication Server admin tools. These are on the Start Screen in More Apps or the Start Menu. Note that it will start the software itself if given time:

image

image

Do not skip the wizard, but click Next. You will be asked to activate the server. Activating the server is linking it to your Azure MFA instance. The email address and password you need are obtained from the Azure multi-factor auth provider that was configured in Step 1. Click the Generate Activation Credentials on the Downloads page of the Azure MFA provider auth management page.

image

The credentials are valid for ten minutes, so your will differ from mine. Enter them into the MFA Server configuration wizard and click Next.

MFA Server will attempt to reach Azure over TCP 443.

Select the group of servers that the configuration should replicate around. For example, if you where installing this software on each Exchange CAS server, then you might enter “Exchange Servers” as the group name in the first install and then select it during the install on the remaining servers. This config will be shared amongst all servers with the same group name. If you already have a config set up with users in it and set up a new group here, then it will be different settings for the users. For example you might have a phone call to authenticate a VPN connection but use the app for OWA logins. This would require two configs and different groups of servers. If you want the same settings for all users in the entire company, then one group (the default group) should be configured.

image

Next choose if you want to replicate your settings. If you have more than one MFA Server instance in the same group select yes.

Then choose what you want to authenticate. Here I have chosen OWA:

image

Then I need to choose the type of authentication I have in place. In my OWA installation I am using the default of Forms Based Authentication, but if you select Forms-based authentication here, the example URL for forms based authentication shown on the next page is from Exchange Server 2003 (not 2007 or later). Therefore I select HTTP authentication

Next I need to provide the URL to OWA. I can get this by browsing the OWA site over https. The MFA install will also use HTTPS, so you will need a certificate and have this trusted by a third party if you want to support user managed devices. Users managing their own MFA settings (such as telephone numbers and form of authentication) reduces the support requirement. That needs the User Portal, the SDK and the Mobile App webservice installed as well. These are outside the scope of this blog. For here I am going to use https://servername/owa.

image

Finish the installation at this time and wait for the admin application to appear.

Step 3: Configure Users for MFA

Here we need to import the users who will be authenticated with MFA. Select the Users area and click Import from Active Directory. Browse the settings to imports group members, or OUs or a search to add your user account. Once you have it working for yourself, add others. Users not listed here will not see any change in their authentication method.

Ensure that your test user has a mobile number imported from the Active Directory. If not add one, choosing the correct country code as well. The default authentication for the user is that they will get a phone call to this number and need to press # before they can be logged in. Ensure that the user is set to Enabled as well in the users area of the management program.

Step 4: Configure OWA for MFA (additional steps)

On the IIS Authentication node you can adjust the default configuration for HTTP. Here you need to set Require Multi-Factor Authentication user match. This ensures that each auth attempt is matched to a user in the users list. If the user exists and is enabled, then do MFA for them. If disabled, then the setting for Succeed Authentication on the advanced tab comes into play. If the user is not listed, authentication passes through without MFA.

image

Change to the Native Module tab and select OWA under Default Web Site only. Do not set authentication on the Backend Web Site. Also enable the native module on ECP on the Default Web Site as well:

image

Then I can attempt a login to OWA or ECP. Once I successfully authenticate my phone rings and I am prompted to press #. Once I press # I am allowed into Exchange!

The Case of the Disappearing Folders

Posted on 3 CommentsPosted in 2013, exchange online, IAmMEC, MVP, Office, Office 365 ProPlus, Outlook

Here is a issue I have come across at one of my current clients – you create a folder in Outlook 2013 when in the “Mail” view (showing only mail folders – your typical default view) and the folder does not get created. For example, in the below picture the user is in the middle of creating a folder called “Test Inline” as a child of the “SO” folder:

image

Upon pressing Enter, the folder disappears and fails to be created:

image

So where does one see this issue? It happens when the parent folder in question, in this case the “SO” folder is created by Microsoft’s PST Capture Tool. The PST Capture Tool creates a parent folder in the Online Archive in Exchange (in this case Exchange Online but it does not matter which Exchange Server) named after the PST file, so in this case SO.pst was uploaded by the PST Capture Tool. Any attempt to create folders inline below this parent folder fails! If you drag content into this folder it will not allow you to drop the content in, and the folder appears to be read-only.

If you change Outlooks view to Folder view (click the … on the Outlook 2013 view bar to the right) then you can create folders (using a dialog) and that works fine – this is how “Test Dialog” was made in the above pictures.

In Outlook 2010 all works as expected! In Outlook 2013 the issue appears to be the way Outlook handles folders that have a MAPI property on the folder created with a null value. In tools such as MFCMapi and OutlookSpy you can view the MAPI properties of a folder and the folder created by PST Capture Tool has a property call PR_CONTAINER_CLASS_W with a null (empty) value. Normally, Outlook will make folders that have “IPF.Note” as the value of this folder, if this is a mail and notes folder (i.e. not a calendar or contact etc folder). But clearly there is a problem, as Folder view allows you to create subfolders when the parent’s PR_CONTAINER_CLASS_W value is null and so does Outlook 2010 and coincidently does OWA!

The fix, but I do not have it ready yet, is to run an EWS script to reset the PR_CONTAINER_CLASS_W property of this folder to IPF.Note or wait for an update to Outlook from Microsoft, and for that I have contacted them.

With thanks to fellow MVP Jaap Wesselius for double-checking this for me and testing it in Outlook 2010.

Speaking at TechEd Europe 2014

Posted on 4 CommentsPosted in certificates, cloud, EOP, exchange, exchange online, Exchange Online Protection, GeoDNS, hybrid, IAmMEC, journaling, mcm, mcsm, MVP, Office 365, smarthost, smtp, starttls, TechEd, TLS, transport

I’m please to announce that Microsoft have asked me to speak on “Everything You Need To Know About SMTP Transport for Office 365” at TechEd Europe 2014 in Barcelona. Its going to be a busy few weeks as I go from there to the MVP Summit in Redmond, WA straight from that event.

image

My session is going to see how you can ensure your migration to Office 365 will be successful with regards to keeping mail flow working and not seeing any non-deliverable messages. We will cover real world scenarios for hybrid and staged migrations so that we can consider the impact of mail flow at all stages of the project. We will look at testing mail flow, SMTP to multiple endpoints, solving firewalling issues, and how email addressing and distribution group delivery is done in Office 365 so that we always know where a user is and what is going to happen when they are migrated.

Compliance and hygiene issues will be covered with regards to potentially journaling from multiple places and the impact of having anti-spam filtering in Office 365 that might not be your mail flow entry point.

We will consider the best practices for changing SMTP endpoints and when is a good time to change over from on-premise first to cloud first delivery, and if you need to maintain on-premises delivery how should you go about that process.

And finally we will cover troubleshooting the process should it go wrong or how to see what is actually happening during your test phase when you are trying out different options to see which works for your company and your requirements.

Full details of the session, once it goes live, are at http://teeu2014.eventpoint.com/topic/details/OFC-B350 (Microsoft ID login needed to see this). Room and time to be announced.

Configuring Exchange On-Premises to Use Azure Rights Management

Posted on 7 CommentsPosted in 2010, 2013, 64 bit, aadrm, ADFS, ADFS 2.0, DLP, DNS, exchange, exchange online, https, hybrid, IAmMEC, load balancer, loadbalancer, mcm, mcsm, MVP, Office 365, powershell, rms, sharepoint, warm

This article is the fifth in a series of posts looking at Microsoft’s new Rights Management product set. In an earlier previous post we looked at turning on the feature in Office 365 and in this post we will look at enabling on-premises Exchange Servers to use this cloud based RMS server. This means your cloud users and your on-premises users can shared encrypted content and as it is cloud based, you can send encrypted content to anyone even if you are not using an Office 365 mailbox.

In this series of articles we will look at the following:

The items above will get lit up as the articles are released – so check back or leave a comment to the first post in the series and I will let you know when new content is added.

Exchange Server integrates very nicely with on-premises RMS servers. To integrate Exchange on-premises with Windows Azure Rights Management you need to install a small service online that can connect Exchange on-premises to the cloud RMS service. On-premises file servers (classification) and SharePoint can also use this service to integrate themselves with cloud RMS.

You install this small service on-premises on servers that run Windows Server 2012 R2, Windows Server 2012, or Windows Server 2008 R2. After you install and configure the connector, it acts as a communications interface between the on-premises IRM-enabled servers and the cloud service. The service can be downloaded from http://www.microsoft.com/en-us/download/details.aspx?id=40839

From this download link there are three files to get onto the server you are going to use for the connector.

  • RMSConnectorSetup.exe (the connector server software)
  • GenConnectorConfig.ps1 (this automates the configuration of registry settings on your Exchange and SharePoint servers)
  • RMSConnectorAdminToolSetup_x86.exe (needed if you want to configure the connector from a 32bit client)

Once you have all this software (or that which you need) and you install it then IT and users can easily protect documents and pictures both inside your organization and outside, without having to install additional infrastructure or establish trust relationships with other organizations.

The overview of the structure of the link between on-premises and Windows Azure Rights Management is as follows:

IC721938

Notice therefore that there are some prerequisites needed. You need to have an Office 365 tenant and turn on Windows Azure Rights Management. Once you have this done you need the following:

  • Get your Office 365 tenant up and running
  • Configure Directory Synchronization between on-premises Active Directory and Windows Azure Active Directory (the Office 365 DirSync tool)
  • It is also recommended (but not required) to enable ADFS for Office 365 to avoid having to login to Windows Azure Rights Management when creating or opening protected content.
  • Install the connector
  • Prepare credentials for configuring the software.
  • Authorising the server for connecting to the service
  • Configuring load balancing to make this a highly available service
  • Configuring Exchange Server on-premises to use the connector

Installing the Connector Service

  1. You need to set up an RMS administrator. This administrator is either the a specific user object in Office 365 or all the members of a security group in Office 365.
    1. To do this start PowerShell and connect to the cloud RMS service by typing Import-Module aadrm and then Connect-AadrmService.
    2. Enter your Office 365 global administrator username and password
    3. Run Add-AadrmRoleBasedAdministrator -EmailAddress <email address> -Role “GlobalAdministrator” or Add-AadrmRoleBasedAdministrator -SecurityGroupDisplayName <group Name> -Role “ConnectorAdministrator”. If the administrator object does not have an email address then you can lookup the ObjectID in Get-MSOLUser and use that instead of the email address.
  2. Create a namespace for the connector on any DNS namespace that you own. This namespace needs to be reachable from your on-premises servers, so it could be your .local etc. AD domain namespace. For example rmsconnector.contoso.local and an IP address of the connector server or load balancer VIP that you will use for the connector.
  3. Run RMSConnectorSetup.exe on the server you wish to have as the service endpoint on premises. If you are going to make a highly available solutions, then this software needs installing on multiple machines and can be installed in parallel. Install a single RMS connector (potentially consisting of multiple servers for high availability) per Windows Azure RMS tenant. Unlike Active Directory RMS, you do not have to install an RMS connector in each forest. Select to install the software on this computer:
    IC001
  4. Read and accept the licence agreement!
  5. Enter your RMS administrator credentials as configured in the first step.
  6. Click Next to prepare the cloud for the installation of the connector.
  7. Once the cloud is ready, click Install. During the RMS installation process, all prerequisite software is validated and installed, Internet Information Services (IIS) is installed if not already present, and the connector software is installed and configured
    IC002
  8. If this is the last server that you are installing the connector service on (or the first if you are not building a highly available solution) then select Launch connector administrator console to authorize servers. If you are planning on installing more servers, do them now rather than authorising servers:
    IC003
  9. To validate the connector quickly, connect to http://<connectoraddress>/_wmcs/certification/servercertification.asmx, replacing <connectoraddress> with the server address or name that has the RMS connector installed. A successful connection displays a ServerCertificationWebService page.
  10. For and Exchange Server organization or SharePoint farm it is recommended to create a security group (one for each) that contains the security objects that Exchange or SharePoint is. This way the servers all get the rights needed for RMS with the minimal of administration interaction. Adding servers individually rather than to the group results in the same outcome, it just requires you to do more work. It is important that you authorize the correct object. For a server to use the connector, the account that runs the on-premises service (for example, Exchange or SharePoint) must be selected for authorization. For example, if the service is running as a configured service account, add the name of that service account to the list. If the service is running as Local System, add the name of the computer object (for example, SERVERNAME$).
    1. For servers that run Exchange: You must specify a security group and you can use the default group (DOMAIN\Exchange Servers) that Exchange automatically creates and maintains of all Exchange servers in the forest.
    2. For SharePoint you can use the SERVERNAME$ object, but the recommendation configuration is to run SharePoint by using a manually configured service account. For the steps for this see http://technet.microsoft.com/en-us/library/dn375964.aspx.
    3. For file servers that use File Classification Infrastructure, the associated services run as the Local System account, so you must authorize the computer account for the file servers (for example, SERVERNAME$) or a group that contains those computer accounts.
  11. Add all the required groups (or servers) to the authorization dialog and then click close. For Exchange Servers, they will get SuperUser rights to RMS (to decrypt content):
    image
    image
  12. If you are using a load balancer, then add all the IP addresses of the connector servers to the load balancer under a new virtual IP and publish it for TCP port 80 (and 443 if you want to configure it to use certificates) and equally distribute the data across all the servers. No affinity is required. Add a health check for the success of a HTTP or HTTPS connection to http://<connectoraddress>/_wmcs/certification/servercertification.asmx so that the load balancer fails over correctly in the event of connector server failure.
  13. To use SSL (HTTPS) to connect to the connector server, on each server that runs the RMS connector, install a server authentication certificate that contains the name that you will use for the connector. For example, if your RMS connector name that you defined in DNS is rmsconnector.contoso.com, deploy a server authentication certificate that contains rmsconnector.contoso.com in the certificate subject as the common name. Or, specify rmsconnector.contoso.com in the certificate alternative name as the DNS value. The certificate does not have to include the name of the server. Then in IIS, bind this certificate to the Default Web Site.
  14. Note that any certificate chains or CRL’s for the certificates in use must be reachable.
  15. If you use proxy servers to reach the internet then see http://technet.microsoft.com/en-us/library/dn375964.aspx for steps on configuring the connector servers to reach the Windows Azure Rights Management cloud via a proxy server.
  16. Finally you need to configure the Exchange or SharePoint servers on premises to use Windows Azure Active Directory via the newly installed connector.
    • To do this you can either download and run GenConnectorConfig.ps1 on the server you want to configure or use the same tool to generate Group Policy script or a registry key script that can be used to deploy across multiple servers.
    • Just run the tool and at the prompt enter the URL that you have configured in DNS for the connector followed by the parameter to make the local registry settings or the registry files or the GPO import file. Enter either http:// or https:// in front of the URL depending upon whether or not SSL is in use of the connectors IIS website.
    • For example .\GenConnectorConfig.ps1 –ConnectorUri http://rmsconnector.contoso.com -SetExchange2013 will configure a local Exchange 2013 server
  17. If you have lots of servers to configure then run the script with –CreateRegEditFiles or –CreateGPOScript along with –ConnectorUri. This will make five reg files (for Exchange 2010 or 2013, SharePoint 2010 or 2013 and the File Classification service). For the GPO option it will make one GPO import script.
  18. Note that the connector can only be used by Exchange Server 2010 SP3 RU2 or later or Exchange 2013 CU3 or later. The OS on the server also needs to be include a version of the RMS client that supports RMS Cryptographic Mode 2. This is Windows Server 2008 + KB2627272 or Windows Server 2008 R2 + KB2627273 or Windows Server 2012 or Windows Server 2012 R2.
  19. For Exchange Server you need to manually enable IRM as you would do if you had an on-premises RMS server. This is covered in http://technet.microsoft.com/en-us/library/dd351212.aspx but in brief you run Set-IRMConfiguration -InternalLicensingEnabled $true. The rest, such as transport rules and OWA and search configuration is covered in the mentioned TechNet article.
  20. Finally you can test if RMS is working with Test-IRMConfiguration –Sender billy@contoso.com. You should get a message at the end of the test saying Pass.
  21. If you have downloaded GenConnectorConfig.ps1 before May 1st 2014 then download it again, as the version before this date writes the registry keys incorrectly and you get errors such as “FAIL: Failed to verify RMS version. IRM features require AD RMS on Windows Server 2008 SP2 with the hotfixes specified in Knowledge Base article 973247” and “Microsoft.Exchange.Security.RightsManagement.RightsManagementException: Failed to get Server Info from http://rmsconnector.contoso.com/_wmcs/certification/server.asmx. —> System.Net.WebException: The request failed with HTTP status 401: Unauthorized.”. If you get these then turn of IRM, delete the “C:\ProgramData\Microsoft\DRM\Server” folder to remove old licences, delete the registry keys and run the latest version of GetConnectorConfig.ps1, refresh the RMS keys with Set-IRMConfiguration –RefreshServerCertificates and reset IIS with IISRESET.

Now you can encrypt messages on-premises using your AADRM licence and so not require RMS Server deployed locally.

Managing Azure Active Directory Rights Management

Posted on Leave a commentPosted in 2013, aadrm, dirsync, encryption, IAmMEC, journal, journaling, licence, mcm, mcsm, MVP, Office 365, rms, transport agent

This article is the third in a series of posts looking at Microsoft’s new Rights Management product set. In the previous post we looked at turning on the feature in Office 365 and in this post we will look at how to manage the service in the cloud.

In this series of articles we will look at the following:

The items above will get lit up as the articles are released – so check back or leave a comment to the first post in the series and I will let you know when new content is added.

Once you have signed up for the Azure Active Directory Rights Management (AADRM) Service there are a few things that you need to manage. These are:

  • The service itself
  • Users who are allowed to create RMS protected content
  • Enable and configure Super User rights if required.

Managing AADRM

There is not a lot to do in the Office 365 admin web pages with regard to the management of the service apart from enabling it, which we covered in the previous post and disabling it. Disabling the service involves the same steps as enabling it – you just click the big deactivate button!

AADRM can be further managed with PowerShell though. There are lots of blog posts on connecting to Office 365 using PowerShell, and some of those include the cmdlets to connect to Exchange Online etc. as well. The code below adds to this, and loads the AADRM module and connects to AADRM service in the cloud.

$cred = Get-Credential

write-host "Username: " $cred.username

Connect-MsolService -Credential $cred

Write-Host "...connected to Office 365 Windows Azure Active Directory"

$s = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $cred -Authentication Basic -AllowRedirection

$importresults = Import-PSSession $s -Verbose

Write-Host "...connected to Exchange Online"

Import-Module AADRM

Connect-AadrmService -Verbose -Credential $cred

If you save the above PowerShell code as a text file with a .ps1 extension then you can run the script and easily connect to Office 365 with the credentials you enter. Then connect to Exchange Online with the same set of credentials and finally to AADRM with, of course, the same credentials. This allows you to manages users, email and security from a single session.

To get the AADRM PowerShell module on your computer (so that Import-Module AADRM works) you need to download the Rights Management PowerShell administration module from http://go.microsoft.com/fwlink/?LinkId=257721 and then install it.

To install you need to have already installed the Microsoft Online Services Sign-In Assistant 7.0 and PowerShell 2.0. The PowerShell config file needs some settings adding to it, though I found on my Windows 8 PC that these had already been done. See the instructions at http://technet.microsoft.com/en-us/library/jj585012.aspx for this change to the config file.

  1. Run a PowerShell session and load the module with
    1. Import-Module AADRM
    2. Connect-AadrmService -Verbose
  2. Login when prompted with a user with Global Admin rights in Office 365.
  3. Or, use the script above to do Office 365, Exchange Online and AADRM in a single console.
  4. Run Get-Aadrm to check that the service is enabled

Enabling Super User Rights

Super Users in RMS are accounts that have the ability to decrypt any content protected with that RMS system. You do not need Super User rights to use RMS, nor do you need anyone who has Super User rights to use the product. But there are times when it might be required. One example would be during a discovery or compliance process. At this time it might be required that someone is able to open any RMS protected document to look for hits on the compliance issue in question. Super User gives that right, but would be needed just for the duration of the task that requires these rights. Rights to be Super User would be granted as needed and very importantly removed as needed.

Another example for the use of Super User is when a process needs to see content in its unprotected form. The common use case for this is Exchange Server and its transport decryption process. In Exchange Server you have agents that run against each message looking for something and then acting if that something is found. For example you would not want an virus to bypass the built in AV features of Exchange Server 2013 by protecting it with RMS! Or if you had a disclaimer transport rule or agent, you would not want the disclaimer or DLP feature to not see the content and act upon it because the content was encrypted. The same goes for journaling and the ability to journal a clear text copy of the message as well as the encrypted one if you wish.

To do all this in Exchange Server, the RMS Super User feature needs to be enabled and we will come back in a later post on the specifics of doing that for Exchange, but first we need to enable it in AARMS and set the users who will be Super Users and then, when we are finished with whatever required Super User, we need to turn it off again.

The Rights Management super users group is a special group that has full control over all rights-protected content managed by the Rights Management service. Its members are granted full owner rights in all use licenses that are issued by the subscriber organization for which the super users group is configured. This means that members of this group can decrypt any rights-protected content file and remove rights-protection from it for content previously protected within that organization.

By default, the super users feature is not enabled and no groups or users are assigned membership to it. To turn on the feature run Enable-AadrmSuperUserFeature from the AADRM PowerShell console. The opposite cmdlets exists to turn the feature off again – Disable-AadrmSuperUserFeature!

Once it is enabled you can set Office 365 users as Super Users. To do this run Add-AadrmSuperUser –EmailAddress user@domain.com where the user is either a cloud only Office 365 account or one that you have pushed to Office 365 using DirSync from your on-premises Active Directory. You can add more than one user, each user is added as a separate running of the cmdlets.

To see your list of Super Users, run Get-AadrmSuperUser. To remove users either take them out one by one (Remove-AadrmSuperUser –EmailAddress user@tenant.onmicrosoft.com) or just turn off the Super User feature with Disable-AadrmSuperUserFeature.

Adding AADRM Licences to Users

Once you have AADRM activated you can give your users the rights to create protected content. This is done in the licencing page of the Office 365 web admin portal or via PowerShell. The steps for adding user licences in the shell are discussed at http://c7solutions.com/2011/07/assign-specific-licences-in-office-365-html. That article was written some time ago, so the following are the changes for AADRM:

  • The SkuPartNumber for AADRM is RIGHTSMANAGEMENT_ADHOC
  • The Service Plan for the AADRM SKU is RMS_S_ADHOC

Most Valued Professional Award

Posted on 1 CommentPosted in exchange, MVP

MVP Award EmailDear Brian Reid,

Congratulations! We are pleased to present you with the 2013 Microsoft® MVP Award! This award is given to exceptional technical community leaders who actively share their high quality, real world expertise with others. We appreciate your outstanding contributions in Exchange Server technical communities during the past year.

Also in this email:

  • About your MVP Award Gift
  • How to claim your award benefits
  • Your MVP Identification Number
  • MVP Award Program Code of Conduct

The Microsoft MVP Award provides us the unique opportunity to celebrate and honor your significant contributions and say “Thank you for your technical leadership.”

Mike Hickman
Director
Community Engagement
Microsoft