close

Azure AD

Azure AD

Azure ADAzure VM

Microsoft Sustainability Calculator Aims to Help Cloud Customers Manage their Carbon Footprint

no thumb

Microsoft has announced a new tool that will help cloud customers better understand their carbon emissions. Called the Microsoft Sustainability Calculator, the product has landed in private preview ahead of a future launch.
According to Redmond, the aim of the Microsoft Sustainability Calculator is to give customers more oversight across their carbon output. More specifically, to become more transparent about what their environmental impact is.
“It’s challenging to make and meet meaningful carbon reduction goals without the ability to measure carbon emissions,” Microsoft says.

Microsoft has announced a new tool that will help cloud customers better understand their carbon emissions. Called the Microsoft Sustainability Calculator, the product has landed in private preview ahead of a future launch.

According to Redmond, the aim of the Microsoft Sustainability Calculator is to give customers more oversight across their carbon output. More specifically, to become more transparent about what their environmental impact is.

“It’s challenging to make and meet meaningful carbon reduction goals without the ability to measure carbon emissions,” Microsoft says.

By leveraging AI technology, the calculator provides accurate accounting for carbon usage. It highlights the impact caused by Microsoft cloud service across an organization’s footprint. Armed with the information, company’s can make concise decisions about their environmental impact.

For example, the Microsoft Sustainability Calculator measures the impact of moving regular applications to the cloud and how this can reduce the carbon output of a company.

Carbon Negative

It looks like the tool goes hand-in-hand with Microsoft’s own push to be carbon negative by 2030. Redmond made that pledge earlier this year. The decision followed a 2017 commitment to cut 75% of its carbon emissions by the same date and builds on 2019 revisions of 70% renewable energy by 2023.

“While the world will need to reach net zero, those of us who can afford to move faster and go further should do so,” Microsoft President Brad Smith said of the new commitment. “That’s why today we are announcing an ambitious goal and a new plan to reduce and ultimately remove Microsoft’s carbon footprint.”

Source Winbuzzer

read more
Azure AD

Microsoft and Hitachi Announce Partnership Based on Azure Cloud Integration

Microsoft-Cologne-Office-Pixabay-768×578

Microsoft has announced an expansion of its partnership with Japanese multinational Hitachi. Specifically, the companies are entering a new era of deeper collaboration as part of a multi-year strategic alliance.

Leading the goals of the partnership is to drive transformation in logistics and manufacturing across North America, Southeast Asia, and Japan.

On its end, Hitachi, will integrate its solutions into Microsoft’s cloud services. For example, the IoT industrial controllers HX Series and Lumada platform will now integrate with Microsoft Azure, Dynamics 365, and Microsoft 365.

“We are delighted to expand our partnership with Microsoft and combine our OT, IT and products excellence to provide manufacturing and logistics companies with digital solutions. We use Lumada to provide total seamless solutions to solve challenges by connecting cyberspaces with physical spaces. Through this collaboration with Microsoft, we will be able to accelerate our customers’ digital transformation and continue to deliver social, environmental and economic value,” said Jun Abe, Vice President and Executive Officer, CEO of Industry & Distribution Business Unit, Hitachi Ltd.

Partnership

Both companies will also work to combine Lumada and Azure into a new industry data platform. In a blog post to announce the alliance, Microsoft says Hitachi will bring the following benefits to its Microsoft Azure platform:

  • “Increase manufacturing productivity: Using Hitachi Digital Supply Chain as well as Azure IoT to analyze 4M data collected from manufacturing sites for the visualization and analysis of production processes to optimize factory operations and increase productivity.
  • Optimize logistics with data analytics: Increasing the logistics efficiency and reducing operational costs by analyzing traffic congestion, storage locations and delivery locations, and enabling smart routing to save miles and deliver faster through advanced digital technologies such as Azure Maps and Hitachi Digital Solution for Logistics/Delivery Optimization Service.
  • Predictive maintenance and remote assist: Enabling predictive maintenance, real-time remote assistance and remote training scenarios for first-line workers, leveraging HoloLens 2 and Dynamics 365 Remote Assist as well as other smart devices.”

Those solutions will make their debut next month in Thailand and will arrive in Japan and North America later in the year.

“Building resilient and flexible digital supply chains is critical to grow a business and meet customer needs in today’s fast-changing environments. By expanding our collaboration with Hitachi, we’ll unlock new opportunities for manufacturing and logistics companies as they strive to lead in their industries and pioneer with a data-driven mindset and digital capabilities,” said Çağlayan Arkan, Vice President Manufacturing at Microsoft.

Source Winbuzzer

read more
Azure AD

How to quickly install and configure Azure AD Connect

18-23-2020-583-p365-Generic-IT-admin-computing-something-image-LOW

One of the fundamental components of setting up Office 365 is installing Azure AD Connect. This tool is used to connect your on-premises Active Directory to Azure AD.

It works by synchronizing a copy of objects in the directory, such as users, groups, contacts and devices from Active Directory to Azure AD every 30 minutes. When you use Azure AD Connect, your local Active Directory remains the master copy and only selected attributes, such as those needed to support Exchange Hybrid, are written back.

Azure AD Connect supports many topologies, including a single Active Directory, multiple Active Directories and even multiple Office 365 tenants.

Before we begin, it’s worth outlining that there is a variety of configuration options available and these should be considered if you have more than basic requirements. For example, if you cannot synchronize hashes of passwords to the cloud, then you may wish to consider options like pass-through authentication. If you still run older clients or do not plan to use Hybrid Azure AD join to provide single sign-on to PCs, then you might wish to configure Seamless Sign-On.

In this guide, we’re not going to cover every option for installation of Azure AD Connect, as there’s a variety of ways to configure it.

The key purpose of this guide is if you are installing and configuring Azure AD Connect to support using a tool like Microsoft Teams, and plan to update your configuration to support wider needs in the future. We’ll show you how to install it in a similar way to the Express option which uses the most common deployment settings.

Prerequisites for installing Azure AD Connect

Before you begin, ensure you meet the pre-requisites for installation. As a minimum, you need Windows Server 2012 or later, on a domain-joined server (or domain controller) with .NET Framework 4.5.1 and PowerShell, with at least 4GB RAM and a 70GB HDD. The server will need access to the internet, in particular access to the Azure AD Connect service. IP ranges are listed here.

It is always recommended to analyze your Active Directory for issues that will prevent accounts synchronizing to Azure AD. The best way to do this, is to use the IDFix tool. The process to run this is documented here. In particular, it is common to ensure that the User Principal Name matches user’s email addresses for easy sign-in and to meet the requirement of matching one of your Office 365 tenant’s custom domains.

And, if you haven’t already, follow our guide on adding a custom domain to match (at a minimum) your primary SMTP domains (the ones you’ll use for sign-in) and if you will be migrating mailboxes to Exchange Online, all domains you use to receive email.

Learn more: What is Azure AD Connect Cloud Provisioning and should you plan to use it?

In this guide we’ll show you how to user Alternate Login ID for rapid identity provisioning to Office 365 applications like Microsoft Teams. If you are planning to use Exchange Hybrid, however, then you should plan to move to matching against the User Principal Name at a later date. This can be achieved fairly simply, by staging the switch of User Principal Names to match user’s Primary SMTP address, then when complete updating Azure AD Connect to use the User Principal Name instead.

Steps for installation

Once pre-requisites are in place we’ll begin. First, download a copy of Azure AD Connect. You’ll find this at the Microsoft Download site.

Next, run the installation tool on the server you’ll install Azure AD Connect on to, then when given the opportunity, we’ll choose the Customize option, unless you want to install with the Express Settings, which include synchronizing all accounts:

Azure AD Connect Express Settings

Next, we’ll choose sign-in options. As mentioned above, we’ve got a variety of options available, and you need to select the right one for your organization.

However, most organizations should choose Password Hash Synchronization, then choose Next:

Azure AD Connect User Sign-In

Next, enter your Office 365 Global Administrator credentials. These will be used to create a synchronization account inside the Office 365 tenant, and not stored by the server:

Connect to Azure AD

We’ll then need to add our local Active Directory. In this guide, we’re assuming you are using a single AD to synchronise to Office 365. Choose Add Directory:

Azure Add Directory

At this point, use enterprise administrator credentials to add an Active Directory connection. The wizard will, like with Office 365, create a synchronization account with the pre-requisite permissions, then choose OK, then Next.

AD Forest Account

On the next page of the wizard, we’ll see the sign-in configuration already chosen and select the on-premises attribute to use as the Azure AD username.

If you plan to use Exchange Hybrid immediately, then you should select the default, userPrincipalName as described earlier in the article – and ensure you have run IDFix and aligned your primary SMTP address values to the UPN.

In the example below, you’ll see a warning that will show if you have a UPN suffix in your environment that is not routable, or not registered in your Office 365 tenant.

We see the warning below because the UPN suffix lab01.local is not routable and therefore cannot be verified in the tenant. However we do have the lab01.allabout365.com domain (which is also our Primary SMTP address registered), therefore we can select Continue without matching all UPN suffixes to verified domains.

Azure AD Sign-In Configuration

If you cannot match your User Principal Name value to your custom domains right now and don’t plan to enable Exchange Hybrid immediately – for example, if you are planning on just enabling Microsoft Teams, or other services like SharePoint or OneDrive, then you can workaround this using Alternate Login ID.

