Tag: Azure AD

Office Cloud Policy Service – Preview Feature

Earlier this year Microsoft announced a new cloud based service that allows administrators to create and manage policies for Office ProPlus users in your tenant, this service is called “Office Cloud Policy Service” or “OCPS” for short. These policies are created and managed via an internet based portal and are then enforced upon members of a Azure Active Directory Security Group.

The settings that you can apply in your OCPS policies include many of the same settings that you can find in the traditional user based settings in Group Policy. So the best thing about OCPS is that it doesn’t require any on-premises or MDM infrastructure to work, its all cloud based!
Even though its completely cloud based, you shouldn’t see OCPS as a replacement for Group Policy, but more of an extension. That’s because OCPS policies apply to devices even if they aren’t domain joined or MDM enrolled ( where Group Policy can’t be applied), they apply to all devices where the user is logged in to Office ProPlus.  Note that OCPS only applies user based settings and not machine based settings like Group Policy does.

What are the requirements for getting started?

The requirements for getting this to work are not very many or complex

  • The minimum version of Office ProPlus must be 1808
  • Users must login to Office ProPlus with an Azure AD account. This account can either be synced or cloud-only.
  • Security groups in Azure AD that contains the appropriate users that you want to apply a policy to. The groups can be synced or cloud only as well.
  • In order to manage OCPS you must either be a Global Administrator, Security Administrator or a Desktop Analytics Administrator


How to create your first policy

Creating a policy in the internet based portal is very simple and straight forward.

1: Start by signing into the OCPS portal with the URL https://config.office.com/officesettings And choose “Go to Office policy management”

2: Click on “Create”

3: You will now be met with the following fields that need to be specified

4: After you’ve specified a name for your policy you can go ahead and click the “Select group” button to be able to specify the group this policy will apply to. Note that you can search for specific groups in the search box, or just choose a group from the list. Note that you can only select one group per policy.

5: After you’ve selected your group you can go ahead and click the “Configure Policies” button to actually start applying setting for the policy

6: There is a search function to easily find the settings you are interested in. For example, I’ve searched for “Outlook” and I’m interested in preventing the attachment preview functionality, so I can click on the setting to start configuring it

When we click on a setting we get a description that will tell us what the setting controls and what will happen if we change the configuration of the setting.

7: After I’ve configured all the setting I want to be a part of my policy, I can go ahead and click “Create” on top of the policy wizard

Managing a policy

After you’ve created a policy it will show up in a list so you can easily edit, delete, copy or reorder its priority.

If you edit a policy you can see what settings have been configured by filtering the “Status” Column to “Configured”

This will show you only the settings that are currently configured in this policy. So you can easily modify the configuration ,and also verify what settings actually apply to your users.
In my example I only have the Attachments preview setting we configured earlier

Note that the status is set to “Configured”

So what is OCPS good for and when should it be used?

Like I previously mentioned OCPS is a way for administrators to control the behavior and configuration of Office ProPlus on all devices a users logs into. It doesn´t have to be a domain joined or MDM enrolled device. These policies are applied once a users logs in and activates Office ProPlus.

I believe that OCPS is a very good function for primarily cloud-only organizations that don’t have or don’t need an on-premises  server structure with Active Directory and Group Policy management, but still want the opportunity to secure and control their users Office ProPlus installations.
It´s also a good tool for organizations that already have Group policy in place, but want to be able to apply similar configuration on non domain or MDM joined devices.
For example, if a CEO has several corporate and private devices he or she logs into Office with, we might want to enforce some settings for the Office applications on those devices that would normally be out of our control. This might be because the CEO might be targeted by different types of harmful attacks, maybe by macro enabled Word documents etc.
This could be prevented on the CEO´s personal devices as well by setting up a OCPS policy that disabled Macros in Word.


If you have any questions or would like to know more about Office Cloud Policy Service (OCPS)
feel free to contact me at oliwer.sjoberg@xenit.se or by leaving a comment.

New baseline policies available in Conditional Access

