it security list

How to Put Out Fires Before They Start or General Principles of IT Security

Having examined the effect of the WannaCry and Petya viruses and how the attacks affected our customers, we would like to share our findings and give general cybersecurity recommendations. These tips will be especially helpful for Windows system administrators as we know they have suffered due to these viruses.

Server protection:

  • The Active Directory forest must be at least 2012 R2, and users must be in a protected user group. This prevents passwords from being intercepted using Mimikatz;
  • Shared file access must be implemented through a versioning system or snapshots, e.g. Sharepoint + OneDrive for Business;
  • Secure Boot must be enabled on hypervisors, so cryptolockers will fail to start instead of the native OS;
  • Email server settings must prohibit receiving executable files and corrupted archives. As an extreme measure, you could change the email format to plain text to eliminate links in the message body;
  • Updates must regularly be installed at least once every two weeks. Regularly update the servers’ OS, drivers, and firmware. This is one of the most important information security measures that will considerably strengthen your protection. You must have a clear update plan with the date of the latest update and who performed it;
  • Locate the backup system outside of the current environment. Configure replication to the backup site.


  • Client computers must run Windows 10 LTSB. The LTSB version has fewer potentially dangerous components and, theoretically, does not spy on users, though disabling telemetry is still a good practice;
  • Enable UEFI and Secure Boot. Like with the servers, these precautions will prevent ransomware from running instead of blocking the native OS. The Petya virus reboots the machine to start encryption. The two settings will prevent this. There is a large chance that future cryptolockers will use this strategy;
  • Automatically update not only the operating system, but also all applications, especially MS Office. It does not matter if you use WSUS or update directly from Microsoft servers. This paragraph requires no explanations. The servers should be updated manually with proper supervision to avoid downtime, while workstations should be updated automatically;
  • System administrators should not work on workstations using domain administrator rights;

General recommendations:

  • Separate the working environment from web surfing, and separate different company’s departments into isolated environments, for example, as demonstrated here;
  • Separate the infrastructure environments using VLANs with traffic filtering in between. In this case, blocking access to certain ports can stop malware from spreading through the network. In the case of Petya, to prevent the ransomware from spreading, outside access to TCP ports 135, 139, and 445 (the ports used for SMB and WMI services) must be blocked;
  • It is advisable not to use server software that requires network access to shared folders. Business software, such as 1C must be on SQL Server;
  • Workstations and servers must have a network filter configured to block outbound access to any applications except those required. Detailed information on how and why to do this may be found here;
  • Disable SMBv1 and, if possible, SMBv2 on workstations and servers;
  • Specialized and rare programs like M.E.doc Internet banking (especially Java applications), should run on a separate virtual machine with a strong firewall;
  • Don’t rely on antivirus software, which creates a false sense of security. Consider the latest viruses and how the leading manufacturers responded: even the standard Windows Defender was one of the first to be updated.
  • Help your IT personnel get technical certifications. Choose an outsourcer with valid certifications in the professional areas you need;
  • Conduct training and other activities to increase the level of IT awareness among all your employees; provide examples of real-life security breaches and demonstrate potential consequences.

More articles about IT security

azure mfa for rdg

Remote Desktop Gateway client two-factor authentication via Azure Multi-Factor Authentication

Users and Security Methods

Typical users have a lightminded attitude for password security. Our experience shows that even if a company uses strict policies, provides user training, etc., unencrypted devices still make their way outside the office. Review the product list of a well-known company, and you will understand that cracking passwords for unencrypted devices is only a matter of time.

In order to control cloud access from these devices, some companies block remote access by setting up tunnels between the cloud and the office. We believe that this is not the optimal solution. First, you lose some advantages of cloud solutions. And secondly, as noted in the article, there are productivity issues.

Using a terminal server and Remote Desktop Gateway (RDG) is more flexible, because you can set up a high level of security. This method lets you prevent transmitting data from the cloud, and you can simultaneously impose limitations on a user’s work. However, this doesn’t solve the problem of authentication, which is a DLP solution.

Two-factor authentication is probably the best way to guarantee that an intruder doesn’t work under a user’s account. The MFA setup provided by Microsoft and Google for client VPNs is a good choice, but 1) it requires CISCO ASA, which is not always easy to implement, especially in budget-conscious clouds and 2) working via a VPN is inconvenient. Working with a terminal session via RDG is significantly more convenient, and the SSL encryption protocol seems to be more universal and reliable than a CISCO VPN.

There are many solutions for a terminal server with two-factor authentication. For example, here is a free solution . Unfortunately, this solution does not work via RDG.

The advantages of the Microsoft Azure Multi-Factor Authentication Server (MFAS) are described in the article mentioned above, so I won’t repeat them here. Instead, let’s directly with the settings.

To keep this article short, we will skip the process for initial installation and configuration of the RDG server that authorizes users based on a username and password.

For clarity, we will outline the RDG request authentication scheme used by Azure MFA. The Network Policy Server (NPS) role is started on the RDG server, making it possible to redirect Radius requests. The MFA server will be deployed on a separate virtual machine in the company’s internal structure.

The RDG server requests authorization from the MFA server. MFA calls, sends an SMS, or sends a request to the mobile application, depending on the chosen authentication method. The user then confirms or rejects the access request and the MFA server returns the result of the second authentication factor to the RDG server.

For clarity, we will outline the RDG request authentication scheme used by Azure MFA. The Network Policy Server (NPS) role is started on the RDG server, making it possible to redirect Radius requests. The MFA server will be deployed on a separate virtual machine in the company’s internal structure.

rdg request authentication scheme

The RDG server requests authorization from the MFA server. MFA calls, sends an SMS, or sends a request to the mobile application, depending on the chosen authentication method. The user then confirms or rejects the access request and the MFA server returns the result of the second authentication factor to the RDG server.

Azure Multi-Factor Authentication Server setup and installation

Creating an Authentication Provider in the Microsoft Azure Portal

