I'm trying to think of the best way to populate this. In other usage, I see serverSpn getting set as the resource and dataSource getting set as the serverName. I think it makes sense to continue that pattern here given that serverName and server SPN may be different.

I'm also not sure how to feel about authority. In federated auth, it's assumed that authority will be present, but here we don't set a value.

Let me chat with the team to see if we'd prefer to create a new type to better represent this set of credentials.

Sounds good. I refactored the builder so that the same pattern can be had wherever it's used if we want to use the existingSqlAuthenticationParameters

I'm probably missing something, but from my understandingSspiContextProvider attempts to generate sspi context by iterating over eachserverSpns (which is passed viaauthParams.Resource). But because_negotiateAuth is cached here, if it fails for the first spn, it's also going to fail for the others since it's going to be the exact same spn.

You're right, nice catch! The implementation used to reset _negotiateAuth to null if authentication failed, but that's missing now.@twsouthwick can we correct it in a follow up PR?

Will do - good catch. I'll open a separate PR for that.

The looping was added independently of the work I've been doing, so I'm not fully aware of how it's expected to work.

It opens a question as to the design I've moved this to - if we have a list of SPNs, what's the expected outcome? I think things will be just fine if it's the first SPN that completes the SSPI handshake. However if it's the second, on subsequent attempts it will be trying the first again. I can update the SspiContextProvider base to keep track of what was the successfull SPN to only submit that on subsequent calls.

Here's the PR to add that back:#3347