Testing Kerberos and NTLM Authenticated APIs🔍: A Step-by-Step Guide

Kerberos is a widely-used security authentication protocol in many companies, essential for testing endpoints that require authentication. However, Postman, the world’s most renowned API testing tool, currently doesn’t support testing Kerberos-authenticated endpoints, which is undoubtedly unfriendly to many organizations.

Fortunately, I’ve discovered a free software that can implement Kerberos authentication – Apidog. This article will detail how to use Apidog to test Kerberos-authenticated endpoints, aiming to enhance your testing process without significant expense.

What is Kerberos?

Kerberos is a network security authentication protocol developed by MIT. It has become a built-in authentication technology in Microsoft Windows and is used by many organizations for Single Sign-On (SSO), securely transmitting user identity data to applications.

How does Kerberos Authentication work?

Kerberos authentication is a complex process with several components we must understand:

• KDC: Key Distribution Center, including AS and TGS components. In Windows environments, this role is typically assumed by the domain controller.

• AS: Authentication Server, responsible for initial authentication, verifying user identity, and issuing TGT.

• TGT: Ticket Granting Ticket, issued by AS to users who have passed initial authentication, used to request specific service tickets from TGS without re-entering passwords.

• TGS: Ticket Granting Service, a component of KDC, responsible for verifying TGTs and issuing service tickets for specific services.

To better understand the relationship between these components, we can simplify the Kerberos authentication process into the following steps:

1. When a user logs in, the client sends an authentication request to the AS.

2. After verifying the user’s identity, AS issues a TGT.

3. When the user needs to access the specific service, they use the TGT to request a service ticket from the TGS.

4. TGS verifies the TGT and issues a service ticket for the specific service the user is trying to access.

5. The user uses this service ticket to access the required service.

In this process, KDC acts as a whole, containing AS and TGS as its two main functional components. TGT and service tickets are key credentials used to prove identity and authorize access during this process.

This design allows users to perform initial authentication only once (obtaining a TGT) and request different service tickets multiple times within the TGT’s validity period, achieving Single Sign-On (SSO) functionality while maintaining high security.

Benefits of Kerberos Authentication

Using Kerberos as an authentication service offers numerous advantages, particularly in terms of security:

• Centralized authentication service: All authentication is managed by a central server (KDC), simplifying user management and security policy enforcement, and facilitating auditing and monitoring of authentication attempts.

• Mutual authentication: Kerberos provides mutual verification, where both client and server verify each other’s identity.

• Single Sign-On (SSO): Users only need to authenticate once to access multiple services, avoiding password transmission and enhancing security.

• Limited ticket validity: Actual passwords are never sent over the network; instead, encrypted tickets are used. Tickets are time-stamped and have a limited lifetime controlled by administrators. Automatic ticket renewal without user intervention enhances security without compromising convenience.

• Reduced server load: Users only need to authenticate once to access multiple services, and servers don’t need to handle password verification for each request, improving overall system performance.

These advantages make Kerberos the preferred choice for enterprise-level authentication, especially in Windows environments and large-scale networks where security, efficiency, and user experience are crucial.

Testing Kerberos-Authenticated APIs with Apidog on macOS

Let’s walk through the practical steps of using Apidog to test a Kerberos-authenticated API endpoint on macOS.

Step 1: Preparation

Companies that employ Kerberos authentication typically set up accounts for each employee in their AD. These organizations provide their staff with essential Kerberos-related information, which usually includes:

1. Account: Typically based on the employee’s name, often formatted as firstname.lastname or another company-specified format. Let’s say I have an account called scarlett@APIDOG.LOCAL.

2. Password: A personal password for login purposes. It’s usually required to be changed upon first login for security reasons.

3. Kerberos Realm: Generally the uppercase version of the company’s domain name. For example: APIDOG.LOCAL.

4. KDC Server Address: This is the address of the Kerberos Key Distribution Center. It’s typically either the Fully Qualified Domain Name (FQDN) or IP address of the domain controller. Examples include ills7i8hyt2.apidog.local or 192.168.1.100.

This information enables employees to authenticate using the Kerberos protocol, granting them secure access to various company network resources and services.

It’s important to note that the web version of Apidog doesn’t support this feature due to browser limitations. Therefore, make sure you’ve downloaded the latest version of the Apidog desktop client.

Step 2: Modify Local DNS

Endpoints using Kerberos authentication are typically accessed within an internal network. Therefore, we need to configure our DNS server to point to the AD server address. This configuration facilitates subsequent access to these endpoints.

Step 3:Configure /etc/krb5.conf File

The krb5.conf file is the primary configuration file for Kerberos, usually located at /etc/krb5.conf. Here you can configure the KDC server address, AS, and mapping of Kerberos realm hostnames.

Check if this file exists on your machine by entering the following command in the terminal:

cat /etc/krb5.conf

If it shows “No such file or directory,” you need to create this file.

