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

  • 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.