[Fedora-directory-users] TLS authentication

[Adams, Samuel D Contr AFRL/HEDR]

I have been adding, modifying, and removing ACIs on different parts of
my directory, generally breaking things.  The restore feature has been
useful lately.  For example, if you talk away the anonymous access aci
or at least anonymous read to the various parts of your directory, you
can certainly prevent anonymous access to that part of the directory,
but then a lot of important features break like PAM or seeing those
parts in the admin console.  

Is there an easier way of modifying ACIs a know beforehand what the
effect will be other than modifying them in the GUI or changing the
expression and restarting the server?

Sam Adams
General Dynamics - Information Technology
Phone: 210.536.5945

-----Original Message-----
From: fedora-directory-users-bounces at redhat.com
[mailto:fedora-directory-users-bounces at redhat.com] On Behalf Of Pete
Rowley
Sent: Tuesday, August 08, 2006 3:11 PM
To: General discussion list for the Fedora Directory server project.
Subject: Re: [Fedora-directory-users] TLS authentication

Adams Samuel D Contr AFRL/HEDR wrote:

>I also have two medium vulnerabilities the keep popping up with ISS
that
>I need to resolve but can't seem to find the proper configuration in
the
>admin console. 
>
>" LDAP NullBind: LDAP anonymous access to directory
>
>
>  
>
...

>" LDAP Schema: LDAP schema information gathering
>
>  
>
In addition to the other posters comments I would point out that with 
zero access control configured in the DS nobody but the directory 
manager can do anything - zero access by default.  The best method of 
securing the server is to start with that blank sheet and selectively 
enable targeted operations for targeted users/groups on targeted sets of

entries. For example, your requirement is that pam operates: add the aci

that makes that happen and no more. The default aci's added on install 
should be treated as examples only that just happen to be suitable for 
casual evaluation.

Most deployments can get away with very few aci's in order to enforce 
their policy. Adding aci's when something is found not to work correctly

due to insufficient access is a lot less painful than the ramifications 
of overly broad grants of access.

-- 
Pete