Enhance your SMB file transfer security with Kerberos and AWS DataSync

Businesses replicate data from on-premises file shares to the cloud to power analytics processes, enable migrations, or free up archival storage. When authenticating to Windows Server Message Block (SMB) file shares, the NTLM protocol has been ubiquitous for decades. However, Microsoft announced its deprecation in 2024. Whether your business operates in a highly regulated industry or not, you want to use strong, modern authentication mechanisms for the services accessing your data.

Amazon Web Services AWS DataSync is a managed data transfer and discovery service that streamlines and accelerates the movement of data between on-premises storage, edge locations, other cloud providers, and AWS Storage. DataSync supports using Kerberos authentication with your SMB locations, enabling you to use the preferred authentication method for Windows systems. Kerberos provides enhanced security and mutual authentication of the client and server, without transmitting passwords over the network, as well as improved performance over NTLM.

In this post, we introduce the concepts for Kerberos used in your configuration, the changes to the authentication process used by the DataSync agent, and how to create and manage the identities and secrets for use with DataSync. We walk through the configuration of a new DataSync SMB location using Kerberos authentication.

Overview of Kerberos with DataSync SMB locations

Relying on cryptography, time synchronization, and the domain name service (DNS), Kerberos introduces a model for authentication with some key differences related to your DataSync configuration. To obtain Kerberos credentials, called tickets, your DataSync agent needs to locate the Key Distribution Center (KDC) service of your domain controller (DC) and prove its identity cryptographically. To begin using Kerberos with your SMB location, you must know a few terms used in the configuration.

Realm: A Kerberos realm is an administrative boundary containing identities and services (principals). Your Microsoft Active Directory domain (example.com) is also a Kerberos Realm (EXAMPLE.COM). The realm name is case sensitive and appears in the principals and configuration files that you use with Kerberos and DataSync.

Principal: A principal is a unique identity of a user or service in your realm. You specify the identity that you want DataSync to use by its Service Principal Name (SPN). The SPN uses the format SERVICE/instance@REALM, for example CIFS/datasyncuser@EXAMPLE.COM. Associating this principal to an Active Directory user who has needed permissions to the file share enables you to allow DataSync to authenticate to the file share through Kerberos.

Keytab or Key Table: A cryptographic file that includes principals mapped to their secret keys. Keytabs allow programmatic access to Kerberos authenticated resources, and your DataSync agent uses the keytab to obtain the tickets used to access your file share. You create this file by issuing a command with the ktpass utility in Windows.

When it is configured, Kerberos authentication necessitates that DNS locate all servers by their domain names. To initiate the authentication process, the DataSync agent contacts the KDC to obtain a Ticket Granting Ticket and a Service Ticket for the file service on your SMB server, as shown in the following figure. Then, it authenticates to the file server using the Service Ticket in place of a username and password. Kerberos uses port 88 UDP/TCP when communicating with the KDC as well as standard DNS and SMB traffic.

The DataSync agent, when initiating Kerberos authentication, follows this network path:

1. The agent resolves the DNS name of a domain controller (KDC) – DNS – port 53 UDP/TCP.
2. The agent connects to the KDC service to obtain a Ticket Granting Ticket and a Service Ticket – Kerberos – port 88 UDP/TCP.
3. The agent resolves the DNS name of the File Server – DNS – port 53 UDP/TCP.
4. The agent connects to the File Server on TCP port 445 to authenticate using the Service Ticket – SMB/CIFS – port 445 TCP.

Figure 1: Diagram showing communication between a DataSync agent, domain controllers, DNS, and file server

Walkthrough

To allow a DataSync agent to request the Kerberos tickets needed to access your file share, you provide Kerberos configuration parameters when creating the DataSync SMB location.

In this walkthrough you do the following:

1. Use ktpass to assign a Service Principal Name to a user and export the keytab file.
2. Create a krb5.conf file mapping your Kerberos realm to the related DNS namespace.
3. Create the DataSync SMB Location with Kerberos authentication.
4. Configure Kerberos Authentication for your DataSync SMB location.
5. Create a DataSync task.

Prerequisites

Before you begin, make sure that you have configured the following:

• A DataSync Agent deployed and activated.
• Network connectivity: Ports allowed following AWS DataSync network requirements.
• DNS names are registered and resolvable for the file server and domain controllers.
• Time synchronization: Kerberos needs time synchronization between your file server, DataSync agent, and domain controllers, typically to within five minutes tolerance.
• An Active Directory user with permissions to access your file share and allowed to use Kerberos AES 256 bit encryption. AES is now the default encryption type for Windows operating systems. If you previously set alternative msDS-supportedEncryptionTypes/DefaultDomainSupportedEncTypes, then confirm that you can enable AES256_HMAC_SHA1 to continue.

Step 1: Use ktpass to assign a Service Principal Name to a user and export the keytab file

In this step you generate a keytab using the ktpass command from your Windows server to export the principal and the related secret key. Take care managing the keytab file and make sure to store it securely. In this example, ktpass sets the user’s password is set to a random value, as shown in the following figure. You may also set your own password using ktpass if desired. Changing a user’s password increments the key version number (vno), invalidating previous keytabs. If you have multiple keytab files, then you can use the vno to determine which one is the latest. Make sure that you don’t reset the user’s password through other means, because you must generate a new keytab file for use with DataSync.

