Steven Jones wrote:
Hi,
I want to have 2 trees of user (and, or? host?) groups, one server branch and
one desktop as the desktop admins differ from the server admins and have to be
kept separate..so that seems to be a high level thing
So reading the delegation section its unclear if I am in the right place or what
permission to giveso for a top level admin I give the manager attribute? to the top
group or simply all? or what? looking down the attributes I see things like
cn so I see nothing that helps me understand.yep Im lost.
What I need to do is give the desktop admins control over desktops and desktop
users but not any over servers and server users and the the server admins the
opposite.
There are also going to be at least two password policies, one for staff and
one for students. After a bit I will have passync from AD for staff so that
policy needs to be disabled...also the requirement to reset their password on
first login as that's done via AD
So is the best way to make a top level group for each of the two trees,
delegate this to each admin branch (manager?) to that? and then under that have
two groups where I attach each of the password policies? seems logical, but
who knows
Say a group labeled 1 is the top for the server tree with 2 under it for staff
server passwords and 3 for student server passwords.
Say a group labeled A is the top for the desktop tree with B under it for
staff server passwords and C for student server passwords...
hope my asci art works
2
1
3
b
a
c
So a staff password policy is attached to 2 and B and a student password policy
is attached to 3 and C?
:/
Is this clear?
The next Q is doing the nesting, I get confused on which way it goes1
goes into group 2 and 3 while a goes into b and c?
That way 1 has control over 2 and 3? which is what I want
or do 2 and 3 go into 1? cant see taht as 2 and 3 would have the same level as
1?
I then have to repeat something similar for the hosts/clients?
IPA has a flat DIT, so all users are stored together, all groups, etc.
You cannot use the IPA tools to manage users stored elsewhere in the tree.
You can grant permissions via groups and hostgroups, I think that will
do what you need.
You'll need to craft a series of permissions granting access to modify
attributes of members of a group. Then create privileges and roles and
assign membership as necessary.
So for example you create a couple of groups: DesktopAdmins and
DesktopUsers.
Assign users as appropriate. It is ok for users to be members of both.
Here is how it might look. I'm just creating a permission to modify a
few attributes of a class of users but it should point you in the right
direction.
Create our groups
$ ipa group-add desktopusers --desc='Desktop users'
$ ipa group-add desktopadmins --desc='Desktop admins'
Create a permission to write some user attributes
$ ipa permission-add 'Manage desktop users' --memberof=desktopusers
--attrs='givenname,sn,telephonenumber' --type=user --permissions=write
Create some sample users (yes, one extra user)
$ echo password | ipa user-add --first=tim --last=user duser1 --password
$ echo password | ipa user-add --first=tim --last=user dadmin1 --password
$ echo password | ipa user-add --first=tim --last=user tuser1 --password
Assign members to groups
$ ipa group-add-member --users=duser1 desktopusers
$ ipa group-add-member --users=dadmin1 desktopadmins
Create privilege and role
$ ipa privilege-add 'Desktop admins' --desc='Desktop admins'
$ ipa role-add 'Desktop admins' --desc='Desktop admins'
$ ipa privilege-add-permission --permissions='Manage desktop users'
'Desktop admins'
$ ipa role-add-privilege --privileges='Desktop admins' 'Desktop admins'
Now become a desktop admin and test
$ kinit dadmin1
$ ipa user-mod --first=Gary duser1
--
Modified user duser1
--
User login: duser1
First name: Gary
Last name: user
Home directory: /home/duser1
Login shell: /bin/sh
UID: 64384
GID: 64384
Account disabled: False
Password: True
Member of groups: ipausers, desktopusers
Kerberos keys available: True
$ ipa user-mod --first=Gary tuser1
ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the
'givenName' attribute of entry
'uid=tuser1,cn=users,cn=accounts,dc=example,dc=com'.
You can see that it can manage the user we added to desktopusers but not
the other user.
Things you can't easily do are things like Create a desktop user. You
can't easily do this because the group membership is assigned later.
regards
rob
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
