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/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
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?
The /content/nasm directory structure gets rebuilt every install/upgrade/downgrade/rollback. Somehow you ended up with a copy of the 17.5 directory structure in a 18.0 box.
I need to know the upgrade (etc) history of this box.
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.
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.SymptomsAD 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:stoprm -rf /content/nasmservice -ds nosync nasm:start