Office365

Fastest way to capture and upload the hardware hashes into Intune AutoPilot (Microsoft Device Management #MEM)

Carlos A Lopez (Twitter: @CLopezDC) Office365 , , ,

We expect the vendors to provide the Windows Autopilot hardware hashes or onboard the devices directly into our tenant. However, that is not usually the case. While the process has improved over the years, there are situation where vendors may not be able to generate the hardware hashes on a timely manner, or not at all. That is why Windows Autopilot device registration can be done within your organization by manually collecting the hardware hashes and uploading this information in a comma-separated-value (CSV) file.

STOP THERE… that process has been updated and improved, making our life much easier. Thank to a newly available option as part of the Windows10 devices, you can manually generate the hashes and automatically upload the hashes to your tenant without the need exporting it into a .CSV file.

During the OOBE (Out of the Box Experience) you also can initiate the hardware hash upload by launching a command prompt (Shift+F10 at the sign in prompt), and using the following commands.

Prerequisite: Your device needs to be connected either a wired or wireless network with internet access.

Powershell.exe 
Install-Script -name Get-WindowsAutopilotInfo -Force
Set-ExecutionPolicy Unrestricted
Get-WindowsAutoPilotInfo -Online

At this point you will be prompted to sign in, an account with the Intune Administrator role is sufficient, and the device hash will then be uploaded automatically. If MFA is enabled, you will be required to use it. (Always make sure to have MFA enabled in all your accounts)

Upon confirmation of the uploaded device hash details, run a sync in the Microsoft Endpoint Manager Admin Center and wait for your new device to appear.

Once the device is shown in your device list, and an autopilot profile is assigned, restarting the device will result in OOBE running through Windows Autopilot provisioning process.

Tools to drive your Zero Trust implementation

Carlos A Lopez (Twitter: @CLopezDC) Cloud Security ,

Today, someone said on a call that implementing a zero-trust model, was as difficult as learning a new language and did not know where to start.

PowerPoint Presentation I am trying to describe the areas and provide my peers with ideas on where to start with the basics of zero-trust. As you begin to assess your Zero Trust readiness and begin to plan on the changes to improve protection across identities, devices, applications, data, infrastructure, and networks. CIOs and IT personnel should consider these key areas to help drive the Zero Trust implementation more effectively.

  1. Strong authentication: Ensure strong multi-factor authentication and session risk detection as the backbone of your access strategy to minimize the risk of identity compromise.
  2. Policy-based adaptive access: Define acceptable access policies for your resources and enforce them with a consistent security policy engine that provides both governance and insight into variances.
  3. Micro-segmentation: Move beyond simple centralized network-based perimeter to comprehensive and distributed segmentation using software-defined micro-perimeters.
  4. Automation: Invest in automated alerting and remediation to reduce your mean time to respond (MTTR) to attacks.
  5. Intelligence and AI: Utilize cloud intelligence and all available signals to detect and respond to access anomalies in real time.
  6. Data classification and protection: Discover, classify, protect, and monitor sensitive data to minimize exposure from malicious or accidental exfiltration.

Enabled the functionality of Conditional Access (Best Practice 3/10)

Carlos A Lopez (Twitter: @CLopezDC) AAD Connect, Azure, Cloud Security , , , , ,

The idea of the cloud is to allow users to access the resources by using a variety of devices and apps from anywhere at any time. Since the perimeter of the network is no longer the edge but the identity, IT administrators face the challenges, therefore controlling the devices and making sure that these devices meet the standards for security and compliance, is a very effective way to protect the cloud implementation.

The trade between security and productivity here plays an important role. IT admins need to think about how a resource is accessed before they can make a decision about access control. With Azure AD Conditional Access, IT administrators can address this requirement. With Conditional Access, IT admins can make automated access control decisions based on conditions for accessing your cloud apps.

Best practice: Manage and control access to corporate resources. Configure Azure AD Conditional Access based on a group, location, and application sensitivity for SaaS apps and Azure AD–connected apps.

Best practice: Block legacy authentication protocols. Attackers exploit weaknesses in older protocols every day, particularly for password spray attacks. Configure Conditional Access to block legacy protocols. See the video Azure AD: Do’s and Don’ts for more information.

Image result for conditional access

 

 

*Image from Official Microsoft Website – Credit: https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/overview

Types of conditions:

  • Sign-in risk: Azure AD Identity Protection detects sign-in risks. How do you restrict access if a detected sign-in risk indicates a bad actor? What if you would like to get stronger evidence that a sign-in was performed by the legitimate user? What if your doubts are strong enough to even block specific users from accessing an app?
  • Network location: Azure AD is accessible from anywhere. What if an access attempt is performed from a network location that is not under the control of your IT department? A username and password combination might be good enough as proof of identity for access attempts from your corporate network. What if you demand a stronger proof of identity for access attempts that are initiated from other unexpected countries or regions of the world? What if you even want to block access attempts from certain locations?
  • Device management: In Azure AD, users can access cloud apps from a broad range of devices including mobile and also personal devices. What if you demand that access attempts should only be performed with devices that are managed by your IT department? What if you even want to block certain device types from accessing cloud apps in your environment?
  • Client application: Today, you can access many cloud apps using different app types such as web-based apps, mobile apps, or desktop apps. What if an access attempt is performed using a client app type that causes known issues? What if you require a device that is managed by your IT department for certain app types?