Hi @helmoet - I'm sorry to hear about this!
Have you verified that the SSO Username and Password is using a Service Account with privileges to the Active Directory listings?
One "gotcha" is entering DOMAIN\\USERNAME for the 'Domain Search User' and the 'SSO Username' – the latter should be only USERNAME.
And are you trying to login using Windows Credentials on the same machine that FME Server is installed to? Please try from a different machine.
There are a couple non-FME Server configurations that may apply, so please make sure that all steps are satisfied as noted in documentation.
Hi @Rylan, thanx for the suggestions. Not at the premises right now, so I'll have to check thursday. I'll notice the workforce, they can look into this in the meantime.
Yet I think the service account we're using has rights to the Active Directory listings, since that part seems to work fine. However, a good suggestion is to use another account (for testing)
I'm pretty sure the DOMAIN\\USERNAME gotch did not catch us (we tried both possibilities and kept the good one).
We tried from another machine, that indeed didn't work, we still have to do something on the Tomcat configuration. If we use 'localhost' in the URL, we see the Use Windows Credentials button, however, if we use the fully qualified server name in the URL, we get a different login screen without the button.
However, I checked the External facing URL setting in the Tomcat Properties file, yet no success so far. But for sure, there is some work to do on that file, too.
Hi @Rylan, thanx for the suggestions. Not at the premises right now, so I'll have to check thursday. I'll notice the workforce, they can look into this in the meantime.
Yet I think the service account we're using has rights to the Active Directory listings, since that part seems to work fine. However, a good suggestion is to use another account (for testing)
I'm pretty sure the DOMAIN\\USERNAME gotch did not catch us (we tried both possibilities and kept the good one).
We tried from another machine, that indeed didn't work, we still have to do something on the Tomcat configuration. If we use 'localhost' in the URL, we see the Use Windows Credentials button, however, if we use the fully qualified server name in the URL, we get a different login screen without the button.
However, I checked the External facing URL setting in the Tomcat Properties file, yet no success so far. But for sure, there is some work to do on that file, too.
>If we use 'localhost' in the URL, we see the Use Windows Credentials button, however, if we use the fully qualified server name in the URL, we get a different login screen without the button.
@helmoet - I cannot reproduce this behaviour and I would expect the "Use Windows Credentials" button to appear for both URLs. Please submit a ticket to
Safe Support with the FME Server log files so we can investigate further. It would also be great to test multiple browsers as well to see if there is any change in behaviour (IE, Chrome, Firefox).
On behalf of Helmoet the generated log files during single sign on are attached (.zip)
fme-logging.zip
Hi, I think the username is case sensitive, and this could also cause problems.
On behalf of Helmoet the generated log files during single sign on are attached (.zip)
fme-logging.zip
Thank you for sharing the log files, @gu19495. Unfortunately I could not identify anything – save for the SSO errors in fmeserver.log – that may be the root cause. Please contact
Safe Support to open a support ticket so we can deep dive into the investigation.
After change DEBUG_LEVEL to FINEST (tomcat propertiesFile.properties) interesting logging showed up:
INFORM RequestHandler-Thread 408043 : (Single Sign-On) Enabled single sign-on authentication.
INFORM RequestHandler-Thread 408049 : (Single Sign-On) Using pre-authenticated credentials (for a service account) to create server credentials...
INFORM RequestHandler-Thread 408050 : (Single Sign-On) Created server credentials.
INFORM RequestHandler-Thread 408053 : (Single Sign-On) Negotiation reported an error: "Failure unspecified at GSS-API level (Mechanism level: Encryption type AES256 CTS mode with HMAC SHA1-96 is not supported/enabled)".
WARN RequestHandler-Thread 408058 : (Single Sign-On) Failed authentication because of an negotiation error. Refer to single sign-on documentation for resolution.
ERROR RequestHandler-Thread Single sign-on authentication failed
WARN RequestHandler-Thread 401934 : Failed login by user YIIQWAYGKwYBBQUCoIIQTDCCEEigMDAu... due to insufficient credentials.
We are investigating whether TLS cipher suite EAS265 should be added...
After change DEBUG_LEVEL to FINEST (tomcat propertiesFile.properties) interesting logging showed up:
INFORM RequestHandler-Thread 408043 : (Single Sign-On) Enabled single sign-on authentication.
INFORM RequestHandler-Thread 408049 : (Single Sign-On) Using pre-authenticated credentials (for a service account) to create server credentials...
INFORM RequestHandler-Thread 408050 : (Single Sign-On) Created server credentials.
INFORM RequestHandler-Thread 408053 : (Single Sign-On) Negotiation reported an error: "Failure unspecified at GSS-API level (Mechanism level: Encryption type AES256 CTS mode with HMAC SHA1-96 is not supported/enabled)".
WARN RequestHandler-Thread 408058 : (Single Sign-On) Failed authentication because of an negotiation error. Refer to single sign-on documentation for resolution.
ERROR RequestHandler-Thread Single sign-on authentication failed
WARN RequestHandler-Thread 401934 : Failed login by user YIIQWAYGKwYBBQUCoIIQTDCCEEigMDAu... due to insufficient credentials.
We are investigating whether TLS cipher suite EAS265 should be added...
@gu19495 - Great detective work! The error you have highlighted matches the symptom reported in
this Knowledge Center article. Let us know if the suggested resolution works for you!
@gu19495 - Great detective work! The error you have highlighted matches the symptom reported in
this Knowledge Center article. Let us know if the suggested resolution works for you!
Yep, @RylanAtSafe we found that one, too, We will probably choose the alternative to use a certificate and implement SSL. That will do the trick I suspect, so no support tickets needed. Thankx a lot for all the support. And thanks @gu19495 Andre for the hard work. I will keep this issue informed on the outcome.
Hi, I think the username is case sensitive, and this could also cause problems.
True, definitely true.
@helmoet, @RylanAtSafe thank you for thinking along !!
I installed the Java Cryptography Extension (JCE)
https://knowledge.safe.com/articles/395/enabling-aes256-in-the-java-runtime-environment-fo.html
This did not solve the issue but fmeserver.log now shows this:
INFORM RequestHandler-Thread 408043 : (Single Sign-On) Enabled single sign-on authentication.
INFORM RequestHandler-Thread 408049 : (Single Sign-On) Using pre-authenticated credentials (for a service account) to create server credentials...
INFORM RequestHandler-Thread 408050 : (Single Sign-On) Created server credentials.
INFORM RequestHandler-Thread 408053 : (Single Sign-On) Negotiation reported an error: "Failure unspecified at GSS-API level (Mechanism level: Checksum failed)".
WARN RequestHandler-Thread 408058 : (Single Sign-On) Failed authentication because of an negotiation error. Refer to single sign-on documentation for resolution.
ERROR RequestHandler-Thread Single sign-on authentication failed
WARN RequestHandler-Thread 401934 : Failed login by user YIIQWQYGKwYBBQUCoIIQTTCCEEmgMDAu... due to insufficient credentials.
Windows Domain Configuration is updated with these ServicePrincipalNames:
http/t-fmeserver.gasunie.nl <service account>
http/t-fmeserver <sercice account>
Web Browser configuration is configured as follows:
'Local intranet'. =>
http://t-fmeserver and
http://t-fmeserver.gasunie.nl
'Advanced' tab => Enable Integrated Windows Authentication is checked.
@helmoet, @RylanAtSafe thank you for thinking along !!
I installed the Java Cryptography Extension (JCE)
https://knowledge.safe.com/articles/395/enabling-aes256-in-the-java-runtime-environment-fo.html
This did not solve the issue but fmeserver.log now shows this:
INFORM RequestHandler-Thread 408043 : (Single Sign-On) Enabled single sign-on authentication.
INFORM RequestHandler-Thread 408049 : (Single Sign-On) Using pre-authenticated credentials (for a service account) to create server credentials...
INFORM RequestHandler-Thread 408050 : (Single Sign-On) Created server credentials.
INFORM RequestHandler-Thread 408053 : (Single Sign-On) Negotiation reported an error: "Failure unspecified at GSS-API level (Mechanism level: Checksum failed)".
WARN RequestHandler-Thread 408058 : (Single Sign-On) Failed authentication because of an negotiation error. Refer to single sign-on documentation for resolution.
ERROR RequestHandler-Thread Single sign-on authentication failed
WARN RequestHandler-Thread 401934 : Failed login by user YIIQWQYGKwYBBQUCoIIQTTCCEEmgMDAu... due to insufficient credentials.
Windows Domain Configuration is updated with these ServicePrincipalNames:
http/t-fmeserver.gasunie.nl <service account>
http/t-fmeserver <sercice account>
Web Browser configuration is configured as follows:
'Local intranet'. =>
http://t-fmeserver and
http://t-fmeserver.gasunie.nl
'Advanced' tab => Enable Integrated Windows Authentication is checked.
Hi @gu19495 , some of my colleagues are actively investigating this issue with our dev team. At least one other instance of this error has cropped up and they are checking for common symptoms. As far as your configuration is concerned, it does appear to be correct as you have it posted.
Hi @RylanAtSafe
I can login with my Windows Credentials as long as I type them in, but if I click on "Use Windows Credentials", I get a message saying "You are not authorized to access this web application".
Then I checked the FMEServer.log.
401831 : Accepted new client connection from /127.0.0.1 on port 7,071
408041 : (Login Module) Authenticating single sign-on token "YIIJBwYGKwYBBQUCoIII+zCCCPegMDAu...".
408043 : (Single Sign-On) Enabled single sign-on authentication.
408049 : (Single Sign-On) Using pre-authenticated credentials (for a service account) to create server credentials...
408050 : (Single Sign-On) Created server credentials.
408053 : (Single Sign-On) Negotiation reported an error: "Failure unspecified at GSS-API level (Mechanism level: Checksum failed)".
408058 : (Single Sign-On) Failed authentication because of an negotiation error. Refer to single sign-on documentation for resolution.
Single sign-on authentication failed
401934 : Failed login by user YIIJBwYGKwYBBQUCoIII+zCCCPegMDAu... due to insufficient credentials.
My user ID is all lower case both in AD and in the FME Users.
Since all the FME users have been imported from AD, and they can login with their Windows Credentials, I don't think there is anything wrong with the AD settings. I followed the instruction in https://docs.safe.com/fme/html/FME_Server_Documentation/Content/AdminGuide/IWA.htm for these AD settings.
Hi @RylanAtSafe
I can login with my Windows Credentials as long as I type them in, but if I click on "Use Windows Credentials", I get a message saying "You are not authorized to access this web application".
Then I checked the FMEServer.log.
401831 : Accepted new client connection from /127.0.0.1 on port 7,071
408041 : (Login Module) Authenticating single sign-on token "YIIJBwYGKwYBBQUCoIII+zCCCPegMDAu...".
408043 : (Single Sign-On) Enabled single sign-on authentication.
408049 : (Single Sign-On) Using pre-authenticated credentials (for a service account) to create server credentials...
408050 : (Single Sign-On) Created server credentials.
408053 : (Single Sign-On) Negotiation reported an error: "Failure unspecified at GSS-API level (Mechanism level: Checksum failed)".
408058 : (Single Sign-On) Failed authentication because of an negotiation error. Refer to single sign-on documentation for resolution.
Single sign-on authentication failed
401934 : Failed login by user YIIJBwYGKwYBBQUCoIII+zCCCPegMDAu... due to insufficient credentials.
My user ID is all lower case both in AD and in the FME Users.
Since all the FME users have been imported from AD, and they can login with their Windows Credentials, I don't think there is anything wrong with the AD settings. I followed the instruction in https://docs.safe.com/fme/html/FME_Server_Documentation/Content/AdminGuide/IWA.htm for these AD settings.
Hi @fardosht, I'm really sorry to hear that this has affected yet another user! If you haven't already done so, please contact
Safe Support referencing this Q&A; Thread and include an fmeserver.log file that shows the occurrence of this error. This will ensure that we can formally track the issue.
Note: I have reached out to you from a previous support ticket that might have been opened in relation.
UPDATE: This was resolved by correcting the SPNs registered to the Service Account. Please see
documentation for more details. The
FME Server Troubleshooting Article has been updated.
@helmoet, @RylanAtSafe thank you for thinking along !!
I installed the Java Cryptography Extension (JCE)
https://knowledge.safe.com/articles/395/enabling-aes256-in-the-java-runtime-environment-fo.html
This did not solve the issue but fmeserver.log now shows this:
INFORM RequestHandler-Thread 408043 : (Single Sign-On) Enabled single sign-on authentication.
INFORM RequestHandler-Thread 408049 : (Single Sign-On) Using pre-authenticated credentials (for a service account) to create server credentials...
INFORM RequestHandler-Thread 408050 : (Single Sign-On) Created server credentials.
INFORM RequestHandler-Thread 408053 : (Single Sign-On) Negotiation reported an error: "Failure unspecified at GSS-API level (Mechanism level: Checksum failed)".
WARN RequestHandler-Thread 408058 : (Single Sign-On) Failed authentication because of an negotiation error. Refer to single sign-on documentation for resolution.
ERROR RequestHandler-Thread Single sign-on authentication failed
WARN RequestHandler-Thread 401934 : Failed login by user YIIQWQYGKwYBBQUCoIIQTTCCEEmgMDAu... due to insufficient credentials.
Windows Domain Configuration is updated with these ServicePrincipalNames:
http/t-fmeserver.gasunie.nl <service account>
http/t-fmeserver <sercice account>
Web Browser configuration is configured as follows:
'Local intranet'. =>
http://t-fmeserver and
http://t-fmeserver.gasunie.nl
'Advanced' tab => Enable Integrated Windows Authentication is checked.
Hi @gu19495 - If you are still experiencing issues related to SSO, please contact
Safe Support referencing this Q&A; Thread.
Hi @gu19495, @RylanAtSafe,
We still experience SSL trouble, logging in using typed-in user/password is successful (as long as we type UPPERCASE username), however the SingleSignon button does not work (stating "Login failed, please try again").
What reminds me on the fact that we use IE
for accessing the FME Server UI. I opened the console messages during the log
in to FME Server, with the resulting image below. What strikes me is the last
message, which states that CORS is needed for this action. I don’t know if this
is some kind of error message, yet I take it to be some kind of license check.
“SEC7118:
XMLHttpRequest for
https://fmestartup.safe.com/server/?product=server&platform;=win64&build;_string=FME%20Server%202017.1.1%20-%20Build%2017650%20-%20win64&build;=17650 required Cross Origin Resource Sharing (CORS).”
Would it be possible that this has
something to do with our FME Server / SSL issue?
Regards, Helmoet.
Hi @gu19495, @RylanAtSafe,
We still experience SSL trouble, logging in using typed-in user/password is successful (as long as we type UPPERCASE username), however the SingleSignon button does not work (stating "Login failed, please try again").
What reminds me on the fact that we use IE
for accessing the FME Server UI. I opened the console messages during the log
in to FME Server, with the resulting image below. What strikes me is the last
message, which states that CORS is needed for this action. I don’t know if this
is some kind of error message, yet I take it to be some kind of license check.
“SEC7118:
XMLHttpRequest for
https://fmestartup.safe.com/server/?product=server&platform;=win64&build;_string=FME%20Server%202017.1.1%20-%20Build%2017650%20-%20win64&build;=17650 required Cross Origin Resource Sharing (CORS).”
Would it be possible that this has
something to do with our FME Server / SSL issue?
Regards, Helmoet.
Hi @helmoet - I tested explicitly blocking this URL and it did not appear to affect the login process. Great idea to check the Developer Tools!
I'm not certain but my understanding is fmestartup.safe.com is linked to our Marketing Department – if you navigate to that URL, it displays the latest banner (observed in FME Workbench).
(Tested: FME Server 2018.0 Build 18251 Win64, SSO Enabled)
Hi, I had a similar experience.
I followed the https steps "To use a CA-issued certificate", but I had to import the certificate into ...\\Utilities\\jre\\lib\\security\\cacerts as well before Single Sign-On logins worked.
Hi @helmoet - I'm sorry to hear about this!
Have you verified that the SSO Username and Password is using a Service Account with privileges to the Active Directory listings?
One "gotcha" is entering DOMAIN\\USERNAME for the 'Domain Search User' and the 'SSO Username' – the latter should be only USERNAME.
And are you trying to login using Windows Credentials on the same machine that FME Server is installed to? Please try from a different machine.
There are a couple non-FME Server configurations that may apply, so please make sure that all steps are satisfied as noted in documentation.
Thanks a lot, the 'SSO Username' should be only USERNAME hint made the whole thing work :)
Hi, I had a similar experience.
I followed the https steps "To use a CA-issued certificate", but I had to import the certificate into ...\\Utilities\\jre\\lib\\security\\cacerts as well before Single Sign-On logins worked.
@RylanAtSafe is it necessary to have SSL enabled to use SSO? I'm using FME Server 2018.1.1.1 - Build 18578 - win64
@helmoet and @RylanAtSafe did you ever find a resolution for this issue? I've double checked the SPN settings, case sensitivity of the "Service Account Name" (without domain specified) and added the crypto libraries as suggested in a commend above. Nevertheless I am still experiencing problems connecting with SSO with the error log below. We're using FME Server 2018.1.1.1 - Build 18578 - win64
INFORM pool-3-thread-1 408078 : (Active Directory) Connecting using directory configuration "mydomain.com"...
INFORM pool-3-thread-1 408001 : (Active Directory) Connecting to an available server in ( DCSERVER.mydomain.com:389 )...
INFORM pool-3-thread-1 408002 : (Active Directory) Successfully connected to DCSERVER.mydomain.com.
INFORM pool-3-thread-1 408065 : (Active Directory) Connected server is an Active Directory server.
INFORM pool-3-thread-1 408066 : (Active Directory) Default user name attribute is "sAMAccountName".
INFORM pool-3-thread-1 408067 : (Active Directory) Default user full name attribute is "displayName".
INFORM pool-3-thread-1 408073 : (Active Directory) Default user mail attribute is "mail".
INFORM pool-3-thread-1 408068 : (Active Directory) Default group name attribute is "sAMAccountName".
INFORM pool-3-thread-1 408004 : (Active Directory) Found default search base "DC=mydomain,DC=com".
INFORM pool-3-thread-1 408037 : (Active Directory) Using connected server "DCSERVER.mydomain.com" as KDC.
INFORM pool-3-thread-1 408038 : (Active Directory) Using domain name of connected server "mydomain.com" as realm.
INFORM pool-3-thread-1 408029 : (Active Directory) Found supported SASL mechanism "GSSAPI".
INFORM pool-3-thread-1 408029 : (Active Directory) Found supported SASL mechanism "GSS-SPNEGO".
INFORM pool-3-thread-1 408029 : (Active Directory) Found supported SASL mechanism "EXTERNAL".
INFORM pool-3-thread-1 408029 : (Active Directory) Found supported SASL mechanism "DIGEST-MD5".
INFORM pool-3-thread-1 408040 : (Active Directory) Configured to use simple authentication.
INFORM pool-3-thread-1 408007 : (Active Directory) Authenticating user "mydomain\svcMyServiceAccount"...
INFORM pool-3-thread-1 408060 : (Active Directory) Successfully connected to DCSERVER.mydomain.com.
INFORM pool-3-thread-1 408079 : (Active Directory) Successfully connected using directory configuration "mydomain.com" and encountered 0 errors.
INFORM Health Check Thread for LDAPConnectionPool(serverSet=RoundRobinServerSet(servers={DCSERVER.mydomain.com:389}), maxConnections=100) 408060 : (Active Directory) Successfully connected to DCSERVER.mydomain.com.
INFORM RequestHandler-Thread 401831 : Accepted new client connection from /127.0.0.1 on port 7071
INFORM RequestHandler-Thread 408053 : (Single Sign-On) Negotiation reported an error: "Failure unspecified at GSS-API level (Mechanism level: Checksum failed)".
WARN RequestHandler-Thread 408058 : (Single Sign-On) Failed authentication because of an negotiation error. Refer to single sign-on documentation for resolution.
ERROR RequestHandler-Thread Single sign-on authentication failed
WARN RequestHandler-Thread 401934 : Failed login by user YIIQbwYGKwYBBQUCoIIQYzCCEF+gMDAu... due to insufficient credentials.
What is this user specified in the log file? How can we make sense of that value? YIIQbwYGKwYBBQUCoIIQYzCCEF+gMDAu...
@RylanAtSafe is it necessary to have SSL enabled to use SSO? I'm using FME Server 2018.1.1.1 - Build 18578 - win64
@justincornell - No, it is not necessary.
@helmoet and @RylanAtSafe did you ever find a resolution for this issue? I've double checked the SPN settings, case sensitivity of the "Service Account Name" (without domain specified) and added the crypto libraries as suggested in a commend above. Nevertheless I am still experiencing problems connecting with SSO with the error log below. We're using FME Server 2018.1.1.1 - Build 18578 - win64
INFORM pool-3-thread-1 408078 : (Active Directory) Connecting using directory configuration "mydomain.com"...
INFORM pool-3-thread-1 408001 : (Active Directory) Connecting to an available server in ( DCSERVER.mydomain.com:389 )...
INFORM pool-3-thread-1 408002 : (Active Directory) Successfully connected to DCSERVER.mydomain.com.
INFORM pool-3-thread-1 408065 : (Active Directory) Connected server is an Active Directory server.
INFORM pool-3-thread-1 408066 : (Active Directory) Default user name attribute is "sAMAccountName".
INFORM pool-3-thread-1 408067 : (Active Directory) Default user full name attribute is "displayName".
INFORM pool-3-thread-1 408073 : (Active Directory) Default user mail attribute is "mail".
INFORM pool-3-thread-1 408068 : (Active Directory) Default group name attribute is "sAMAccountName".
INFORM pool-3-thread-1 408004 : (Active Directory) Found default search base "DC=mydomain,DC=com".
INFORM pool-3-thread-1 408037 : (Active Directory) Using connected server "DCSERVER.mydomain.com" as KDC.
INFORM pool-3-thread-1 408038 : (Active Directory) Using domain name of connected server "mydomain.com" as realm.
INFORM pool-3-thread-1 408029 : (Active Directory) Found supported SASL mechanism "GSSAPI".
INFORM pool-3-thread-1 408029 : (Active Directory) Found supported SASL mechanism "GSS-SPNEGO".
INFORM pool-3-thread-1 408029 : (Active Directory) Found supported SASL mechanism "EXTERNAL".
INFORM pool-3-thread-1 408029 : (Active Directory) Found supported SASL mechanism "DIGEST-MD5".
INFORM pool-3-thread-1 408040 : (Active Directory) Configured to use simple authentication.
INFORM pool-3-thread-1 408007 : (Active Directory) Authenticating user "mydomain\svcMyServiceAccount"...
INFORM pool-3-thread-1 408060 : (Active Directory) Successfully connected to DCSERVER.mydomain.com.
INFORM pool-3-thread-1 408079 : (Active Directory) Successfully connected using directory configuration "mydomain.com" and encountered 0 errors.
INFORM Health Check Thread for LDAPConnectionPool(serverSet=RoundRobinServerSet(servers={DCSERVER.mydomain.com:389}), maxConnections=100) 408060 : (Active Directory) Successfully connected to DCSERVER.mydomain.com.
INFORM RequestHandler-Thread 401831 : Accepted new client connection from /127.0.0.1 on port 7071
INFORM RequestHandler-Thread 408053 : (Single Sign-On) Negotiation reported an error: "Failure unspecified at GSS-API level (Mechanism level: Checksum failed)".
WARN RequestHandler-Thread 408058 : (Single Sign-On) Failed authentication because of an negotiation error. Refer to single sign-on documentation for resolution.
ERROR RequestHandler-Thread Single sign-on authentication failed
WARN RequestHandler-Thread 401934 : Failed login by user YIIQbwYGKwYBBQUCoIIQYzCCEF+gMDAu... due to insufficient credentials.
What is this user specified in the log file? How can we make sense of that value? YIIQbwYGKwYBBQUCoIIQYzCCEF+gMDAu...
Hi @justincornell – I'm sorry to hear another user has encountered this! I don't think there had been any changes to the product as a result of the issue presented in this Q&A thread. It likely did not escalate after being resolved by (at least one of) the two solutions suggested here.
However, as you note that they have not worked – please contact Safe Support for further assistance. If you reference this Q&A URL, it will be helpful.
The user denoted "YIIQbwYGKwYBBQUCoIIQYzCCEF+gMDAu.." refers to an internal token that the product defaults to in this scenario. You will notice this error for different users. I don't have any developers on hand I can ask right now (Christmas holidays!) but it is an encrypted value nonetheless. It shows up only in relation to specific login issues – usually related to AD configurations.
Hi @justincornell – I'm sorry to hear another user has encountered this! I don't think there had been any changes to the product as a result of the issue presented in this Q&A thread. It likely did not escalate after being resolved by (at least one of) the two solutions suggested here.
However, as you note that they have not worked – please contact Safe Support for further assistance. If you reference this Q&A URL, it will be helpful.
The user denoted "YIIQbwYGKwYBBQUCoIIQYzCCEF+gMDAu.." refers to an internal token that the product defaults to in this scenario. You will notice this error for different users. I don't have any developers on hand I can ask right now (Christmas holidays!) but it is an encrypted value nonetheless. It shows up only in relation to specific login issues – usually related to AD configurations.
@RylanAtSafe thanks for the response. I've submitted a case with support. When I get a resolution I'll make sure I post it here for others. Even if it's a silly mistake on my part 
@helmoet and @RylanAtSafe did you ever find a resolution for this issue? I've double checked the SPN settings, case sensitivity of the "Service Account Name" (without domain specified) and added the crypto libraries as suggested in a commend above. Nevertheless I am still experiencing problems connecting with SSO with the error log below. We're using FME Server 2018.1.1.1 - Build 18578 - win64
INFORM pool-3-thread-1 408078 : (Active Directory) Connecting using directory configuration "mydomain.com"...
INFORM pool-3-thread-1 408001 : (Active Directory) Connecting to an available server in ( DCSERVER.mydomain.com:389 )...
INFORM pool-3-thread-1 408002 : (Active Directory) Successfully connected to DCSERVER.mydomain.com.
INFORM pool-3-thread-1 408065 : (Active Directory) Connected server is an Active Directory server.
INFORM pool-3-thread-1 408066 : (Active Directory) Default user name attribute is "sAMAccountName".
INFORM pool-3-thread-1 408067 : (Active Directory) Default user full name attribute is "displayName".
INFORM pool-3-thread-1 408073 : (Active Directory) Default user mail attribute is "mail".
INFORM pool-3-thread-1 408068 : (Active Directory) Default group name attribute is "sAMAccountName".
INFORM pool-3-thread-1 408004 : (Active Directory) Found default search base "DC=mydomain,DC=com".
INFORM pool-3-thread-1 408037 : (Active Directory) Using connected server "DCSERVER.mydomain.com" as KDC.
INFORM pool-3-thread-1 408038 : (Active Directory) Using domain name of connected server "mydomain.com" as realm.
INFORM pool-3-thread-1 408029 : (Active Directory) Found supported SASL mechanism "GSSAPI".
INFORM pool-3-thread-1 408029 : (Active Directory) Found supported SASL mechanism "GSS-SPNEGO".
INFORM pool-3-thread-1 408029 : (Active Directory) Found supported SASL mechanism "EXTERNAL".
INFORM pool-3-thread-1 408029 : (Active Directory) Found supported SASL mechanism "DIGEST-MD5".
INFORM pool-3-thread-1 408040 : (Active Directory) Configured to use simple authentication.
INFORM pool-3-thread-1 408007 : (Active Directory) Authenticating user "mydomain\svcMyServiceAccount"...
INFORM pool-3-thread-1 408060 : (Active Directory) Successfully connected to DCSERVER.mydomain.com.
INFORM pool-3-thread-1 408079 : (Active Directory) Successfully connected using directory configuration "mydomain.com" and encountered 0 errors.
INFORM Health Check Thread for LDAPConnectionPool(serverSet=RoundRobinServerSet(servers={DCSERVER.mydomain.com:389}), maxConnections=100) 408060 : (Active Directory) Successfully connected to DCSERVER.mydomain.com.
INFORM RequestHandler-Thread 401831 : Accepted new client connection from /127.0.0.1 on port 7071
INFORM RequestHandler-Thread 408053 : (Single Sign-On) Negotiation reported an error: "Failure unspecified at GSS-API level (Mechanism level: Checksum failed)".
WARN RequestHandler-Thread 408058 : (Single Sign-On) Failed authentication because of an negotiation error. Refer to single sign-on documentation for resolution.
ERROR RequestHandler-Thread Single sign-on authentication failed
WARN RequestHandler-Thread 401934 : Failed login by user YIIQbwYGKwYBBQUCoIIQYzCCEF+gMDAu... due to insufficient credentials.
What is this user specified in the log file? How can we make sense of that value? YIIQbwYGKwYBBQUCoIIQYzCCEF+gMDAu...
Hi @justincornell @RylanAtSafe @gu19495 sorry, this item did not get full priority for us. We still did not resolve this issue. What struck me recently is that we could use both FME Server credentials AND Active Directory logins (i.e., typed in, not through the "Use Windows Credentials" button) to log in FME Server (we're using FME Server 2017.1).
