close

Azure AD

Azure AD

Azure AD

Microsoft Details Plans for Decentralized Digital Identity Platform

Azure-Availability-Zone-Microsoft-696×381 (1)

Azure-Availability-Zone-Microsoft

Three years ago, Microsoft teamed with Mastercard to create a new Azure cloud-based digital identity. Together, the two companies through Azure and Mastercard Track wanted to revolutionize identification beyond hard IDs like driver’s license and passport. Alongside other similar projects, Microsoft has learned a lot over the following three years.

Now Microsoft is ready to take the next step in its digital identity revolution. According to the company, it is working on two projects towards its goal. The first involves entering partnerships with other leaders in the decentralized identity space. Secondly, Microsoft will develop the first decentralized digital identity platform that is widely available.

Alongside the Mastercard collaboration, both these goals build on the company’s Microsoft Azure Active Directory Verifiable Credentials, which was launched at Build 2021:

“Verifiable credentials let organizations confirm information—like their education or professional certifications someone provides—without collecting and storing their personal data, thereby improving security and privacy.”

Standards

Alongside the two new goals towards a decentralized digital identity future, Microsoft also detailed five guiding principles to help bring those plans to fruition. The company believes any decentralized identity system should offer:

  • Inclusive, fair, and easy to use
  • Secure, reliable, and trustworthy
  • Supervisible
  • Privacy protection and in my control
  • Environmentally responsibile

Microsoft says its platform will combat illegal activity and will follow laws in nations where it is adopted. The company plans to use standards outside its control to build the platform on. This will ensure a level of transparency and accessibility to the technology, while also promoting privacy. Finally, the company says it will have more details in the coming months.

Tip of the day: If you have an HP, Dell, or Lenovo touchscreen PC, you’ll probably want to enable or disable it at various times. Unfortunately, however, many Windows 10 touch screen laptops don’t make this easy.

Thankfully, through some tweaks, you can turn off the touch screen no matter your device. In our tutorial, we show you how to disable a touchscreen on Windows 10. We’ll also show you to enable it if you wish, which may help if your HP laptop touch screen is not working, the touch screen is not working on your Lenovo laptop, or you’re having problems with any other brand.

Source Winbuzzer

read more
Azure AD

Microsoft Details CloudKnox Plans for Azure and Other Cloud Platforms

CloudKnox-Office-Microsoft

Back in July, Microsoft acquired cloud security firm CloudKnox to bolster protection on the Microsoft Azure platform. This week, Microsoft is back to explain exactly how CloudKnox will work on Azure and how the service will function moving forward. Specifically, Microsoft says CloudKnox will continue to be available as a separate product for new and existing customers. For those who are using the service outside Azure, “sales, engineering, and service support” will now come from Microsoft. Pricing will also remain the same, says Alex Simons, corporate vice president for identity program management at Microsoft. Instead of lock down the service to Azure exclusivity, CloudKnox will continue as a multi-cloud security tool:

Back in July, Microsoft acquired cloud security firm CloudKnox to bolster protection on the Microsoft Azure platform. This week, Microsoft is back to explain exactly how CloudKnox will work on Azure and how the service will function moving forward.

Specifically, Microsoft says CloudKnox will continue to be available as a separate product for new and existing customers. For those who are using the service outside Azure, “sales, engineering, and service support” will now come from Microsoft. Pricing will also remain the same, says Alex Simons, corporate vice president for identity program management at Microsoft.

Instead of lock down the service to Azure exclusivity, CloudKnox will continue as a multi-cloud security tool:

“In fact, the #1 reason Microsoft purchased CloudKnox was to accelerate our ability to help customers manage their AWS and Google Cloud Platform, and VMware deployments,” Simons points out, as reported by rcpmag.

If you are unfamiliar with CloudKnox Security, it develops Cloud Infrastructure Entitlement Management (CIEM) services. As a leader in the space, the company allows organizations to manage permissions and privilege access. Using analytics, the platform protects against security breaches

Azure Active Directory

While it will be available across the cloud, Microsoft’s interest in CloudKnox was the benefits it can bring when integration with Azure Active Directory. It will allow customers to monitor and automate multi-cloud, cloud, and hybrid permissions. Microsoft has previously discussed the benefits th security tool brings to Azure AD:

  • “Automated and simplified access policy enforcement in one integrated multi-cloud platform for all human and workload identities.
  • The widest breadth of signal-enabling, high-precision machine learning-based anomaly detections.
  • Seamless integration with other Microsoft cloud security services, including Microsoft 365 Defender, Azure Defender and Azure Sentinel.”

Tip of the day: If you need to create an ad-hoc network, you can do it on Windows 10. In our tutorial we show you how to easily create a shareable wireless internet connection in Windows 10 as a free WIFI hotspot.

Source Winbuzzer

read more
Azure AD

Microsoft Azure Cosmos DB is Leaving Customer Data Exposed Online

no thumb

Azure-Cosmos-DB-Landing-Logo-Microsoft

Microsoft has suffered a second major data scare of this week. Following a PowerApps leak that exposed 38 million private records, a Microsoft Azure bug has allowed data to be available online. In fact, this vulnerability means data has been exposed for as much as two years.

