[Freeipa-users] Closing off some ports for FreeIPA

[Alexander Bokovoy]

On Fri, 01 Apr 2016, Jeremy Utley wrote:
>Hello all on the list.
>
>First off, if this is documented somewhere I'm not aware of, I apologize
>for the noise.  I've spent a couple of hours google searching google
>without success, so pointers to any documentation I've missed would be
>greatly appreciated!
>
>We're in the process of setting up a FreeIPA system within our ultra-secure
>PCI zone.  It's currently working well, and we are very happy with it.
>However, we know that come our next audit, we're going to get hit on a few
>things, so I would like to ask about blocking off some additional ports
>(specifically 80, 389, 53).  53 I think will be safe to block off, as all
>our clients actually use a dedicated caching DNS system with unbound, which
>has been configured to forward all queries for the zone "ipa.domain.com" to
>the FreeIPA servers, so we should be able to block 53 from everywhere but
>the unbound servers without breakage.
>
>However, port 80 and 389 I'm not so sure about.  I know most things that
>hit port 80 get redirected to 443, and 389 provides STARTTLS functionality,
>but in theory, these ports can provide unencrypted communications, and
>therefore our auditors will ask that they be closed off.  However, in my
>research so far, I have not been able to find out what the ramifications
>would be to blocking these ports for the IPA system itself (would it fall
>back to using SSL on 636? Would API calls fail if port 80 is closed?).
You can always disable anonymous bind for LDAP by raising min ssf above
zero. You can read in more details how to increase security of 389-ds
communications here:
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/SecureConnections.html

FreeIPA does not require port 80 to be working for its API calls.

Switching to LDAPS via port 636 is not recommended. The use of LDAP over
SSL was common in LDAP Version 2 (LDAPv2) but it was never standardized
in any formal specification. This usage has been deprecated along with
LDAPv2, which was officially retired in 2003.

-- 
/ Alexander Bokovoy