ADSSO/NTLM Bug in v18 EAP3

Hi,

during the test of the adsso Kerberos authentication for Web, i could see in the nasm.log that there are some files missing:

[nasm]  hi_i_m_child(): excvp('/bin/ntlm_krb5_setup.sh') failed for 'No such file or directory'

initialize_kerberos(): gss_acquire_cred HOST/AFWXGTEST01@INTERN.LOCAL: Key table file '/etc/krb5.keytab' not found

after i renamed the /content/nasm/etc/ntlm_krb5.sh to ntlm_krb5_setup.sh and change some values in the script

#!/bin/sh

export KRB5_KTNAME=FILE:/tmp/krb5.keytab

MYNBNAME=fwxg01$4

/bin/rm /tmp/krb5.keytab
/oss/net -U "$1%$2" ads keytab add HTTP/$MYNBNAME.demo.io@$3
/oss/net -U "$1%$2" ads keytab add host/$MYNBNAME.demo.io@$3
/oss/net -U "$1%$2" ads keytab add HTTP/$MYNBNAME.$3@$3
/oss/net -U "$1%$2" ads keytab add host/$MYNBNAME.$3@$3
/oss/net -U "$1%$2" ads keytab add HTTP/$MYNBNAME@$3
/oss/net -U "$1%$2" ads keytab add host/$MYNBNAME@$3
/oss/net -U "$1%$2" ads keytab add HOST/$MYNBNAME@$3

exit 0

i got a valid krb5.keytab file which i linked from the /content/nasm/etc/krb5.keytab to the /content/nasm/etc/krb.keytab

but now i got an Kerberos decrypting error in the nasm.log

[ntlmserver]  authenticate_kerberos(): gss_accept_sec_context: Request ticket server HTTP/fwxg01.demo.io@DEMO.IO kvno 2 enctype aes256-cts found in keytab but cannot decrypt ticket

With EAP1 and EAP2 it was working.

Are there any settings missed, or is the feature actually broken?

 

Best regards,

Markus

 

Parents Reply Children
  • Hi Michael,

    it was an Upgrade from SFOS 18 EAP 1 (in this version the scripts were available in the described path, also the link to the krb5.keytab exists).

    Then i upgraded to EAP2 and now i upgraded to EAP3. And i don't know exactly if the ADSSO was working with EAP2, but in EAP3 there were some missing script files.

     

    Best regards,

     

    Markus

  • We don't know what caused the problem. Some part of the upgrade process. XG sllows two firmwares to be "installed" at the same time. If you flip back and forth between them then it is possible that something screwed up. If you are doing something, for example, to have one slot maintained as 17.5 while the other slot is EAP1, then EAP2, then EAP3. In order to do that you keep booting into 17.5 so you can install into your 18 slot. Potentially there is a problem there.
    But if you are always installing to the non-active slot and always booting to a newer version and never back, I don't see how even theoretically this could happen.

    Hopefully in the real world 17.5 MR9 -> 18.0 GA upgrade this will be a lot more straight forward upgrade and this won't occur.

    If anyone else experiences this, please let me know.
    Symptoms
    AD SSO (NTLM, Kerberos) is not working.
    /log/nasm.log complains about missing files


    In any case, the solution is fairly easy:

    service -ds nosync nasm:stop
    rm -rf /content/nasm
    service -ds nosync nasm:start