Last week Microsoft starting to rollout three new baseline policies in Conditional Access.

  • Baseline policy: Block legacy authentication (Preview)
  • Baseline policy: Require MFA for Service Management (Preview)
  • Baseline policy: End user protection (Preview)

Baseline Policy in Conditional Access are part of Baseline Protection in Azure Active Directory (Azure AD) and the goal of these policies is to ensure that you have at least the baseline level of security enabled in Azure AD.

Conditional Access are normally part for a Premium SKU (P1 or P2) for Azure AD but Baseline Protection are available for all editions of Azure AD, including Free.

Here is a walk-through of all the available baseline policies that Microsoft offers and how they protect your organization.

Require MFA for admins

This policy requires Multi-Factor Authentication (MFA) for accounts that are part for directory roles that elevate an account with more privileged than a normal account. This policy also blocks legacy authentication, like POP, IMAP and older Office desktop client.

The directory roles that are covered by this policy are:

  • Global administrator
  • SharePoint administrator
  • Exchange administrator
  • Conditional access administrator
  • Security administrator
  • Helpdesk administrator / Password administrator
  • Billing administrator
  • User administrator

Block legacy authentication

This policy blocks all sign-ins using legacy authentication protocols that doesn’t support Multi-Factor Authentication, such as

  • Office 2013 (without registry keys for Modern Authentication)
  • Office 2010
  • Thunderbird client
  • Legacy Skype for Business
  • Native Android mail client

However, this policy does not block Exchange ActiveSync.

Require MFA for Service Management

This policy requires users logging into services that rely on the Azure Resource Manager API to perform multi-factor authentication (MFA). Services requiring MFA include:

  • Azure Portal
  • Azure Command Line Interface (CLI)
  • Azure PowerShell Module

End user protection

This policy protects users by requiring multi-factor authentication (MFA) during risky sign-in attempts to all applications. Users with leaked credentials are blocked from signing in until a password reset.

Once the policy is enabled, users are required to register for MFA within 14 days of their first login attempt. The default method of MFA registration is the Microsoft Authenticator App.


Here are a few recommendations before you enable these polices:

  • If you have privileged accounts that are used in scripts or Azure Automations, you should replace them with Managed Identities for Azure resources or service principals with certificates. You could also exclude specific user accounts from the baseline policy but should be a temporary workaround.
  • Make sure you exclude the emergency-access / break glass account(s) from these polices

Read more about baseline protection and baseline policies on docs.microsoft.com

Querying Microsoft Graph with Powershell, the easy way

Microsoft Graph is a very powerful tool to query organization data, and it’s also really easy to do using Graph explorer but it’s not built for automation.
While the concept I’m presenting in this blogpost isn’t something entirely new, I believe my take on it is more elegant and efficient than what I’ve seen other people use.

So, what am I bringing to the table?

  • Zero dependancies to Azure modules, .net Core & Linux compatibility!
  • Recursive/paging processing of Graph data (without the need for FollowRelLink, currently only available in powershell 6.0)
  • Authenticates using an Azure AD Application/service principal
  • REST compatible (Get/Put/Post/Patch/Delete)
  • Supports json-batch jobs
  • Supports automatic token refresh. Used for extremely long paging jobs
  • Accepts Application ID & Secret as a pscredential object, which allows the use of Credential stores in Azure automation or use of Get-Credential instead of writing credentials in plaintext

Sounds great, but what do I need to do in order to query the Graph API?

First things first, create a Azure AD application, register a service principal and delegate Microsoft Graph/Graph API permissions.
Plenty of people has done this, so I won’t provide an in-depth guide. Instead we’re going to walk through how to use the functions line-by-line.

When we have an Azure AD Application we need to build a credential object using the service principal appid and secret.

Then we aquire a token, here we require a tenantID in order to let Azure know the context of the authorization token request.

Once a token is aquired, we are ready to call the Graph API. So let’s list all users in the organization.