Create the keytab

1. Open the Command Prompt on your Windows Server.
2. Run the following command, substituting your principal, username, and output path for the keytab file.
   ktpass /out <filepath> /princ <principal> /mapuser <username> rndpass /crypto AES256-SHA1 /ptype KRB5_NT_PRINCIPAL

   

   Figure 2: Output of ktpass when setting the SPN and creating the keytab file, showing the key version number (vno) 5

3. To display the contents of the keytab file and check the version number, run the following command, substituting your path to the file, also shown in the following figure.
   ktpass /in <filepath>

   

   Figure 3: Output of ktpass with an existing keytab file, showing the related principal (for example CIFS/datasyncuser@EXAMPLE.COM) and the same key version (vno 5).

Step 2: Create your Kerberos configuration file

The Kerberos configuration file (krb5.conf) describes a mapping of domain names to realms and the DNS name to use when contacting the KDC(s) for that realm. For most Active Directory domains, the domain name in lower case matches the realm name in uppercase. This walkthrough provides a sample template here for a typical deployment. We specify kdc = example.com, which is the DNS record that resolves to all the registered domain controllers for this domain. You can also list individual KDCs if desired, adding each on a separate line starting with kdc = and the domain name of the server. If your directory involves subdomains or trusts, then you list those names and authoritative KDCs for them here as well.

Create a krb5.conf file

1. Create a text file named krb5.conf.
2. Using the following template, replace the example with your domain/REALM name, making sure to match the lower or upper case of each.

[libdefaults]
    dns_lookup_realm = true
    dns_lookup_kdc = true
    forwardable = true
    default_realm = EXAMPLE.COM 
[realms] 
    EXAMPLE.COM = { 
        kdc = example.com 
        admin_server = example.com 
    } 
[domain_realm] 
    .example.com = EXAMPLE.COM 
    example.com = EXAMPLE.COM

Step 3: Create the DataSync SMB location

You are now ready to create a DataSync SMB location with Kerberos authentication, shown in the following figure.

Begin creating your SMB location

1. Log in to the DataSync console.
2. From the sidebar choose Locations.
3. Choose the Create location
4. For Location type, choose Server Message Block (SMB).
5. Choose your Agent (configured in the prerequisites).
6. Enter the domain name of your SMB server. Kerberos needs the domain name instead of an IP address in this field.
7. For Share name, enter your share name.

Figure 4: The DataSync console showing the Create location dialogue with sample inputs.

Step 4: Configure Kerberos authentication for your DataSync SMB location

For authentication you use the principal name, keytab file, and krb5.conf that you created in Steps 1 and 2, shown in the following figure. For more information, refer to DataSync configuration options for Kerberos.

Enter your configuration in the Authentication pane

1. For Authentication type choose Kerberos.
2. For Kerberos Principal enter the SPN that you specified when creating the keytab in Step 1. The principal is case sensitive, so make sure that it matches the exact name and case.
3. For Keytab file choose the keytab file that you exported with the ktpass command.
4. For DNS IP addresses – optional enter the addresses for your DNS servers. If the default DNS servers used by your DataSync agent can resolve the domain controllers and file share domain names, then skip this step.
5. Choose Create location.

Figure 5: The Authentication section of DataSync SMB location configuration, showing the Kerberos properties entered

The console shows your new SMB location configured to use Kerberos. The SMB location is now ready to use with DataSync tasks, as shown in the following figure.

Figure 6: The location details displaying your completed Kerberos configuration.

Step 5: Create a DataSync task

Now that you have created the SMB location configured with Kerberos authentication, configure a DataSync task, and refer to the task settings documentation to learn more about the task settings and options.

When the task is created successfully, start your DataSync task by choosing Start from the task list, or inside the task overview itself. Learn more about task execution and monitoring your DataSync task with Amazon CloudWatch in the linked documentation.

Cleaning up

To avoid incurring future costs, remove the AWS resources that you created for this walkthrough.

• DataSync agent
• DataSync SMB location
• DataSync task

Furthermore, as part of maintaining Security in the Cloud and the Shared Responsibility Model, remember to secure or remove any copies the keytab file that you created.

Conclusion

In this post, we introduced the concepts for Kerberos used in your configuration, the changes to the authentication process used by the DataSync agent, and how to create and manage the identities and secrets for use with DataSync. We also walked through configuring a new DataSync SMB location using Kerberos authentication.

Following this post, your DataSync SMB location is configured for Kerberos and ready to use for running tasks. Now that you understand the parameters and configuration, you can begin updating more SMB locations to use Kerberos in the DataSync console, AWS Command Line Interface (AWS CLI), or API, and move toward retiring NTLM. If you are authenticating across Active Directory Trusts and want to know more, then visit Starting with Kerberos.

For more information, visit the AWS DataSync product page, view the product documentation and SMB location using Kerberos documentation, or try it in the AWS Management Console.