If you have nano installed, you can create and edit the file directly in nano. Of course, feel free to use any text editor you’re comfortable with.

nano /etc/krb5.conf

Then, save the following configuration content in the file:

[libdefaults]
    default_realm = APIDOG.LOCAL  # Your Kerberos realm name, typically the uppercase form of your organization's domain name

[realms]
    EXAMPLE.COM = {
        kdc = ills7i8hyt2.apidog.local # KDC server address, assumed here to be the FQDN of the domain controller
        admin_server = ills7i8hyt2.apidog.local # Usually the same as the KDC
    }

[domain_realm]
    .apidog.local = APIDOG.LOCAL  # Mapping between domain name and Kerberos realm name, left side is lowercase
    apidog.local = APIDOG.LOCAL

After saving, you’ve successfully configured the /etc/krb5.conf file on your machine and can proceed to the next step.

Step 4: Log in to AD Account

macOS comes with both CLI and GUI tools for Kerberos. The GUI tool is called Ticket Viewer. We can use either of these tools to log in.

Open Ticket Viewer by typing “Ticket Viewer” in Spotlight search. Choose “Add Identity,” enter the company-provided account and password, and you’ve successfully logged into AD. Note that login accounts have a time limit; you’ll need to click the refresh button to “renew” the identity after it expires.

Alternatively, you can log in directly using CLI:

# Obtain a Ticket for an AD account
kinit <username@domain>
# Check local Tickets
klist

After successful login, you can test the endpoint in Apidog.

Step 5: Configure Auth in Apidog

Open Apidog and create “New Request.”

Enter the API endpoint URL you want to test, then click “Auth” below and select “Kerberos” as the type.

You’ll see that configuring Kerberos authentication only requires filling in an SPN (Service Principal Name). The SPN mainly consists of the KDC server address and Kerberos realm name. In the input box, enterHTTP + / + KDC server address + @ + Kerberos realm name.

After filling this in, click send. You should see a successful response, and you can continue with your testing.

In the event of encountering 401 error, it is advisable to verify the following points:

• DNS Configuration: Ensure that the DNS settings are correctly configured.

• Kerberos Setup: Verify the accuracy of the Kerberos configuration.

• Credential Validity: Confirm that the account credentials (username and password) are valid and active.

• API Access Permissions: Check whether you have the necessary permissions to access the specific API in question.

• Ticket Expiration: Examine if the Kerberos ticket has expired. If so, you may need to renew it.

Systematically reviewing these elements can help identify and resolve the root cause of the authentication failure, facilitating successful API access.

Testing Kerberos-Authenticated APIs with Apidog on Windows

Great news for Windows users! If you’re already part of a domain, you can start testing Kerberos-authenticated APIs in Apidog right away, without any complex configuration.

Not part of a domain yet? No worries! It’s a straightforward process:

1. Configure your DNS settings

2. Join the domain by entering your credentials in the ‘Connect to work or school account’ section

While the process is streamlined, it’s crucial to ensure you have the necessary permissions and correct credentials before attempting to join the domain. With these in place, you’ll be up and running in no time, ready to leverage Apidog’s powerful API testing capabilities in your Kerberos-authenticated environment.

Using Apidog to Test NTLM-Authenticated APIs

Windows Server environments often use both Kerberos and NTLM authentication methods. While Kerberos, introduced with Windows 2000, is the preferred choice due to its stronger security, NTLM remains relevant for its speed in small networks and compatibility with older systems.

Many companies use both protocols, with NTLM serving as a backup when Kerberos fails, ensuring optimal flexibility.

Apidog supports both authentication methods, with NTLM configuration being particularly simple – requiring just one step and working identically across Windows and macOS systems.

Step 1: Preparation

NTLM authentication doesn’t require as much information; we only need the company-provided account and password.

And, don’t forget to ensure you’ve downloaded and registered the latest version of Apidog.

Step 2: Modify Local DNS

As with Kerberos authentication, since the endpoints are typically accessed internally, we need to configure the DNS server to the AD server address.

Step 3: Configure Auth in Apidog

Surprisingly, NTLM authentication doesn’t require any additional configuration. We can directly configure and complete the test in Apidog.

In the “Auth” section, select “NTLM Authentication” as the type. You’ll see two text boxes to fill in: username and password. Simply enter your account credentials.

Click “Send,” and you’re done! Too simple!

Conclusion

In this article, we’ve explored how to use Apidog to test both Kerberos and NTLM authenticated APIs. Apidog proves to be a versatile and user-friendly tool for testing both authentication methods. It provides a straightforward process for configuring Kerberos authentication, which can be particularly beneficial for organizations that have struggled with this in other API testing tools.

As API security continues to be a critical concern for organizations, tools like Apidog that simplify the testing of secure authentication methods become increasingly valuable. Whether you’re working with cutting-edge Kerberos implementations or maintaining systems that rely on NTLM, Apidog provides the capabilities needed to ensure your APIs are functioning correctly and securely.