In the response, we see a value property which contains the first 100 users in the organization.
At this point some of you might ask, why only 100? Well that’s the default limit on graph queries, but this can be expanded by using a $top filter on the uri which allows you to query up to 999 users at the same time.

The cool thing with my function is that it detects if your query doesn’t return all the data (has a follow link) and gives a warning in the console.

So, we just add $top=999 and use the recursive parameter to get them all!

What if I want to get $top=1 (wat?) users, but recursive? Surely my token will expire after 15 minutes of querying?

Well, yes. That’s why we can pass a tokenrefresh and credentials right into the function and never worry about tokens expiring!

What if I want to delete a user?

That works as well. Simply change the method (Default = GET) to DELETE and go!

Deleting users is fun and all, but how do we create a user?

Define the user details in the body and use the POST method.

What about json-batching, and why is that important?

Json-batching is basically up to 20 unique queries in a single call. Many organizations have thousands of users, if not hundreds of thousands of users, and that adds up since much of the queries need to be run against individual users. And that takes time. Executing jobs with json-batching that used to take 1 hour now takes about 3 minutes to run. 8 hours long jobs now takes about 24 minutes. If you’re not already sold on json-batching then I have no idea why you’re still reading this post.

This can be used statically by creating a body with embedded queries, or as in the example below, dynamically. We have all users flat in a $users variable. Then we determine how many times we need to run the loop and build a $body json object with 20 requests in a single query, then we run the query using the $batch operation and POST method and put them into a $responses array and tada! We’ve made the querying of Graph 20x more efficient.

Sounds cool, what more can I do?

Almost anything related to the Office 365 suite. Check out the technical resources and documentation for more information. Microsoft is constantly updating and expanding the api functionality. Scroll down for the functions, should work on Powershell 4 and up!

Technical resources:

Creating an Azure AD application

Graph API

About batch requests

Known issues with Graph API

Thanks to:


OpenID Connect token validation in Citrix ADC

I’ve previously written about how to use OpenID Connect in NetScaler and a way to use callouts to validate tokens. You can also use the function JWT_VERIFY_CERTKEY() but that requires that you (for now) keep the issuing certificate updated locally.

Another way is to setup an OpenID Connect client (OAuth Action) on Citrix ADC and enable 401 authentication in the load balancing vserver. Below is an example where the NetScaler will validate that the token sent is valid and issued by the correct provider. (I’ve used Azure AD in my example)

The only thing you have to do is send traffic with tokens (HTTP.REQ.HEADER(“Authorization”).SET_TEXT_MODE(IGNORECASE).CONTAINS(“Bearer “)) to this LB and a session will be created in NetScaler. In my case, I’m also verifying that the user exists using a second factor to LDAP.

Try it out and all feedback is welcome!

Azure AD Connect and .NET Framework 4.7.2


Last week a discussion erupted on Microsoft forums regarding Azure AD Connect due to it’s Monitoring Agent using all free resources of CPU on the servers. These issues were caused by a .NET Framework update and a lot of administrators spent time uninstalling and blocking these patches to resolve the CPU usage issues on their servers. On Saturday Microsoft released an update (KB4340558) which contains a collection of several patches where one of the earlier mentioned .NET Framework updates were included. For more information, see this link.

Microsoft has recently published an article regarding this issue. In addition, Microsoft also published a new version of the health agent where they state that the issue is resolved, it can be downloaded from here. The new health agent version is set to be included in the next version of Azure AD Connect, which will be published for Automatic Upgrade (Auto Upgrade). The following patches have been identified with issues causing Azure AD Connect’s monitoring agent using huge amounts of CPU:

Auto Upgrade

In version of Azure AD Connect, Microsoft introduced Auto Upgrade. Although, not all updates are published for Automatic Upgrade. Whether a version is eligible for automatic download and installation will be announced on Microsofts version-history website for Azure AD Connect.

You can verify whether your Azure AD Connect installation have Auto Upgrade enabled by either using Powershell or viewing your configuration in It’s GUI.

Graphical User Interface of Azure AD Connect
PowerShell-command for determining whether Auto Upgrade is enabled or not.

