MS-AZOD Test Suite User Guide

November 27, 2019 · View on GitHub

Contents

Introduction

This guide provides information about how to install, configure, and run the MS-AZOD Test Suite and its environment. This suite is designed to test implementations of MS-AZOD Protocols, as specified in the Microsoft documents and their referenced dependencies. The MS-AZOD test suite consists of Microsoft protocol Authorization Protocols Overview [MS-AZOD]. The guide provides information about using the test suite on Microsoft Windows operating systems and on operating systems that are not Windows-based.

This suite of tools tests only the protocol implementation behaviors that are observed on the wire. For detailed information about the scope of this test suite, see MS-AZOD Test Design Specification (MS-AZOD_ODTestDesignSpecification.docx).

License Information

For licensing information, see the End User License Agreement (EULA) that was provided with this test suite. The EULA is contained in the LICENSE.rtf file in the installation folder.

Further Assistance

If you need further information about this test suite or assistance in troubleshooting issues related to this test suite, contact dochelp@microsoft.com.

Quick Start Checklist

The following checklist summarizes the steps required to get the test suite up and running. The checklist also provides references to documentation that can help you get started.

CheckTaskTopic
Download the test suite for the protocol implementationFor a list of the files that the download package contains, see Installed Files and Folders.
Confirm that your test environment and computers meet the requirements of the test suiteFor information about the requirements of the test suite, see Requirements.
Install the software prerequisitesFor information about software that must be installed on the computers in your test environment before the test suite is installed, see Software.
Set up the Local-Realm Key Distribution Center (KDC) ComputerSee Set Up the Local-Realm/Trust-Realm KDC Computer.
Set up the Trust-Realm Key Distribution Center (KDC) ComputerSee Set Up the Local-Realm/Trust-Realm KDC Computer.
Note: only for cross realm scenario.
Set up the Local-Realm Application Server (AP) ComputerSee Set Up the Local-Realm/Trust-Realm Application Server Computer.
Set up the Trust-Realm Application Server (AP) ComputerSee Set Up the Local-Realm/Trust-Realm Application Server Computer.
Note: only for cross realm scenario.
Set up the Client Computer/Driver ComputerSee Set Up the Client Computer/Driver Computer.
Set up the networkSee Network Setup.
Verify the connection from the Client Computer/Driver Computer to the SUT and other computersSee Verify Connectivity.
Configure the Local-Realm KDC computerSee Configure the Local-Realm KDC Computer.
Configure the Trust-Realm KDC computerSee Configure the Trust-Realm KDC Computer.
Note: only for cross realm scenario.
Configure the Local-Realm Application Server computerSee Configure the Local-Realm Application Server Computer.
Configure the Trust-Realm Application Server computerSee Configure the Trust-Realm Application Server Computer.
Note: only for cross realm scenario.
Configure the Client Computer/Driver ComputerSee Configure the Client Computer/Driver Computer.
Configure test suite settingsSee Configuring the Test Suite.

How Do I?

Use the following quick reference to learn how to complete common tasks.

How do I…?For more information…
Set up the test environmentNetwork Setup and Computer Setup
Verify the connection from the driver computer to other computers and between other computers in the test environmentVerify Connectivity
Setup the Local-Realm/Trust-Realm KDC ComputerSet Up the Local-Realm/Trust-Realm KDC Computer
Setup the Local-Realm/Trust-Realm Application Server ComputerSet Up the Local-Realm/Trust-Realm Application Server Computer
Setup the Client Computer/Driver ComputerSet Up the Client Computer/Driver Computer
Configure the Local-Realm KDC ComputerConfigure the Local-Realm KDC Computer or Configure a KDC Computer that is Not Windows-based
Configure the Trust-Realm KDC ComputerConfigure the Trust-Realm KDC Computer or Configure a KDC Computer that is Not Windows-based
Configure the Local-Realm Application Server ComputerConfigure the Local-Realm Application Server Computer or Configure an Application Server Computer that is Not Windows-based
Configure the Trust-Realm Application Server ComputerConfigure the Trust-Realm Application Server Computer or Configure an Application Server Computer that is Not Windows-based
Configure the Client Computer/Driver ComputerConfigure the Client Computer/Driver Computer
Configure the test suite settingsConfiguring the Test Suite
Run test casesRun All Test Cases, Run Specified Test Cases
Debug my own test casesDebugging Test Cases
Get the results of test runsCheck Test Results
Troubleshoot problemsTroubleshooting

