How to sync extension attribute from on-prem AD to AAD - and how to use it

ADC syncs a default set of attributes from AD to AAD out of box. To sync extension attributes (the term 'extension attributes' here doesn't refer to "extensionattribute1-15", but rather any attribute that is not included by default by ADC for sync with Azure):

1. Open ADC | Configuration | Customize Sync Options
2. In "optional features", check "Directory extension attribute sync"
3. In attribute select page, check and select what you want to include to be sync'ed

Within Azure AD portal, how to retrieve extension attribute

1. There should be a new app called "Tenant Schema Extension App" , this is where you can find App ID so you can retrieve extension attributes
2. E.g. Creating a dynamic group based on extension attribute
1. when create group rule, select "Get custom extension properties" option
2. In new window, paste in the App ID you copied from step 1, then click on refresh button
3. back to attribute dropdown list, at buttom the new attribute should be available for you to chose. The attribute name is in format similar to "extension_appID_GUID_onPremAttName"

See Also: general concept of extend attribute in AAD

Azure - Places to enable MFA - and special notes about Authentication App as a factor

There are multiple places where you can mandate MFA. Below are the list and the advantages/disadvantages of each place.

• Conditional Access Policy
  
  This method focuses on "access control". It forces MFA based on certain conditions when user is accessing resources. Naturally, this is fit for when you want to have higher level of assurance when certain resources are accessed
  
  
• Identity Protection\MFA registration policy
  
  This place is to force users to register MFA rather than define when to use
  
  
• Sign-in risk policy
  
  Force user to use MFA base on risk detected. What considered as "risky" is determiend by MS algorithm that is not disclosed. Factors include unusual logon behavior, unusual location etc.
  
  
• Security Default
  
  This is a heavy hand approach. "Security Default" enforces a bunch of best practices tenant-wide along with MFA requirement.

Places you define what factors you can offer to users for registration, and how each factor should behave

• Legacy
• AAD | Security | Multifactor authentication | additional cloud-based MFA settings
• AAD | Password Reset | SSPR Policy (if used, only for SSPR)
• New
• AAD | Security | Authentication policies (how each factor should behave )

Besides the above 4 approaches to require MFA, it can also be registered on per-user basis in AAD portal. To improve Authenticator registration rate among users, you can create a registration campaign under "Security | Authentication methods | Registration campaign"

Special notes about registering Authenticator App as a factor:

When doing a per-user registration, other form of factors (SMS, voice call) can be assigned to users in AAD portal, but Authenticator App can only be registered by user himself in "my account" portal

How "Authentication Context" Works in Azure

 First of all, let's just say "Authentication Context" has little to do with authentication, not sure why MS picked such a misleading name. It's really a labeling system to give content owner more control over what should be protected, and how.

1. Create the context
   It's a label can be defined in AAD | security - in here, everything is just a text tag. It has no meaning now until after you use it in a Conditional Access Policy
2. Link the "auth context" created in step 1 to a "sensitivity label"
   "auth context" created above will be shown as an option for you to choose from in your Sensitivity Label'| site setting | "Define external sharing and device access settings" page, there is an option called "Use Azure AD Conditional Access to protect labeled SharePoint sites", under which you will see the label you created in step #1
3. Link the context to an access policy
   Create a conditional access policy targeting this label (traditionally you can only target applications, user actions, but now you can target a tag/label)
4. How everything works together
   For documents with the abovementioned sensitivity label, its access settings -> context name -> access policy in scope for the context
5. This way, the level of protection is not limited to be defined only by Azure admin, but by content owner as well.
   In other words, Azure AD admin defines a protection option, content owners decide if they want to use that option themselves (by enabling the label) (compare to the old way where Azure admin push down a policy for all things in scope)