On ma, 17 tammi 2022, lejeczek via FreeIPA-users wrote:
On 17/01/2022 16:06, Harry G. Coin via FreeIPA-users wrote:
>
>On 1/17/22 05:30, lejeczek via FreeIPA-users wrote:
>>On 16/01/2022 20:25, lejeczek via FreeIPA-users wrote:
>>>Hi guys.
>>>
>>>I have an old - set up ~2 yrs ago - IPA domain which "survived"
>>>updates/upgrades till this day in such a way that integrated
>>>Samba serves up under different hostname/domain and serves
>>>non-enrolled clients(win 10) too.
>>>
>>>With new deployment, 4.9.6, just adding things to just DNS -
>>>which worked in that "old" domain - does _not_ do the trick.
>>>With only such "simple" DNS Samba does respond, clients connect
>>>and get password prompt but Samba says: NT_STATUS_WRONG_PASSWORD
>>>
>>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?
>
>
>Lately it seems so much of freeipa's developers time is spent
>chasing Active Directory and related issues, when something 'breaks'
>'a small business with a handful of windows boxes (maybe a mix of
>'home' and 'professional' versions, and a mix of windows 7 or 8 or
>10) sharing off of freeipa's samba instance with no domain
>capability, used very basic 'map network dirve' and 'usernames and
>passwords' (entirely sufficient for most businesses which are small
>and will never have money enough for a full time IT staff member) I
>wonder if the upgrades still test for that 'widely needed not too
>technically exciting' setup.
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_
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