On 21/12/2020 21:07, Alexander Bokovoy wrote:
On ma, 21 joulu 2020, lejeczek via FreeIPA-users wrote:
hi gents
Longish time ago, I think more than a year, I asked and
gotten a succinct reply about ways to access IPA's
integrated Samba from non-member Win clients.
If I remember correctly it was possible - answer was by I
think one of you IPA devels - for one version of IPA
(with rhel/centos 7) and still is, to have such Win
clients to access Samba, but on newer IPA it was not and
at that time it was undecided - I was told - whether it
was going to be "fixed" in future IPA releases.
Is there more to shed light on now? Is or will there be a
way in which IPA+Samba latest/future releases allow
non-members?
If by non-members Windows systems you understand Windows
systems not
enrolled into any Active Directory deployment, then
nothing did change
here. SMB protocol has two ways of authenticating users:
- with NTLM-based authentication, using a password-based
challenge-response system as described in [MS-NLMP]
specification
- with Kerberos tickets, the whole scheme is described in
[MS-KILE]
specification
Non-enrolled Windows clients cannot authenticate with
Kerberos against
FreeIPA as they have no real way to obtain user's Kerberos
ticket
granting ticket (against what? what user?).
NTLM-based authentication does not support any recent
cryptographic
methods and uses message digest algorithms for integrity
and RC4 cipher
for encryption. It is generally not advised for use due to
known
security issues.
In Fedora 31+ and RHEL 8 system-wide crypto policy denies
the usage of
RC4 cipher in system crypto libraries unless system-wide
crypto policy
is downgraded or a special AD-SUPPORT subpolicy is activated.
In order to authenticate a user with NTLM-based approach,
Samba file
server needs to know a hash of the user's credentials in
RC4 format.
FreeIPA uses MIT Kerberos library facilities to generate
RC4 hashes
stored in ipaNTHash attribute in user's entry. If MIT
Kerberos library
does not allow generation of the hash due to system-wide
policy, no RC4
hash will be available for the user stored in FreeIPA and
no NTLM-based
authentication will be possible for the user in question.
Would it be as simple as toggling in a "weak" crypto-policiy
and re/generating RC4 ipaNTHash?
Or even easier would be to switch to RC4 crypto policy prior
to IPA deployment?
Or none of above would work/help in IPA VERSION: 4.8.7,
API_VERSION: 2.239 (centos 8.3) as those patches you talked
of are not sewn in.
as a thought - I'm sure many of us regular users will be
looking and hoping for a practical and ideally supported(to
execute in orderly manner) way to make this work in our
small isolated setups, even if that meant weaker cryptos.
Until very recently Samba and FreeIPA integration didn't
allow to
properly query FreeIPA about these user NTLM hashes. This
was fixed
upstream during autumn 2020 and we added this change to
Samba in Fedora
33 and RHEL 8.4. This requires FreeIPA to have some of the
patches I am
yet to submit upstream and which we are developing as a
part of the
Global Catalog effort.
Over last year or so we improved Samba upstream to not use
NTLM
authentication when system-wide crypto policy demands that
RC4 is not to
be used. As a result, in FIPS mode Samba in RHEL 8.4 or
later and Fedora
33 or later will reject NTLM authentication as a weak
crypto and will
prefer using Kerberos authentication in this mode. This
does not play
well with non-enrolled Windows clients which do not use
Kerberos.
Since there is no mechanism to replace NTLM for
non-enrolled clients,
the only way going forward without enrolling them is to
re-use
capabilities that exist in Windows on top of Kerberos
implementation.
Microsoft Windows allows to negotiate additional
authentication
capabilities as a part of Kerberos negotiation through an
extension
called NegoEX, described in [MS-NEGOEX] specification. It
doesn't
require a client and a server to be enrolled into an
Active Directory
environment but instead allow to exchange opaque (to
Kerberos protocol)
messages between the client and the server, then use
external entity to
validate both parts. Microsoft uses this extension to
allow binding of
your local Windows user account to a social login
mechanism like
live.com or a face identification method. It also uses
this to provide
mutual authentication between two Windows systems which
are not enrolled
into the same domain.
There is no implementation of this mechanism in free
software. MIT
Kerberos 1.18 provides NegoEX exchange support, opening a
possibility to
write such mechanism. Until it is written, we have no way
to support
non-enrolled clients with contemporary crypto algorithms.
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
