Notes from Leverage enterprise identity and authentication (Wednesday, June 24th, 2020)

Notes from Leverage enterprise identity and authentication

Apple has built a number of tools to help organizations leverage identity providers.

Device Authentication

iOS - Shared logins provided by Managed Apple IDs (MAID_
macOS - local, network, or network mobile accounts for logins.

macOS account types:

Local
Network
Mobile

Mobile accounts are a specific kind of network account, which cache the account credentials provided by a directory service.

Network and mobile accounts were how organizations first started using directory services, before iPhones and iPads were available. They existed to help with sharing devices among multiple users, like with computer labs.

For 1 to 1 deployments today, where one person is using one device consistently, Apple recommends using local accounts. The user record is stored on that specific Mac and that Mac is the source of truth for authentication.

The reason for the recommendation is that it avoids login delays and all password management happens locally on the Mac.

For organizations which have traditionally bound Macs to a directory service:

* Consider not binding to a directory service for 1 to 1 deployments.
* Instead, enable directory connectivity with Apple's built-in Kerberos extension, third-party SSO extensions, or other third-party MDM vendor add-on tools.

Using Apple's Kerberos extension:

Allows Mac to get a Kerberos ticket-granting-ticket (TGT).
Grants access to directory resources, like servers and printers.
Keep local accounts' passwords synced with counterpart account in directory service and comply with organizations' password complexity rules.

Where a Mac would need to be bound:

When traversing Distributed File Systems
When using the AD Certificate Payload via MDM

(Note: For Jamf Pro customers, it is possible to get certificates from an Active Directory Certificate Service without needing to be bound. For more details, Google "Jamf AD CS Connector".)

That said, even if the Mac is bound and has an AD machine record stored in the AD domain, this does not mean that a domain account must be used to log into the Mac. Ideally, local accounts would still be used for authentication.

Local accounts:

Offer the best, most reliable experience on macOS
Apple recommends their use whenever possible on macOS.


Network accounts:

Source of truth for authentication is a directory service, like OpenLDAP, Active Directory or Open Directory.
Home folders are optionally stored on a network volume.
Storing data in a network home folder may be challenging, as many modern apps use databases for storing content and loss of connectivity to the database may result in corruption and/or data loss.

Apple views network accounts as being legacy and do not recommend their use. However, they are not deprecated.


Mobile accounts:

A type of network account
More common than true network accounts

Source of truth for authentication is a directory service, like OpenLDAP, Active Directory or Open Directory, but the credentials for the account are cached locally.
A home folder is created locally on the Mac.

Having credentials and home folder cached on the Mac means that the Mac can be used even when the directory service is unavailable. However, because the source of truth for authentication is the directory service, there may be login delays as the result of trying (and failing) to access a directory service.

Additional complexities exist with synchronizing the password, as the password can be changed on the directory service while the Mac is not able to communicate with the directory service. This may lead to password-out-of-sync issues, especially when it comes to FileVault-encrypted Macs, as FileVault used the previous password to generate derived keys to unlock the FileVault-encrypted boot volume. With passwords now out of sync, the OS may be using the latest password to log in while FileVault still requires the keys generated by entering the previous password.

Mobile accounts are supported, but not recommended, for 1 to 1 deployments.

Mobile accounts are appropriate for shared computers, like those found in computer labs, and can be set to automatically delete themselves after a certain amount of inactivity time.


Single Sign-On Extensions

Introduced in iOS 13, iPad OS 13 and macOS Catalina
Enable native app and WebKit authentication

Apple is using an SSO extension internally to authenticate agains their internal identity provider, and third-parties like Microsoft and Okta have introduced them as well for their IdPs.

SSO extensions leverage existing credentials.
Requires MDM management
User interface can be native to an app, web interface or totally transparent to the user.

New features being introduced in iOS 14, iPad OS 14 and macOS Big Sur:

User-channel profile delivery - allows configuration of SSO extensions on the user channel for both macOS and iPad OS (with Shared iPad.)
Improvements to how SSO extensions interact with per-app VPN configurations.
Embedded wildcard matching in the list of matching URLs embedded inside an app.
Additional information is provided to the SSO extension about the app which is calling it.
MDM profile removal also now triggers an operation for any clean-up tasks required by the removal.
Enhancements to the Kerberos Extension


SSO settings configured on the user channel take priority over system-level settings. This change will also allow for easier per-user settings for SSO.

SSO per-app VPN improvements

Associated Domains now work with per-app VPN - 
 * Result is that SSO redirect extensions can now redirect to on-premise IdPs.
 * On-premise IdPs have the same certificate restrictions as Internet-based IdPs, where the certificate needs to be issued by a pre-installed system-trusted certificate authority (CA).

Per-app VPN Excluded Domains - list of domains which are excluded from per-App VPN; for example - allows for direct device-to-cloud IdP traffic instead of routing that traffic over the VPN.

Use MDM to configure domains associated with SSO Extensions.
On iOS and iPad OS, Associated Domains are configured via the Managed App configuration
On macOS, Associated Domains are configured by the managed associated domains profile payload, where the profile is provided by MDM.

Use of associated domains in an app requires an entitlement:

com.apple.developer.associated-domains.mdm-managed

Now public and no longer requires approval from ADC Support.

As of iOS 14, iPad OS 14 and macOS Big Sur:

Apple App Site Association File is no longer directly accessed by the device by default.
Instead, the file is accessed by an Apple-operated Content Delivery Network (CDN) which is dedicated to Associated Domains.

Why? Reduces server load and routes devices to a known-good and known-fast connection.

Additional options available for managed apps and devices on non-internet-facing domains


SSO Extensions - Embedded wildcard matching

Allows matching for multiple customers
Eases setup process for large providers with common URL schemes with slightly different URLs to distinguish between customers or tenants.

Example: If common URL is auth.company.com/CUSTOMER/login, the following wildcard URL could be used:

auth.company.com/*/login


Kerberos Extension:

A number of improvements have been made to the Kerberos Extension.

* Menu extra on macOS more accurately represents the state of the extension
* Extension requires the following:
	- Account credential
	- Active network connection to the directory service
	- Functioning DNS
	- Unexpired Kerberos ticket	

The menu extra will show up as a solid icon if all of the requirements are met. If something is missing, the menu extra is more translucent and will indicate to the user what the problem is.

Extension now also has a customizable UI:
* Help test
* Custom name for identity

Better support for per-App VPN

On macOS Big Sur, the Kerberos extension now supports app-to-per-app VPN.
	- You need to add the App-SSO-Agent and the Kerberos-Menu-Extra to the app-to-per-app VPN profile's payload.

User-channel support enables certificate based Kerberos or PKINIT


Managed Apple IDs (MAID) and Apple Business Manager / Apple School Manager


What are Managed Apple IDs?

Apple user accounts owned and managed by a company, school or institution.
MAIDs are used to provide access to Apple services
Some applications are available only for managed Apple IDs, like ABM and ASM.
MAIDs are also required for Shared iPad
MAIDs can also be generated by Federated Authentication

Federated Authentication identities are provided by Microsoft Azure Active Directory
No additional sign on required.
Automatic account creation

For details on Federated Authentication setup, I recommend watching the session video.

Federated Authentication:

SCIM (System for Cross-domain Identity Management) integration with Azure AD
SCIM integration available for ABM and ASM

SCIM = Allows automatic synchronization of information between an identity provider and a service provider.
Available for all federated organizations

For details on SCIM setup and sync process, I recommend watching the session video.