[Freeipa-devel] Trust relationship between IPA and samba4

[Simo Sorce]

On Thu, 2011-06-23 at 12:33 -0430, Loris Santamaria wrote:
> El jue, 23-06-2011 a las 09:26 -0400, Simo Sorce escribió:
> > On Thu, 2011-06-23 at 08:32 -0430, Loris Santamaria wrote:
> > > Hi,
> > > 
> > > this week I tried to establish a trust relationship between freeipa v2
> > > and a samba 4 domain. In that setup most workstations live in the samba
> > > 4 domain and most servers in the freeIPA domain so I am mainly
> > > interested in having windows being able to authenticate to the linux
> > > servers.
> > > 
> > > First I set up the kerberos 5 trust from the "AD Domains and Trusts"
> > > control panel, then using kadmin.local I added the proper principals to
> > > the kerberos database in freeIPA (krbtgt/IPA.CORPFBK at WIN.CORPFBK and
> > > krbtgt/WIN.CORPFBK at IPA.CORPFBK).
> > > 
> > > Second I added a sasl mapping to 389 DS to have windows users mapped one
> > > to one to IPA users:
> > > 
> > > dn: cn=zz,cn=mapping,cn=sasl,cn=config
> > > objectClass: top
> > > objectClass: nsSaslMapping
> > > nsSaslMapRegexString: \(.*\)@WIN.CORPFBK
> > > cn: zz
> > > nsSaslMapBaseDNTemplate: dc=ipa,dc=corpfbk
> > > nsSaslMapFilterTemplate: (krbPrincipalName=\1 at IPA.CORPFBK)
> > > 
> > > And... everything worked beautifully! I can obtain a ticket from samba 4
> > > and use it to browse 389DS or connect via ssh to a Linux server.
> > > 
> > > Ok this is all well with services that just need to authenticate a user
> > > and then don't care with the realm part of the username, but it is not
> > > enough with services that use the complete principal to gather group
> > > membership of the users, I'm thinking of squid_kerb_auth +
> > > squid_ldap_group or mod_auth_kerb + mod_authzn_ldap.
> > > 
> > > To have the trust relationship work with these services I should store
> > > the samba4 user complete principal name in some attribute of the
> > > corresponding freeIPA user. What would be the proper attribute?
> > > krbPrincipalAliases? 
> > > 
> > > Thanks in advance.
> > 
> > Hi Loris,
> > great work there.
> > 
> > We are actually starting working right now to support trust
> > relationships in FreeIPA, but we haven't attacked the problem of
> > representing user memberships for external accounts.
> > 
> > Given you are mapping krbPrincipalName to the IPA one you shouldn't need
> > to add anything else from the IPA point of view. When you log-in into
> > DirSrv your group memberships will be those of the user that has the
> > same name in IPA. The AD domain groups will not be seen at all of
> > course.
> 
> That is not enough for all applications, see this example:
> 
> 1) User logs in in windows workstation and obtains AD (or samba 4) or
> kerberos ticket, say loris at WIN.CORPFBK
> 
> 2) User tries to browse the web, which is filtered by a kerberized Squid
> proxy
> 
> 3) Thanks to the trust relationship the user is authenticated by
> squid_kerb_auth. Squid receives its full principal name,
> loris at WIN.CORPFBK
> 
> 4) To manage squid authorization the administrator set up
> squid_ldap_group to search in ldap for the group membership of the
> authenticated user.
> 
> 5) Since the mentioned principal isn't stored anywhere in the IPA
> directory, squid authorization fails.
> 
> So, I think one should store the foreign principal in some attribute of
> the IPA user for applications that need it. Another application which
> uses the full principal is apache's mod_auth_kerb.

Ah so you need this for external applications that do searches on their
own.
In that case you could set krbCanonicalName to be the IPA's principal
and add another krbPrincipalName with the AD principal.

This is untested though, and might cause issues to the management
framework and potentially the KDC.

If you can specify the attribute where to look for in these applications
I would suggest to extent your local schema with an additional
class/attribute pair to add to user where you store the mapping for now.

This will also make it simpler to migrate later to whatever solution we
will come up in IPA as you won't have conflicts.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York