Requirements

This section describes the requirements for the test environment and computers that are used to run this test suite.

image2.png Note

The requirements in this section apply only to the Windows-based computers in the test environment. Note that the driver computer must use a Windows-based operating system.

Environment

Run this test suite in a domain environment that contains the following computers, physical or virtual:

image2.png Note

For Windows based computer acting as the Key Distribution Center, it requires an Active Directory working as its database.

  • Need a domain environment for the Cross-Forest Trust to be built upon.

  • One computer set up as a Windows-based Local-Realm Key Distribution Center (KDC) or as a Local-Realm KDC that is not based on the Windows operating system. If the computer is running on Windows, it must be running on Microsoft® Windows Server® 2012 or later version, 64-bit edition, with the latest updates.

  • One computer set up as a Windows-based Trust-Realm KDC or as a Trust-Realm KDC that is not based on the Windows operating system. If the computer is running on Windows, it must be running on Microsoft® Windows Server® 2012 or later version, 64-bit edition, with the latest updates. The trust should be set up as a cross-forest trust.

  • One computer configured as an Application Server (AP) joined to the local realm. If the computer is running on Windows, it must be running on Microsoft® Windows Server® 2012 or later version, 64-bit edition, with the latest updates.

  • One computer configured as an Application Server (AP) joined to the trust realm. If the computer is running on Windows, it must be running on Microsoft® Windows Server® 2012 or later version, 64-bit edition, with the latest updates.

  • One Client Computer/Driver Computer configured as an Application Client (Endpoint) joined to the local realm. If the computer is running on Windows, it is suggested to run on Microsoft® Windows® 2012 or later version, 64-bit edition, with the latest updates.

Local-Realm KDC

If the KDC is running on Windows, the minimum requirements are as follows:

RequirementDescription
Operating systemMicrosoft Windows Server 2012 or later version
ServicesActive Directory Domain Services (AD DS)
DNS Server
Memory1 GB RAM
Disk space30 GB

Trust-Realm KDC

If the KDC is running on Windows, the minimum requirements are as follows:

RequirementDescription
Operating systemMicrosoft Windows Server 2012 or later version
ServicesActive Directory Domain Services (AD DS)
DNS Server
Memory1 GB RAM
Disk space30 GB

Local-Realm Application Server (AP)

If the application server computer is running on Windows, the minimum requirements are as follows:

RequirementDescription
Operating systemMicrosoft Windows Server 2012 or later version
ServicesFile And Storage Service (File Service Resource Manager installed)
Memory1 GB RAM
Disk space30 GB

Trust-Realm Application Server (AP)

If the application server computer is running on Windows, the minimum requirements are as follows:

RequirementDescription
Operating systemMicrosoft Windows Server 2012 or later version
ServicesFile And Storage Service (File Service Resource Manager installed)
Memory1 GB RAM
Disk space30 GB

Client Computer/Driver Computer

The minimum requirements for the driver computer are as follows:

RequirementDescription
Operating systemMicrosoft Windows Server 2012 or later version
Memory4 GB RAM
Disk space30 GB

Software

All of the following software must be installed on the driver computer before the installation of this test suite.

Required Software

All common softwares listed in prerequisites for running Windows Protocol Test Suites.

  • Microsoft® Message Analyzer

    Microsoft® Message Analyzer (MMA) is required for this test suite to analyze the network traces and validate the message sequences, structures and fields per scenario. Install Microsoft Message Analyzer (Complete) on the Client Computer/Driver Computer which runs Windows operate system.

    image3.pngNote

    November 25 2019 - Microsoft Message Analyzer (MMA) has been retired and removed from public-facing sites on microsoft.com. A private MMA build is available for testing purposes; to request it, send an email to getmma@microsoft.com.

Optional Software

  • Protocol Test Manager

    Protocol Test Manager provides a graphical user interface (UI) to facilitate configuration and execution of Microsoft® Windows Protocol Test Suite tests. Its use is highly recommended.

Network Setup

Run this test suite in domain environment with an isolated Ethernet connection. You can use either physical or virtual machines. This section describes the domain test environment using physical computers.

For information about configuring a virtual machine, see https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/quick-start/create-virtual-machine. The configuration of virtual machines for use with this test suite is out of scope for this guide.

