[Freeipa-users] Ubuntu Samba Server Auth against IPA

[Christopher Lamb]

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 <abokovoy at redhat.com>
To:	Christopher Lamb/Switzerland/IBM at IBMCH
Cc:	"Matt ." <yamakasi.014 at gmail.com>, "freeipa-users at redhat.com"
            <freeipa-users at 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