Jenkins setup was configured to talk to AD via SAML,  Users could login via SAML and Jenkins could show AD groups associated with users. All working as expected.

A plugin update was available which required Jenkins to be restarted. Upon initiating the plugin update and requesting Jekins to restart resulted in users being locked out with an OOPS message.

Restarting Jenkins service either via the WebUI or manually from the backend (systemctl restart) appears to re-generate the contents (x509Certificate data) in JENKINS_HOME/saml-sp-metadata.xml . Thus user is locked out with the following OOPs being reported;

org.pac4j.saml.exceptions.SAMLException: Authentication response is not success ; actual urn:oasis:names:tc:SAML:2.0:status:Responder

Not sure if regenerating the contents of saml-sp-metadata.xml is expected behaviour by design for perhaps security reasons?  

Not sure if its because the contents of JENKINS_HOME/saml-sp-metadata.xml  is the root cause for the lockout.

Possible Workarounds;

1. Send new JENKINS_HOME/saml-sp-metadata.xml  file to IT team to import into AD server - need to confirm this works without further hacking. This worked and got me working again - but not an ideal workaround where IT team is subcontracted out in a different time zone.
2. Attempt to restore a backup copy of $JENKINS_HOME/saml-sp-metadata.xml  - attempted but this didn't work, this would be least disruptive and quicker turn around.
3. Hack $JENKINS_HOME/config.xml to disable SAML plugin to gain access - this worked, but a bit of a pain!