[Freeipa-users] Re: crypto policies but for SAMBA only - ?
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=5740 --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 -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] Re: crypto policies but for SAMBA only - ?
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. 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. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] Re: crypto policies but for SAMBA only - ?
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? thanks, L. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] Re: crypto policies but for SAMBA only - ?
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... -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] Re: crypto policies but for SAMBA only - ?
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
[2022/01/25 14:21:55.947834, 2, pid=16175]
../../source3/auth/auth.c:348(auth_check_ntlm_password)
check_ntlm_password: Authentication for user [dupa] -> [dupa] FAILED
with error NT_STATUS_WRONG_PASSWORD, authoritative=1
[2022/01/25 14:21:55.947889, 2, pid=16175]
../../auth/auth_log.c:653(log_authentication_event_human_readable)
Auth: [SMB2,(null)] user [INCCN]\[dupa] at [Tue, 25 Jan 2022
14:21:55.947867 GMT] with [NTLMv2] status [NT_STATUS_WRONG_PASSWORD]
workstation [CCN-dupa] remote host [ipv4:10.8.0.144:59930] mapped to
[INCCN]\[dupa]. local host [ipv4:10.8.0.1:445]
{"timestamp": "2022-01-25T14:21:55.948030+", "type":
"Authentication", "Authentication": {"version": {"major": 1, "minor":
2}, "eventId": 4625, "logonId": "0", "logonType": 3, "status":
"NT_STATUS_WRONG_PASSWORD", "localAddress": "ipv4:10.8.0.1:445",
"remoteAddress": "ipv4:10.8.0.144:59930", "serviceDescription": "SMB2",
"authDescription": null, "clientDomain": "INCCN", "clientAccount":
"dupa", "workstation": "CCN-dupa", "becameAccount": null,
"becameDomain": null, "becameSid": null, "mappedAccount": "dupa",
"mappedDomain": "INCCN", "netlogonComputer": null,
"netlogonTrustAccount": null, "netlogonNegotiateFlags": "0x",
"netlogonSecureChannelType": 0, "netlogonTrustAccountSid": null,
"passwordType": "NTLMv2", "duration": 24664}}
thanks, L.
___
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[Freeipa-users] Re: crypto policies but for SAMBA only - ?
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. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
