MSCHAP No logon servers are currently available (again, but solved)

[Brendan Kearney]

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 at 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 at posteo.de wrote:
> Hi, all!
> I refer to this older thread with same subject: 
> https://lists.freeradius.org/pipermail/freeradius-users/2021-August/100519.html
> 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_Directory 
> ,
> 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