This command will return either Enabled, Disabled or Suspended, where as the Suspended state only can be set by the system itself. Newer installations of Azure AD Connect enables Auto Upgrade by default, in case your installation applies to Microsoft’s recommendations. For more information, see this link.

Enabling Auto Upgrade

In case you have an installation of Azure AD Connect older than (February 2016), Auto Upgrade will be disabled, if you’ve not enabled it manually. Enabling this function can be done with below PowerShell-command if so wanted.

If you have any questions, feel free to email me at robert.skyllberg@xenit.se

Device cleanup rules for Microsoft Intune

As an IT Administrator you want to keep your IT environment clean and tidy and the same goes for Microsoft Intune.

By default all devices that has been inactive or stale and hasn’t checked in for over 270 days will automatically been removed from the console.

In the latest update for Microsoft Intune dated July 2, Microsoft included a new feature, Device cleanup rules:.

New rules are available that let you automatically remove devices that haven’t checked in for a number of days that you set.


You will find it in the Intune pane, select Devices, and select Device Cleanup Rules:

By default, this is not enabled, so you need to change it to Yes and specific the numbers of days between 90 and 270 that suites your company’s policy and requirements.

If nothing is changed or you remain it set to No, it will use the default 270 days:

Block external access for Service Accounts using Conditional Access in Azure AD

Conditional Access in Azure Active Directory is normally used for users and administrators to secure and control company data in Office 365 and Azure, but what about Service Accounts? Aren’t they a potential security risk?

Using Service Accounts for scripts and other tasks related to Office 365, Azure and Azure AD is a normal practice along companies, sometimes the accounts has full administrative permissions (Global Admin for Office 365, Owner of a subscription/resource group in Azure) and sometimes the accounts has delegated privileges but they all have more permissions than a regular user.

In this post we will cover how you can use Conditional Access to block sign-ins from service accounts outside the company main datacenter to make sure they are only used on servers located on networks that the company has control over.

  1. Open portal.azure.com and go to Azure Active Directory and Conditional Access under Security
  2. Go to Named locations and Add the external IP address of the data center(s) that should be allowed for the service accounts to sign-in from.
  3. Create a new policy and name it “Block external access for service accounts
  4. Select the Service Accounts or an Azure AD Group, in our case we use a groups that will contain all the service accounts
  5. In Cloud apps, select All cloud apps
  6. For Conditions, select Locations and Configure. Select Any location in the Include tab
  7. Also in Conditions and Locations, select the Exclude tab and select the location of the data center added in step 2.
  8. For Access, go to Grant and select Block access
  9. Select On for Enable policy, and verify all settings before creating it.
  10. The policy should now look like the following:
    Conditional Access policy - Block external access for service accounts

    Conditional Access policy – Block external access for service accounts


You can find out more about Conditional Access on docs.microsoft.com:


How to join a Windows 10 computer to your Azure Active Directory


Some of the benefits of having your Windows 10 devices in your Azure AD is that your users can join the computer to your Azure AD without any extra administrator privileges, assuming you have configured this in your Azure AD. They can also login to the computer without the need of being connected to a specific company network the first time, as long as they have internet connection. You can also manage your Windows 10 devices wherever it may be in the world.

Devices i Azure AD – varför det är viktigt

Devices i Azure AD – varför är det viktigt? I princip alla organisationer vi arbetar med har ett traditionellt on-premise Active Directory. Många av dessa börjar nu använda Office 365 och Azure, ofta börjar det med Exchange Online för mail och växer sedan till att börja använda Skype, OneDrive, Teams eller någon av de andra tjänsterna Office 365 erbjuder. I botten av allt detta är ett Azure AD, detta är något alla får eftersom så fort du skapar en Office 365 tenant får du också ett Azure AD som är användarkatalogen. Vare sig du sedan editerar användarna i Office 365 admin portalen (https://portal.office.com) eller Azure AD admin portalen (https://portal.azure.com) så är det grund och botten ditt Azure AD du ändrar i.