Skip to main content
Solved

FME Server Single Sign-On refuses logins while Active Directory login works fine

  • November 13, 2017
  • 30 replies
  • 753 views
Show first post
This post is closed to further activity.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.

30 replies

J
Forum|alt.badge.img+1

Greetings @helmoet @RylanAtSafe.  We figured it out!!  I worked with @RichardAtSafe via a support ticket and it turned out the SPN's were to blame.  So the moral of the story is while the SIGNGLE_SIGN_ON_URL can be the CNAME in tomcat properties file and the url in the browser to FME Server can be a CNAME, there MUST be a SPN registration for the HOST name of the computer.  Below are the commands we ran to get it to work with the CNAME as the url.  The CNAME entries are needed to allow the server to be accessed via the friendly name in the browser and the host names are needed to allow SSO for FME Server.  The bold commands below were what fixed the issue.

 

CNAME SPN registrations

setspn -S http/testfme svcMyServiceAccount
setspn -S http/testfme.mydomain.com svcMyServiceAccount 

 

HOST (machine name) SPN registrations

setspn -S http/MyMachineName svcMyServiceAccount 
setspn -S http/MyMachineName.mydomain.com svcMyServiceAccount

 

Essentially what I think is happening is that when a Kerberos ticket is attempted to be generated it's using the machine name (HOST) despite the URL that is being specified in the SINGLE_SING_ON_URL.  It's likely a server side process generating the Keberos ticket which would mean the machine name needs to be registered with a SPN.

 

Hope this helps someone else figure this out.  

 

 

davidwilton
Contributor
Forum|alt.badge.img+1
  • davidwiltonContributor
  • Contributor
  • July 25, 2025

Greetings @helmoet @RylanAtSafe.  We figured it out!!  I worked with @RichardAtSafe via a support ticket and it turned out the SPN's were to blame.  So the moral of the story is while the SIGNGLE_SIGN_ON_URL can be the CNAME in tomcat properties file and the url in the browser to FME Server can be a CNAME, there MUST be a SPN registration for the HOST name of the computer.  Below are the commands we ran to get it to work with the CNAME as the url.  The CNAME entries are needed to allow the server to be accessed via the friendly name in the browser and the host names are needed to allow SSO for FME Server.  The bold commands below were what fixed the issue.

 

 

CNAME SPN registrations

setspn -S http/testfme svcMyServiceAccount
setspn -S http/testfme.mydomain.com svcMyServiceAccount 

 

 

HOST (machine name) SPN registrations

setspn -S http/MyMachineName svcMyServiceAccount 
setspn -S http/MyMachineName.mydomain.com svcMyServiceAccount

 

 

Essentially what I think is happening is that when a Kerberos ticket is attempted to be generated it's using the machine name (HOST) despite the URL that is being specified in the SINGLE_SING_ON_URL.  It's likely a server side process generating the Keberos ticket which would mean the machine name needs to be registered with a SPN.

 

 

Hope this helps someone else figure this out.  

 

 

 

 

​@rylanatsafe we are having this same issue, however, it is no longer possible to had both the CNAME and the machine name. However, it seems that Microsoft tightened up the uniqueness and if it matches the machine name you can no longer add it “After November 2021 patch Microsoft (KB5008382) has increased SPN uniqueness requirements for SPNs covered by the "HOST" spn”. If you try you get the error 

“the operation failed because SPN value provided for addition/modification is not unique forest-wide.”

 

We did add the machine name to SPN with the port :443 (and the CNAME without port), however, the issue persists. Any other suggestions as to how to work out the cause of the issue?


