Skip to main content

I upgraded my Development machine Thursday, and install ran smooth, import of backup ran smooth. Checked settings and all appear to match up with Staging and Production, but unable to get Single-Sign-On to function again.

 

Negotiation reported an error: "Failure unspecified at GSS-API level (Mechanism level: Encryption type RC4 with HMAC is not supported/enabled)".

 

All three of my systems use the same Service-Account, and Staging and Prod have not issue, and Dev worked fine until the upgrade.

 

 

Hi @David Wright​: we noticed that you also created a support case which my colleague @mattmatsafe​ responded to. Just sharing his response here as well:

FME 2023 uses more secure encryption than previous versions. Our SSO documentation is being updated to reflect this change and the steps below. 

If you have access to the Windows Domain server you can configure the encryption types:

  1. Search for and open Local Security Policy on the menu search bar
  2. Navigate to Local Policies > Security Options
  3. Scroll down and find 
  4. Network security: Configure encryption types allowed for Kerberos
  5. Enable AES128 and AES256 as shown in the screenshot
  6. Disable RC4_HMAC_MD5

Very sorry for the confusion and inconvenience this has caused you.


Hi @David Wright​: we noticed that you also created a support case which my colleague @mattmatsafe​ responded to. Just sharing his response here as well:

FME 2023 uses more secure encryption than previous versions. Our SSO documentation is being updated to reflect this change and the steps below. 

If you have access to the Windows Domain server you can configure the encryption types:

  1. Search for and open Local Security Policy on the menu search bar
  2. Navigate to Local Policies > Security Options
  3. Scroll down and find 
  4. Network security: Configure encryption types allowed for Kerberos
  5. Enable AES128 and AES256 as shown in the screenshot
  6. Disable RC4_HMAC_MD5

Very sorry for the confusion and inconvenience this has caused you.

Thank you; yes we did try making the needed fixes and changes and had to update the support case.


Hi @David Wright​: we noticed that you also created a support case which my colleague @mattmatsafe​ responded to. Just sharing his response here as well:

FME 2023 uses more secure encryption than previous versions. Our SSO documentation is being updated to reflect this change and the steps below. 

If you have access to the Windows Domain server you can configure the encryption types:

  1. Search for and open Local Security Policy on the menu search bar
  2. Navigate to Local Policies > Security Options
  3. Scroll down and find 
  4. Network security: Configure encryption types allowed for Kerberos
  5. Enable AES128 and AES256 as shown in the screenshot
  6. Disable RC4_HMAC_MD5

Very sorry for the confusion and inconvenience this has caused you.

I have the exact same problem but this solution didn't work.

Where should this GPO bet set? On the FME Server itself or on the Domain Controller?

I set those Options in the as local GPO on the FME Server and rebooted, the issue persists:

image.png


I have the exact same problem but this solution didn't work.

Where should this GPO bet set? On the FME Server itself or on the Domain Controller?

I set those Options in the as local GPO on the FME Server and rebooted, the issue persists:

image.png

The Docs have been updated, the GPO must be set on the Kerberos Server (DC):

https://docs.safe.com/fme/html/FME-Flow/WebUI/Create-Directory-Server-Connection.htm


I have the exact same problem but this solution didn't work.

Where should this GPO bet set? On the FME Server itself or on the Domain Controller?

I set those Options in the as local GPO on the FME Server and rebooted, the issue persists:

image.png

That isn't always realistic; we tried doing at the GPO level; for each machine and they would not always take if you had a higher/superseding GPO required at a a higher level.

 

We ended up needing to define a krb5.conf file; and setting...

 

plibdefaults]

allow_weak_crypto = true


I have the exact same problem but this solution didn't work.

Where should this GPO bet set? On the FME Server itself or on the Domain Controller?

I set those Options in the as local GPO on the FME Server and rebooted, the issue persists:

image.png

Where did you create the krb5.conf file?


I have the exact same problem but this solution didn't work.

Where should this GPO bet set? On the FME Server itself or on the Domain Controller?

I set those Options in the as local GPO on the FME Server and rebooted, the issue persists:

image.png

C:\\Program Files\\FMEFlow\\Utilities\\jre\\conf\\security , putting the file here so when the JVM instances activate they read in the krb5.conf file and allow for the use of the lessor settings.


I have the exact same problem but this solution didn't work.

Where should this GPO bet set? On the FME Server itself or on the Domain Controller?

I set those Options in the as local GPO on the FME Server and rebooted, the issue persists:

image.png

Thanks, this worked. I've tried several other of the "security" folders but not this one 😅


I have the same problem after upgrading from FME Server 2022.2.4 to FME Flow 2023.1.1.

@David Wright​ So what did u put in the krb5.conf file? 😊

 

Rgds,

/Erik


I have the same problem after upgrading from FME Server 2022.2.4 to FME Flow 2023.1.1.

@David Wright​ So what did u put in the krb5.conf file? 😊

 

Rgds,

/Erik

Sure, really simple...

 

plibdefaults]

allow_weak_crypto = true

 

These 2-lines are all that was needed.


The best solution, if your FME Flow Server runs with a AD service User, is to tick the box "This account supports Kerberos AES 256 bit encryption" in the Active Directory Users Properties and not use the krb5.conf workaround


The best solution, if your FME Flow Server runs with a AD service User, is to tick the box "This account supports Kerberos AES 256 bit encryption" in the Active Directory Users Properties and not use the krb5.conf workaround

This worked for us too, with both AES128 and AES256 enabled on the AD service account that we use as the "Search Account" on the Authentication Service Connection.

 

Disabling RC4 network wide seems like it might risk breaking some legacy systems, so it's nice to keep using Flow's improved encryption without forcing the change before we've had time to test it properly :)


Reply