Sign in to Microsoft Azure (the account must have a subscription or trial version) and find Multi-Factor Authentication (MFA).

For now, there is no MFA management in the new version of the Azure portal, so the old version will open.

To create a new multi-factor authentication provider press “Create ->Application services -> Active Directory -> Multi-factor authentication provider -> Quick start”. Specify the name and usage model.

The form of payment depends on the usage model: either based on the number of users, or based the number of authentications.

create mfa provider

Once created, MFA will be displayed in the list. Next, go to Control by clicking the corresponding button.

azure active directory

Go to “Downloads” and download the MFA server.

download mfa server

Deploying the MFA server

You must install the MFA server on a virtual machine separate from the RDG server. MFA supports OSes older than Windows Server 2008 or Windows 7. Microsoft .NET Framework 4.0 is also required.
These addresses should be accessible on port 443:


While installing the MFA server, do not use the setup wizard.

On first launch, you must enter credentials that need to be generated on the server’s load page.

mfa credentials

Next, add users. Go to “Users” and click “Import from Active Directory,” then select users to import.

mfas add users

mfas add users

If needed, new users can be automatically added from AD:

“Directory Integration -> Synchronization -> Add”. This process can also add a directory that will be automatically synchronized at a specified time interval.

new users added from AD

Test that the MFA server is working correctly. Go to “Users”. Specify the phone number (if not already set) and select the authentication method “Phone Call”. Click “Test” and enter the username and password. MFA Azure will call the phone. Answer and press #.

test MFA server

Configuring the MFA server to work with Radius requests

Go to “Radius Authentication” and check “Enable RADIUS Authentication”.

Add a new client and specify the IP address of the NPS server and the shared secret. If authentication needs to be performed for all users, check everyone (in this case, all users should already be added to the MFA server).

You also need to confirm that the ports specified for the connection correspond to the ports indicated on the NPS server and are not blocked by the firewall.

enable RADIUS Authentication

Go to “Target” and add the Radius server.

add radius server

Note: If there is no central NPS server in the network, the Radius client’s and Radius server’s IP addresses will be the same.

Configuring RDG and NPS servers to work with MFA

The Remote Desktop Gateway must be configured to send Radius requests to the MFA server. To do this, open the RDG properties and go to the “RDG CAP Store” tab. Select “Central server running NPS” and specify the MFA server address and shared secret.


Next, configure the NPS server. Expand the “Radius clients and servers -> Remote Radius server groups” section. Open “TS gateway server group” properties group (this group is created when you configure the RDG server) and add the MFA server.

When adding the server, increase the server timeout limits on the “Load Balancing” tab. Set the “Number of seconds without response before request is considered dropped” and “the Number of seconds between requests when server is identified as unavailable” in the range of 30-60 seconds.

In “Authentication/Accounting”, check the accuracy of the specified ports and set the shared secret.

Edite Radius Authentication/Accounting

Edite Radius Authentication/Accounting

Go to “Radius clients and servers -> Radius clients” and add the MFA server by entering a “Friendly name”, address, and shared secret.

edite radius clients

Next, go to “Policies -> Connection request policies”. This section should have the policy created during configuration of RDG. This policy directs Radius requests to the MFA server.

Copy the policy and open its settings. Add a condition comparing “Client Friendly Name” with the “Friendly name” specified in the previous example.

copy policy properties Radius

On the “Settings” tab, replace the Authentication service provider with a local server.

policy properties settings Radius

This policy will guarantee that when you receive a Radius request from the MFA server it will be processed locally and prevent request loops.

Check that this policy is placed above the original policy.

network policy server

For now, the RDG and MFA link is ready. The following steps are necessary for those who want to authenticate via a mobile app or let users access several multifactor authentication configurations through the user portal.

Installing the SDK, mobile app web services, and user portal

The connection to these components is made via HTTPS. Therefore, you must install an SSL certificate on the server where they are deployed.

The user portal and web-service mobile app use the SDK to communicate with the MFA server.

SDK installation

The SDK is installed on the MFA server and requires IIS, ASP.NET, and Basic Authentication, which must be installed beforehand using the Server Manager.

To install the SDK, go to “Web Service SDK” in “Multi-Factor Authentication Server” and follow the instructions of the installation wizard.

SDK installation

Mobile app web-service installation

The following service is necessary for the mobile app to interact with the MFA server. For the service to function properly, the computer it is installed on must have Internet access and an open 443 port to connect to the internet.

The service installation file is located in C:\Program Files\Azure Multi-Factor Authentication on the computer with MFA installed. Run the installer and follow the installation wizard. For convenience, you can replace the name of the virtual directory “MultiFactorAuthMobileAppWebService” with a shorter one.

After installation, go to C:\inetpub\wwwroot\MultiFactorAuthMobileAppWebService and change the file web.config. In this file, you need to specify the WEB_SERVICE_SDK_AUTHENTICATION_USERNAME and WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD parameters that correspond to the “PhoneFactor Admins” security group. This account will be used to connect to the SDK.

Mobile app web service installation

In the same file, indicate the URL where the SDK is available.

Note: The connection to the SDK is made via the SSL Protocol, so you must reference the SDK by the server name (specified in the SSL certificate) rather than an IP address. If a call is made using a local name, you must add a corresponding entry to the hosts file in order to use the SSL certificate.


Add the URL where the mobile app web service is available to the Multi-Factor Authentication Server app in the Mobile App tab. This is necessary to properly generate a QR code in the user portal in order to connect to mobile apps.

You can also check “Enable OATH tokens”. This lets you use the mobile app as a software token to generate time-based one-time passwords.

User Portal Installation

Installation requires IIS, ASP.NET, and the IIS 6 Metabase Compatibility role (for IIS 7 or later).

If the portal is installed on the MFA server, just go to the “User Portal” in the Multi-Factor Authentication Server, press “install,” and follow the installation wizard. If the computer is joined to a domain, a user belonging to the PhoneFactor Admins security group will be created during installation. This user is required for a secure connection to the SDK.