hu-24-July-2025 09:43:23.866 am   INFORM   requesthandler   408038 : Using domain name of connected server "EXAMPLE.COM" as realm.
Thu-24-July-2025 09:43:23.867 am   INFORM   requesthandler   408029 : Found supported SASL mechanism "GSSAPI".
Thu-24-July-2025 09:43:23.868 am   INFORM   requesthandler   408029 : Found supported SASL mechanism "GSS-SPNEGO".
Thu-24-July-2025 09:43:23.869 am   INFORM   requesthandler   408029 : Found supported SASL mechanism "EXTERNAL".
Thu-24-July-2025 09:43:23.870 am   INFORM   requesthandler   408029 : Found supported SASL mechanism "DIGEST-MD5".
Thu-24-July-2025 09:43:23.871 am   INFORM   requesthandler   408032 : Configured to use SASL mechanism "GSSAPI" for authentication.
Thu-24-July-2025 09:43:23.919 am   INFORM   requesthandler   408060 : Successfully connected to abc.example.com.
Thu-24-July-2025 09:43:23.928 am   INFORM   requesthandler   408049 : (Single Sign-On)   Using pre-authenticated credentials (for a service account) to create server credentials...
Thu-24-July-2025 09:43:24.197 am   INFORM   requesthandler   408050 : (Single Sign-On)   Created server credentials.
Thu-24-July-2025 09:43:24.204 am   INFORM   requesthandler   408053 : (Single Sign-On)   Negotiation reported an error: "Failure unspecified at GSS-API level (Mechanism level: Checksum failed)".
Thu-24-July-2025 09:43:24.206 am   WARN     requesthandler   408058 : (Single Sign-On)   Failed authentication because of an negotiation error. Refer to single sign-on documentation for resolution.
Thu-24-July-2025 09:43:26.693 am   INFORM   requesthandler   408053 : (Single Sign-On)   Negotiation reported an error: "Failure unspecified at GSS-API level (Mechanism level: Checksum failed)".
Thu-24-July-2025 09:43:26.694 am   WARN     requesthandler   408058 : (Single Sign-On)   Failed authentication because of an negotiation error. Refer to single sign-on documentation for resolution.
Thu-24-July-2025 09:44:00.980 am   INFORM   requesthandler   408053 : (Single Sign-On)   Negotiation reported an error: "Failure unspecified at GSS-API level (Mechanism level: Checksum failed)".
Thu-24-July-2025 09:44:00.981 am   WARN     requesthandler   408058 : (Single Sign-On)   Failed authentication because of an negotiation error. Refer to single sign-on documentation for resolution.

davidwilton
Contributor
Forum|alt.badge.img+1
  • davidwiltonContributor
  • Contributor
  • July 29, 2025

Greetings @helmoet @RylanAtSafe.  We figured it out!!  I worked with @RichardAtSafe via a support ticket and it turned out the SPN's were to blame.  So the moral of the story is while the SIGNGLE_SIGN_ON_URL can be the CNAME in tomcat properties file and the url in the browser to FME Server can be a CNAME, there MUST be a SPN registration for the HOST name of the computer.  Below are the commands we ran to get it to work with the CNAME as the url.  The CNAME entries are needed to allow the server to be accessed via the friendly name in the browser and the host names are needed to allow SSO for FME Server.  The bold commands below were what fixed the issue.

 

 

CNAME SPN registrations

setspn -S http/testfme svcMyServiceAccount
setspn -S http/testfme.mydomain.com svcMyServiceAccount 

 

 

HOST (machine name) SPN registrations

setspn -S http/MyMachineName svcMyServiceAccount 
setspn -S http/MyMachineName.mydomain.com svcMyServiceAccount

 

 

Essentially what I think is happening is that when a Kerberos ticket is attempted to be generated it's using the machine name (HOST) despite the URL that is being specified in the SINGLE_SING_ON_URL.  It's likely a server side process generating the Keberos ticket which would mean the machine name needs to be registered with a SPN.

 

 

Hope this helps someone else figure this out.  

 

 

 

 

​@rylanatsafe we are having this same issue, however, it is no longer possible to had both the CNAME and the machine name. However, it seems that Microsoft tightened up the uniqueness and if it matches the machine name you can no longer add it “After November 2021 patch Microsoft (KB5008382) has increased SPN uniqueness requirements for SPNs covered by the "HOST" spn”. If you try you get the error 

“the operation failed because SPN value provided for addition/modification is not unique forest-wide.”

 

We did add the machine name to SPN with the port :443 (and the CNAME without port), however, the issue persists. Any other suggestions as to how to work out the cause of the issue?


hu-24-July-2025 09:43:23.866 am   INFORM   requesthandler   408038 : Using domain name of connected server "EXAMPLE.COM" as realm.
Thu-24-July-2025 09:43:23.867 am   INFORM   requesthandler   408029 : Found supported SASL mechanism "GSSAPI".
Thu-24-July-2025 09:43:23.868 am   INFORM   requesthandler   408029 : Found supported SASL mechanism "GSS-SPNEGO".
Thu-24-July-2025 09:43:23.869 am   INFORM   requesthandler   408029 : Found supported SASL mechanism "EXTERNAL".
Thu-24-July-2025 09:43:23.870 am   INFORM   requesthandler   408029 : Found supported SASL mechanism "DIGEST-MD5".
Thu-24-July-2025 09:43:23.871 am   INFORM   requesthandler   408032 : Configured to use SASL mechanism "GSSAPI" for authentication.
Thu-24-July-2025 09:43:23.919 am   INFORM   requesthandler   408060 : Successfully connected to abc.example.com.
Thu-24-July-2025 09:43:23.928 am   INFORM   requesthandler   408049 : (Single Sign-On)   Using pre-authenticated credentials (for a service account) to create server credentials...
Thu-24-July-2025 09:43:24.197 am   INFORM   requesthandler   408050 : (Single Sign-On)   Created server credentials.
Thu-24-July-2025 09:43:24.204 am   INFORM   requesthandler   408053 : (Single Sign-On)   Negotiation reported an error: "Failure unspecified at GSS-API level (Mechanism level: Checksum failed)".
Thu-24-July-2025 09:43:24.206 am   WARN     requesthandler   408058 : (Single Sign-On)   Failed authentication because of an negotiation error. Refer to single sign-on documentation for resolution.
Thu-24-July-2025 09:43:26.693 am   INFORM   requesthandler   408053 : (Single Sign-On)   Negotiation reported an error: "Failure unspecified at GSS-API level (Mechanism level: Checksum failed)".
Thu-24-July-2025 09:43:26.694 am   WARN     requesthandler   408058 : (Single Sign-On)   Failed authentication because of an negotiation error. Refer to single sign-on documentation for resolution.
Thu-24-July-2025 09:44:00.980 am   INFORM   requesthandler   408053 : (Single Sign-On)   Negotiation reported an error: "Failure unspecified at GSS-API level (Mechanism level: Checksum failed)".
Thu-24-July-2025 09:44:00.981 am   WARN     requesthandler   408058 : (Single Sign-On)   Failed authentication because of an negotiation error. Refer to single sign-on documentation for resolution.

Actually, IT tried again and they were able to do this as domain admin. Didn’t solve our SSO issue unfortunately

davidwilton
Contributor
Forum|alt.badge.img+1
  • davidwiltonContributor
  • Contributor
  • August 1, 2025

We got this working with Safe’s support

 

Flow does not support adding the load balancer as the AD hostname. So if mycom.mycompany.com.au is the LB endpoint, then it would not work. 

I see that you have added mycompanydcprd5.mycom.mycompany.com.au, which I presume is one of the 4 DCs behind the LB, and the other 3 have been added to the “Alternate Servers”. Can we test by removing the 3 alternate servers?

Please explicitly add the main DC as the KDC in the optional fields. Flow does not support multiple KDC setup. 

If you are unable to set the Realm and KDC in the existing connection, i.e. it is greyed out, please try creating a new connection.

 

For us it appeared to be using the load balancer, we had to use an explicit AD hostname. We could use alternate hosts for high availability. This is something that has changed in FME, because we have this running in previous version.

Note, I think there is a bug in the latest version. If you edit the connection after creating it then it will lose the Realm and the KDC

davidwilton
Contributor
Forum|alt.badge.img+1
  • davidwiltonContributor
  • Contributor
  • August 14, 2025

We got this working with Safe’s support

 

Flow does not support adding the load balancer as the AD hostname. So if mycom.mycompany.com.au is the LB endpoint, then it would not work. 

I see that you have added mycompanydcprd5.mycom.mycompany.com.au, which I presume is one of the 4 DCs behind the LB, and the other 3 have been added to the “Alternate Servers”. Can we test by removing the 3 alternate servers?

Please explicitly add the main DC as the KDC in the optional fields. Flow does not support multiple KDC setup. 

If you are unable to set the Realm and KDC in the existing connection, i.e. it is greyed out, please try creating a new connection.

 

For us it appeared to be using the load balancer, we had to use an explicit AD hostname. We could use alternate hosts for high availability. This is something that has changed in FME, because we have this running in previous version.

Note, I think there is a bug in the latest version. If you edit the connection after creating it then it will lose the Realm and the KDC

 

Further to this we also found that if FME is behind a load balancer we had to add the load balancer to the SPN

 

Community Stats

32,413
Posts
122,925
Replies
40,129
Members

Latest FME

Terms & ConditionsCookie settingsAccessibility statement
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.