This is when your scenario matches the example user below. You’ll see on the left the email value is using the correct custom domain, however you haven’t yet been able to update the User logon name on the right to match the custom domain value.

New properties

To use Alternate Login ID as a temporary measure, use the User Principal Name drop-down to select the mail attribute:

Azure AD Connect Mail Sign-In

Next, we’ll select the Domain and OU filtering options. You may not wish to synchronize every object in your Active Directory to Azure AD and Office 365.

For mail routing and Exchange Hybrid in particular you will want to synchronize (at a minimum) every recipient including mailboxes, mail users, mail contacts and distribution groups.

However, you may not wish to synchronize leavers’ accounts, service accounts and built-in accounts and non-mail enabled security groups. Therefore, it’s useful to use the Domain and OU filtering to select the OUs that contain valid recipients.

In the example below, we know that all recipients are within the People OU, and we’ll only select the Sync selected domains and OUs radio box, then select the checkbox for the OU, then choose Next:

Domain and OU Filtering

After completing the configuration and selecting any optional features to enable, we are ready to configure and perform our initial sync.

Ready to configure Azure AD Connect

After the sync completes, navigate to the Microsoft 365 admin center to validate the synchronization task is completing successfully. You should see within Users and Groups copies of your Active Directory objects.

Active users

If things don’t look right, then navigate to the Azure AD Connect Health portal. This will provide you the option to monitor Sync errors that the service is experiencing. A good result should show no sync errors to the service. You’ll resolve sync errors by following the recommendations from IDFix.

Sync Errors

Source Winbuzzer

read more
Azure AD

AMD Gains Ground on Intel in Steam CPU Usage

AMD-Threadripper-Official-696×392

AMD continues to become an increasingly potent rival to fellow chipmaker Intel. Since launching its Ryzen series of processors several years ago, AMD has made consistent gains against Intel’s market dominance. In the latest step forward for the company a recent survey shows AMD is making ground on Intel in the gaming realm.

Specifically, AMD processors are gaining CPU market share on Steam. Each month, Steam publishes its Hardware and Software Survey. This shows usage statistics across the platform, including operating system and other metrics… including processors.

Last month, Intel machines continued to be the most used on Steam, with 77.54 percent of users. However, AMD enjoyed a 0.74 percent boost and now has 22.45 percent of the usage market. Since January, the company’s share has increased by over one percent.

Of course, Intel still has a 55 percent lead so don’t expect AMD to take over. However, it is clear the gaming chip market is becoming more competitive. It’s a trend we have also seen across other areas away from gaming.

That said, it is worth remembering this survey only looks at a single platform.

GPU Data

AMD also makes GPUs, but it’s success in this area is more limited. Steam says Nvidia remains the leading GPU maker amongst its users. In fact, Nvidia GPUs make up the top nine spots in terms of GPU usage. AMD is tenth and then the rest of the list holding at least one percent of the market is made of Nvidia products.

Source Winbuzzer

read more
Azure AD

What are Azure AD Security Defaults, and should you use them?

23-03-2020-505-Archive-Shuttle-image-LOW

Azure AD Security Defaults arrived recently and make it easier to implement some of the most common security settings in your Azure AD directory, and Office 365 environment. They aren’t appropriate for everyone, but if you’ve not enabled multi-factor authentication yet, or haven’t disabled legacy authentication, then this might want to be something you consider.

Every Office 365 environment should be secure, and technically – they aren’t susceptible to vulnerabilities, are patched and up to date and regularly tested. But the default settings for an Office 365 tenant have been aimed at the lowest common denominator – organizations with legacy clients and with an expectation that organizations will buy add-on security features, like EM+S if they truly want security. This does mean that many, may Office 365 tenants are vulnerable to a number of attack vectors, including password spray attacks, because an attacker can repeatedly try and login to an Office 365 tenant using basic scripting to attempt a login, then if they successfully authenticate with a username and password, there isn’t an MFA mechanism in place.

Security Defaults replace Baseline Conditional Access policies, which do a similar job, and are offered free to all Office 365 subscriptions, whether or not you’ve paid for Azure AD Premium licensing. This is a change, as although per-user MFA could be enabled in Office 365, it didn’t include the Authenticator app, nor the straightforward enablement mechanism enjoyed by Conditional Access or service-wide Azure MFA.

Security Defaults enforces these settings:

  • Multi-Factor authentication for administrators and end-users, required within 14 days of the next sign-in after enablement
  • Legacy authentication will be blocked, restricting access from older clients, like Office 2010, IMAP, POP3, SMTP, ActiveSync clients that don’t support Modern Auth, and traditional methods of managing Exchange Online using Remote PowerShell.
  • Immediate MFA protection for “privileged” Azure AD actions via the Azure Resource Manager API (such as Azure Portal Access, Azure PowerShell and the Azure CLI).

