Deprecating UPN based APIs

[tranamst]

As part of increasing the security of the Intune MAM SDK, the UserPrincipalName (UPN) based APIs will be deprecated in October 2024 for the current Xcode15 branch.
The upcoming Xcode16 releases which start in September 2024 will however have absolutely no support for these UPN based APIs.
 
Why should apps not use UPN?
UserPrincipalName (UPN) is an attribute that is an Internet-style login name for a user based on the Internet standard RFC 822. It is not a reliable parameter to uniquely identify a user account.

• It can change overtime.
• Two completely different accounts can be sharing the same UPN.
• In order to avoid inconsistencies relating to UPNs, Intune MAM SDK added a set of new APIs that take in Entra ID User ObjectId which is a unique identifier for the user account as a parameter rather than UPN in v16.0.0 (May 2022).

How will this affect your organization?
You will no longer be able to call the existing UserPrincipalName APIs (The ones where you pass in the user email address/UPN) after the API deprecation deadline. 
It is strongly recommended that app developers start switching to using the Entra ID User ObjectId based APIs in order to avoid missing out future updates when the SDK no longer supports the UPN based APIs in October 2024.
 
What do you need to do to prepare?
Any APIs that previously required the app to send in UPN will have a corresponding ObjectID based API. The parameter will be called accountId for all these APIs.
Few examples:

• Use the ObjectId API - (void)registerAndEnrollAccountId:(NSString *_Nonnull)accountId; instead of - (void)registerAndEnrollAccount:(NSString *_Nonnull)identity;
• Use the ObjectId API - (void)deRegisterAndUnenrollAccountId:(NSString *_Nonnull)accountId withWipe:(BOOL)doWipe; instead of - (void)deRegisterAndUnenrollAccount:(NSString *_Nonnull)identity withWipe:(BOOL)doWipe;
• Use the ObjectId API - (void) remediateComplianceForAccountId:(NSString*_Nonnull) accountId silent:(BOOL) silent; instead of - (void) remediateComplianceForIdentity:(NSString*_Nonnull) identity silent:(BOOL) silent;

What to use for ObjectId?
Here's what you need to send for the Entra ID User ObjectId parameter from MSAL:

• If the sign-in is successful, then MSAL sends back the result in MSALResult object. Use tenantProfile.identifier within MSALResult. This value will need to be used for all the MAM SDK APIs that the app uses for this signed-in account. So the app will have to save the ObjectId from the MSALResult for future usage.

• If you are using the MAM SDK remediation APIs for MAM-CA:

  1. First get the homeAccountId from userInfo[MSALHomeAccountIdKey] within MSALError object sent back by MSAL.
  2. This homeAccountId will be in the format .. Extract the ObjectId value by spliting the string on the . and then use that value for the accountId parameter in remediation API remediateComplianceForAccountId.

• If your app is not handling authentication and you are using loginAndEnrollAccount by passing in the UPN then once the app is managed, you need to get the ObjectId value from the MAM SDK using enrolledAccountId in the IntuneMAMEnrollmentManager. Use this for all the MAM SDK APIs that the app uses for the enrolled account.

NOTE: You will see the deprecation warnings in May 2024 release. Please switch any of these deprecated APIs that you have been using to ObjectId based APIs.
 

[TheFalc0n]

How does this change affect the IntuneMAMUPN key with {{userprincipalname}} value that was required for apps to recognize each other as managed? Is there a replacement for it? Will it still be required?

[wangxiaoms]

IntuneMAMUPN is not being deprecated at this time. However, there is now a IntuneMAMOID setting which should be configured for all applications when the device is MDM enrolled with Intune. This will avoid potential issues in scenarios where two accounts may have the same UPN. More info is available here: https://learn.microsoft.com/mem/intune/apps/app-protection-policies#device-management-types