Kerberos for SMB with AWS DataSync: Secure Windows Shares to AWS

Amazon’s managed DataSync service now supports Kerberos authentication for SMB file locations, giving Windows-heavy environments a practical path away from NTLM and toward stronger, mutual authentication when moving on‑premises file shares to AWS for analytics, migration, or archive workflows. This feature adds native support for supplying a Kerberos principal, a keytab, and a krb5.conf mapping so the DataSync agent can obtain tickets from your Key Distribution Center (KDC) and authenticate to SMB shares without sending reusable password material across the wire.

Background​

Modern Windows environments have been moving away from legacy authentication primitives for years. Microsoft has marked all versions of NTLM as deprecated, removed NTLMv1 in recent releases, and is steering customers toward Negotiate/Kerberos and token-based approaches for stronger security and reduced relay risk. These steps are documented in Microsoft’s deprecation and removed-features pages and reinforced in the MSRC guidance on hardening NTLM-related attack surfaces.
AWS DataSync is a managed data transfer service that automates and accelerates file and object movement between on‑premises stores and AWS. DataSync historically supported NTLM for SMB authentication; with Kerberos support now available, DataSync can participate in enterprise Kerberos realms (for example, Microsoft Active Directory) and obtain short‑lived Kerberos tickets from your KDC to authenticate to SMB servers. The DataSync documentation shows the Kerberos-specific parameters—Kerberos principal, keytab, and krb5.conf—required when creating an SMB location.

---

Why Kerberos matters for SMB file transfer security​

The security advantages of Kerberos over NTLM​

• Mutual authentication: Kerberos exchanges tickets that authenticate both client and server, reducing the risk of relay and man-in-the-middle attacks that NTLM is vulnerable to.
• No password transmission: Clients request tickets and present them—passwords are not sent over the network during normal operation.
• Stronger cryptography and negotiation: Modern Kerberos deployments default to AES-based ciphers (AES128/AES256) and avoid RC4/DES; Windows updates set AES as the default session key type in many cases.
• Operational telemetry: Kerberos generates explicit events (TGT/TGS issuance) that can be monitored for suspicious patterns; combining this with SMB auditing yields better visibility than NTLM’s behavior often provides.

These advantages make Kerberos the recommended authentication method for SMB traffic where a Kerberos realm is available and administratively manageable—exactly the environments that typically run DataSync agents and SMB servers.

The operational impetus: NTLM deprecation and Microsoft hardening​

Microsoft’s deprecation of NTLM and its push to block or audit NTLM usage where possible is an operational driver for many enterprises to adopt Kerberos. That move, plus new SMB signing/EPA auditing and certificate-mapping changes, has created urgency to remove legacy authentication dependencies and adopt Kerberos-first designs. DataSync’s Kerberos support is a timely tool in that migration toolkit.

---

How DataSync implements Kerberos for SMB locations​

Core components DataSync expects​

When you create an SMB location that uses Kerberos, DataSync requires three Kerberos artifacts from your environment:

• Kerberos principal (Service Principal Name, SPN) — The identity DataSync will present in the Kerberos exchange (for example, CIFS/datasyncuser@EXAMPLE.COM). SPNs are case sensitive and must match what’s in Active Directory.
• Keytab file — A Kerberos key table containing the principal and its secret keys, created with Windows’ ktpass utility. This file lets the DataSync agent perform programmatic Kerberos logins (obtain a TGT and TGS) without an interactive password.
• krb5.conf — A Kerberos configuration file that maps DNS names and domains to realms and lists KDC hostnames. DataSync uses this to locate your KDCs and determine realm mappings.

The DataSync agent sequence for Kerberos authentication is:

• Resolve domain controller / KDC DNS name (DNS port 53).
• Connect to the KDC to obtain a Ticket Granting Ticket (TGT) and a Service Ticket (Kerberos, typically port 88 TCP/UDP).
• Resolve the SMB server by DNS and mount the share (SMB over TCP port 445).
• Present the Service Ticket to the SMB server in lieu of a plaintext password.

