We have had the group-based licensing option available in preview for over a year. While this service is in preview, it makes provisioning hundreds of users from Active Directory really simple.
You simply create users in your on-premise Active Directory, assign them a valid User Principal Name, add them to the correct group and then sync them with Azure AD Connect, right? Not that fast cowboy!
For quite a long time, we have been running a local service called SkolniLogin.cz which primarily focused on providing SSO experience for various systems at schools (primary and high schools) along with automatic synchronization with the school’s information system. Throughout the time we have hit a lot of edge scenarios, and compiled a best practices guideline.
UPDATE 19/9/18: It has been fixed in 22.214.171.124 version of Plugin Registration Tool https://www.nuget.org/packages/Microsoft.CrmSdk.XrmTooling.PluginRegistrationTool/126.96.36.199
If you use 9.0 version of Plugin Registration Tool to update your assemblies in Dynamics 365 you may encounter the following exception:
ERROR: Occurred while checking whether the assembly exists
The PluginType(00000000-0000-0000-0000-000000000000) component cannot be deleted because it is referenced by 1 other components. For a list of referenced components, use the RetrieveDependenciesForDeleteRequest.
The import of the solution XYZ failed. The following components are missing in your system and are not included in the solution. Import the managed solutions that contain these components (Active) and then try importing this solution again.
If you ever run into this exception and there are all the components already present in the environment you just need to get rid of few lines in a solution definition in the ZIP file you are trying to import.
Do this only if you are absolutely sure that you know what you are doing.
When you have a OneNote notebook shared with an entire group or site in SharePoint (or with few people in OneDrive for Business) you might want to be able to set permissions on a section or section-group level. While this functionality isn’t for some reason available directly from the UI, it is definitely possible. Read on to learn how!
To be honest, managing authentication in Linux for multiple users/admins can be a huge pain. Different companies use various tools – generally, they use a centralized tool to distribute developer’s SSH keys. This can still be a pain, however if the company has Azure AD (or Office 365), why not to use those accounts for authentication?
In previous article, we have looked at the possibility to connect Dynamics 365 on-premise directly with Azure AD, which is on one hand really cool, on the other, it doesn’t provide all the features like mobile apps integration. In this article, we are going to explore a production ready solution by leveraging Active Directory Federation Service and Azure AD as a Claims Provider Trust.
While Dynamics 365’s documentation is full of articles and tutorials about setting it up with Active Directory Federation Services, there is no mention of using Azure Active Directory for Single Sign On. Many replies in communities say that this is not possible, but today we are going to prove them wrong.