[Freeipa-users] FreeIPA Deployment Proposal (request for recommendations)

Fri Apr 1 08:12:21 UTC 2016

Hello,

most importantly:
- FreeIPA does not support real multi-tenancy
- FreeIPA is not a general purpose DNS server and does not (and will not)
support DNS views

If real multi-tenancy is required or not depends on your use-case and
possibilities your users have.

Do users join their custom machines into FreeIPA? If not and everything is
let's say hidden behind web app, it might be possible to hack it in a way
which pretends multi-tenancy.

Missing support for DNS views can be worked around with custom scripting or
even better: FreeIPA team is looking forward to better integration
capabilities with external DNS infrastructure. If you are willing to work with
us on it the progress will be faster :-)

Petr^2 Spacek

On 1.4.2016 00:22, Michael S. Moody wrote:
> Hello FreeIPA Devs/Mailing List,
> 
> We use FreeIPA to great success in several places, but we want to roll it
> out for us. Thus, we want to ask about best practices for the type of
> deployment we’re planning. First, FreeIPA is truly awesome, and the glue
> that holds all these pieces together is really a phenomenal achievement. We
> want to set up our FreeIPA deployment according to best practices.
> 
> As it stands today, we want to implement FreeIPA to take over the
> authentication duties and DNS duties of an infrastructure which we are in
> the process of rebuilding from scratch, so we’re not worried about
> retroactively making things work on older systems. This is an important
> point for us, basically consider that we’re doing everything from scratch,
> and re-basing off of CentOS 7. (Apologies in advance for the wall-of-text).
> 
> Who we are:
> 
> We are a Managed Services Provider with multiple clients, and manage our
> clients’ systems end-to-end. This enables us to have full control over the
> infrastructure.
> 
> Topology:
> 
> We currently have 3 (where we’ll place FreeIPA at least) datacenter
> facilities in the USA, and are bringing a 4th DC online in the EU shortly.
> These datacenters are protected via enterprise-grade hardware firewalls,
> and we have VPNs across the DCs to allow our various infrastructure pieces
> to communicate on internal subnets vs across the public WAN. Additionally,
> we advertise our own IP addresses via BGP. We also have (bind-based) DNS in
> each DC, but primarily for external purposes.
> 
> Private:
> 
> US-EAST: 172.29.0.0/19
> 
> US-WEST: 172.29.32.0/19
> 
> US-SOUTH: 172.29.64.0/19
> 
> EU-WEST: 172.29.96.0/19
> 
> Public:
> 
> US-EAST: 1.1.1.0/24
> 
> US-WEST: 1.1.2.0/24
> 
> US-SOUTH: 1.1.3.0/24
> 
> EU-WEST: 1.1.4.0/24
> 
> Goals:
> 
>    1.
> 
>    We want to have centralized authentication for our entire infrastructure.
>    2.
> 
>    We want the authentication to be highly available (FreeIPA replicas)
>    3.
> 
>    We want to have a drastically improved DNS system that handles both
>    external (domain names) and internal (systems).
>    4.
> 
>    We want that DNS system to also be highly available (FreeIPA replicas
>    with bind-ldap as the backend seems to be the best way)
>    5.
> 
>    We want to use our own SSL certificates if at all possible (wildcard
>    certificates, letsencrypt, etc)
>    6.
> 
>    We would like to be multi-tenant with domains/realms/whatever so that
>    CLIENT1 can have their authentication of their systems centralized through
>    our FreeIPA. Similar for CLIENT2, CLIENT3, etc. The clients don’t care, so
>    how this is set up is up to us/best practices.
>    7.
> 
>    As part of the multi-tenancy, we don’t want all users to be able to see
>    all users. To be more clear, we want to have 1 FreeIPA infrastructure that
>    can use our domain (let’s call it GREATMSP.COM), and have systems for
>    CLIENT1 as part of CLIENT1.GREATMSP.COM or whatever the best way is. We
>    also want where if they login to FreeIPA, they’ll only see their
>    users/systems.
>    8.
> 
>    If we use GREATMSP.COM as the domain, we of course want to still have
>    all of our normal DNS records (MX, NS, etc, etc). We’re perfectly good with
>    (and prefer) using the more robust FreeIPA as nameservers for our root
>    domain name.
>    9.
> 
>    We would like users to be able to self manage (FreeIPA web ui)
>    10.
> 
>    We plan to have at least 2 x FreeIPA servers in each DC, with the more
>    likely scenario being 4 x in each DC.
>    11.
> 
>    We want to use DNSSEC wherever possible. Because security.
>    12.
> 
>    Ideally, can we use the FreeIPA servers as NTP servers?
> 
> 
> Questions:
> 
>    1.
> 
>    What services/ports can we safely expose to the outside world, and what
>    services/ports NEED to be exposed to the outside world for this to work
>    effectively with systems in multiple DCs?
>    2.
> 
>    As part of the above, should authentication only be done across the VPN?
>    3.
> 
>    Can we safely use our main domain name (GREATMSP.COM) as the domain for
>    FreeIPA? As part of this, we have say, TICKETING.GREATMSP.COM (a web app
>    which will remain the same), and for systems, we might have
>    SSH01.US-EAST.PRODUCTION.GREATMSP.COM (or perhaps
>    SSH01.DC.US-EAST.PRODUCTION.GREATMSP.COM for the internal, and
>    SSH01.US-EAST.PRODUCTION.GREATMSP.COM for the external).
>    4.
> 
>    Can we use this as a more generalized DNS system for other customer
>    domains as opposed to our current bind system? If so, is it as simple as
>    registering all of the FreeIPA servers (replicas) as NS servers with the
>    registrar?
>    5.
> 
>    Since we want to be effectively multi-tenant, can we make it so that all
>    authentication from the CLIENT1 infrastructure uses external addresses vs
>    us needing to open holes into our FreeIPA infrastructure via VPN? How safe
>    is/can this be?
>    6.
> 
>    We see some notes about CA-Less being somewhat broken. Is this true?
> 
> 
> (Things we don’t really need/want to do):
> 
>    1.
> 
>    Have each Client have their own SSL certs (complete non issue)
> 
> 
> Things we don’t know we don’t know:
> 
>    1.
> 
>    Robustness?
>    2.
> 
>    Security?
>    3.
> 
>    Performance?
>    4.
> 
>    Anything else we haven’t thought of?
> 
> 
> 
> Any help you can provide would be wonderful. We have attached a proposed
> diagram of what we're thinking of trying to accomplish.
> 
> Thanks in advance,
> 
> Michael
> 
> 
> 

-- 
Petr^2 Spacek