close

Azure AD

Azure AD

Azure AD

How To Host a DNS Domain in Azure

images

One of the important things you will do with any online service is to configure DNS. You obtain a DNS domain from a registrar and either host the domain with the registrar’s own hosting service or on your own public DNS servers.

People often don’t consider the impact of DNS on the performance on their online service. The first thing that a client (or potential customer) will do when browsing your site is to attempt to resolve the name of your service. So, if they browse to www.petri.com the browser/operating system will attempt to convert that name into an IP address to connect to – the address might be hidden by several layers of abstraction (CNAMEs).

How fast that resolution happens impacts the overall performance of the site, and the longer a site takes to load, the less profitable it will be. Many DNS hosting services are located in one or a few data centers in a relatively small area. For example, I might host a DNS name in California. If a customer in the Western US browses the site, the name will resolve quickly and then the site can start to load. But if a customer in India attempts to browse to the site, the name is on the other side of the globe and it will take much longer for the name to resolve and the site to start loading – customer lost!

Azure DNS hosts your domain in Azure’s global network of data centers. That means that your domain is hosted all around the world, with automatic replication, and places the domain names closer to your potential customers. Using anycast networking, the client is redirected to the closest replica – now that client in India is redirected to an Azure DNS replica in India and the name resolves in milliseconds.

Other Benefits include:

  • Being an Azure service, Azure DNS can leverage Azure AD, auditing, governance, role-based access control (RBAC), and resource locking to secure your DNS service.
  • The admin experience is extremely simple – much easier than those “cpanels” that registrars use.
  • There is an internal DNS hosting option, but I find it a bit immature today. The external option, however, is awesome, in my opinion.

Create the Azure DNS Resource

Start off in the Azure Portal and click Create a Resource. Search for and select DNS Zone, and then click Create. Enter the following details in Create DNS Zone:

  • Name: The name of the DNS domain that you want to host.
  • Subscription: The subscription that you want to create the new resource in.
  • Resource group: The name of the resource group to create/use.
  • Resource group location: The Azure region of the resource group.
Creating a DNS hosting resource in Azure [Image Credit: Aidan Finn]
Creating a DNS hosting resource in Azure [Image Credit: Aidan Finn]

The new DNS zone resource is created as a global resource, not dependent on any one region … in theory. If I was creating a DNS zone in Azure for a service that runs in North Europe and has failover to West Europe, I would host the DNS zone in a different resource group that is hosted in France Central … weird things can happen in huge clouds and I don’t like to take chances.

The resulting resource is pretty simple. You can add records and delete the zone. Speaking of which – you might want to add a Delete lock to the DNS zone resource.

A new DNS zone hosted in Azure [Image Credit: Aidan Finn]
A new DNS zone hosted in Azure [Image Credit: Aidan Finn]

Note the highlighted name servers in the above screenshot. These are the names, resolvable by anycast, that the Internet will use to find the DNS servers for this DNS domain.

Modify Name Servers

At this time, the Internet has no idea about your new DNS hosting resource in Azure. It is time to change that. Browse to the control panel of your DNS registrar and log in. Browse through the maze of links until you find the option to manage your name servers. Change the registrar’s default name servers to the four Azure name servers.

Yes – Azure DNS is global and there are just four name servers. These names will use anycast to resolve to the closest replica of your globally replicated DNS zone.

Modifying the name servers for Azure DNS hosting [Image Credit: Aidan Finn]
Modifying the name servers for Azure DNS hosting [Image Credit: Aidan Finn]

Tip: Don’t do this until you have created all the required DNS records in your new DNS zone. It also might take time for the TTL (caching period) of old records to expire and force a re-lookup to your new DNS records in Azure.

And that is it! Now the Internet will start to look to Azure DNS to resolve names in this domain. You can now go through the simple process of creating DNS records in the Azure Portal.

read more
Azure ADUncategorized

Multi-factor Authentication by Default for Administrators in Azure AD and Office 365

attachdocumentssharepointlist13a

Microsoft is rolling out a new baseline security policy for Azure Active Directory and Office 365 that requires multi-factor authentication for privileged accounts. The policy is in public preview right now, meaning it is visible in tenants but not yet enabled.

The baseline security policy will require multi-factor authentication for accounts that are members of one of the following privileged roles:

  • Global administrator
  • SharePoint administrator
  • Exchange administrator
  • Conditional access administrator
  • Security administrator

You can view the policy in the Azure AD portal by navigating to the Conditional access section.