Network Infrastructure

  • A test network is required to connect the test computer systems

  • It must consist of an isolated hub or switch

  • It must not be connected to a production network or used for any other business or personal communications or operations

  • It must not be connected to the internet

  • IP addresses must be assigned for a test network

  • Computer names should be assigned in a test network infrastructure

  • User credentials used on the system must be dedicated to the test network infrastructure

  • Details including computer IP addresses, names and credentials are saved in log files

Refer to the Privacy Statement and EULA for further information.

Single Realm Environment

The single realm environment requires interactions between the following computers and server roles:

  • The Client Computer/Driver Computer runs the observer test cases by verifying the traffic messages captured on other computers.

  • The KDC, AP, and Client run the implementation of the protocols that are being tested.

  • The Client Computer/Driver Computer also runs the traditional synthetic client test cases to test the claim based scenarios.

The following figure shows a single realm environment using an isolated Ethernet connection.

image4.png

Single Realm Environment

The following table lists a suggested network configurations for all the test machines:

Machine NameUsernamePasswordRoleIPv4Subnet MaskDNS ServerDefault GatewayDomain Name
DC01AdministratorPassword01!Local-Realm KDC192.168.0.1255.255.255.0127.0.0.1192.168.0.102contoso.com
AP01AdministratorPassword01!Local-Realm AP192.168.0.2255.255.255.0192.168.0.1192.168.0.102contoso.com
CLIENT01AdministratorPassword01!Local-Realm Client/Driver Computer192.168.0.3255.255.255.0192.168.0.1192.168.0.102contoso.com

Cross-Forest Trust Environment

The forest-trust environment requires interactions between the following computers and server roles:

  • The driver computer runs the test cases by capturing messages among all other computers on the wire.

  • The Local-Realm KDC, Local-Realm AP, Local-Realm Client, Trust-Realm KDC, and Trust-Realm AP run the implementation of the protocols that are being tested.

The following figure shows a forest-trust environment using an isolated Ethernet connection.

image5.png

Multiple Realm Environment

The following table lists a suggested network configurations for all the test machines:

Machine NameUsernamePasswordRoleIPv4Subnet MaskDNS ServerDefault GatewayDomain Name
DC01AdministratorPassword01!Local-Realm KDC192.168.0.1255.255.255.0127.0.0.1; 192.168.0.10192.168.0.254contoso.com
AP01AdministratorPassword01!Local-Realm AP192.168.0.2255.255.255.0192.168.0.1192.168.0.254contoso.com
CLIENT01AdministratorPassword01!Local-Realm Client/Driver Computer192.168.0.3255.255.255.0192.168.0.1192.168.0.254contoso.com
DC02AdministratorPassword01!Trust-Realm KDC192.168.0.10255.255.255.0127.0.0.1; 192.168.0.1192.168.0.254kerb.com
AP02AdministratorPassword01!Trust-Realm AP192.168.0.11255.255.255.0192.168.0.10192.168.0.254kerb.com

Verify Connectivity

After you install the environment, verify the connection from the driver computer to the KDC Computers, and among all other computers in the test environment. The following provides a general list of steps you can use to check for connectivity between two Windows-based computers. For further information, see the administration guide for your operating system.

To check the connection from a Windows-based computer

image2.png Note

  • Disable active firewalls in the test environment (Run Disable_Firewall.ps1 or do it manually).

  • Press Win Key + R.

  • In the Run dialog box, type cmd and then click OK.

  • At the command prompt, type ping followed by the IP address of the KDC computers or the other computers in the test environment and then press Enter. The following example checks the connection to a KDC computer with IP address 192.168.0.1: > ping 192.168.0.1

  • If the KDC is named “DC01”, type ping followed by the hostname and press Enter: > ping DC01

  • Repeat to confirm connectivity between all computers in the test environment.

image2.png Note

Verifying connection using hostname is a must because Kerberos client requires a DNS service for locating KDCs.

Do not proceed with the installation of the test suite until connectivity is confirmed. Any issues with network connectivity must be resolved before you configure the test suite.

Computer Setup

This section explains how to set up the test computers and configure the network for the test environment.

Set Up the Local /Trust-Realm KDC

This section provides information about how to set up the Windows-based Local-Realm/Trust-Realm KDC Computer for use with this test suite.

To set up a Windows-based Local /Trust-Realm KDC computer:

  • Run the MS-AZOD-TestSuite-ODEP.msi installer on the Windows-based Local-Realm/Trust-Realm KDC.

  • When options are prompted, select the option, Install and configure Windows System Under Test (SUT).

To set up a KDC that is not based on the Windows operating system, see Configuring a KDC Computer that is Not Windows-based.

