Secondo evento della community MEM Italiana.
Marco Saracco e Alessandro Baggiossi parlano dei falsi miti legati alla join di macchine Windows 10/11 ad Azure Active Directory.
AD on-prem join • Registered in Azure AD • Needs DC to authenticate users • Users log on with domain account Azure AD Join (AADJ) • Joined on Azure AD • No needs DC to authenticate the users • Users log on with domain account Azure AD Registration • BYOD scenarios • Requires Azure AD User account for access to organizational resources • Users use Local Account or Microsoft account to login
• User can access on-prem resources • User cannot access cloud resources. Hybrid User • User exists on AD database • User synced with AD Connect to Azure AD • User can access on-prem resources • User can access cloud resources Cloud User • User exists only on Azure AD • User can access cloud resources • User cannot access on- prem resources
resources Details: • Azure AD sends user domain information with PRT. • Computer requests a User TGT if it has a line of sight with the DC. • User can access to on-prem resources: • using Kerberos or NTLM • Web app that are configured for WIA https://docs.microsoft.com/en-us/azure/active-directory/devices/azuread-join-sso
Business CAN ACCESS on-prem resources! WHfB must validates Kerberos response from DC: • Kerberos Auth Certificate installed on DCs • CRL Published and available on Azure AD Joined client. • Root/intermediates Certificate installed on AAD Clients. https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base
Account in Active Directory it won’t work. Some examples: - File share with Computer Account grants - WiFi/LAN Authentication with Computer account grants (Radius) - Applications that rely on Computer Account Authentication
Devices are managed through MDM: • Intune Standalone • Intune and ConfigMgr in co- management • Any 3rd party MDM that supports CSP Policies deployments. Remember, only MDM Policies return a feedback status about the deployment.
Authority can be enrolled on MDM managed devices. • Root and Intermediate are deployed via MDM Policies • Certificates can be deployed via MDM Policies using: • SCEP • PKCS https://docs.microsoft.com/en-us/troubleshoot/mem/intune/troubleshoot-scep-certificate-profiles#scep- communication-flow-overview
remote AADJ Device Both PCs must be running Windows 10, version 1607 or later. Your source device must be either: • Azure AD-joined • Hybrid Azure AD-joined • Azure AD registered (from W10 2004) Both source and destination devices must be joined to the same Azure AD Tenant. Bonus: Firewall for domain profile on AAD Joined devices does not exist!
access to AAD Joined devices from anywhere: • First Logon Authentication can be completed without the line of sight with a Domain Controller. (Good with Intune Autopilot process). • You want to provide joining capabilities to workers in remote branch offices with limited on-premises infrastructure (Simple network topology) • No Need for a VPN or being in Corporate Network to receive configurations (MDM Management required).