bulkcopy() & bulkcopy_arrow() fail with Schannel AcquireCredentialsHandleW error 0x8009030D (SEC_E_UNKNOWN_CREDENTIALS)

Start where bulkcopy() and bulkcopy_arrow() open their separate mssql_py_core.PyCoreConnection, and compare it with the path that connect() uses, which already works. Check how that path negotiates TLS and acquires Schannel credentials, and see what changed around issues #501 and #459. Done means bulk copy connects on Windows build 14393 with the reported connection strings, or the failure is reported with a clear reason. Without access to that Windows build, expect to need a maintainer's help to reproduce it.

Hello ☺️

I have been trying to use mssql_python to read from and write to a SQL Server Database.

I am able to read with zero problems from the database and convert the data to Arrow. But, when I try to write back to the database using bulkcopy_arrow(), mssql_python raises the following error:

Failed to connect to SQL Server: Unexpected Implementation Error: Schannel AcquireCredentialsHandle failed: AcquireCredentialsHandleW(UNISP_NAME) failed: unknown SECURITY_STATUS (status=0x8009030D)

I have tried everything and nothing works, can you please help me?

Bellow i send more details about the bug:

On a client machine running Windows Server 2016 / Windows 10 1607 (build 14393), connecting to SQL Server 2022, a normal mssql_python.connect() session works perfectly — I can run SELECTs and executemany() inserts over it. But cursor.bulkcopy_arrow() always fails at connection time with a Schannel credential error:

Failed to connect to SQL Server: Unexpected Implementation Error: Schannel AcquireCredentialsHandle failed: AcquireCredentialsHandleW(UNISP_NAME) failed: unknown SECURITY_STATUS (status=0x8009030D)

0x8009030D is SEC_E_UNKNOWN_CREDENTIALS. This happens before any certificate validation, so it is distinct from the TLS cert-trust failures in #501 / #459 (which were fixed). The common root is the same design noted there: bulkcopy/bulkcopy_arrow open a separate mssql_py_core.PyCoreConnection instead of reusing the already-open, working connection, and that separate path negotiates TLS differently. On this older Windows build, the Rust client's TLS/Schannel credential acquisition fails outright.

I have ruled out the usual suspects — none of these change the result:

• Encrypt=no and Encrypt=yes;TrustServerCertificate=yes — both fail identically (so the #501 cert-trust workaround does not apply here; the failure is before cert validation).
• Windows Integrated auth (Trusted_Connection=yes) and SQL login (UID/PWD) — both fail identically (so it is not tied to integrated/Kerberos auth).
• Upgrading from 1.15.0 to 1.16.0 — no change.

Meanwhile the exact same connection strings work fine for normal connect() + SELECT + executemany().

To reproduce

import mssql_python

conn = mssql_python.connect(
    "Server=<server>,1433;"
    "Database=<db>;"
    "Trusted_Connection=yes;"       # also tried UID=<user>;PWD=<pass>
    "TrustServerCertificate=yes;"   # also tried Encrypt=no
    "Encrypt=yes;"
)
cur = conn.cursor()

# This works fine
cur.execute("SELECT @@SERVERNAME, DB_NAME(), SUSER_SNAME()")
print(cur.fetchone())

# This works fine too
cur.executemany(
    "INSERT INTO <table> (col1, col2) VALUES (?, ?)",
    [(1, "a"), (2, "b")],
)
conn.commit()

# This FAILS at connection time:
#   Schannel AcquireCredentialsHandle failed:
#   AcquireCredentialsHandleW(UNISP_NAME) failed:
#   unknown SECURITY_STATUS (status=0x8009030D)
cur.bulkcopy_arrow("<table>", arrow_table, batch_size=1000)

Further technical details

• mssql-python version: 1.16.0 (also reproduced on 1.15.0)
• mssql-python-odbc: 18.6.2.2
• mssql_python_rs: 0.3.0
• Python: 3.10.4 (64-bit)
• Client OS: Windows, build 10.0.14393 (Windows Server 2016 / Windows 10 1607), reported by platform.win32_ver() → ('10', '10.0.14393', 'SP0', 'Multiprocessor Free')
• Auth: fails with both Trusted_Connection=yes and SQL login (UID/PWD)
• SQL Server: Microsoft SQL Server 2022 (RTM-CU24) (KB5080999) - 16.0.4245.2 (X64)

Observations

• Normal connection + SELECT + executemany all succeed on the same connection string.
• Only the bulkcopy/bulkcopy_arrow path fails, and it fails at connect time (no data is sent).
• Fails regardless of Encrypt=no vs Encrypt=yes;TrustServerCertificate=yes, and regardless of integrated vs SQL auth — consistent with the failure happening in Schannel credential acquisition, before certificate validation.

Possibly related: #501, #459 (separate PyCoreConnection, TLS handled differently than the main connection — but those were certificate-trust failures that are now fixed; this is a credential-acquisition failure on an older Windows build).

Workaround: cursor.executemany(...) + conn.commit() instead of bulk copy.