These defaults are more secure than the baseline policies. Baseline protection policies were (and are) provided using the Conditional Access portal settings, and allowed selective enablement of MFA for administrators, MFA protection for (what Microsoft determine as) risky sign-ins for end users, blocks for legacy authentication and MFA for service management. Baseline policies were not only hidden away, but also never left preview – so many people won’t be using them in production.

Microsoft plan to enable Security Defaults for all new Azure AD tenants within the “next few months” – which should mean by the end of January 2020, a new Office 365 subscription will come with MFA enforced out of the box, and legacy authentication enabled. That’s important to know as it’s a big change.

How this might affect new Office 365 migrations

If you sign-up for an Office 365 subscription over the next few months and Security Defaults are enabled then this might be a surprise – even if you don’t have older clients like Office 2010 or use IMAP and POP3 clients.

One example of this is Outlook clients. When you migrate a mailbox, the expected behaviour is that Outlook will automatically reconfigure and connect to Exchange Online. Even with the latest Office 365 Pro Plus, signed in using Modern Authentication to Office 365 for licensing, you could still see an issue with Security Defaults enabled.

This is because when a mailbox is migrated, it continues to use the legacy authentication process as it follows the Autodiscover bread-trail to Exchange Online, and then fails when attempting to sign-in. This can be solved, either by switching off Security Defaults during your migration – or if you have control over your Outlook clients, you can deploy the registry key in this article.

In general though, you shouldn’t expect many technical issues at all if you are using up-to-date Office 365 Pro Plus clients and the Office apps on mobile. You’ll also find ActiveSync clients on iOS devices, the Gmail app and Samsung Mail apps all support Modern Authentication too (however, you’ll need to reconfigure those clients).

The biggest factor though maybe the user impact of enforcing MFA from every location.

No replacement for Azure AD Conditional Access

The down-side with Multi-Factor Authentication is the inconvenience to users. This of course, is necessary from unknown devices in unknown locations, but most organizations invest significant time and expense in ensuring that their devices and locations are secure, and as such trust their devices.

This is where Azure AD Conditional Access remains important. Conditional Access allows different levels of security for different people, apps, managed and unmanged devices and locations. You can choose where and when to enable MFA or even block access.

For example, you might choose to remove the need for a user to confirm it’s them via the Microsoft Authenticator app when they are signing in from their domain-joined, Windows 10 PC, using Office 365 Pro Plus at their computer in the Office.

You might also avoid regular prompts for MFA on their company issued mobile, too – and instead manage the device properly using tools like Intune. However you might require them to sign-in every so often if they are working from home on their company issued laptops. You might even block sign-in altogether to services containing sensitive business data from random web browsers on unmanaged devices.

There’s a lot more to Conditional Access than the above snippet – a lot more – but those are some of the core scenarios that most companies look to achieve and Security Defaults doesn’t cover.

The greatest pity about Security Defaults is that the most basic functionality organizations need – to define locations where MFA isn’t necessary – isn’t included.

This will be especially frustrating for some organizations where they have simple use-cases, like shop-floor workers in manufacturing where employees are not allowed mobile devices and the uplift to Azure AD Premium for each user doesn’t provide enough value to justify it for those type of workers. In those cases, we’ll probably see those organizations left unprotected.

Perhaps Microsoft will do as they did with the Authenticator app, and bring the basic trusted IP address range for skipping MFA.

Enabling (and Disabling) Security Defaults

You can enable Security Defaults if you aren’t using Conditional Access today. If you do have CA policies, then you won’t be able to enable Security Defaults.

Before you do anything, make sure you perform user communications so people know the change is coming – and ensure you won’t prevent access from legacy clients or applications. It’s an all-or nothing switch; so you can’t put in place exceptions for users or legacy applications  like you can with conditional access.

To enable Security Defaults, sign-in as a Global Administrator to the Azure AD Portal and navigate to Azure Active Directory and scroll down to Properties. From there, select Manage Security Defaults:

You’ll then see the option to enable Security Defaults. It’s an all or nothing switch – it’s either enabled or disabled:

The good news with Security Defaults is that should you decide you need Conditional Access policies, you don’t need to switch off Security Defaults before you define your CA policies. When you configure your CA policies, you’ll be informed you can continue to create them – once you’ve created your policies you can switch off Security Defaults and enable the CA policies you’ve defined.

Summary

Security Defaults are a good addition to Azure AD, and therefore Office 365 and will ensure many more organizations are secured by default. It’s a pity they don’t include all of the basic functionality most organizations should have – but they are a great start by Microsoft on helping all customers – not just those with Azure AD Premium licensing – to secure their identity.

Source Practical365

read more
Azure AD

Microsoft Fixed an Azure Security Vulnerability before Researchers Could Report It

Cloud-Security-Microsoft-Official-768×480

Microsoft beat security researchers to the ball in a dangerous Azure vulnerability. A CyberArk blog post titled ‘I Know What Azure Did Last Summer’ discloses a bug in the tech giant’s cloud platform that was exploitable for up to two weeks.

According to researcher Omer Tsarfari, the September issue lay in the way the Azure portal was parsing JavaScript that’s used in the Azure Portal’s Extension Manifest. An attacker with a HTTP server with the “urehubs” hostname and a signed root CA certificate could grab the access tokens of anyone who logged into the Azure portal.

The researchers were able to exploit this bug in the wild to grab an Azure token from an external organization. As a precaution, CyberArk then bought 72 urehub domains with various suffixes. Tsarfari says the bug could have led to complete takeovers of Azure environments.
“While there is a lot of honey in the Cloud Computing solutions, there is also a sting to be aware of. Relying on “someone else’s computer” also means relying on someone else’s security measures. We’ve seen a lot of attacks that have focused on cloud configuration weaknesses – and seeing and understanding these vulnerabilities helps us fortify our cloud environments,” he cautioned. “But, what about the vulnerabilities we don’t know of? Are we ready for those?”
A Speedy Fix
Thankfully, Microsoft also took action. The organization says it managed to discover and fix the bug before the researchers could report it.
“This issue was identified internally and we deployed a fix to address it,” a spokesperson told ThreatPost.

Tsarfati tells a different story. According to ThreatPost, he wrote that Microsoft’s fix of the vulnerability, just a day after his frim created a working POC, was unintentional. The company added three lines of code, adding a URL to the JavaScript file’s HREF attribute that mitigated the issue. This was all done server-side, so admins have no need to worry if they haven’t been attacked already. However, Tsarfarti believes Microsoft’s indecision when it comes to URI schema could still come back to bite in the future.
“Regarding the URI formats in the ExtensionsManifest, I think that it might be worth sticking to one URI format, as not doing that could be a root cause for many other bugs that could pop up over time,” he said.
Good enterprise security practices will always help to mitigate the damage of such vulnerabilities, but the trust, ultimately, has to be with Microsoft. This time, it has at least caught it early on.

Source Winbuzzer

read more
Azure AD

Microsoft Is ‘Investigating’ Claims That It Benefits from Forced Labor in China

China-Flag-Wikipedia-1-768×512

Microsoft has responded after a report that claims the company benefits from forced labor in China. A publication by the Australian Strategic Insitute (APSI) published on Saturday alleges the Chinese government has performed a mass transfer of Uyghur and other ethnic minorities from Xinjiang to factories across the company in what appears to be forced labor.

These factories supply 83 well-known brands, including tech giants like Apple, Microsoft, Samsung, Huawei, Google, and Sony. Over 80,000 Uyghurs were transferred to factories across China between 2017 and 2019, the ASPI says, with some of them sent directly from detention camps. Evidence shows the workers are under constant surveillance, have limited freedom of movement, live in segregated dorms, and are forbidden from religious observances.

“Microsoft is committed to responsible and ethical sourcing. We take this responsibility very seriously and take significant steps to enforce our policies and code of conduct in support of human rights, labor, health and safety, environmental protection, and business ethics through our assurance program,” said a Microsoft spokesperson to Windows Central on Monday. “All forms of forced labor are specifically banned by our Supplier Code of Conduct. We are investigating the claims and will take appropriate action if breaches of our code of conduct exist.”
This follows reports in mid-2019 that companies like Microsoft, Amazon, and Google are looking to move production outside of China. As the trade war between it and the US continues and the atrocities against the Uyghur people becomes clear, it’s more and more difficult for tech giants to justify the use of workers in the country for cheap labor.
Ensuring their a product is ethically sourced from start to finish is a difficult undertaking, but it’s something companies must bear and respond to criticism on. Microsoft is at least looking into the issue, but human rights organizations will undoubtedly want to know what action it’s taking and how it plans to prevent problems in the future.

Source Winbuzzer

read more
Azure AD

AMD Confirms Ryzen Threadripper 3990X Works on Windows 10 Pro Without Performance Dips

AMD-Threadripper-Official-768×432

Since the launch of AMD’s Ryzen Threadripper 3990X, it was believed the monster CPU would not run on Windows 10 Pro. That because the CPU was believed to be too powerful and would need Windows 10 for Workstations or Windows 10 Enterprise. However, AMD has today said the Pro SKU also works, and there’s also some good news for Linux users.

If you’re unfamiliar with the Ryzen Threadripper 3990X, it is part of the company’s 3000 series and is among the most powerful CPUs ever made. It is capable of running triple A graphically intensive games without a coupled dedicated GPU.

When the 3990X launched last month, most believed Windows 10 Pro would not handle the CPU. Furthermore, Linux also seemed to be off the cards. Today, AMD has confirmed that is not the case and is backing the Threadripper on those OS’s.
“We wanted to clarify that AMD officially recommends Windows 10 Professional or Linux for the AMD Ryzen Threadripper 3990X. Higher editions/versions of Windows 10 confer no additional performance or compatibility benefits to the processor.
“We do understand that this suggestion has been made in some articles, and our team is presently testing this further, but this is the official recommendation.”
Details
There is a caveat to consider. Namely, the Threadripper 3990X won’t show all its 128 threads across 64 cores on the Windows 10 Pro Task Manager. However, this will not affect the overall performance of the CPU on the platform.
It is worth noting AMD recommends running Windows 10 Pro version 18362.592 or higher for the best performance experience.
Over on the Linux side of the OS fence, users can now splash out (over $3,000) on the Ryzen Threadripper 3990X and know its performance won’t be hampered.

Source Winbuzzer

read more
Azure AD

https://winbuzzer.com/2020/02/12/windows-10x-has-two-file-explorers-xcxwbn/

27-01-20-434-Blog-Header-Office-365-Management-1-1024×553

Entitlement management – Connected organizations
Welcome back! So far in this series, we covered the concepts behind entitlement management and created a sample access package in the first article. In the second part, we expanded on some additional settings, looked at how things work from the end user’s perspective, and covered topics such as auditing in reporting. Now, we will explore one of the main reasons why you might want to use entitlement management – the ability to grant access to users from “connected” organizations and manage their lifecycle within your own directory.
Connected organization
We’ll start by introducing the concept of Connected organization. Any organization you have a relationship with can become a Connected organization, regardless of whether they are already using Azure AD or not. In our scenario, we can imagine that part of the work that needs to be completed for the successful delivery of Project Tango will be executed by an external company. To make things simpler, we will cover the scenario where the external company already uses Azure AD, but will provide notes for other scenarios throughout the text.
To add a new Connected organization, navigate to the Azure AD blade -> Identity governance -> Connected organizations and press the Add connected organization button. The familiar wizard interface will guide us over the creation process. On the first page, Basics, you can enter the Name and Description, then continue to the Directory + Domain page. Here you will press the Add directory + domain link and provide a domain name to search for.
You can use any of the domains verified in the (external) organization, or their default, tenant.onmicrosoft.com domain. If the organization is found, the corresponding Name will appear for you to verify, and if they are using Azure AD, the corresponding Authentication type will be configured. If they are not using Azure AD, the Authentication type will change to One-time pass code, the new B2B feature allowing users to redeem their invitation by providing a code sent to their email address. Another possible scenario here is direct federation. Only a single directory/domain can be added at a time, so you might need to repeat the process in case you have multiple organizations to add.

Add connected organization

The next step is to configure Sponsors. Those are basically users that are responsible for managing some of the tasks related to collaboration between users of the two organizations, such as issuing approvals for assigning a package. Two types of sponsors exist, internal or external, which you configure via the corresponding Add internal sponsors/Add external sponsors links. While both types are optional, it’s recommended that you do configure at least one sponsor. If you choose to configure an external sponsor, it is important to understand that they must already exist in your directory as a Guest user, that is you cannot select a user directly from the external organization. The UI actually allows you to select regular (internal) users as the external sponsor, a small improvement here would be to filter the view and only present Guest users.

Lastly, on the Review + Create page, you can go over the configuration one last time and if everything checks out press the Create button to provision the new connected organization. You can change the settings later by selecting the corresponding entry from the list of connected organizations. One small annoyance found here is that you can only see the “Name” of the connected organization when it is of type Azure AD, not the actual (default) domain you pointed to when configuring it. This can cause confusion later on, as the “Name” is a free-form field, unrelated to the default domain and can have any value. Similarly, multiple organizations can have the same “Name”.

Assigning packages to users from connected organization

Now that we have at least one connected organization configured, we can proceed to provision some access packages that assign resources to users from said organization. Please note, that the catalog with the corresponding resources must be Enabled for external users, by toggling the corresponding setting on the catalog overview page.

To make things a bit easier and avoid repeating steps from our previous articles, we will select the already existing Project Tango package and create a new policy, this time using the For users not in your directory option. Doing so presents the choice between Specific connected organizations, where you select one or more pre-configured organizations; All connected organizations, which as the name suggests applies to all organizations; and All users, which includes any additional connected organizations you configure in the future.

