On 26/01/2022 16:23, Alexander Bokovoy wrote:
On ti, 25 tammi 2022, lejeczek via FreeIPA-users wrote:
On 25/01/2022 14:31, Alexander Bokovoy wrote:
On ti, 25 tammi 2022, lejeczek via FreeIPA-users wrote:
On 25/01/2022 12:11, Alexander Bokovoy wrote:
On ti, 25 tammi 2022, lejeczek via FreeIPA-users wrote:
Hi guys.
If that can be a news for some - I'd like to share a
finding: it's possible to have ipa-integrated Samba
serving non-enrolled clients, both Linux & Windows,
with passwords for authentication. (which has been
long & will continue to be a must-have for me)
Question for @devel - above I get with simply by
switching to 'LEGACY' - is it possible to do that but
only for IPA-Samba(+ whatever required bits) as
oppose to system-widely?
It would be great to have IPA capable of that -
perhaps an "enhancement" to future releases.
FreeIPA is not a single application, so it is hard to
apply that.
I wonder if DEFAULT:AD-SUPPORT would work for you too?
Or something on
top of AD-SUPPORT one? The following is what I have on
Fedora 35:
$ cat
/usr/share/crypto-policies/policies/modules/AD-SUPPORT.pmod
# AD-SUPPORT subpolicy is intended to be used in
Active Directory
# environments where either accounts or trusted domain
objects were not yet
# migrated to AES or future encryption types. Active
Directory implicitly
# requires RC4 and MD5 (arcfour-hmac-md5) in Kerberos
by default.
cipher@kerberos = RC4-128+
hash@kerberos = MD5+
Samba uses GnuTLS, so may be expanding @gnutls scope
in a similar way
would work?
E.g., add
/etc/crypto-policies/policies/modules/MY-MODULE.pmod that
includes
cipher@kerberos = RC4-128+
hash@kerberos = MD5+
cipher@gnutls = RC4-128+
hash@gnutls = MD5+
and then set sytem-wide policy to use
DEFAULT:MY-MODULE as a policy.
This doesn't define it per application but at least
limits use of
insecure types to Kerberos and any application using
GnuTLS.
I actually haven't tried this all.
Testing with this policy now and nope, Samba 4.15.3 says:
...
[2022/01/25 14:21:55.930113, 2, pid=16175]
ipa_sam.c:3645(init_sam_from_ldap)
init_sam_from_ldap: Entry found for user: dupa
[2022/01/25 14:21:55.947759, 1, pid=16175]
../../source3/auth/check_samsec.c:454(check_sam_security)
Failed to modify entry: NT_STATUS_NOT_IMPLEMENTED
All these modifications of the policy will not change
the fact that we
do not implement modification of SAM entry in IPA SAM
module. This means
you are getting in a different code path here.
So probably more changes to the policy are needed...
Here is something VERY !!!!? peculiar...
1) I could both smbclient & ssh between IPA masters with
passwords
2) I could ssh from a non-enrolled to IPA master with the
password
3) non-enrolled smbclient _failed_ as with the log
snipped, with password
then I looked at that Samba log again and did, on a master:
-> $ ipa passwd dupa
now I do ! can 3)
WTF? I must say.
user was created by IPA with '--password
--password-expiration=20310312232428Z' as args to 'ipa
user-add'
So, the policy seems good!! but that 'monstrosity' ?
anybody will agree will be a 'bug', right?
I think what you see above is that the user was created
before IPA setup
was enabled to handle trust configuration (which is a
pre-requisite to
generate NT hashes). So when you re-generated password,
that triggered
adding NT hash to that user.
Well.. I do not think that was that(or rather should not
be), for my first master was set up with:
-> $ ipa-server-install --setup-dns --setup-kra
--no-forwarders --idstart=57400000 --admin-password=#diradm
--ds-password=#dirsrv --enable-compat --setup-adtrust
and every next master as well
-> $ ipa-replica-install --setup-dns --no-forwarders
--setup-ca --enable-compat --setup-adtrust
Would that be be what you think still, when instantiating
IPA(4.9.6) in ways such as above?
thanks, L
With newer IPA (4.9.8 in Fedora or CentOS 9 Stream, for
example, or
recent RHEL 8.5 update) you still need to prepare IPA to
work with trust
(ipa-adtrust-install) but proper NT hash generation
internally is
enabled from initial install instead of when
ipa-adtrust-install is run.
For new installations this should reduce the gap as users
created after
install would already be ready to access Samba when
ipa-adtrust-install
will be run.
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