Although the baseline security policy is implemented as a conditional access policy there is no customization available except for excluding users and groups. Conditional access rules that you can fully customize require Azure AD Premium licenses, whereas the baseline security policy is available to all customers. You can use the exclusion option to exclude at least one global administrator account from all conditional access policies. Microsoft recommends doing so to ensure that you still have a way to log in if you inadvertently lock yourself out of all admin portals. Think of it as a “break glass in case of emergency” account. The account should have a strong password that is stored in a secure location, and is not regularly used for day to day administration tasks.

The new baseline security policy has been reported elsewhere as “mandatory” or as Microsoft “forcing” multi-factor authentication on customers’ administrative accounts. This is not true of course. You can opt-out of the policy before it goes live by choosing Do not use policy, and you can set exclusions as I just mentioned a moment ago. Aside from the emergency access account you should aim to minimize the exclusions that you add to the policy. Microsoft recommends if possible switching to Managed Service Identity (MSI) or service principals with certificates.

The nature of the policy also ensures that accounts that are temporarily elevated to a privileged role (either manually or via privileged identity management) have MFA enforced on them, reducing the risk of compromise during the period of time they hold privileged access. This is similar to another recent addition to conditional access allowing policies to be targeted at directory roles. That capability extends to a wider range of directory roles than the five that are targeted by the baseline security policy.

Overall this is a good move for Microsoft to make, strongly pushing customers towards securing privileged accounts. When I surveyed readers last year, 55% of respondents were not using MFA at all (even for admin accounts). That’s despite MFA for admin accounts being one of the recommend first steps for new Office 365 tenants, being flagged by Office 365 Secure Score, and being one of the general account security recommendations from Microsoft.

What do you think? Will you be enabling the new baseline security policy in your tenant?

read more
Azure AD

Microsoft Extends Azure Active Directory Conditional Access Policies

AzureAD-1.x98795

The Azure Active Directory identity and access management service now supports conditional access policies when used with Microsoft Teams, as well as the Azure Portal, Microsoft announced today.

Conditional access policies refer to conditions that must be true before access to network resources is permitted. For instance, a device might need to have the latest software updates in place before gaining access to those resources. Other conditions might be the user’s location or the user’s sign-in risk, which might be factors set under conditional access policies.

Microsoft explained that, until today, IT pros using the Azure AD service didn’t have the ability to set conditional access policies for either Microsoft Teams or the Azure Portal. Now, that capability is available.

IT pros can set conditional access policies for the Azure Portal using that portal. However, Microsoft cautioned that such changes will affect other management solutions as well, such as “classic Azure portal, Azure portal, Azure Resource Manager provider, classic Service Management APIs, as well as PowerShell.”

In addition, IT pros making such changes via the Azure Portal could wind up locking themselves out.

“While configuring a policy for Azure portal, be cautious! A bad configuration might lead to you locking yourself out,” Microsoft cautioned.

On the Microsoft Teams side, IT pros can use the Microsoft Teams “cloud app for IT admins” to set conditional access policies. (Possibly, Microsoft is referring to the “Office 365 Admin Center,” a browser-based administrative portal, as described in this support document.) Microsoft Teams is the company’s newest collaboration solution for Office 365 users.

The announcement added that if other conditional access policies have been set for applications other than Microsoft Teams, then they’ll take effect, too.

“It’s important to note that Conditional Access policies created for Exchange Online and SharePoint Online cloud apps also affect Microsoft Teams as the Teams clients rely heavily on these services for core productivity scenarios such as meetings, calendars and files,” the announcement explained.

read more
Azure ADUncategorized

Microsoft Extends Azure Active Directory Conditional Access Policies

hero_azuread

The Azure Active Directory identity and access management service now supports conditional access policies when used with Microsoft Teams, as well as the Azure Portal, Microsoft announced today.

Conditional access policies refer to conditions that must be true before access to network resources is permitted. For instance, a device might need to have the latest software updates in place before gaining access to those resources. Other conditions might be the user’s location or the user’s sign-in risk, which might be factors set under conditional access policies.

Microsoft explained that, until today, IT pros using the Azure AD service didn’t have the ability to set conditional access policies for either Microsoft Teams or the Azure Portal. Now, that capability is available.

IT pros can set conditional access policies for the Azure Portal using that portal. However, Microsoft cautioned that such changes will affect other management solutions as well, such as “classic Azure portal, Azure portal, Azure Resource Manager provider, classic Service Management APIs, as well as PowerShell.”

In addition, IT pros making such changes via the Azure Portal could wind up locking themselves out.

“While configuring a policy for Azure portal, be cautious! A bad configuration might lead to you locking yourself out,” Microsoft cautioned.

