USERS
By default, PowerVC uses the local operating system to manage users and groups. To avoid exposing all of the system's users and groups, filtering is implemented. Only users and groups which match the corresponding filter will be exposed in PowerVC.
On a new installation, a new group named "powervc-filter" is created, the default user (root) is added to that group, and the filters are configured so that only the powervc-filter group and its members are visible to PowerVC. When a user is visible in PowerVC, this user is visible independently of a project. But when a role is assigned to a user it is important in which project this happens. Switch projects when you want to assign a role in antother project. If a role is assigned in 2 projects then the user can switch between projects.
PowerVC backups include the user and group filters. However, they do not create users or groups, or adjust group memberships. If operating system users and groups are configured differently when the backup is restored, this might lead to issues. For example, if the system on which the restore is being performed does not have the same users in the powervc-filter group, different users will be seen in PowerVC. Some role assignments might no longer work because the user or group to which they were granted does not exist or is not visible based on the user and group filters.
Checking the current filters (for groups and users) and authentication type (os or ldap)
[root@powervc ~]# powervc-config identity repository
Type: os
User filter: (memberOf=powervc-filter)
Group filter: (name=powervc-filter)
With these default filters, only the OS users that are members of the group ‘powervc-filter’ are visible to PowerVC. Similarly, the only group that is visible in PowerVC is the one named ‘powervc-filter’
(In earlier versions of powervc this filtering mechanism was missing for OS user it worked only for LDAP)
Create a filter so that PowerVC can see all of the users that are members of the groups power1, power2, and can also see any groups that are named power1, power2:
# powervc-config identity repository -t os --user-filter "(|(memberOf=power1)(memberOf=power2))" --group-filter "(|(name=power1)(name=power2))"
------------------------------------------
Roles:
Roles are used to specify what actions a user can perform. Roles are assigned to a user (or group, in which case they are inherited by all users in that group). A user or group can have more than one role, in which case they are able to perform any action that at least one of their roles allows.
admin: It can do all tasks and access all resources. Only adminis on the ibm-default project can list, create, and delete projects.
deployer: Deploying a virtual machine from an image, Viewing all resources except users and groups
image_manager: Capturing, importing, or deleting an image, Editing description of an image, Viewing all resources except users and groups
storage_manager: Creating, deleting, or resizing a volume, Viewing all resources except users and groups
viewer: can view resources and the properties of resources, but can perform no tasks. They cannot view users and groups.
vm_user: Starting, stopping, or restarting a virtual machine, Viewing all resources except users and groups
vm_manager: Deploying a virtual machine from an image, Deleting, resizing, starting, stopping, or restarting a virtual machine, Attaching or detaching volume/network interface, Editing details of a deployed virtual machine, Viewing all resources except users and groups, Creating, attaching, detaching, and deleting floating IP addresses
Some tips:
If a user needs to write automation to deploy virtual machines, but does not need to perform any other tasks, assign that user deployer.
If a user needs to deploy and manage their own virtual machines , but does not need to work with images, storage, or infrastructure tasks, such as registering hosts, assign that user vm_manager.
If a user needs to deploy and manage VMs but also needs to capture and manage images, assign the user both vm_manager and image_manager.
If a user needs to work with storage volumes and nothing else, assign that user storage_manager.
If a user needs to manage virtual machines that others have created, assign that user vm_manager.
------------------------------------------
Self-service user roles- policies:
Self-service users are limited to only using deploy templates for images that are assigned to their project.
For example, we can specify how many virtual machines a self-service user can create before needing administrator approval. After reaching that point, if a user tries to create a virtual machine a request is generated (an email sent to the administrator by PowerVC). If an administrator approves the request, the virtual machine is then created.
A self-service user will create virtual machines by using deploy templates. These have been set up by the administrator. Deploy templates are tied to one project, but multiple deploy templates that use different settings can be created from the same image.
The self-service role is exclusive to a project. That is, if you have the self-service role in a project, you cannot have other roles in that project. However, you can have the same or different roles in other projects.
The following policies can be set for a self-service user:
- Default expiration date for all VMs created by self-service users in this project.
- How many VM expiration extension requests are automatically approved. After reaching the limit administrator approval is needed.
- How long a VM expiration extension request waits before being auto-approved.
- How long to keep an expired VM before it is deleted.
- How many deploys a self-service user can perform without requiring administrator approval.
- How many times a self-service user can capture an image (or take a snapshot) without requiring administrator approval.
------------------------------------------
Adding users and role
Creating a user in PowerVC and adding a role to that user:
1. # useradd powervc <--create user on linux
2. # passwd powervc <--add a password for that user
3. # usermod -a -G powervc-filter powervc <--add user to the group (easiest way to make a user visible to PowerVC)
(after this user can be seen in powervc GUI and also in openstack commands)
4. # openstack role add --project ibm-default --user powervc admin <--adding admin role to the user
(this can be done in the GUI, which is more preferrable)
if needed:
chfn powervc -f "Admin user for deploy project" <--changing GECOs for a user
gpasswd -d powervc powervc-filter <--remove user from a group (or edit /etc/group))
------------------------------------------
POWERVC and LDAP
It is possible to use PowerVC with LDAP, either using secure or insecure connection. During the configuration, there are parameters which will need to be checked/answered by an LDAP admin. (ldap server, attributes ...)
powervc-config identity repository -t ldap ... command uses these options:
--ldap-user (the user which is connected to LDAP and does the query for authentication, full path is used with CN, OU, DC ...)
--ldap-url (url to the ldap server, we can use ldaps or ldap protocol)
--insecure or --tls-cacertificate (insecure or secure connections, for secure connection path to tls certificate file is needed)
--chase-referral (it is similar to following links, IBM recommendation was to set it on False)
-u (LDAP user name which will be the admin user in PowerVC, this user can give roles to other users in PowerVC UI)
powervc-config example for insecure connection:
# powervc-config identity repository -t ldap --ldap-user CN=LDAP_myuser,OU=Functional,OU=Accounts,DC=mydomain,DC=org --ldap-url ldap://ldap.mydomain.org --insecure --chase-referral False -u "bill.will"
powervc-config example for secure connection:
# powervc-config identity repository -t ldap --ldap-user CN=LDAP_myuser,OU=Functional,OU=Accounts,DC=mydomain,DC=org --ldap-url ldaps://ldap.mydomain.org --tls-cacertfile /etc/ssl/certs/ca-bundle.crt --chase-referrals False -u "bill.will"
LDAP user/group information will be stored in PowerVC database.
Do you want to proceed? [y/n] y
Configuring PowerVC for LDAP.
Password:
…
…
It will ask for LDAP_myuser password, then user and group filters needs to be filled in.
# powervc-config identity repository
Type: ldap
URL: ldaps://ldap.mydomain.org
CA certificate file: /etc/ssl/certs/ca-bundle.crt
Anonymous bind: n
User name: CN=LDAP_Hmc,OU=Functional,OU=Accounts,DC=mydomain,DC=org
User tree DN: DC=mydomain,DC=org
User filter: (|(sAMAccountName=power*)(memberOf=CN=AT_Devs,OU=Groups,DC=mydomain,DC=org)(memberOf=CN=PL_Devs,OU=Lab,DC=mydomain,DC=org))
User object class: person
User ID attribute: CN
User name attribute: sAMAccountName
User mail attribute: mail
User description attribute: description
Group tree DN: DC=mydomain,DC=org
Group filter: (|(CN=AT_Devs)(CN=PL_Devs))
Group object class: group
Group ID attribute: sAMAccountName
Group name attribute: sAMAccountName
Group member attribute: member
Group description attribute: description
Query scope: sub
Chase referrals: y
User and Group lines control what is displayed under the Users and Groups tabs in PowerVC UI. In our example:
-users: those will be listed whose name starts with power and memers of of AT_Devs and PL_Devs groups.
-groups: these 2 group names will be listed in PowerVC UI: AT_Devs and PL_Devs.
(So in PowerVC we can choose individual users or a group and give them roles, authorizations etc...)
quiet mode:
If we want to change 1 parameter only (for example the user filter) we can use the quiet, all the other parameters won't be touched, they will remain the same:
# powervc-config identity repository --type ldap --quiet --user-filter "(|(sAMAccountName=powervc_api)(sAMAccountName=bill.will)(sAMAccountName=joe.doe))"
ldapsearch:
ldapsearch can be used to check out if our planned filter woud give a good result.
$ ldapsearch -D "LDAP_myuser" -w 'password1234' -h ldap.mydomain.org -b "dc=mydomain,dc=org" "(cn=Joe Doe)" <--searches for user Joe Doe, using given pw
$ ldapsearch -LLL -W -D "LDAP_myuser" -h ldap.mydomain.org -b "dc=mydomain,dc=org" "(cn=Joe Doe)" <--same jus pw will be asked
$ ldapsearch -LLL -W -D "LDAP_myuser" -H ldap://ldap.mydomain.org -b "dc=mydomain,dc=org" "(cn=Joe Doe)" <--same as well
…"(cn=Joe Doe)" -v sn cn mail samaccountname userprincipalname <--showing only specified parameters
… (cn=AT_Engineers) <-- searching for a group
… (|(sAMAccountName=powervc_adm)(sAMAccountName=powervc_api)) <--searching for 2 users, | means OR statement, & would mean AND
This is the equivalent ldapsearch for the above configuration:
$ ldapsearch -LLL -W -D "MYDOMAIN\LDAP_myuser" -h ldap.mydomain.org -b "dc=mydomain,dc=org" "(|(sAMAccountName=power*)(memberOf=CN=AT_Devs,OU=Groups,DC=mydomain,DC=org)(memberOf=CN=PL_Devs,OU=Lab,DC=mydomain,DC=org))"
searching for member in a nested group (there is this long number which means following the chain of groups until members are found):
$ ldapsearch -LLL -D "LDAP_myuser" -w 'password1234' -h ldap.mydomain.org -b "dc=mydomain,dc=org" "(memberof:1.2.840.113556.1.4.1941:=cn=WW_CloudDevelopment_U,OU=DevApps,OU=Lab,DC=mydomain,DC=org)"
------------------------------------------
Some additional details regarding LDAP config
IBM documents:
https://ibm.ent.box.com/s/hpgonkzhvhqgkf15uiownebwh840khy5
https://www.ibm.com/support/knowledgecenter/en/SSXK2N_1.4.4/com.ibm.powervc.standard.help.doc/powervc_ldap_hmc.html
LDAP config example:
Found this: Here is an example of PowerVC LDAP config using our AD Environment this is a windows server 2012 R2 Domain:
user_objectclass = person
user_id_attribute = sAMAccountName
user_name_attribute = sAMAccountName
user_mail_attribute = mail
user_description_attribute = description
group_tree_dn = CN=Users,DC=TestDomain,DC=ibm,DC=com
group_objectclass = group
group_id_attribute = sAMAccountName
group_name_attribute = cn
group_member_attribute = member
group_desc_attribute = description
query_scope = one
use_tls = False
chase_referrals = True
Comments from IBM when LDAP configuration failed:
# powervc-config identity repository -t ldap -u "John Doe" --ldap-url ldap://ldap.mycompany.org --insecure
(IBM recommendded to use --chase-referral False for AD)
Configuring PowerVC for LDAP.
Anonymous bind [n]:
User name [dc=Manager,dc=example,dc=com]: CN=ldap_user,OU=Functional,OU=Accounts,DC=mycompany,DC=org
Password: ******
User tree DN [ou=Users,dc=example,dc=com]: OU=EU,OU=Primary,OU=Accounts,DC=mycompany,DC=org <--looks correct, aligns with ldapsearch dn
User filter [None]: (|(uid=John Doe)) <--please remove this and try; this looks incorrect
User object class [inetOrgPerson]: <--check if the objectclass corresponding to their user is inetOrgPerson or not.
It completely depends on how LDAP user has been configured.
User ID attribute [uid]: <--check if the unique identifier for LDAP user is the uid attribute or something else.
It completely depends on how LDAP user has been configured.
User name attribute [cn]: <--This should be the LDAP attribute that is associated with the user name.
From the ldapsearch results, it looks like this is correct.
User mail attribute [email]:
User description attribute [description]:
Group tree DN [ou=Groups,dc=example,dc=com]: <--This is the group tree under which the users are present.
No value enterd here, so the default value is taken, which is clearly incorrect.
Group filter [None]:
Group object class [groupOfNames]: <--they have to check and input the objectclass used to define their LDAP group
Group ID attribute [cn]: <--same comment as previous (check the LDAP attribute that uniquely identifies their group)
Group name attribute [cn]: <--check if the cn attribute is set against their LDAP group to represent the name
Group member attribute [member]: <--Ensure if this value defines the members of a group
Group description attribute [description]:
Query scope [one]: <--if their users/groups are under multiple hierarchies, recommend changing this to sub
Error: User 'John Doe' was not found
Error: There must be at least one admin user. Check user and group inputs.
------------------------------------------
No comments:
Post a Comment