Set Up the Local /Trust-Realm AP

This section provides information about how to set up a Windows-based Local-Realm/Trust-Realm Application Server Computer for use with this test suite.

To set up a Windows-based Local /Trust-Realm AP:

  • Run the MS-AZOD-TestSuite-ODEP.msi installer on the Windows-based Local-Realm/Trust-Realm Application Server Computer.

  • When options are prompted, select the option, Install and configure Windows System under Test (SUT).

To set up an Application Server that is not based on the Windows operating system, see Configuring an Application Server Computer that is Not Windows-based.

Set Up the Client Computer/Driver Computer

This section provides information about how to set up the Windows-based Client Computer/Driver Computer for use with this test suite.

image6.png Important

To set up the driver computer:

  • Install Microsoft Visual Studio, SpecExplorer, Protocol Test Framework and Microsoft Message Analyzer.

  • Copy the MS-AZOD-TestSuite-ODEP.msi to the driver computer.

  • Run the MS-AZOD-TestSuite-ODEP.msi file.

  • When options are prompted, select the option, Install Test Suite on Driver Computer.

Installed Files and Folders

The installation process for this test suite adds the following folders and files to the driver computer at C:\MicrosoftProtocolTests\MS-AZOD\OD-Endpoint\ < version # > .

image2.png Note

The path may vary based on your installation location. The < version # > placeholder indicates the installed build of the test suite.

File or FolderDescription
BatchCommand files that you can use to run all test cases or, BVT test cases.
BinTest suite binaries and configuration files.
ScriptsScripts that are used to set up and configure the Client Computer/Driver Computer, the Key Distribution Centers and the Application Servers.
LICENSE.rtfThe End User License Agreement.

Configuration

This section explains how to configure the network and computers in the test environment for this test suite.

This section explains how to configure the test environment for computers running Windows-based operating systems. For general information about configuring the test environment for computers that are not based on Windows, see Configuring Computers that are Not Based on Windows.

image2.png Note Before each configuration, go to C:\MicrosoftProtocolTests\MS-AZOD\OD-Endpoint\ < version # > \Scripts, and open the Config.xml file. Edit the properties according to the actual situation.

Configure the Local-Realm KDC

This section provides a general list of steps that you can use to configure the Local-Realm KDC computer in a Windows-based test environment. For specific information about how to complete these steps, see the administration guide for your operating system.

To configure the Local-Realm KDC

  • Log on the Local-Realm KDC computer as local administrator.

  • Configure the Computer IP and Computer Name values as section Network Setup.

  • Turn off firewall.

  • Start Windows® PowerShell by right-clicking on the Windows PowerShell icon, and then click Run as Administrator, or from a Windows PowerShell command window, type: Start-process powershell -verb runAs

  • At the command prompt, type Set-ExecutionPolicy Unrestricted -F, and press Enter.

  • Type _cd C:\MicrosoftProtocolTests\MS-AZOD\OD-Endpoint_ < version # > \Scripts, and press Enter.

  • Install ADDS and DNS services, promote this computer as domain controller. To do this, you could Type .\PromoteDomainController.ps1 and press Enter. Or you could do it manually, for more information, please refer to https://blogs.technet.microsoft.com/canitpro/2017/02/22/step-by-step-setting-up-active-directory-in-windows-server-2016/

  • Type .\Set-AutoLogon.ps1 and press Enter to set auto login.

  • Type .\Config-DC01.ps1 and press Enter.

  • The script will create required users, groups, Claim types, Resource property, Central access rule and central access policies to the local realm KDC computer.

Configure the Local-Realm AP

This section provides a general list of steps that you can use to configure the Local-Realm Application Server computer in a Windows-based test environment. For specific information about how to complete these steps, see the administration guide for your operating system.

To configure the Local-Realm Application Server computer

  • Verify that the Local-Realm KDC Computer is configured and running.

  • Log on to the Local-Realm Application Server computer as local administrator.

  • Turn off firewall.

  • Configure the Computer IP and Computer Name values as section Network Setup.

  • Type _cd C:\MicrosoftProtocolTests\ MS-AZOD\OD-Endpoint_ < version # > \Scripts, and press Enter.

  • Type .\Install-FSRM.ps1, and press Enter.

  • Type .\domainjoin.ps1, and press Enter. When it is completed, restart the computer to confirm the success of joining domain.

  • Type .\Config-AP01.ps1, and press Enter.

  • These scripts will join the application server into local realm, create share folders to local realm application server, and apply resource property and central access policy to these folders.