On the Microsoft Teams side, IT pros can use the Microsoft Teams “cloud app for IT admins” to set conditional access policies. (Possibly, Microsoft is referring to the “Office 365 Admin Center,” a browser-based administrative portal, as described in this support document.) Microsoft Teams is the company’s newest collaboration solution for Office 365 users.

The announcement added that if other conditional access policies have been set for applications other than Microsoft Teams, then they’ll take effect, too.

“It’s important to note that Conditional Access policies created for Exchange Online and SharePoint Online cloud apps also affect Microsoft Teams as the Teams clients rely heavily on these services for core productivity scenarios such as meetings, calendars and files,” the announcement explained.

read more
Azure AD

Microsoft Intune in Azure Portal Now Commercially Available

Azure intune

Microsoft Intune, as managed through the Azure Portal, has reached “general availability” status and now supports conditional access settings, Microsoft announced today.

Intune is Microsoft’s mobile device and mobile application management solution. It’s typically available as part of Microsoft’s Enterprise Mobility + Security licensing bundle. In December, Microsoft had announced a preview of Intune controls from within the Azure Portal. The Azure Portal is a browser-based administrative console used for managing Azure services, but Microsoft planned to move all of Intune’s capabilities into that portal as part of a general consolidation effort. Today Microsoft is signaling that the consolidation effort is complete, and the use of Intune from the Azure Portal is ready for production use by organizations.

In addition, Microsoft indicated that conditional access policies can now be set using Intune in the Azure Portal as that feature has reached general availability, too. Conditional access is Microsoft’s phrase for setting policy conditions for granting device access to network resources. With those policies in place, end users get challenged, or locked out, if their devices don’t meet various compliance criteria.

The Intune announcement follows an earlier one this week indicating that conditional access policy support is now available for Microsoft Teams, which is Microsoft’s Office 365 workspace collaboration service. Conditional access also is available from within the Azure Portal itself, Microsoft indicated.

There are three advantages to using Intune via the Azure Portal, according to Microsoft. It can be used on “any browser on any device form-factor.” There’s better integration with Azure Active Directory and Azure Information Protection services. And lastly, it unlocks access to the Microsoft Graph API, which is the developer interface for the search service that underlies various Office 365 services. Microsoft Graph API access is currently at the preview stage, but general availability will arrive “in the coming quarter,” Microsoft promised.

The general move of Intune and conditional access capabilities to the Azure Portal is Microsoft’s basic plan. New features will be destined for the portal.

“From this point forward, all new Intune and conditional access features will be delivered in the new portal, so keep an eye out,” Microsoft’s announcement stated.

read more
Azure AD

Quest On Demand Service Now Available To Ease Office 365 and Azure Active Directory Management Woes

download

Quest today rolled out the first three additions to its new cloud-based solutions for managing Office 365 applications and Azure Active Directory implementations.

There are three new “modules” that are part of the new “Quest On Demand” (PDF) software-as-a-service (SaaS) portfolio that was launched today. The “Policy Management for Skype for Business Online” and the “Policy Management for Exchange Online” modules provide centralized management capabilities for those applications. There’s also a new “Recovery for Azure AD” module that offers granular restore capabilities for Azure Active Directory users.

Quest On Demand is a new SaaS platform that has been at the preview stage since March. Today, it’s ready for commercial use, along with the new modules. The platform is “100 percent born in the cloud” and runs on Microsoft Azure infrastructure, according Michael Tweddle, president and general manager of the Quest Microsoft Platform Management Business Unit.

Previously, Quest has had success helping organizations move to Office 365 services. It’s also provided support for “hybrid” customers that manage on-premises infrastructures along with Office 365 services.

“When you look at just our portfolio, we have about 150 million Active Directory accounts under management,” Tweddle said. “We have just over a 100 million accounts that are being covered and secured by our auditing solutions. We’ve migrated over 85 million Active Directory accounts.”

The new SaaS platform will make it easier for organizations to track changes in Active Directory that can also be used with Azure Active Directory, and it can be done in an auditable fashion, he said.

Quest has broader plans for its SaaS platform and plans to add additional modules over time, such as audit, license management and migration modules.

“On Demand will be that SaaS offering that we build around for the future,” said Brad Kirby, director of product management at Quest.

He described two key goals for On Demand. One of them will be to drive a unified customer experience that will make management easier than in the past. The On Demand platform has a unified RESTful API that allows organizations to interact programmatically with the platform, he added. The other goal is interaction between modules within the ecosystem.

“So you can imagine, over time, that there’s an audit portion that picks up that some changes happen, and I can immediately launch it to the recovery portion of the platform and roll back that change if that’s something I want to do,” Kirby explained.