Network and timing prerequisites​

• Ports and connectivity: Ensure your DataSync agent can reach DNS (port 53), KDC(s) on Kerberos (port 88 TCP/UDP), and SMB servers on port 445. DataSync’s network requirements page documents these ports and the agent’s expected connectivity.
• Time synchronization: Kerberos relies on timestamped tickets to prevent replay attacks. The commonly accepted clock skew tolerance is five minutes (300 seconds) by default; verify agent, server, and KDC clocks are synchronized via NTP. RFC4120 and Kerberos guides recommend the 5‑minute window, and Windows Kerberos policy defaults align with that expectation.
• DNS hygiene: Kerberos requires canonical DNS resolution for domain controllers and SMB servers. Use fully qualified domain names (FQDNs) and ensure reverse lookups are reliable where the Kerberos configuration expects them.

---

The practical walkthrough (verified and expanded)​

Below is a production-oriented, verified sequence that mirrors the DataSync blog walkthrough while adding operational cautions and pointers to official documentation.

Prerequisites checklist​

• An activated DataSync agent with network reachability to your SMB server and domain controllers.
• DNS records for DCs and SMB servers resolvable by the agent.
• NTP (or equivalent) syncing across KDC, agent, and file server so clocks remain within the Kerberos skew tolerance.
• An Active Directory user or service account with appropriate rights on the target file share and permission to be mapped to an SPN. If you need to preserve NTFS ACLs during transfers, ensure the account has SE_RESTORE_NAME or SE_SECURITY_NAME as required by DataSync.

Step 1 — Create a keytab with ktpass (Windows)​

Use the Windows ktpass utility to map an SPN to an AD user and export a .keytab file for DataSync to consume.
Example (pattern verified from Microsoft docs):
ktpass /out <filepath> /princ <principal> /mapuser <domain\username> rndpass /crypto AES256-SHA1 /ptype KRB5_NT_PRINCIPAL
Notes and cautions:

• The /crypto parameter determines which encryption keys are written into the keytab. Use a cipher your KDC supports; AES256 is commonly recommended today. Microsoft guidance and the ktpass documentation show AES256 options and note the need to map the principal to a user when using AES encryption.
• Setting the account’s password or rotating it changes the key version number (kvno), invalidating older keytabs. Track kvno values if you maintain multiple keytabs across rotations.
• Protect keytab files as highly sensitive artifacts—treat them like secrets. Do not copy them to untrusted machines or leave them in shared, unencrypted storage. DataSync’s cleanup guidance explicitly warns to remove or secure copies of keytab files after testing.

Step 2 — Create a krb5.conf that maps your realm​

Create a krb5.conf describing your realm-to-domain mapping and KDC host(s). A simple template maps lowercase DNS domain names to uppercase realms and lists KDC hostnames or a domain name that resolves to the DCs.
Example template (adapt to your domain):
[libdefaults]
dns_lookup_realm = true
dns_lookup_kdc = true
forwardable = true
default_realm = EXAMPLE.COM
[realms]
EXAMPLE.COM = {
kdc = dc1.example.com
admin_server = dc1.example.com
}
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
Operational notes:

• You can list multiple KDCs to provide redundancy. If your environment has cross-domain trusts or subdomains, add the authoritative realm mappings for those domains.

Step 3 — Create the DataSync SMB location (console/CLI/API)​

When creating the SMB Location:

• Choose the DataSync Agent that has network access to your KDC and SMB server.
• For Server Hostname, use the SMB server’s DNS name (not an IP) so Kerberos name-resolution and service principal matching works.
• Provide the Share name and select Kerberos for Authentication type.
• Upload your keytab and the krb5.conf (these are the KerberosKeytab and KerberosKrbConf parameters via the API/CLI or the console UI).

Step 4 — Configure and test the DataSync task​

