Re: [Freeipa-users] User Roles and access in GUI

2013-04-16 Thread Martin Kosek
On 04/16/2013 03:16 AM, Dmitri Pal wrote:
 On 04/15/2013 07:42 PM, Chandan Kumar wrote:

 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.

 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). 

 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.

 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.

 I believe similar GUI views could be applied for discussion 

 http://osdir.com/ml/freeipa-users/2013-03/msg00218.html

 where geographically separate Organization units may share the same directory
 with limited visibility on other branches.


 Having said that, I am not sure how feasible/logical my view is owing to my
 limited knowledge in 389 directory server and IPA.
 
 I think you are talking about this: 
 https://fedorahosted.org/freeipa/ticket/217
 and somewhat about this https://fedorahosted.org/freeipa/ticket/1313
 
 Would you mind adding the details of your use case to one of those two 
 tickets?
 
 Alternatively we can start another ticket.
 However I think we should have some kind of a complete solution that covers
 LDAP, UI and CLI consistently.
 Doing it right would be a huge task IMO.
 For LDAP we would probably have to implement some kind of smart proxy that
 would reply only to the requests that user are entitled to. Same with CLI and
 UI. But the point is that one configuration should be respected by all three 
 at
 the same time. For example if you are not allowed to manage sudo the sudo
 commands should not return any data as well as LDAP searches and there should
 be no panel in the UI.
 
 I am really reluctant to fix just UI because we would end up different
 components of the system behaving differently and it would be hard to evolve
 them and maintain.
 
 Thanks
 Dmitri
 

I think there were some related discussions about this. I agree that this a
bigger effort, but I do think that a proxy is needed. We should be able to
achieve that goal by being able to disable global ACI allowing read access to
all entries and attributes unless those explicitly blacklisted.

I think we are talking about this ticket:
https://fedorahosted.org/freeipa/ticket/2786

If there is a solid use case for this ticket (and it seems it is), we can
increase its priority. In order to be able to manage such access also for
system accounts (like sudo for example when SSSD is not used), we may want to
also add API to manage such accounts and control their access too:

https://fedorahosted.org/freeipa/ticket/2801

Martin

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


Re: [Freeipa-users] User Roles and access in GUI

2013-04-16 Thread Petr Vobornik

On 04/16/2013 01:14 AM, Stephen Ingram wrote:

On Mon, Apr 15, 2013 at 3:13 PM, Dmitri Pal d...@redhat.com wrote:


  On 04/15/2013 11:11 AM, Chandan Kumar wrote:


  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.


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?



I wasn't involved in this thread before now, however, in our case we do not
allow LDAP access (only Kerberos and WebUI) from outside firewall so there
*could* be a distinction between the two. I could also present that some
users have been confused when they login to change their personal
information and see a huge list of other users. Of course, they are
directed to their information first upon login, however, we all know that
one wrong click can always happen with some users.


We might hide menu and breadcrumb navigation in self-service. Would that 
help? Another possible problem is direct modification of url and thus 
showing details of another user.




Perhaps it's better to just put together a new WebUI using the Python API,
however, with the fantastic new password reset page in 3.x, I've become
lazy and let users access IPA directly.

Steve



--
Petr Vobornik

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


Re: [Freeipa-users] User Roles and access in GUI

2013-04-16 Thread Dmitri Pal
On 04/16/2013 03:38 AM, Martin Kosek wrote:
 On 04/16/2013 03:16 AM, Dmitri Pal wrote:
 On 04/15/2013 07:42 PM, Chandan Kumar wrote:
 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.

 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). 

 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.

 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.

 I believe similar GUI views could be applied for discussion 

 http://osdir.com/ml/freeipa-users/2013-03/msg00218.html

 where geographically separate Organization units may share the same 
 directory
 with limited visibility on other branches.


 Having said that, I am not sure how feasible/logical my view is owing to my
 limited knowledge in 389 directory server and IPA.
 I think you are talking about this: 
 https://fedorahosted.org/freeipa/ticket/217
 and somewhat about this https://fedorahosted.org/freeipa/ticket/1313

 Would you mind adding the details of your use case to one of those two 
 tickets?

 Alternatively we can start another ticket.
 However I think we should have some kind of a complete solution that covers
 LDAP, UI and CLI consistently.
 Doing it right would be a huge task IMO.
 For LDAP we would probably have to implement some kind of smart proxy that
 would reply only to the requests that user are entitled to. Same with CLI and
 UI. But the point is that one configuration should be respected by all three 
 at
 the same time. For example if you are not allowed to manage sudo the sudo
 commands should not return any data as well as LDAP searches and there should
 be no panel in the UI.

 I am really reluctant to fix just UI because we would end up different
 components of the system behaving differently and it would be hard to evolve
 them and maintain.

 Thanks
 Dmitri

 I think there were some related discussions about this. I agree that this a
 bigger effort, but I do think that a proxy is needed. We should be able to
 achieve that goal by being able to disable global ACI allowing read access to
 all entries and attributes unless those explicitly blacklisted.

 I think we are talking about this ticket:
 https://fedorahosted.org/freeipa/ticket/2786


Actually no. I see it on a much broader scale than in this ticket.
I am thinking about blacklisting components like: sudo, hbac, selinux,
DNS, hosts, users, services etc.
Have a way to completely hide those areas from the user.
It would get pretty complex right away as the dependencies are hierarchical.





 If there is a solid use case for this ticket (and it seems it is), we can
 increase its priority. In order to be able to manage such access also for
 system accounts (like sudo for example when SSSD is not used), we may want to
 also add API to manage such accounts and control their access too:

 https://fedorahosted.org/freeipa/ticket/2801


And I do not think it is about system accounts. It is about different
flavors of the admin accounts.
It is another dimension of the access control - ability to scope the
actual data that gets exposed to someone.


 Martin


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


Re: [Freeipa-users] User Roles and access in GUI

2013-04-16 Thread Martin Kosek
On 04/16/2013 04:25 PM, Dmitri Pal wrote:
 On 04/16/2013 03:38 AM, Martin Kosek wrote:
 On 04/16/2013 03:16 AM, Dmitri Pal wrote:
 On 04/15/2013 07:42 PM, Chandan Kumar wrote:
 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.

 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). 

 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.

 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.

 I believe similar GUI views could be applied for discussion 

 http://osdir.com/ml/freeipa-users/2013-03/msg00218.html

 where geographically separate Organization units may share the same 
 directory
 with limited visibility on other branches.


 Having said that, I am not sure how feasible/logical my view is owing to my
 limited knowledge in 389 directory server and IPA.
 I think you are talking about this: 
 https://fedorahosted.org/freeipa/ticket/217
 and somewhat about this https://fedorahosted.org/freeipa/ticket/1313

 Would you mind adding the details of your use case to one of those two 
 tickets?

 Alternatively we can start another ticket.
 However I think we should have some kind of a complete solution that covers
 LDAP, UI and CLI consistently.
 Doing it right would be a huge task IMO.
 For LDAP we would probably have to implement some kind of smart proxy that
 would reply only to the requests that user are entitled to. Same with CLI 
 and
 UI. But the point is that one configuration should be respected by all 
 three at
 the same time. For example if you are not allowed to manage sudo the sudo
 commands should not return any data as well as LDAP searches and there 
 should
 be no panel in the UI.

 I am really reluctant to fix just UI because we would end up different
 components of the system behaving differently and it would be hard to evolve
 them and maintain.

 Thanks
 Dmitri

 I think there were some related discussions about this. I agree that this a
 bigger effort, but I do think that a proxy is needed. We should be able to
 achieve that goal by being able to disable global ACI allowing read access to
 all entries and attributes unless those explicitly blacklisted.

 I think we are talking about this ticket:
 https://fedorahosted.org/freeipa/ticket/2786
 
 
 Actually no. I see it on a much broader scale than in this ticket.
 I am thinking about blacklisting components like: sudo, hbac, selinux,
 DNS, hosts, users, services etc.
 Have a way to completely hide those areas from the user.
 It would get pretty complex right away as the dependencies are hierarchical.

This is what I meant. We could offer disabling the global ACI granting read
access to everyone and let admins assign read privileges only to functions
(HBAC, SUDO, SELinux, ...) they want. I tried to sum all these thoughts to this
upstream ticket:

https://fedorahosted.org/freeipa/ticket/3566

Comments and suggestions from FreeIPA users welcome!

Thanks,
Martin

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


Re: [Freeipa-users] User Roles and access in GUI

2013-04-15 Thread Dmitri Pal
On 04/12/2013 08:17 PM, Chandan Kumar wrote:

 Thanks for the response.

 The way we can turn off the anonymous bind in 389 Server. using
  nsslapd-allow-anonymous-access: off.

 Is there any way to limit the read access of user to only to the DNS
 entries? In that way I can create a user who could/will be able to
 see/edit DNS entries only.

In general yes though it is not standard because as I mentioned earlier
the tree is assumed to be readable to an authenticated user.
When user logs in the framework the UI or CLI will log into LDAP as a
user and try to do operations. It will need to read user entry and
groups and other things so closing read access to everything other than
DNS would not work. You can close access to some of the objects but not
to all of them.
It still unclear what is the harm in ability to read other parts of the
tree but not modify them.

To change the permissions you would have to user LDAP level ACI commands
as we do not expose these capabilities via CLI or UI but be careful as I
mentioned above you might end up hiding something that would prevent
framework from functioning properly.


 Thanks,
 Chandan

 On Friday, April 12, 2013, Dmitri Pal wrote:

 On 04/12/2013 02:23 AM, Martin Kosek wrote:
  On 04/12/2013 01:07 AM, Chandan Kumar wrote:
  Hello,
 
  I have a question regarding Uer Roles and Access in GUI. What I
 have found that
  irrespective of Role assigned to a user, he gets read only
 access across the
  directory.
 
  For example, I created one user say dnsadmin with only Roles
 related to DNS
  such as DNS Servers, DNS Administrator. Now that user has read
 only access to
  entire directory. Is there any way of controlling it?
 
 
  Thanks,
  Chandan
 
  Hello Chandan,
 
  If you create a new role, assign DNS Administrators privilege
 to it, and
  assign that role to user dnsadmin, that user will have write
 access to DNS tree
  and configuration.
 
  Beyond that tree, dnsadmin will have read-only access just like
 all other
  non-admin users. If you want dnsadmin to have write access also
 to other
  entries, you would need to assign more privileges/roles to it.
 
  HTH,
  Martin
 
  ___
  Freeipa-users mailing list
  Freeipa-users@redhat.com javascript:;
  https://www.redhat.com/mailman/listinfo/freeipa-users


 If you are worried about the read access the LDAP data is
 traditionally
 readable by any authenticated user.
 In the past is was even possible to read the tree as anonymous user
 which is a bad security practice and not recommended.


 --
 Thank you,
 Dmitri Pal

 Sr. Engineering Manager for IdM portfolio
 Red Hat Inc.


 ---
 Looking to carve out IT costs?
 www.redhat.com/carveoutcosts/ http://www.redhat.com/carveoutcosts/



 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com javascript:;
 https://www.redhat.com/mailman/listinfo/freeipa-users



 -- 

 --
 http://about.me/chandank



-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] User Roles and access in GUI

2013-04-15 Thread Rob Crittenden

Dmitri Pal wrote:

On 04/12/2013 08:17 PM, Chandan Kumar wrote:


Thanks for the response.

The way we can turn off the anonymous bind in 389 Server. using
 nsslapd-allow-anonymous-access: off.

Is there any way to limit the read access of user to only to the DNS
entries? In that way I can create a user who could/will be able to
see/edit DNS entries only.


In general yes though it is not standard because as I mentioned earlier
the tree is assumed to be readable to an authenticated user.
When user logs in the framework the UI or CLI will log into LDAP as a
user and try to do operations. It will need to read user entry and
groups and other things so closing read access to everything other than
DNS would not work. You can close access to some of the objects but not
to all of them.
It still unclear what is the harm in ability to read other parts of the
tree but not modify them.

To change the permissions you would have to user LDAP level ACI commands
as we do not expose these capabilities via CLI or UI but be careful as I
mentioned above you might end up hiding something that would prevent
framework from functioning properly.


There is no easy way to do this. We start with granting all 
authenticated users read access to the tree with the exception of 
certain attributes (like passwords).


You'd have to start by removing that, then one by one granting read 
access to the various containers based on, well, something.


It would be very prone to error, with probably lots of corner cases and 
overlap.


Do you really want to deny read access or do you want to simplify the 
the UI to include only certain tabs/functions?


rob

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


Re: [Freeipa-users] User Roles and access in GUI

2013-04-15 Thread Petr Spacek

On 15.4.2013 15:39, Rob Crittenden wrote:

There is no easy way to do this. We start with granting all authenticated
users read access to the tree with the exception of certain attributes (like
passwords).

You'd have to start by removing that, then one by one granting read access to
the various containers based on, well, something.


Would it be possible to create a new role to allow current 'read-all access' 
and add this role to all users by default?


It could be much simpler to change the behaviour with this role, or not? :-)

--
Petr Spacek

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


Re: [Freeipa-users] User Roles and access in GUI

2013-04-15 Thread Alexander Bokovoy

On Mon, 15 Apr 2013, Petr Spacek wrote:

On 15.4.2013 15:39, Rob Crittenden wrote:

There is no easy way to do this. We start with granting all authenticated
users read access to the tree with the exception of certain attributes (like
passwords).

You'd have to start by removing that, then one by one granting read access to
the various containers based on, well, something.


Would it be possible to create a new role to allow current 'read-all 
access' and add this role to all users by default?


It could be much simpler to change the behaviour with this role, or not? :-)

It would affect service accounts (include host/fqdn@REALM) since roles
cannot be applied to them, if I remember correctly. We would need to
make an exclusive ACI that allows all services to gain read only access...

--
/ Alexander Bokovoy

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


Re: [Freeipa-users] User Roles and access in GUI

2013-04-15 Thread Dmitri Pal
On 04/15/2013 11:11 AM, Chandan Kumar wrote:

 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.


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? 


 On Monday, April 15, 2013, Alexander Bokovoy wrote:

 On Mon, 15 Apr 2013, Petr Spacek wrote:

 On 15.4.2013 15:39, Rob Crittenden wrote:

 There is no easy way to do this. We start with granting
 all authenticated
 users read access to the tree with the exception of
 certain attributes (like
 passwords).

 You'd have to start by removing that, then one by one
 granting read access to
 the various containers based on, well, something.


 Would it be possible to create a new role to allow current
 'read-all access' and add this role to all users by default?

 It could be much simpler to change the behaviour with this
 role, or not? :-)

 It would affect service accounts (include host/fqdn@REALM) since roles
 cannot be applied to them, if I remember correctly. We would need to
 make an exclusive ACI that allows all services to gain read only
 access...

 -- 
 / Alexander Bokovoy

 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-users



 -- 

 --
 http://about.me/chandank



 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-users


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] User Roles and access in GUI

2013-04-15 Thread Stephen Ingram
On Mon, Apr 15, 2013 at 3:13 PM, Dmitri Pal d...@redhat.com wrote:

  On 04/15/2013 11:11 AM, Chandan Kumar wrote:


  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.


 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?


I wasn't involved in this thread before now, however, in our case we do not
allow LDAP access (only Kerberos and WebUI) from outside firewall so there
*could* be a distinction between the two. I could also present that some
users have been confused when they login to change their personal
information and see a huge list of other users. Of course, they are
directed to their information first upon login, however, we all know that
one wrong click can always happen with some users.

Perhaps it's better to just put together a new WebUI using the Python API,
however, with the fantastic new password reset page in 3.x, I've become
lazy and let users access IPA directly.

Steve
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] User Roles and access in GUI

2013-04-15 Thread Dmitri Pal
On 04/15/2013 07:42 PM, Chandan Kumar wrote:

 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.

 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). 

 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.

 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.

 I believe similar GUI views could be applied for discussion 

 http://osdir.com/ml/freeipa-users/2013-03/msg00218.html

 where geographically separate Organization units may share the same
 directory with limited visibility on other branches.


 Having said that, I am not sure how feasible/logical my view is owing
 to my limited knowledge in 389 directory server and IPA.

I think you are talking about this:
https://fedorahosted.org/freeipa/ticket/217
and somewhat about this https://fedorahosted.org/freeipa/ticket/1313

Would you mind adding the details of your use case to one of those two
tickets?

Alternatively we can start another ticket.
However I think we should have some kind of a complete solution that
covers LDAP, UI and CLI consistently.
Doing it right would be a huge task IMO.
For LDAP we would probably have to implement some kind of smart proxy
that would reply only to the requests that user are entitled to. Same
with CLI and UI. But the point is that one configuration should be
respected by all three at the same time. For example if you are not
allowed to manage sudo the sudo commands should not return any data as
well as LDAP searches and there should be no panel in the UI.

I am really reluctant to fix just UI because we would end up different
components of the system behaving differently and it would be hard to
evolve them and maintain.

Thanks
Dmitri


 Thanks
 Chandan


 On Monday, April 15, 2013, Dmitri Pal wrote:

 On 04/15/2013 11:11 AM, Chandan Kumar wrote:

 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.


 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? 


 On Monday, April 15, 2013, Alexander Bokovoy wrote:

 On Mon, 15 Apr 2013, Petr Spacek wrote:

 On 15.4.2013 15:39, Rob Crittenden wrote:

 There is no easy way to do this. We start with
 granting all authenticated
 users read access to the tree with the exception of
 certain attributes (like
 passwords).

 You'd have to start by removing that, then one by one
 granting read access to
 the various containers based on, well, something.


 Would it be possible to create a new role to allow
 current 'read-all access' and add this role to all users
 by default?

 It could be much simpler to change the behaviour with
 this role, or not? :-)

 It would affect service accounts (include host/fqdn@REALM)
 since roles
 cannot be applied to them, if I remember correctly. We would
 need to
 make an exclusive ACI that allows all services to gain read
 only access...

 -- 
 / Alexander Bokovoy

 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-users



 -- 

 --
 http://about.me/chandank



 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com
 

