I'm trying to run the script below in microstrategy command manager. I'm getting the error code below. Does anyone know what the issue might be and what I need to do to solve it?
Code:
LIST PROJECTS;
Error:
Syntax is correct.
(You do not have Monitor Cluster privilege that is required to perform the task.)
Task(s) execution completed with errors.
Execution Time: 00:00:00
There are a number of privileges granted directly to the user or group and not granted from a security role.
This particular privilege is one of those. Edit your user or one of the groups to which your user belongs and click “Project Access”. Scroll down to the “Administration” group and check “Monitor cluster”.
You can see more of these privileges in the Admin Supplemental guide. Those that are “server level” are granted directly to the user or group and not from a security role.
Related
imagine there is a Powershell script running under the SYSTEM account on a Windows 10 machine and checks which domain user is currently logged on. No big deal.
Now: I want to check if this logged on user has administrator rights on this machine. Every check I could find so far is only looking at ".IsInRole([Security.Principal.WindowsBuiltInRole]::'Administrator')".
But this only checks if the user is a direct member of the local group "Administrators". But it is possible that within the local Administrators group there is a domain group, and the user is a member of this domain group instead. So he is admin, even if he is not a direct member of the Administrators group.
How can I check for both at the same time? I just want to check IF someone is admin, no matter where those admin rights come from. This check will also run under the SYSTEM account, not with the affected user account itself.
Any ideas?
If the Domain group is part of the local admins group, then by design, all users in that domain group are local admins and has all the rights and privileges that means. So, that code block would still apply.
You have to explicitly check for user rights and privileges assigned. There is no cmdlet for this built-in, so you have to code for it. To see your rights and privs, you can just use the good old whoami.exe...
whoami /priv
# Results
<#
PRIVILEGES INFORMATION
----------------------
Privilege Name Description State
============================= ==================================== ========
SeShutdownPrivilege Shut down the system Disabled
SeChangeNotifyPrivilege Bypass traverse checking Enabled
SeUndockPrivilege Remove computer from docking station Disabled
SeIncreaseWorkingSetPrivilege Increase a process working set Disabled
SeTimeZonePrivilege Change the time zone Disabled
#>
... then compare that to the Windows Privilege list that are normally used for Administration actions.
Running this remotely as the logged-on user, cannot be done with PowerShell natively, it's a Windows Security boundary and thus, you'll need something like PSExec.exe from MS SysInternals to try that.
Want to identify the users/login with Administrative access on server to migrate them to new server's. I have tried Select * from $System.TMSCHEMA_ROLE_MEMBERSHIPS but these give information regarding the particular database i need more at server level.
Ssas users are done quite differently from normal databases. Ssas uses only the active directory account of the user trying to connect.
On server level the only security is done in the properties of the server, there you can select active directory users with administrative access to the server.
On database level you can create roles, give them access to (part of a) database and link active directory users/groups to them.
Using the analysisservices namespace of microsoft you already mentioned you can look trough every role in every database and note the permissions.
As far as I know you can't actually use this namespace to see all the administrators of the user. But unless you have an unreasonable amount of administrators the best solution might be to just open the server in sql server management studio, click on properties, security and write down all the AD members manually.
I hope this helps you and good luck!
I get following error when trying to save a release pipeline on Azure dev. What exact permissions do I need to ask from my administrator?
Access denied. <<user id>> needs Use permissions for pool Default to perform the action. For more information, contact the Azure DevOps Server administrator.
I found granting Admin to a pool very confusing (and time-consuming to resolve) but I think I can explain how I got it to work for my org. This is a further explanation, based upon what #Leo Lui-MSFT said, as that was not quite clear enough for me.
My problem: I wanted to give a user access to update a pool that the user had not created (ie, was not an Owner).
Attempted solution: Making the user Admin on the pool did not let the user do that.
Successful solution: I had to go to https://dev.azure.com/my-org/_settings/agentpools > Security > Add . I then added the user and assigned the Admin role.
This has the side effect of giving the user Admin on every pool in the org (which was not what I wanted to do). If this is not your desire then go into the pool you do not wish to grant Admin access to, set Inheritance off and then remove the user from that pool.
This feels wrong, to me. I should have been able to make a user an Admin of a single pool without granting org-wide Admin over all pools.
Also as all pools seem to be created with Inheritance defaulted to true then to remove that user as an Admin from all other pools could be time-consuming and when more pools are created then I would need to remember to turn inheritance off.
That is my experience. If I have missed something please let me know.
What exact permissions do I need to ask from my administrator?
You need ask the User permissions from administrator.
When we go to Project Settings->Agent pools->The Agent Name->Security:
Check the document Security of agent pools for some more details.
Roles are also defined on each organization agent pool, and
memberships in these roles govern what operations you can perform on
an agent pool.
The All agent pools node in the Agent pools tab is used to control the
security of all project agent pools in a project. Role memberships for
individual project agent pools are automatically inherited from those
of the 'All agent pools' node. By default, the following groups are
added to the Administrator role of 'All agent pools': Build
Administrators, Release Administrators, Project Administrators.
So, you should ask User permissions from your administrator, or add your account to one of the groups mentioned above, then try it again.
I used -e AZP_POOL=XXX parameter when docker run to solve the same issue, even my account is an administrator.
Check if you are entering the pool name correctly. If you pressed 'Enter' to keep the default name for the pool, it does not work, you need to specify the correct name for the agent pool
I had similar problem with a Pipeline:
Error: Access Denied: 0000000d-0000-8888-8000-000000000000 needs the following permission(s) on the resource /Organizations to perform this action: Read Organization resources
I created again service connections and change this in the pipeline:
I think this user was delete from active directory.
(I realize this question is regarding DevOps but DevOps Server / TFS may have different interface but encounter the same issue)
In TFS or DevOps Server, you have to be added to Team Foundation Administrators group through TFS Admin Console only. To do that:
Access Team Foundation Server Administration Console via Server > Application Tier > Group Membership > Team Foundation Administrators > Properties > Add user.
You should have an organization level access to get rid of the error message you are getting.
If you've created the organization you will be the owner of the organization, you should have all the admin access to do whatever your pipeline need.
otherwise, Select the organization -> Go to organization settings -> agent pool [left plane] -> security [right top] -> add a new user with your name with admin role
Try the same with project level settings.
I am upgrading Collaborative lifecycle management version to 6.0.5 current version is 5.0.2. As specified in IBM Interactive upgrade guide one of the step is to run upgrade script on your databases and below are the command
cd D:\IBM\JazzTeamServer6.0.5\server
upgrade\jts\jts_upgrade.bat -oldJTSHome "D:\IBM\JazzTeamServer5.x\server\conf" -updateTomcatFiles no -updateAppServerFiles no
After running this command I am getting message as "Upgrade must be run with administrator rights"
I am logged in as administrative user on the system, assigned all the full access control permission of folder where CLM server is installed to user still everytime same problem persist.
I was going through links to troubleshoot the problem but nothing seems to be working out for me. Some of the links I have referred are
https://www.techsupportall.com/how-to-enable-administrator-account-on-welcome-screen/
http://www.thewindowsclub.com/elevated-privileges-windows
Can anyone please suggest I am missing anything here?
This could be caused by User Account Control, a feature which makes so that, even if you have administrative rights, you don't actually have them unless you explicitly request them. There are two distinct policies governing UAC behaviour (both found in Computer settings\Windows settings\Security settings\Local policies\Security options), one for the built-in Administrator account, and another one for all other administrative users:
User Account Control: Admin Approval Mode for the built-in Administrator account (disabled by default)
User Account Control: Run all administrators in Admin Approval Mode (enabled by default)
What this means is: by default, the built-in Administrator account is not affected by UAC, while all other administrative users are; thus, it's possible for an administrative user (different from the built-it Administrator) to not actually have administrative rights, even if it's a member of the Administrators group.
More info -> https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd835564(v=ws.10)
On IBM DB2 v.9 windows, when someone connect to database by Server\Administrator user
DB2 database will automatically accept and grant all the permissions to this user?
But, in some case environment Administrator of server does not need to see every data in the database. So how to prevent Administrator use connect to database?
On 9.5 and older this would not be possible because the account under which your instance runs is SYSADM. Also Administrator can reset at least local account passwords and gain access to them, making changing the instance owner account useless.
However on 9.7 and onwards the instance owner will not have access to the data anymore. One option is to upgrade to 9.7. Furthermore you can set up an AD account for the connections your applications use. Local Administrator is not necessarily able to change into those credentials.
Still, the Administrator ultimately has access to the (usually unencrypted) database files. You can mostly improve the administrative aspect of security.
Umm... For many times I try to revoke with this command but when I connect to database by Administrator account DB2 will automatic grant permission to Administrator again.
I will try again for make sure.
By default, DB2 databases are created with CONNECT authority granted to public. If you want to restrict some users from connecting, you need to do
GRANT CONNECT ON DATABASE TO <user1>, <user2>, ...
Then revoke the CONNECT authority from PUBLIC
REVOKE CONNECT ON DATABASE FROM PUBLIC
I don't think it's possible under normal circumstances simply because Administrator is in the sysadm group.
Options I can think of (but haven't tried) include:
Setting the sysadm group to something else ("db2 update dbm cfg using sysadm_group blah"). Check the docs for caveats and gotchas when doing this, as I'm sure there are some.
Stop using OS authentication. Use a different security plugin (8.2 and higher only). This would move the authentication, and thus groups, to a new location (say an LDAP server). Then you just don't add Administrator to the new location, and especially don't add Administrator to the sysadm group again.
On Windows, the database manager configuration parameter SYSADM_GROUP controls who has SYSADMauthority at the instance level. When SYSADM_GROUP is blank (as is the default on Windows), then DB2 defaults to using the Administrators group on the local machine.
To fix this, you can create a new group in Windows and then modify the value of SYSADM_GROUP to use this new group. Make sure that the ID that the DB2 Service runs under belongs to this new group. After making this change, members of the Administrators group will no longer have SYSADM authority.
As Kevin Beck states, you may also want to look at restricting CONNECT authority on databases, too, because by default the CONNECT privilege is granted to PUBLIC.