If you are an Office 365 administrator, I believe that you have experienced this scenario. The situation when you want to add a domain to an Office 365 tenant, but you cannot because it is blocked by a different tenant .
More specifically, a customer wants you to set up a domain in their current tenant and when you try to add the domain it keeps telling you that the domain is being used already.
We need database so we need SQL Server. How many times have you heard this nonsense? There are many alternatives to traditional relation databases that are more suitable for some use cases. One of them is Table Storage. In this article, I will show you how to test your code that is using Table Storage in your Azure DevOps CI pipeline.
Since 2018 I am playing with Logic Apps. All that time I have been thinking about the best approach for authentication and authorization. There are certain scenarios where the standard approach (OAuth2, basic, static API key) are not ideal. Consider sending REST API call to someone else’s Azure Active Directory. You can use HTTP with Azure AD, but you need to have someone’s username and password, which is not the nice way of doing this.
If you or your customers are running hybrid Microsoft Exchange deployment and you are using Microsoft Graph, you might have noticed that using the client_credentials grant flow doesn’t really work and ends with errors. Last week, we have had a customer who we have been integrating few systems for, and hit the exactly same issue.
Last week, we have hit a really interesting issue with our Linux machines in Azure. We “somehow” (will be explained later in the post) managed to get completely locked out of the machine, not even Serial Console could have been used to login. After bunch of time spent by investigating the situation, we managed to get it resolved.
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.
Imagine you have some tools or a framework you want to share with your company and reuse it on various projects. If you develop your tool in .Net standard, then you are in luck. Creating a NuGet package has never been easier.
Sometimes we need to work with a variable inside a loop section. Whether it’s a precomputation or just a helper variable. Logic Apps allows us to do so. Yet the variable must be initialized on a global level (above all loops).
Here comes the problem:
By default, foreach runs in parallel, in 20 threads (instances). Now, because there is no such thing as mutex in Logic Apps, there is no way how to create a critical section. Critical section is a section only one thread at a time can enter. That results in dirty reads.
We can solve this problem by running the loop synchronously. You can do that by editing settings of the foreach block.
Now only one thread at a time will execute the foreach loop and no other thread will modify our variable while we work with it.
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?