New answers tagged security
This is really more of an AD question than a SQL question, but... Whom is the application running as, and what are you trying to do? By specifying that DOMAIN\computername$ has full permissions, you're implying that LocalSystem (NT Authority\System) or NetworkService is the account that will be running that process. ...
Can tell you solution I came up with in situation like yours (its quite complicated, but still love it): I have database DB1 with Service Broker an DB2 where data has to be updated as well (I do have triggers in DB2 as well). I am using certificate to create server login + users in each db. I am signing procedures and triggers to Grant rights. You can read ...
I can't explain precisely why you can't get server-level permissions for a database-level principal while impersonating them inside the database, but I can't say I'd ever expect that to work anyway. Especially since you are expecting a special database principal (dbo) to have server-level permissions associated with them. I think there are a couple of points ...
To give a user rights to work with SSRS they need to have permissions at the root folder (which is what it sounds like you have done), but you also have to go into the "site settings" link into the "security" tab and add the user as (at minimum) a system user. It is easy to do one, but not the other. Both are required to allow full access to the system.
Whilst liasing with Microsoft on a different issue (paid support request) i happened to ask them about this & they confirmed the unhashed password is passed to the remote server but the mechanism in which the SQL Engine does this is "hidden and cannot be captured" - but suffice to say, the login is not done using the hash. Here is there full response: ...
This means that database users have no matching server logins. That is, each database sys.database_principals has no match in sys.server_principals For Windows logins this is easy. This generates your missing CREATE LOGINS USE MyDB SELECT 'CREATE LOGIN ' + QUOTENAME(SUSER_SNAME(sid)) + ' FROM WINDOWS' FROM sys.database_principals DP WHERE ...
In my view Windows Authentication is still more secure. Just. With windows authentication you can allow a group of people (via a Windows Group) to have access to the database. Only those users can use an application, any application, to connect to the database. If you use a SQL Server account then anyone who knows the credentials (and invariably these ...
Both options should work. The article you referrenced should deal with this exact scenario, but if the login is present for you to delete and re-add then go with that route. It is quicker and easier by far.
No, there is no reliable way to prevent the local administrator (or a domain admin with the ability to grant themselves local admin on a machine) from accessing the raw PostgreSQL data files, starting/stopping the server, changing the service account password, changing pg_hba.conf so they can log in to the server, etc. As stated in the comments, if you ...
There's no native way to do this. You'll have to create a SQL Agent job which disabled the login and the specific time.
You could setup a job that reads from a table containing a list of logins and their expiration dates. For every login that is expired in this table it could just drop it. There you could also automatically deal with users associated with and databases own by this login.
Create a temp table on the local server, load the results of the query into the temp table and execute the sp_send_dbmail @query on the temp table. Edit: Sorry, this is not a solution to get the sp_send_dbmail function to work across the linked servers but could provide a work around.
DB mail is processed by an external service: DatabaseMail90.exe. This service connects to the engine using the DOMAIN\SQL credential. This context executes the query specified in your sp_send_dbmail call. As such the linked server is not reached under the service account, but under an impersonation context of the application connected (DatabaseMail90.exe), ...
I do believe that the protocol allow the exchange of username and hashed password. This is probably used when connecting to linked server, but cannot be used when connecting from a third application. For sure, the database engine internally store username and hashed password only. This is also confirmed in ...
You have to give username password(non hashed) of remote server when setting up the linked server. When giving non windows username, password should be same on both servers to work!
Top 50 recent answers are included