SS Technology Forum

SS Technology Forum

Computer Migration - Things to Consider

Here are a few points which you can consider while doing computer migration. These points are applicable to all migrations irrespective of the migration tool (ADMT, NetIQ, Quest etc)

Active Directory User Migration

Here is a graphical representation of the high level steps involved in an Active Directory migration using ADMT

User Migration and Merging Using Quest Migration Manager

Pre-creating user account in the target domain is a common scenario these days due to single-sign-on solution, HR management procedure etc

Microsoft Right Management Service (RMS)

Rights Management Service (RMS) is an add-on to many RMS aware applications. In this article my main focus is to explain how we can utilize RMS technology with Exchange 2003 and how we can take advantage of RMS technology to increase the email security

Microsoft ISA Server

I am sure we have all either encountered or heard of this "problem" one time or another if the ISA Server is part of the Active Directory Domain. Is it a problem?

Thursday, June 23, 2016

Advanced Threat Analytics–Attack Simulation and Demo–Part1

Advanced Threat Analytics–Attack Simulation and Demo–Part1

Advanced Threat Analytics–Attack Simulation and Demo–Part2

Advanced Threat Analytics–Attack Simulation and Demo–Part3

Microsoft Advanced Threat Analytics (ATA) is an user and entity behavior analytics solution to identify and protect protect organizations from advanced targeted attacks (APTs).  You can read more information about Microsoft Advanced Threat Analytics (ATA) here.  The purpose of this blog is to provide a few methods which can be used to simulate and demonstrate some of the basic attacks for demo and testing purpose.

Suspicious Activity Simulation #1ATA Gateway Stopped Communicating 

We will start with the most obvious one! – ATA communication issue.   In this scenario, I am using ATA Light Weight Gateway (LWGW).  In this case Microsoft Advanced Threat Analytics Gateway (ATAGateway) service should be running on Domain Controllers. 

To simulate this scenario,

  1. Identify all Domain Controllers from the forest/domain. You can use the following DSQUERY command to get all DCs from the domain.  
    • DsQuery Server -Forest
  2. Stop the ATAGateway service remotely
    • Here are a few scripts -  Script1 or Script2 or Script3 – if you want to go a script based approach
    • Or we can use a simple SC command – SC \\Lab-DC01 stop ATAGateway
    • image

You will receive the following high alert – ATA Gateway Stopped Communicating – in Health Center. 

image

Suspicious Activity Simulation #2- Honey Token Account Activities

In general, the Honey Token accounts are non-interactive accounts.  These accounts can be service accounts or dummy accounts to detect malicious activities.

To simulate this scenario,

  1. Create two 2 user accounts in Active Directory (ATA-Test1 and ATA-Test2)
  2. Add ATA-Test2 to Domain Admins group
  3. Get the SID of ATA-Test1 and ATA-Test2 using PowerShell or DSQUERY command
    • dsquery * -filter (samaccountname=ata-test1) -attr objectsid (Reference)
    • Get-ADUser Ata-test1 -Properties objectSID (Reference)
  4. Add this SID as Honey token accounts (ATA Console –> Configuration –> Detection –> Honeytoken Account SIDs). Save the configuration. 
  5. image
  6. Establish an integrative logon session using these accounts. You can RDP into a machine use these accounts

Honey Token accounts (non-sensitive)

You will receive the following alert/email with recommended actions in the ATA console. 

image

Honey Token accounts (Sensitive)

Since ATA-Test2 account is a domain admin account, you will receive the same alert with "Sensitive (S )" indicating that this account is a high privileged account in Active Directory. 

image

Suspicious Activity Simulation #3 – Massive Object Deletion

Bulk object deletion can be a suspicious activity in an Active Directory environment.  ATA can alert alert you based on massive object deletion activities. 

To simulate this scenario,

  1. Create a few users in Active directory. Here is a sample PowerShell  script which you can use to create test accounts in Active Directory

Clear
Import-module activedirectory
$pass = ConvertTo-SecureString "MyPassword0!" –asplaintext –force
for ($i=0;$i -lt 100;$i++)
{
$accountname = "Test-Account$i"
Write-Host "Creating $accountname" -NoNewline
New-ADUser –SamAccountName $accountname –name $accountname -OtherAttributes @{'description'="ATA Test User Account"} -Path "OU=Test Accounts,OU=User Accounts,DC=labanddemo,DC=com"
Set-ADAccountPassword –identity $accountname –NewPassword $pass
Write-Host "...Done"
}

  1. Make sure ATA is "learned" about these account.
  2. image
  3. Delete these accounts from Active Directory 

You will receive the Massive Object Deletion alert in the ATA console right away as shown below. 

image

Suspicious Activity Simulation #4 - Reconnaissance using DNS

The DNS or name resolution information in a network would be  useful reconnaissance information. In general, DNS data contains a list of all the servers and workstations and the mapping to their IP addresses. Verifying this  information may provide attackers with a detailed view of the environment allowing attackers to focus their efforts on the relevant entities. 

For this simulation, the plan is to perform a DNS zone lookup using NSLOOKUP LS command. 

To simulate this scenario,

  1. Logon to a remote server. 
  2. Open Command Prompt and run NSLOOKUP command
  3. From the NSLOOKUP window, run LS command to list the DNS zone

image

You will receive the following Reconnaissance using DNS alert the ATA console. 

image

Advanced Threat Analytics–Attack Simulation and Demo–Part1

Advanced Threat Analytics–Attack Simulation and Demo–Part2

Advanced Threat Analytics–Attack Simulation and Demo–Part3

Thursday, June 2, 2016

Azure MFA Server –Authentication Types (Part II)

Azure MFA–Authentication Type (Part I)

Azure MFA–Authentication Type (Part II)

The Microsoft Azure Multi-Factor Authentication (MFA) provides various authentication types when using an on-premises MFA server.  The Company Settings section allows the Multi-Factor Authentication (MFA) administrator to define company wide settings for all users. 

image_thumb28

The administrators can also make (or override)  individual user configuration from User Section.  

image_thumb30

An end user can make their own sections from the the User Portal.

image_thumb33

In general, the following authentication modes are available when using an on-premises MFA server. The purpose of this blog is to explain each of these authentication types and expected result with screenshots.  

  1. Phone call (Standard)
  2. Phone call (PIN)
  3. Text message (One-way OTP)
  4. Text message (Two-way OTP)
  5. Text message (One-way OTP + PIN)
  6. Text message (Two-way OTP + PIN)
  7. Azure Authenticator application (Standard)
  8. Azure Authenticator application (PIN)
  9. Azure Authenticator application (OATH token)
  10. Third Party OATH token

In this blog, I will be covering the following authentication types. 

  1. Azure Authenticator application (Standard)
  2. Azure Authenticator application (PIN)
  3. Azure Authenticator application (OATH token)
  4. Third Party OATH token

Review Part I of this blog for other authentication type details. 

The Azure Mobile App mode results in a notification being sent to the user's Azure Authenticator mobile app.  There are 2 different modes for Mobile App – Standard and PIN mode. 

Azure Authenticator application  -Standard

In this mode, user will be prompted for primary authentication using a user name and password and the second authentication is when the user receives a notification in the Azure Authenticator mobile app.

image

Expected Result

In Standard Mode, users will prompted to authenticate, deny, or deny and report fraud as shown below:

image

Azure Authenticator application – PIN

The PIN mode enhances the security of the Multi-Factor Authentication by requiring the user enter a PIN in the Azure Authenticator mobile app. 

image

Expected Result

In this mode, user will be prompted for primary authentication using a user name and password and the second authentication is when the user receives a notification in the Azure Authenticator mobile app to enter the PIN number as shown below:

image

Azure Authenticator application - OATH token

Oath Token mode results in the user being prompted for an OATH code to authenticate with Multi-Factor Authentication.  Time-based OATH codes can be generated by the Azure Authenticator Mobile App or a third-party token. We will start with Azure Authenticator Mobile App. As shown in the following screenshot, the OATH Tokens (Enable OATH Tokens) must be enabled in the MFA Server console to display a Time-based OATH codes in Azure Authenticator Mobile App.  keep in mind that the OATH Token method is only supported by RADIUS Authentication and IIS Authentication Form-Based Authentication.

image

After the activation of Mobile App, users can select OATH token mode from the User Portal or an administrator can configure this from a MFA server console. 

image

Expected Result

A Time-based OATH codes will be generated by Azure Authenticator Mobile App as shown below. 

image

This code needs to entered in the respective application to complete the second factor authentication.  image

Third Party OATH token

Azure MFA server supports a time based OATH (OATH – TOTP) third party tokens.  This is an alternative to using the Azure Authenticator mobile app as an OATH token (see the above scenario - Azure Authenticator application  -Standard).  OATH tokens can be added or imported prior to being associated with a user.  Administrators can associate users and tokens in the Multi-Factor Authentication Server  (as shown below) or the User Portal.  Users can associate themselves with an OATH token during User Portal enrollment or using the OATH Token menu option when the User Portal is configured to provide this functionality.    A bulk token import and configuration is also supported by MFA Server .  An administrator can import OATH Token records from an input  file .  The secret keys must be in Base32 format

image

For this scenario, I am using the Yubikey 4 (Yukico) OATH token.  You need to use Yubico Authentication application to get the OATH code from Yukikey.  Review my Azure MFA and Yubico OATH configuration blog for configuration details. 

The OATH token option is same as the Azure Authenticator mobile app configuration as shown below:

image

Expected Result

In this scenario, you will be using the Time-based OATH codes generated by Yubico Authenticator application. 

image

This OATH code must be entered in the respective application to complete the second factor authentication. 

image