Another important part to note is that any packages that have a policy associated with a given connected organizations will be accessible by any user within said organization. This will also include users from any additional (sub)domains within the corresponding Azure AD directory. If you select one of the other available choices here, the package will be eligible for even broader scope of external users. One way to restrict access is to use the Azure AD B2B policy controls to specify a list of allowed/blocked domains. Alternatively, you can control this via approvals and access reviews.

Read more: How to Manage Guest User Access in Azure Active Directory

After making the selection, proceed with configuring the rest of the policy settings. Since you are effectively provisioning access for external users, it’s a good idea to diligently configure the Approval settings, where you can request that both the External sponsor and Internal sponsor you configured when adding the connected organization have their say in the process (two-stage approval). Justification, alternate approvers and fallback settings can also be configured as needed. Same applies to the Lifecycle policy settings, which you should also configure with care. Since no additional controls are presented here, refer to our previous articles or the official documentation for more information on these.

External user experience

We now have a connected organization configured and a policy that makes one of our access packages eligible for users within said organization. In order for users from connected organizations to request access to a package, they will need to be given a link to it, as access packages from connected organizations do not show under the My Access portal. Alternatively, access for external users can also be granted directly by a user with sufficient permissions via the corresponding page in the Azure portal, as with the other scenarios we examined.

Once the person opens the link sent to them, the process is pretty much the same as that for internal users, with the slight difference that you cannot view the set of resources included in the package until you get the actual approval. When submitting the request, you will also see a privacy notice, which you must accept.

Once the request is approved and the corresponding access package has finished provisioning, the list of resources will be populated, and the external user can access them. As part of the process, a Guest user object is provisioned/invited to the directory. This representation of the user object within your own directory is what allows you to assign access and otherwise govern the lifecycle for such external users. Unlike the “regular” Guest user invitations process though, no email invitation will be sent, however the user will receive a notification that he has been granted access as part of the access package.

At this time, the user can click on any of the links in the (now updated) list of resources or access the corresponding resource directly. The first time they do this, they will have to complete the invitation process by consenting to the below prompt:

Another way for the user to access the corresponding resources is via the My apps portal. In our scenario, they should expect to see the two Azure AD integrated applications we’ve added as part of the package, and under the Groups page, he should also be added as members of the specified groups. Since the tenant has some groups with dynamic membership rules configured as well, the external user will become a part of their membership where applicable.

Final remarks and series summary

Before we close off the series, we should also mention some important settings related to Managing the lifecycle of external users. Those settings control what happens when access lapses for all of the access packages previously assigned for the user and allow you to block the user or remove him from the directory altogether. Additionally, you can specify the number of days before the user is removed. You can find the corresponding settings under the Azure AD blade -> Identity Governance -> Settings as pictured below:

So, there you have it, our not so short review of the entitlement management feature in Azure AD. Over the course of three articles we introduced the concepts behind the feature, and examined a sample scenario where an access package that grants access resources needed for a given project was created and later assigned to users. Apart from managing the set of resources and user assignments, the feature comes with built-in approval workflow, lifecycle controls (including managing the lifecycle of external users), robust auditing and reporting capabilities as well as PowerShell and Graph API support (albeit in preview). In a world where “minimum viable products” are becoming the norm, it’s refreshing to see Microsoft releasing a fully functional and highly customizable solution.

That’s not to say that entitlement management is perfect or without limitations. We mentioned already that only cloud-authored Azure AD groups are supported, meaning you cannot use Access packages to grant access to on-premises or Exchange Online groups. This argument can be extended to cover other resource types, but I suppose those will be covered when we get Graph API support for the corresponding workloads. Another restriction that you should be aware of is that multi-geo SharePoint Online locations are not supported, you can only grant access to sites within the default geo-location. Some of the choices presented when selecting different resources in the UI can also be handled better. Lastly, the Azure AD Premium P2 license requirement for every user that requests a package might also be a problem for some organizations.

Source Practical365

read more
Azure AD

What is Azure AD Connect Cloud Provisioning and should you plan to use it? Part Two

406-Blog-Header-An-image-of-a-plan-with-clouds-2-LOW

In part one, we examined why Azure AD Connect Cloud Provisioning has a clear use-case for organizations dealing with mergers and acquisitions – and how it helps move organizations to a cloud-based provisioning model rather than running more services on-premises to simply duplicate their directories in the cloud. In particular, Cloud Provisioning makes it possible to sync multiple Active Directory environments that aren’t connected over the network.
Azure AD Connect doesn’t allow this because only one instance can be installed per Azure AD/Office 365 tenant and the Azure AD Connect server needs to be able to access every AD forest.
To round up part one we set up three Active Directory environments, all running Exchange Server and synchronized them to Azure AD.
In part two we’ll explore the configuration that gets applied when you use Azure AD Connect Cloud Provisioning and explore some of it’s current limitations. As mentioned in part one – this technology is in preview so don’t go and try this out in your environment until it’s GA.
Exploring Azure AD Connect Cloud Provisioning’s configuration and limitations
However limitations with using Exchange Hybrid – or device sync (necessary for Hybrid Azure AD Join of Windows 10 devices) may mean that this is really a stop-gap solution rather, if these limitations persist when Azure AD Connect Cloud provisioning goes into General Availability.
This may be a big limitation for some uses because the attributes synced include the common set of Exchange Hybrid attributes, such as ExchangeGUID (and more) that correctly identify that a mailbox exists on premises and block creation of a user mailbox in the cloud. Third-party migration tools usually expect a target mailbox to be created in Office 365.

