We'd love to hear about it! Click here to go to the product suggestion community
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?
There have been no changes to kerberos or authentication overall since EAP1. If it was working in EAP1/2 I have no idea what would stop working in EAP3.
Did you do any rollbacks to previous builds? The way that nasm does rollback is different from the rest of the system.
Please don't modify files like that. Depending on what you have done, I don't know how reversible it is. Some of these files are symlinked and only valid when running in the chroot that nasm runs in.
It might just be your post, but you are also mixing up bin and etc directories.
Can you revert your system back and then tell me what the original problem is?
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.
In reply to Michael Dunn:
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.
In reply to MarkusMeister:
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