[Freeipa-users] Securing IPA Redux

Mon May 18 14:26:45 UTC 2015

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. 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 <mkosek at 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
> 