Before we start a few things to keep in mind... troubleshooting anything to do with the loginwindow can get rather tricky quickly.
Before beginning to explore with NoMAD Login you should have a few things in place.
It's best to do all testing in a virutal machine. Especially one that you can snapshot and roll back. This is the single best thing you can do for troubleshooting purposes.
Keep an ssh session into the system with a root shell. This should allow you to undo any damage you've done.
Have a copy of the output of security authorizationdb read system.login.console from a standard install around. If you need to remove anything that NoMAD Login has done, you'll want to upload that.
There's a few things that you should check when things go wrong.
Smack the permissions on the plugin itself. sudo chmod -R 755 /Library/Security/SecurityAgentPlugins/ When copying the plugin around these can sometimes get munged.
Check the authorizationdb and ensure that the proper mechs are running and are privileged if necessary. This can be done with security authorizationdb read system.login.consoleNoMADLogin:CheckAD and NoMADLogin:CreateUser,privileged should be in the list for basic NoMAD Login AD functionality.
Here's how to revert things back to normal when they go wrong.
First load back the original authorization rule, the one that you saved before starting or you get from another machine. security authorizationdb write system.login.console < original.txt
Reload the loginwindow with kill <loginwindow PID> with the appropriate loginwindow process ID. Note: you can do a killall loginwindow but that will kill any fast use switching sessions you may have going on the machine.
While there's no need to remove the actual NoMAD Login plugin itself... you can if you want to from /Library/Security/SecurityAgentPlugins/
You can do all of this from that root ssh shell you had going.
When it gets really funky...
If things are very strange, or you just want to get logging, you can either use the log command from your root shell, or sign in as a user and open Console.app and leave it running.
Then fast user switch to the loginwindow and attempt to login. If that doesn't work, reset the loginwindow to a working state, ensuring you only kill loginwindow process owned by root and not the user that's already signed in. Sign in as the use with Console running and grab the logs.
Last chance desperation moves
If you are totally busted and can't login you can still recover things by moving the authorizationdb out of the way and letting the system replace it with a default copy.
Boot into single user mode (Recovery Mode on macOS 10.14+) and follow the check and mount prompts.
Rename the existing database mv /var/db/auth.db /var/db.auth.db.bak
Logout and let the Mac finish booting.
Now you should be back to the standard Apple login screen.