Address issue where we connect using Windows Auth when Credential is provided

[wsmelton]

Type of Change

• Bug fix ( non-breaking change, fixes Test-DbaIdentityUsage attempts using current Windows account before specified -SqlCredential #2012 )
• New feature (non-breaking change, adds functionality)
• Breaking change (affects multiple commands or functionality)
• Ran manual Pester test and has passed (`.\tests\manual.pester.ps1)
• Pester test is included

Purpose

It was found after debugging and stepping through Connect-SqlServer that when a credential object is passed in, or the -MinimumVersion parameter was used in a command that an attempt is made to connect to the given SQL Server instance. This allows for an unknown login attempt by the account running the PowerShell session/host.

The main issue where this is found is when the account running the PowerShell host does not have access to the given SQL Server instance. The instance will log multiple login failed attempts just by executing a single command. If a credential (e.g. SQL Login) is provided it still attempts to login as the account running the PowerShell host. [See learning section below.]

Approach

By provided a known bogus server name then no connection will be made until the $server.ConnectionContext.Connect() line of either command is executed.

Commands to test

Appveyor test should run enough as the Pester test utilize Connect-DbaSqlServer and then the commands run in the integration test call Connect-SqlInstance.

Screenshots

Will provide a blog post that details how this was identified in debugging.

Learning

This was one of those "after I saw it I knew/recall why this happens".

The general reasoning is just executing this command in a PowerShell host will cause an attempted connection to the localhost:

New-Object Microsoft.SqlServer.Management.Smo.Server

If the localhost does not have SQL Server running, then you will never notice anything. If the localhost has SQL Server running, but the account executing it does not have access then a login failed message will be logged, but you will not see any error posted to the PowerShell host.

So as we do this in our code (or close to it):

$server = New-Object Microsoft.SqlServer.Management.Smo.Server $SqlInstance

This will try to immediately connect to the $SqlInstance as soon as that line is run. Then, as well, any subsequent line that accesses the $server object will cause additional login attempts to be performed.

The only workaround to this is to pass in a bogus server to the initial New-Object so it connects to nothing. That is the sole purpose in this ([System.Guid]::NewGuid()). PowerShell 5 offers New-Guid but in order to support back to PowerShell 3 we have to use the System.Guid 's NewGuid() method.

[wsmelton]

There is a potential this will also fix #1190

[wsmelton]

All main test completed successfully. The failures are with the snapshot test.