Security firm Wiz discovered and disclosed the problem, which is found in Microsoft Azure Cosmos DB. Specifically, the data of over 3,300 customers is open and available online without restriction. Threat actors could access this information and use it in a cyberattack.

Azure Cosmos DB was announced at Build 2017. It is a cloud database service is a brand-new platform created from the ground up. It allows customers to power planet-scale cloud services and huge data applications. Microsoft describes Cosmos DB as a first of its kind service with guaranteed uptime, consistency, throughput, and latency at the 99th percentile.

Ami Luttwak, chief tech officer for Wiz, says the danger of this leak should not be underestimated.

“This is the worst cloud vulnerability you can imagine. This is the central database of Azure, and we were able to get access to any customer database that we wanted.”

The issues comes from the Jupyter Notebook feature that Microsoft added to Azure Cosmos DB in 2019. While this tool allows users to create custom views of their data, misconfigurations allow attackers to exploit Jupyter Notebook to access customer data.

Ongoing Threat

This has been possible since 2019, but the problem is worse now because Microsoft made Jupyter Notebook an automatic feature earlier this year. Wiz was able to leverage the vulnerability to gain access to Azure Cosmos DB and access user read, delete, and write permissions.

Wiz informed Microsoft two weeks ago and the company issued a patch. However, the company is going public because Microsoft is unable to change the access keys of customers. Users must know to manually change the keys to avoid the vulnerability.

Microsoft has already informed around 30% of its Cosmos DB clients but Wiz wants a public disclosure to help more customers. Speaking to Bloomberg, Microsoft says “There is no evidence of this technique being exploited by malicious actors.”

The company paid Wiz $40,000 for discovering the flaw.

Tip of the day: Do you sometimes face issues with Windows 10 search where it doesn’t find files or return results? Check our tutorial to see how to fix Windows 10 search via various methods.

Source Winbuzzer

read more
Azure ADOffice 365

For Heaven’s Sake, Just Turn on MFA Already

GENERIC-Azure-AD-and-authentication-340×200

It’s time for some real talk: not enough of us are using multi-factor authentication. For example, Twitter estimates that only about 2% of their users have MFA enabled for their Twitter accounts—which is terrible, but at least they release their usage data.

I’d expect similarly low uptake for other consumer services—after all, most consumers aren’t security experts—but we really should expect and demand better for enterprise accounts. And yet a rather shocking number of cyberattacks are publicly attributed to account compromises linked to a lack of MFA: in 2020, Microsoft’s Alex Weinert said that 99.9% of successfully attacked Microsoft 365 accounts had MFA disabled.

Security vendor Yubico released a report that makes for some interesting reading about what enterprises say they’re going to do (hint: they’re going to spend more money, especially on tokens from Yubico), but a mediocre plan executed now is better than a great plan executed later—so let’s get started and get MFA turned on in your tenant.

Two ways to get started

Microsoft, much to their credit, has done a ton of work to improve the capability and resiliency of multi-factor authentication in Azure AD. There are four ways you can take advantage of MFA in your Microsoft 365 estate.

First, you could just enable it manually and selectively for individual accounts. Don’t do this. It’s conceptually simple, but it’s also far too easy to leave out accounts, and it will require too much ongoing maintenance in the future as users come and go. Because this is a bad suggestion, I won’t officially count it as a way to get started.

Second: if you’re using Microsoft 365 Business, E3, or E5, MFA will either be on for everyone or off for everyone. So I suppose that’s a second way to get started, but perhaps not what you had in mind.

The first real way to get started is to use the “security defaults” feature that Microsoft introduced in 2019. If your tenant was created after then, good news: this is already enabled for you, and you probably don’t need to do anything. If not, as the linked article explains, it’s simple and easy to set up. Microsoft even says “If you are an organization that wants to increase your security posture but you don’t know how or where to start, security defaults are for you.” It’s easy enough to do this that I won’t cover it further here.

The other real way to get started is to use Azure AD Conditional Access (CA). This can be much more complex than security defaults, and it requires Azure AD Premium P1 or P2 licenses, but it gives you a great deal more flexibility and control.

Read more: Achieving Passwordless Authentication in Azure AD

Conditional access basics

The idea behind CA policies is straightforward: every time a user or device requests access to a resource in Microsoft 365, the endpoint they’re talking to expects to see an authentication token. If there’s no token, or the token is expired or invalid, the endpoint will force the client to authenticate.

In the simplest possible scenario, that means that the user sees a logon dialog and enters her credentials, which Azure AD then checks, issuing a token if they’re valid. CA extends this process by letting you add conditions and exceptions—you can think of these as if-then rules. For example, you could create a rule that says “if a user is signing in to the Azure management portal from a location I don’t trust, require MFA” or “don’t require MFA for users who sign in to Teams from inside our corporate network.”

Conditional Access is incredibly capable and flexible; for example, you can easily create policies that block older versions of Android and iOS (possibly a good idea given the rate at which zero-day vulnerabilities have been coming to light) without affecting access from other clients.

To manage CA policies, you’ll need to log in either to the Azure portal (then go to Azure Active Directory > Security > Conditional access) or the Microsoft Endpoint Manager portal (Endpoint security > Conditional access). Although there are a ton of things you can do with policies, we’re going to focus on a simple policy to require MFA for your users.

Creating an MFA policy

