I’m trying to configure a MSSQL instance to be used with Boundary. The instance is configured through a Vault credential library (same setup I’ve been using for MySQL, and it works great).
However, I can’t connect to said instance with the credentials provided by Vault when connecting through Boundary (they’re fine when connecting to the instance directly).
I’m getting the following error when using mssql-cli:
mssql-cli -S 127.0.0.1,3489 -UuserZ-1683210626 -S -Ppassword-LS1Ite7esZ {“error”:“error reading handshake result: failed to read protobuf message: failed to get reader: received close frame: status = StatusInternalError and reason = "refusing to activate session"”} {“error”:“error reading handshake result: failed to read protobuf message: failed to get reader: received close frame: status = StatusInternalError and reason = "refusing to activate session"”}
When connecting through SQL Server Management Studio, the error is:
A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: TCP Provider, error: 0 - The specified network name is no longer available.) (Framework Microsoft SqlClient Data Provider)
As mentioned, Boundary’s range has the same network-level permissions as Vault and I can connect directly to the instance with the crendentials provided that Vault created through a machine in the same range, but not when proxying through Boundary, using either the Desktop Client or CLI. (Unfortunately) running all of this on Windows.
The target database is MSSQL RDS, and I don’t presume there’s any error on the Vault side since the credentials are properly created, but maybe in the way Boundary is trying to handle the proxying (handleProxy?)
Did anyone have success configuring credentials brokering for MSSQL with Vault+Boundary?
Is there anything I need to do on the client side (Windows) to allow proper proxying that I’m maybe overlooking?
I’m not deeply familiar with SQL Server but from what I’m able to find this may be because of a mismatch between the name SQL server is reporting to the client (which the client is then trying to reconnect to it through), and the IP the client actually has access to SQL Server through, because with Boundary proxying the access IP is localhost.
If this is the issue and the name the server reports is a hostname rather than an IP, then mapping the server hostname to 127.0.0.1 in your client’s hosts file locally should make things work. If you’re OK with that, that may be a long-term solution as well.
This is essentially the same reason TLS validation throws errors through Boundary proxying as well – you can connect to a TLS-secured server as a TCP target, but you have to accept warnings about localhost or 127.0.0.1 not being a valid name in the certificate presented by the target service. (How to make this user-friendlier without sacrificing transport security is an active topic of discussion on the Boundary team.)
Thanks a lot for your reply. After investigating further, I’ve also tried to modify the hosts file to point 127.0.0.1 to the server host and also the server name (SELECT @@SERVERNAME), but the error remains, even when trying to listen on the same port as the server is (default, 1433).
If modifying the hosts would fix it, it wouldn’t be a problem, but unfortunately the error remains - and as I’ve mentioned, no issues with the MySQL targets I have in the same setup…
As far as I see you are using as the destination address of mssql-cli - 127.0.0.1 with port 3489. Is this correct?
Would you share the boundary connect command that you are using for creating the localhost listener?
Furthermore, the creds being used are -UuserZ-1683210626 -S -Ppassword-LS1Ite7esZ , how those credentials were retrieved?
Finally, here is a link related to the mssql-cli utility that states for non-default ports the tcp: protocol should be specified in the connection string.
Yes, this is correct. The command for that case would be: boundary connect -target-id $TCP --listen-port $port
Where the port is 3489.
The credentials are retrieved using a credential library from Vault.
Unfortunately I have tried using tcp: and it doesn’t work either. Neither on mssql-cli, SQL Server Management Studio, or DBeaver.
Temporarily I have solved it using a normal SSH tunnel using the Vault-provided credentials and that works fine on all clients, but I don’t have to say that’s less than ideal…
Would you try to specify TrustServerCertificate=True or -C for the mssql-cli in your connection string?
It seems to me that this is related to the TLS connection between the client and the MSSQL server and the introduction of the Boundary proxy between them, at least that is how it looks from my research online.
Thanks @martinhristov90. I’ve already tried that as well, with both mssql-cli and SQL Server Management Studio (in the application settings and also using connection strings on the client). Same issue. And a issue that doesn’t popup with a regular SSH tunnel (no extra settings needed for anything - just connect normally and it’s done).
Here’s something to try, just to try to figure out where the issue is occurring: you said that it works with a normal SSH tunnel – presumably you are tunneling from the local box (from which you are also running boundary connect) to the MSSQL box. If you connect through Boundary to the SSH server on that box (as in, have your target point to port 22) are you able to create an SSH tunnel through Boundary and then run mssql-cli over that successfully?
If you’re not able to make the SSH connection through Boundary then it narrows the issue to the interaction with Boundary versus something specific to connecting to MSSQL via Boundary.
So apparently the mistake was on me for not keeping up with the times. I’ve updated boundary on the controllers and workers on the servers and now everything works as expected with the latest version.