Access Manager 5.1 is out

Hi everybody!

If anybody has missed, AM 5.1. is out (https://www.microfocus.com/documentation/access-manager/5.1/)

If you are upgrading existing setup and already have entries in Advanced File Configuration, there is a know issue where after the upgrade files in Advanced File Configuration are blank and unusable.

So export configuration from there BEFORE you start upgrade, otherwise you will need to revert snapshot as I needed to do.

For more details see this: https://www.microfocus.com/documentation/access-manager/5.1/accessmanager51-release-notes/accessmanager51-release-notes.html#t4ox80hhk25e

Anyway, I have upgraded one of my AM appliances and for now it looks OK, except kerberos authentication. It looks like client is asked for kerberos ticket but then AM is not able to extract user information.

I will do more troubleshooting on Monday, but please let me know if you have kerberos auth working on AM 5.1

Kind regards,

Sebastijan

Kind regards,

Sebastijan

If you found this post useful, give it a “Like” or click on "Verify Answer" under the "More" button

Labels:

Access Manager
  • 0  

    Regarding kerberos authentication that failed after upgrade to AM 5.1, after upgrade there is a change which kerberos encryption types are accepted by AM

    Our keytab is created with etypes 1, 3, 17, 18 and 23 (encryption types are defined here: https://www.iana.org/assignments/kerberos-parameters/kerberos-parameters.xhtml#kerberos-parameters-1), but when loaded by AM I can see following:

    Looking for keys for: HTTP/idp.nam.example@NAM.EXAMPLE
    Found unsupported keytype (3) for HTTP/idp.nam.example@NAM.EXAMPLE
    Found unsupported keytype (1) for HTTP/idp.nam.example@NAM.EXAMPLE
    Found unsupported keytype (23) for HTTP/idp.nam.example@NAM.EXAMPLE
    Added key: 17version: 1
    Added key: 18version: 1
    Using builtin default etypes for default_tkt_enctypes
    default etypes for default_tkt_enctypes: 18 17.

    Our KDC (Domain Services for Windows) is for some reason issuing kerberos tickets with encryption type 23 and since AM does not support that etype, tickets cannot be decrypted.

    I need to troubleshoot DSfW kerberos issue (some tickets are issued with aes256-cts-hmac-sha1-96 - type 18 and some with rc4-hmac - type 23) and fix that there, but if somebody else faces this problem, you can temporary enable deprecated encryption types on AM by adding allow_weak_crypto = true to [libdefaults] section in /etc/krb5.conf of each IDP server and restarting novell-idp service.

    I hope this workaround saves some time for somebody else facing similar issue.

    Kind regards,

    Sebastijan

    PS: How to find out encryption type of kerberos ticket? Run klist command on client and check "KerbTicket Encryption Type" line for AM ticket:

    #1>     Client: sebastijan @ NAM.EXAMPLE
            Server: HTTP/idp.nam.example @ NAM.EXAMPLE
            KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
            Ticket Flags 0x40a90000 -> forwardable renewable pre_authent name_canonicalize 0x80000
            Start Time: 5/22/2024 10:48:30 (local)
            End Time:   5/22/2024 20:25:32 (local)
            Renew Time: 5/29/2024 10:25:32 (local)
            Session Key Type: RSADSI RC4-HMAC(NT)
            Cache Flags: 0
            Kdc Called: dsfw.nam.example

    Kind regards,

    Sebastijan

    If you found this post useful, give it a “Like” or click on "Verify Answer" under the "More" button

  • 0 in reply to   

    Thank you for posting your findings.  Will monitor forums before we move forward with patching.  I'd rather click next next next finish and be done, but I know that is too much to ask.  Maybe look for the next patch and hope it isn't a year.

  • 0 in reply to   

    Thank you for reporting this issue. It also affects version 5.0.4.1.

    We still had a keytab file that only supported RC4-HMAC. Even after regenerating the keytab file (using /crypto All), the problems persisted. Since the workaround was not viable for us, we adjusted the msDS-SupportedEncryptionTypes attribute on the service account from 0 (all) to 16 (AES 256).

    After this change, all service tickets for our SPN are issued with AES-256-CTS-HMAC-SHA1-96.

  • 0   in reply to 

    Just saw this post as I upgraded a site to 5.0.4.1 and had the same problem. Generated new key tab using /crypto all, but users are getting this error:

    "Error processing SPNEGO/Kerberos : Error processing SPNEGO/Kerberos : Error processing SPNEGO/Kerberos : Failure unspecified at GSS-API level (Mechanism level: Encryption type RC4 with HMAC is not supported/enabled)"

    Will just changing msDS-SupportedEncryptionTypes take care of this?  Is it just a matter of editing the attribute on the account used by NAM and changing it from 0 to 16?

    I also noticed that password fetch class is broken again in 5.0.4.1.  I had gotten a patch to fix that way back in 2023 and now that problem is back! Unbelievable.  I haven't tested in 5.1, but I wonder if password fetch is broken in 5.1 as well?

    Seems like all kinds of patches and fix simply got lost somewhere along the way.  

    Matt

  • 0 in reply to   

    Adjusting the msDS-SupportedEncryptionTypes attribute on the SPI/service account to 16 (AES 256) is sufficient.

    Did you receive the '504PatchHF' engineering patch (which also applies on 5.0.4.1)? This patch includes a modified version of nidp.jar for the PasswordFetch class issue.

  • 0   in reply to 

    Super, I will try that.

    I have the patch that I got back in May 2023 for 5.0.4 with an updated nidp.jar to fix the password fetch issue.  Are you saying I can use the same patch on 5.0.4.1 as well?

    I specifically opened a case when 5.0.4.1 asking if all the fixes I had gotten for 5.0.4 are in 5.0.4.1 and support told me, oh yes, they are in there.  So far, 0 for 3.    I still am not sure if they are even in 5.1 or 5.1.0.1.   Every release is like a gamble, will they be in there or not, no one knows!

    Matt

  • 0 in reply to   

    I have the patch that I got back in May 2023 for 5.0.4 with an updated nidp.jar to fix the password fetch issue.  Are you saying I can use the same patch on 5.0.4.1 as well?

    I'm not sure. A few months ago, I requested an engineering patch that had been created for version 5.0.3, but instead, I received a gigantic patch containing 25 files. Interestingly, the patch I requested was never applied to versions 5.0.4, 5.0.4.1, or even the gigantic patch I received. So, I'm still waiting for it. 

    I specifically opened a case when 5.0.4.1 asking if all the fixes I had gotten for 5.0.4 are in 5.0.4.1 and support told me, oh yes, they are in there.  So far, 0 for 3.    I still am not sure if they are even in 5.1 or 5.1.0.1.   Every release is like a gamble, will they be in there or not, no one knows!

    I compared all jars with the stock 5.0.4.1 jars. 14 jars were the same (though recompiled, so with different checksums), and 8 were different. One of them was nidp.jar. The code changes appeared to be related to the PasswordFetch class and some redirect functionality. I assume it has something to do with the open redirect vulnerability.

    Every release is like a gamble, will they be in there or not, no one knows!

    It’s a huge mess. Security vulnerabilities that recur are unacceptable!

  • 0   in reply to 

    Support supplied to me the "Hot Fix" that has ALL the fixes. I was not aware one even existed!  It's called 504HF1 (you mentioned earlier I believe), however, you have to apply it AFTER 5.0.4 Patch 1, so I don't know why they didn't call it 5041HF1.  Very confusing.  It does not change the version of anything, so you will have no idea that you applied it.  Just wonderful stuff.

    But it has all the fixes I need for my customers.

    I'm also told that all those fixes in there are in 5.1.0.1 as well.

    Matt

  • 0   in reply to 

    I forgot to mention that setting msDS-SupportedEncryptionTypes worked perfectly.  So thanks for that tip!  Where is the updated documentation and/or TID/Support Document on this one? :)

    Since the topic here is really 5.1, have you seen the issue with deploying folders using the Advanced File Configurator?  Even with the 5.1.0.1 patch, folders (zips) still get corrupted and cannot be deployed.  I've had a case open on this for months.

    Another issue I've seen, albeit at one customer, is where the admin console login fails after the auth (/roma throws an exception).  Only fix for that one is a restart of the admin console.  I've had a case open on that one for months as well.

    Matt

  • 0 in reply to   
    I forgot to mention that setting msDS-SupportedEncryptionTypes worked perfectly.  So thanks for that tip!  Where is the updated documentation and/or TID/Support Document on this one? :)

    You can find it in the release notes under "undocumented deprecations". Because who doesn't love a good surprise? Wink

    Since the topic here is really 5.1, have you seen the issue with deploying folders using the Advanced File Configurator?  Even with the 5.1.0.1 patch, folders (zips) still get corrupted and cannot be deployed.  I've had a case open on this for months.

    No, I don’t have any experience with that. I know that Advanced File Configurator is now the recommended approach, but I use Ansible to manage configuration and customizations across all nodes.

    Another issue I've seen, albeit at one customer, is where the admin console login fails after the auth (/roma throws an exception).  Only fix for that one is a restart of the admin console.  I've had a case open on that one for months as well.

    After the release of 5.1, I decided to stay on 5.0.4.(1) for a while, but its support will end in April. Over the next few months, I'll start exploring 5.1.0.1.