If you have a large on premise environment, you might want to automate the assignment of Office 365 licenses by using (dynamic) security groups in Azure AD. With this simple manual you should be able to setup automatic license assignment based on a security group.
By default everyone may create a new team in Microsoft Teams. As an organisation admin you might want to control this, or release it a some point. With this manual you should be able to lock down team creation to users that are member of a Azure AD Security group.
STEP 1: First we will need to install the Preview version of the Azure Active Directory PowerShell module for Graph. Open a PowerShell window with Adminstrator privileges and run the following 2 commands:
The result of the script should give you the updated settings. On the last line you should see EnableGroupCreation. If you want to reverse this setting. Just simply change the following line to True and run the entire script:
$AllowGroupCreation = “True”
If you want another security group, rerun the script with the new group name.
Next, we just need to change the 2 value’s below, and run it. After running, you don’t get a confirmation. It might take up to 30 minutes before changes are visible in all Office 365 and/or Azure portals.
With the move to the cloud there might be a time where you would like to remove the Active Directory link (AD Connect) and go for a cloud only strategy. With a few simple steps you can disconnect the AD connect sync from Azure AD.
When you look in your Office 365 environment you will notice that the sync status has different symbols. One for cloud only, and one for Active Directory. To disable the link, open a PowerShell window and run the following steps.
STEP 1: First make sure that you disable the AD Connect sync service by disabling the service, or set it to staging mode.
STEP 2: Connect to your Microsoft Office 365 environment using the following command, and login to the desired environment:
STEP 3: Now run the following command to disable the sync, confirm your actions, you cannot undo this change!
With the Azure AD Premium P2 license you are entitled for Azure AD Identity Protection. You will get the option in Conditional Access to assign risk level based options to your policies. Azure AD Identity Protection can detect six different types of suspicious sign-in activities with 3 different levels of risks.
With the riks levels combined with conditional access policies we can protect sensitive application and data access. With this article I am going to show you how to create risk-based conditional access policies
So let’s create a Policy and get Conditional Access applied with risk levels
Multi Factor Authentication (MFA) is an added security feature from Azure which I believe that should be enabled by default for everybody in Office 365 and Azure. There for this manual how to enforce (Azure) MFA for all users using Azure Multi Factor Authentication
MFA can prevent unauthorized access in case of the following events:
Sign-ins from anonymous IP addresses
Impossible travel to atypical locations
Sign-ins from unfamiliar locations
Sign-ins from infected devices
Sign-ins from IP addresses with suspicious activities
Using Conditional access we can ensure that your users and company data is safe. Important to know is that Office 365 MFA is free of charge, and if you have Azure AD applications an Azure AD Premium license is required.
If you want to mark your locations as trusted location, you can do that if you have a static public IP. So the first steps are there to define your office locations.
Last few weeks I’ve been struggling with an very difficult Office 365 / Exchange Online case, that got escalated to multiple Microsoft departments to be fixed. I already found one part of the solution, but Microsoft found the second part. Today I would like to take you through all the steps to fix possible causes and resolutions. So the initial problem started with the following error in the Office 365 admin portal with the affected users:
Another symptom is the mailbox provisioning gets stuck, and hangs on “We are preparing a mailbox for this user”
You will only see this error with AD connect sync enabled environments. The problem occurs when the on-premise value mismatches with the Online Archive Guid. With just a few easy steps we can fix this issue.
We will need to fill multiple Active Directory user attributes to resolve this issue.
With Azure Conditional access you get more control over your data, get better security and visibility! To use this feature you will need to buy and assign Azure AD Premium or EM+S E3/E5 licenses to your users.
This manual can be used to enforce the use of the Outlook app on IOS and Android devices by blocking all apps that do not support Modern Authentication like iOS mail and Google mail client.
Step 1: In the Azure Portal go to Conditional Access. On the first page that you get create a New policy
With the transition to Azure AD, you might want to connect your AAD joined devices to the traditional file server as explained in this article: Go Azure AD Joined with on-prem DC and fileserver The next step is to map some network drives with Intune!
Step 1: The first step is to create a PowerShell script that will do the actual drive mappings. This script will be placed on a Azure Blob storage (or your internal domain) where you will be able to manage and maintain the script. This script will be run using a second script that we will deploy with Intune. For your convenience I’ve already prepared the script:
When moving your applications to the cloud, it makes sense to start using Azure Services to get the best service, highest availability (SLA) and worry free maintenance provided by Azure. The next step is to use Azure AD identities with Azure SQL Database.
Within a few steps you will have Azure AD user authentication setup.
We all know that phishing is going on all the time. But how to defend your organization against these criminals that want to get your login information! The answer is simple, Office 365 Advanced Threat Protection, or short: ATP.
Microsoft released Lighthouse last weekend, and since this is a great feature, I wanted to implement it as soon as possible, but the Microsoft docs might be a bit confusing, so I wanted to simplify the manual, so here it is! We will be using PowerShell, as this makes life so much easier, and faster.
Your admin tenant needs to have a valid Azure subscription
You need to have a native user account with the new Owner role in the tenant that you want to manage (Customer tenant)
Azure PowerShell module: AZ (Install-Module -Name az)
If you have a ADFS server for your user authentication in Office 365 / Azure AD, and you want to use Pass Through Authentication and/or password Hash Synchronization we will need to change a few things and run a few Powershell commands.
So before we can change the domain to managed, verify if your domain has password sync enabled using the AD connect wizard:
If you have an AD Connect server, you sometimes require a faster sync than the default 30 minutes. This can be done very easily by entering one Powershell command. Open a Powershell window, and load the AD Connect Sync Powershell module:
Once imported, you have 2 options. For a full sync, type the following command:
Wouldn’t be cool to migrate all your laptops and desktops to Azure AD, but still have your on-premise file server for the people that can’t say goodbye to their network drives?
Now it is possible! Azure is supporting out of the box, Azure AD domain joined devices to connect with their on-premise domain joined counterparts with credentials (Kerberos) to the good old file and print server!
To be able to set this up, you will still need a traditional domain controller with a file/print server. On top of that you will need to synchronize the identities to Azure AD. Make sure that you enable password sync, and start joining the devices to Azure AD.
One other important thing, your device needs to be Windows 10 1607 or higher! Older versions of Windows 10 do not support the Kerberos authentication.
If you now want to map a network drive with the existing NTFS permissions, just map the drive, and start using like you used to do before!
Last week we talked about why passwords are bad. Today we will continue with part 2, how to get the passwords gone, and we will zoom in on Windows Hello for Business!
So what is Windows Hello? Windows Hello is a modern way of authenticating users on their laptop, where this will be a two factor authentication. The first factor is the integrated TPM chip in the device, and the 2nd factor is the bio-metric of the user.
By enabling the TPM chip and the bio-metric data from the end user we will eliminate the need of a password on the users device. Off course the user can use his password to unlock the device in case bio-metric verification fails because of different reasons.
If you have a on-premise domain with Windows Hello for business enabled, it is also possible to enable the convenience PIN, however, I wouldn’t recommend it, as Microsoft has disabled this in Azure AD as well. In short:
Windows Hello for Business is: An asymmetric key-pair protected and stored in the TPM, unlock with PIN or Bio-metric Authentication
In the Azure portal you can reset the password of a user, but this is always a temporary password. But PowerShell to the resque again, lets set the password in Azure AD with PowerShell with a predefined password! On your Windows device open a PowerShell prompt and connect to Azure AD. (Click here if you don’t know how to)
First we need to get the object ID from the user where we want the password to be reset. Run the following command (replace emailadres):