If you have Azure Mobile App OATH and a third party OATH token active for the same user, both token code will be valid. 

      Azure MFA–Authentication Type (Part I)

      Azure MFA–Authentication Type (Part II)

      Tuesday, May 31, 2016

      Azure MFA Server–Authentication Types (Part I)

      Azure MFA Server–Authentication Type (Part I)

      Azure MFA Server–Authentication Type (Part II)

      The Microsoft Azure Multi-Factor Authentication (MFA) provides various authentication types when using an on-premises MFA server.  The Company Settings section allows the Multi-Factor Authentication (MFA) administrator to define company wide settings for all users. 

      image

      The administrators can also make (or override)  individual user configuration from User Section.  

      image

      An end user can make their own sections from the the User Portal.

      image

      In general, the following authentication modes are available when using an on-premises MFA server. The purpose of this blog is to explain each of these authentication types and expected result with screenshots.  

      1. Phone call (Standard)
      2. Phone call (PIN)
      3. Text message (One-way OTP)
      4. Text message (Two-way OTP)
      5. Text message (One-way OTP + PIN)
      6. Text message (Two-way OTP + PIN)
      7. Azure Authenticator application (Standard)
      8. Azure Authenticator application (PIN)
      9. Azure Authenticator application (OATH token)
      10. Third Party OATH token

      We will start with standard Phone Call option.  The Phone call authentication type has two sub options:

      1. Phone call (Standard)
      2. Phone call (PIN)

      Authentication Type : Phone Call – Standard

      image

      Expected Result

      In this mode, user will be prompted for first authentication using a user name and password and then the second authentication is based on the phone call as shown below:

      image

      The first authentication is based on the configuration in MFA.  For example, for RADIUS, you an select  the following options from the Target tab:

      image

      The “from” telephone number can be customized from azure console (https://manage.windowsazure.com/ –> Active Directory –> Configure –>Multi-factor Authentication –> Manage Service Settings –>  Go to the Portal –> Configure –> Settings –> General Settings –> Caller ID Phone Number) as shown below:

      image

      Also, the Voice Messages can be customized based on your requirements. This option is available in https://manage.windowsazure.com/ –> Active Directory –> Configure –>Multi-factor Authentication –> Manage Service Settings –>  Go to the Portal –> Configure –> Voice Message section. 

      image

      Authentication Type : Phone Call – PIN

      In this scenario, we will use Phone call with PIN option. 

      image

      Expected Result

      In this mode, user will be prompted for first authentication using a user name and password and then the second authentication is based on the phone.  During the phone call, MFA will ask you to enter a personalized PIN. 

      image + image

      The PIN creation and enforcement is based on the following configuration in user section. 

      image

      You also have an option in Company Settings section to enforce default PIN rules as shown below:

      imageThe next authentication type is Text message.  Text Message type has four sub options:

      1. Text message (One-way OTP)
      2. Text message (Two-way OTP)
      3. Text message (One-way OTP + PIN)
      4. Text message (Two-way OTP + PIN)

      Authentication Type : Text message - One-way OTP

      image

      Expected Result

      In this mode, user will be prompted for first authentication using a user name and password and then the second authentication is based on  a text message containing a One-Time Passcode (OTP) is sent to the user as shown below:

      image

      The user must enter this  One-Time Passcode (OTP) in the respective application to complete the authentication request.   You application must support Challenge – Response (Authentication Chaining). 

      image

      Authentication Type : Text message – Two-way OTP

      image

      Expected Result

      In this mode, user will be prompted for first authentication using a user name and password and then the second authentication is based on  a text message containing a One-Time Passcode (OTP).   The user must reply to the same  text message by entering the provided OTP to complete the authentication request as shown below:

      image

      Authentication Type : Text message - One-way OTP  + PIN

      image

      Expected Result

      In this mode, user will be prompted for first authentication using a user name and password and then the second authentication is based on  a text message containing a One-Time Passcode (OTP) is sent to the user as shown below:

      image

      This One-Time Passcode (OTP) + PIN needs to be entered in the application to complete the authentication request.   

      image

      The PIN values is based on the configuration in the user or Company Settings:

      User settings:

      image

      Company Settings:

      image

      Authentication Type : Text message – Two-way OTP  + PIN

      image

      Expected Result

      In this mode, user will be prompted for first authentication using a user name and password and then the second authentication is based on  a text message containing a One-Time Passcode (OTP) + PIN.   The user must reply to the same  text message by entering the provided OTP + their personal PIN to complete the authentication request as shown below:

      image

      I believe we have enough information and  screenshots for this blog Smile. I will cover the following authentication types in the Part-II of this blog:

      1. Azure Authenticator application (Standard)
      2. Azure Authenticator application (PIN)
      3. Azure Authenticator application (OATH token)
      4. Third Party OATH token

       

      Azure MFA Server–Authentication Type (Part I)

      Azure MFA Server–Authentication Type (Part II)

      Popular Posts

      Share

      Twitter Delicious Facebook Digg Stumbleupon Favorites More