I have a SSRS 2016 instance that we've implemented a custom authentication module for. The module works perfectly for 100's of users but for a handful, users are unable to create subscriptions.
When those users hit the "Create" button, they receive an error "Something went wrong, please try again later".
There's nothing obvious within the log files.
However - if I look at the Users table within the SSRS database, all affected users have a UserType set to 1. With all other users set to 0.
It seems to much of a coincidence so I'm assuming this is the issue.
Looking at https://learn.microsoft.com/en-us/dotnet/api/microsoft.sqlserver.management.smo.usertype?redirectedfrom=MSDN&view=sql-smo-160 it seems that 1 represents user who user a certificate for authentication. 0 is for username and password.
If I set the UserType to 0 for the affected users, when the user re-logs in, SSRS sets it back to 1.
Does anyone know what SSRS is looking at in order to set that value to 1? Perhaps if I knew the condition being met in order to set that, I can work out why that applies to the handful of users affected.
Related
I have a 2010 sharepoint list. It's linked to Microsoft Access as a linked table. I'm trying to make some updates in Access. The SP list has no lookup columns, all of the People-type fields are People Only (not People and Groups), there is no referential integrity set because there are no lookup columns, and absolutely none of the columns are required. Also, there is no Validation set on any column in the List Settings.
I get the error: "You cannot update this field because the value you're trying to apply is not valid or would break a data integrity rule. Please correct and try again"
The thing that's frustrating is, if I ADD records (using Access), I can do that, and then I can EDIT those records. When I first add them, I don't include any People information (because it seems I cannot do that from Access) - I leave those columns blank.
If I THEN go, at that point, to my newly created records, in sharepoint online, and add some People information, and then go back to Access, suddenly I cannot do ANY update in ANY column - I get that error message.
Anyone know what this might be or what I am doing wrong? I'm not even trying to update a People field in access at this point - I'm only trying to update fields I was easily able to update in Access a few minutes ago--just BEFORE I populated those People columns with data in SP online.
I have an MS Access database where all the users will be in the same group, except a few. I don't need to restrict certain objects from users. Instead, I need to give the current user write capabilities to his record and its related records only and read-only capabilities to all other records. Is this possible?
Unfortunately, be it Access, SQL server or Oracle, the restriction of rows to a single user is not built in. This means you have to build some type of interface in which you grab/use the users Logged on ID (their network pc id, or say prompt for a user + password). Then you when a form loads you have to restrict the records to that one given user. There are many ways to do this and they are all standard approaches to filtering or restricting data. However "YOU" have to build and write such code into the forms. You could perhaps base the form on a query with a expression (VBA or macro TempVars) that limits the records returned to the given user.
So you have to “cook” and “code” this ability for most any database. You thus also need to code to “save” the user name who created the record. This coding requirement as noted is required for most systems when looking to restrict data to single rows and such features are not generally built into the database system. You also likely need to restrict and prevent users from opening the database and seeing the table view.
I was working to set up SSRS as a Self Service tool for all the users in an organisation.
Is it possible to have 5000 unique users for SSRS ?
If so, can we set up row level security for each employee ?
Yes you can provide row level security. By providing the individual user permissions to the database and restrict the data returned for your report.
There is no rule as to how many users you can have (I believe it is set to 32767). However depending on what they are doing, the simultaneous user connection number can get limited by your hardware specifications so to not overload your server.
I suspect the answer is no, but here goes..
I'm using the WebForms Report Viewer on a public-facing website to allow users to report on themselves or their users (if the user is an admin user).
A report has a parameter called Users where an admin can pick a user from the list and generate a report from it. Mundane users can also view this report, but I programmatically create a linked report for each user and set the UserID value to their ID so they can only view themselves.
This works well except that the UserID parameter is query-based, and not every user is visible in the list using default settings (the user list is based off date range parameters can provide, and only users we consider 'active' during the date range are visible).
This is blowing up for mundane users that are not active for the default date range (which is the previous month).
I suspect the flow of execution is something like this:
Report loads with default parameters
The linked report rules are now applied and the value of the UserID is overridden with the ID in the linked report
UserID field is now hidden to prevent the user from changing it
SSRS can't find the UserID default value in the query results (that I didn't even want it to run) so it displays an error The 'UserID' parameter is missing a value
Through some testing I've found a perfect correlation between users not inside the default date range and users who can't view the report.
Can anyone suggest a way to make the report usable for those users that aren't in the default list? The reports are created programmatically so I do have a fair bit of control over the situation.
I would love to simply be able to mark a parameter in a linked report as no longer being query-based, but those properties are all read-only.
I really, really don't want to have to create duplicate reports to accommodate these users but I'm at a bit of a loss right now.
Any suggestions are greatly appreciated!
Go into parameter section of linked report.
Disable 'Has Default'
Click 'Apply'
Re-enable 'Has Default'
Click 'Apply'
and you're good to go!
I haven't figured out yet how to re-enable 'Query Based' as a default after removing it :(
Would be very much obliged had you found out......
Can't you just mark the param as 'nullable' then pass null in from the linked report ( you may have to alter the back end to cope with this?
Alternatively add an extra row to the 'users' day something like -1 "unknown user" then you can just watch for -1 and handle accordingly
Considering the set up:
Ms Access Application split into Front End and Back End = both native MS Access
Front End consists of forms only - it will be the only way to access data
Front End copy distributed to each user machine (thanks for answers to this question)
I need to implement the following scenario:
Ms Access application with < 20 users,
each user is assigned to 1 to 10 projects,
when user opens the MS Access he should only be presented with the data related to the project(s) he is assigned to
So for example we have users:
John
Owen
John is assigned to projects A,B,D.
Owen to B,D
When John logs in he can see only data
related to projects A,B,D. When Owen
logs in he can see only B,D
John and Owen can access the application at the same time
Related tables in the Back End
user
project
userProject - links user(s) to project(s) in many to many relationship.Each user can be assigned to one or more projects, one or more users can work on a project.
I came across this solution on databasedev.co.uk which basically uses a hidden form to store the current users details and then using this to filter the data on other forms.
So here is my Question:
Would that be the recommended solution? Are there any better options? I was thinking that I could use a table on the Front End instead of the hidden form for example.
Edit Re Comment
I see no reason why you should not maintain a table of users in the back-end with a join table of user, project that can be used to filter the projects.
The current user can be obtained with code if you are using network name (http://www.mvps.org/access/api/api0008.htm), it can be stored to a hidden field on the form, which would be useful for setting the form to relevant projects, or you could store the name to a custom database property (http://wiki.lessthandot.com/index.php/Custom_Database_Properties_Creation_and_Use)
The code below applies to finding number of logged-in users.
You could use provider specific ADO Schemas. You need to pass a valid connection, for example:
ADOUserList Currentproject.Connection
Public Sub ADOUserList(oConn As ADODB.Connection)
Dim rs As ADODB.Recordset
Set rs = oConn.OpenSchema(adSchemaProviderSpecific, , "{947bb102-5d43-11d1-bdbf-00c04fb92675}")
Debug.Print rs.GetString
rs.Close
End Sub
More information: http://msdn.microsoft.com/en-us/library/aa155436.aspx
I have a similar, if slightly more complex, situation. In my case, Users are assigned to User Groups, which have varying permissions over Access objects (forms, reports etc). They also have Projects to which they are assigned, and Preferences. Tables:
user
user_group
user_pref
project
user_project
I still, however, use a hidden form (session) which holds session information about the user that's currently logged in. eg: user_id, user_name, subform of assigned projects, preferences (such as 'Current Project').
Finally, a module basSession contains all the functions I need to get or set any of the session information in the hidden form, eg gfSession_GetUserID().
HTH
Be aware that in your current setup there is no way a method to 'Identify users and based on that limit access to data'. If all data resides in a shared backend Access file, your users can just open the back-end database and browse through all data. The only way to actually limit your users' access to the data is by using a database server.
If you want to go to Access I would suggest that you create queries for all (important) tables and use these queries in the forms. Include a WHERE statement in the query that limits the output to what the user may view. You can do this by either changing the complete SQL on opening of the database or include a global variable in the WHERE part of the query and set that variable to the current UserID.