The basics of creating a policy are pretty easy; where you can get into trouble is in choosing the right mix of options from the many choices that Azure AD CA policies support. I always like to suggest starting with a written-language description of what the policy is supposed to do, using a simple template:

This policy will [allow or deny] access for [which users] when using [which applications?] but only when [conditions]

In this case, “This policy will allow access for all ‘real’ users in all applications but only when they authenticate with MFA.” You can see that the template approach makes it easy to see what the desired end result is—that sample is going to obviously require different policy settings than a template that says “This policy will block access for global admins but only when they are connecting from Pyongyang.”

Start with the basics:

  1. Log in to https://portal.azure.com using an account that has Global admin, then navigate to Azure Active Directory > Security > Conditional access.
  2. Click + New policy.
  3. Give your policy a name, ideally one that will make sense to you when you look at it a year from now and wonder “what did I create that for?”

Who gets the policy?

Next you need to decide which users will be affected by this policy. The users and groups control in the left nav bar allows you to both include and exclude users. You can choose to apply this inclusion or exclusion to several categories: no one, all users, or selected users, where the selection is based on their guest status, the directory role they hold, or the group membership you specify. Examples of problems you can solve using these controls include:

  • Including all guest users
  • Including all users except for users in the “Sales” security group
  • Excluding all users except for users who hold the “Azure DevOps administrator” role

Most admins will be tempted to use these controls in combination to make fine-grained policies. While you certainly can do this, it’s always a better idea to start simply. In our case, we want to require MFA for ‘real’ users—which just means “users who are actually humans and not service accounts, etc”.

This is a little harder than it sounds, because Azure AD doesn’t have a way to separate real-human accounts from service accounts; you’ll need to put them in their own groups. In my small tenant, I only have two service accounts, so I just picked them separately on the “exclude” tab. The “include” tab, not shown, has the “all company” group I created. The result is something like this:

For Heaven’s Sake, Just Turn on MFA Already

What apps does it apply to?

You may decide that certain apps are more sensitive or important than others; conversely, you may find that users complain more about being required to occasionally authenticate with MFA in some workloads.

The Cloud apps or actions lets you fill in the “when using” clause of your template. As with user selection, you can include and exclude all apps or choose them individually. If you choose to include or exclude specific apps, you’ll find that the app list includes every app that’s registered in your Azure AD tenant, so you can apply CA policies to third-party apps and your own line-of-business apps, not just Microsoft 365 apps. For our sample policy, we’ll choose to include “All cloud apps.”

Setting conditions: “only when…”

Now we get to the fun part. Right now, there are six categories of conditions you can use, some of which require additional Azure AD licenses: user risk, sign-in risk, device platform (Android, iOS, Windows Phone, Windows, and macOS), locations, client apps, or device filters. If we want to apply the broadest possible requirement for MFA, the simple way to do this is to set a Client apps condition by selecting the Configure control and then enabling Browser and Mobile apps and desktop clients.

You could also enable the condition for legacy Exchange ActiveSync clients and other historical oddities, but those clients typically won’t have a facility for using MFA so you shouldn’t expect them to work properly. Choosing these options will give you something like the following example:

For Heaven’s Sake, Just Turn on MFA Already

The most important part!

Lurking at the bottom of the new-policy page is a small control that looks like this. It’s easy to miss, especially on screens that don’t have a lot of vertical resolution, but you’ll sort of be forced to see it because it’s right next to the Create button.

For Heaven’s Sake, Just Turn on MFA Already

Microsoft defaults the Enable policy setting to Report-only. This is an excellent choice, and you should keep it that way until you’re confident that the policy does only what you want. If you’ve ever accidentally deployed an Active Directory group policy or Exchange retention policy that did something undesirable, you know the sinking feeling that comes when you realize that your incorrect instructions are being cheerfully, and destructively, carried out by the policy engine. Intune will happily give you that same feeling if you let it.

Next steps

Once you’ve tested that the policy applies only to the users and applications you meant for it to, you can flip the enable toggle to On and start enjoying some extra security. That’s really just the first tiptoe step into the world of what Intune can do, though; you can create policies to manage many other aspects of how your users, applications, and devices are allowed to interact with, and through, Azure AD and the other Microsoft 365 workloads.

Source Practical365

read more
Azure AD

How to Permanently Remove Deleted Microsoft 365 Users from Azure AD

GENERIC-Azure-AD-around-Authentication-340×200

The original version of this article was written by Paul Cunningham and published on January 15, 2015. This version is revised to reflect the current environment within Microsoft 365.

When you delete a Microsoft 365 user account from the Microsoft 365 admin center, the account enters a soft-deleted state for 30 days. During this time, administrators can recover the account easily if the deletion was not intended. Azure AD restores the account fully except for license assignments. This includes, for example, memberships of Microsoft 365 Groups (and teams), Exchange attributes such as mailbox permissions and delegates, files including shares in OneDrive, etc.

Thirty Day Deleted Account Retention Limit

The 30-day limit for deleted account retention is set by Azure AD. A tenant cannot choose another value. However, if you want to permanently remove a deleted Microsoft 365 user you can use PowerShell. Reasons why you might want to do this include:

  • Incorrect provisioning of a user account.
  • Preventing a soft-match through Azure AD Connect when the UPN or primary smtp address is the same.
  • A mailbox with active hold is to be set to inactive.

