Articles

gMSA is a special type of account in Active Directory used for service accounts. It can be used on Windows for services, applications (that support it), or scripts (scheduled tasks). The administrator does not know its strong password, which is changed automatically. We will describe the options for using gMSA within Veeam Backup & Replication (VBR), where it is supported for Application-Aware Processing. We will also look more closely at Guest Processing on Windows and what accounts we need for certain situations.

One day, the Veeam ONE Reporting Service stopped starting without any warning. As a result, most Veeam ONE features stopped working. The cause turned out to be straightforward, a self-signed certificate for the Web API had disappeared from the system certificate store. How this happened could not be determined, but the fix was quick and simple.

In this article, we will look at the various ways to find out which authentication methods a user has registered (available) in their Microsoft Entra ID work account. Authentication methods represent the ways in which users sign in to resources protected by Microsoft Entra. The first part of the article covers the options available to a regular user for viewing their own registered methods. The second part describes tools intended for Entra ID administrators, who can view information about a specific user's methods or obtain a summary overview across the entire tenant.

We have another update on using passkeys for user authentication within Microsoft Entra ID. This is a new way to register (add) passkeys to a Windows computer into Windows Hello. It works for both managed devices (joined or registered to Entra ID) and unmanaged devices. It is currently in Public Preview, but hopefully will reach GA soon.

Microsoft continues to expand the options for using passkeys for user authentication. Since March, new capabilities within Microsoft Entra ID for corporate accounts have become Generally Available. These are passkey profiles assigned to user groups. Instead of a single global setting, we can now configure allowed passkeys more granularly. The second new feature is support for synced passkeys, which are not tied to a single device.

This article describes my experience with replacing Fortinet FortiGate devices that are reaching end of support with new ones. Obviously, we want to transfer the current configuration as simply as possible and achieve minimal downtime during the switchover. We will use the FortiConverter service for configuration migration. The situation is somewhat more complex because the solution is built as a High Availability FGCP cluster with two nodes. Less significant is the use of VDOMs. FortiGate is currently running on FortiOS 7.4.11. The final device switchover went (after prior preparation) very well with only a five-minute outage.

After upgrading FortiAnalyzer from version 7.6.4 to 7.6.6, one FortiGate VM disconnected and was reported as unauthorized. The issue was caused by enforced certificate-based authentication for OFTP connections to FortiAnalyzer (replacing the previously used username and password), combined with an incorrect Common Name in the FortiGate Factory certificate. We will describe three possible solutions to this problem: enabling legacy auth, re-issuing the factory certificate, and using a custom certificate.

Continuing the description of using Terraform (an Infrastructure as Code tool) with the Fortinet FortiOS Provider for automated FortiGate configuration. In this article, we will try creating records on a DNS server running on FortiGate. We will describe a more complex situation where we first import the current configuration and then add new records. There is also an issue with the order of loaded records, which are nested objects of the DNS database. We will handle record sorting, so we will use an alternative option of generating the existing configuration.

We will look at the options for using Terraform to automate the deployment and management of FortiGate devices. Fortinet provides a FortiOS Terraform Provider that enables management of FortiGate and FortiManager through Infrastructure as Code principles. We will demonstrate the basic connection configuration to a device and a practical example of creating a simple firewall policy using declarative configuration.

The principle of Terraform is that it creates (or destroys) defined objects. It stores information in a state file (State) and uses it to detect the difference between the current and desired state. Resources created this way can be modified or destroyed by changing the configuration. If we want to use Terraform to modify resources that were created in a different way, we must import them into Terraform. This is not entirely straightforward. In the example, we will import all VMs from a specific vApp.