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.

On Tue, 21 May 2019 at 00:16, John Keates <john@keates.nl> wrote:
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.

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.

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)
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.

John

> On 20 May 2019, at 20:11, Stepan Vardanyan via FreeIPA-users <freeipa-users@lists.fedorahosted.org> wrote:
>
> Hello,
>
> I've proposed to migrate from OpenLDAP to FreeIPA solution in my organization because the former did not met our requirements as we moving to Single Sign On. We migrated to FreeIPA but set it up with internal DNS name. This was dumb decision as we have a lot of external hosts in AWS and other datacenters which we want to join to our FreeIPA for authentication with one credential and utilize policies (HBAC, sudoers) easily and centrally.
>
> We found that there is two solutions:
> - setup tunnels between AWS and datacenters for making our DNS zone and FreeIPA servers available;
> - redeploy whole FreeIPA with external DNS name and expose FreeIPA servers to Internet.
> We end up with second option because first one is very complex, but second option make us think about security.
> What came to mind is:
> - disable anonymous bind;
> - prohibit unencrypted traffic and improve communications security by using options: nsslapd-minssf=128, nsslapd-require-secure-binds=on, sslVersionMin=TLS1.1.
>
> So, there is several questions:
> 1) Is there anything else from security perspective that we should care, configure properly (Kerberos DC for example)?
> 2) We want to share with users only one Web service from specific replica so users will not cause replication conflicts by modifying entries in other replicas. Is it ok if we close web ports (80, 443) only to localhost on other replicas and leave all other ports on all replicas opened to internet (389,636,88,464)?
> 3) How secure and strong is default SASL/GSSAPI replication mechanism? I've noticed that traffic is encrypted but can be decrypted by using servers kerberos keytab
> 4) Overall, even with all previous concerns taken into account cared is it proper to open FreeIPA to internet? This is kinda rhetorical question as we see that this is only choice for us but just want to hear some advices, expert vision.
>
> P.S. We don't utilize FreeIPA internal DNS service. DNS is configured on external hosts
>
> Thanks in advance.
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org