On 17/01/2022 06:19, Alexander Bokovoy wrote: It's purely about IPA - as mentioned that "old" deployment of mine - where DNS would manage a record(s) for a HA non-real-host, where such a FQDN (under IPA's realm or outside of it(as I had it with "old" domain)) would "float" between masters(following floating IP) Really nothing else to be bothered with, certainly not at this point. Info I found on "clustered services" is pretty scarce - my opinion - wish that covered Samba as one specific example, since Samba is - my opinion again - such an integral part of IPA. Such "clustered Samba" seems like what should work - for me - any of the masters' Samba serving a given HA-FQDN - part needin careful fiddling would be kerberos I presume. many thanks, L.

On 16/01/2022 20:25, lejeczek via FreeIPA-users wrote: That - NT_STATUS_WRONG_PASSWORD - seems not an issue of my env but rather it is, that non-enrolled clients, linux & windows will fail even if trying a "legitimate" master's Samba. Is that the default behavior in current version - as I mentioned my "old" with up-dates/grades IPA allows non-enrolled - and if so can it be managed into allowing non-enrolled clients? Log snippet off a master's Samba when non-enrolled Linux connects: ... [2022/01/17 11:14:09.090933,  2, pid=35744] ipa_sam.c:3645(init_sam_from_ldap)   init_sam_from_ldap: Entry found for user: me254 [2022/01/17 11:14:09.099720,  1, pid=35744] ../../source3/auth/check_samsec.c:454(check_sam_security)   Failed to modify entry: NT_STATUS_NOT_IMPLEMENTED [2022/01/17 11:14:09.099758,  2, pid=35744] ../../source3/auth/auth.c:348(auth_check_ntlm_password)   check_ntlm_password:  Authentication for user [me254] -> [me254] FAILED with error NT_STATUS_WRONG_PASSWORD, authoritative=1 [2022/01/17 11:14:09.099793,  2, pid=35744] ../../auth/auth_log.c:653(log_authentication_event_human_readable)   Auth: [SMB2,(null)] user [CCN]\[me254] at [Mon, 17 Jan 2022 11:14:09.099772 GMT] with [NTLMv2] status [NT_STATUS_WRONG_PASSWORD] workstation [DRUNK] remote host [ipv4:10.0.0.6:55170] mapped to [CCN]\[me254]. local host [ipv4:10.0.0.16:445]   {"timestamp": "2022-01-17T11:14:09.099858+0000", "type": "Authentication", "Authentication": {"version": {"major": 1, "minor": 2}, "eventId": 4625, "logonId": "0", "logonType": 3, "status": "NT_STATUS_WRONG_PASSWORD", "localAddress": "ipv4:10.0.0.16:445", "remoteAddress": "ipv4:10.0.0.6:55170", "serviceDescription": "SMB2", "authDescription": null, "clientDomain": "CCN", "clientAccount": "me254", "workstation": "DRUNK", "becameAccount": null, "becameDomain": null, "becameSid": null, "mappedAccount": "me254", "mappedDomain": "CCN", "netlogonComputer": null, "netlogonTrustAccount": null, "netlogonNegotiateFlags": "0x00000000", "netlogonSecureChannelType": 0, "netlogonTrustAccountSid": null, "passwordType": "NTLMv2", "duration": 12172}}

On ma, 17 tammi 2022, Harry G. Coin via FreeIPA-users wrote: FreeIPA team never claimed to provide any support for non-domain joined Windows systems. On contrary, this is explicitly not supported. We do not test these configurations because they are not supported for a reason. This does not stop brave sysadmins to try to hack their configurations into what they think could be done. It might work or might not. Samba upstream has too little resources to focus on all these configurations as well. The focus there is more on Samba AD and most of very specific file serving setups for AD domain members. Life of NT4 domains and not joined clients using NTLM is long gone for most of deployments that care about security. We (Samba and FreeIPA teams upstream) are working with Microsoft to make a path forward without insecure use of RC4 cipher in NTLM. Hopefully, we'll get somewhere and not joined clients could get better support but we aren't there. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland

On 17/01/2022 16:06, Harry G. Coin via FreeIPA-users wrote: I'm of that same mind and shared my thoughts on occasions such as this in the past. That setup I did long ago was such that system policies needed to be 'LEGACY' and non-enrolled Linux & win clients connected to IPA deployed that way - off the LEGACY, worked beautifully with Samba - so, not much hacking. I understand there might be large customers with large ADs with IPA only glued somewhere next to it but the rest of us I imagine must be like that - small deployments which mixes everything and do _not_! need AD, and securities... are taken of with all sorts of other means. I saw during one upgrade 'CLASSIC IPA" - or something alike - migrated to "IPA PRIMARY" or something like that. I'd imagine that was/when NEW installation changed so non-enrolled do not work now. If I can vote, my vote shall go to - IPA devel re/consider changes to reintroduce (as an option) such a deployment mode where Samba would "weaken" the setup/config so all those non-enrolled customers can connect with _passwords_ many thanks, L.

On ma, 17 tammi 2022, lejeczek via FreeIPA-users wrote: Please read Samba CVE notes from the recent (November 2021) security release. Samba Team is not going to get back on the security, so please realize that early rather than late. The change of 'classic' domain controller type in smb.conf to 'ipa primary domain controller' does not affect this operation, though. This is exactly the change to keep IPA functioning as it was: commit e2d5b4d709293b52112d078d6fcde95593d790c5 CVE-2020-25717: Add FreeIPA domain controller role As we want to reduce use of 'classic domain controller' role but FreeIPA relies on it internally, add a separate role to mark FreeIPA domain controller role. It means that role won't result in ROLE_STANDALONE. ROLE_STANDALONE is what Samba internally banned from using Kerberos authentication to prevent name authorization abuses as in CVE-2020-25717. Since you are using unjoined client, this affects you in a way that you cannot use the API that joined clients use in SMB protocol (mutually authenticate domain controller and domain member, then use secure channel between them to communicate) and have to use paths that aren't supported anymore. Some part might be fixable -- I saw in your (extremely short) log excerpt something that we definitely not support: [2022/01/17 11:14:09.090933, 2, pid=35744] ipa_sam.c:3645(init_sam_from_ldap) init_sam_from_ldap: Entry found for user: me254 [2022/01/17 11:14:09.099720, 1, pid=35744] ../../source3/auth/check_samsec.c:454(check_sam_security) Failed to modify entry: NT_STATUS_NOT_IMPLEMENTED [2022/01/17 11:14:09.099758, 2, pid=35744] ../../source3/auth/auth.c:348(auth_check_ntlm_password) check_ntlm_password: Authentication for user [me254] -> [me254] FAILED with error NT_STATUS_WRONG_PASSWORD, authoritative=1 The key here is source3/auth/check_samsec.c:check_sam_security() -- we've got there because the password provided by a client was verified to be *wrong*: nt_status = sam_password_ok(mem_ctx, username, acct_ctrl, challenge, lm_pw, nt_pw, user_info, &user_sess_key, &lm_sess_key); /* Notify passdb backend of login success/failure. If not NT_STATUS_OK the backend doesn't like the login */ update_login_attempts_status = pdb_update_login_attempts(sampass, NT_STATUS_IS_OK(nt_status)); if (!NT_STATUS_IS_OK(nt_status)) { ... error happens down this path ... } Which means we were able to fetch the password from IPA and were able to validate whether a password provided by a client was correct. It wasn't so we went into updating SAM record for this user, by increasing the number of failed attempts and FreeIPA does not support this operation from Samba side. Hence, the error message. We have a long standing issue to add support for modifying user accounts from Samba side, didn't get there yet. But the issue is not a change in your update. It is that a client provided incorrect password in the first place. That or this user record didn't have NTLM hash stored in the entry at all. This I cannot tell from the log because a corresponding error message in the log requires debug level 5, not 2. I can only assume that before the update this user 'me254' worked, so the hash is at place. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland