2:49 a.m.
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".
>
>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?
>
>Regards,
>Mike
>
>
>On Sat, Mar 21, 2020 at 12:52 AM Alexander Bokovoy <abokovoy(a)redhat.com>
>wrote:
>
>> Hello,
>>
>> On pe, 20 maalis 2020, Michael Deffenbaugh wrote:
>> >Alexander,
>> > If I deploy a *second* IPA server running RHEL/Centos 8, the file
server
>> >with EL8 and continue to run my initial IPA server on EL7, I should be
>> >good, correct? Or does the IPA domain need to be created on EL8
system to
>> >start.
>>
>> That's a good question. IPA upgrades assume that all masters eventually
>> run at the same level, more or less. You can have temporarily masters
with
>> different versions until they all were upgraded.
>>
>> This assumption stays regardless how you started -- we had the same with
>> RHEL 6 and RHEL 7 upgrades in past. There is also a protection in the
>> installers' code that detects if you are trying to install a master
>> using smaller version than already existing master (e.g. creating a
>> replica of RHEL 8-enrolled master will only work with RHEL 8-based IPA,
>> not RHEL 7). So, eventually all these masters would need to become
>> RHEL8.
>>
>> >
>> >Additionally, If I followed any of the instructions from my previous
link,
>> >is there anything I need to undo prior to following the RHEL 8
>> >instructions? Thanks!
>>
>> Standard and recommended method of upgrade is to create a new replica,
>> migrate services to it, and then decommission the old master. So the
>> specific content of that machine is irrelevant in the end. Use of
>> 'ipa-adtrust-install' stays the same (I think since IPA 3.0, actually,
>> it is RHEL 6.4+). For the client (which will be your file server), you'd
>> need to start from scratch, as ipa-client-samba utility will do all
>> configuration, including updates of Samba databases.
>>
>> >
>> >Regards,
>> >Mike
>> >
>> >On Fri, Mar 20, 2020 at 3:36 AM Alexander Bokovoy <abokovoy(a)redhat.com
>
>> >wrote:
>> >
>> >> On pe, 20 maalis 2020, Michael Deffenbaugh via FreeIPA-users wrote:
>> >> >Hey all,
>> >> > I'm having issues getting a setting up a Samba file server
using
>> IPA as
>> >> >an authentication source on my network. I followed the guide
based
>> off of
>> >> >the mailing list chatter
>> >> ><
>> >>
>>
https://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA
>> >> >.
>> >> >No success.
>> >>
>> >> The procedure described there is not really supported. The supported
>> >> configuration is available starting with RHEL 8.1/Fedora 31 and is
>> >> described in RHEL 8 documentation already.
>> >>
>> >> However, your problem is different (below)
>> >>
>> >> >
>> >> >When I try to authenticate using kerberos (or password), I get an
>> access
>> >> >denied error on the client when running "smbclient -k -L
>> >> >fs01.svr.ipa.domain":
>> >> >session setup failed: NT_STATUS_ACCESS_DENIED
>> >> >
>> >> >And it tries to revert to local user lookup on the server:
>> >> >[2020/03/20 02:47:32.669898, 3]
>> >> >../auth/kerberos/gssapi_pac.c:123(gssapi_obtain_pac_blob)
>> >> > gssapi_obtain_pac_blob: obtaining PAC via GSSAPI
>> gss_get_name_attribute
>> >> >failed: The operation or option is not available or unsupported:
No
>> such
>> >> >file or directory
>> >> >[2020/03/20 02:47:32.670131, 3]
>> >> >../auth/gensec/gensec_util.c:55(gensec_generate_session_info_pac)
>> >> > gensec_generate_session_info_pac: Unable to find PAC for mddeff@
>> >> <IPA.DOMAIN>,
>> >> >resorting to local user lookup
>> >>
>> >> Each user trying to access Samba should have SID associated with it.
For
>> >> IPA users you can generate SIDs for those users that do lack it by
>> >> re-running 'ipa-adtrust-install --add-sids' on IPA master that
serves as
>> >> Trust Controller already. You have to have at least one Trust
Controller
>> >> among your IPA masters in order to have Samba integration.
>> >>
>> >> After you did so, make sure 'kinit' again to obtain a new TGT
that
would
>> >> include PAC.
>> >>
>> >> --
>> >> / 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
>>
>>
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland