Kerberos SSO without presence of Certificate Authority

Is it possible to run the Kerberos WinSSO module in a project, in an environment where the Domain Controller does not have a certificate truststore? We are currently trying to implement this module at our customer, but are facing constant 'GSSHeader could not find the right tag' errors, despite having followed the instructions provided in the documentation. Internet Explorer 10 was setup accordingly, as was Firefox. However, each time we try to access the /sso/ we get the invalid token error. The m2ee_log shows that the principal is correctly identified and that even tickets are created and added to the cache. A message that the system administrator did manage to find is that no certificate could be found. Could this be the cause for the SSO to fail? And if so, is there any way that Kerberos SSO authentication could be made possible without the need for a certificate to be present on the domain controller? Further info: Application is running on premise, Windows Server 2008 R2. Internet Explorer 10, latest Firefox.
1 answers

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.