[Freeipa-users] allowing anonymous access to ipa directory

[JR Aquino]

On Apr 13, 2011, at 5:26 PM, Stephen Ingram wrote:

> This question might be better posed on a general directory server
> list, however, as ipa obviously contains very sensitive data, I'm
> curious as to what ipa users think. Although ipa uses extensive acl's
> to shield the most important directory attributes from general view,
> it does allow anonymous access to many of the general entries. I
> notice that many directories do this to allow outside firms to view
> addressbook-type information of the company from their directories and
> referrals also depend on this functionality. I'm wondering though, if
> you have users from multiple domains in your directory with say name
> and email address information available, wouldn't this just be a
> free-for-all for some enterprising spammer or such? Or, if hosting dns
> from ipa, host records available to aid potential attackers to map
> network systems? Shouldn't this be controlled further in some
> instances and perhaps require at least a user bind (if not a TLS/SSL
> layer) to access this information?
> 
> Steve

This question has come up before Stephen.

A conscious effort has been made to provide FreeIPA with a balance of security minded and usable defaults.   

There are circumstances with other Distributions/OS's and nss_ldap situations which require anonymous binds.  It is for this reason that the default for FreeIPA permits read access to a limited scope of the LDAP directory.  You will note that areas of the directory responsible for mapping security authorization controls have been deliberately protected with ACLs.

That being said, there has been an ongoing effort to verify that the FreeIPA framework all functions correctly with ldap security features turned on: 
Always Encrypt/Disable Anonymous or Unauthenticated Binds.

To turn on these features:

You will want to look to: /etc/dirsrv/slapd-DOMAIN-COM/dse.ldif:

nsslapd-allow-anonymous-access: on/off
(This toggles anonymous / unauthenticated binds)

and

nsslapd-minssf: 56 
(This enforces the encryption minimum security strength factor and prevents unencrypted communications)

service dirsrv restart will be required for the features to take effect.

-JR