Removing Deleted Azure AD Accounts with PowerShell

To remove accounts, you need both the Azure Active Directory PowerShell and Microsoft Online Services modules installed on your computer.

Caution: do not proceed unless you are completely sure that you want to permanently remove the users.

First, connect to Azure Active Directory by running Connect-AzureAD and entering your admin credentials. Also connect to Microsoft Online Services by running the Connect-MSolService cmdlet:

After connecting, run the Get-MsOlUser cmdlet to return a list of deleted users together with their object identifier:

After finding the required account in the set returned by Get-MsolUser, you can remove their user object permanently by running the Remove-AzureADMSDeletedDirectoryObject.

Removal is immediate and the account is then irrecoverable.

To permanently remove deleted accounts from Azure AD before their deletion retention period expires, you can pipe the set of objects retrieved by Get-MsolUser to the Remove-AzureADMSDeletedDirectoryObject cmdlet:

Source Practical365

read more
Active DirectoryAzure ADAzure App ServiceAzure BackupAzure MediaAzure NetworkAzure SQLOffice 365Sharepoint

Attend TEC 2021 and Learn from the Very Best

TEC-340×200

TEC 2021 (The Experts Conference) takes place as a free virtual event on September 1-2. Practical365.com has a close relationship with TEC as many of our writers are TEC speakers, so I thought that I’d highlight some of the sessions I am looking forward to. Many other sessions covering different topics are on the TEC agenda, so you’re sure to find something interesting to attend.

Please register for TEC to access the sessions. Even if you can’t attend on the day, you’ll be able to use your registration link to access recordings afterwards. Of course, attending live is best because you’ll then have the chance to participate in the live Q&A following the recorded segment of each session. Be nice to the presenters and don’t throw too many curve balls… With that said, here’s my curated list of TEC 2021 sessions. All times are in U.S. eastern time.

Artificial Intelligence and Microsoft 365

Some excellent Microsoft speakers are going to share their unique perspectives on different aspects of Microsoft 365 technology. At 10:30AM on September 2, Jeffrey Snover, the CTO for Modern Workplace Transformation (a fancy name for making stuff work across Microsoft 365) will deliver a keynote covering the use of artificial intelligence within Microsoft 365. Sometimes people get worried about the use of machine learning and AI within Microsoft 365 as they see features like insights and suggested responses turn up in email and meeting requests. I’m more focused on the use of AI in applications like Viva Topics. Jeffrey says that AI will make features more intelligent and easier to use. Turn up and see what you think!

Protecting Office 365 Against Attack

Practical365 traffic spiked in March when the Hafnium attack exploded and many Exchange on-premises administrators discovered just how exposed their servers were to attack. Alex Weinert, Director of Identity Security, is going to improve our knowledge about how attacks develop, the techniques used to penetrate systems, and how Microsoft and other security companies work to mitigate and close off vulnerabilities. Specifically, he’s going to analyze the Nobelium (SolarWinds) attack in December 2020 during his 1:30PM session on September 1.

Using Sensitivity Labels with SharePoint Online

Sensitivity labels are a great way to apply rights management-based encryption to Office documents. They can also be used to protect containers (Teams, Groups, and Sites). I can’t think of a better person to come along and talk about how to protect SharePoint Online and OneDrive for Business with sensitivity labels than Sanjoyan Mustafi, a Principal Product Manager who’s one of my go-to people whenever I have a question about the inner workings of sensitivity labels for SharePoint content. Sanjoyan speaks at 1:30PM on September 2. Apparently, he might even drop some hints about some new features due to appear soon.

Collaborating Teams Channels

A conference would be a pretty bland affair if only Microsoft people spoke, so TEC has many other experts come along to talk about different aspects of technology. MVP Curtis Johnstone talks at 12:45PM on September 1 about the different types of channels used in Teams, including the new shared channels first revealed in March and now getting close to public preview. Curtis plans to cover how shared channels work, differences with private channels, and how organizations can govern channel use.

Power Automate and Teams

Microsoft spends a lot of time banging the publicity drum for Teams and Power Automate. MVP Christina Wheeler brings some practical advice (always appreciated at Practical365.com) at 1:30PM on September 1 to show how to connect the two technologies to get real work done by exploring how to launch a flow from a Teams bot.

Go to OneDrive

At 12:45PM on September 2, MVP Andy Huneycutt dives into the topic of moving people off network drives to OneDrive for Business. Many good business and technology reasons exist for this transition. Better data governance, more stable infrastructure, more visibility over content, better sharing, and so on. And of course, the simple fact that Office 365 and Microsoft 365 apps are built to use OneDrive for Business (Stream and Whiteboard are both moving their storage to OneDrive for Business). Why anyone would stay on old-fashioned network drives is beyond me…

Manage Exchange Online at Massive Scale

SAP is a very large software company that also uses Exchange at massive scale. MVP Ingo Gegenwarth gets lots of practice running PowerShell scripts to process tens of thousands of objects, and he’s going to share his experience and give some tips and techniques for how to approach the problem of dealing with so many objects at 2:30PM on September 1. I suspect Ingo might even say that it’s a good idea to use the Microsoft Graph API with PowerShell to get data about service incidents or interrogate Azure AD.