Re: [Freeipa-users] User Roles and access in GUI

2013-04-12 Thread Martin Kosek
On 04/12/2013 01:07 AM, Chandan Kumar wrote:
 Hello,
 
 I have a question regarding Uer Roles and Access in GUI. What I have found 
 that
 irrespective of Role assigned to a user, he gets read only access across the
 directory. 
 
 For example, I created one user say dnsadmin with only Roles related to DNS
 such as DNS Servers, DNS Administrator. Now that user has read only access to
 entire directory. Is there any way of controlling it? 
 
 
 Thanks,
 Chandan
 

Hello Chandan,

If you create a new role, assign DNS Administrators privilege to it, and
assign that role to user dnsadmin, that user will have write access to DNS tree
and configuration.

Beyond that tree, dnsadmin will have read-only access just like all other
non-admin users. If you want dnsadmin to have write access also to other
entries, you would need to assign more privileges/roles to it.

HTH,
Martin

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


Re: [Freeipa-users] User Roles and access in GUI

2013-04-12 Thread Dmitri Pal
On 04/12/2013 02:23 AM, Martin Kosek wrote:
 On 04/12/2013 01:07 AM, Chandan Kumar wrote:
 Hello,

 I have a question regarding Uer Roles and Access in GUI. What I have found 
 that
 irrespective of Role assigned to a user, he gets read only access across the
 directory. 

 For example, I created one user say dnsadmin with only Roles related to DNS
 such as DNS Servers, DNS Administrator. Now that user has read only access to
 entire directory. Is there any way of controlling it? 


 Thanks,
 Chandan

 Hello Chandan,

 If you create a new role, assign DNS Administrators privilege to it, and
 assign that role to user dnsadmin, that user will have write access to DNS 
 tree
 and configuration.

 Beyond that tree, dnsadmin will have read-only access just like all other
 non-admin users. If you want dnsadmin to have write access also to other
 entries, you would need to assign more privileges/roles to it.

 HTH,
 Martin

 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-users


If you are worried about the read access the LDAP data is traditionally
readable by any authenticated user.
In the past is was even possible to read the tree as anonymous user
which is a bad security practice and not recommended.


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


Re: [Freeipa-users] User Roles and access in GUI

2013-04-12 Thread Chandan Kumar
Thanks for the response.

The way we can turn off the anonymous bind in 389 Server. using
 nsslapd-allow-anonymous-access: off.

Is there any way to limit the read access of user to only to the DNS
entries? In that way I can create a user who could/will be able to see/edit
DNS entries only.

Thanks,
Chandan

On Friday, April 12, 2013, Dmitri Pal wrote:

 On 04/12/2013 02:23 AM, Martin Kosek wrote:
  On 04/12/2013 01:07 AM, Chandan Kumar wrote:
  Hello,
 
  I have a question regarding Uer Roles and Access in GUI. What I have
 found that
  irrespective of Role assigned to a user, he gets read only access
 across the
  directory.
 
  For example, I created one user say dnsadmin with only Roles related
 to DNS
  such as DNS Servers, DNS Administrator. Now that user has read only
 access to
  entire directory. Is there any way of controlling it?
 
 
  Thanks,
  Chandan
 
  Hello Chandan,
 
  If you create a new role, assign DNS Administrators privilege to it,
 and
  assign that role to user dnsadmin, that user will have write access to
 DNS tree
  and configuration.
 
  Beyond that tree, dnsadmin will have read-only access just like all other
  non-admin users. If you want dnsadmin to have write access also to other
  entries, you would need to assign more privileges/roles to it.
 
  HTH,
  Martin
 
  ___
  Freeipa-users mailing list
  Freeipa-users@redhat.com javascript:;
  https://www.redhat.com/mailman/listinfo/freeipa-users


 If you are worried about the read access the LDAP data is traditionally
 readable by any authenticated user.
 In the past is was even possible to read the tree as anonymous user
 which is a bad security practice and not recommended.


 --
 Thank you,
 Dmitri Pal

 Sr. Engineering Manager for IdM portfolio
 Red Hat Inc.


 ---
 Looking to carve out IT costs?
 www.redhat.com/carveoutcosts/



 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com javascript:;
 https://www.redhat.com/mailman/listinfo/freeipa-users



-- 

--
http://about.me/chandank
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users