Is it possible to use GSS-NTLMSSP instead of Kerberos on Linux?

[brandonros]

https://github.com/gssapi/gss-ntlmssp

FROM rust:1.68.0-slim-buster

# cert workaround
COPY certs/redacted.crt /usr/local/share/ca-certificates/redacted.crt
RUN update-ca-certificates --verbose

# openssl-sys + libgssapi-sys-0.2.4 dependencies
ENV DEBIAN_FRONTEND=noninteractive 
RUN apt-get update && apt-get install -y pkg-config libssl-dev gss-ntlmssp libgssapi-krb5-2 krb5-user llvm-dev libclang-dev clang libkrb5-dev

# project
WORKDIR /usr/src/myapp
COPY src src
COPY Cargo.toml Cargo.toml
COPY Cargo.lock Cargo.lock
COPY ntlm.txt ntlm.txt

# build
ENV CARGO_REGISTRIES_CRATES_IO_PROTOCOL=sparse
RUN cargo build --release

ENV NTLM_USER_FILE=/usr/src/myapp/ntlm.txt
ENV NETBIOS_COMPUTER_NAME=redacted
ENV NETBIOS_DOMAIN_NAME=redacted
ENV NTLMUSER=redacted

CMD ["/usr/src/myapp/target/release/sspi_poc"]

[brandonros]

I don't think this actually works, but I'm trying to understand why. Apologies upfront. I've been searching far and wide for this, coming up blank.

[pimeys]

Apologies from my side too, I've never set up Kerberos anywhere, and the implementation in Tiberius came from @dwink who might be able to help you with this.

Also read the discussion in 2020 from the original pull request: https://github.com/prisma/tiberius/pull/77

[dwink]

@brandonros definitely something I never tried. I glanced through the docs for the plugin and I don’t think my implementation here will work out of the box, but in theory it should be possible to extend what’s here to work with the gss-ntlmssp plugin.

[brandonros]

Another route would be pulling in https://docs.rs/sspi/latest/sspi/ I'm guessing (which seems to support Ntlm without gss-ntlmssp plugin).

https://github.com/prisma/tiberius/blob/27ea5a763fa7e3f95c6a81eed405e6589cd97458/src/client/connection.rs#L341

I see "mechanism" here.

https://github.com/gssapi/gss-ntlmssp/blob/8149435632628a2c4d814624954f48564a3a5d9e/src/gssapi_ntlmssp.h#L13

And I see mechanism OID here.

I'm aware this isn't a burning need for anybody. I'd be happy to help test. I just wanted to call out for anybody else who ends up on a deep-dive for the corporation they're working for trying to mix + match Linux/Docker/Windows/MS-SQL/NTLM that this usecase isn't supported. I had to use ODBC driver instead.

Thank you for making a great library. I can give more details if needed.

I kind of found a workaround for this. Sorry for the spam/cry for help, I was doing a deep dive working for a corporation that has MS-SQL set up without the proper Kerberos MSSQLSvc/host:1433 service principal names and just kept hitting brickwalls/deadends. They're primarily a Windows shop, as you can imagine.

Hilariously, Microsoft's official SQL client that they maintain for "their" programming language (.NET) doesn't support their auth mechanism (NTLM) to their SQL database (MS-SQL) on Linux. Kind of understandable I guess? .NET being added to Linux is an afterthought.

https://github.com/dotnet/SqlClient/issues/31 Been open since 2018. Seems like it would be maybe 20 lines of code (based on what one of the issue comments says) to add but... I guess it's just ultra uncommon/no demand for it. I guess people typically work for organizations that support properly configured Kerberos or don't try to mix + match half-Windows half-Linux solutions.

Long story short, you can't use https://www.nuget.org/packages/Microsoft.Data.SqlClient in C# to do Linux/Docker MS-SQL connectivity (unless your organization properly configures the servers in Kerberos, which isn't super common for "Windows shops" to know how to do). You also can't use this Rust library either because this Rust library basically matches the .NET functionality (Kerberos on Linux, without support for NTLM).