Many organizations want to delegate enabling and disabling MFA for a user to their helpdesk, but the only RBAC role that allows MFA management is the Global Administrator and no one wants to grant helpdesk technicians Global Admin access to their tenant. However, there is a way around this RBAC limitation if your organization has Azure AD Premium.
At a high level enabling and disabling MFA will be managed by adding and removing users from a security group. The security group will be included in a Conditional Access policy which defines the MFA requirements.
Admin with Conditional Access administrator role
Helpdesk user(s) with User Administrator role assigned
Have a Helpdesk user create a security group in Azure Active Directory and assign the users your organization wants to require MFA when accessing applications. Make sure to include a descriptive name like MFA Required Users.
Next, have the Conditional Access Admin create a new Conditional Access rule with Assignments target set to the group created by the Helpdesk user.
Next, select the Cloud apps you want to require MFA before allowing access, or select All Cloud Apps.
Next, choose the option to Grant Access and check Require multi-factor authentication.
Finally, Enable the policy and choose Create.
Now, when the Helpdesk (someone with User Administrator Role) needs to enable or disable MFA for a user all they need to do is add (Enable MFA) or remove (Disable MFA) the user from your MFA Security Group.
Duo Labs announced on Feb 27th that it had discovered a security vulnerability in some SAML SSO providers. The outline of their public post showed how an attacker could authenticate so a SAML SSO provider, and then manipulate the SAML response to allow them to impersonate a user based thanks to different canonicalization algorithms.
As you can imagine this raised serious concerns across the IT industry who relies on SAML for Federated Identity and Authentication services.
On March 2nd, following a review of the issue Microsoft announced that our core products, Azure Active Directory, Azure Active Directory B2C, and Windows Server Active Directory Federation Services are NOT affected by this vulnerability. In addition, any services which utilize Windows Identity Foundation (WIF) and/or ASP.NET WS-Federation as their identity middleware are also NOT affected.
I have done a lot of development with SharePoint workflows, especially those developed in Visual Studio. Unless I have been working with a standard list type, I generally create a Content Type that my workflow can be associated with and to ensure the columns and values needed in the workflow will be present. However, creating Content Types is always a painful process, because as you develop the content types and test them you need to delete the original content type, and any list depended up in before you deploy the updated version. This is even worse when you upgrade a solution that is in use in production because you can’t easily delete the content type just to add additional fields.
Recently, I have been working with Publishing Content Types, usually designed through the SharePoint UI, and what I began to notice was that when the published Content Type was updated in the Content Type Hub those changes were reflected in the sites making use of those Content Types.
This made me wonder if the same would happen if I deployed the Content Type through a Visual Studio solution, published it and then updated the Content Type. I initially created a Content Type that had a Title and a Choice column. Once deployed I published the content type and created a list in my Published Content Type Consumer site. I then added an additional text column to the Content Type and redeployed. After the Content Type Hub timer jobs executed the List I created using the Published Content Type now had the new column.
Lesson from this: If you have to deploy and maintain Custom Content Types use a Content Type Publishing Hub to manage the Content Types, and any future updates you may need to make.