When you are managing services which deal with customer’s data, sensitive information etc. you should never allow users to directly access the data. Instead, you should use some privileged identity management solution. In this article, we are going to look into how to implement this on our own with the use of SharePoint and Microsoft Flow.Continue reading “Just In Time Access with SharePoint and Microsoft Flow”
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!
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.