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.
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
------ Server Config ----- [global] workgroup = SVR realm = SVR.IPA.DOMAIN dedicated keytab file = /etc/samba/samba.keytab kerberos method = dedicated keytab use kerberos keytab = true log file = /var/log/samba/log.%m log level = 3 security = ads ----------
Client: Fedora 30
File Server: CentOS 7.7, Samba 4.9.1, ipa-client 4.6.5 selinux is enabled.
Any thoughts? Thanks in advance!
Regards, Mike
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, 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.
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!
Regards, Mike
On Fri, Mar 20, 2020 at 3:36 AM Alexander Bokovoy abokovoy@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
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@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
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/html/configuring_and_managing_identity_management/setting-up-samba-on-an-idm-domain-member_configuring-and-managing-idm#preparing-the-idm-domain-for-installing-samba-on-domain-members_setting-up-samba-on-an-idm-domain-member, 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?
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!
Regards, Mike
On Sat, Mar 21, 2020 at 12:52 AM Alexander Bokovoy abokovoy@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@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
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/html/configuring_and_managing_identity_management/setting-up-samba-on-an-idm-domain-member_configuring-and-managing-idm#preparing-the-idm-domain-for-installing-samba-on-domain-members_setting-up-samba-on-an-idm-domain-member, 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.
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.
Regards, Mike
On Sat, Mar 21, 2020 at 12:52 AM Alexander Bokovoy abokovoy@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@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
On Sat, Mar 21, 2020 at 2:50 AM Alexander Bokovoy abokovoy@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/htm...
, 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@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@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
On la, 21 maalis 2020, Michael Deffenbaugh via FreeIPA-users wrote:
On Sat, Mar 21, 2020 at 2:50 AM Alexander Bokovoy abokovoy@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/htm...
, 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+265+e...
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, 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@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@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/htm...
, 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+265+e...
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
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Michael Deffenbaugh