On premises AzDevOps Server 2019, version Dev17.M153.5. I have restricted default access rights to agent queues on every single project in every single collection - removed the default set (Release Admins/Build Admins/Project Admins), added some other lines (Server Admins).
Now, ever once in a while, intermittenly with no pattern that I can see, those three permissions keep coming back automagically. On different projects, through no human actions (all the humans who have the rights for that have been told), those three lines with the Administrator role reappear on the default agent queue ACL.
Is that a known behavior in AzDevOps? Any way to opt out?
EDIT: here's what it looks like. The first three lines don't belong.
EDIT: as per the advice, I'd try to track it down using the activity log. I went and made a dummy change to default queue security elsewhere. There was a log record with command SecurityRoleAssignments.SetRoleAssignments. I then filtered the activity log on the collection where the permissions have reverted, and searched for the same command. No instances. The log ends around 7/14, which is likely before the event.
This should be caused by Inheritance permission. By default, the option Inheritance is turned on and the following groups are added to the Administrator role of 'All agent pools': Build Administrators, Release Administrators, Project Administrators.
If we turn off the option Inheritance, we can remove the default permission groups (Release Admins/Build Admins/Project Admins).
If we turn on the Inheritance, the permission group will be inherited again and the default permission groups will come back, please check the option and confirm that inheritance is always off. Please also confirm with all the humans who have the rights to update the option.
Uodate1
Login {Azure DevOps Server URL}/_oi/_diagnostics/activityLog, we can see the Activity Log and check who added the permission groups, please check it.
Installed Azure DevOps 2020. A couple of weeks in, no such behavior.
Concluding it was a bug in AzDevOps 2019 all along that they've quietly fixed.
Related
I've been looking at organisation and project settings but I can't see a setting that would prevent users from creating work items in an Azure DevOps project.
I have a number of users who refuse to follow the guidelines we set out for our projects so I'd like to inconvenience them and the wider project team so that they find it better to follow the guidelines than not - at the moment we've got one-word user stories and/or tasks with estimates of 60-70 hours which isn't reflective of the way that we should be planning.
I'd still want them to be able to edit the stories or tasks and moving statuses, but that initial creation should be off-limits for them (for a time at least). Is there a way to do this??
The Azure DevOps Aggregator project allows you to write simple scripts that get triggered when a work item is created or updated. It uses a service hook to trigger when such an event occurs and abstracts most of the API specific stuff away, providing you with an instance of the work item to directly interact with.
You can't block the creation or update from, such a policy, Azure DevOps will inform the aggregator too late in the creation process to do so, but you can revert changes, close the work item etc. There are also a few utility functions to send email.
You need to install the aggregator somewhere, it can be hosted in Azure Functions and we provide a docker container you can spin up anywhere you want. Then link it to Azure DevOps using a PAT token with sufficient permissions and write your first policy.
A few sample rules can be found in the aggregator docs.
store.DeleteWorkItem(self);
should put the work item in the Recycle Bin in Azure DevOps. You can create a code snippet around it that checks the creator of the work item (self.CreatedBy.Id) against a list of known bad identities.
Be mindful that when Azure DevOps creates a new work item the Created and Updated event may fire in rapid succession (this is caused by the mechanism that sets the backlog order on work items), so you may need to find a way to detect what metadata tells you a work item should be deleted. I generally check for a low Revision number (like, < 5) and the last few revisions didn't change any field other than Backlog Priority.
I'd still want them to be able to edit the stories or tasks and moving statuses, but that initial creation should be off-limits for them (for a time at least). Is there a way to do this??
I am afraid there is no such out of setting to do this.
That because the current permission settings for the workitem have not yet been subdivided to apply to the current scenario.
There is a setting about this is that:
Project Settings->Team configuration->Area->Security:
Set this value to Deny, it will prevent users from creating new work items. But it also prevent users from modify the workitem.
For your request, you could add your request for this feature on our UserVoice site (https://developercommunity.visualstudio.com/content/idea/post.html?space=21 ), which is our main forum for product suggestions.
I would like the ability to protect against the deletion of a cloud SQL instance. This seems like a good step to take to avoid actions from an angry employee or a regretful click.
Google added a deletion protection flag for Cloud SQL in August 2022.
https://cloud.google.com/sql/docs/mysql/deletion-protection
I couldn't find anything like literally protecting the instance vs deletion, but, you could use the predefined roles in your instance to try to protect your instances from, as you said, angry employees.
For example:
Keeping the role owner to yourself (assuming you are, indeed, the owner of this project).
Depending on the needs of the employees, you can probably assign them the role cloudsql.editor or similar. If this is too much, you can create your own custom roles to narrow down what you need.
As for a regretful click, there is no much you can do. You could regularly create an export and save it on one of your buckets, just in case you need to create again your instance after a 'regretful' click.
Well, terraform certainly seems to have added some kind of deletion protection on the GCP sql instance. When I try to "terraform destroy" , I get this error
Error: Error, failed to delete instance because deletion_protection is set to true. Set it to false to proceed with instance deletion
Perhaps this functionality was added after the OP had reported the issue - which is quite possible given how old this thread is.
A related issue which talks about this.
We have a bunch of reports in our server that are shared among many users. The reports implement data filtering based on user attributes so the same report will show different data to different users. Each user gets a login to our server and the ROLE_USES gives them read-only access to the shared reports.
Our problem is that users can see, edit and even delete each other's scheduled jobs. According to the documentation "Typical users only see the jobs that they have defined themselves; administrators see the jobs defined by all users.". But that doesn't seem to be the case.
One of the workaround seemed to be to create separate roles for the users and then make copies of the reports. We have tried that. Two users, each having access to different sets of reports. When they go to the "View" -> ""Schedules" menu, they still see all scheduled job, even the ones that are for the reports that they have no access to!
I would really appreciate is someone had any clue where to look. We've been searching through many JasperReports configuration files but can't find any clues...
We are using Community Edition 6.2.1 of JasperReports Server.
Analysis
Usually you want to separate the users into different groups. Those groups can be used to assign rights. So lets assume you've got two different groups, Finance and Operations. The following rules should get created:
RULE_FINANCE
RULE_OPERATIONS
Regarding the setup for the users, just assign the new roles to the users.
NOTE: Keep in mind that ROLE_USER always needs to be assigned to a user for it to function correctly. Do not remove this role from users. Where applicable, you can remove rights on e.g. folder for this user, though.
Using the roles
Now every role or group should be able to see only the reports, folders or schedules the role or group has created.
The jasperadmin, which is the highest level admin of the Community Edition, is always able to see all schedules, reports and folder for all users and could deactivate the schedules in any case.
I have created and added some workflows to CRM 2011 RU13, through the UI
Through not fault of my own my development environment is completely air gapped from my production environment.
I added these workflows to my solution and exported the solution as managed and given the solution to the production admin.
When he deploys it fails with this message.
The workflow cannot be published or unpublished by someone who is not it's owner
How do I fix this. There is no way to not give workflows an owner. or say that the owner is the solution.
The production admin gets that message because he is not the owner (inside the target CRM environment) of one or more active workflows included in your solution.
This happens in these situations:
First time you give your solution to be imported, is USER_A to
perform the operation and all the workflows are assigned automatically
to him. If later USER_B try to import an updated version of the
solution he gets the error message because is not the owner of the
workflow(s).
First time you give your solution to be imported, is USER_A to
perform the operation and all the workflows are assigned
automatically to him. Meanwhile one or more workflows are assigned to
USER_C. If later USER_A try to import an updated version of the
solution he gets the error message because is not the owner of the
workflow(s).
Before a workflow can be updated must be first deactivated, and only the owner can deactivate a workflow. This is by design.
In your case the production admin must be the owner of the processes (he can assign temporarily the workflows to himself, import the solution and after assign back to the right user) or needs to be the owner of the workflows to import the solution (if he has the rights)
A couple of additional points for clarity for the OP:
The owner of the workflows in your dev environment is not relevant, the importing user in prod will become the owner (this does not contradict Guido, I'm just making sure you don't follow a red herring). It is quite right for their to be an "air gap" between dev and prod.
If you know which workflows are in your solution, assign those in prod to yourself, then import, then if and only if you need to, reassign them to the original owner(s).
You may not need to if that owner is just an equivalent system admin user, but if it is a special user (eg "Workflow daemon" so users can see why it updated their records) you will want to re-assign.
Note that after re-assigning them, that user has to activate the workflows. You cannot activate a workflow in someone else's name (or users could write workflows to run as admins and elevate their priviledges).
If the workflows have not actually been changed in this version of your solution, take them out of the solution and ignore them - often I find that a workflow has been written, carried across to production in the original "go live" and is then working perfectly fine, but is left in the solution which is constantly updated and re-published (ie export / imported).
Personally I often have a "go live" solution (or more than one, but that's a different thread...) and then we start all over again with a new solution which only contains incremental changes thereafter. This means that all your working workflows, plugins, web resources etc do not appear in that solution so this avoids confusion as to versions, reduces solution bloat, and avoids this problem of workflow ownership. If a workflow is actually updated, then you need to deal with the import, but don't make this a daily occurrence for unrelated changes.
We are using perforce in my company and heavily rely on it. I need some suggestion for the following scenario:
Our Depot structure is something like this:
//depot
/product1
/component1
/component2
.
.
/componentN
/*.java
/*.xml
/product2
/component1
/component2
.
.
/componentN
/*.java
/*.xml
Every product has multiple components and every component consist of java or xml or some other program file. Every component has a manager/owner associated with it.
Right now, we have blocked the write permissions for every user and only when it is approved by the manager/owner after code review, we open the write permission for that user for any file/folder to check in. This process becomes a little untidy because the manager/developer have to wait for perforce admin to allow permissions (update protections table of perforce). Also, we give them a window of only 24 hrs to check in (due to agile, which i dont understand much :)), after which we are supposed to block the write access again for that user.
What I am looking for is a mechanism where perforce admins can delegate this responsibility to respective managers/owners without giving them super user or admin access and which automatically disables the write permission after 24 hrs.
Any suggestions ?
Thanks in advance.
There's nothing to do this out of the box, per se.
The closest thing I can think of is if the mainline version of these components were permissioned by a group with an owner. The owner of the group is allowed to add and remove members from the group, thus delegating the permissioning to the "gatekeeper" rather than the admins, themselves.
Let me know if you require further clarification about this.
One common solution is to build a simple tool which reads and writes the protections table, the group memberships, etc., to implement the policies that you desire.
The protections and groups data are not complex in format, and you can easily write a little bit of text-processing code that writes and re-writes these specs according to your needs.
Then install your tool on the server machine in a secure fashion, granting the tool the rights to update the protections table, and have your component administrators use the tool to manage the permissions.
For example, I've seen this done by writing a small web application, in Java or Perl for example, installing that on a web server on a secure machine, and letting the component admins operate that tool through a web interface.
All your tool has to provide is (a) a simple login/logout mechanism for your component admins (the web server may already do this for you), (b) a command that takes a user name and a folder name and grants permission, and (c) a command (or a timer) that removes that permissions subsequently.