Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update the MAX_TOKEN_SIZE in Sspi.java to 48000 #1396

Closed
JStroom opened this issue Nov 23, 2021 · 3 comments · Fixed by #1398
Closed

Update the MAX_TOKEN_SIZE in Sspi.java to 48000 #1396

JStroom opened this issue Nov 23, 2021 · 3 comments · Fixed by #1398

Comments

@JStroom
Copy link

JStroom commented Nov 23, 2021

We ran into an issue with Windows authentication, that was caused by the Sspi.MAX_TOKEN_SIZE being too small for our current Windows version. We are using JNA 5.9.0.

According to the article below the default MAX_TOKEN_SIZE has been updated from 12.000 to 48.000 in recent windows version (Windows 11).
I want to propose to update the MAX_TOKEN_SIZE in jna to 48.000.

https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/kerberos-authentication-problems-if-user-belongs-to-groups#calculating-the-maximum-token-size

@dblock
Copy link
Member

dblock commented Nov 25, 2021

See #261 for a similar discussion. The conclusion was a "yes, go for it, but ...".

@dbwiddis
Copy link
Contributor

See #261 for a similar discussion. The conclusion was a "yes, go for it".

Looks like the final conclusion was to remove it from the API in a major version bump, that got missed? :)

@dblock
Copy link
Member

dblock commented Nov 25, 2021

I think I am with @matthiasblaesing in that issue that says we should keep it, but the caller needs to know that the API the are calling can fail with insufficient buffer and handle that like in https://github.com/Waffle/waffle/blob/208077d732dc9081571971f4aca2bdf408b463cb/Source/JNA/waffle-jna/src/main/java/waffle/windows/auth/impl/WindowsSecurityContextImpl.java#L127 for example.

Removing works for me too, but then we need to be more careful. I wonder though why we would inflict a backwards incompatible change on everyone while the caller still needs to handle insufficient buffer size.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants