<div><br></div>I agree it won't be a security feature nor you are doing wrong by not adding it. However, it might come as nice to have feature. Let me explain you my condition.<div><br></div><div>We host web application where lot of DNS entries (Public and Internal) are created for different kind of requests and features. Now we already have a separate DNS server, Separate Manual Linux User/Access Control management by puppet. Linux users   ACL have no relationship with the web application user (which is internal to the web app). </div>


<div><br></div><div>So FreeIPA can help me to centralize the Linux user-management as well as (Public and Internal) DNS. However, the problem is : traditionally the access levels were different for DNS users (support guys) and user management (sysadmins). Now bring both system together even the Host based access control, sudoers rule everything becomes visible to non-sysadmin group.</div>

<div><br></div><div>You are right that every user could query all entries from command line and hence it won't help  to secure the system, but not having it on GUI may help to avoid "obvious" visibility of the whole directory.</div>


<div><br></div><div>I believe similar GUI "views" could be applied for discussion </div><div><br></div><div><a href="http://osdir.com/ml/freeipa-users/2013-03/msg00218.html">http://osdir.com/ml/freeipa-users/2013-03/msg00218.html</a></div>
<div><br></div><div>where geographically separate Organization units may share the same directory with limited visibility on other branches.</div><div><br></div><div><br></div><div>Having said that, I am not sure how feasible/logical my view is owing to my limited knowledge in 389 directory server and IPA.</div>
<div><br></div><div>Thanks</div><div>Chandan</div><div><br></div><div><div><br>On Monday, April 15, 2013, Dmitri Pal  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    On 04/15/2013 11:11 AM, Chandan Kumar wrote:
    <blockquote type="cite">
      <div><br>
      </div>
      <div>I think controlling Visibility of tabs would be the best
        option, if possible, based on Roles as mentioned by Rob. As long
        as other entries are not visible in UI, even though they have
        read only access with command line, should be enough.</div>
      <br>
    </blockquote>
    <br>
    It would not be a security feature though. Just a convenience
    because the same admin would be able to bind directly to ldap and
    run a search. This is why we did not go this route. Yes we can hide
    panels but it would not mean that the user can't easily get that
    info. So is there really a value in hiding? So far we did not see
    any this is why we did not do it, but may be you have some arguments
    that might convince us that we are wrong. Can you please share these
    arguments with us?  <br>
    <br>
    <blockquote type="cite"><br>
      On Monday, April 15, 2013, Alexander Bokovoy wrote:<br>
      <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, 15 Apr
        2013, Petr Spacek wrote:<br>
        <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
          On 15.4.2013 15:39, Rob Crittenden wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
            There is no easy way to do this. We start with granting all
            authenticated<br>
            users read access to the tree with the exception of certain
            attributes (like<br>
            passwords).<br>
            <br>
            You'd have to start by removing that, then one by one
            granting read access to<br>
            the various containers based on, well, something.<br>
          </blockquote>
          <br>
          Would it be possible to create a new role to allow current
          'read-all access' and add this role to all users by default?<br>
          <br>
          It could be much simpler to change the behaviour with this
          role, or not? :-)<br>
        </blockquote>
        It would affect service accounts (include host/fqdn@REALM) since
        roles<br>
        cannot be applied to them, if I remember correctly. We would
        need to<br>
        make an exclusive ACI that allows all services to gain read only
        access...<br>
        <br>
        -- <br>
        / Alexander Bokovoy<br>
        <br>
        _______________________________________________<br>
        Freeipa-users mailing list<br>
        <a>Freeipa-users@redhat.com</a><br>
        <a href="https://www.redhat.com/mailman/listinfo/freeipa-users" target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a><br>
      </blockquote>
      <br>
      <br>
      -- <br>
      <br>
      <div>--</div>
      <div><a href="http://about.me/chandank" target="_blank">http://about.me/chandank</a><br>
      </div>
      <br>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
Freeipa-users mailing list
<a>Freeipa-users@redhat.com</a>
<a href="https://www.redhat.com/mailman/listinfo/freeipa-users" target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a></pre>
    </blockquote>
    <br>
    <br>
    <pre cols="72">-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
<a href="http://www.redhat.com/carveoutcosts/" target="_blank">www.redhat.com/carveoutcosts/</a>


</pre>
  </div>

</blockquote></div></div>
<br><br>-- <br><br><div>--</div><div><a href="http://about.me/chandank" target="_blank">http://about.me/chandank</a><br></div><br>