user portal installation azure mfa

When installing on a separate server, copy the installation file from the MFA server (the installation file is located in C:\Program Files\Multi-Factor AuthenticationServer). Perform the installation and edit the web.config file located in C:\inetpub\wwwroot\MultiFactorAuth. Change USE_WEB_SERVICE_SDK from false to true. Specify the credentials for the account in the PhoneFactor Admins group in the WEB_SERVICE_SDK_AUTHENTICATION_USERNAME and WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD parameters. Specify the URL of the SDK service, and don’t forget to correct the hosts file, if necessary, to make the SSL protocol work.

In the “User Portal” section, add the URL at which the user portal will be available to the Multi-Factor Authentication Server application.

Demonstration of using Azure MFA to authenticate RDG connections

We will consider what MFA does from the user’s perspective. In our case, the second authentication factor will be a mobile app, since cellular networks have a number of vulnerabilities that allow for easy interception of calls and texts.

First of all, the user must log in to the user portal, provide his or her phone number (if not specified in AD), and sync his or her account to the mobile app. Log in to the portal with your own account and answer the security questions (in case we need to recover access to the account).

MFA user log in

Then, select the authentication method (in our case, mobile app) and press “Generate New Activation Code”. A QR code will appear that must be scanned in the mobile app.

generate-new activation code azure mfa

Because PIN authentication was used when importing users to the MFA server, you will be asked to create a PIN code. Enter the desired PIN code and click “Authenticate”. Confirm the request in the mobile app. After taking these steps, you have an app linked to the account and full access to the portal in order to change personal settings.

change personal settings azure mfa

Note: The list of settings that the user may change through the portal is specified by the administrator in the Multi-Factor Authentication Server app.

Next, we will look at connecting through the RDG.

Create an RDP connection by specifying your RD Gateway and connecting.

RDP connection

RDP connection

Enter the credentials to access the RDG server.

credentials access RDG server

Confirm the request in the mobile app.

RDG server mobile-app

Enter the credentials to sign in on the local PC and wait for a connection.

credentials local PC

credentials local PC

Note: If the phone is equipped with a fingerprint sensor, the Authenticator application will prompt you to associate the PIN code with a fingerprint to subsequently authenticate by simply touching the phone.

Authentication methods offered by Azure MFA:

  • Phone call
    • press #
    • enter the PIN code and press #
  • SMS – you can use OTP or OTP + PIN
    • One-Way – while authorizing, enter the received code into the auxiliary field
    • Two-Way – send the received code back by SMS
  • Mobile app
    • Simple confirmation
    • You must enter the PIN code to confirm
  • OATH token – you will need to enter the code from the token screen into the auxiliary field when authorizing. You can use the mobile app as a software token.

The SMS One-Way and OATH token methods are not universal, since they require an auxiliary field for entering the code during authorization.

In conclusion, we will tell you about an MFA function that lets you track and protect against intruders who attempt to gain access without having the second authentication factor.

In the MFA control panel on the Azure portal, you may enable users to mark an incoming request as fraudulent. It is also possible to automatically block the user when receiving this message and send an email notification to support.

Azure MFA control panel

After enabling this function, users who have blocked the authentication request will receive a message asking them to notify support about an unauthorized login attempt.

MFA control panel

MFA control panel

The Azure MFA control panel has a report that shows fraud notifications:

Azure MFA control panel

If you need to find out the IP address from which an RDP session was initialized, look at the RDG server logs in the Event Viewer. If the second authentication factor was not passed, the event will have an “Error” status, and the description will indicate the IP address from which the RDP connection was established.

RDG server logs Event Viewer

Remote Desktop Gateway and Azure Multi-Factor Authentication Server using RADIUS
User Portal
Mobile App Web Service

Best regards,
The Servilon Team

More articles about two-factor authentication

Ferma VDI

Installing a white certificate on a Microsoft VDI farm

Many companies using VDI infrastructure for remote work from the uncontrolled personal workstations of the company’s employees. External users face the problem of distrusting the certificate issued by the corporate certifying authority when publishing a VDI farm to the Internet. As a result, security warnings appear when connecting remotely.

RD Connection

In this case, the warning appears twice: at the first connection the broker server is untrusted; at the second connection, the VDI farm virtual machine is untrusted.

To resolve this problem, many system administrators suggest either checking the “Don’t ask me again” checkbox and ignoring this message, or “whitelisting” the root certificate on user’s remote computer and publishing the corporate CA’s CRL. However, such methods don’t work if users connect from different locations each time or connect to different virtual machines.

Solving this problem requires you to use a “white” certificate issued for the VDI farm by the trusted certificate authority. The names of the external certificate and the VDI computers must match.

The solution

