Earlier today I restored a database from our DEV environment onto our TEST environment. After restoring, I removed all of the logins (both NT and SQL) from the database. Much to my dismay, one of the users from the database in the DEV environment is able to get into the TEST database. I have confirmed this through both looking at his screen confirming his connection and using Profiler and watching his logins.
He cannot get to any other databases on TEST which is expected.
Although it shouldn't matter, DEV is 2008R2 and TEST is 2012.
Has anyone ever seen anything like this before? Is it possible something I cannot see has "come over with the backup" and is still there?
There's a distinction between database users, and server logins. Restoring a database should have no impact on the login (username and password) that the individual used to connect to the server...
If you only removed users from the database that you restored, the individual may still have permission to the database because of the access granted to their login (such as sysadmin).
Check what logins exist at the server level, instead of at the database level. Also watch out for the BUILTIN\Administrator role at the server level, which may be granting the individual access because he is an administrator at the windows server level.
Related
I setup some security on a database called test.
The user with the name "user_test" is not a system Admin. Therefore, he has the admin permissions and member permissions on the test database.
As stated :
Creating design documents is restricted to admins, and if the replication is triggered without admin credentials, writing the design documents during replication will fail and be recorded as doc_write_failures. If you have admins, be sure to include the credentials in the replication request:
Since they are referring to the design docs, I was thinking about the database admin.
Therefore, when I try to setup a replication document in the _replicator database, the connection "hang" with the "user_text" credentials.
If I use my system admin, the replication get triggered instantly.
So my question :
In the target or source property, do I need to put the system admin credential or the database admin credentials?
Update
Setting up a replication using a system admin gets triggered automatically (good).
If I use a database admin, nothing occurs. Not even an error. Wich is kind of weird because it works on other pcs...
For you information, after testing and fixing some errors, I figured out that you can use non-system admin for replication.
Even tough, I had some problems with my replications that were having errors. I ended up clearing the corrupted documents in the _replicator and restarting each instance and everything got fixed.
We have c# web app connecting MongoDb deployed on Linux server. The idea is to use single designated Linux account for our web application to login and connect into MongoDb. As I understand from what I read, MongoDb does not support integrated security at all by default, it supposed to have its own user database with passwords, and no roles too, right? If so, I wonder if there is any separate third-party framework/tool or something that helps me use desired approach?
Other than that, if you know good online article regarding best practices to implement Security for Mongo in web applications, like where and how to store users and encrypted passwords etc., please give me a link.
please give me a link.
I did some security documentation a few months ago for MongoDB and it can be found here, this should be your starting point.
As I understand from what I read, MongoDb does not support integrated security at all by default, it supposed to have its own user database with passwords, and no roles too, right?
Up until MongoDB 2.2, authentication and authorisation is all local.In 2.2, there is limited RBAC (Role Based Access), i.e. two roles "read" and "write", with "write" being able to do everything on that database, i.e. admin.
Things will change in 2.4 with new roles:
name description of privilege
read ability to query data in any collection in the database, other than 'system.users', and also ability to run any command without an A or W attribute
readWrite everything permitted by 'read' privilege, and also the ability to insert, update,
or remove documents or indexes in any collection other than 'system.users', and also the ability to run any command without an A attribute
userAdmin ability to read and write the 'system.users' collection
dbAdmin ability to run admin commands affecting a single database; see list below
serverAdmin ability to run admin commands affecting the entire database server; Can only be set on admin database; see discussion
clusterAdmin admin commands for a cluster of shards or a replica set; Can only be set on admin database
as documented here. This enhanced RBAC will be available in all versions of MongoDB from 2.3.2 (development build) and the next production release, 2.4.0.
With MongoDB 2.4, there will also be the ability to use Kerberos for authentication, however, this delegated authentication will only be available in the Enterprise builds, which require a Commercial Support contract for us.
There is currently nothing within MongoDB that enforces password complexity but obviously in 2.4 with Kerberos, the KDC can do this. You will manually have to ensure (through your internal password policy etc) that users realise the issues of using non-complex passwords and re-using the same passwords on multiple devices. Assuming you are running 2.2, all logins, passwords and permissions for MongoDB access are stored in the system.users collection under each database. Here is the exact link to the documentation that you should read.
I have created a webpart which works fantastic on my Virtual Machine where I have developed it.
But When I try to run the same webpart on my physical Machine, I cannot open the SQL Connection as the SQL Server is Seperate box on the network.
My Physical, Virtual and SQL Box are on the Same network but for some reason, It doesn't work on my Physical Machine,
It Come up with the following Message: Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'
What causes this Issue?
You are using Intgrated Security, which means the current User is used for authentication against the database service. On the production server the webpart code is executed, using the anonymous user. And (of course) this user has no right to access any ressources other the web server files.
To avoid this behaviour use a dedicated account using SQL-Server security. See this example Connection string:
connectionString="Data Source=SERVERHOSTNAME;Initial Catalog=YOURDATABASE;Persist Security Info=True;User ID=YOURUSER;Password=YOURPASSWORD";
Be sure to get a valid logon from your production database administrator for your database with appropriate rights (such as db_reader).
You specified User Id and Password and then set Trusted_Connection to True, so I guess that integrated authentication is used - remove the Trusted_Connection=True part.
In response to a question I asked about a week ago I changed our database engine to only accept Windows Authentication instead of SQL Authentication. Because our code runs in a different user context then that of the database connection we need to specify the username and password information in order for us to connect to the database. How do we do this using a ConnectionString? Remember, we are not using SQL Authentication anymore.
Thanks,
On your SQL Server instance, you need to add the domain group under the Security node (the one in the main server group, not in the individual databases). Under that node, the end result would be an item that resembles
<Your Domain>\Domain Users
Then in your application (Windows or Web) connection strings you want to set integrated security to be TRUE, and elsewhere, you need to set Impersonation to also be True. I am being vague here because the methods vary by application type.
Hopefully that sets you on the correct path.
Since you are using only Windows authentication, you can't in the connection string. The calling process will need to impersonate a windows principle (user) with the relevant access permissions.
Good morning everyone,
I'm running into an issue using a SharePoint workflow project (C#,
VS 2008) and connecting to a database. Here is my database connection
string:
Data Source=DBSERVER;Initial Catalog=DBNAME;Integrated Security=True;
When I attempt to run the following code I get the following error ...
SqlConnection dbEngine = new SqlConnection(Constants.DBCONNECTION_STRING);
dbEngine.Open();
"Login failed for user 'DOMAIN\MACHINE_NAME$'"
What I need it to do is pass through the logged in user's credentials.
I've got impersonation turned on but it doesn't seem to be passing
through. Any suggestions would be very much appreciated.
Thank you in advance for any advice,
Scott Vercuski
Any DB access should run as a Windows Service account for security and connection pooling reasons.
Regarding the Workflow Security Context, see:
SharePoint, Workflows and Security
http://cglessner.blogspot.com/2008/09/sharepoint-workflows-and-security.html
Declarative Workflows and User Context http://blogs.msdn.com/sharepointdesigner/archive/2008/09/28/declarative-workflows-and-user-context.aspx
Security and Application Development in SharePoint: First Steps
Workflow
http://www.microsoft.com/technet/community/columns/secmvp/sv0408.mspx#EACAC
Are the web front end and the SQL server on the same box ?
If not, you'll have to set up Kerberos to allow credentials propagation.
You cannot do that - the workflow does not run in the context of a user. Workflows are executed asynchronuously. Only (HTTP) WebPage-Requests run in the context of the user (if you turn on impersonation). You cannot flow the impersonation to the workflow. To restore impersonation in the workflow (which you should not do) would require username AND password OR protocol transition (process would need to run under system then).
Additionally, your application has a serious design issue if you try to access the db from an impersonated user context. That messes up connection pooling and will seriously hurt performance. That is generally a no-go.
This is not a kerberos issue. The process tries to access the db as the machine account, which tells you the process is running as either network service or (win 2008 and later) system.