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.
Related
My team has attempted to utilize a 3rd party Active Directory Object auditing tool which ran some automated scripts and turned on active directory auditing on our domain controllers. We use Win 2016 Server for our domain controllers.
As a result our DCs got bogged down and we subsequently turned off the auditing. My boss doesn't want to risk having this happen again so I am attempting to find a less invasive way to monitor changes to groups, user accounts and group policy. For security reasons, we want to be able to ask the question: Who changed what and at what date and time.
My options as I see them are basically some kind of custom .NET library or solution, accessing LDAP via PHP or perhaps a polling solution using PowerShell to dump data to a secondary file, API or service.
I've scoured the internet for a solution that might work for us and spent several days experimenting and building prototypes to no avail. It seems that the expectation for all possible solutions are to turn on the auditing features and simply hope that your DCs don't immediately max out on resources.
If we were to deploy a test DC and turn on auditing for evaluation purposes, I could potentially come up with a solution to track changes over time but we wouldn't be able to assess the real world impact of certain auditing features being turned on because it wouldn't have the same traffic that our production Domain Controllers have.
The solution that I am looking for has a low impact on the performance of our domain controllers and offers a method by which to store data pertaining to active directory object changes that can be subsequently displayed on one or more reports.
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.
I have been tasked with copying users and groups from one domain to another.
These are two 2012 domains, without a trust. (Prod → model → dev domains). Passwords are not a concern (all will be reset). This will be written in powershell running on a member server of the source domain (if that matters).
My question is, should I
copy all of the groups, then copy the users adding them to the newly created groups as each one is copied, or
copy the users, then create the groups adding the memberships as each group is created, or
copy all the users, then all the groups, then go back thru the users (or groups) to confirm memberships are processed?
My gut leans me to #1, but would #2 be a better option (and is #3 really even a consideration?)
Note: This is not a directory migration. I understand users will have new SID's, and profiles. Rather, this is to set up as identical as I can lab environment.
Create your Users first as no nesting membership concerns. Create your groups and add membership, you can be sure your User membership is correct on this first pass but not nested group membership. Rescan groups for missing (group) membership and record how many groups were modified, repeat until no further modifications are required. Done.
This is basically the strategy you use with Microsoft Active Directory Migration Tool (ADMT).
You could create groups first, but your code would start with groups then users and then back to groups again. Not that this is a necessary a problem.
We did this approach in our test and dev for a while but eventually moved to Veeam Virtual Labs (Isolated Sandbox).
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.
So as to avoid overwhelming the infrastructure in a web application instance, what would be the methods of implementing a feature roll out to a controlled group of your user-base?
It depends on the situation. You can't really redirect them to another site using another database if the users are expecting to work with real data and the real site.
I would introduce a flag on your users in your user-table, let's say isBetaUser (bool). Then you can just show these new features for users that got this flag set to True. You could also let them check this flag off using a checkbox through some settings page, if they don't like the idea of trying out new features that is.
Partition your users into groups. Randomly. Demographically. Somehow.
Pick one or more groups for a pilot.
Fix your web site to have both versions of your app running. Maybe use virtual hosting or a different path or something.
One database. Two applications. Data doesn't move. Only the presentation changes.
At first, all users are in the old version. Workload has not changed.
Move a group of users so that their default URL's or links or menus or whatever are references to the new application.
Same workload. Same database. Same number of users. Two applications.
Move another group of users to the new application.
Same workload. Same database. Same number of users. Two applications.
Eventually, after all users are moved, you can delete the old application.