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.
Related
I am getting below error while generating the SQL scripts using a web installer with Integrated security as true /Windows authentication mode on.
It works perfectly fine with SQL authentication mode.
The server principal "DOMAIN\MACHINENAME$" is not able to access the database "" under the current security context.
Regards
Web Installer Issue -DB Issue -The server principal
“DOMAIN\MACHINENAME$” is not able to access the database
First, if you access a private database by your current account, you should make sure that your current account is under the domain.
Then, if you have web.config file in your project, add <identity impersonate="false" /> under <system.web>.
===================
If you use SQL Server,
1) login into it and check whether you can access the database's info. Or just change another
2) Go to SQL Server --> Security --> Logins and right click on NT AUTHORITY\NETWORK SERVICE and select Properties
In newly opened screen of Login Properties, go to the User Mapping tab. Then, on the User Mapping tab, select the desired database – especially the database for which this error message is displayed. On the lower screen, check the role db_owner. Click OK.
=================
If use you SSMS,
Open SSMS --> Security --> Logins.
Right click NT AUTHORITY\NETWORK SERVICE and Click Properties.
Go to Status tab and set Permission to Connect To Database Engine To Grant.
==================
If you use IIS manager,
open IIS manager-->your application pool --> advanced setting-->set custom account under Identity menu-->then enter your domain user name(DOMAIN\USERNAME) and password.
Or you could just click Identity--> slectBuild-in Account and choose NetworkService.
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.
I building a console app that runs under a normal user account to access sharepoint lists programmatically. In order to access Sharepoint objects the console application impersonates the user under the context of which the Sharepoint is running. The impersonation is successful but when I try to access any share point SPWeb objects the following error is given as follows
spWeb.ID = 'spWeb.ID' threw an exception of type 'System.Data.SqlClient.SqlException'
base {System.Data.Common.DbException} = {"Cannot open database \"WSS_Content_92\" requested by the login. The login failed.\r\nLogin failed for user 'DOM\USER'."}
Doesnt the imepersonation should have allowed to access to the underlying database and also do i need to explicitly grant access to the current user to give access to sharepoint lists etc.
Thanks in advance
In a console or windows app when accessing the object model - when you are impersonating the user then the database connection will be made under the users account credentials - so in effect you will have to give each of your users fairly high level permissions to access the database (or better make them a member of a group that has these permissions).
http://technet.microsoft.com/en-us/library/cc721638(office.12).aspx
This is different to the web app where the account used is the AppDomain account of the IIS site.
However - this is a very non-standard setup and is fraught with security risks - do you really want to give your users permission to access that database directly?
Instead can I suggest that you look again at your design - what are you trying to achieve?
Running the console application in the context of the same user as the application pool did the trick. So the solution would be to use the runas command.
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.