Alexander,
Thank you for the clarification on all points. Sorry for being dense on
this topic; I've never had to delve into the depths of Samba configuration
before. And totally understand on the CentOS front; it'll get fixed when
it does. Thanks!
Regards,
Mike
On Sat, Mar 21, 2020 at 6:15 AM Alexander Bokovoy <abokovoy(a)redhat.com>
wrote:
On la, 21 maalis 2020, Michael Deffenbaugh via FreeIPA-users wrote:
>On Sat, Mar 21, 2020 at 2:50 AM Alexander Bokovoy <abokovoy(a)redhat.com>
>wrote:
>
>> On la, 21 maalis 2020, Michael Deffenbaugh via FreeIPA-users wrote:
>> >Gotcha, thank you for the background.
>> >
>> >Added wrench in the gears. Fired up an EL8 box, made it a replica, ran
>> >ipa-adtrust-install, everything seemed to go smoothly. Opened up the
>> >firewall ports, went to restart the ipa service per the RedHat manual
>> ><
>>
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/...
>> >,
>> >failed to start. Ran it to ground and it's the Samba service giving
me an
>> >error:
>> >
>> >[2020/03/21 01:21:19.193530, 0]
>> >../../source3/passdb/pdb_interface.c:171(make_pdb_method_name)
>> > No builtin nor plugin backend for ipasam found
>> >
>> >Thoughts?
>>
>> You need to show more details but this looks like you don't have
>> ipa-server-trust-ad package installed (though that wouldn't be possible
>> if you were able to run ipa-adtrust-install).
>>
>> What is your exact version? I remember there was bug in CentOS 8.1 where
>> they built IPA before rebuilding Samba and that caused issues as Samba
>> did change ABI in some internal libraries, making previously built IPA
>> modules unloadable:
>>
>>
https://bugs.centos.org/view.php?id=16929
>>
>> I was assured by CentOS people they rebuilt the packages already but it
>> seems still to be an issue.
>>
>
>Exact Version on IPA Master:
> CentOS 8.1
> ipa-4.8.0-13.module_el8.1.0+265+e1e65be4.src.rpm
> idm DL1 [e]
> common [d] [i], adtrust, client, dns, server The
>Red Hat Enterprise Linux Identity Management system module
>
>
>Do I need to be on a different profile? Apologies, still trying to get
>used to "streams"/"profiles".
No, it is not a question of a profile. It is CentOS bug I pointed you
to. ipa package is still built against wrong (outdated) version of Samba
in CentOS 8.1, as can be seen from
https://koji.mbox.centos.org/pkgs/packages/ipa/4.8.0/13.module_el8.1.0+26...
Sadly, none of us in FreeIPA can rebuild CentOS packages, so we cannot
really help there. The bug was raised and it seems to not attended well
there.
>> >Additionally, does the EL8 solution to the Samba problem have the same
>> >limitation that only IPA/AD joined systems will be able to
authenticate to
>> >the Samba shares? End goal is to have all systems on my network
>> (including
>> >some MacBooks) be able to hit these shares. Thanks!
>>
>> If you'd use Kerberos authentication from them, they will work.
>> Non-Kerberos authentication will most likely not work.
>>
>>
>Are there plans for non-kerberos authentication (password auth) support
for
>an IPA backed samba share on the roadmap? I can see many use cases
>(non-domain joined systems, OSX systems, scanners/MFDs, etc.). Should I
>just make an AD DC and cross-trust it to support the samba server?
Please do not mix password auth and non-Kerberos auth, they are not the
same. What is not supported is an authentication based on using RC4
hashes. This means that, for example, pure cifs.ko module without
Kerberos in use would not work as FreeIPA does not provide RC4 hashes
anymore (and Fedora 30+, RHEL 8.2 beta and so on are preventing their
generation and use over Kerberos). However, Samba client side code (e.g.
smbclient) can automatically request Kerberos ticket using a password
you provided with -Uuser%password option (or interactively). The same
happens with Windows systems.
I have no idea how macOS would behave, though. I haven't tried that yet
myself.
Going forward, a pure non-Kerberos authentication for SMB protocol would
require a replacement method that doesn't use RC4 hashes. It is not
implemented and not even designed yet. We have some technical means to
enable it with very recent MIT Kerberos and Heimdal versions but it
needs implementations from both client and server sides. These are
probably at least few years away until that work starts.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland