Issue Details (XML | Word | Printable)

Key: DNET-941
Type: Bug Bug
Status: Closed Closed
Resolution: Duplicate
Priority: Major Major
Assignee: Jiri Cincura
Reporter: Luciano Mendes
Votes: 0
Watchers: 1

If you were logged in you would be able to see more operations.
.NET Data provider

Windows Trusted Authentication (Win_Sspi) exception on Client PC when Firebird Server is version 3.0.5

Created: 14/Jun/20 11:32 PM   Updated: 11/Sep/20 07:47 PM
Component/s: ADO.NET Provider
Affects Version/s:
Fix Version/s: None

File Attachments: None
Image Attachments:

(4 kB)
Windows 10 Pro Version 1909
Firebird 3.0.5
Issue Links:

 Description  « Hide
Windows Trusted Authentication (Win_Sspi) exception on Client PC when Firebird Server is version 3.0.5 (See LOGIN_ERROR.png picture attached):
- 335544382 - Invalid clumplet buffer structure: buffer end before end of clumplet - clumplet too long

No Windows Trusted Authentication (Win_Sspi) exception should be happen on Client PC when Firebird Server is version 3.0.5

- Try to connect a Firebird 3.0.5 Database Server from a client PC using Windows Trusted Authentication (Win_Sspi)

- This issue does NOT happen when Firebird server version is 2.5.9;
- If the .NET application (FirebirdSql.Data.FirebirdClient 7.5.0) is installed on the same PC where Firebird 3.0.5 is installed (Server), the .NET application can authenticate via Windows Trusted Authentication (Win_Sspi) without any issue;
- The issue is only reproducible if the .NET application is installed on a client PC;
- The .NET application authentication via user/password (Srp) works perfectly on both the server PC and the client PC;
- The Windows Trusted Authentication (Win_Sspi) using the native Firebird 3.0.5 (fbclient.dll - FlameRobin) library is working perfectly on both the server PC and the client PC;
- The issue is the same described in the following Firebird FAQ:

AuthClient = Legacy_Auth, Srp, Win_Sspi
AuthServer = Legacy_Auth, Srp, Win_Sspi
ServerMode = Super
UserManager = Legacy_UserManager, Srp
WireCrypt = Enabled
DefaultDbCachePages = 30K
FileSystemCacheThreshold = 2M
LockHashSlots = 30011
LockMemSize = 15M
RemoteServicePort = 3050
TempBlockSize = 2M
TempCacheLimit = 3000M
DatabaseAccess = None
SecurityDatabase = $(dir_secDb)/security3.fdb

Database Page Size: 8192

=== ADO.NET Connection String ===
var fbConnectionStringBuilder = new FbConnectionStringBuilder
                Pooling = true,
                ServerType = FbServerType.Default,
                DataSource = Properties.Settings.Default.Server,
                Database = Properties.Settings.Default.Database,
                Charset = "WIN1252",
                Role = "RDB$ADMIN"

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Luciano Mendes added a comment - 25/Jun/20 11:36 AM
Hi Jiri Cincura

This is the same issue of the
Would you know if there is any relationship between this bug and the bug introduced in Firebird 3.0.5 and fixed in Firebird 3.0.6?

Best Regards,

Jiri Cincura added a comment - 29/Jun/20 06:52 AM
It's related to DNET-936, not exactly the same, as far as I can tell from your description.

The CORE-6329 seems to be unrelated.

Luciano Mendes added a comment - 29/Jun/20 10:41 AM
Hi Jiri Cincura

I just retested this issue in Firebird 3.0.6, released yesterday, and the issue is still reproducible. That is, this bug is NOT related to the CORE-6329 bug fixed in Firebird 3.0.6.

Other than that, I just retested this issue using an old version of the ADO.NET provider (v5.5.0 - Wednesday, October 5, 2016) and the issue IS also reproducible on it, that is, this is an old issue and it was NOT introduced recently by any update of the ADO.NET provider.

Anyway, this issue is blocking the use of the Firebird 3.0 Windows Trusted Authentication (Win_Sspi) in .NET applications :(

Best regards,

Luciano Mendes added a comment - 12/Aug/20 02:55 PM
Hi Jiri Cincura,

Any news about this issue? Did you have a chance to evaluate the proposed solution in the DNET-936 issue? Could you generate a FirebirdSql.Data.FirebirdClient.dll with the solution proposed in the DNET-936 issue so that I can confirm that it is the same issue that I described here?

I am sorry on insisting in this case but the reason for so much insistence is because this issue is blocking the migration of the .NET systems of the company to from Firebird 2.5 to 3.0.

I thank you in advance for making possible the use of Firebird by .NET systems!

Best Regards,

Jiri Cincura added a comment - 18/Aug/20 08:27 AM
Haven't looked at the DNET-936 yet. I'll try to find some time and run the whole tests suite with this change.

Luciano Mendes added a comment - 31/Aug/20 10:26 AM
Thank you very much Jiri Cincura!

This bug is really blocking the use Windows Trusted Authentication of .NET applications with Firebird 3.0.x and I am hoping that you will be able to fix this bug in time for the next version of ADO.NET provider.

Thanks again!