Configure the Trust-Realm KDC

image2.png Note

Trust realm KDC is not required for Single realm environment. If you only run single realm cases, please skip this step.

This section provides a general list of steps that you can use to configure the Trust-Realm KDC computer in a Windows-based test environment. For specific information about how to complete these steps, see the administration guide for your operating system.

To configure the Trust-Realm KDC

  • Log on the Trust-Realm KDC computer as local administrator.

  • Configure the Computer IP and Computer Name values as section Network Setup.

  • Turn off firewall.

  • Type _cd C:\MicrosoftProtocolTests\ MS-AZOD\OD-Endpoint_ < version # > \Scripts, and press Enter.

  • Install ADDS and DNS services, promote this computer as domain controller. To do this, you could Type .\PromoteDomainController.ps1 and press Enter. Or you could do it manually, for more information, please refer to https://blogs.technet.microsoft.com/canitpro/2017/02/22/step-by-step-setting-up-active-directory-in-windows-server-2016/

  • Type .\Set-AutoLogon.ps1 and press Enter to set auto login.

  • Type .\Config-DC02.ps1, and press Enter.

  • The computer will setup the forest trust with local realm, then define claims, central access rules and central access policy, and create ClaimTransformPolicy.

Configure the Trust-Realm AP

image2.png Note

Trust realm KDC is not required for Single realm environment. If you only run single realm cases, please skip this step. This section provides a general list of steps that you can use to configure the Trust-Realm Application Server computer in a Windows-based test environment. For specific information about how to complete these steps, see the administration guide for your operating system.

To configure the Trust-Realm Application Server computer

  • Verify that the Trust-Realm KDC Computer is configured and running.

  • Log on to the Trust-Realm Application Server computer as local administrator.

  • Turn off firewall.

  • Configure the Computer IP and Computer Name values as section Network Setup.

  • Type cd _C:\MicrosoftProtocolTests\ MS-AZOD\OD-Endpoint_ < version # > \Scripts, and press Enter.

  • Type .\Install-FSRM.ps1, and press Enter.

  • Type .\domainjoin.ps1, and press Enter. When it is completed, restart the computer to confirm the success of joining domain.

  • Type .\Config-AP02.ps1, and press Enter.

  • These scripts will join the application server into trust realm, create share folder and apply central access policy to the share folder.

Configure the Client Computer/Driver Computer

This section provides a general list of steps that you can use to configure the driver computer in a Windows-based test environment. For specific information about how to complete these steps, see the administration guide for your operating system.

To configure the Client Computer/Driver Computer

  • Log on to the Client Computer/Driver Computer as local Administrator.

  • Turn off firewall.

  • Configure the Computer IP and Computer Name values as section Network Setup.

  • Type _cd C:\MicrosoftProtocolTests\ MS-AZOD\OD-Endpoint_ < version # > \Scripts, and press Enter.

  • Type .\domainjoin.ps1, and press Enter. When it is completed, restart the computer to confirm the success of joining domain.

  • Type .\Config-client01.ps1, and press Enter.

  • These scripts will create logging folders and join the Client Computer/Driver Computer into local realm.

Configuring the Test Suite

This test suite is installed with default configuration settings. You may need to change these settings if you use a customized test environment or if you customize your test runs.

You can define various required and optional settings for the test suite, such as the following:

  • Define the settings of the test environment, including computer names and IP addresses.

  • Define the basic options used in the test suite; for example, the protocol version or the version of the target operating system.

  • Define the folders used to store output and logs from test runs.

  • Define the location of scripts to run before each test run.

  • Set time limits on discrete test tasks and for test runs.

To change configuration settings for this suite, edit the MS-AZOD_ODTestSuite.deployment.ptfconfig file. You can find this file in the directory C:\MicrosoftProtocolTests\MS-AZOD\OD-Endpoint\ < version # > \Bin.

Required Configuration Settings

The following table describes the required configuration properties and their values.

PropertyDescription
ApplicationServerNameThe default application server name in local realm.
Default value: AP01
ApplicationServerIPThe default application server IP in local realm.
Default value: 192.168.0.2
FQDNUncPathThe default application server share folder name in local realm.
Default value: \AP01.contoso.com\azodshare
UncPathThe default application server share folder name in local realm.
Default value: \192.168.0.2\azodshare
KdcDomainNameThe default local realm domain name.
Default value: contoso.com
KdcNameThe default DC computer name in local realm.
Default value: DC01
KDCIPThe default DC IP in local realm.
Default value: 192.168.0.1
KdcAdminUserThe default domain administrator user name in local realm.
Default value: administrator
KdcAdminPwdThe default domain administrator user password in local realm.
Default value: Password01!
KdcClaimUserThe default user name with claim in local realm.
Default value: claimuser
KdcClaimUserPwdThe default user password with claim in local realm.
Default value: Password01!
ClientComputerNameThe default Client Computer/Driver Computer name in local realm.
Default value: client01
ClientComputerIpThe default Client Computer/Driver Computer IP in local realm.
Default value: 192.168.0.3
ClientAdminUserThe default Client Computer/Driver Computer administrator user name in local realm.
Default value: administrator
ClientAdminPwdThe default Client Computer/Driver Computer administrator password in local realm.
Default value: Password01!
CrossForestNameThe default forest name of cross realm.
Default value: kerb.com
CrossForestDCNameThe default DC computer name in cross realm.
Default value: DC02
CrossForestDCIPThe default DC computer IP in cross realm.
Default value: 192.168.0.10
CrossForestAdminUserThe default domain administrator user name in cross realm.
Default value: administrator
CrossForestAdminPwdThe default domain administrator user password in cross realm.
Default value: Password01!
CrossForestApplicationServerNameThe default application server name in cross realm.
Default value: AP02
CrossForestApplicationServerIPThe default application server IP in cross realm.
Default value: 192.168.0.11
CrossForestApplicationServerShareFolderThe default application server share folder in cross realm.
Default value: \AP02.kerb.com\azodshare
ScriptPathThe default scripts path in test suite installation directory for all endpoints.
Default value: C:\MicrosoftProtocolTests\MS-AZOD\OD-Endpoint\ < version # > \Scripts.
image2.pngNote
The default version number is 1.0.5644.0, which may inconsistent with the current version number. Please update the < version # > as the actual version number installed on the driver computer.
LocalCapFilePathThe default directory for Message Analyzer capture files on driver computer.
Default value: C:\Test\TestLog\MA
DriverLogPathThe default log directory on driver computer.
Default value: C:\Test\TestLog
MaxSMB2DialectSupportedMax SMB2 Dialect supported.
Default value: 770
SiteNameThe default Name of the Site.
Default value: Default-First-Site-Name
CentralAccessPolicyNamesThe default central access policy name.
Default value: AZODPolicy
CentralAccessRuleNamesThe default central access rule.
Default value: AZODRule
ResourcepropertyNamesThe default Resource property name.
Default value: Company_Name

Optional Configuration Settings

No optional configuration settings.

Running Test Cases

This test suite includes command files that you can use to complete basic test cases. Each test case exercises the protocol implementation based on a given scenario.

You can find and run these test cases in the following directory: C:\MicrosoftProtocolTests\MS-AZOD\OD-Endpoint\ < version # > \Batch

You can run these command files at the command prompt, or by selecting and clicking one or more of the files from the directory.

Run All Test Cases

Use the steps below to run all test cases. Shortcuts listed are created during the installation process.

To run all test cases

  • From the desktop of the driver computer, double-click the Run MS-AZOD-OD-EP Test Cases shortcut. Alternatively, go to C:\MicrosoftProtocolTests\MS-AZOD\OD-Endpoint\ < version # > \Batch and double-click the RunAllTestCases.cmd file.

Run Specified Test Cases

Use the steps below to run specific test cases.

To run specified test cases

Check Test Results

Test suite generates test result files in C:\MicrosoftProtocolTests\MS-AZOD\OD-Endpoint\ < version # > \Batch\TestResults

For further information about test log settings, see the PTF User Guide in the PTF installation directory.

Troubleshooting

This section describes how to troubleshoot common issues in running test cases.

Ping Failure

PROBLEMThe domain controller does not respond to pings from the driver computer.
CAUSECheck the firewall is turned off for each computer
RESOLUTIONDisable the firewall for all endpoints

Test Run Issues

PROBLEM8 test cases failed with error cannot find the capture
CAUSEThe 8 cases are for the observer scenarios, which depend on the network capture for verification against TD message sequences.
If the capture files don’t exist, the case will skip.
RESOLUTIONCapture the data on the wire by MMA and save the capture files to folder LocalCapFilePath specified and the case will go on. If the case still fails, it means the capture file doesn’t match the expected frames or some messages miss. This depends on the capture file quality.
PROBLEMThe test suite is not running as expected
CAUSEThe .ptfconfig file was not found or the configuration property values were not set.
RESOLUTIONCopy the .ptfconfig file to the path C:\MicrosoftProtocolTests\MS-AZOD\OD-Endpoint\ < version # > \Server\TestCode\TestSuite and verify the values in the file.

Appendix: Build the Cross-realm Trust Relationship between Windows AD and MIT KDC

Overview

This document is prepared for the installation of Windows AD and MIT KDC, and the guide for building the cross-realm trust relationship between AD and KDC. Moreover, extra descriptions will be given. The configurations are tuned to adapt the Winterop Protocol testing environment, and are NOT meant to be applied to any production environments. In the rest of the document, I will assume machines in the following table to have machine names, domain/realm etc. Make necessary adjustment if any machine/domain/realm differs in your own test environment.

MachineMachine NameDomain/RealmRoleBuildIP Address
Windows ADDC01MS.KERBDCWindows Server 2012172.16.0.1/2012::1
MIT KDCkdcMIT.KERBKDCFedora17/Krb5-1.10172.16.0.254/2012::254
Win Clientwin8MS.KERBClientWindows 8172.16.0.101/2012::101
Linux ClientclientMIT.KERBClientFedora17172.16.0.201/2012::201

Configuring the MIT KDC

Install Fedora 17

  • In order to compatible with Hyper-V, a Fedora-17-KDE version is recommended. Also, you SHOULD select the proper Time Zone such as Shanghai etc. and UNCHECK System clock uses UTC. Configure a “Legacy Network Adapter” to your VM and make sure it’s connected to the External Network.

**

image7.png **

  • Disable the Linux Desktop GUI(KDE) from System Boot (logon as root, the same below).

  • Disable the NetworkManager to enable IPV4 Address.

  • Disable the iptables. In order to support IPv6, you must disable the ip6tables.

Install MIT KDC

  • Install the necessary packages in the Master KDC. Before this, you MUST configure the proper yum repository and http proxy (An example of 163 mirrors is below). . Append the following to /etc/profile:

Here jpnproxy.fareast.corp.microsoft.com is used in Shanghai site. Please replace the server with your site’s preferred proxy server.

  • Then, you can begin install the MIT KDC.

  • Change the network to your own environment, since the MIT KDC will run in this internal network. Edit /etc/sysconfig/network-scripts/ifcfg-eth0 to this:

  • Configure the DNS name server and restart network. Edit /etc/resolv.conf to this:

  • Also, you must specify the host name if you didn’t before. Edit /etc/sysconfig/network to this:

  • Specify the hosts file. Edit /etc/hosts to this:

  • Follow up instructions on http://web.mit.edu/Kerberos/krb5-current/doc/krb_admins/install_kdc.html # edit-kdc-configuration-files. An example of /etc/krb5.conf is below.

An example of /var/kerberos/krb5kdc/kdc.conf is below.

  • Create the KDC database on the MIT KDC realm.

This will create five files in /var/kerberos/krb5kdc (or at the locations specified in kdc.conf): ●two Kerberos database files, principal, and principal.ok ●the Kerberos administrative database file, principal.kadm5 ●the administrative database lock file, principal.kadm5.lock ●the stash file, in this example .k5.MIT.KERB. If you do not want a stash file, run the above command without the -s option.

image8.png

  • Add administrators to the Access Control List (ACL) file. You need create an ACL file and put the Kerberos principal of at least one of the administrators into it. This file is used by the kadmind daemon to control which principals may view and make privileged modifications to the Kerberos database files. The ACL filename is determined by the acl_file variable in kdc.conf; the default is /var/kerberos/krb5kdc/kadm5.acl. Here is an example of a kadm5.acl.

  • Add administrators to the Kerberos database. For example, admin/admin.

  • Create a new user account in the MIT KDC as a test User, such as mituser@MIT.KERB. Also, you had better add the pre-authentication attribute to this user.

  • Start the Kerberos daemons on the MIT KDC. You can verify that they started properly by checking for their startup messages in the logging locations you defined in krb5.conf (see [logging]).Any errors the daemons encounter while starting will also be listed in the logging output.

  • As an additional verification, check if kinit succeeds against the principals that you have created on the previous step.

Configuring the Windows DNS and AD

Install DNS Server

Install Windows DNS. Run dnsmgmt.msc Right Click Forward Lookup Zones- > New Zone… (use default settings) Name the New Zone with the realm name of the MIT KDC. Navigate to DNSDC01Forward Lookup ZonesKERB Right click KERB and create New Domain for MIT.KERB. Then, create SRV for Kerberos service, Kpasswd service and Host (A) for the KDC host. For example in MIT.KERB, (1) create _kerberos._udp.MIT.KERB and _kerberos._tcp.MIT.KERB on port 88 offered by host kdc.mit.kerb; (2) create _kpasswd._udp.MIT.KERB and _kpasswd._tcp.MIT.KERB on port 464 offered by host kdc.mit.kerb; (3) create IPv4 and IPv6 address-to-host resolution for kdc.mit.kerb. For any machine joining MIT.KERB realms: For example Client joining MIT.KERB, (1) create IPv4 and IPv6 address-to-host resolution for client.mit.kerb.

image9.png

Install Windows AD

Install Windows AD with domain MS.KERB. Create a new user account in the Active Directory as a test user, such as msuser.

To avoid dispensable troubles, you had better open the 88 port or close the firewall.

Setting Trust between Windows AD and MIT KDC

Configure the Windows AD

  • Set up access to services. Workstation computers that use services in an MIT realm need to have a realm entry added and enable delegation across the realm trust. To do this, use the Ksetup command on Windows AD that uses the MIT realm for services.

  • Start the Active Directory Domains and Trusts snap-in, Right-click on Properties of your domain (MS.KERB), then select the Trusts tab and select New Trust.

  • Create a trusted domain relationship with the MIT Kerberos realm using the following parameters:

  • Trust Name: < MIT.KERB >

  • Trust Type: Realm trust

  • Transitivity of Trust: Transitive

  • Direction of Trust: Two-way

  • Trust Password: < provide the password you created for the MIT Kerberos realm, this password will be mentioned in the next section >

  • The sequence of these steps is shown in the following screenshots:

image10.png

image11.png

image12.png

image13.png

image14.png

image15.png

image16.png

image17.png

image18.png

Configure the MIT KDC

  • Use the following MIT Kerberos administration commands to create cross-realm principals in the foreign MIT realm (note that the commands is typically run on MIT KDC).

  • After executing each of these commands you will be prompted to supply a password for the account. This password should match the password supplied when creating the Cross-Realm trust in the Active Directory Domains and Trusts snap-in as performed previously in section 4.1.

  • To be careful, there may be some clock problems because of the different time between DC and KDC. You should sync the time, for example, let Windows AD as the Time Server(NTP). Run this command in the MIT KDC to sync.

Create account mappings

  • Account mappings are used to map a foreign Kerberos identity (in a trusted non-Windows Kerberos realm) to a local account identity in the domain. These account mappings are managed through the Active Directory Users and Computers snap-in.

  • These account mappings will allow the non-Windows Kerberos realm to act as an account domain. Users with non-Windows Kerberos principals that have mappings to domain accounts, can logon to a workstation that is joined to a trusted domain using the non-Windows Kerberos principal and password from the non-Windows Kerberos realm.

  • Start the Active Directory Users and Computers snap-in, start advanced features by clicking View, and then Advanced Features as shown below.

image19.png

  • Locate the account to which you want to create mappings, and right-click to view Name Mappings. This example uses the account msuser.

image20.png

  • Click the Kerberos Names mappings tab, add a principal from the foreign MIT realm. The example shown below uses mituser@MIT.KERB.

image21.png

Verify the cross-realm trust relationship

There are some features to show the cross-realm trust relationship has been built before. Also, you can install the clients, such as Windows 8 client and Fedora client, to join each realm as a member of realm user. You can run your own services such as File Sharing or Web Service in the client that has joined one of this realms, and logon from the client of other realm using the other realm’s users. But I just show the relationship’s features and left the other testes to yourself. First, if the cross-realm trust relationship has been built, there must be some users in the Active Directory. Open the ADSI Edit, move to CN=Users, you can find CN=krbtgt and CN=MIT.KERB$ as below.

image22.png

Move to CN=System, you can find trustedDomain CN=MIT.KERB.

image23.png

On the other hand, there must be some users in the MIT KDC as the red circle show below.

image24.png

Of course, the verifications show above cannot be absolutely valid. You must try your own test case to verify the trusting relationship such as Samba. I will not give it in this document.

Reference

Kerberos V5 Installation Guide. Kerberos V5 System Administrator's Guide. Kerberos Interoperability Step-by-Step Guide for Windows Server 2003.