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, 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


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!


On Sat, Mar 21, 2020 at 12:52 AM Alexander Bokovoy <> wrote:

On pe, 20 maalis 2020, Michael Deffenbaugh wrote:
>  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

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

>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.

>On Fri, Mar 20, 2020 at 3:36 AM Alexander Bokovoy <>
>> 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
>> ><
>> >.
>> >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@
>> >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