When using kerberos it is imperative that both the application and the domain controller trust each other. If either server finds a reason not to trust the other they should abort all communication.
When you are not implementing the security chain according this statement you are creating some significant gaps in your security.
I'm saying this because the security of kerberos is based on the truststore, this trust store is critical in allowing only legitimate applications to access user and password information. It is impossible to authenticate with Kerberos without setting up the truststore.
On the Domain Controller, you will have to generate a keytab file. This keytab file needs to be identified on the DC with the correct principal. If your principle used for generating the keytab file is different from the actual principle you will get unexplainable certification errors.
(The principal is the name/identifier under which the DC can access the app server, this can be an ip-address or servername. You can find the principal name using a reverse DNS lookup)
Once you have the keytab file you also have to register your app under a trusted Service Principal Name (SPN). This is to make sure that the DC allows your server to initiated contact with the proper url and credentials.
Once the keytab and SPN are correctly registered, under an active account in the DC you need to make sure all info given in the previous process is a 100% match to your sso properties.
If all your information given in the DC is accurate you can login without any issues.