If you're automating your SQL Server 2025 installations on Windows with Ansible over SSH (passwordless login), you might hit a cryptic error that stops you in your tracks. I recently ran into this, and the solution is all about understanding Kerberos delegation.

The Problem: A Cryptographic Failure

You run your playbook, and the SQL Server setup fails with a ChainerInfrastructureException. The real clue is found on down in the error stack:

System.Security.Cryptography.CryptographicException: The requested operation cannot be completed. The computer must be trusted for delegation and the current user account must be configured to allow delegation.

This isn't a SQL Server bug; it's a classic Kerberos "double-hop" problem. Your Ansible control node connects to the Windows server (Hop 1), but when the installer on that server tries to contact Active Directory (Hop 2), it doesn't have the permission to use your credentials. The result is a crash.

After a deep dive, here is the streamlined checklist to solve it. Interestingly, it didn't require all the typical server-side and Active Directory delegation settings.

The Solution: A Streamlined Delegation Checklist

Here are the steps that ultimately led to a successful, automated installation.

1. Prerequisite: Standard SSH Key Authentication

First, ensure your basic SSH connection works. I used ssh-keygen to generate an SSH key pair and then used Ansible to add the public key to the C:\ProgramData\ssh\administrators_authorized_keys file on all my managed Windows servers that I'm installing SQL Server 2025 on. This establishes the initial connection.

2. Configure the SSH Server (The Windows Managed Node)

You need to tell the OpenSSH service on your Windows Server that it's allowed to accept Kerberos tickets for authentication. This is the only change needed on the server side (you can do this using Ansible as well).

• Edit the sshd_config file located at C:\ProgramData\ssh\sshd_config.

• Ensure this line is present and set to yes:

  GSSAPIAuthentication yes
  

• Restart the sshd service to apply the changes.

What is GSSAPIAuthentication? In simple terms, this setting turns on Kerberos as an authentication method. It tells your SSH server, "I am now willing to accept a valid Kerberos ticket as proof of a user's identity, not just a password or public key." This enables single sign-on using your domain credentials.

3. Configure the Ansible Client & Acquire a Ticket

This is where the key to delegation was found. Even without server-side or Active Directory changes, forcing delegation from the client side was enough.

• Force Delegation: In your Ansible inventory or ansible.cfg, explicitly enable GSSAPI and credential delegation using ansible_ssh_common_args and the -o switch for each setting.

  # In inventory file
  ansible_ssh_common_args: '-o GSSAPIAuthentication=yes -o GSSAPIDelegateCredentials=yes'

• Get a Ticket: This was the final breakthrough. The user running the playbook must have a Kerberos ticket before starting. You can automate this as a pre_task in your playbook or run it manually beforehand:

  # Run this on the Ansible control node
  kinit [email protected]

Quick note here.  To fully automate your playbook and skip this step, consider using a keytab file and skipping kinit.

4. Run the Playbook!

Conclusion

With all the pieces of the Kerberos delegation chain in place, you can now run your playbook to install and configure SQL Server 2025. The installer will now be able to successfully complete the second hop to Active Directory.

The Kerberos double-hop problem is one of those authentication challenges that can derail even the most carefully planned automation projects. What makes this particular issue so frustrating is that the error messages rarely point you directly to the root cause—delegation configuration.

The streamlined approach outlined here proves that you don't always need complex Active Directory policy changes or extensive server-side configuration to solve delegation issues.

Sometimes the solution is as straightforward as enabling the right SSH options and ensuring your control node has a valid Kerberos ticket before execution.

This experience reinforces an important principle in infrastructure automation: when cryptographic errors appear during remote operations, think delegation first.

Whether you're automating SQL Server installations, deploying applications, or managing Windows infrastructure, understanding how your credentials flow through each hop of the authentication chain will save you hours of troubleshooting.

With this configuration in place, your SQL Server 2025 (or 2022) deployments can run smoothly and consistently across your Windows Server 2025 infrastructure using SSH. The initial setup investment pays dividends when you can reliably automate what was once a manual, error-prone process.

Now you can focus on the database configurations that matter, rather than wrestling with authentication plumbing.