Thanks for you reply John.
> I would never run FreeIPA over the public internet, bad idea. It’s not as bad as running AD over the internet, but it’s getting pretty close.
FreeIPA is based on 389ds and MIT kerberos. 389ds has risks with MITM attacks (capture plain text traffic) which can be avoided by forcing TLS and anonymous bind (which can be disabled), kerberos according to docs designed to work via untrusted networks. So, what are the risks from technical side?
> Run servers in all zones/regions and have those servers talk to each other (tunnels).
> Stuff inside a zone will do a discovery and find the servers that work, which would be the local servers as the rest isn’t reachable.
This either requires configuring DNS forwarding on local DNS or manual filling of replica list in every host, both of which are headache. For us it doesn't work also because most of our external hosts are in AWS and Route53 (AWS DNS service) doesn't have forwarding functionality. The tricky option is to create local DNS zone in every DC with exact same zone used in FreeIPA deployment but this is dirty and hard maintainable (e.g. every time we add/remove replica we should modify _ldap._tcp records in every datacenter). Ideally, we want DNS zone controlled centrally.
> Regarding DNS: would not do external servers, just use the internal DNS and add conditional forwarders or subzone delegation. (either way, IPA-to-Zone or Zone-to-IPA, as long as it can resolve)
I'm not sure but in doubt if it works. I've tried to bind external DNS name to replica with internal DNS hostname and it didn't work because hostname operated while install is hardcoding in FreeIPA. In other words when you try access in browser
external.example.com in redirects you to internal.example.local which is not resolvable outside of infrastructure. I wanted to bind external name for sharing web interface of FreeIPA with users so they can change their password, set SSH keys by themself, etc. See details about hardcode here
https://pagure.io/freeipa/issue/7479> Problem with ’special’ setups like what you’re describing is that it’s harder to support, upgrade, troubleshoot etc. It also usually means the infrastructure isn’t designed correctly.
Our infrastructure is not spreaded through different regions as you may understood. We are software development company and we host our applications for clients in cloud services as AWS. We utilized FreeIPA because we want to avoid bunch of credentials (use only LDAP creds on all hosts) and centrally manage HBAC, sudo access to hosts running our applications. Honestly, these external hosts are the reason why we thought to expose FreeIPA and hence care about security.