estokes / cross-krb5 Goto Github PK

9.0 3.0 4.0 55 KB

Rust 100.00%

cross-krb5's Issues

vendoring the libkrb5 in mac and linux

static linked the libkrb5 maybe easier to use when crossing compile the binary on one machine

Cannot debug error raised when using client()

Whenever I use client() on a finished ServerCtx I get the error code 0x80090302 "The requested function is not supported" and I cannot for the life of me debug what that is supposed to mean.

Another question: Is the ServerCtx supposed to be reused after finishing a login sequence or are you supposed to make a new one for e.g. a Web API?

Can this be used under Windows and PHP directly?

I am totally new to rust.
I compiled the sources and have now build-script-build.exe
How do I use it? Is it possible to use it and get authentication from PHP under Windows?

Thanks.

Add gss_wrap_size_limit() like functionality

I'm trying to use the ldap3 crate, and I'm running into some problems there. When I dive into the ldap3 code, I see this comment:

        // FIXME: the max_size constant is taken from OpenLDAP GSSAPI code as a fallback
        // value for broken GSSAPI libraries. It's meant to serve as a safe value until
        // gss_wrap_size_limit() equivalent is available in cross-krb5.

So I hope gss_wrap_size_limit-like functionality can be added to cross-krb5. The following code (which was subsequently reverted) was maybe an attempt at doing that? 90796a0
If so, I perhaps it could be tried again?

Build is failing on Windows with 0.2.1

Hi!

I've seen you released 0.2.1 and I tried to use it but it doesn't build:

Checking cross-krb5 v0.2.1
error[E0308]: mismatched types                                                                 
   --> C:\Users\geobe\.cargo\registry\src\github.com-1ecc6299db9ec823\cross-krb5-0.2.1\src\windows.rs:411:19
    |
411 |         if res == SEC_E_OK.0 {
    |                   ^^^^^^^^^^ expected `u32`, found `i32`
    |
help: you can convert an `i32` to a `u32` and panic if the converted value doesn't fit
    |
411 |         if res == SEC_E_OK.0.try_into().unwrap() {
    |                             ++++++++++++++++++++

error[E0308]: mismatched types
   --> C:\Users\geobe\.cargo\registry\src\github.com-1ecc6299db9ec823\cross-krb5-0.2.1\src\windows.rs:415:19
    |
415 |         if res == SEC_I_COMPLETE_AND_CONTINUE.0 || res == SEC_I_COMPLETE_NEEDED.0 {      
    |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `u32`, found `i32`
    |
help: you can convert an `i32` to a `u32` and panic if the converted value doesn't fit
    |
415 |         if res == SEC_I_COMPLETE_AND_CONTINUE.0.try_into().unwrap() || res == SEC_I_COMPLETE_NEEDED.0 {
    |                                                ++++++++++++++++++++

error[E0308]: mismatched types
   --> C:\Users\geobe\.cargo\registry\src\github.com-1ecc6299db9ec823\cross-krb5-0.2.1\src\windows.rs:415:59
    |
415 |         if res == SEC_I_COMPLETE_AND_CONTINUE.0 || res == SEC_I_COMPLETE_NEEDED.0 {      
    |                                                           ^^^^^^^^^^^^^^^^^^^^^^^ expected `u32`, found `i32`
    |
help: you can convert an `i32` to a `u32` and panic if the converted value doesn't fit
    |
415 |         if res == SEC_I_COMPLETE_AND_CONTINUE.0 || res == SEC_I_COMPLETE_NEEDED.0.try_into().unwrap() {
    |                                                                                  ++++++++++++++++++++

error[E0308]: mismatched types
   --> C:\Users\geobe\.cargo\registry\src\github.com-1ecc6299db9ec823\cross-krb5-0.2.1\src\windows.rs:570:19
    |
570 |         if res == SEC_E_OK.0 {
    |                   ^^^^^^^^^^ expected `u32`, found `i32`
    |
help: you can convert an `i32` to a `u32` and panic if the converted value doesn't fit
    |
570 |         if res == SEC_E_OK.0.try_into().unwrap() {
    |                             ++++++++++++++++++++

error[E0308]: mismatched types
   --> C:\Users\geobe\.cargo\registry\src\github.com-1ecc6299db9ec823\cross-krb5-0.2.1\src\windows.rs:574:19
    |
574 |         if res == SEC_I_COMPLETE_AND_CONTINUE.0 || res == SEC_I_COMPLETE_NEEDED.0 {      
    |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `u32`, found `i32`
    |
help: you can convert an `i32` to a `u32` and panic if the converted value doesn't fit
    |
574 |         if res == SEC_I_COMPLETE_AND_CONTINUE.0.try_into().unwrap() || res == SEC_I_COMPLETE_NEEDED.0 {
    |                                                ++++++++++++++++++++

error[E0308]: mismatched types
   --> C:\Users\geobe\.cargo\registry\src\github.com-1ecc6299db9ec823\cross-krb5-0.2.1\src\windows.rs:574:59
    |
574 |         if res == SEC_I_COMPLETE_AND_CONTINUE.0 || res == SEC_I_COMPLETE_NEEDED.0 {      
    |                                                           ^^^^^^^^^^^^^^^^^^^^^^^ expected `u32`, found `i32`
    |
help: you can convert an `i32` to a `u32` and panic if the converted value doesn't fit
    |
574 |         if res == SEC_I_COMPLETE_AND_CONTINUE.0 || res == SEC_I_COMPLETE_NEEDED.0.try_into().unwrap() {
    |                                                                                  ++++++++++++++++++++

For more information about this error, try `rustc --explain E0308`.
error: could not compile `cross-krb5` due to 6 previous errors

SSPI Explodes with out of memory when passed a negotiate token instead of a native kerberos token

Hi,

thank you so much for this crate which make things way simpler!

I'm trying to use this crate to accept a token received from Active Directory and I get this failure:

ServerCtx::step failed Not enough memory is available to complete this request

I tried a quick and dirty accept(None, token) to get this error

and the platform is Windows 2019 server in an Hyper-V VM with dynamic RAM management (up to 10GB).

Any clue on how to allocate more memory for the underneath of accept call?

Uncomplete context case?

According to https://datatracker.ietf.org/doc/html/rfc4559#section-5

If the context is not complete, the server will respond with a 401 status
code with a WWW-Authenticate header containing the gssapi-data.

But when we call accept(), if I read the code properly, there's no Error managing this case. It's either we are good or not with the provided token.

Am I reading right?

If yes, maybe there is something to do around windows.rs:572-577 ?

EDIT: Maybe we need a proper error type instead of an anyhow::Error so we can match against it for different errors causes and manage the SEC_E_INCOMPLETE_MESSAGE case?

Allow `GSS_C_NT_HOSTBASED_SERVICE` with `ClientCtx::new(...)`

I wrote a HTTP client which authenticates to a HTTP Proxy via Proxy-Authorization: Negotiate ... where the Kerberos token is generated by cross_krb5.

I create the ClientCtx like this:

let target_principal = format!("HTTP/{proxy_fqdn}"); // e.g. proxy_fqdn = "example.org"
ClientCtx::new(InitiateFlags::empty(), None, &target_principal, None);

This used to work fine until recently on macOS and Linux, but now I get this error:

    major: MajorFlags(
        GSS_S_BAD_NAME | GSS_S_UNAVAILABLE,
    ),
    minor: 0,

The documentation states:

[...] target_principal must be the service principal name of the service you intend to communicate with. This should be an spn as described by GSSAPI, e.g. service/host@REALM.

which suggests, that my usage was not supposed to work.

Since Curl via curl --proxy proxy.example.org:8080 --proxy-user : --proxy-negotiate example.org still works I compared their GSS-API usage to mine, and it looks like it differs in the usage of gss_import_name.

Curl uses gss_import_name with GSS_C_NT_HOSTBASED_SERVICE , while cross_krb5 is fixed to [GSS_NT_KRB5_PRINCIPAL] in ClientCtx::new.

Would it make sense, that cross_krb5 behaves similar to curl?

Update `libgssapi` to 0.7.1

Since 0.7.1 fixes a runtime panic cross-krb5 should probably update to this version as well.

estokes / cross-krb5 Goto Github PK

cross-krb5's Issues

vendoring the libkrb5 in mac and linux

Cannot debug error raised when using client()

Can this be used under Windows and PHP directly?

Add gss_wrap_size_limit() like functionality

Build is failing on Windows with 0.2.1

SSPI Explodes with out of memory when passed a negotiate token instead of a native kerberos token

Uncomplete context case?

Allow `GSS_C_NT_HOSTBASED_SERVICE` with `ClientCtx::new(...)`

Update `libgssapi` to 0.7.1

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent