![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](https://image.slidesharecdn.com/conditionalaccessandhybridadjoin-171006165106/85/Preparing-your-enteprise-for-Hybrid-AD-Join-and-Conditional-Access-13-320.jpg)
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
- 2. Contact Information Jason Condo Practice Director – Advanced Infrastructure Cleveland and Columbus jcondo@bennettadelson.com 216-800-5199
- 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
- 5. Threats getting more prevalent
- 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
- 14. Demo
- 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.
- 18. Demo
- 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
- 20. Demo
- 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.
- 22. Demo
- 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
- 24. Demo
- 25. Demo
- 26. Important Links • Extensive detail on hybrid AD setup • https://docs.microsoft.com/en-us/azure/active-directory/device- management-hybrid-azuread-joined-devices-setup#step-2-setup-issuance-of- claims • Workplace Join 2.1 install • https://www.microsoft.com/en-us/download/details.aspx?id=53554 • Conditional Access Technical Reference • https://docs.microsoft.com/en-us/azure/active-directory/active-directory- conditional-access-technical-reference • Bennett Adelson • www.bennettadelson.com
- 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
- 28. Selected Clients
Editor's Notes
- #13: •The registration of Windows current devices is supported in non-federated environments such as password hash sync configurations.
- #15: 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'.
- #17: 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