Examples of what can be done with the new modules include creating a set of policies that restrict individuals from sending documents outside an organization when using Exchange Online. It’s possible to set Skype for Business Online policies that restrict office workers to using the cheaper VoIP service instead of the public switched telephone network (PSTN).

“So essentially it’s all about being able to apply a set of rules to a group or user that determines what they can do,” Kirby said. “And then, as they migrate from group to group within your organization, … they would receive the set of policies appropriate to that group.”

Organizations can set mailbox retention policies, Active Sync policies, and even whether end users can use a Web client, he added. Quest has taken aspects of its Recovery Manager for Active Directory product and applied it to Azure Active Directory. So, while Microsoft’s retention policy for deleted users is just 30 days, Quest makes it possible to restore deleted accounts beyond that limit.

Kirby said that organizations typically have to use PowerShell today to make such configurations, and “so you have to have the experts on staff.” Quest took the effort to simplify the user interface for organizations. The policies, once set up, become self-enforcing, and it’s possible to prove to an internal or external auditor that the policies have been applied, he added.

“I think Microsoft has done a good job with some of their admin portals, but they can’t do everything,” Kirby said. “If you look at some of the capabilities that they provide for setting policies, they’re pretty rudimentary.”

Quest On Demand modules are standalone SaaS applications. Today, they do not integrate directly with the Microsoft Operations Management Suite (OMS), which is Microsoft’s management service for cloud workloads. It’s something that Quest has contemplated, though, Kirby said.

The subscription-based Quest On Demand service requires an annual contract at minimum, with three-year contracts being the maximum term. The service is offered via annual, quarterly and monthly billing.

Quest is not part of Dell, although Dell had announced plans to buy Quest back in 2012. Quest is an independent software company backed by Francisco Partners and Elliott Management, consisting of four business units. It has a Data Protection and KACE segment. There’s a Security and Identity and Access Management (One Identity) unit. Another segment is Information Management, plus there’s a Microsoft Platform Management unit.

read more
Azure AD

Give Anyone Credentials with Azure Active Directory

azure-b2b

Active Directory was designed to help IT provide secure access to enterprise networks, but its architecture has never lent itself to providing business partners and other external users with access to an organization’s systems and applications. Although there are well-established techniques for providing such access to outside users, it has often proven difficult if impractical. This is especially true for organizations that deal with large numbers of partner organizations, or who need to grant access to users who are independent contractors or who work for a company that doesn’t have an IT department. Recently, however, Microsoft has made it far easier to provide external users with access to resources through Azure Active Directory (Azure AD) B2B.

Azure AD B2B marks a revolutionary shift in digital identity management, and yet at the same time is somewhat evolutionary in nature. Let me explain. IT pros experienced with administering Windows Server networks are familiar with the concept of domain-joining a PC. Simply stated, joining a PC to an AD domain makes the PC a part of that domain. As a domain member, the PC will be subject to any applicable Group Policy settings. It also means that users who have domain accounts will be able to use the domain-joined PC to log into the domain.

For many years, domain-joined PCs were the standard for enterprise networks. Because a domain-joined PC exists as a domain member, such a PC can be tightly controlled, secured and managed. Although domain-joined PCs are still widely used, the mobile device revolution had a major impact on the way that network endpoint devices are used in the enterprise. Seemingly overnight, there was an insatiable demand by users to be able to work from tablets, smartphones and other mobile devices.

However, such devices cannot generally be domain-joined. Therefore, they were largely perceived by IT professionals as being difficult to manage, and potentially introducing new security vulnerabilities. Because there was such an extreme demand for using such devices, the IT industry relented, and non-domain-joined devices became the norm. Of course, this meant that the IT industry had to come up with ways of securing and managing these non-traditional devices.

On the surface, there would seem to be absolutely no link between mobile device use and Azure AD B2B. In many ways, though, the mobile device revolution laid the groundwork for Azure AD B2B. To understand why, it’s important to consider the AD anatomy. Windows PCs are configured with a unique computer name. When a PC is joined to AD, an AD object representing the computer is added to the Computers folder (see Figure 1). This object’s name matches the computer name of the PC that it represents.

[Click on image for larger view.]Figure 1. Figure 1. Computer objects are placed into the Computers folder.

Although the AD Users and Computers console makes a computer object look a lot like any other type of AD object, computer objects actually function in a similar manner to user accounts. Like a user account, a computer account even has an associated password, although the use of this password is entirely automated and is hidden from view.

When a device isn’t domain-joined, there’s no computer account representing the device and security policies that are normally applied to such accounts cannot be applied to a such a device. Consequently, Microsoft had to come up with a way of decoupling a device’s identity from computer account objects. Over the years, Microsoft has come up with a few different ways of doing this. Windows Server, for example, includes a mechanism for enrolling a device. Similarly, a device can be registered through Microsoft Intune.

More recently, Microsoft has faced a very similar problem with user accounts, and it’s hardly surprising that the company has solved this problem in a manner similar to how it solved the domain-join problem.

Microsoft has faced problems with user accounts for decades. Specifically, businesses often collaborate with one another. This is true of business partnerships, but it also holds true for other types of business relationships such as supply chains. The problem is how to grant digital resource access to users who don’t actually work for the organization.

Microsoft has introduced several different collaborative mechanisms over the years, but none of these solutions has been perfect. For example, some organizations create user accounts for employees in partner organizations. However, this increases the organization’s software licensing costs. The approach may also drive up the organization’s support costs, because an external user may occasionally require technical support, password resets and so on.

Creating user accounts for external users also complicates things from an administrative standpoint. Administrators must be able to somehow differentiate between an employee’s account and an external user’s account. Because external users are presumably not going to be working on-premises, the organization will also have to provide those users with a VPN or a similar mechanism that they can use to access the organization’s resources externally. Granted, remote access is very common these days, but it’s still something that must be considered when providing access to external users.

Another approach that is sometimes used is directory trusts. In other words, the organization configures its AD environment to trust their partner’s AD domain. Doing so makes it possible to grant resource access to users in the partner organization, without explicitly creating user accounts for those users.

Although this approach works, it’s far from being ideal. For one thing, AD trusts can only be used if both organizations have an AD environment. Furthermore, AD trusts can be complicated to set up, and they tend to raise a lot of questions about security. For example, what happens if you choose to trust an organization that trusts an organization that you do not trust? Incidentally, Microsoft provides the answer to this and many other directory trust questions here. The bottom line is although there are ways of providing resource access to external users, those methods tend to create a support burden, and may not fully meet an organization’s logistical or security requirements.

These are the types of issues that Azure AD B2B is designed to address. With Azure AD B2B, Microsoft has addressed it essentially the same way it handles mobile device enrollment. Even so, the concept seems far more profound when it’s applied to users rather than to devices. In creating Azure AD B2B, Microsoft has separated the user’s account from the user’s identity.

Consider that in the past, users were usually given a username and a password. The username corresponded to an account, and all of the user’s permissions were based on that account. But what if it were possible to control user access without creating user accounts? That’s the focus of Azure AD B2B. Technically, Azure AD B2B doesn’t completely mitigate the need for user accounts. However, it completely changes the account model to something best described as Bring Your Own Account. For example, my primary AD domain is BrienPosey.com. If I have a collaborative application running on Azure and need to give my editors at Redmond access to the application, because I’m a freelance contributor and not an employee, the editors all use accounts that reside in domains I don’t own.

read more
Azure AD

Microsoft Previewing Azure Active Directory Sign-In Changes Coming Next Month

no thumb

Microsoft is previewing yet another sign-in experience for Azure Active Directory and Microsoft account users, giving organizations notice of changes that will get established this fall.

The sign-in experience is getting revamped to have a “consistent look and feel” for both Azure AD and Microsoft account, with the aim of eliminating “jarring transitions when you move between the two,” Microsoft explained, in its announcement today. With the new design, users will see two screens. They’ll get prompted to enter their names on one screen. Next, they see a screen prompting for passwords or other means of verification. Organizations will be able to add their brands to this updated user interface.

Microsoft has already pushed out this change to Microsoft accounts “over the last few weeks.” Today, Microsoft gave notice that it is starting to deliver the new experience to Azure AD sign-in pages, too, although it will show up as a preview option over “the next few weeks.”

However, the new portal behavior soon will go live. It will happen in “the last week of September.”

Microsoft is giving organizations about 30 days advance notice about the coming changes. The new approach could break any automation that might have been set up by an organization because of its multiple-screen sign-in approach. Branding also could get obscured with the new approach, and organizations might want to update their documentation.

The updated portal behavior likely will be a “disruptive change” for some organizations, Microsoft’s announcement admitted. Microsoft MVP Paul Cunningham indicated in a blog post today that he has already seen the new behavior and suggested it could be problematic for organizations that have set up custom branding.

The 30-day advance notice was something that Microsoft promised it would do earlier this year after it had abruptly rolled out new portal changes that caused confusion among organizations. In April, Microsoft rescinded those portal changes after getting complaints. It promised back then to deliver a preview before going live. The aim of the change is to fix the “branding logic” for end users when they use their company portal to access resources at another business, Microsoft had explained back then.

read more
1 2 3 4
Page 1 of 4