Support integratedsecurity on Unix and MacOS

[edmellum]

.NET Core supports integratedsecurity on Unix and MacOS via Kerberos through GSSAPI. It seems to all be open source under an MIT license now, so an implementation could be based on .NET Core. 😄

[pimeys]

Is there already some Rust crate that provide this API?

[edmellum]

There's rust-sasl but I'm unsure how complete it is. Materialize seems to have GSSAPI support via rust-sasl, but it kind of seems like the actual GSSAPI usage is done in C/C++ in librdkafka through rust-rdkafka instead of in pure rust?

[dwink]

libgssapi looks promising...

[pimeys]

You want to try it out if it works?

[pimeys]

Happy to assist if you need help :)

[tafia]

I would be really interested in having this working on unix as well. I will have to use odbc because our dba won't allow any other authentication type.

[dwink]

I tried it out and it DOES work! As it turns out the NTLM-based SSPI mechanism is just a Microsoft implementation of SPNEGO, so I was able to reuse almost all the SSPI stuff. Cleaning up the code for a PR.

[dwink]

PR: #77

[pimeys]

Is there a way to test this in our CI? I'm still on vacation with no proper computer until 23.8. so I cannot really test or review this properly. What kind of setup one needs to try this out? Any comments @esheppa? Sent from ProtonMail mobile

…

-------- Original Message --------

On Aug 16, 2020, 00:34, David Harks wrote: PR: [#77](#77) — You are receiving this because you commented. Reply to this email directly, [view it on GitHub](#34 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAAIRF54DYOIF6YRFMCF5LTSA4EOXANCNFSM4M7HKZQQ).

[pimeys]

Oh, and this is really interesting work. Thanks for the PR! Sent from ProtonMail mobile

…

-------- Original Message --------

On Aug 16, 2020, 00:34, David Harks wrote: PR: [#77](#77) — You are receiving this because you commented. Reply to this email directly, [view it on GitHub](#34 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAAIRF54DYOIF6YRFMCF5LTSA4EOXANCNFSM4M7HKZQQ).

[dwink]

Is there a way to test this in our CI? I'm still on vacation with no proper computer until 23.8. so I cannot really test or review this properly.

I took a look at the Appveyor docs, and alas I don't see a way to enable Active Directory & Kerberos integration ☹️ . The giant downside to Kerberos is it's designed for large LAN networks, and needs to be administered with support for consistent name lookups and so on.

What kind of setup one needs to try this out?

The simplest setup I know of is to set up an Active Directory domain, add the SQL Server to it, and register a SPN for the server. How do you test the NTLM auth features today? With the exception of the SPN registration, the same setup should work, I'd think.

Unfortunately Kerberos/GSSAPI are old and arcane technologies. There's a reason everyone has moved to OAuth when they can.

As a first step, maybe one of the commenters on this thread can try with my fork and see if it works in their environments, in order to flush out any environment differences? @edmellum ? @tafia ?

[pimeys]

We should also document this properly to the main module... Sent from ProtonMail mobile

…

-------- Original Message --------

On Aug 16, 2020, 19:07, David Harks wrote: > Is there a way to test this in our CI? I'm still on vacation with no proper computer until 23.8. so I cannot really test or review this properly. I took a look at the Appveyor docs, and alas I don't see a way to enable Active Directory & Kerberos integration ☹️ . The giant downside to Kerberos is it's designed for large LAN networks, and needs to be administered with support for consistent name lookups and so on. > What kind of setup one needs to try this out? The simplest setup I know of is to set up an Active Directory domain, add the SQL Server to it, and register a SPN for the server. How do you test the NTLM auth features today? With the exception of the SPN registration, the same setup should work, I'd think. Unfortunately Kerberos/GSSAPI are old and arcane technologies. There's a reason everyone has moved to OAuth when they can. As a first step, maybe one of the commenters on this thread can try with my fork and see if it works in their environments, in order to flush out any environment differences? ***@***.***(https://github.com/edmellum) ? ***@***.***(https://github.com/tafia) ? — You are receiving this because you commented. Reply to this email directly, [view it on GitHub](#34 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAAIRF4N44N4JOQWQKBXWODSBAG5BANCNFSM4M7HKZQQ).

[pimeys]

The simplest setup I know of is to set up an Active Directory domain, add the SQL Server to it, and register a SPN for the server. How do you test the NTLM auth features today? With the exception of the SPN registration, the same setup should work, I'd think.

We just test ln that Windows computer with the current user. So this crate doesn't work on Windows? We still need separate code for that? Sent from ProtonMail mobile

…

-------- Original Message --------

On Aug 16, 2020, 19:07, David Harks wrote: > Is there a way to test this in our CI? I'm still on vacation with no proper computer until 23.8. so I cannot really test or review this properly. I took a look at the Appveyor docs, and alas I don't see a way to enable Active Directory & Kerberos integration ☹️ . The giant downside to Kerberos is it's designed for large LAN networks, and needs to be administered with support for consistent name lookups and so on. > What kind of setup one needs to try this out? The simplest setup I know of is to set up an Active Directory domain, add the SQL Server to it, and register a SPN for the server. How do you test the NTLM auth features today? With the exception of the SPN registration, the same setup should work, I'd think. Unfortunately Kerberos/GSSAPI are old and arcane technologies. There's a reason everyone has moved to OAuth when they can. As a first step, maybe one of the commenters on this thread can try with my fork and see if it works in their environments, in order to flush out any environment differences? ***@***.***(https://github.com/edmellum) ? ***@***.***(https://github.com/tafia) ? — You are receiving this because you commented. Reply to this email directly, [view it on GitHub](#34 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAAIRF4N44N4JOQWQKBXWODSBAG5BANCNFSM4M7HKZQQ).

[dwink]

We just test ln that Windows computer with the current user. So this crate doesn't work on Windows? We still need separate code for that?

Technically it can work on Windows, but Windows code tends to use the Windows API for this (as you did in the WindowsIntegrated variant), so there might be build annoyances trying to link in the gssapi libraries on Windows, since most systems wouldn't install both.

Another point here is that I created a new enum variant for my implementation, but the process itself is nearly identical to the WindowsIntegrated variant -- we could merge the two and use cfg variants for the two different dependencies, which would avoid needing to use different client code per-platform.

[pimeys]

I'll see what we can do with it when I get back to Berlin. If you want this to be merged earlier, maybe @esheppa has time to review and merge? Then what we need next is windows named pipes and the in-memory protocol, and this crate is in a quite good shape already! Oh, and maybe figuring out how broken the client gets when using future cancellation such as the `select!` macro. My guess: very... Sent from ProtonMail mobile

…

-------- Original Message --------

On Aug 16, 2020, 19:20, David Harks wrote: > We just test ln that Windows computer with the current user. So this crate doesn't work on Windows? We still need separate code for that? Technically it can work on Windows, but Windows code tends to use the Windows API for this (as you did in the WindowsIntegrated variant), so there might be build annoyances trying to link in the gssapi libraries on Windows, since most systems wouldn't install both. Another point here is that I created a new enum variant for my implementation, but the process itself is nearly identical to the WindowsIntegrated variant -- we could merge the two and use cfg variants for the two different dependencies, which would avoid needing to use different client code per-platform. — You are receiving this because you commented. Reply to this email directly, [view it on GitHub](#34 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAAIRF7VHVKIN6SUQ2PNBEDSBAIM7ANCNFSM4M7HKZQQ).

[dwink]

I'll see what we can do with it when I get back to Berlin. If you want this to be merged earlier,

I am in no rush; I think making sure this works in a few environments is probably worth waiting a bit for, since if there is an issue it might be tricky to troubleshoot. Setting KRB5_TRACE=/dev/stderr helps tremendously.

Meantime I'll try to document in the main module and push that up for further review.

[esheppa]

Hi @pimeys I'm happy to do a review, I can take a look through it tomorrow but from a brief look it looks good, thanks @dwink! :)

My only thought here is it might be nice to have this as an cargo feature such that the dependency can be avoided if not needed (I recognize that the Windows integrated auth is currently non-optional on Windows, but potentially it could also be made optional in the future)

In terms of testing one thought I've had is we could potentially use the FreeIPA demo realm but I don't have much experience in that area.

[pimeys]

Yeah, this is really cool if we could make stuff like Kerberos authentication on Rust easy and modernish!

[pimeys]

This is now implemented in 0.4.9.

[edmellum]

Has anyone tested this on MacOS? I'm having some issues when following the docs

[pimeys]

I think we have no macOS devs working on Tiberius... Would be useful to have one to test and fix issues with the OS.

[edmellum]

I can't promise I'll start actively working on Tiberius, but I'm going to try it out a bit on a Mac and write up any issues I find 😄

Are the Tiberius tests running on MacOS? I think Github Actions have free minutes on MacOS, would a pull request setting that up be of interest?

[pimeys]

Everything is always appreciated!

…

-------- Original Message --------

On Sep 3, 2020, 22:51, David Ed Mellum wrote: I can't promise I'll start actively working on Tiberius, but I'm going to try it out a bit on a Mac and write up any issues I find 😄 Are the Tiberius tests running on MacOS? I think Github Actions have free minutes on MacOS, would a pull request setting that up be of interest? — You are receiving this because you modified the open/close state. Reply to this email directly, [view it on GitHub](#34 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAAIRF5SV6HZKAHM64XM7O3SD76VRANCNFSM4M7HKZQQ).