Verified Answers

If an answer to your question is correct, click on "Verify Answer" under the "More" button. The answer will now appear with a checkmark. Please be sure to always mark answers that resolve your issue as verified. Your fellow Community members will appreciate it! Learn more

  • State Suggested Answer
  • Replies replies
    9
  • Answers answer
    1
  • Subscribers subscribers
    25
  • Views views
    547
  • Users 0 members are here
Related
Options

OES 24.2 DSfW issuing kerberos tickets with deprecated encryption types

Sebastijan Sef
 

Hi!

I am facing interesting issue. After Access Manager upgrade we have noticed that kerberos SSO has stopped working.

Reason is that kerberos tickets issued by DSfW are using encryption type 23 (encryption types are defined here: https://www.iana.org/assignments/kerberos-parameters/kerberos-parameters.xhtml#kerberos-parameters-1) which is deprecated and also now unsupported by Access Manager.

Looking at /var/opt/novell/log/oes/dsfw/kdc.log I can see following line:

May 22 10:48:30 dsfw krb5kdc[2388](info): TGS_REQ (5 etypes {18 17 23 24 -135}) <client IP>: ISSUE: authtime 1716366332, etypes {rep=23 tkt=23 ses=23}, sebastijan@EXAMPLE.COM for am@EXAMPLE.COM

As we can see, requested etypes were 18 17 23 24 but issued etype was 23.

Resulting output of klist command on client is (see KerbTicket Encryption Type):

#1>     Client: sebastijan @ EXAMPLE.COM
        Server: HTTP/am.example.com @ EXAMPLE.COM
        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.example.com

Interestingly, kerberos tickets for DSfW services have issued etype 18

Line in /var/opt/novell/log/oes/dsfw/kdc.log:

May 22 10:29:31 dsfw krb5kdc[2388](info): TGS_REQ (5 etypes {18 17 23 24 -135}) <IP>: ISSUE: authtime 1716366332, etypes {rep=23 tkt=18 ses=18}, sebastijan@EXAMPLE.COM for DSFW$@EXAMPLE.COM

Looking at that Kerberos ticket on client we see AES-256-CTS-HMAC-SHA1-96 as encryption type:

#3>     Client: sebastijan @ EXAMPLE.COM
        Server: ldap/dsfw.example.com @ EXAMPLE.COM
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40ad0000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize 0x80000
        Start Time: 5/22/2024 10:29:31 (local)
        End Time:   5/22/2024 20:25:32 (local)
        Renew Time: 5/29/2024 10:25:32 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0
        Kdc Called: dsfw.example.com

Has anybody else seen something like that?

Or to rephrase, how to persuade DSfW kdc to issue kerberos tickets for AM with proper etype (18 - AES-256-CTS-HMAC-SHA1-96)?

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  
    Sebastijan Sef said:
    Or to rephrase, how to persuade DSfW kdc to issue kerberos tickets for AM with proper etype (18 - AES-256-CTS-HMAC-SHA1-96)?

    I don't use Access Manager but I do use DSfW. Over the past few years I have opened dozens of cases for similar issues. These issues are usually referred to the developers who, shall I say, have been less than enthusiastic about getting them resolved. 

    Due to the many issues I have reported, but have yet to be resolved, my DSfW servers are pretty much dysfunctional. 

    It's important that we present issues like these in the forums so that everyone is aware of them but it is just as important that we open a case so that there is an official record. Hopefully the issue can be resolved but even if it isn't we can establish a pattern of issues we have all encountered and their final disposition.

    My cases were for issues encountered on DSfW 18.x. Now, I'm going to have to reproduce them on a current DSfW version, collect log entries, packet traces, etc, and open new cases. That's a lot of work. My experience has been that it is up to the customer to prove, beyond a shadow of a doubt, that a defect exists. Even after the developers acknowledge the defect my experience has been that it is an uphill battle to get it resolved. Unamused

    __________
    Kevin Boyle,     Knowledge Partner
    Calgary, Alberta, Canada

  • 0

    Yes, that is strange and I see a similar behaviour. Most of the tickets are issued with etype 18, but if the request contains the etype -135, then etype 23 is issued.

    This does work on windows servers and clients.

    But, if Access Manager does not support etype 23, why does it declare etype 23 as an accepted etype in his request? I think, that it is the fault of the requester (Access Manager) to declare an etype as accepted, if this is not the case. And as long as etype 23 is supported by DSfW, it is not a fault, to issue an etype 23 ticket, if the client tells the server in his request, that it accepts etype 23.

  • 0   in reply to 
    Prindl said:
    But, if Access Manager does not support etype 23, why does it declare etype 23 as an accepted etype in his request? I think, that it is the fault of the requester (Access Manager) to declare an etype as accepted

    Access Manager is not the requester, requester is windows workstation.

    But that gave me an idea to test.

    So I have used Group Policy and limited configured kerberos encryption types on computer to AES only (128 and 256) + "Future encryption types" (whatever that means):

    After restart of the computer I don't get ANY kerberos tickets (klist is empty), not even those from DSfW.

    Looking at EventLog I can see two interesting events:

    Also trying to get kerberos ticket with klist get fails with error:

    If I reenable RC4:HMAC_MD5 encryption type in group policy, I get back to previous behavior.

    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 in reply to   

    Yes, that's, what I found sometimes before, too. If you disable RC4:HMAC-MD5 DSfW authentication from Windows PCs fails. I did not test, if this is also true for a Windows Server AD domain controller.

    And you can enable quite fancy encryption types on kerberos, but that is of no use for Windows connections. But from the Linux side these seem to work.

  • 0  

    Hi Sebastijan,

    Engineering team is trying to reproduce the issue in our labs.  we have Access Manager 5.1 appliance version installed and added DSfW under user stores.  

    Can you please explain the exact use-case for us to reproduce the issue ?  How did you configure or achieve Kerberos SSO ?  Is there any Access Manager Client which we need to configure and join to DSfW ?

    We would like to know how HTTP service is configure to get Kerberos ticket "HTTP/am.example.com @ EXAMPLE.COM"

    Thanks,

    Kiran

  • Suggested Answer

    0   in reply to   

    Hi Kiran!

    You actually don't need to configure/do anything on AM side to simulate problem, since kdc issues kerberos ticket on client request, not AM.

    Just create simple user/service account on DSfW and set it's servicePrincipalName LDAP attribute to something (in my case HTTP/idp.genlan.si or groupwise/mail.genlan.si)

    Then on domain joined windows computer issue following command in command prompt:

    klist get <whatever you put in servicePrincipalName>

    This will request kdc to issue ticket for HTTP/<something> and you can see encryption type in output of command.

    For example:

    Same goes for any other service, for example if I try to get kerberos ticket for our groupwise:

    Interestingly, at the same time tickets issued for dsfw resources (e.g. krbtgt/GENLAN.SI and ldap/gnl-dsfw1.genlan.si) are issued with encryption type AES-256-CTS-HMAC-SHA1-96

    To me it looks like KDC is able to issue tickets with AES-256-CTS-HMAC-SHA1-96 etype, but not if it needs to issue it for specific servicePrincipalName.

    If KDC would be Microsoft AD we could set msDS-SupportedEncryptionTypes attribute on service account to define etypes KDC can use when issuing tickets (that attribute has no affect in DSfW environment, I tried it Blush)

    Please let me know if you need additional information, we can also have a workshop if you'd like (Girish has my email).

    Kind regards,

    Sebastijan

    PS: Let me also answer your questions:

    >How did you configure or achieve Kerberos SSO ?

    There are quite some steps (see https://www.microfocus.com/documentation/access-manager/5.1/admin/b9uctt5.html), but to summarize:

    - On AD create service account form AM and set SPN (servicePrincipalName)

    - On DC issue keytab file for AM and upload that file to AM

    - On AM konfigure kerberos class which will use provided keytab to decrypt received kerberos ticket

    >Is there any Access Manager Client which we need to configure and join to DSfW?

    No, AM uses keytab file to decrypt kerberos ticket received from client.

    Or to rephrase, when kerberos ticket is sent to AM (it is sent by browser), AM uses keytab to decrypt ticket and extract user information (sAMAccountName). This is then used to find user in backend directory and authenticate that user.

    So AM actually does not need to talk to KDC/ADDC at all, all it needs is valid keytab file to decrypt kerberos tickets issued by KDC (brilliant setup, I must say Blush)

    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   

    Hi    We have a potential fix for this issue.  We tested the fix in our labs and it seems to be working.

    I request you to raise an SR so that we can delivery the binary which you can validate on your setup.

    Thanks,

    Kiran

  • 0   in reply to   

    Hi Kiran!

    That is great information! I have just opened case #02938936 (I just hope people in support will not request tons of logs before it will land on your desk Sweat smile)

    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   in reply to   

    Thank you for reporting the issue. I have notified the support manager, and hopefully, it will reach the engineering team soon.

Resources

Support
Documentation
Learning Services
Partner Programs
Privacy
Compliance
Help
Company
Privacy Policy
Terms of Use
Cookies Preferences
Accessibility
Anti-Slavery Statement
Support
Contact Us
Careers
Code of Business Conduct and Ethics
The opinions expressed above are the personal opinions of the authors, not of OpenText. By using this site, you accept the Terms of Use. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.), Hewlett Packard Enterprise Company, or Micro Focus. As of January 31, 2023, the Material is now offered by OpenText, a separately owned and operated company. Any reference to the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks is historical in nature and the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks are the property of their respective owners.