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
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.
It's possible to remove null ciphers, but then there's really no reason not to
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.
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,
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.
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
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):
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 (22.214.171.124)
Host is up (0.19s latency).
PORT STATE SERVICE
636/tcp open ldapssl
| 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
|_ 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:
Even now, it can be manually configured. This is what GNOME used:
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.
Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project