Removing the last Exchange On-Premises Server

After the Hafnium exploit in March, some organizations started to look more closely at the question of removing the last Exchange on-premises server. This has been a hotly debated topic for years, with some people saying that it’s easy to do (by performing brain surgery with ADSIEdit) and Microsoft continually saying that they are seeking a more graceful solution. Steve Goodman takes on the challenge of reporting the current situation at 12:45PM on September 2.

Group Policies Are Dead: Long Live Intune

I hate Group Policy Objects (GPOs). For years, they’ve been a necessary evil to enable workstation and server management. Intune is a better solution, especially in the world of Microsoft 365 where the PC is not the sole focus. Paul Robichaux covers this topic at 11:45AM on September 2 with a real focus on making management easier for your Microsoft 365 tenant.

Leveraging the Graph to Manage Microsoft 365

Finally, if you have time, you could attend my session at 11:45AM on September 1 where I’ll discuss how to use the Microsoft Graph APIs to manage Microsoft 365 tenants and applications. This is not a session for programmers. It’s focused on tenant administrators who automate processes with PowerShell today and want (or need) to use some Graph APIs with PowerShell. Maybe it’s just to get work done faster (like when you need to process thousands of mailboxes) or it’s because a Graph API is the only way to change a tenant setting.

Many Practical365.com articles cover different aspects of using the Graph APIs from reporting the storage used by Teams channels to updating tenant privacy controls. It should be a fun session (for me anyway!).

Enjoy TEC 2021. I plan to and hope that you’ll come along and have a terrific time sharing knowledge with some excellent speakers.

Source Practical365

read more
Active DirectoryAzure AD

Microsoft acquires CloudKnox Security to offer unified privileged access and cloud entitlement management

Microsoft-Logo-Microsoft-1-696×304

At Microsoft, we are committed to supporting organizations in their digital transformation and helping them to deliver secure and seamless experiences. Since IT modernization often spans multiple clouds, cloud security and identity are top of mind for most of our customers. Modern identity security needs to protect all users and resources consistently across multi-cloud and hybrid cloud environments. Today, Microsoft is taking a significant step toward this goal with the acquisition of CloudKnox Security, a leader in Cloud Infrastructure Entitlement Management (CIEM). CloudKnox offers complete visibility into privileged access. It helps organizations right-size permissions and consistently enforce least-privilege principles to reduce risk, and it employs continuous analytics to help prevent security breaches and ensure compliance. This strengthens our comprehensive approach to cloud security.

People working in office
Microsoft acquires CloudKnox to offer unified privileged access and cloud entitlement management.

As organizations adapt to hybrid work and more and more cloud services are deployed, new service entities that collaborate and exchange data without human interaction, such as virtual machines and containers, are proliferating. The growth of these service accounts and identities and their increasing volumes of permissions, privileges and entitlements exposes organizations to new attack vectors. Left in blind spots or uncontrolled, these permissions leave business critical systems open to infiltration and disruption. High-profile breaches demonstrate how quickly bad actors can move laterally by exploiting misappropriated privileged credentials.

While organizations are reaping the benefits of cloud adoption, they still struggle to assess, prevent, enforce and govern privileged access across hybrid and multi-cloud environments. Even if they piece multiple siloed systems together, they still get an incomplete view of privileged access. Traditional Privileged Access Management and Identity Governance and Administration solutions are well suited for on-premises environments, however they fall short of providing the necessary end-to-end visibility for multi-cloud entitlements and permissions. Neither do they provide consistent identity lifecycle management or governance in multi-cloud and cloud-native environments.

In January, when I shared the five identity priorities for 2021, I stressed the importance of a Zero Trust security approach that verifies explicitly, grants least privileged access and always assumes breach — with identity as your first line of defense. As the corporate network perimeter disappears, it’s crucial to establish a strong cloud identity foundation, so you can enforce least privileged access to protect business-critical systems while improving business agility. We’re committed to making it easier to enforce least privileged access for all user and workload identities.

The acquisition of CloudKnox further enables Microsoft Azure Active Directory customers with granular visibility, continuous monitoring and automated remediation for hybrid and multi-cloud permissions. We are committed to providing our customers with unified privileged access management, identity governance and entitlement management including:

  • Automated and simplified access policy enforcement in one integrated multi-cloud platform for all human and workload identities.
  • The widest breadth of signal-enabling, high-precision machine learning-based anomaly detections.
  • Seamless integration with other Microsoft cloud security services, including Microsoft 365 Defender, Azure Defender and Azure Sentinel.

Our acquisition of CloudKnox, like our recent acquisition announcements on RiskIQ and ReFirm Labs, shows our focus and execution in acquiring, integrating and expanding the strongest defenses for our customers — from chip to cloud — backed by more than 3,500 defenders at Microsoft and the more than 8 trillion security signals we process every day. Microsoft is uniquely positioned to help empower and defend the future of hybrid work and multi-cloud environments, providing essential visibility, control and monitoring Zero Trust demands.

We’re excited to bring the CloudKnox team and technology to Microsoft and our joint customers and look forward to their contributions. We’ll share more information as we integrate CloudKnox with Microsoft’s identity, security and compliance solutions.

Source Microsoft

read more
Active DirectoryAzure AD

Windows 365 Announced and Azure Virtual Desktop Gains New Features

GENERIC-Microsoft-‘emojis-340×200

Microsoft announced Windows 365 – launching on August 2nd, which is (arguably) Microsoft’s big entry into Desktop as a Service (DaaS). Windows 365 allows you to provide users with persistent virtual desktops without managing the supporting infrastructure.

The core idea behind it from Microsoft is that for a set monthly fee, you can assign a Windows 365 license to a user after picking the appropriate Cloud PC size. These range from 1 vCPU with 2GB RAM and 64GB HDD space, up to 8 vCPUs, 32GB RAM and 512GB of storage space. The license is then provisioned from Microsoft Endpoint Manager, which avoids the need to build out either a traditional VDI environment on-premises, or build-out and manage Azure Virtual Desktop.

Windows 365 Announced and Azure Virtual Desktop Gains New Features
Figure 1: Managing Windows 365 Cloud PCs within Microsoft Endpoint Manager.

The timing of this Windows 365 release is important, as it was announced at Microsoft’s global partner conference, Inspire. If you currently work for a Microsoft Partner, the main message is that if you are currently configuring Microsoft 365 services like Intune today, and also helping roll-out Windows 10 desktops, then it should be straightforward for you to help customers with Windows 365.

In episode 20 of the Practical 365 podcast, we briefly discussed announcements for Azure Virtual Desktop as part of the rename from Windows Virtual Desktop, including the news that a Public Preview of Azure AD Join and Intune management would arrive soon. This week, at the same time as Windows 365, Microsoft announced that these features are now in Public Preview.

What’s the Difference Between Windows 365 and Azure Virtual Desktop?

If you haven’t examined either offering in detail, it’s easy to look at both and think of them as basically the same thing. And the confusing part is there’s a lot of overlap, so you aren’t wrong for making that assumption. Fundamentally speaking, with Windows 365 you are avoiding the core infrastructure & platform piece, leaving that to Microsoft to worry about that. Therefore, it is most definitely a Software-as-a-Service type solution.

With Azure Virtual Desktop, you’re required to manage a supporting Azure subscription, configure and implement the platform services required to allow a thin-client or Remote Desktop client to connect in. Then performed over HTTPS into the environment, must be authenticated and allocated to the correct machine via a session broker, maybe even provision a VM or start one up, and so on. Plus, you need to make the architectural decisions around that, such as how you will configure redundancy, backup and resilience on top of Azure.

The difference between AVD and simply building out a VDI platform on Azure VMs (Infrastructure-as-a-Service) is that AVD is a Platform-as-a-Service offering, built primarily of modules you can configure, alongside infrastructure you deploy to it.

Almost all of the platform configuration melts away with Windows 365, where the key decision for an Enterprise SKU is how you will (today) connect an Azure vNet to your on-premises environment. While you can upload your own custom images for Windows, you can also choose ‘vanilla’ images – i.e. those pre-configured to work, with add-ins for Teams VDI pre-installed and ready to go.

Microsoft provides a table that explains when and why you’ll choose each:

Windows 365 Announced and Azure Virtual Desktop Gains New Features
Figure 2: Microsoft’s view on which to choose – AVD or Windows 365.

Windows 365 Will Launch with Limitations

There are two versions of Windows 365 that will be available upon launch – a small business version and an enterprise version.

The small business version is intended for those lacking an IT team and is self-service for someone that runs their own business and chooses to buy a Cloud PC to use with their Microsoft 365 Business subscription. It doesn’t include any management capabilities but does allow sign-ins via Azure AD accounts.

The enterprise version (if you’re reading this, this is probably the version you need) will at launch require Hybrid Azure AD Join of each machine. That should make you pause and reflect a little, because that means there are pre-requisites that must be fulfilled prior to using Windows 365, including:

  • A local Active Directory on-premises, or as IaaS in Azure (Azure AD Directory Services isn’t supported)
  • Synchronization of your local AD to Azure AD
  • Network connectivity to an Azure vNet, so that Windows 365 Cloud PCs can join Active Directory as traditional workstations, Hybrid Azure AD Join configured and supporting connectors installed on-premises.
  • Plan and configure how network access and internet access will function – however, you can of course connect to the public Internet from Azure as well as route traffic from Azure to on-premises.

(For more info, feel free to read through Microsoft’s step-by-step example guide for setup (which admittedly glosses over a few aspects, but still comprehensive) to get a better idea of what’s involved.)

While not exactly unexpected, this could simply reflect the timing of when Azure Virtual Desktop features are released to General Availability (see below), as Microsoft has already said that this isn’t a permanent limitation, but rather one tied to the underlying platform, Azure Virtual Desktop today.

Therefore, in several months’ time, pure Azure AD joined and Intune/MEM managed Windows 365 Cloud PCs, should be M be easy to get started with.

Important Considerations

However, a crucial technical point to expose is that at least today, all features and functionality available in Windows 365 is tied to features and functionality available in Azure Virtual Desktop. If you’ve already deployed Azure Virtual Desktop and wondered whether functionality such as Teams VDI is improved, then the answer is no – there’s no special sauce for Windows 365 such as a different model for local device redirection, or an XBox Cloud Gaming-style set of improvements to the Remote Desktop user experience beyond what is currently offered in Azure Virtual Desktop. The client you’ll use on mobile or on desktop is the same as you use or deploy for AVD – the Remote Desktop app from the respective app stores.

A key thing to remember is that Windows 365 is focused on making everything simpler than AVD, rather than better. While the HAADJ requirement today might be disappointing, it isn’t forever – if you aren’t looking for simply the lowest cost but looking for simplicity – then some of the details like Windows 365 being completely persistent, single-user desktops without the need for FSLogix is a big benefit.

Azure AD Join and Intune/MEM management arrive in Azure Virtual Desktop

The success of AVD over the last 12 months means that there are lots of organizations who will look at Windows 365, consider the amount of work they have done to get AVD up and running, and remain confident with their choice. AVD is likely to be cheaper to run on an ongoing basis over setup Windows 365 but will require specialist skills to successfully implement and manage.

Savings are gained because charges are based upon the compute, network and storage consumed for AVD whereas with Windows 365, you pay per-machine, per-user, per-month (plus Azure network egress charges). With both solutions, you still need licensing for Windows and the applications installed, but you can save money with AVD by using multi-user images and auto-scaling based on usage.

One blocker for urgent AVD requirements has been the requirement for Active Directory – strikingly similar to Windows 365 when it launches on August 2nd. A key ask, especially for organizations deploying laptops that are Azure AD joined and Intune managed, is for the AVD to support Azure AD Join and Intune management so there isn’t a requirement to extend networking from on-premises to Azure to get line-of-sight access to AD, or enable Azure AD DS – not something you want to do even if you have an on-premises AD.

This functionality is now in preview for both Azure AD Join and Intune management, greatly simplifying the ability to deploy VDI in Azure using AVD for the same user types who would also be able to use a pure Azure AD Joined & Intune managed device. Once in GA, this means that a rapid enablement of AVD will be one of the key deciding factors when choosing between that and Windows 365.

Source Practical 365

read more
Azure AD

Upgrading PowerShell Scripts with Azure AD Cmdlets to Use Graph API Calls

GENERIC-PowerShell-and-Microsoft-Graph-340×200 (1)

Updating the Distribution List Count Script for the Graph

In June, I described how I upgraded a PowerShell script written for Exchange on-premises to report the count of members in distributions to work with Exchange Online. Or more precisely, with Azure AD rather than Active Directory. While everything works just fine, the problem is that Microsoft is moving away from the Azure AD Graph API that the Azure AD cmdlets use. After June 30, 2022, Microsoft will no longer provide security updates for the Azure AD Graph, nor will they support its use. This doesn’t mean that you can’t continue to use the Azure AD PowerShell module; it just means that Microsoft won’t deliver support for any problems you encounter. The cmdlets in the module work well, so I don’t anticipate many problems, but the writing is on the wall.

Microsoft’s path forward is the Graph PowerShell SDK, a wrapper around many different Graph API calls. The problem is that the SDK is still under development and doesn’t work as well as it will (eventually). And the nagging doubt is that perhaps it might just be best to use the underlying Graph API calls instead.

Using Graph API Calls

With that in mind, let’s explore what it takes to convert a script using Azure AD cmdlets to Graph API calls. Our starting point is the script to report distribution list counts. The end is the Graph version (both available in GitHub).

PowerShell scripts can invoke Graph API calls using the Invoke-RestMethod or Invoke-WebRequest cmdlets. Either work, but the Invoke-RestMethod cmdlet is more aligned with the REST-based Graph APIs than the more general-purpose Invoke-WebRequest cmdlet is. Before you can use these cmdlets to call Graph APIs in a script, some housekeeping is necessary.

First, you need to register an app in Azure AD to use as an entry point to Graph API calls. To allow access to data via the Graph, the app receives consent from an administrator to use a set of permissions. In this case, the app needs the following Graph application permissions: Directory.Read.All, Group.Read.All, and User.Read.All permissions.

Second, you need to authenticate. In this case, the script is intended to run interactively (other arrangements are necessary to run scripts non-interactively). Authentication is performed by asking Azure AD for an access token. To prove that the app is authorized, it passes an app secret, which you generate for the app from the Azure AD admin center. A combination of the tenant identifier, the app identifier (also generated by Azure AD), and the app secret is sufficient to allow the app to authenticate.

If you examine the Graph version of the script, you’ll see that it has more lines of code than the original PowerShell version. Housekeeping needs some code to get done, but once you’ve figured out the code that works for you (taking your own coding style, error handling, and so on into account), you’ll probably have code that can be lifted from one script to another to fulfil the task of getting ready to communicate with the Graph. For instance, because many Graph API calls use pagination to return a limited set of data per call, I have a function to continue fetching data until no more is available.

Counting Distribution Lists

The big challenge when counting the number of members in a distribution list is how to deal with nested groups. The PowerShell version uses a function to expand the membership of any nested groups to come up with a full set of members, just like the way the Exchange Online transport service expands a distribution list to create copies of messages during its fan-out process.

The Graph API for Groups includes the transitiveMembers call to return the members of a group (including distribution lists). This means that we can replace the PowerShell function with a single graph call. In this code, we ask the Graph to return the membership for a distribution list identified by its Azure AD object identifier (stored in the list’s ExternalDirectoryObjectId property).

