On 05/18/2015 08:26 AM, Martin Kosek wrote:
Adding freeipa-users list back, to keep others in the loop.

On 05/18/2015 12:32 PM, Brian Topping wrote:
Thanks for taking the time to write that, Martin. It's good to have a reference 
to build from.

Result of "ida-client-install" outside the firewall with port 636 accessible:
Ah, I mostly just use 636 as a convenience port to show the supported cryptos,
389 is really the port we should be using by default.

Of course, 389 port + STARTTLS environment turned on, to make sure passwords do
not go in clean over the wire.

Please make sure the following ports are opened in the firewall settings:
      TCP: 80, 88, 389
      UDP: 88 (at least one of TCP/UDP ports 88 has to be open)
Also note that following ports are necessary for ipa-client working properly 
after enrollment:
      TCP: 464
      UDP: 464, 123 (if NTP enabled)
No mention of 636, confirmed by tcpdump that it's not trying. Also no option on 
command line to specify 636.

Opening up 389 means that some misconfigured client could expose passwords.

Not necessarily.
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/SecureConnections.html#requiring-secure-connections

It's possible to remove null ciphers, but then there's really no reason not to 
use 636.

Seems like ipa-client-install should try 636 by default, then fall back to 389 
in it's various forms, no?
I think the general direction here was the opposite. To work on the port 389 as
the common denominator, offering both password-less traffic and encrypted
traffic. I am not sure if there were other reasons too, I would let Rob or
Ludwig reply here if they know.

Martin

On May 18, 2015, at 4:10 PM, Martin Kosek <mko...@redhat.com> wrote:

On 05/15/2015 01:33 PM, Brian Topping wrote:
In the (apparently) first message to the list in 2014, 
https://www.redhat.com/archives/freeipa-users/2014-January/msg00000.html 
<https://www.redhat.com/archives/freeipa-users/2014-January/msg00000.html> 
addressed questions about securing IPA and I don't see much other talk about it. Now 
that 4.x is prevalent, I wanted to bring it up again.
This is the default by design. However, note that in FreeIPA 4.0+ you can
change that default (permission-mod) and let users or some of the user
attributes be only shown for authenticated users.

https://www.freeipa.org/page/V4/Permissions_V2

So, from my POV, this is not a flaw.

I'd like my installation to be allow hardened machines (i.e. in the cloud with encrypted 
filesystems) to be a part of the domain. I believe this means that I need to expose 
Kerberos and LDAP to the world, since the machines could live anywhere. I don't believe I 
need to worry about KRB5, but I am concerned about 389-DS since it seems somewhat difficult 
to force TLS (https://blog.routedlogic.net/?p=119 
<https://blog.routedlogic.net/?p=119>) and maybe that's a bad idea under IPA for 
reasons I thought I'd ask here about. Last year's thread also referenced 
https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/disabling-anon-binds.html 
<https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/disabling-anon-binds.html>
 and I thought I would check to see if that's still necessary under 4.x.
389-DS and TLS should be also fixed, since FreeIPA 4.1 (RHEL/CentOS 7.1):

https://fedorahosted.org/freeipa/ticket/4653

This is an nmap test against the FreeIPA public demo (4.1.x):

$ nmap --script ssl-enum-ciphers -p 636 ipa.demo1.freeipa.org

Starting Nmap 6.47 ( http://nmap.org ) at 2015-05-18 11:08 CEST
Nmap scan report for ipa.demo1.freeipa.org (209.132.178.99)
Host is up (0.19s latency).
PORT    STATE SERVICE
636/tcp open  ldapssl
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA256 - strong
|       TLS_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA256 - strong
|       TLS_RSA_WITH_RC4_128_MD5 - strong
|       TLS_RSA_WITH_RC4_128_SHA - strong
|     compressors:
|       NULL
|_  least strength: strong

Nmap done: 1 IP address (1 host up) scanned in 6.19 seconds

Setting up the firewall to allow cloud networks in is always an option, but if 
I can get a secure IPA setup going, it would also allow road warriors to kinit 
and use their credentials for configured intranet sites without having to turn 
on the VPN (which can really slow things down from remote parts of the globe).
BTW, if you are concerned about exposed Kerberos traffic, FreeIPA 4.2 plans to
offer Kerberos-over-HTTP functionality by default:
https://fedorahosted.org/freeipa/ticket/4801

Even now, it can be manually configured. This is what GNOME used:
https://www.dragonsreach.it/2014/10/07/the-gnome-infrastructure-is-now-powered-by-freeipa/

So, if I am reading my notes correctly, there should be no blockers in using
FreeIPA in your environment. If yes, please let me know.

Martin

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to