03-21-2016 11:41 AM
SAS 9.4 - Error writing metadata user does not have permission
We created a new user admin account and grant the account Manage - User Administration group. But when we tried to change the user role for an existing user using the newly created user admin account, we recd the following error
Error writing metadata: user does not have permission to perform this action.
can anybody advise?
03-21-2016 12:40 PM
I am not familiar with the group "Manage - User Administration". I don't have it. Is it a self defined one? check if said group is assigned role "Metadata Server: User Administration". Alternatively, use the group "SAS Administrators". That should set you up, perhaps too good.
Hope this helps,
03-21-2016 10:00 PM
Hi, thanks for the feedback. I already grant the role 'Metadata Server: User Administration" to the specific user and tried. but it still fails.
But if i assign SAS Adminstrator, then it works fine. But i want to assign only to manage user admin and not full admin rights. Possible?
03-24-2016 04:12 AM
What do you mean by "But if i assign SAS Adminstrator, then it works fine"? Do you mean when you log in as the "SAS Administrator" user (sasadm@saspw), an unrestricted administrator, or when you add the new user administrator as a member of the "SAS Adminstrators" group (which itself is usually a member of the "Metadata Server: User Administration" role, and gets granted additional permissions in key places via ACTs and ACEs).
Additionally, which user are you trying to get the new user administrator to modify? Restricted user administrators (members of the "Metadata Server: User Administration" role) do have limitations. For example they are limited in their ability to manage membership for the "Metadata Server: Unrestricted" role, and to manage individual unrestricted users - otherwise they could be in a position to promote themselves to unrestricted. Restricted user administrators can also be blocked from modifying an identity through an explicit denial of WriteMetadata on that identity. Are there by any chance any explicit/ACE denials (white background checked boxes) on the user that cannot be modified?
As LinusH mentioned it is difficult to help with permissions issues from a forum without all the necessary information. Posting screenshots of the tabs for the user administrator and the user they are trying to modify would be a good start (masking individuals names/logins if necessary). Even then it might be necessary to delve deeper and look at how the various admin users, groups and roles and ACTs may have been customized at your site.
03-21-2016 01:15 PM
03-25-2016 06:50 AM - edited 03-25-2016 06:58 AM
If you just need user administration permissions, and not be full administrators (aka, not being part of the SAS Administrators group or being Unrestricted):
- If you need that user to be able to administrate all user accounts and groups, following some best practices:
- Create a group as (SAS User administrator)
- Add the user to this group
- Provide this group the Metadata Server: User Administration
- In case that this is still not sufficient, you can apply a deviation from the best practices (therefore, hopefully it should work with just the role): with an unrestriced account, provide full permissions to the "SAS User administrator" on the "/System/Security/Users" and "/System/Security/User Groups" folders.
An alternative, not recommended, but necessary on some scenarios:
- If you need that user to be able to administrate only some user accounts and groups:
- Create a group as (SAS Users administrator - Group A) - Where Group A stands for the set/batch of groups and users to be administrated.
- Add the user to this group
- Do NOT provide this group the Metadata Server: User Administration
- with an unrestriced account, provide full permissions to the "SAS User administrator" on only the "/System/Security/Users" and "/System/Security/User Groups" items this user wiill administrate.
PS, An additional remark: in an ideal world, you would neever require to administer users: the users can be on sync with your AD/LDAP authentication system with an script or Metacoda's plugin, and you need only to administer groups, no users.
PS2. If you want to really follow best practices, the permissions applied on folders for a groups of users, this has to be transformed into: ACT for this permissions (ACT Users Admin or ACT GroupA users Admin), add the group to this ACT with the Permissions pattern as you wish, then remove the group from Authorizations on the required folders, and add the ACT to Autorizations on the required folders, .
01-11-2017 04:49 PM
We have a team taking care of all access creation for the company. The also have to create SAS Account for enterprise guide programming. We are not ready yet to link SAS Access creation to WinAD so we need to create a group for User Administration.
It seems that we have an issue with this role because it doesn't allow writting to the metadata.
I tryed going to this location, Folder/System/Security and give some access in the propertied but I have this message: "Properties have not been defined for this item.
We are on Linux 64 bit. SAS9.4 Version TS1M3.
I have linked some screen shots.
01-11-2017 06:26 PM
I have replicated the same setup in SAS 9.4 M3 as shown in the screenshots in your document and it works ok for me. There may be some other permissions settings that are causing problems for you. For example if I add sec_test to the repository ACT and deny WM then I get the same error as you do. I would suggest you review your repository ACT to see what users, groups and permissions it contains with respect to the identity hierarchy for the sec_test user. Perhaps there is an issue there?
As @LinusH mentioned troubleshooting permissions issues can be hard to do in the forums without access to your environment to review. If you are still having problems then I'd suggest you to contact SAS Technical Support for assistance, or for a more thorough review of your metadata security implementation SAS Professional Services or SAS Partner in your local area.
01-12-2017 11:57 AM
After reading the Fast Track training documentation, I found out that in our environments, the "Metadata Server: User Administration" role cannot give access to write metadata by itself, we needed to give it the "SAS System Services" default group in order to allow it. I don't know if this is by design or normal but it is working now.
What I know for sure is that they are differences between my development environment and my production environment. In my development environment, the "Metadata Server: User Administration" role doesn't show the "User Manager" and the "Authorization Manager" plugins as in production, the plugins shows.
I suspect some corruption in the default roles, groups and security configuration. I will open a tickets to SAS Support team.
Thank you for your help.
01-12-2017 11:47 PM
That does sound odd. You shouldn't need to put user administrators in the "SAS System Services" group. That's a group that has the "SAS Trusted User" as a member, the user that fetches metadata on behalf of the object spawner and several other services.
Additionally the standard "Metadata Server: User Administration" role doesn't provide access to the User Manager and Authorization Manager plug-ins. By default those capabilities are provided to "SAS Administrators" group members via the "Management Console: Advanced" role and SASUSERS members in general via the "Management Console: Content Management" role. It sounds like you have some customization to those roles and/or some additional custom roles.
01-13-2017 08:52 AM
In definition, the "Metadata Server: User Administration" role exist to allow "Create, update, and delete users; groups,
roles, internal accounts, logins, and authentication domains". No capabilities, no Contributing Rôles Added, no ACT, no modification done. We where using the équivalent Role in SAS92 before and it was working.
Thank you for your help Paul.
01-14-2017 05:23 PM - edited 01-14-2017 10:31 PM
The "Metadata Server: User Administration" has no explicit capabilities that you will see in the SAS Managemenr Console User Manager Capabilities tab. It, along with the other "Metadata Server: *" roles" has implicit capabilities that are hard coded into the software and cannot be modified by SAS customers. However, as I mentioned in a previous comment, there can be interactions with other permission settings in metadata and it might be those that are causing your problems.
What is contained in the Permission Pattern tab in your Foundation repository ACT (usually named "Default ACT"). My repository ACT, which has not been modified from the original post-install state, contains the following:
* PUBLIC: -RM,-WM,-WMM,-CM,-R,-W,-C,-D,-I,-S,-U,-CT,-DT,-AT,-A,-X
* SAS Administrators: +RM,+WM,+CM,+A
* SAS System Services: +RM,+WM
* SASUSERS: +RM,+WM,+CM
BTW you mentioned no ACT and no modifications done to the "Metadata Server: User Administration" role. In the default post-install state it should have an ACT applied (SAS Administrator Settings) and an explicit permission (PUBLIC: -WM). If it does not have those then that suggests that it has been modified, if only to remove those protections.