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(a)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(a)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(a)lists.fedorahosted.org
> > To unsubscribe send an email to
> freeipa-users-leave(a)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.fedoraho...
>
>