If you want to examine the schema and understand what is synced (and what isn’t) then instructions to access this in JSON format are available on Microsoft Docs. To follow the procedure, you’ll need to setup a sync configuration first – so to give you an example schema to examine I’ve uploaded one from the lab here. You can use a JSON tree viewer (as shown below) to make navigating the structure easier:

Azure AD Connect Object mappings

Dealing with duplicate objects

Naturally if you have multiple Active Directory forests, there’s a reasonable change that you will have objects relating to the same user across each forest. A common example might be contact objects or user accounts created to allow access to applications.

Azure AD Connect Cloud Provisioning doesn’t currently match objects across different source environments, which means if there are multiple objects relating to one user, then you need to either de-scope these users from the sync – or use Azure AD Connect.

But what happens if you do synchronize multiple objects? To test this out, we’ve created an object in Lab 01 that matches a user in Lab 02. This is a Mail User – a normal user account, with an External Email Address of the user in Lab 02:

Azure AD Connect synchronize multiple objects

You would expect that this would fail to synchronize because the Primary SMTP address already exists due to the sync relationship with Lab 02. However – it does successfully sync and results in a duplicate Mail User in Exchange Online – as shown below:

However – in the Office 365 Admin portal, this is recognised as an error when we attempt to licence the user. Although both have a different UPN value, attempting to licence the user results in an error message due to the duplicate SMTP address:

Therefore, the best advice if you are testing this today is to ensure that you validate uniqueness across directories before attempting to sync. The staging mode or error logs won’t highlight errors like this for you, nor prevent this from occurring.

What happens if you attempt an Exchange Hybrid configuration?

We can see one key reason by viewing the synchronization job schema (above) or reading the limitations around write-back to understand why Exchange Hybrid isn’t supported. The Hybrid attributes normally expected aren’t written back to the local Active Directory.

You can verify this after a successful sync by examining a mailbox. We would normally expect to see the LegacyExchangeDN created in Exchange Online written back as an X500 address to the local AD and Exchange environment. As you’ll see below, it’s not written back:

Additionally, upon attempting to perform an Exchange Hybrid configuration, we’re informed that Azure AD Connect isn’t in place – which should (hopefully) be a red flag.

To see what happens in the lab (and really, don’t try this in production – not only is Azure AD Connect Cloud Provisioning in preview but Exchange Hybrid is explicitly NOT supported) we choose I will install Azure AD Connect later on my own to allow the Exchange HCW to continue as normal.

For the purposes of testing we then Hybridized all three Exchange Server environments, and created Migration Endpoints for each.

After performing synchronization jobs to ensure that the additional mail.onmicrosoft.com email aliases were correctly synchronized to Azure AD, we successfully migrated mailboxes from each environment – however as the core Exchange attributes are being synchronized, and a mailbox migration isn’t reliant on Azure AD Connect itself, this was generally expected:

As a side note, it’s worth mentioning that although Azure AD Connect write-back wasn’t available, the attribute stamping process as part of a mailbox migration added the missing Legacy Exchange DN value:

Potentially more useful was testing the ability to use an Exchange Server to create an Office 365 mailbox. At present, if you have a Hybrid AD – then you’ll need to use an Exchange Hybrid server to create and manage mailboxes. That’s certainly a tricky support situation to be in with Azure AD Connect Cloud Provisioning.

As expected, after performing Hybrid Configurations in each environment the New Office 365 Mailbox option becomes available (or in Exchange 2010, New Remote Mailbox):

To test this worked correctly, we created a new mailbox in Office 365 using the Exchange Admin Center and archive-enabled it on-premises to ensure that relevant attributes were correctly synced. As shown below – once licenced the mailbox was created as normal in Office 365, including the archive:

Summary

The Azure AD Connect Cloud Provisioning preview is a good insight into what Microsoft are making available for helping organizations deal with disconnected multi-forest environments who are consolidating in Office 365, or using Azure AD as a central SSO platform. Right now the preview is very much a preview and if you need premium features like write-back – or common functionality like Exchange Hybrid, you’ll need to wait a little while yet.

Source – Practical365

read more
1 2 3 5
Page 1 of 5