You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The is currently no mechanism to age credentials that get cached when calling Set-DMDomainContext (which happens automatically in every single test or invoke command).
These are then later used for resilient cross-domain identity resolution in Get-Principal and Convert-Principal.
The problem here is: If the credentials change later on, all subsequent attempts to connect to the domain fail due to bad password. This is a common event when using sensitive Break Glass accounts.
Solution Ideas:
Implement a Clear-DMDomainCredential command
Maybe integrate that command the ADMF domain commands
Better error handling for those instances with better user information
Maybe purge cached credentials when authentication fails
Convert-Principal
Should use specified credentials if specified, at least as a fallback
ADMF Credential Providers
Temporary credentials would be cached (and used). If the workflow later resets the password, subsequent connections without a CredentialProvider would still be using the bad password.
The text was updated successfully, but these errors were encountered:
Currently implemented and pending release: Reset-DMDomainCredential
Allows targeted clearing of cached credentials, enabling workflows such as ADMF Credential Providers to clear their own creds without affecting other cached entries.
The is currently no mechanism to age credentials that get cached when calling
Set-DMDomainContext
(which happens automatically in every single test or invoke command).These are then later used for resilient cross-domain identity resolution in
Get-Principal
andConvert-Principal
.The problem here is: If the credentials change later on, all subsequent attempts to connect to the domain fail due to bad password. This is a common event when using sensitive Break Glass accounts.
Solution Ideas:
Should use specified credentials if specified, at least as a fallback
Temporary credentials would be cached (and used). If the workflow later resets the password, subsequent connections without a CredentialProvider would still be using the bad password.
The text was updated successfully, but these errors were encountered: