On pe, 28 huhti 2023, Alan Latteri wrote:
Hi Alex,
I’ve tried with hostname too, not working with Windows, fine
with macOS. Is there a way to set Windows to use some type of
“basic” SMB connection, not Kerberos? I’m assuming macOS is not
using Kerebos as they are also stand alone non-domain machines,
and work fine with FreeIPA Samba share.
This is with my macOS machine connected to the RHEL 9 based NAS.
[alan@nas02 ~]$ sudo smbstatus
Samba version 4.16.4
PID Username Group Machine Protocol
Version Encryption Signing
----------------------------------------------------------------------------------------------------------------------------------------
131219 alan alan 192.168.1.222 (ipv4:192.168.1.222:50494) SMB3_11
- partial(AES-128-CMAC)
Service pid Machine Connected at Encryption Signing
---------------------------------------------------------------------------------------------
IPC$ 131219 192.168.1.222 Fri Apr 28 10:14:38 AM 2023 PDT - -
nas02 131219 192.168.1.222 Fri Apr 28 10:14:38 AM 2023 PDT - -
No locked files
Without debug logs from nas02, I can only guess that Windows does
something additional even when it is not enrolled to domain. It may be
that it negotiates incompatible parameters or sends requests that Samba
rejects.
If you are able to gather debug logs using instructions from Andreas'
guide
https://www.samba.org/~asn/reporting_samba_bugs.txt, that would be
great.
Thank you,
Alan
> On Apr 28, 2023, at 12:45 AM, Alexander Bokovoy <abokovoy(a)redhat.com> wrote:
>
> On pe, 28 huhti 2023, Alan Latteri via FreeIPA-users wrote:
>> Hello,
>>
>> I have both RHEL 8 and 9 file servers that are authenticated to IPA and
>> setup to export samba shares using the "Samba on an IdM domain member"
>> method. I can access these shares via smb:// on macOS without issue.
>> When I try to access them via Windows 10 or 11, it will prompt for
>> credentials and then reject them. The windows machines are setup
>> standalone, no domain, no AD. I'm only trying to access the share, via
>> //192.XXX.XXX.XX.
>
> Only Kerberos authentication is supported in such setup. Access over IP
> address will not be successful because there is no Kerberos service
> principal named after the IP address, so Windows will not be able to
> obtain a Kerberos service ticket and will fallback to use of NTLMSSP
> which will fail.
>
> Did you try using //nas02.xxx.local ?
>
> Also, while Windows would default to Kerberos and then fallback to
> NTLMSSP, if that machine is not in a domain trusted by IPA, its
> operations will pretty much be limited and may not be working. This is
> an unsupported setup.
>
>
> --
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
>
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland