[Freeipa-users] Looking for instructions on one way subtree sync IPA->IPA
David Kupka
dkupka at redhat.com
Fri Feb 10 08:34:24 UTC 2017
On Thu, Feb 09, 2017 at 01:45:42PM +0000, Piper, Nick wrote:
> Hi Alexander,
>
> Alexander Bokovoy wrote:
> >On to, 09 helmi 2017, Piper, Nick wrote:
>
> >>We're currently using FreeIPA 4.2.0, and we have two unrelated
> >>instances of IdM server. We'd like the user list which IPA maintains
> >>in one, to be a superset of the other; so we're looking for one way
> >>replication (of cn=users,cn=accounts,dc=realm, not necessarily of host
> >>entries etc.)
>
> >>We use a different 'dc' in each instance, and could use a different cn
> >>too if needed.
>
> >In short, there is no support for IPA-IPA trust or replication. There
> >are many reasons for that, including some complex technical issues on
> >how this could be reliably working.
>
> >If you are after actual POSIX systems where users need to logon to use
> >their services, you may try to configure SSSD with two different domains
> >(for IPA1 and IPA2). You can look at discussion we had in 2014:
> >https://www.redhat.com/archives/freeipa-users/2014-January/msg00075.html
> >You are not necessarily need to enroll the machine in two different
> >realms, any Kerberos principal would do instead of a host principal to
> >authenticate against IPA LDAP (see sssd-ldap man page for details on
> >ldap_sasl_authid).
>
> Thanks, so the idea here would be for SSSD (and any other software
> which uses krb or LDAP) to be configured to use both our IPA instances
> simultaneously. I'll ponder on this and check into if each of our
> applications has support for multiple LDAP servers.
>
> >>We believe we need one way sync (including passwords) to be able to
> >>authenticate users which are mastered in the 'remote' IPA, even when
> >>the 'remote' IPA is offline. Another option we might explore is
> >>'cross-forest trust', although I believe this would make
> >>authentication unavailable if the 'master' IPA is unavailable. Both
> >>are discussed at
> >>https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html#summary-indirect
> >>, but again in the context of AD/IPA rather than IPA/IPA.
>
> >>I'd welcome any pointers on trust or one-way replication between two
> >>IPA instances!
>
> >You are stuck, there is no such support between different IPA
> >deployments.
>
> >It would help to actually explain your real use case. So far you
> >outlined above your approaches to solve a problem which is not really
> >stated upfront.
>
> Thanks - I'll try to explain the wider picture:
>
> We have a Hadoop deployment which uses an instance of FreeIPA both for
> the Operating Systems (using SSSD) and applications which use LDAP
> (for authentication, authorisation and for directory search.) This
> FreeIPA (Project IPA) is intended to be authoritative for user
> accounts which are specific to the project, such as administrators,
> contractors, and so on. The project fits into a wider estate, which
> uses FreeIPA (call this Enterprise IPA) to manage general user
> accounts.
>
> For auditing and consistency purposes, the general users managed in
> Enterprise IPA should be able to run POSIX processes under their
> username (in this case YARN containers), log into project tools (which
> use LDAP to Project IPA - although this could be changed to
> SAML/Shibboleth which might avoid Project IPA having to validate
> credentials) and so on.
>
>
> +----------------------------------------------------------+
> | |
> | +----------------------------------------------------+ |
> | | | |
> | | +-------+ +---------+ +--------+ +----------+ | |
> | | | IPA | |Linux OS | |Linux OS| | App using| | |
> | | | | | | | | | LDAP | | |
> | | +-------+ +---------+ +--------+ +----------+ | |
> | | | |
> | | ^ | |
> | |Project +--------------------------------------------
> | +----------------------------------------------------+ | user1 can own
> | | processes here
> | |
> | |
> | |
> | |
> | +--------+ +---------+ +---------+ +------------+ |
> | | | | | | | | | |
> | | IPA | | Linux | | Linux | | App using | |
> | | | | OS | | OS | | LDAP | |
> | +--------+ +---------+ +---------+ +------------+ |
> | |
> | ^ |
> | | |
> | Wider Enterprise Estate |
> +--------|-------------------------------------------------+
> |
> |
> user1 details mastered here
>
>
> If 'Enterprise' IPA was instead Active Directory, I believe the above
> could be achieved with a One way Trust?
>
> We have an additional aim to be able to set authorisation rules in the
> Project IPA (e.g., putting the Enterprise IPA users into groups where
> the groups are managed in Project IPA.)
>
> Thanks,
>
> Nick
>
> --
> 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
Hi Nick,
I might be missing something but I would say that the Project IPA is not
necessary in the desribed scenario.
You can create accounts for all the users involved in Project in Enterprise
IPA and assign them to Project group. You can also enroll all Project hosts
to Enterprise IPA and add them to Project hostgroup. Then you can use HBAC
rules [1] to:
* disable the default allow_all rule
* allow everyone in Project IPA to acces Project hostgroup
* allow all but Project group to access Any host
Employees that are also part of other group will be still able to access
everything. Contractors will be only in Project group and won't be able to
access your Enterprise environment.
Of course, unless this is against your company policy...
[1] http://www.freeipa.org/page/Howto/HBAC_and_allow_all
--
David Kupka
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20170210/8a9618e8/attachment.sig>
More information about the Freeipa-users
mailing list