In the presentation learn what you need to do in AD FS, Active Directory, and Azure Active Directory to leverage domain joined machines in conditional access policies to O365 services.
Integration and Automation in Practice: CI/CD in Mule Integration and Automat...
Preparing your enteprise for Hybrid AD Join and Conditional Access
1. Azure AD Conditional
Access for O365 Services
Preparing your enterprise for Azure AD Condition Access and Hybrid AD
Join
Jason Condo
DogFood Conference
October 6, 2017
3. Overview
We will discuss Conditional Access and how to use it to protect your
O365 tenant from unauthorized access.
• Why the need for security
• What is Azure AD Conditional Access
• How to configure your environment to enable it use
• What we won’t cover
• Setting up a tenant
• Configuring AAD Connect
• Azure AD Join or BYOD
• Configuration of AAD Conditional Access policies
• Compliant devices or MFA
4. Aren’t logins good enough?
• O365 concerns
• Cloud facing login using domain
credentials
• Once they get a credential, they are
in because many companies expose
other means to access the
enterprise (VPN, Citrix, RDS)
• Once compromised, leverage social
trust and business process to
compromise and steal
6. What is Conditional Access
• One way to provide a control gate to O365 and Azure services without
restricting your users to only connecting through your network.
• Two types of conditional access
1. Claims rules
• through AD FS, Okta, Ping
• Expects all traffic to be private and through claims provider
• More difficult to write claims for all scenarios
2. Azure AD Conditional Access
• Conditions and controls engine
• Platform agnostic, does not require on-prem infrastructure
• AAD CA is easier to configure than protecting through claims rules alone
7. Overview of CA Policy
• With Azure Active Directory (Azure AD) conditional access, you can control how
authorized users access your cloud apps. In a conditional access policy, you define the
response ("do this") to a specific condition ("when this happens").
• In the context of conditional access:
• "When this happens" is called condition statement
• "Then do this" is called controls
• The combination of a condition statement with your controls represents a conditional
access policy.
• Each control is either a requirement that must be fulfilled by the person or system
signing in, or a restriction on what the user can do after signing in.
8. Requirements
• Must have AAD Premium
• (P1 or P2, EMS E3 E5)
• Only applies to O365 resources (not on-premise resources*) Compatible
with Modern Auth applications
• Default is permit all
• Enables access to O365 if no Conditional Access policies exist
• If policy doesn’t apply, user gets through.
• Avoid blocks applied to all user, all service, and/or all devices
• Could lock yourself out of management of your tenant
* you can protect on-premise applications exposed using the Azure AD Application Proxy
9. Conditions built on idea of trusts
• Users
• Trusted Users - User has valid login to
the service (access granted)
• Networks
• Trusted Networks – traffic is being seen
by O365 as coming from a defined
network
• Must be defined
• Be careful to segment internal traffic to
only trusted resources (exclude guestnets)
• Devices
• Trusted PC
• Compliant – ConfigMgr or Intune
• Hybrid Domain Joined PC – Domain Joined
and registered to AAD, AAD Joined
• Trusted Device
• Compliant – BYOD or Enterprise Enrolled
and AAD compatible MDM (Intune,
AirWatch, MobileIron)
10. Azure AD Device Registration (Hybrid AD Join)
• Azure AD Device
Registration is
focused on
providing Single
Sign On (SSO) and
seamless multi-
factor
authentication
across company
cloud applications
• On AD Domain
Joined Windows
clients, provides
seamless access to
cloud applications
and reduced logins
when off-network.
11. Configuring your environment to support CA
• What we will cover:
• Requirements in a federated environment to leverage Hybrid AD Join to enable
devices for conditional access
• Verification of Service Connection Point
• Configuration of your ADFS to register devices
• Configuration of DNS so devices to find where to register
• Configuration of your tenant to enable registration of devices
• Configuration of devices to enable register
• Configuration of GPO to automate registration
• Assumptions
• AD DS
• AD FS 3.0 or higher, published as sts.<your fqdn> internally and externally
• Windows 7 or higher
• AAD Premium (P1 or P2) licensing
• AAD Connect configured (device writeback and password hash optional)
• Single, verified domain in AAD
12. Verify SCP configuration
• Usually configured when AAD Connect is installed
• Only one per domain
• Depending on how you have deployed Azure AD Connect, the SCP object may have already been configured. You can verify the
existence of the object and retrieve the discovery values using the following Windows PowerShell script:
• $scp = New-Object System.DirectoryServices.DirectoryEntry;
• $scp.Path = "LDAP://CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration
Configuration,CN=Services,CN=Configuration,DC=fabrikam,DC=com";
• $scp.Keywords;
• If the service connection point does not exist, you can create it by running the Initialize-ADSyncDomainJoinedComputerSync
cmdlet on your Azure AD Connect server. Enterprise admin credential is required to run this cmdlet.
• More information can be found here:
• https://docs.microsoft.com/en-us/azure/active-directory/device-management-hybrid-azuread-joined-devices-setup
13. ADFS configuration
• When using AD FS, either adfs/services/trust/13/windowstransport or adfs/services/trust/2005/windowstransport must be enabled.
• Verify that AAD Connect is configured to use federation and created the Microsoft Office 365 Identity Platform Relying Party Trust. This has the
needed Issuance Claim Rules.
• This section covers how to configure on-premises federation service to issue claims to support Integrated Windows Authentication for device
registration. The ADFS service must support issuing authenticationmethod and wiaormultiauthn claims when the request is made.
• To do so, perform the following two steps:
• Add an issuance transform rule that passes through the authentication method. You can use the UI to do this:
• In the AD FS management console, go to AD FS > Trust Relationships > Relying Party Trusts.
• Right-click the Microsoft Office 365 Identity Platform relying party trust object*, and then select Edit Claim Rules.
• On the Issuance Transform Rules tab, select Add Rule.
• In the Claim rule template list, select Send Claims Using a Custom Rule.
• Select Next.
• In the Claim rule name box, type Auth Method Claim Rule.
• In the Claim rule box, type the following rule:
c:[Type == "http://schemas.microsoft.com/claims/authnmethodsreferences"] => issue(claim = c);
• Click Finish and OK to save
• On your federation server, in an elevated PS session, type the following PowerShell command to add multi-authentication for integrated windows authentication claims.
* This trust object is created when you integrate Azure AD with ADFS using the AAD Connect wizard
Set-AdfsRelyingPartyTrust -TargetName "Microsoft Office 365 Identity Platform" -
AllowedAuthenticationClassReferences wiaormultiauthn
15. DNS Namespace
• The following DNS namespaces need created reviewed to support
Windows device registration into Azure AD (Workplace join) and
Intune enrollment.
Internal DNS Entry Type Address Purpose
sts A <your AD FS server>
Required for single-sign on (SSO) and points to your
AD FS server(s)
enterpriseregistration CNAME sts
Optional: Required for Workplace Join (device
registration discovery)
Public DNS Entry Type Address Purpose
sts A <your external facing AD FS proxy>
Required for single-sign on (SSO) and points to your
AD FS server(s)
enterpriseregistration CNAME enterpriseregistration.windows.net
Required for Azure Workplace Join (device
registration discovery)
Optional
enterpriseenrollment CNAME enterpriseenrollment-s.manage.microsoft.com
To ease enrollment process of mobile devices
16. Demo
• Confirm your ADFS is configured
for sts. Adjust DNS configuration
as needed.
• Example of external DNS to
support enterprise enrollment
17. Azure AD Configuration
Enable Azure Active Directory Device Registration Service
1. Sign in to the Microsoft Azure portal as Administrator.
2. On the left pane, select Azure Active Directory.
3. Under Manage, Select Device Settings.
4. Select ALL for Users may register their devices with Azure AAD.
• If you have enabled Intune Enrollment, this will already be configured.
5. Select the maximum number of devices you want to authorize per user.
6. Optional: For added security, you may want to Require MFA to join devices.
Note: There is also an option for Users may join devices to Azure AD. This
enables users to join directly to AAD instead of to a domain. This is can be used
for CYOD or BYOD scenarios but not part of this discussion.
19. PC Readiness
• Install the Workplace Join
• Applies to the following OS in federated environment
• Windows 7
• Windows 8.1
• Windows Server 2008 R2
• Windows Server 2012
• Windows Server 2012 R2
• /quiet command line for automation
• Deploy to all non-windows 10 computers that will access O365
• Add to OSD process if you are still deploying older OS
21. Win 10 GPO
• To control the rollout of automatic registration of domain joined computers with Azure AD of Windows 10, you should deploy the
Register domain joined computers as devices Group Policy object to your Windows 10 devices you want to register. For example,
you can deploy the policy to an organizational unit or to a security group.
• To set the policy:
• Open Server Manager, and then go to Tools > Group Policy Management.
• Go to the domain node that corresponds to the domain where you want to activate auto-registration of Windows 10 or Windows Server 2016
computers.
• Right-click Group Policy Objects, and then select New.
• Type a name for your Group Policy object. For example, Automatic Registration to Azure AD. Select OK.
• Right-click your new Group Policy object, and then select Edit.
• Go to Computer Configuration > Policies > Administrative Templates > Windows Components > Device Registration. Right-click Register
domain joined computers as devices, and then select Edit.
• Select Enabled, and then select Apply.
• Select OK.
• Link the Group Policy object to a location of your choice. For example, you can link it to a specific organizational unit. You also
could link it to a specific security group of computers that automatically register with Azure AD. To set this policy for all domain
joined Windows 10 and Windows Server 2016 computers in your organization, link the Group Policy object to the domain.
• Note - This Group Policy template has been renamed from earlier versions of the Group Policy Management console. If you are
using an earlier version of the console, go to Computer Configuration > Policies > Administrative Templates > Windows
Components > Workplace Join > Automatically workplace join client computers.
23. Deployment and Rollout
• When the prerequisites described above are met, domain joined devices are ready to
automatically register with Azure AD.
• Domain joined devices running Windows 10 Anniversary Update and Windows Server 2016
automatically register with Azure AD at device restart or user sign-in. New devices register with
Azure AD when the device restarts after the domain join operation completes.
• Note
• Windows 10 November 2015 Update automatically registers with Azure AD only if the rollout Group Policy
object is set.
• You can use a Group Policy object to control the rollout of automatic registration of Windows 10
and Windows Server 2016 domain joined computers.
• To rollout automatic registration of non-Windows 10 domain joined computers (e.g. Windows
7/8.1), you can deploy a Windows Installer package to computers that you select.
• Note
• If you push the Group Policy object to Windows 8.1 domain joined devices, registration will be attempted,
however it is recommended that you use the Windows Installer package to register all your non-Windows 10
devices including Windows 8.1
27. At the forefront of facilitating productive,
secure communication and collaboration
throughout enterprise.
A regional leader in the technology
community since the pre-beta bits of
.NET 1.0 were released.
Our Business Intelligence team helps
you gain insight into your data and
offers skills that span the range of
the BI landscape, from Self-Service
BI to Enterprise BI to Big Data.
Helping companies migrate,
upgrade, and grow their network
capabilities leveraging Microsoft
technologies.
We help our clients connect discrete
systems to make business operations
and partner interactions more agile.
Assists organizations to visualize, create,
and/or execute a mobility strategy.
Engages all aspects of the customer’s
interaction with your brand, company,
products and services.
We specialize in delivering solutions that
centralize your customer touch points. A
“Customer Hub” that is mobile ready and
cloud enabled.
Bennett Adelson is comprised of 8 practice disciplines
•The registration of Windows current devices is supported in non-federated environments such as password hash sync configurations.
If you don’t run the powershell (Set-AdfsRelyingPartyTrust -TargetName 'Microsoft Office 365 Identity Platform' -AllowedAuthenticationClassReferences wiaormultiauthn) , you will get the following error in the eventlog:
Event ID: 364
Relying Party:
urn:federation:MicrosoftOnline
Exception details:
Microsoft.IdentityServer.RequestFailedException: The requested authentication method 'wiaormultiauthn' is not valid for relying party trust 'Microsoft Office 365 Identity Platform'.
First is making ADFS available outside of organization. STS not a requirement, but is most common.
Important that whatever the DFAS public name, that internal and external use the same
Important that internal is redirected for enterpriseregistrationto the ADFS so that the devices send through ADFS
External use the Microsoft point directly