First of all, we need a wildcard certificate (* issued by the trusted certificate authority.

Add a new DNS suffix to the domain:

Add a new Active Directory Integrated zone ( to serve internal requests for new server names and VDI farm virtual machines on a domain controller in DNS.

To have an additional domain suffix in a domain you have to edit the msDS-AllowedDNSSuffixes attribute at the domain level. You must add the internal and external domain names as the attribute value. For example, yourcompany.local and Create a new group policy at the domain level to specify the DNS suffixes that can be added to short names in DNS queries.

edit msDS-AllowedDNSSuffixes attribute

Enable the following policy: Computer Configuration \ Policies \ Administrative Templates \ Network \ DNS Client\ DNS suffix search list. Then add the internal and external domain name values, separated by commas.

DNS suffix search list

Setup certificate for RD server

You also have to change the DNS suffix of the planned RD servers to the external domain name before creating the VDI farm. Go to system properties and click “Change…”. Click “More…” on the “Computer Name/Domain Changes” tab and enter the new primary DNS suffix –

Computer Name/Domain Changes

Next create a new VDI farm based on the selected Microsoft Windows Server 2012 R2 servers. You can easily find information online about how to do this.

After you receive the certificate’s pfx file, you can install it on the new VDI farm. On the RD Connection Broker server, go to Server Manager > Remote Desktop Services > Overview. In the Deployment Overview field, select Edit Deployment Properties in the Tasks dropdown list.

RD Connection Broker server edit

Open the Certificates tab and set up the necessary * certificate for each farm service.

Add the certificate for each service role. Click “Select an existing certificate…”, then specify its file path and password.

RD Connection Broker server

In the end, the following certificates will be installed on the VDI servers, but not on virtual machines. The SSLCertificateSHA1Hash REG_BINARY parameter appears with the thumbprint certificate value in the registry on Connection Broker server at the following path:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp.

This parameter determines which certificate will be used while the RDP session is being established. Add it to the registry on the client machine as well.


Installing the certificate on virtual machines

The following are required when using a white certificate on virtual machines:

  • Install the certificate in the personal certificate store on every machine.
  • Set the certificate key read permissions for each machine’s Network Service.
  • The SSLCertificateSHA1Hash REG_BINARY certificate parameter must have the thumbprint value.
  • Virtual machines names must match the certificate name (have the suffix)

Create a new group policy at the Organizational Unit level, dedicated to the VDI farm’s virtual machines’ accounts.

This policy must run Startup Script ExportVDICert.bat on the virtual machines.

Startup Script ExportVDICert.bat

The script below uses the Microsoft Certutil and FindPrivateKey utilities. Certutil is a built-in utility. FindPrivateKey is provided as a Sample tool for developers and can be compiled independently. The script must be added to the policy.

The certificate and FindPrivateKey utility must be placed in the network folder where the script will grab the installation files. Here’s the script:

certutil -f -p “” -importpfx “” NoExport


mkdir “c:\TempCertSecurity”

cd c:\TempCertSecurity”

xcopy “” “c:\TempCertSecurity”

FindPrivateKey.exe My LocalMachine -t

-a > tmp.txt

set /p myvar= < tmp.txt del tmp.txt del FindPrivateKey.exe cd \

rd “c:\TempCertSecurity”

cacls.exe %myvar% /E /G “NETWORK SERVICE”:R”

This script will install the new certificate with permissions after the virtual machine is rebooted.

The next part of the policy has to do with the SSLCertificateSHA1Hash installation option. The required key is configured via Preferences \ Windows Settings \ Registry

SSLCertificateSHA1Hash installation option

To change virtual machines’ Primary DNS Suffix in the policy in a central way, enable the Primary DNS Suffix and set as the external domain name.

Primary DNS Suffix

The machine will receive the new FQDN and corresponding white certificate after being rebooted. After you perform all these operations, your users will no longer see the annoying security alerts.

MFAS as a Second Authentication Factor

How to Configure Microsoft Azure Multi-Factor Authentication Server (MFAS) as a Second Authentication Factor

Why MS Azure?

  1. Best AD integration, which is very convenient when the same VPN account is used for multiple resources.
  2. Different types of authentication: phone call, SMS or offline OTP code.
  3. Ease of configuration.
  4. High reliability and trust.

As for the downsides, the only thing worth noting may be that it is a paid solution, but security has never been cheap.

Microsoft Azure Configuration

The steps below assume that you have a subscription or you have installed a trial version of Microsoft Azure.

Let’s move directly to the setup process:

  • 1. Log on to the Azure active directory
  • 2. Click on the Active Directory tab -> Multi-Factor Authentication Providers -> select Quick Create. Specify the necessary parameters and click active directoryAfter the creation provide has been created, the “Manage” button will be available; select it:
  • 3. Go to Downloads. Download MULTI-FACTOR AUTHENTICATION SERVER. You also need to create an account to activate the active directory

.NET Framework 2.0 is required to install this server.

Important: We recommend installing on a separate VM. Skip the configuration wizard during installation.

Server Features: user synchronization with AD, RADIUS server for Cisco ASA, submission of authorization requests by the second factor, reception and processing of client responses, user authentication. It can be installed both on server and client versions.

  1. When starting the first time, activate using the previously generated account (we do not need replication at this stage).
  2. Set up user integration between AD and our server. In the Directory Integration tab, add a directory that will sync with AD and configure the synchronization settings:

azure add syncronization item

mfa server

In AD, create a user and synchronize the user database with MFAS:

  • a) Create a test user and enter a phone number:mfa server edit user
  • b) Save, click the “Test…” button in the “Users” tab. Enter the user credentials:mfa server test user
  • c) After receiving the phone call at the specified phone number, press “#”. Upon successful completion of the test, the following message should be displayed:mfa server test user

You can also test SMS-based authentication. To do this, in the client settings, specify the “Text message – One-Way – OTP” authentication method. In this case, the MFAS will ask for an OTP, which will come to your phone in a text message.

mfa server otp

In order to associate a user with a mobile device on which the Azure Authenticator app is installed, open and configure the User Portal (Instructions to Install and Configure the User Portal).

You also need to install and configure the Mobile Portal:

  • Go to the C:\Program Files\Multi-Factor Authentication Server directory;
  • Select the correct version and install;
  • After installation, edit the file:

    Find the parameters:


and change the values to match the User Portal parameters.

In the pfup section, change the … parameter to match the … in the User Portal. In our case, “EXTERNALFQDN” is

Note that to use the User Portal you will need:

– A record in the external DNS zone that will point to the User Portal.

– A trust relationship with the server. Ideally, a “white” certificate issued for “EXTERNALFQDN”.

After installation and configuration, in order for the User Portal to work correctly, enter the URL to the portal in the “User Portal” tab. If you are using domain user authentication, set “Primary authentication” as Windows Domain.

mfa server windows domain

In the “Mobile App” tab, enter URL Mobile App Web Service and enable OATH tokens, if you want to use your mobile device as a software token.

The app works as follows:

  • In Token Modemfa server token mode
  • In standard mode without a PINmfa server without pin mode

After the portal is configured, to link the mobile device, click on the User Portal link.

mfa user log in

The first time you log in, you have to fill out the form with security questions. The user will then receive full access to the portal.

In the “Activate Mobile App” menu, click “Generate New Activation Code”. The result should look as follows:

mfa active mobile app

The Azure Authenticator app must be installed on your mobile device (links for iOS, Android and Windows Mobile).

Run the application, tap + and scan the QR code. The account will be synced to your mobile device:

Verify this on the server:

mfa server user edit

Now you can experiment with different authentication modes and see the difference between the Standard and OATH Token modes.

mfa server user edit

Configuring Radius

AnyConnect Cisco ASA can use a third-party Radius server for user authentication. On ASA, configure the AAA Server. On MFAS, configure the Radius client:

mfas radius edit

mfas radius edit

Configuring CISCO ASA

Since we are using domain authentication, ASA must be trusted by the domain. It is also recommended to use a “white” certificate for the VPN gateway. In our case, this is

On ASA, you can configure the AnyConnect VPN gateway with local authentication. Make sure that the connection works, then proceed to configuring authentication through Radius.

Then configure RADIUS. Go to Configuration / Remote Access VPN / AAA/Local Users / AAA Server Groups, and create a group:

mfas cisco asa edit

Add the server to the group. You need to increase the timeout, because the default value may not be enough to enter the code.

mfas cisco asa edit

Test the connection with the RADIUS server:

mfas cisco asa edit

After a successful test, in previously configured AnyConnect connection profiles, change authentication from local to the new group:

mfas cisco asa edit

Profile configuration:

  • 1. Change the timeout:mfas cisco asa edit
  • 2. Specify FQDN for the AnyConnect gateway.mfas cisco asa edit

In order to test the connection with authentication in Standard mode or OATH Token mode, connect to FQDN and enter the domain credentials.

mfas cisco asa edit

You will be prompted to enter a code from the mobile app. If you are using Standard mode without a PIN, the application will receive the authentication confirmation.

After verification via the second factor, the user is authenticated. You will see this:

mfas cisco asa edit

This article describes configuring two-factor authentication for Cisco AnyConnect, but this setup can be implemented for any service that supports authentication via the Radius protocol.

More articles about MS Azure

Two Factor Authentication


The competent approach to IT security in terms of server authorization, both inside and outside the company premises, implies a number of important measures. They include providing a unique user name and meeting password complexity requirements, as well as conducting the planned password change and non-disclosure of credentials to third parties, etc. However, many users quickly forget about these policies. For easy reference, they hang a piece of paper with their username and password in a prominent place, such as their monitor. That can be quite convenient for an attacker wishing to gain access to their sensitive data.Laptop-with-Password-Post-it-768x585

Used products

As an example, let’s consider implementation of OTP password based on multiOTP  project – open source PHP software, capable of working on standard algorithms which are well proven in the industry of multi-factor authentication (HOTP, TOTP, OCRA).

To provide additional input fields for OTP, we will be using the MultiOneTimePassword-CredentialProvider

The user will generate one-time passwords on their mobile device using Google Authenticator.

MultiOTP installation

Download  the multiOTP product and place the contents of the Windows folder from the downloaded directory into the root of the system drive: C:\multiotp.

All configuration is done through the command line. Run CMD as an Administrator and go to our directory:


The following is a list of commands needed to configure and sync the multiOTP service with the Active Directory:

  1. C:\multiotp>multiotp -config default-request-prefix-pin=0

Enter the PIN code by default when you create new users (1 | 0)

  1. C:\multiotp>multiotp -config default-request-ldap-pwd=0

Use Active Directory password instead of the PIN code by default (1 | 0)

  1. C:\multiotp>multiotp -config ldap-server-type=1

Select the AD/LDAP server (1 = Active Directory | 2 = standard LDAP)

  1. C:\multiotp>multiotp -config ldap-cn-identifier=”sAMAccountName”

Set the CN user identifier (sAMAccountName, eventually userPrincipalName)

  1. C:\multiotp>multiotp -config ldap-group-cn-identifier=”sAMAccountName”

Set the group CN identifier (sAMAccountName for Active Directory)

  1. C:\multiotp>multiotp -config ldap-group-attribute=”memberOf”

Set the attribute that determines group membership

  1. C:\multiotp>multiotp -config ldap-ssl=0

Set an SSL connection to be used by default (0 | 1)

  1. C:\multiotp>multiotp -config ldap-port=389

Set the connection port (389 = standard | 636 = SSL connection)

  1. C:\multiotp>multiotp -config,ldaps://

Set the Active Directory server(s)

  1. C:\multiotp>multiotp -config ldap-base-dn=”DC=SERVILON,DC=COM”

Specify the domain suffix

  1. C:\multiotp>multiotp -config ldap-bind-dn=”CN=Administrator,CN=Users,DC=servilon,DC=com”

Set the account used to connect to AD DS.

  1. C:\multiotp>multiotp -config ldap-server-password=”P@$$w0rd”

Set the password used to connect to AD DS

  1. C:\multiotp>multiotp -config ldap-in-group=”OTP”

Set group in which users must use the OTP to access the server

  1. C:\multiotp>multiotp -config ldap-network-timeout=10

Synchronization timeout – set in seconds

  1. C:\multiotp>multiotp -config ldap-time-limit=30

Set the timeout for the OTP password reset

  1. C:\multiotp>multiotp -config ldap-activated=1

Enable the AD/LDAP multiOTP server

  1. C:\multiotp>multiotp -debug -display-log -ldap-users-sync

Synchronization of users with AD/LDAP. This last command must be run each time you add a new user or configure a scheduled run of the script.

If all commands were entered correctly and the AD/LDAP server is available, running the last command should result in synchronization and creation of a new user for the multiOTP service:


Setting up Google Authenticator

Now you need to transfer the unique user key on the user’s device. The most convenient way to do so is to use a QR code. We need to establish a web server which will help us view and register users. Just go to the multiotp folder and run webservice_install.cmd. A browser with a multiOTP web administration console should appear. After entering it, we can create a new local user, or view a list of existing users, which is very useful:


But most importantly, the web console will help us register a user on a mobile device. Click “Print” in the chosen user line and you will we see a QR code generated for the user in a new tab:


Scan the generated QR code with the help of Google Authenticator. The registration process is complete.

As you can see, everything is quite simple. It is also possible to send a QR code to the user by email and the user will do the registration himself. If all goes well, there will be an available OTP password updated on your mobile device every 30 seconds:


Installing MultiOneTime Password Credential Provider

Now we need to tell our Terminal server to use an additional OTP password upon user authentication. To do this, run the previously downloaded MultiOneTimePassword-CredentialProvider installer, where we only need to specify the Default Provider installation and the folder with multiotp service:



Important! After installing Credential Provider, users without OTP installed will not be able to access the server. Therefore, you must take care to set up OTP password on the Administrator’s account.



Now our Terminal server has received an additional level of security in the form of an OTP password based on a free solution multiOTP-Credential Provider.

This solution can be deployed entirely on the user’s PC and build a barrier against an attacker trying to log on to the employee’s office PC.

More articles about two-factor authentication



Know your enemy

Malware, or malicious software, stands for a broad range of applications designed to harm your computer or use it to do damage elsewhere. Malware comes in different shapes and sizes including viruses, Trojan horses, spyware, and others, all of which most users try to avoid like the plague, especially if they store work or private information on their PCs. Some malware applications encrypt your files and demand payment before decrypting them back; some send copies of your desktop files or screen captures to other destinations; yet others use your machine to circulate unauthorized or illicit information or launch attacks on other networks. None of these spell anything good for you.

In the pre-Internet era, malware was distributed mainly via physical storage containing all the code needed to do the bad deed. Modern malware, however, uses a two-stage process to infect your computer. First, you are tricked into downloading a small and virtually harmless downloader application; for example, by clicking on a legitimate-looking link from your email. This downloader is what downloads and installs one, two, or a hundred real malware programs from the Internet, which then cause the real harm.

While this working method is effective, it is malware’s soft spot at the same time. As both stages of the process require an Internet connection, appropriate Internet access administration is a potent way to fight malware. You can dramatically enhance the security of your PC simply by allowing Internet access only for applications that you trust and actually need to work with. How do you do that? That’s what we’re going to talk about in this post.

What weapons to choose?

Before going any further, let’s check to see if you actually need to do anything. Are you lucky enough to be working in a highly-regulated company network, where all traffic is monitored by professional security software utilizing the latest virus definitions from well-known vendors, where Internet access is granted only to a strictly maintained list of client applications? Then you have nothing to worry about. However, if your employer has not implemented robust security procedures, or if you’re on your own, then PC security is a concern for you.

The easiest and most effective method of protection is a local firewall—a security system that monitors and controls traffic. There are quite a few firewall solutions available on the market today, which vary greatly in functionality, user-friendliness, and pricing. While the price tag may be a deterrent for some users, there’s a more pressing concern: that some of these applications may actually function like spyware themselves.

This applies particularly to free software, though you can never be a 100% sure even with paid products. For example, see Bloomberg on Kaspersky products. Technically, this should not be all that surprising. Antivirus and firewall software enjoys the most extensive access privileges on your PC; it can freely transfer your data to the software vendor’s servers, download any updates, and access user files, Internet traffic, and RAM and video memory. Its job is not that different from spying to begin with. So, if some security software serves some harmful purposes under the counter, you cannot really tell.

So what’s your best course of action? If you’re using Microsoft Windows, the answer is pretty straightforward. All instances of Windows come with a built-in local firewall which is free and fairly easy to configure.

It’s true that we cannot be absolutely sure that Windows Firewall does not spy on its users. But hey, you’ve already installed Windows, so you’re pretty much 100% committed to Microsoft. If the corporation is spying on you already, using one more application will not make a huge difference. This is why we’ll focus on how Windows Firewall works and how you can get the most out of it.

Disable & Enable

By default, Windows Firewall allows Internet access for all outbound traffic. This means that any software installed on your machine can transfer and receive data over the Internet. Your first order of business then is to disable Internet access for all applications except for those you trust.

Windows Firewall may be configured either via its GUI (Graphical User Interface) or from the command line. The latter is especially useful for creating distributable batch files designed to apply predefined settings on multiple computers. (This works for networks where all PCs are connected to a domain; there are more efficient ways to distribute policies, but that’s beyond the scope of this post.) We’ll cover both methods.

First, you’ll need to create a rule that will disable Internet access for all software. To do this via the Firewall GUI:

  • Open Windows Firewall snap-in with Advanced Security and select the active profile on the main screen:

Windows Firewall

  • Select ‘Actions’ and then click ‘Properties’:


  • In the dialog that opens, for both ‘Inbound connections’ and ‘Outbound connections,’ select ‘Block’ from the drop-down list:

Inbound connections

To set up a rule that disables traffic from the command line, run the following command:

Set-NetFirewallProfile -all -DefaultInboundAction Block -DefaultOutboundAction Block

After applying this rather harsh rule, you will need to make certain exceptions: first for applications that need to access the Internet, and then for shared folders on your PC.
Software that needs to access the Internet includes web browsers such as Internet Explorer, Google Chrome, or Mozilla Firefox. Let’s set up at a Firewall exception for Internet Explorer as an example.

  • In the Windows Firewall snap-in, right-click on ‘Outbound Rules’ (we’ll be working with outbound traffic from now on) and then click ‘New Rule’:


  • On the next screen, click the ‘Program’ radio button:


  • Provide a path to the executable, which in our example is the Internet Explorer executable:


  • Select ‘Allow the connection’:


  • Select the profile(s) to which this rule will apply. All network profiles are selected by default:


  • Enter a name for this rule:


