If you use Azure SQL Server and you care about security, then it definitely makes sense to give users access via their Azure Active Directory account. Azure AD supports multi-factor authentication, identity protection and a lot of other security features which makes it much more secure than using a connection string.
The first thing to configure is the Admin access via Azure AD. That’s easily doable via the Azure Portal:
- Navigate to your Azure SQL Server (not the Database!)
- Open the Active Directory Admin settings:
- Go to Set Admin and configure your user. I suggest to configure a group as it gives you more flexibility
If you join devices to Azure AD, then you can see that each device has an owner. The owner is the user who joined the device to the Azure AD which is sometimes the account of the administrator. That’s why one probably wants to change the owner which is unfortunately not possible via the Azure portal. But, as usual, you can easily do it via PowerShell.
The main commands you need are:
Get-AzureADDevice # returns all device
Get-AzureADUser # returns all users
# add new device owner
Add-AzureADDeviceRegisteredOwner -ObjectId [DeviceObjectId] -RefObjectId [NewOwnerObjectId]
#remove previous device owner
Remove-AzureADDeviceRegisteredOwner -ObjectId [DeviceObjectId] -OwnerId [PreviousOwnerObjectId]
I created a simple script which has device name and new owner as input and simply does the job:
There are many reasons why someone wants to forward all incoming mails from a domain to a specific address. One use case is by sure testing. If you test an application, then you probably need a lot of mail addresses. To avoid creating all the mail addresses, you could use tools like postfix for it. But it also requires some setup and configuration.
I am Office 365 user and I love it and by sure, I want to solve this issue with Office 365. I tried it and it took some time, but then I found the right setup.
So, what I want to achieve is simple:
All mails sent to @tst.axr.at should be forwarded to a shared mailbox, where all testers have access (or to specific address).
Sounds simple and you can easily configure it in Office 365, but there are a few pitfalls, that’s why I created this blog post. So let’s go through it step by step.
You probably think about using Microsoft Azure to host your WordPress blog. Azure gives you great scalability features that are important if you want to scale up your website. There are also many other services that could be useful for your blog. I created a new WordPress blog in Azure and want to describe in this blog post, which steps I performed and what it needed to set it up to get a full up and running Azure blog.
Before creating the new WebApp required for the wordpress blog, I suggest to create the resource group at first. If you do this manually, then you can decide the location of the resource group, if you just create the web app and create the resource group during that step, the default location is US.
+ Create a resource – “Resource group” – set the properties and done
Azure key vault is a service to store and manage keys, secrects and certificates that you can use for your applications. In this blog post I want to quickly show how to create a key vault and how to use it.
Key vault is a secure key management service that allows to manage keys, application secrets and certificates. The keys are stored in hardware security modules (FIPS 140-2 Level 2) and even Microsoft does not see them. Pretty cool stuff, so why should someone use Azure Key Vault?
A common problem is how to manage keys and secrets for your applications? Where to store them? And how to ensure that they have a defined lifetime? Azure key vault allows to achieve all these things. A few features are:
- Save keys in Azure in a safe place
- Keep encryption keys in hardware security modules (FIPS140-2 Level 2+)
- Control keys from a single place
- Control lifetime and renewal of keys
- Let other AD users/groups manage access to secrets
- Access keys from your applications
- Automatically rotate keys
It especially helps you to solve the issue of storing keys/secrets for your applications. If you develop an application – where do you put e.g. storage keys or other secrets? Sometimes developers hardcode them into the code. Other developers store them in the configuration (e.g. app.config) and just a few use something like azure key vault.
Ok, but what is a key vault? A key vault is a container for keys and secrets that are managed together. If you develop an application, then it makes sense to create one key vault per application because the access control and also the billing is per key vault. If you have all keys/secrets stored in one key vault, then each user that has access to that key vault can read all keys/secrets that in the key vault. So you should definitely create one key vault per application. As a key vault itself is for free, this shouldn’t be a problem and helps you to secure your stuff. The pricing for key vault is pay per usage of keys (see: Key Vault Pricing Details).
The key vault allows you store:
- Key: A cryptographic key (RSA 2048) that you can use to decrypt/sign with the key
- Secret: A secret is a sequence of bytes unter 25KB – for example a connection string, PFX file, AES encryption key.
This blog post is a quick walk-through and will show how to use let’s encrypt certificates with Azure WebApps. As prerequisites I assume that the following things are done:
- App Service and WebApp is already up and running
- App Service is at least B1 (pricing tier Basic 1)
- A custom domain is already configured
There are 3 main steps that I will describe in this post:
- Add service account and application to Active Directory
- Add the let’s encrypt site extension
- Force https (optional)
I already blogged about Azure functions, the billing API and a few other things. In this blog post, I’ll combine some of my previous blog posts to build an Azure function that creates a weekly billing report of an Azure subscription. To build this solution, the following steps are required:
- Create an Azure function
- Configure the CRON schedule for the Azure function
- Read data from the Azure Billing API
- Create a HTML page with the billing data
- Send the report via email
To implement it, I’ll use Visual Studio 2017, C# and the AzureBillingAPI NuGet package that I created.
The final solution can be found on GitHub: https://github.com/codehollow/AzureBillingFunction
Last month I wrote a blog post with a short introduction to Microsofts Recommendation API (Introduction to Microsofts Recommendation API). I wrote about the basics, how to start and how to work with this nice API which is part of the Microsoft Cognitive Services.
When I started to work with the recommendation API, I soon realized that the most important thing is – Data! Okay – no surprise – but how to get the data? Or how to create some test data if you just want to try it?
In my previous blog post, I mentioned that I used a tool to create my (test) recommendation data. The tool was a quick and dirty, self-hacked WCF application, but it worked and I had some data to start.
Today I spent some time to explore the Microsoft Recommendations API. This API is part of the Microsoft Cognitive Services and it allows to show related articles – something like “people who are interested in A are also interested in X,Y and Z”. This can be useful for web shops or blogs but also to see related items/interests.
In this blog post, I’ll:
- Create the cognitive service and the recommendations API
- Create and upload some test data
- Build a model
- Use that model
Create the recommendations service
The recommendations service is part of the cognitive services and can therefore be found as cognitive service in the Azure portal. Just create it with your preferred pricing tier.
This post is a short note on how to use SSH with Windows Powershell. I will quickly describe three ways: OpenSSH, Posh-SSH and Putty. I found a few blog posts about how to use SSH with Powershell and most of them are referring Posh-SSH. Posh-SSH is nice, but I think OpenSSH is much easier to use because it works the same way as the ssh command in linux.
Open SSH for Powershell
If chocolatey is not yet installed, you must at first install it. Run the Powershell as administrator and execute:
iwr https://chocolatey.org/install.ps1 -UseBasicParsing | iex
If chocolatey is already installed, run the Powershell as administrator and execute the following command to install OpenSSH, to reload the environment variables and to connect to a client:
choco install openssh # installs open ssh
refreshenv # reloads the environment variables
ssh remoteClient -i "MyKeyPair.pem" # connects to remoteClient via ssh