Writes a new password to memory on the host ("mimikatz") that will work in addition to the real password for any user.
(switching to an attacker machine with no AD credentials; and the "administrator" password is not "mimikatz")
A little more context:
The Mimikatz skeleton feature allows us to write a patch in the process memory for LSASS that will allow authentication as any domain user using the password "mimikatz".
It's a post exploitation / persistence attack requiring domain administrator level privileges (and access to a domain controller).
Rather than attacking the authentication protocol in flight, the patched lsass process will start to compare the hash that was sent in as an authentication request with the hash stored in active directory for the requested user. The AD side of the comparison will be patched over with the hash for the string "mimikatz", ensuring that a match is found and authentication will succeed.
When it fails...
If the administrative team have enabled lsass process protection you might have an additional hurdle to clear.
Lsass process protection "provides additional protection for the LSA to prevent reading memory and code injection by non-protected processes. This provides added security for the credentials that the LSA stores and manages"
It is configured via a registry key that may be set either manually, or via group policy (preferences):
(In case you are wondering, the main reason people have for not doing this is compatibility with LSA plug-ins for things like smartcard drivers that may not meet the strict requirements of those allowed by lsass process protection. You should test first; the Microsoft article linked above helps).
When you hit this hurdle, it will look more like this:
To get around it, you need to load the service using "!+", then use the "!processprotect /process:lsass.exe /remove" command.