Hi Louis On 29.09.2021 11:32, L.P.H. van Belle via samba wrote:> "or authentication information" ... > > So, im thinking, these older pc's what used in samba in the low samba version > And the encryptions how its saved maybe.. Like DES/3DES/AES > Lots of problems i see ( in other forum and mailing lists ) involve encryptions.I was thinking into same direction and hence I played also with max protocol and client max protocol entries as well as signing configuration parameters. If anyone is able to tell me how I could dump the actual password hash of a working and non-working node we might get a bit more detail. Weird thing is that in the link you provided (<https://bbs.archlinux.org/viewtopic.php?id=270003>) the report states even re-joining the machine do the domain did not help. I didn't actually try this as I did not want to lose my test system showing the issue. The problem might be related also to the age of client. Keeping in mind my test machine was upgraded from Windows 10 1903 or similar and running 21H1 now. On the other hand the machine which is working fine was also upgraded to 21H1 recently but was joined only after 21H1 was installed already. The other one was joined using a previous release for sure. I really think there is a problem in Samba 4.15 which should be resolved as the only component which is changing is Samba and it suddenly starts to deny the computer account. Unless there is a reason clearly indicating an issue on client side it looks like Samba is misbehaving. I will also watch the linked arch linux topic. best regards, Rainer
On Wed, 2021-09-29 at 11:48 +0200, Rainer Meier via samba wrote:> Hi Louis > > On 29.09.2021 11:32, L.P.H. van Belle via samba wrote: > > "or authentication information" ... > > > > So, im thinking, these older pc's what used in samba in the low > > samba version > > And the encryptions how its saved maybe.. Like DES/3DES/AES > > Lots of problems i see ( in other forum and mailing lists ) involve > > encryptions. > > I was thinking into same direction and hence I played also with max > protocol and client max protocol entries as well as signing > configuration parameters.They have been removed from 4.15.0> > If anyone is able to tell me how I could dump the actual password > hash > of a working and non-working node we might get a bit more detail. > > Weird thing is that in the link you provided > (<https://bbs.archlinux.org/viewtopic.php?id=270003>;) the report > states > even re-joining the machine do the domain did not help. I didn't > actually try this as I did not want to lose my test system showing > the > issue. > > The problem might be related also to the age of client. Keeping in > mind > my test machine was upgraded from Windows 10 1903 or similar and > running > 21H1 now. On the other hand the machine which is working fine was > also > upgraded to 21H1 recently but was joined only after 21H1 was > installed > already. The other one was joined using a previous release for sure. > > I really think there is a problem in Samba 4.15 which should be > resolved > as the only component which is changing is Samba and it suddenly > starts > to deny the computer account. Unless there is a reason clearly > indicating an issue on client side it looks like Samba is > misbehaving. > > I will also watch the linked arch linux topic. >I have seen a few reports about 4.15.0 since it was released, one where a standalone server would not even start. Now this all could be coincidental, but it needs researching. Rowland
> > > > I have seen a few reports about 4.15.0 since it was released, > one where > a standalone server would not even start. > Now this all could be coincidental, but it needs researching. >Yes, but not starting, thats not samba, thats a humon error/bad config. All version i compiled and packaged work.> I was thinking into same direction and hence I played also with max > protocol and client max protocol entries as well as signing > configuration parameters.I dont expect its in there, as you said, these are disabled. I suspect its somewhere in the AD object. And you check in the ad on a few computer objects, the msDS-SupportedEncryptionTypes By default its 31. ("DES_CRC","DES_MD5","RC4","AES128","AES256") You can try changing it on a faulty computer to 24. "AES128","AES256" 0x18 = 24 So far, Louis