Hi Alexander As this particular stick has many ends, it is easy to grab the wrong one! 8-)
So it sounds like there are / will be at least four integration paths to integrate Samba and FreeIPA. For clarity my current understanding is as follows: 1) The longer term path via SSSD and NTLMSSP 1.1) Documentation: Not yet documented, as under development 1.2) Viability 4.x/4.x: In development, not yet available. (??? Any idea of a possible timeline ???) 1.3) Schema Extensions: Will this path use the AD Trust Extensions? ipasam module? 1.4) Active Directory: Will this path work without AD (like 2) below)? 1.5) Other: Should be more scalable (less duplication of function e.g. connections, caches) 2) A path using the IPASAM module + AD Trust Extensions to the FreeIPA schema, 2.1) Documentation: Is currently best documented further back in this thread (post(s) from Youeen) 2.2) Viability 4.x/4.x: Is viable for FreeIPA 4.x / Samba 4.x. This is the path successfully tested / implemented by Youeen. However, while viable, this solution is not actively supported, as efforts are focussed on 1) above. 2.3) Schema Extensions: Requires schema extensions (ipa-adtrust-install). 2.4) Active Directory: Despite the AD extensions, NO Active Directory required in the architecture. 2.5) Other: half LDAP (to read NTHash/SID), half Kerberos (to bind samba to the LDAP). 3) A path using the LDAPSAM module + Samba Extensions to the FreeIPA schema. 3.1) Documentation: Is best documented under http://techslaves.org/2011/08/24/freeipa-and-samba-3-integration/, (although this article contains some small errors). 3.2) Viability 4.x/4.x: May no longer be fully viable for FreeIPA 4.x / Samba 4.x, or only viable with some quirks / workarounds. 3.3) Schema Extensions: Requires schema extensions via LDAPMODIFY / LDAPADD scripts + changes to FreeIPA python scripts and WebUI 3.4) Active Directory: NO Active Directory required in the architecture. (Samba clients can be “islands”). 3.5) Other: Is the path that I am currently using in production (originally with 3.x/3.x, now with 4.x/4.x) 4) A path using the kerberos module and Active Directory + AD Trust Extensions to the FreeIPA schema. 4.1) Documentation: Is documented under: https://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA 4.2) Viability 4.x/4.x: ??? The article above mentions FreeIPA 3.3 +, but also RHEL 7.1 preferred / sssd 1.12.2+, which suggests 4.x / 4.x. 4.3) Schema Extensions: Requires schema extensions (ipa-adtrust-install) 4.4) Active Directory: Requires Active Directory + Domain in the architecture. (i.e. Samba clients are NOT “islands”). If we can confirm / correct the above, it can serve as the basis for a FreeIPA Wiki Page, with child How-to articles for each of the viable solutions. As I am using solution 3) in production, yet other have problems getting it working at all, I have now set up a throwaway VM running FreeIPA 4.1 and Samba 4.1.12, and can experiment freely with 3), and after that with 2). Cheers Chris From: Alexander Bokovoy <aboko...@redhat.com> To: Christopher Lamb/Switzerland/IBM@IBMCH Cc: "Matt ." <yamakasi....@gmail.com>, "freeipa-users@redhat.com" <freeipa-users@redhat.com> Date: 07.08.2015 23:09 Subject: Re: [Freeipa-users] Ubuntu Samba Server Auth against IPA On Thu, 06 Aug 2015, Christopher Lamb wrote: >Hi Matt > >As far as I can make out, there are at least 2 viable Samba / FreeIPA >integration paths. > >The route I took is suited where there is no Active Directory involved: In >my case all the Windows, OSX and Linux clients are islands that sit on the >same network. > >The route that Youenn has taken (unless I have got completely the wrong end >of the stick) requires Active Directory in the architecture. Yes, you are at the wrong end of the stick. You don't need AD in the architecture here. You can reuse IPA design for AD integration via trust for normal Samba integration but use ipasam.so instead of ldapsam.so. This is what Youenn did. The only way we don't support it (yet) is because we think doing a longer term solution via SSSD and NTLMSSP support is better scalability vise -- your SSSD client is already having LDAP connection and is already holding identity mappings in the cache so there is no need to run separate LDAP connection in smbd/winbindd for that and cache the same data in a different way. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project