2:25 p.m.
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
How - if it should be possible at all - to have a service,
say Samba, which would serve a "virtual" FQDN? - which would
make High-Available service for what I need.
What I've tried so far - adding host/service seems not
good/enough.
many thanks, L.
12:19 a.m.
On su, 16 tammi 2022, 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
How - if it should be possible at all - to have a service, say Samba,
which would serve a "virtual" FQDN? - which would make High-Available
service for what I need.
What I've tried so far - adding host/service seems not good/enough.
The only HA service supported by Samba upstream is use of CTDB over a
distributed file system that supports required semantics.
https://wiki.samba.org/index.php/CTDB_and_Clustered_Samba
It is impossible to say what is exact problem you have with your setup
with that small amount of details. If you are already using CTDB, I'd
suggest to share more of your configuration and logs. If you are not
using CTDB for this configuration, there is most likely no way to help
with that without going too deep into technical details and since this
configuration would not be supported by either Samba or FreeIPA
upstream, this would probably be a waste of everyone's time.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
3:18 a.m.
On 17/01/2022 06:19, Alexander Bokovoy wrote:
On su, 16 tammi 2022, 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
>
> How - if it should be possible at all - to have a service, say Samba,
> which would serve a "virtual" FQDN? - which would make High-Available
> service for what I need.
> What I've tried so far - adding host/service seems not good/enough.
The only HA service supported by Samba upstream is use of CTDB over a
distributed file system that supports required semantics.
https://wiki.samba.org/index.php/CTDB_and_Clustered_Samba
It is impossible to say what is exact problem you have with your setup
with that small amount of details. If you are already using CTDB, I'd
suggest to share more of your configuration and logs. If you are not
using CTDB for this configuration, there is most likely no way to help
with that without going too deep into technical details and since this
configuration would not be supported by either Samba or FreeIPA
upstream, this would probably be a waste of everyone's time.
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.
3:28 a.m.
On 17/01/2022 09:18, lejeczek via FreeIPA-users wrote:
On 17/01/2022 06:19, Alexander Bokovoy wrote:
> On su, 16 tammi 2022, 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
>>
>> How - if it should be possible at all - to have a service, say
>> Samba, which would serve a "virtual" FQDN? - which would make
>> High-Available service for what I need.
>> What I've tried so far - adding host/service seems not good/enough.
>
> The only HA service supported by Samba upstream is use of CTDB over a
> distributed file system that supports required semantics.
> https://wiki.samba.org/index.php/CTDB_and_Clustered_Samba
>
> It is impossible to say what is exact problem you have with your setup
> with that small amount of details. If you are already using CTDB, I'd
> suggest to share more of your configuration and logs. If you are not
> using CTDB for this configuration, there is most likely no way to help
> with that without going too deep into technical details and since this
> configuration would not be supported by either Samba or FreeIPA
> upstream, this would probably be a waste of everyone's time.
>
>
>
>
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.
I realize one bit I might have left vague - Samba's customers/clients,
those no need to authenticate with Kerberos, password authentication is
good enough(what my "old" IPA does)
5:30 a.m.
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?
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}}
10:06 a.m.
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.
>
> 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}}
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to
> freeipa-users-leave(a)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.fedoraho...
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
10:26 a.m.
On ma, 17 tammi 2022, 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.
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.
>
>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}}
>_______________________________________________
>FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>To unsubscribe send an email to
>freeipa-users-leave(a)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.fedoraho...
>Do not reply to spam on the list, report it:
>https://pagure.io/fedora-infrastructure
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)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.fedoraho...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
10:38 a.m.
On 1/17/22 10:26, Alexander Bokovoy wrote:
On ma, 17 tammi 2022, 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.
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.
An underappreciated realm of 'care about security' are what you might
call 'walled gardens' that have no expectation interior systems provide
more than vandalism-level security, as they have little to no routine
connection to the internet, and the key on the office door, security
cameras and off-site backups are all that's needed.
11:17 a.m.
On ma, 17 tammi 2022, Harry G. Coin wrote:
On 1/17/22 10:26, Alexander Bokovoy wrote:
>On ma, 17 tammi 2022, 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.
>
>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.
>
An underappreciated realm of 'care about security' are what you might
call 'walled gardens' that have no expectation interior systems
provide more than vandalism-level security, as they have little to no
routine connection to the internet, and the key on the office door,
security cameras and off-site backups are all that's needed.
While there are configurations like that, a much more real is a social
engineering factor where a system within your security perimeter is
compromised due to other factors and then exploited to attack internal
infrastructure.
Known attacks on RC4 hashes were within 52 hours to decrypt the has five
years ago. This is using CPU. With GPU it is even faster, so this is not
a fairy tale stuff, it is pretty much real.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
11:08 a.m.
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_
many thanks, L.
>
> 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}}
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to
> freeipa-users-leave(a)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.fedoraho...
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to
freeipa-users-leave(a)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.fedoraho...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
11:35 a.m.
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
11:36 a.m.
On 1/17/22 11:08, 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_
many thanks, L.
I'm not even close to sure what it would look like exactly, but maybe
what we're seeing is the 'Large-Corp' 'MS-IBM-i-zation' of
redhat/freeipa fedora/centos and something like a 'rocky linux' version
of what freeipa does is called for. Most all the business in the world
is small business, while most of the money to pay developers does not
come from there. Large corporations want to own things and need
recurring revenue. Small business values tools that do the job and
prefer not to buy new tools until the old one breaks. Software does not
rust. So there's this disconnect. So very many businesses see nothing
in Windows 11 that helps them generate revenue that wasn't in Windows
7. I bet as more folks move to quickbooks 'on line' version the
justification for having windows systems at all in many small businesses
goes away now as linux based corporate workstations are completely
sufficient.
Bind is doing internally much of what freeipa's added dnssec aims for.
In small business, dns changes are infrequent so updating flat files and
the occasional 'rndc' command is enough for the bind interface
(bind-dns-ldap goes away) (An integrated dhcp server would be nice).
Samba has its own internal ldap server as I understand it. Maybe a
'roll of freeipa' where it's assumed samba will be the ad/dc (to the
extent one is needed anyhow, but it turns on ldap in samba and retires
the need for an external ns-slapd).
Something to think about.
839
days inactive
840
days old
freeipa-users@lists.fedorahosted.org
11 comments
3 participants
participants (3)
-
Alexander Bokovoy -
Harry G. Coin -
lejeczek