<div dir="ltr">On Fri, Jan 3, 2014 at 10:29 AM, Dmitri Pal <span dir="ltr"><<a href="mailto:dpal@redhat.com" target="_blank">dpal@redhat.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    On 01/03/2014 12:50 PM, Will Sheldon wrote:
    <blockquote type="cite">
      <div dir="ltr">
        <div>
          <div>Thanks Petr, that certainly makes sense from the point of
            view of functionality. <br>
            <br>
            I do think the default is sane, but there are a lot of
            possible deployment scenarios and my concern is that a
            junior or time poor admin looking to implement a trusted,
            secure solution should be made aware of any potential data
            leakage during configuration, (preferably in big red letters
            in the documentation, or better still, the install script).
            <br>
            <br>
          </div>
          <div>Though I am reluctant to draw comparisons between IPA and
            MS AD they do seem inevitable. AD restricts anonymous binds
            to the <span>rootDSE entry by default and as such
              this may be considered by many to be the expected default.
              Extra care should therefore be made to point out this
              difference. To do otherwise risks </span>undermining the
            confidence of users in the security of the solution.<br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    It is a double edge sword. We compared IPA to LDAP based solutions
    and with those you have (had) anonymous bind enabled by default.<br>
    IMO it is the question of a migration. The field of centralized
    authentication is crowded with all sorts of different solutions,
    though not that integrated as AD or IdM.<br>
    It seems that migrating and then tightening security to the level
    you need is the way to go. The default you suggest might be a
    barrier to migration as people usually tackle problems one step at a
    time.<br>
    I am not against changing the default eventually but I am not sure
    it is the time to. <br>
    <br>
    But may be I am wrong. Are there any opinions on the matter?  </div></blockquote><div><br></div><div>I think traditionally LDAP-based solutions have been used as true directories where one might be able to search for people through say a Web-based interface, for example at a university. Whereas AD can also be deployed as a directory, but more often than not though say an email Interface (e.g. Outlook) where the user has already gained access via their own credentials so there was not a need to allow anonymous binds. I like following the tradition of LDAP-based directories where anonymous access is allowed by default, however, it would be really nice as the OP requested to have controls available via the WebUI where the admin could apply ACLs to the directory to restrict access to various areas. As changing the overall access scheme requires a directory restart, I'm not too sure how easy it would be to incorporate that into the WebUI, but maybe a notice somewhere to re-enforce the "open" nature of the directory if the default is retained.</div>
<div><br></div><div>Steve</div></div></div></div>