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 <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