there are a couple things that come to mind. kerberos has a KVNO (Key Version Number) that indicates the number of iterations the keytab has gone through. this number increments when the keytab is issued. a computer account password change, which windows requires based on domain settings but i think defaults to 90 days, when forced would require the keytab to be updated and the kvno incremented. it seems that when you re-joined the domain, you received the newest keytab, with the kvno that matches the kerberos database, and you were able to talk to the domain servers properly. it doesnt sound like your server fell out of the domain, its that policy required the computer account's password to change, and - if that happened, the host keytab (default is probably /etc/krb5.keytab) no longer matched both password and kvno - if that did not happen, the windows servers refused to talk to a host that required a password change some validation would be to run: klist -Kket /etc/krb5.keytab before and after the net join process. note the KVNO number next to the "host/name.domain.tld@REALM" entries. if they are different, a new keytab was issued and the computer account password was likely changed. HTH Brendan Kearney On 11/16/22 8:18 AM, uj2.hahn@posteo.de wrote:
Hi, all! I refer to this older thread with same subject: https://lists.freeradius.org/pipermail/freeradius-users/2021-August/100519.h... I run into a similar issue and like to share the way I solved it:
I implemented a Freeradius/AD solution some years ago in a school. (Win10 clients, MS server/AD in Azure cloud) This had been working fine all the time, but after the school installed some Microsoft updates to their clients Freeradius stopped working. No authorization was possible. I debugged it down to above error message when I run ntlm_auth manually (saw same message in FR debug log). Somehow the communication between Ubuntu based FR server and Windows server/AD was broken now. My guess was the the updated Windows environment needs an improved communication protocol with higher security level. So I upgraded Ubuntu to version 22.04 LTS to get a more recent Samba version (4.15.9). But this didn't help. I modified smb.conf as described in https://wiki.samba.org/index.php/Authenticating_Freeradius_against_Active_Di... , but this didn't help neither. Also a reboot of the FR Ubuntu server didn't help. But then I rejoined FR server to domain: net join -U admin (will prompt for password).
The FR server has been part of the domain for years. But somehow this got broken. Not sure which of the actions above was root cause, but the "net join" command was finally the key. So don't forget it even though think you did it earlier already .
Just to help others in case they run in same issue.
Regards Uwe - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html