Get-GraphData is the function to handle pagination referred to above.

After a successful call, the $Members array contains the full set of members. To analyze the membership and create a count of the different types of objects (mailboxes, groups, contacts, etc.), it’s a matter of looping through the array. The values for member type returned by the Graph take a little interpretation, but that’s not hard. Here’s the relevant code:

And that’s about it. A single Graph call replaces the function, and some slightly different processing counts the member types.

Simple Once You Know How

As it turns out, the task of converting the script was straightforward. Admittingly, I make the assertion from the view of someone who has worked with the Graph API for a while, can set up a registered app without breaking sweat, and have some code to paste into a new script to do the housekeeping. Still, I hold to my point. Like anything else to do with Office 365, it takes some time to become accustomed to how best to get things done. In five years, we’ll look back at all the Graph-enabled PowerShell we’ll write between now and then and wonder why anyone was concerned. At least, I hope so.

Source Practical 365

read more
Active DirectoryAzure AD

Upgrading PowerShell Scripts with Azure AD Cmdlets to Use Graph API Calls

GENERIC-PowerShell-and-Microsoft-Graph-340×200

Updating the Distribution List Count Script for the Graph

In June, I described how I upgraded a PowerShell script written for Exchange on-premises to report the count of members in distributions to work with Exchange Online. Or more precisely, with Azure AD rather than Active Directory. While everything works just fine, the problem is that Microsoft is moving away from the Azure AD Graph API that the Azure AD cmdlets use. After June 30, 2022, Microsoft will no longer provide security updates for the Azure AD Graph, nor will they support its use. This doesn’t mean that you can’t continue to use the Azure AD PowerShell module; it just means that Microsoft won’t deliver support for any problems you encounter. The cmdlets in the module work well, so I don’t anticipate many problems, but the writing is on the wall.

Microsoft’s path forward is the Graph PowerShell SDK, a wrapper around many different Graph API calls. The problem is that the SDK is still under development and doesn’t work as well as it will (eventually). And the nagging doubt is that perhaps it might just be best to use the underlying Graph API calls instead.

Using Graph API Calls

With that in mind, let’s explore what it takes to convert a script using Azure AD cmdlets to Graph API calls. Our starting point is the script to report distribution list counts. The end is the Graph version (both available in GitHub).

PowerShell scripts can invoke Graph API calls using the Invoke-RestMethod or Invoke-WebRequest cmdlets. Either work, but the Invoke-RestMethod cmdlet is more aligned with the REST-based Graph APIs than the more general-purpose Invoke-WebRequest cmdlet is. Before you can use these cmdlets to call Graph APIs in a script, some housekeeping is necessary.

First, you need to register an app in Azure AD to use as an entry point to Graph API calls. To allow access to data via the Graph, the app receives consent from an administrator to use a set of permissions. In this case, the app needs the following Graph application permissions: Directory.Read.All, Group.Read.All, and User.Read.All permissions.

Second, you need to authenticate. In this case, the script is intended to run interactively (other arrangements are necessary to run scripts non-interactively). Authentication is performed by asking Azure AD for an access token. To prove that the app is authorized, it passes an app secret, which you generate for the app from the Azure AD admin center. A combination of the tenant identifier, the app identifier (also generated by Azure AD), and the app secret is sufficient to allow the app to authenticate.

If you examine the Graph version of the script, you’ll see that it has more lines of code than the original PowerShell version. Housekeeping needs some code to get done, but once you’ve figured out the code that works for you (taking your own coding style, error handling, and so on into account), you’ll probably have code that can be lifted from one script to another to fulfil the task of getting ready to communicate with the Graph. For instance, because many Graph API calls use pagination to return a limited set of data per call, I have a function to continue fetching data until no more is available.

Counting Distribution Lists

The big challenge when counting the number of members in a distribution list is how to deal with nested groups. The PowerShell version uses a function to expand the membership of any nested groups to come up with a full set of members, just like the way the Exchange Online transport service expands a distribution list to create copies of messages during its fan-out process.

The Graph API for Groups includes the transitiveMembers call to return the members of a group (including distribution lists). This means that we can replace the PowerShell function with a single graph call. In this code, we ask the Graph to return the membership for a distribution list identified by its Azure AD object identifier (stored in the list’s ExternalDirectoryObjectId property).

Get-GraphData is the function to handle pagination referred to above.

After a successful call, the $Members array contains the full set of members. To analyze the membership and create a count of the different types of objects (mailboxes, groups, contacts, etc.), it’s a matter of looping through the array. The values for member type returned by the Graph take a little interpretation, but that’s not hard. Here’s the relevant code:

And that’s about it. A single Graph call replaces the function, and some slightly different processing counts the member types.

Simple Once You Know How

As it turns out, the task of converting the script was straightforward. Admittingly, I make the assertion from the view of someone who has worked with the Graph API for a while, can set up a registered app without breaking sweat, and have some code to paste into a new script to do the housekeeping. Still, I hold to my point. Like anything else to do with Office 365, it takes some time to become accustomed to how best to get things done. In five years, we’ll look back at all the Graph-enabled PowerShell we’ll write between now and then and wonder why anyone was concerned. At least, I hope so.

Source Practical365

read more
1 2 3 7
Page 1 of 7