Version Affected: [24.04+]
Description:
When migrating to new servers, FIDO2 AAGUID enrollments will be handled differently, depending on the restrictions and original enrollment method.
Resolution:
When upgrading/migrating IdP, as long as the domain name remains the same, users will not need to re-enroll. However, if device permission granularity by AAGUID is newly enforced in a newer IdP version where only specific iCloud Keychain AAGUIDs (managed/standard) are allowed, with all-zero AAGUIDs being disallowed, this will result in all enrollments with an attestation of "none" being disabled (including the all-zero AAGUIDs from Apple devices). Users with these specific existing enrollments will have to re-enroll.
Without having an AAGUID that is not all-zero, IdP is unable to discern which passkey provider the enrollment came from.
Special Considerations:
The AAGUID reported to the IdP is decided by the authenticator being used. For Apple devices such as Mac devices, the authenticator typically reports an all-zero AAGUID (00000000-0000-0000-0000-000000000000), even when the user selects direct attestation. This is due to Apple using Anonymous CA attestation that is not in the MDS.
SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.
Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.
Comments
Please sign in to leave a comment.