In 2014, Microsoft announced the Azure Preview Portal, which was going GA in December 2015. Since January 8, 2018, the classic Azure Portal is turned off. The “Preview Portal” was more than a facelift. The classic Azure Portal was based on the Service Management mode, often called the “classic deployment model”, whereas the new Azure Portal uses the Resource Manager model. Azure Service Management (ASM) and Azure Resource Management are both deployment models. The Resource Manager model eases the deployment of complex setups by using templates to deploy, update and manage resources within a resource group as a single operation.
Some days ago, I have implemented one-time passwords (OTP) for NetScaler Gateway for one of my customers. This feature was added with NetScaler 12, and it’s a great way to secure NetScaler Gateway with a native NetScaler feature. Native OTP does not need any third party servers. But you need a NetScaler Enterprise license, because nFactor Authentication is a requirement.
To setup NetScaler native OTP, I followed the availbe guides on the internet.
- NetScaler Gateway 12 Native One Time Passwords (OTP) by Carl Stalhood
- NetScaler native OTP by George Spiers
- Native OTP Support by Citrix
The setup is pretty straightforward. But I used the AD extensionAttribute15 instead of userParameters, because my customer already used userParameters for something else. Because of this, I had to change the search filter from userParameters>=#@ to extensionAttribute15>=#@ .
On January 18, 2018, Microsoft has published KB4074871 which has the title “Exchange Server guidance to protect against speculative execution side-channel vulnerabilities”. As you might guess, Exchange is affected by Meltdown & Spectre – like any other software. Microsoft explains in KB4074871:
Because these are hardware-level attacks that target x64-based and x86-based processor systems, all supported versions of Microsoft Exchange Server are affected by this issue.
Like Citrix, Microsoft does not offer any updates to address this issue, because there is nothing to fix in Microsoft Exchange. Instead of this, Microsoft recommends to run the lates Exchange Server cumulative update and any required security updates. On top, Microsoft recommends to check software before it is deployed into production. If Exchange is running in a VM, Microsoft recommends to follow the instructions offered by the cloud or hypervisor vendor.
I will try to update this blog post regularly!
01-13-2018: Added information regarding VMSA-2018-0004
01-13-2018: HPE has pulled Gen8 and Gen9 system ROMs
01-13-2018: VMware has updated KB52345 due to issues with Intel microcode updates
01-18-2018: Updated VMware section
01-24-2018: Updated HPE section
01-28-2018: Updated Windows Client and Server section
02-08-2018: Updated VMware and HPE section
02-20-2018: Updated HPE section
04-17-2018: Updated HPE section
Many blog posts have been written about the two biggest security vulnerabilities discovered so far. In fact, we are talking about three different vulnerabilities:
Yesterday, a customer called me and told me about a scary observation on one of his Exchange 2016 DAG (Database Availability Groups) nodes.
In preparation of a security check, my customer created a snapshot of a Exchange 2016 DAG node. This node is part of a two node Windows Server 2012 R2/ Exchange 2016 CU7 cluster.
That something went wrong was instantly clear, after the first alarm messages were received. My customer opened a console windows and saw, that the VM was booting.
What went wrong?
Nothing. Something worked as designed, except the fact, that the observed behaviour was not intended.
As part of a bigger Microsoft Exchange migration, one of my customers moved the in- and outbound mailflow to a newly installed mail relay cluster. We modified MX records to move the mailflow to the new mail relay, because the customer also switched the ISP. While changing the MX records for ~40 domains, and therefore more and more mails received through the new mail relay cluster, we noticed events from MSExchangeTransport (event id 1021):
Receive connector Default Frontend EXCHANGE rejected an incoming connection
from IP address 192.168.xxx.xxx. The maximum number of connections per source
20) for this connector has been reached by this source IP address.
192.168.xxx.xxx is the mail relay cluster, which is used for the in- and outbound mailflow.
Microsoft two different logins for their services:
- Microsoft Account (former Live ID)
- work or school account (Azure AD)
Both are located in different directories. The Microsoft account is located in another user database at Microsoft, as a work or school account. Latter are located in a Azure AD, which is associated with a customer. Both account types are identified using the email address. Microsoft accounts are used for service like Skype, OneDrive, but also for the Microsoft Certified Professional portal. Work or school accounts are mainly used for Office 365 and Azure.
In the last months I came across several customers that were in the process to evaluate, or to deploy Office 365. It usually started with a Office 365 trial, that some of the IT guys started to play around with. Weeks or months later, during the proof-of-concept or during the final deployment, the customer had to choose a Office 365 tenant name. That is the part before .onmicrosoft.com.
I had it multiple times, that the desired tenant name was already taken. Bummer. But the customer wants to move on, so the customer decided to take another another name. For example, they added the post code to the name, or a random string. To their surprise, I put my veto on it. They immediately understood why, after I explained the importance of the tenant name.
On November 22, 2017, Ajay Patel (Senior Vice President, Product Development, Cloud Services, VMware) published a blog post in reaction to Microsofts announcement (VMware – The Platform of Choice in the Cloud). Especially these statements are interesting:
No VMware-certified partner names have been mentioned nor have any partners collaborated with VMware in engineering this offering. This offering has been developed independent of VMware, and is neither certified nor supported by VMware.
Microsoft recognizing the leadership position of VMware’s offering and exploring support for VMware on Azure as a superior and necessary solution for customers over Hyper-V or native Azure Stack environments is understandable but, we do not believe this approach will offer customers a good solution to their hybrid or multi-cloud future.
I have wrote about the installation of PowerShell Core in Linux Mint 18 yesterday. Today, I want to show you, how to install Visual Studio Code on Linux Mint 18. The installation is really easy:
- Download the deb package
- Install the deb package
- Run Visual Studio Code
You can download the latest packages for Windows, Linux (deb and rpm, if you want even a tar ball), and Mac on the Visual Studio Code download page. Download the deb file. To install the package, open a Terminal window and run dpkg .
[email protected] ~/Downloads
% sudo dpkg -i code_1.17.1-1507645403_amd64.deb
[sudo] password for patrick:
Selecting previously unselected package code.
(Reading database ... 236413 files and directories currently installed.)
Preparing to unpack code_1.17.1-1507645403_amd64.deb ...
Unpacking code (1.17.1-1507645403) ...
Setting up code (1.17.1-1507645403) ...
Processing triggers for gnome-menus (3.13.3-6ubuntu3.1) ...
Processing triggers for desktop-file-utils (0.22+linuxmint1) ...
Processing triggers for mime-support (3.59ubuntu1) ...
[email protected] ~/Downloads
sudo might ask you for a password. That’s it! Now you can simply start VS Code.After you have installed your favorite extensions, VS Code is ready to code.