----- Original Message -----
> 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).
(1), (2), and (4) are the same. You enable FreeIPA with ipa-adtrust-install and 
then you configure some IPA client as a Samba file server. The way you 
configure it depends on (1) or (2) or (4) but really, (2) and (4) are the same 
and (1) requires ipa-adtrust-install-based configuration because SSSD relies on 
the same LDAP schema for IPA and SIDs.

There is nothing wrong with (3) except that you are responsible yourself in 
maintaining the schema extensions and configuration, and generate SIDs, etc.

I need to update the code in Samba upstream to merge some of ipasam features to 
ldapsam and maybe make it aware of IPA schema/ability to switch using IPA 
schema so that the configuration could be simplified.
At least authenticating with kerberos is something I'd like to push back to 
Samba's ldapsam.


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

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

Reply via email to