1:11 p.m.
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.
1:16 p.m.
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...
2:33 p.m.
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...
>
>
3 p.m.
hi,
On Mon, May 20, 2019 at 8:11 PM 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.
A vpn between data centers is a best practice. It does not have to be very
complex or expensive, openvpn comes to mind, but if you have no experience
with vpns I can understand that they can look very hard.
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.
This is ok, I would probably bump tls to 1.2 but you may have applications
that do not work properly with that so you know better ;-)
So, there is several questions:
1) Is there anything else from security perspective that we should
care,
configure properly (Kerberos DC for example)?
Take a look at the 'Security hardening' section of the documentation:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/...
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)?
This is a bit unclear. All objects in the ldap servers are replicated (all
ldap servers are masters).
You do not need to open the whole internet to your environmnent, you can
firewall everything but the hosts that need authenticating/authorizing.
I would block internet wide connections to unencrypted protocols, so no
389, just ldaps/636. I know you can use starttls, but why bother. You need
http for crl and ocsp, but the rest is https.
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
If you have the keytab, you have the password. This is normal. Secure the
keytab. The replication is as secure as you have configured your directory
server component, I guess. If you set sslVersionMin: TLS1.2, then it's
pretty secure. Remember, security is layered, so restrict ldap traffic to
the ldap servers only to trusted networks (most firewalls can be scripted
nowadays).
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.
With proper care it should be safe. I would use 2FA (otp and/or pkinit),
both work really well with freeipa for any internet facing service, have
the environment properly pentested and enable a central logging mechanism
that gets audited regularly.
HTH.
--
regards,
Natxo
5:19 p.m.
Stepan Vardanyan via FreeIPA-users
<freeipa-users(a)lists.fedorahosted.org> writes:
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)?
Kerberos is fine to expose. If you are concerned, it's possible to
limit the surface with kdcproxy - IPA already sets this up - and then
block port 88.
The main problem, though, with exposing services to the public internet
is handling unexpected load. If you can't handle it, then your system
effectively goes down under DOS.
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
This is how Kerberos works, yes. A keytab is a bit like the private key
on a certificate (in this case). Keep your keytabs safe :)
Thanks,
--Robbie
11:48 a.m.
Hi Natxo,
A vpn between data centers is a best practice. It does not have to be
very
complex or expensive, openvpn comes to mind, but if you have no experience
with vpns I can understand that they can look very hard.
I have enough experience
with OpenVPN) The problem is that we have dozens of AWS accounts (or datacenters) so
openvpn server should be set up in every account with proper monitoring, because if VPN
fail authentication stop working (sssd cache save some time but it's still one point
of failure). Things get worse if we stick with private DNS zone in FreeIPA. This requires
setup local DNS forwarding in every AWS account. Maintaining this is pretty hard.
This is ok, I would probably bump tls to 1.2 but you may have
applications
that do not work properly with that so you know better ;-)
You guess correct) Some
legacy applications still in place and they binded to LDAP
Take a look at the 'Security hardening' section of the
documentation:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/...
Thanks. WIll take a look
This is a bit unclear. All objects in the ldap servers are replicated
(all
ldap servers are masters).
You do not need to open the whole internet to your environmnent, you can
firewall everything but the hosts that need authenticating/authorizing.
The problem
is that AWS is kind of dynamic. If host not use elastic IP (static), but public it will
change after instance started and stopped. Firewalling AWS hosts would be nightmare)
As for HTTP. We would like to keep LDAP consistent. Actually we want master slave schema,
trying to achieve it with that dirty way. Problem with multi master is that it give
possibility for replication conflicts when simultaneous changes of one object from
different replica take place. Even RFC exists which describe it
https://tools.ietf.org/html/draft-zeilenga-ldup-harmful-00
Thanks.
2:18 p.m.
2 of our 3 IPA servers are exposed to the Internet. However we have a host firewall that
limits the hosts that can access us. We use iptables with an ipset. I have a cron job that
dumps a list of hosts known to IPA and adds them to the ipset. So basically we’ll only
accept connections from hosts that we know about. That was easier for us to manage than to
do things on a network basis, since we’ve got hosts in lots of subnets. I use the kdcproxy
for working at home.
Initially I thought we’d expose the IPA web interface. But in the end users normally do
things with custom web applications I’ve written, so we didn’t need to make the IPA web
app available. My web application runs on a different server.
On May 21, 2019, at 12:48 PM, Stepan Vardanyan via FreeIPA-users
<freeipa-users(a)lists.fedorahosted.org> wrote:
Hi Natxo,
> A vpn between data centers is a best practice. It does not have to be very
> complex or expensive, openvpn comes to mind, but if you have no experience
> with vpns I can understand that they can look very hard.
I have enough experience with OpenVPN) The problem is that we have dozens of AWS accounts
(or datacenters) so openvpn server should be set up in every account with proper
monitoring, because if VPN fail authentication stop working (sssd cache save some time but
it's still one point of failure). Things get worse if we stick with private DNS zone
in FreeIPA. This requires setup local DNS forwarding in every AWS account. Maintaining
this is pretty hard.
> This is ok, I would probably bump tls to 1.2 but you may have applications
> that do not work properly with that so you know better ;-)
You guess correct) Some legacy applications still in place and they binded to LDAP
> Take a look at the 'Security hardening' section of the documentation:
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/...
Thanks. WIll take a look
> This is a bit unclear. All objects in the ldap servers are replicated (all
> ldap servers are masters).
>
> You do not need to open the whole internet to your environmnent, you can
> firewall everything but the hosts that need authenticating/authorizing.
The problem is that AWS is kind of dynamic. If host not use elastic IP (static), but
public it will change after instance started and stopped. Firewalling AWS hosts would be
nightmare)
As for HTTP. We would like to keep LDAP consistent. Actually we want master slave schema,
trying to achieve it with that dirty way. Problem with multi master is that it give
possibility for replication conflicts when simultaneous changes of one object from
different replica take place. Even RFC exists which describe it
https://tools.ietf.org/html/draft-zeilenga-ldup-harmful-00
Thanks.
_______________________________________________
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...
9 a.m.
Dmitti Pal, the director at Red Hat who manages Red Hat IdM, says that IdM
is great for internal stuff but you should use Directory Server for outside
stuff or if you need a customized schema. Both can be integrated with Red
Hat SSO.
On Tue, May 21, 2019 at 1:19 PM Charles Hedrick via FreeIPA-users <
freeipa-users(a)lists.fedorahosted.org> wrote:
2 of our 3 IPA servers are exposed to the Internet. However we have a
host
firewall that limits the hosts that can access us. We use iptables with an
ipset. I have a cron job that dumps a list of hosts known to IPA and adds
them to the ipset. So basically we’ll only accept connections from hosts
that we know about. That was easier for us to manage than to do things on a
network basis, since we’ve got hosts in lots of subnets. I use the kdcproxy
for working at home.
Initially I thought we’d expose the IPA web interface. But in the end
users normally do things with custom web applications I’ve written, so we
didn’t need to make the IPA web app available. My web application runs on a
different server.
> On May 21, 2019, at 12:48 PM, Stepan Vardanyan via FreeIPA-users <
freeipa-users(a)lists.fedorahosted.org> wrote:
>
> Hi Natxo,
>
>> A vpn between data centers is a best practice. It does not have to be
very
>> complex or expensive, openvpn comes to mind, but if you have no
experience
>> with vpns I can understand that they can look very hard.
> I have enough experience with OpenVPN) The problem is that we have
dozens of AWS accounts (or datacenters) so openvpn server should be set up
in every account with proper monitoring, because if VPN fail authentication
stop working (sssd cache save some time but it's still one point of
failure). Things get worse if we stick with private DNS zone in FreeIPA.
This requires setup local DNS forwarding in every AWS account. Maintaining
this is pretty hard.
>
>> This is ok, I would probably bump tls to 1.2 but you may have
applications
>> that do not work properly with that so you know better ;-)
> You guess correct) Some legacy applications still in place and they
binded to LDAP
>
>> Take a look at the 'Security hardening' section of the documentation:
>>
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/.
..
> Thanks. WIll take a look
>
>> This is a bit unclear. All objects in the ldap servers are replicated
(all
>> ldap servers are masters).
>>
>> You do not need to open the whole internet to your environmnent, you can
>> firewall everything but the hosts that need authenticating/authorizing.
> The problem is that AWS is kind of dynamic. If host not use elastic IP
(static), but public it will change after instance started and stopped.
Firewalling AWS hosts would be nightmare)
> As for HTTP. We would like to keep LDAP consistent. Actually we want
master slave schema, trying to achieve it with that dirty way. Problem with
multi master is that it give possibility for replication conflicts when
simultaneous changes of one object from different replica take place. Even
RFC exists which describe it
https://tools.ietf.org/html/draft-zeilenga-ldup-harmful-00
>
> Thanks.
> _______________________________________________
> 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...
_______________________________________________
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...
--
Kristian Petersen
System Administrator
BYU Dept. of Chemistry and Biochemistry
11:05 a.m.
But Directory Server is just plain LDAP, without policies (hbac, sudo), isn't it?
Policies are the reason why we moved from OpenLDAP.
11:11 a.m.
I’d think that if you can remote-enrol hosts as IPA clients, it would be real easy to also
enrol them as VPN clients first. Heck, even Wireguard would be good enough, even without a
full audit.
You’d just add a single route to the route table for that VPN to the IPA server and you’re
good to go.
On 22 May 2019, at 18:05, Stepan Vardanyan via FreeIPA-users
<freeipa-users(a)lists.fedorahosted.org> wrote:
But Directory Server is just plain LDAP, without policies (hbac, sudo), isn't it?
Policies are the reason why we moved from OpenLDAP.
_______________________________________________
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...
11:40 a.m.
This even more complicate infrastructure and make ipa clients depend on VPN.
P.S. Wireguard is not prod ready) See here https://www.wireguard.com/#work-in-progress
11:42 a.m.
See this image to have basic understanding of our infrastructure -
https://imgur.com/a/R5c8BWW
3:44 p.m.
Well, in that scenario site-to-site VPNs should not be too terrible (AWS
provides one, for instance).
I think that certainly having a default install which is "safe" to
expose to the Internet would be a very nice feature. However, I realize
that has its cost and maybe its drawbacks, so of course I'm not sure if
it's the best use of development time for the project.
I can say that it would be one of the top items in my features wishlist
for FreeIPA*, but then again I'm neither a typical, nor paying, nor
particularly smart customer, so I'm just talking here and I don't think
I should be listened much. I think VPNs also have a cost, so not having
to setup them up and maintain them is a huge plus in my book.
Cheers,
Álex
* the other two would be very low effort monitoring (e.g. a built-in
health check URL or command line tool included in the default install)
and low effort full backup/restore + recovery.
On 5/22/19 6:42 PM, Stepan Vardanyan via FreeIPA-users wrote:
> See this image to have basic understanding of our infrastructure -
https://imgur.com/a/R5c8BWW
> _______________________________________________
> 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...
3:46 p.m.
Well, in that scenario site-to-site VPNs should not be too terrible (AWS
provides one, for instance).
I think that certainly having a default install which is "safe" to
expose to the Internet would be a very nice feature. However, I realize
that has its cost and maybe its drawbacks, so of course I'm not sure if
it's the best use of development time for the project.
I can say that it would be one of the top items in my features wishlist
for FreeIPA*, but then again I'm neither a typical, nor paying, nor
particularly smart customer, so I'm just talking here and I don't think
I should be listened much. I think VPNs also have a cost, so not having
to setup them up and maintain them is a huge plus in my book.
Cheers,
Álex
* the other two would be very low effort monitoring (e.g. a built-in
health check URL or command line tool included in the default install)
and low effort full backup/restore + recovery.
On 5/22/19 6:42 PM, Stepan Vardanyan via FreeIPA-users wrote:
> See this image to have basic understanding of our infrastructure -
> https://imgur.com/a/R5c8BWW
> _______________________________________________
> 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...
2:11 a.m.
Hello
Best practises say to deploy 2 - 3 IPA server per site (Deployment Recommendations)
however I've never really understood why. We run 2 IPA servers in each of our primary
DCs and then connect our smaller remote sites to those IPA servers over IPSEC VPNs. For
example, IPA clients in a small site in Italy connect to an IPA server in London and an
IPA server in Paris (I haven't yet looked at service discovery.)
Regards
Angus
> On 22 May 2019 at 22:46 Alex Corcoles via FreeIPA-users
<freeipa-users(a)lists.fedorahosted.org> wrote:
>
>
> Well, in that scenario site-to-site VPNs should not be too terrible (AWS
> provides one, for instance).
>
> I think that certainly having a default install which is "safe" to
> expose to the Internet would be a very nice feature. However, I realize
> that has its cost and maybe its drawbacks, so of course I'm not sure if
> it's the best use of development time for the project.
>
> I can say that it would be one of the top items in my features wishlist
> for FreeIPA*, but then again I'm neither a typical, nor paying, nor
> particularly smart customer, so I'm just talking here and I don't think
> I should be listened much. I think VPNs also have a cost, so not having
> to setup them up and maintain them is a huge plus in my book.
>
> Cheers,
>
> Álex
>
> * the other two would be very low effort monitoring (e.g. a built-in
> health check URL or command line tool included in the default install)
> and low effort full backup/restore + recovery.
>
> On 5/22/19 6:42 PM, Stepan Vardanyan via FreeIPA-users wrote:
> > See this image to have basic understanding of our infrastructure -
> > https://imgur.com/a/R5c8BWW
> > _______________________________________________
> > 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...
> _______________________________________________
> 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...
6:59 a.m.
That’s not too bad.
We have a similar setup somewhere, about 39 AWS accounts, some with multiple VPCs, three
physical locations, one with two separate DCs (the others have one).
For AWS we simply add PCXes where possible with sg source rules, makes it pretty secure.
For other accounts we run OpenVPN or IPSec site-to-site.
The physical DCs have DirectConnect fiber attachments straight to AWS (expensive!) but
also fallback IPSec tunnels (relatively cheap).
It’s all automated as well; we build IPA AMIs to auto-deploy IPA everywhere, and where we
can’t deploy we run OpenVPN AMIs and when we can’t even do that we run IPSec.
Those deployments are done using Terraform and Ansible; this means that adding a new
connection or account or client simply means adding two lines to a YAML file and deploying
the change.
Doing all of this manually is also possible, but at that point you might ask yourself if
looking for a better job/employer is less painful ;-)
John
On 22 May 2019, at 18:42, Stepan Vardanyan via FreeIPA-users
<freeipa-users(a)lists.fedorahosted.org> wrote:
See this image to have basic understanding of our infrastructure -
https://imgur.com/a/R5c8BWW
_______________________________________________
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...
8:16 a.m.
That’s mostly for general redundancy and speed. Speed is both for load balancing and
querying local servers first.
Say you don’t talk to IPA often and your cross-continental latency isn’t an issue, then
running 1 server in Iceland would fit.
For us, the redundancy part is relatively important because our sites and DCs have to be
able to run independently. We don’t want an issue in one DC or AWS account to affect
another.
This way, we could have 9 out of 10 systems fail and still have a fast and reliable
system. So far we had some cross connects fail, some undersea fibers broken and a few key
expiration issues cause inter-DC connectivity issues, but it never caused and service
interruption. Total cost of running multiple instances is negligible as long as you have a
reasonable amount of automation in place, or as we could say: cattle, not pets.
John
On 23 May 2019, at 09:11, Angus Clarke via FreeIPA-users
<freeipa-users(a)lists.fedorahosted.org> wrote:
Hello
Best practises say to deploy 2 - 3 IPA server per site (Deployment Recommendations)
however I've never really understood why. We run 2 IPA servers in each of our primary
DCs and then connect our smaller remote sites to those IPA servers over IPSEC VPNs. For
example, IPA clients in a small site in Italy connect to an IPA server in London and an
IPA server in Paris (I haven't yet looked at service discovery.)
Regards
Angus
> On 22 May 2019 at 22:46 Alex Corcoles via FreeIPA-users
<freeipa-users(a)lists.fedorahosted.org> wrote:
>
>
> Well, in that scenario site-to-site VPNs should not be too terrible (AWS
> provides one, for instance).
>
> I think that certainly having a default install which is "safe" to
> expose to the Internet would be a very nice feature. However, I realize
> that has its cost and maybe its drawbacks, so of course I'm not sure if
> it's the best use of development time for the project.
>
> I can say that it would be one of the top items in my features wishlist
> for FreeIPA*, but then again I'm neither a typical, nor paying, nor
> particularly smart customer, so I'm just talking here and I don't think
> I should be listened much. I think VPNs also have a cost, so not having
> to setup them up and maintain them is a huge plus in my book.
>
> Cheers,
>
> Álex
>
> * the other two would be very low effort monitoring (e.g. a built-in
> health check URL or command line tool included in the default install)
> and low effort full backup/restore + recovery.
>
> On 5/22/19 6:42 PM, Stepan Vardanyan via FreeIPA-users wrote:
>> See this image to have basic understanding of our infrastructure -
>> https://imgur.com/a/R5c8BWW
>> _______________________________________________
>> 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...
> _______________________________________________
> 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...
_______________________________________________
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...
11:53 a.m.
After a lot of replies I see that using VPN tunnels to reach servers is the best option.
But, there is DNS issue also.
I see two options with private zone (both are unwanted for us):
- set up DNS forwarding to our private DNS server in each AWS account (using bind9 for
example);
- create in Route53 zone with exact same domain name and populate it with actual SRV
records (this one is pretty ugly).
So, what about using public DNS domain in FreeIPA (say ipa.example.com)?
12:24 p.m.
You don’t need to setup a DNS server or Route 53 Zone, you can use the route53resolver. It
allows a conditional forwarder for any domain you wish and you can point it straight at an
IPA DNS server.
It’s built in to AWS:
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-gettin...
<https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-gettin...
+ https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html
<https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html>
(Announcment:
https://aws.amazon.com/blogs/aws/new-amazon-route-53-resolver-for-hybrid-...
<https://aws.amazon.com/blogs/aws/new-amazon-route-53-resolver-for-hybrid-... )
and works great with IPA and even MS AD.
John
On 23 May 2019, at 18:53, Stepan Vardanyan via FreeIPA-users
<freeipa-users(a)lists.fedorahosted.org> wrote:
After a lot of replies I see that using VPN tunnels to reach servers is the best option.
But, there is DNS issue also.
I see two options with private zone (both are unwanted for us):
- set up DNS forwarding to our private DNS server in each AWS account (using bind9 for
example);
- create in Route53 zone with exact same domain name and populate it with actual SRV
records (this one is pretty ugly).
So, what about using public DNS domain in FreeIPA (say ipa.example.com)?
_______________________________________________
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...
1792
days inactive
1795
days old
freeipa-users@lists.fedorahosted.org
18 comments
10 participants
participants (10)
-
Alex Corcoles -
Alex Corcoles -
Angus Clarke -
Charles Hedrick -
John Keates -
Kristian Petersen -
Natxo Asenjo -
Robbie Harwood -
Step Vardanyan -
Stepan Vardanyan