[Freeipa-users] Re: secure freeipa exposed to internet

2019-05-23 Thread John Keates via FreeIPA-users 
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-getting-started.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-clouds/
 

 ) and works great with IPA and even MS AD.

John

> On 23 May 2019, at 18:53, Stepan Vardanyan via FreeIPA-users 
>  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@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@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

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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

[Freeipa-users] Re: secure freeipa exposed to internet

2019-05-23 Thread Stepan Vardanyan via FreeIPA-users 
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@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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

[Freeipa-users] Re: secure freeipa exposed to internet

2019-05-23 Thread John Keates via FreeIPA-users 
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 
>  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 
>>  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@lists.fedorahosted.org
>>> To unsubscribe send an email to freeipa-users-le...@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
>> ___
>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>> To unsubscribe send an email to freeipa-users-le...@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
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@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
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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

[Freeipa-users] Re: secure freeipa exposed to internet

2019-05-23 Thread Angus Clarke via FreeIPA-users 
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 
>  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@lists.fedorahosted.org
> > To unsubscribe send an email to freeipa-users-le...@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
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@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
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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

[Freeipa-users] Re: secure freeipa exposed to internet

2019-05-23 Thread John Keates via FreeIPA-users 
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 
>  wrote:
> 
> See this image to have basic understanding of our infrastructure - 
> https://imgur.com/a/R5c8BWW
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@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
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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

[Freeipa-users] Re: secure freeipa exposed to internet

2019-05-22 Thread Alex Corcoles via FreeIPA-users 
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@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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

[Freeipa-users] Re: secure freeipa exposed to internet

2019-05-22 Thread Alex Corcoles via FreeIPA-users 
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@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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

[Freeipa-users] Re: secure freeipa exposed to internet

2019-05-22 Thread Stepan Vardanyan via FreeIPA-users 
See this image to have basic understanding of our infrastructure - 
https://imgur.com/a/R5c8BWW
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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

[Freeipa-users] Re: secure freeipa exposed to internet

2019-05-22 Thread Stepan Vardanyan via FreeIPA-users 
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
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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

[Freeipa-users] Re: secure freeipa exposed to internet

2019-05-22 Thread John Keates via FreeIPA-users 
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 
>  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@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@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
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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

[Freeipa-users] Re: secure freeipa exposed to internet

2019-05-22 Thread Stepan Vardanyan via FreeIPA-users 
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@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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

[Freeipa-users] Re: secure freeipa exposed to internet

2019-05-22 Thread Kristian Petersen via FreeIPA-users 
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@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@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@lists.fedorahosted.org
> > To unsubscribe send an email to
> freeipa-users-le...@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
>
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@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
>


-- 
Kristian Petersen
System Administrator
BYU Dept. of Chemistry and Biochemistry
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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

[Freeipa-users] Re: secure freeipa exposed to internet

2019-05-21 Thread Charles Hedrick via FreeIPA-users 
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 
>  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@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@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

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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

[Freeipa-users] Re: secure freeipa exposed to internet

2019-05-21 Thread Stepan Vardanyan via FreeIPA-users 
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@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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

[Freeipa-users] Re: secure freeipa exposed to internet

2019-05-20 Thread Natxo Asenjo via FreeIPA-users 
hi,

On Mon, May 20, 2019 at 8:11 PM 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.
>

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/html/linux_domain_identity_authentication_and_policy_guide/p.security-hardening

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
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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

[Freeipa-users] Re: secure freeipa exposed to internet

2019-05-20 Thread Step Vardanyan via FreeIPA-users 
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  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

[Freeipa-users] Re: secure freeipa exposed to internet

2019-05-20 Thread John Keates via FreeIPA-users 
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 
>  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-le...@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
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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