Performance Testing Active Directory

Active Directory is Microsoft’s Authentication software. Siteminder by Computer Associates is another similar product to Active Directory. Within ZOS, ACF2 & RACF are major authentication products.

Interestingly ACF2 and RACF have completely different philosophies for achieving the same aim, i.e. ensuring access to only those users who should have access. ACF2 requires the administrator to explicitly grant access to a resource. RACF requires the administrator to explicitly block access to a resource. Which approach is better? Well, I’m a performance tester, thankfully I can dodge that one.

Requirements to performance test Authentication Software are rare. In most cases the performance tester is looking at a new or enhanced application, an upgrade to system software or hardware or some other such similar requirement. This normally requires little change or little extra load to security policy.

There is normally just one implementation of Authentication software that covers all development and test environments. The performance tester normally excludes authentication software from scope as there are many users across the development infrastructure which would make it difficult to correlate workload with resource utilisation.

There are some cases though where it can be very useful to test Authentication software. For instance:

1. Implementation of single sign-on where authentication of users is handled by a centrally located authentication software.

2. Addition to an authentication application of large numbers of security objects such as users or devices. This can add to the complexity

of structure of security objects which when combined with increased demand can cause greatly extended response times.

3. Any major reorganisation of authentication such as merging two or more domains into one.

Loadrunner can be used to test authentication software. Simply choose an application of protocol type that you are licensed for and create a logon script. Obtain sufficient user IDs and passwords and away you go.

Life isn’t always that easy. Sometimes (especially with single sign on), logon takes place at boot-up, or when a machine is connected to the network. Once the user is logged in and another application is started, for instance Exchange, additional user credentials are not required to be entered by the user, single sign on takes care of it.

Loadrunner can be used to simulate authentication against Radius. This is a protocol that allows centralised authentication for machines to connect and use a networking service. Actual authentication would still be carried out by reference to Active Directory, Site Minder or some other similar product.

The most common usage of Radius is for ISP’s that provide wireless networks. While these wireless networks can be connected to and used, unless authentication takes place (which may involve the use of a credit card), access to any other network location other than the portal cannot take place.

Rasius also allows an organisation to maintain user profiles in a central location that all remote servers can share. This allows a company to set up a policy that can be applied at a single administered network point using Active Directory or similar.

The Radius protocol can only be played back, it cannot be recorded. There is limited support for this protocol, for instance, it does not support certificates. The following details are setup in the runtime settings:

Property

Network Type Accounting network type

GPRS (General Packet Radio Service) or CSD (Circuit-Switched Data)

IP Address

IP address of the Radius server

Authentication port number

Authentication port of the Radius server

Accounting port number

Accounting port of the Radius server

Secret Key

The secret key of the Radius server

Connection Timeout (sec). The time in seconds to wait for the Radius server to respond. The default is 120 seconds.

Retransmission retries. The number of times to retry after a failed transmission. The default is 0.

Store attributes returned by the server to parameters. Allow Vusers to save attributes returned by the server as parameters, which can be used at a later time. The default is False.

Radius client IP

Radius packets source IP, usually used to differentiate between packets transmitted on different NIC cards on a single Load Generator machine

There are really only two statements that can be used with the Radius protocol.

This is an example as shown in the Loadrunner documentation of the Radius_account statement.

radius_account("AccountName=account1",

"Action=Start",

"Username=joe123",

"CallingId=123456", // MSISDN

LAST);

The other statement is the Radius Authenticate statement.

radius_authenticate("Username=jim",

"Password=doe123",

"CallingId=999", // the MSISDN

LAST);

Active Directory can be performance tested directly with a number of tools. The tool that makes most sense is the free Microsoft tool called ADTest.exe.

This is a reasonably good product that get the job done. While it takes some time to start using this tool, it is flexible and gets the job done. While it is always better to use production data, if you don’t have any, then ADTest can be used to set it up for you. A large range of sample automated functions come pre set-up. This makes it a lot easier to start familarising yourself with the tool.

Once ADTest is installed, it is initiated by executing a command at the run prompt, for example:

adtest –run inter –f adtest.ats –loop 5 –t 20 –m –bt

The above command stresses Active Directory with the test variation inter which is found in the file adtest.ats. 5 loops of inter are executed with 20 threads.

adtest –run LogonUsers –f adtest.ats –loop 5 –t 20 –m –bt

The file adtest.ats contains the following statements.
LogonUsers

{

TEST [LOGON]

LOOP RAND

RANGE #(1-10)

DN P18121##

PWD PassWord

OP LOGON32_LOGON_INTERACTIVE

SCOPE LOGON32_PROVIDER_DEFAULT

}