To enable outbound traffic for Internet Explorer from the command line, run the following commands:

netsh advfirewall firewall add rule name="Internet Explorer" dir=out action=allow program="%ProgramFiles% (x86)\Internet Explorer\iexplore.exe" enable=yes

You can follow a similar process to enable outbound traffic for other browsers like Chrome or Firefox, and for other applications such as Skype (see the script at the end of this post).

Since web browsers also need to stay updated to work in a stable manner, we also need to create separate exceptions for browser update processes. If you use the Windows Firewall GUI, simply rinse-and-repeat as above. If using the command line, sample commands are given below:

netsh advfirewall firewall add rule name="Chrome Update" dir=out action=allow program="%ProgramFiles% (x86)\Google\Update\GoogleUpdate.exe" enable=yes 

netsh advfirewall firewall add rule name="Mozilla Firefox Updater" dir=out action=allow program="%ProgramFiles% (x86)\Mozilla Firefox\updater.exe" enable=yes

As Internet Explorer ships with Windows, you should also allow Internet access to Windows updates, by running the following commands:

netsh advfirewall firewall add rule name="SVCHOST" dir=out action=allow program="%SystemRoot%\System32\svchost.exe" enable=yes

netsh advfirewall firewall add rule name="WUAC" dir=out action=allow program="%SystemRoot%\System32\wuauclt.exe" enable=yes 

Now let’s talk about enabling access to shared folders. To do so via the GUI:

  • Create a new rule:


  • Click the ‘Predefined’ rule type and select ‘File and Printer Sharing’ from the drop-down list:


  • Select the check-boxes ‘File and Printer Sharing (SMB-Out)’ and ‘File and Printer Sharing (NB-Session-Out)’:


  • Allow the connection and then click Finish:


To do the same from the command line, run this:

netsh advfirewall firewall add rule name="File and Printer Sharing (NB-Session-Out)" new dir=out profile=any action=allow enable=yes remoteip=any remoteport=139 protocol=TCP program="System"

netsh advfirewall firewall add rule name="File and Printer Sharing (SMB-Out)" new dir=out profile=any action=allow enable=yes remoteip=any remoteport=445 protocol=TCP program="System"

Transferring settings from one PC to another

Now you know enough to put all these settings in a PowerShell script that can be copied from one computer to another and applied instantly. Here’s a typical script that configures everything we’ve covered above, and a few other useful things:

Set-NetFirewallProfile -all -DefaultInboundAction Block -DefaultOutboundAction Block

netsh advfirewall firewall set rule all new enable=no

netsh advfirewall firewall add rule name="All ICMP V4 - OUT" protocol=icmpv4 action=allow dir=out

netsh advfirewall firewall add rule name="Chrome" dir=out action=allow program="%ProgramFiles% (x86)\Google\Chrome\Application\chrome.exe" enable=yes

netsh advfirewall firewall add rule name="Chrome Update" dir=out action=allow program="%ProgramFiles% (x86)\Google\Update\GoogleUpdate.exe" enable=yes

netsh advfirewall firewall add rule name="Explorer" dir=out action=allow program="%SystemRoot%\explorer.exe" enable=yes

netsh advfirewall firewall add rule name="Internet Explorer86" dir=out action=allow program="%ProgramFiles% (x86)\Internet Explorer\iexplore.exe" enable=yes

netsh advfirewall firewall add rule name="Internet Explorer64" dir=out action=allow program="%ProgramFiles%\Internet Explorer\iexplore.exe" enable=yes

netsh advfirewall firewall add rule name="Java Web" dir=out action=allow program="%ProgramFiles% (x86)\Java\jre1.8.0_25\bin\javaw.exe" enable=yes

netsh advfirewall firewall add rule name="Mozilla Firefox" dir=out action=allow program="%ProgramFiles% (x86)\Mozilla Firefox\firefox.exe" enable=yes

netsh advfirewall firewall add rule name="Mozilla Firefox Updater" dir=out action=allow program="%ProgramFiles% (x86)\Mozilla Firefox\updater.exe" enable=yes

netsh advfirewall firewall add rule name="MSTSC" dir=out action=allow program="%SystemRoot%\system32\mstsc.exe" enable=yes

netsh advfirewall firewall add rule name="Outlook" dir=out action=allow program="%ProgramFiles%\Microsoft Office\Office15\OUTLOOK.EXE" enable=yes

netsh advfirewall firewall add rule name="Skype" dir=out action=allow program="%ProgramFiles% (x86)\Skype\Phone\Skype.exe" enable=yes

netsh advfirewall firewall add rule name="SVCHOST" dir=out action=allow program="%SystemRoot%\System32\svchost.exe" enable=yes

netsh advfirewall firewall add rule name="TeamViewer" dir=out action=allow program="%ProgramFiles% (x86)\TeamViewer\TeamViewer.exe" enable=yes

netsh advfirewall firewall add rule name="File and Printer Sharing (NB-Session-Out)" new dir=out profile=any action=allow enable=yes remoteip=any remoteport=139 protocol=TCP program="System"

netsh advfirewall firewall add rule name="File and Printer Sharing (SMB-Out)" new dir=out profile=any action=allow enable=yes remoteip=any remoteport=445 protocol=TCP program="System"

netsh advfirewall firewall add rule name="Edge22" dir=out action=allow program="%SystemRoot%\SystemApps\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\MicrosoftEdgeCP.exe" enable=yes

netsh advfirewall firewall add rule name="Edge11" dir=out action=allow program="%SystemRoot%\SystemApps\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\MicrosoftEdge.exe" enable=yes

netsh advfirewall firewall add rule name="Outlook16" dir=out action=allow program="%ProgramFiles%\Microsoft Office\root\Office16\OUTLOOK.EXE " enable=yes

netsh advfirewall firewall add rule name="lync16" dir=out action=allow program="%ProgramFiles%\Microsoft Office\root\Office16\lync.exe" enable=yes