• Create a DataSync task using the Kerberos-backed SMB location as source or destination.
• Run small test transfers and validate file and ACL behavior. If you intend to copy Windows ACLs/SACLs, ensure the identity’s Domain membership and rights permit it.

Step 5 — Monitor and remediate​

• Use CloudWatch metrics and DataSync task logs to verify successful mounts and transfers.
• On failure, check DNS resolution on the agent, time sync, KDC reachability, and the keytab/kvno. Common errors relate to mismatched SPNs, expired/rotated passwords, or unsupported encryption types on the account.

---

Verified operational details and cross‑checks​

• AWS announced Kerberos support for DataSync in late January 2025; the AWS “What’s New” and DataSync documentation describe Kerberos authentication as available in all Regions where DataSync is offered. Use those docs to validate availability per region and refer to the DataSync SMB location guide for concrete configuration options (principal, keytab, krb5.conf).
• Microsoft’s guidance about NTLM deprecation and removal of NTLMv1 is the direct driver for many migrations from NTLM to Kerberos. Microsoft’s "Deprecated features" pages and MSRC blogs lay out the deprecation timeline and hardening steps—these are definitive signals that organizations should prioritize Kerberos migration where feasible.
• The ktpass tool is Microsoft’s supported mechanism to map SPNs and export keytabs for non‑Windows services; its syntax and parameters (/princ, /mapuser, /crypto, /out) are documented on Microsoft Learn and in operational guidance from support vendors. When using AES encryption in the keytab, the SPN mapping and proper msDS-supportedEncryptionTypes/DefaultDomainSupportedEncTypes settings need to match the KDC’s expectations.
• Kerberos requires accurate clock synchronization: RFC4120 and Kerberos admin guides recommend a 5‑minute skew window (the default), which Microsoft’s Group Policy Kerberos settings also reflect. If clocks are skewed beyond this window, ticket validation will fail and DataSync will be unable to obtain or use tickets.
• DataSync’s network requirements explicitly list DNS (port 53), KDC (port 88), and SMB (ports 139/445) as essential for SMB locations using Kerberos. Confirm these ports are allowed in any firewall or network ACL between the agent and on‑prem services.

---

Strengths, risks, and recommended mitigations​

Strengths​

• Stronger default security posture: Kerberos reduces replay/relay risk and avoids exposing NTLM hash material.
• Fits enterprise identity models: Kerberos aligns with Active Directory, allowing DataSync to integrate cleanly into existing domain controls and auditing.
• Modern cryptography: When configured to use AES ciphers, authentication benefits from stronger cryptographic primitives set as defaults in recent Windows updates.

Risks and operational pitfalls​

• Keytab secrecy and lifecycle: Keytabs contain secret keys and must be treated like secrets. Leakage gives an attacker the ability to impersonate the service principal until the keytab is retired or kvno rotated. Mitigate by storing keytabs in secure storage during provisioning, limiting access, and rotating and re-issuing keytabs if compromised.
• Password resets and kvno mismatches: Resetting the mapped account password increments kvno and invalidates prior keytabs. Establish operational playbooks for kvno-aware rotations and test keytab renewal procedures before wholesale migration.
• DNS and time dependencies: Kerberos’s reliance on DNS canonicalization and tight time windows can cause subtle, environment-specific failures. Ensure the DataSync agent uses authoritative DNS servers and robust NTP. RFC4120 and Kerberos admin guidance recommend 300 seconds skew and emphasize reliable DNS.
• Inter-domain trusts and SPN complexities: If authenticating across Active Directory trusts, SPN naming and realm mappings can become complex. Test cross-domain flows and document which accounts and SPNs are authoritative for each share. DataSync’s docs encourage listing DNS IP addresses for multiple domains when required.
• DFS Namespaces: DataSync does not support Microsoft Distributed File System (DFS) Namespaces; specify the underlying server/share directly. This limits some migration patterns and requires extra planning if you rely on DFS.

Recommended mitigations and best practices​

• Store keytabs in encrypted vaults (AWS Secrets Manager, HashiCorp Vault, or equivalent) until you upload them to DataSync during creation; delete ephemeral copies immediately.
• Use dedicated service accounts with least privilege for DataSync access—avoid domain admin or overly permissive rights.
• Automate keytab rotation as part of password or key rotation policies and update DataSync locations in a controlled maintenance window (watch kvno).
• Maintain audit trails: enable Kerberos and SMB auditing on servers and collect DataSync logs to CloudWatch for end-to-end observability.

---

Troubleshooting checklist (practical)​

• DNS failures
• Verify that the DataSync agent can resolve the domain controllers and the SMB server by FQDN.
• KDC unreachable or timeouts
• Confirm KDCs are reachable on TCP/UDP 88 and that no intermediate firewall is dropping UDP replies.
• Time skew
• Check host, agent, and KDC clocks; ensure NTP is configured and skew is within the 5‑minute default.
• Keytab/kvno mismatch
• Recreate the keytab after resetting the mapped account’s password or verify the kvno in the keytab matches the KDC using ktpass/ktutil diagnostics.
• Unsupported encryption types
• If the KDC refuses an encryption type, verify msDS-SupportedEncryptionTypes on the account and the domain’s DefaultDomainSupportedEncTypes registry settings; set AES types where possible.
• Permission denials on share
• Confirm the mapped AD account has NTFS share rights and the DataSync identity belongs to any necessary AD groups for ACL copying.

---

Migration strategy: moving multiple SMB locations to Kerberos​

• Inventory and prioritize shares
• Catalog which shares are domain-joined, which use local accounts, and which rely on DFS. Start with domain‑joined shares that are easiest to reconfigure.
• Pilot with non-critical shares
• Use a small, representative set for initial Kerberos-enabled DataSync tasks and validate file metadata and ACL preservation.
• Remediate legacy dependencies
• Identify appliances or apps that require NTLM and either update them, isolate them, or create controlled exception lists.
• Roll forward in waves
• Migrate a controlled percentage of shares per wave, monitor authentication logs, and adjust GPO/registry settings as needed.
• Enforce and retire NTLM where possible
• As proofs-of-success accumulate, shift policy to block NTLM for SMB clients where practical and continue auditing to catch stragglers. Microsoft’s documented auditing modes and rollout timelines make a staged plan practical.

---

Final analysis and guidance​

DataSync’s Kerberos support is a practical, well-integrated capability for enterprises that need to migrate or copy SMB data securely to AWS. The feature aligns with Microsoft’s broader deprecation of NTLM and the industry-wide push to adopt stronger authentication and cryptography. Official AWS documentation provides the configuration knobs (principal, keytab, krb5.conf) and network/time prerequisites that make the integration deterministic when followed carefully.
The biggest operational risk is key management: keytabs are powerful and must be handled like any high‑value credential. Operational teams must build processes for keytab creation, secure distribution, rotation, and revocation. Also be mindful of DNS, time, and encryption-type mismatches that are common sources of Kerberos failures. Microsoft’s guidance on configuring domain encryption types and AES default behavior should be reviewed before deploying AES-only keytabs.
Finally, while Kerberos adoption reduces many attack surfaces associated with NTLM, it does not eliminate all risk. Good defense-in-depth—least-privilege accounts, network segmentation, SMB signing and encryption where possible, continuous logging, and rapid incident playbooks—remains essential. Community best practices and enterprise hardening guidance recommend an audit-first migration approach, and DataSync’s Kerberos support fits cleanly into that staged path to retire NTLM dependence.

---

This feature gives Windows storage owners and cloud migration teams a path to modernize SMB authentication in transit to AWS while aligning with Microsoft’s security roadmap. Implement carefully, automate secrets lifecycle, and validate across DNS, time, and encryption boundaries to get the security and operational benefits Kerberos delivers.

---

Source: Amazon Web Services Enhance your SMB file transfer security with Kerberos and AWS DataSync | Amazon Web Services