When testing BitLocker encryption on the new Windows 10 1909 release using my VMWare environment. I ran into the following error;
This device cannot use a Trusted Platform Module. Your administrator must set the “Allow BitLocker without a compatible TPM” option in the “Require additional authentication at start-up” policy for OS volumes.
Go to your Local Group Policy
Locate the following setting under Computer Configuration –> Administrative Templates –> Windows Components –> BitLocker Drive Encryption –> Operating System Drives
Require additional authentication at startup
We will now need to edit this policy to enable the required settings, please use the below screenshot as your guide.
Once the policy has been enabled with the required settings, re-run BitLocker Drive Encryption and this time it’ll be more successful.
Recently, I was trying to use Install-Module cmdlet to install a required module for some testing on a client machine however I ran into the following error
Install-Module: The term ‘Install-Module’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. At line:1 char:1Install-Module MSOnline. CategoryInfo : ObjectNotFound: (Install-Module:String) [], CommandNotFoundException FullyQualifiedErrorId : CommandNotFoundException
The error looks like below:
Install-Module : The term ‘Install-Module’ is not recognized as the name of a cmdlet, function, script file, or operable program
The error usually comes, if your PowerShell is not upto date. The major version of PowerShell should be equal or greater than 5. You can run the below cmdlets to check the PowerShell version.
1
$PSVersionTable.PSVersion
My PowerShell major version was 4.
To solve the error the following steps was taken to resolve the issue.
This post will explain how to merge an on-premise AD user objects with an already existing Azure AD user using hard-match with the sourceAnchor/immutableID property. I have recently experience this issue with a customer who was merging their contoso.com addresses to their fabikam.com Azure AD account.
As you can imagine this isnt a simple process but with the power of PowerShell and good old fashion “I can” attitude, this merger was a complete success.
Before we continue I would like to state that there are two methods that Azure AD Connect will use to match existing users; – Soft-Match – Hard-Match
When you install Azure AD Connect and you start synchronizing, the
Azure AD sync service (in Azure AD) does a check on every new object and
try to find an existing object to match. There are three attributes
used for this process: userPrincipalName, proxyAddresses, and sourceAnchor/immutableID.
Soft-Match
Soft-Match will use the properties userPrincipalName and proxyAddresses to match existing users.
Hard-Match
Hard-Match will use the property sourceAnchor/immutableID. You can only select which property is used as sourceAnchor during the installation of Azure AD Connect as described in their documentation.
If the selected sourceAnchor is not of type string, then Azure AD Connect Base64Encode the attribute value to ensure no special characters appear.
Important Note
By default, Azure AD Connect (version 1.1.486.0 and older) uses objectGUID as the sourceAnchor attribute. ObjectGUID is system-generated.
So we only have to set the immutableID property of the existing user in our Azure AD to the Base64 encoded string of the ObjectId of the user in our on-premise AD. If you already synchronized your Active Directory then you probably have two users with the same name in your Azure AD. Just follow the following steps to finally merge these users:
You have to execute the following PowerShell commands on the machine with your on-premise AD and the Azure PowerShell commands via the Azure Cloud Shell.
In my scenario, I had a customer that the Email Address on the Active Directory Account didn’t match the PrimarySMTPAddress in Azure AD, however, the PrimarySMTPAddress in Exchange was correct. So I need to match both objects using the PrimarySMTPAddress from Exchange And Azure to set the ImmutableID. I create a PowerShell to gather PrimarySMTPAddress from Exchange along with the required information from Active Directory
If you have synced users and have duplicate accounts you will need to remove these before looking at continuing. A simple way of doing this changing the OU you have synced which has caused the duplicate or you can use the Azure Portal
Deleted Users
But if you love PowerShell the following command is also possible as well.
1
Remove-AzureADUser -ObjectId <objectid>
3. Get Azure AD User ObjectID
One of the key requirements for this post is that we require the ObjectID of the Azure Active Directory account we are looking to match against. The following PowerShell command prints a list of all users with their ObjectId and exports to your desktop.
Once you have a single pane of glass with your ObjectID and ImmutableID matched within a csv, you will now be able to set all the ImmutableID for all your Azure AD Objects.
5. Set immutableId for Azure AD User in Bulk
Run the following script against Azure AD using PowerShell.
Set-AzureADUser -ObjectID $user.ObjectId -ImmutableID $user.ImmutableID
Write-Host $user.PrimarySMTPAddress,"with ObjectID"$user.ObjectId," has been set with ImmutableID",$user.ImmutableID
}
Stop-Transcript
6. Start AD Sync
You can now resync the OUs which had all the user accounts and hard matching will be completed using the newly set ImmutableID.
The following post contains the new features and updated features from October 2019. This post enables you to quickly glance at the Microsoft Teams Roadmap based on the latest information provided by Microsoft.
One thing I have included in this month’s round-up is Microsoft Bookings as it now integrates with Skype and Teams.
The following post contains the new features and updated features from October 2019. This post enables you to quickly glance at the Office 365 Roadmap that directly targets Microsoft Intune based on the latest information provided from Microsoft.
Leveraging your Azure subscription for Microsoft Intune massively reduces the requirements for on-premises infrastructure. In this post I will show you how to use Azure Blob Storage to provide the Lock Screen and Desktop background all with the power of the Microsoft Cloud.
First up you will need to create a storage account within your Azure subscription.
Create Storage Account
Specify the following; – Resource Group – Storage Account Name – Location (Europe) UK South
Specify settings
Once the storage account has successful created, you will need to go to the resource
Go to resource
Go to “Containers” Create new “Container” Specify the name of the Container Specify the Public Access level as “Blob” Then click ok
Specify settings
Click on your new “Container”
Created Container
Click Upload You will need to upload your required .jpg file
Click on the uploaded file and you will be provided a URL which can be used
Provide the URL into your required destination for example Lock Screen as shown below
As you can see from below my Lockscreen and Desktop backgrounds are what I have specifed.
Image for LockscreenLockscreenImage for DesktopDesktop
Enterprise organizations today are becoming more and more security conscious of where the corporate resides. If you have come across Windows Information Protection yet, check out the below video from Microsoft.
Right let us jump right into it
Windows Information Protection is configured via the Microsoft Intune portal. Browse to Client Apps –> App protection policies –> Required settings
Windows Information Protection mode
Windows Information Protection mode
Block: Block enterprise data from leaving protected apps
Allow overrides: User is prompted when attempting to relocate data from a protected to a non-protected app. If they choose to override this prompt, the action will be logged.
Silent: User is free to relocate data off of protected apps. No actions are logged.
Off: User is free to relocate data off of protected apps. No actions are logged.
You will need to specify your corporate identity, if you have multiple identities you will need to “Protected Domains” under “Advanced settings” –> “Add network boundary”
Protected domains
Once you have selected the Windows Protection mode, we need some applications to protect.
Protected Apps
This step is definitely one of the easiest to do, as Microsoft has already generated a list of all the default applications and all you need to do is go to “Protected Apps” and “Add apps”.
For the purpose of this blog, I have missed out the Cloud Resources as shown below.
I have recently been running into the following issue where using white-glove experience for Windows Autopilot. The error already occurs around the 14-minute mark when “Registering the device for mobile management”.
Device prepartionWindows Autopilot Configuration
This issue is cause by multiple MDM enrollment applications defined within the Mobility (MDM and MAM) window within your Azure Active Directory
Once I had remove Microsoft Intune Enrolment, Windows Autopilot provisioing was able to successful complete.
I have been recently investigating Cloud App Security how it can benefit organizations already paying for this functionality without even knowing. Do you already pay for the following Microsoft licenses?
Starting with Cloud App SecurityCloud App Security – DashboardGetting started with Cloud App Security
Log process flow: From raw data to risk assessment
The process of generating understanding the risk within your organisation from a Cloud Securtity starts here with the following. You can upload data to Cloud App Security and the process takes between a few minutes to several hours depending on the amount of data processed.
Upload – Web traffic logs from your network are uploaded to the portal.
Parse – Cloud App Security parses and extracts traffic data from the traffic logs with a dedicated parser for each data source.
Analyze – Traffic data is analyzed against the
Cloud App Catalog to identify more than 16,000 cloud apps and to assess
their risk score. Active users and IP addresses are also identified as
part of the analysis.
Generate report – A risk assessment report of the data extracted from log files is generated.
Note
Continuous report data is analyzed twice a day.
Supported firewalls and proxies
Cloud App Security support data uploads from the following Firewalls and Proxies.
Barracuda – Web App Firewall (W3C)
Blue Coat Proxy SG – Access log (W3C)
Check Point
Cisco ASA with FirePOWER
Cisco ASA Firewall (For Cisco ASA firewalls, it’s necessary to set the information level to 6)
Cisco Cloud Web Security
Cisco FWSM
Cisco IronPort WSA
Cisco Meraki – URLs log
Clavister NGFW (Syslog)
Digital Arts i-FILTER
Forcepoint
Fortinet Fortigate
iboss Secure Cloud Gateway
Juniper SRX
Juniper SSG
McAfee Secure Web Gateway
Microsoft Forefront Threat Management Gateway (W3C)
Palo Alto series Firewall
Sonicwall (formerly Dell)
Sophos SG
Sophos XG
Sophos Cyberoam
Squid (Common)
Squid (Native)
Stormshield
Websense – Web Security Solutions – Investigative detail report (CSV)
Websense – Web Security Solutions – Internet activity log (CEF)
Cloud App Security also enables organizations to automatically discovery the Cloud Apps in use via actives on your firewall logs. This is done via Log Collectors that allows organizations upload logs to Cloud App Security. Every single long is automatically transfers to the portal, there is 2 different behaviours if you are using FTP or Syslog
FTP Uploads
FTP logs are uploaded to Microsoft Cloud App Security after the file finished the FTP transfer to the Log Collector
SysLog Uploads
The Log Collector writes the received logs to the disk. Then the collector uploads the file to Cloud App Security when the file size is larger than 40 KB
App connectors use APIs from cloud app providers to integrate the
Cloud App Security cloud with other cloud apps. App connectors extend
control and protection. They also give you access to information
directly from cloud apps, for Cloud App Security analysis.
To connect an app and extend protection, the app administrator
authorizes Cloud App Security to access the app. Then, Cloud App
Security queries the app for activity logs, and it scans data, accounts,
and cloud content. Cloud App Security can enforce policies, detects
threats, and provides governance actions for resolving issues.
So how does the look from the portal?
List of Connected Apps available today
Lets connect Office 365 for the purpose of this post.
Connect Office 365Select the components you would like to monitor and connect the appSuccess
Conditional Access App Control protection
Microsoft Cloud App Security Conditional Access App Control uses reverse proxy architecture to give you the tools you need to have real-time visibility and control over access to and activities performed within your cloud environment. With Conditional Access App Control, you can protect your organization:
Avoid data leaks by blocking downloads before they happen
Set rules that force data stored in and downloaded from the cloud to be protected with encryption
Gain visibility into unprotected endpoints so you can monitor what’s being done on unmanaged devices
Control access from non-corporate networks or risky IP addresses
Conditional Access App Control protection
With Conditional Access App Control protection you can define you want to Monitor what is being accessed or block.
Conditional Access Policies
When configured you will notice the below appear for all access control applications
Policies
Once you have configured the basics above the next steps is to enable policies you would like run within your environment. Out of the box you will receive a number policies deemed appropriate from Microsoft but there may be additions ones you would like for example;
In my environment I have created a policy that check for OneDrive Documents shared outside my business to specific domains
This policy also has the power to remove the external user to prevent access and this is where Cloud App Security really comes into its own. As it allows organisations and IT Administrators to the power to real take control of corporate data.
After a bit of recent investigate App Protection policies I have noticed a large chunk of information missing from Microsoft resources and other blog posts. I have recently experienced an issue where network boundaries were not configured correctly and I had to ensure that all applications that were being protected do not experience any issues access corporate resources.
It is recommended to use the following when adding a network boundary.