A script like that can be written in any word-processing software and saved as a .ps1 file. Running a PowerShell script is a bit trickier though, as it requires Administrator permissions. For this reason it’s easier to create and run a batch (.bat) file instead. UAC will automatically prompt you to confirm these permissions. Here’s what your .bat file should look like:

@echo off
echo Rules of Firewall
echo press any key to continue...
pause > NUL
echo Rules of Firewall 
PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& {Start-Process PowerShell -ArgumentList '-NoProfile -ExecutionPolicy Bypass -File ""%~dp0.\firewall.ps1""' -Verb RunAs}"
echo Rules included in Firewall...

where firewall.ps1 – is the name of the .ps1 file you created that contains the PowerShell commands.

Download PowerShell script

Download .bat file

After the script runs and finishes successfully, the added rules will be displayed in Windows Firewall looking something like this:


Is it really that simple?

Well, not quite. Raising the security level may lead to issues such as the following:

1. If there are any other existing rules in your system, running this script will disable them.

2. Not all services have an easily identifiable executable file. In fact, some executables run others in chain order, making it difficult to determine which one you need to specify in your rule. This may turn out to be quite complicated, even if you use special-purpose utilities like Process Explorer or Network Monitor. A good example is the Windows SmartScreen service whose operation involves running both Windows Explorer and a web browser.

3. By enabling access to specific applications, we’re not making exceptions for any given protocol, but instead allowing unrestricted access for that particular executable. This would limit the operation of service protocols, forcing us to create special additional rules for them.

To successfully resolve these issues and ensure all-around security, you may need to delve deeper into how various applications work on your PC. There are quite a few resources on the Internet that you can consult in this effort (unless you’ve disabled that in your Firewall!). By all means, try to do so and educate yourself—more power at your fingertips! If at any point you don’t feel like it, you’re welcome to contact us for help with your PC security.


How to Install Bitlocker with TPM on Hyper-V 2012 R2

In this article we will review the installation of Bitlocker with the TPM module on the Hyper-V Server 2012 R2 Core.

Bitlocker is a built-in Windows utility that allows you to protect data with encryption. Bitlocker uses the AES algorithm with 128-bit keys. To achieve greater data security, the key length can be increased to 256 bits. By default, the TPM stores and ensures the integrity of the encryption key. This module is a chip built into the PC motherboard that checks running code when the OS is loaded, calculates the hash value, and stores the result in special registers called PCRs (Platform Configuration Registers). More information on TPM and Bitlocker is available on Microsoft’s official website

Preparing the Hyper-V Server 2012 R2, Server Core

Typically, TPM support in Windows is turned off. It must be enabled in the BIOS settings. In our case, we are using the Core version of the operating system, and therefore will not be able to check the standard Device Manager to determine whether the TPM is on. Instead, we will use a PowerShell module developed in the Microsoft Partner & Customer Solutions Blog:

Install the module with the following command:

Ipmo .\ScriptName.psd1 –Verbose

PS C:\> Ipmo .\DeviceManagement.psd1 -Verbose

VERBOSE: Loading module from path


VERBOSE: Importing cmdlet 'Disable-Device'.

VERBOSE: Importing cmdlet 'Enable-Device'.

VERBOSE: Importing cmdlet 'Get-Device'.

VERBOSE: Importing cmdlet 'Get-Driver'.

VERBOSE: Importing cmdlet 'Get-NUMA'.

VERBOSE: Importing cmdlet 'Install-DeviceDriver'.

To view all devices in the system, use this command:

Get-Device | Sort-Object -Property Name | ft Name, DriverVersion

If the TPM is enabled, it will appear in the list of devices:

PS C:\> Get-Device | Sort-Object -Property Name | ft Name, DriverVersion


Trusted Platform Module 1.2             6.3.9600.16384

The TPM is configured in the Hyper-V 2012 R2 Server Core operating system using special cmdlets activated by the following command:

dism /online /enable-feature /FeatureName:tpm-psh-cmdlets

PS C:\> dism /online /enable-feature /FeatureName:tpm-psh-cmdlets

Deployment Image Servicing and Management tool

Version: 6.3.9600.16384

Image Version: 6.3.9600.16384

Enabling feature(s)


The operation completed successfully.

A detailed description of all TPM-cmdlets —

To view the TPM settings, use this command:

PS C:\ > Get-TPM

Protector configuration

For disk encryption, you need to specify where to store the encryption key. In our case, we will specify the TPM and the recovery password as key protectors, which will help us to decrypt the drive.

To configure the protectors, we will use the system utility: manage-bde

Add the TPM module as the protector:

manage-bde –protectors –add C: -tpm

PS C:\Users\Administrator> manage-bde -protectors -add G: -tpm

BitLocker Drive Encryption: Configuration Tool version 6.3.9600

Copyright (C) 2013 Microsoft Corporation. All rights reserved.

Key Protectors Added:


ID: {BC0479C0-96DB-42D4-8C28-957385B9D8D9}

PCR Validation Profile:

0, 2, 4, 8, 9, 10, 11

After the key protector has been added, we initiate the encryption process with the following command:

manage-bde –on –recoverypassword C:

Following the instructions, save the auto-generated password and complete the procedure as described in the figure below.

To view the drive encryption process after you restart the server, use this command:

manage-bde.exe -status C:

PS C:\> manage-bde.exe -status C:

BitLocker Drive Encryption: Configuration Tool version 6.3.9600

Copyright (C) 2013 Microsoft Corporation. All rights reserved.

Volume C: []

[OS Volume]

Size:                 464.44 GB

BitLocker Version:   2.0

Conversion Status:   Fully Encrypted

Percentage Encrypted: 100.0%

Encryption Method:   AES 128

Protection Status:   Protection On

Lock Status:         Unlocked

Identification Field: Unknown

Key Protectors:


Numerical Password

More articles about BitLocker