We currently are trying to make MongoDB 3.0 a bit more secure by adding users, roles and passwords, disabling the anonymous logins
However, when we enable auth=true or the --auth command in starting MongoDB, we can login with the DB administrator, (admins all of the DB) but we can't see any data in MongoDB Compass when the authentication is turned on, also, it shows that all of the databases have 0 Bytes of size and no Collection is shown.
Can you help me pinpoint where is the issue?
EDIT: Here is an Image of the things that our DB show on the Compass Community Edition, per clarification of the question
I solved this issue by adding the Read Role to the user Database by Database, also, in the login, I have to explicitly state the Database I am going to connect to
Basically the dbAdmin does not have the read role and has to be included manually
Regards and thanks
Related
I have a MS SQL Server with a DB that is constantly updated.
I have the credentials to access it with admin privileges.
And I'm making a Java EE webapp to display (hence, only display) its data.
But I have to make sure that, under any consequences,
My webapp doesn't modify the DB.
And no, the owners of the DB don't want to make an unprivileged user for the webapp.
Any ideas? I'm using JDBC + JPA.
In EclipseLink you could mark all your objects as #ReadOnly, so they won't be written.
You could also register an event listener to throw an error on persist, update or remove.
I am creating an Access project linked to a SQL Server. Instead of using Windows authentication for the SQL Server I want to use an application specific username/password and authenticate users myself using a login form. The reason is that other applications may connect to this database from a context where Windows authentication is not an option (FileMaker Server for instance).
I have found myriad discussions that cover this issue from one angle or another, but none that have actually enabled me to implement a solution. I do not have a lot of VBA or LDAP experience but I know this must be possible.
So, what I want to do is:
Ask the user for a username and password when they open the database.
Use that username and password to authenticate them
against our LDAP server.
Proceed if it passes, fail if it does not.
Can someone sketch out how this works or point me to a resource that describes this?
One way to accomplish this is to create a VBA procedure which loops through all of your linked tables and alters the connection string to embed the username and password from a login form.
You can get the syntax for the existing ODBC linked tables by going to the debug window and typing this:
? CurrentDb().TableDefs("My Table Name").Connect
Which should give you something similar to:
ODBC;DRIVER=SQL Server;SERVER=MYSQLSERVER001;UID=JPARKER;PWD=Pizza123;APP=2007 Microsoft Office system;DATABASE=MyDatabaseName
So your login form would capture the user name and password from the user, then store those as variables and use to build a new connection string. Then iterate through the tabledefs collection updating the connect property. Happens pretty quickly.
My objective is to prevent direct user access to the database server. One way is to create a WCF service or web service in the middle between the front end application and the database server.
First of all, the users will be authenticated to the application. Subsequently the application will connect through the WCF service to perform business logic operations. The WCF service will perform the database related operations by using one windows account. This will prevent other users to directly access the database server, since the permission will only be granted to specific one windows account.
Here are my questions : Even though the database access is only granted to one windows account and the WCF will use this windows account to perform database related operations, is it possible to mark all database related operations with the credential of the logged in user ?
Update
Thanks for the replies. Seems like the above scenario is not achievable. I am currently exploring the SQL 2008 Application Role feature. One of the example is here. But after further exploration, apparently there is an issue with the connection pooling.
Update
There is a stack overflow thread here regarding SQL Server Application Role
You'd have to have every user set up in sys.server_principals to enable context switching like EXECUTE AS which would mean that they have direct db access anyway.
If you enabled kerberos/delegation, the same applies. Links One and Two
You'd have to pass in the user name as a parameter on each SQL call, or use CONTEXT_INFO perhaps.
Note: every MS Office user has MSQRY32.EXE which acts as a query tool. If you want no direct DB access, then you need to ensure there are no permissions set or granted
Depends.
If your database and WCF service are on the same box and you do a lot of jiggery pokery to impersonate then it is possible. As soon as you move your DB to another box then it stops working.
This is a known limitation and the reason is impersonation will create a token which will get you to a box but this is not passable to another box. I tried to find the Q&A where MS guy had answered but still havent been able to. Whenever I find it, will update.
I'm having a problem with my SSRS 2008 configuration at the moment. This is how we are currently set up.
1 server hosting SQL Server and SSRS, no integration with sharepoint etc. Users access the SSRS web application, and then from there they access the "Report Builder 1.0" too, which they can use to create and run reports based off a reporting model.
This is all done using Windows Authentication - so they login with their domain account to the web application, and then again when loading the Report Builder. Each domain user is configured to be able to login to SQL Server rather than using a generic SSRS account, and all of the above works fine.
The way this is setup means that you can always tell which individual user is logged in and running reports - either to the website or when running reports through report builder. This is a requirement of this application as all users will see slightly different versions of the data models (this is controlled by the underlying views, based off the domain account running the query). So Tom may get 100 rows back from his query but Harry will only get 50, etc.
The Datasource is setup to use integrated security (Which passes through this domain account to SQL Server).
My problem comes when a user creates a report in report builder, and then saves it to the server. When they login to the web application and run the report there - it works fine, but when they try to setup an email subscription, they get this message:
"Subscriptions cannot be created because the credentials used to run the report are not stored, or if a linked report, the link is no longer valid"
A bit of research leads me to think that this is down to the integrated security settings, as for some reason SSRS is ignoring the currently logged on user account or cannot use that to setup the subscription.
Everything works if I set the datasource to use a specific account - but then that breaks the data filtering based on user account (obviously, as it would now be just using one account for everyone!).
Any ideas for how I can approach this? Is there a configuration setting that I can play with to try and get this working using integrated security? Any help/comments are appreciated!
To create a report subscription you must meet a few reqs:
First is,
A report that can run unattended (that is, a report that uses stored credentials or no credentials).
To do what your wanting to do I suggest you setup data driven subscriptions. Heres a link to get you started. Data Driven Subscriptions Theres also several good videos of the basic setup. Like this one sqlLunch #8
Here's another walkthrough that's pretty decent: Walkthrough
Hope any of this helps ya.
Thats a nice one to have in your tool belt as well.
If you just drop the subscribed report into a file share instead of emailing it, the users can fill in their username and password, so it will run as them. The only problem with doing it this way is when they change their password, they will need to go and put the new password into the subscription again.
I guess they could have another account with a password that wont expire to run the report as, but that's probably not good practice
what you could do is have the list of users in a table in the database with what they're permissions are, then set up a data-driven subscription to get the list of users and get their permissions and filter the report accordingly.
We have a system that uses a SQL server 2005 database with a number of views these are automatically run daily and the result sets emailed to the client.
I dont really know much about the system as a colleague of mine looks after it all but apparently its been working fine. We recently changed the admin password on the server SQL is installed on. Since then apparently a number of the views have stopped working. My colleague has said hes fixed the problem by dropping the views and recreating them.
As far as Im concerened the server admin password should have nothing to do with the views, as the application that runs them is using SQL authentication with its own login.
Any ideas what could have caused this? All the views seem to be in the DBO schema and not tied to any particular user account. I'm not convinced its anything to do with the server admin login password changing but just wanted to hear your thoughts.
Thanks.
The views should continue to work. Perhaps you have the sa password hardcoded somewhere in your process.