Set-DbaLogin - Return the login as it is after unlocking it with a new password

[andreasjordan]

Important

One test in this PR will fail on CI, on purpose. The runners have no account lockout threshold, so a login cannot be locked out there and unlocks a login that was locked out cannot pass. See #10529 for what has to change on the runner image. Skipping the test instead would hide the very regression this PR fixes, so it is left enabled and red until the runners are configured. Everything else in the file passes.

The bug

Unlocking a login by setting a new password calls Login.ChangePassword($NewSecurePassword, $Unlock, $PasswordMustChange), which really does clear the lock on the instance. But the login object was only refreshed when -PasswordMustChange was bound, so in every other case the object returned still reported IsLocked as $true:

locked before unlock (server): 1
returned object IsLocked : True
server says IsLocked     : 0

Anyone checking the result had to conclude the unlock had failed while the instance said it had worked. The object is refreshed in both cases now.

Why nobody noticed

The test file was invisible. Its integration Context was skipped with a name of "???" and a # TODO: Fix later, and its -TestCases were built in a BeforeAll, which runs after discovery, so the cases were empty. Pester 5 silently produced no tests from an empty case list; Pester 6 fails the file during discovery instead, which is how this surfaced.

With the cases built in BeforeDiscovery and the Context named and enabled, the file runs 45 tests instead of 1.

The lockout tests needed a second fix

Two tests lock a login out by failing five logons. After a failed logon SqlClient blocks the connection pool for a growing number of seconds and answers the following attempts itself, so most of those logons never reached the instance. BadPasswordCount plateaued at 3 no matter how many attempts were made, even with the Start-Sleep -s 5 the test already had, so the login was never locked.

They use -NonPooledConnection now. The bad password count then climbs one per attempt and the login locks exactly at the threshold, which also makes the sleeps unnecessary and the file faster.

Testing

Against a lab whose host has an account lockout threshold of 5: 45 passed, 0 failed, 0 skipped, 0 warnings.

The precondition is only the threshold. SQL Server reads it from the local policy of the host running the instance, not from the domain policy - verified in a lab where the domain has no threshold and the local one has five, and the lockout follows the local value.

After #10529

Once the runners have a threshold, this test passes on CI unchanged. No follow-up change to this file is needed.

🤖 Generated with Claude Code

[potatoqualitee]

Genuine failure, unfortunately (isn't it nice that we mostly get genuine errors nowadays?)

[potatoqualitee]

oh no! undo undo

[potatoqualitee]

Merged by accident, lemme see how to fix

[andreasjordan]

Just skip the one test again.

[potatoqualitee]

i reverted it, looks like it'll need a new PR, sorry

[andreasjordan]

No problem, I still have the local branch. Will open a new pr after the environment change.