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