Login.ChangePassword() leaves MustChangePassword and IsLocked stale - the property bag is never updated or invalidated

Iniziare da src/Microsoft/SqlServer/Management/Smo/LoginBase.cs, leggendo gli overload di ChangePassword e ExecuteLoginPasswordOptions, quindi confrontarne il comportamento con SetMustChangePassword. Dopo un'esecuzione riuscita senza registrazione, invalidare le proprietà memorizzate nella cache interessate, in modo che le letture sullo stesso oggetto riflettano il risultato di ALTER LOGIN per MustChangePassword, IsLocked, IsPasswordExpired, IsMustChange, PasswordLastSetTime e PasswordHash.

After a successful Login.ChangePassword(newPassword, unlock: true, mustChange: true), reading login.MustChangePassword on the same object still returns the old value (typically False) until Refresh() is called. The same applies to the other properties the ALTER changes: IsLocked after an unlock, IsPasswordExpired, PasswordLastSetTime, IsMustChange.

This is the same object-cache pattern as #40 (Database.SetOwner() not updating .Owner): a method executes DDL immediately but neither updates nor invalidates the cached properties it just changed on the server.

Repro

$login = $server.Logins["testlogin"]   # SQL login, MustChangePassword currently False
$login.ChangePassword("N3wP@ssw0rd!", $true, $true)
$login.MustChangePassword              # False - stale; the server says otherwise:
# SELECT LOGINPROPERTY('testlogin', 'IsMustChange')  --> 1
$login.Refresh()
$login.MustChangePassword              # True

dbatools carries the workaround with the comment "We need to refresh login after ChangePassword. Otherwise, MustChangePassword will appear as False" (New-DbaLogin.ps1#L610-L611), and its Set-DbaLogin re-reads the login after unlocking for the same reason.

Mechanism

All ChangePassword overloads (LoginBase.cs#L142-L282) end in ExecuteLoginPasswordOptions (LoginBase.cs#L533-L555), which builds ALTER LOGIN ... WITH PASSWORD=... [UNLOCK] [MUST_CHANGE] and runs ExecutionManager.ExecuteNonQuery — and returns. Nothing touches the property bag.

A helper that does update the bag exists — SetMustChangePassword (LoginBase.cs#L334-L347) — but it early-returns unless the object is in design mode, and is only called from Create().

Suggested fix

After a successful non-recording execution, invalidate the affected cached properties so the next read fetches current values from the server — the approach proposed for #40 in PR #231. For ChangePassword that covers at least MustChangePassword, IsLocked, IsPasswordExpired, IsMustChange, PasswordLastSetTime, PasswordHash.

Happy to submit a PR along those lines if that helps.

This was created by Claude and reviewed by Andreas Jordan.