Skip to main content

Hi, It must be stunningly simple however we miss the clue, but we're trying to get FME Server to accept Single Sign-On logins. We connected to Active Directory, that seems to work nice since we can use a user and password from the domain and log in, that's a success. 

Mon-13-Nov-2017 04:20:33.924 PM  INFORM  RequestHandler-Thread  401831 : Accepted new client connection from /127.0.0.1 on port 7,071

Mon-13-Nov-2017 04:20:33.926 PM  INFORM  RequestHandler-Thread  401933 : Successful login by user XX99999

However, when we press the Use Windows Credentials the login is denied and fmeserver.log shows this error message:

Mon-13-Nov-2017 04:23:22.734 PM  INFORM  RequestHandler-Thread  401831 : Accepted new client connection from /127.0.0.1 on port 7,071

Mon-13-Nov-2017 04:23:22.770 PM  INFORM  RequestHandler-Thread  408043 : (Single Sign-On)  Enabled single sign-on authentication.

Mon-13-Nov-2017 04:23:22.770 PM  INFORM  RequestHandler-Thread  408049 : (Single Sign-On)  Using pre-authenticated credentials (for a service account) to create server credentials...

Mon-13-Nov-2017 04:23:22.802 PM  INFORM  RequestHandler-Thread  408050 : (Single Sign-On)  Created server credentials.

Mon-13-Nov-2017 04:23:22.803 PM  INFORM  RequestHandler-Thread  408056 : (Single Sign-On)  Encountered negotiation requiring multiple steps; authentication still in progress...

Mon-13-Nov-2017 04:23:22.803 PM  ERROR  RequestHandler-Thread  Single sign-on authentication in progress

Mon-13-Nov-2017 04:23:22.807 PM  WARN  RequestHandler-Thread  401934 : Failed login by user YH0GBisGAQUFAqBzMHGgMDAuBgorBgEE... due to insufficient credentials.

Anybody any suggestions? What stuck me is that the user name seems to be encrypted, while if using the explicit credentials they are not. 

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.  

 

 

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.

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

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

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,005
Posts
121,558
Replies
39,626
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.