Environment : Oracle 12C
In SQL Server, a credential is a record that contains the authentication information (credentials) required to connect to a resource outside SQL Server. This information is used internally by SQL Server. Most credentials contain a Windows user name and password.Here is Microsoft doc about Credentials in SQL Server .In SQL Server, the default is to use the service account credentials to access the resource outside SQL Server.
What is the SQL Server credential equivalent in Oracle ?
There is no direct equivalence as it depends on the resource.
For database links (which are equivalent to SQL Server linked servers), credentials are not stored as a separate object but are considered as part of the database link itself.
For local external jobs, remote external jobs, and remote database used by DBMS_SCHEDULER jobs, you need to use DBMS_CREDENTIAL.CREATE_CREDENTIAL procedure. External procedures are also using DBMS_CREDENTIAL.CREATE_CREDENTIAL.
The view DBA_CREDENTIALS can be used for DBMS_SCHEDULER jobs and external procedures but not for database links.
There may be other resources that are using credentials in a different way.
Related
I have stored SQL server credentials(like username, password) in the secrets of azure keyvault.
For this, I have created keyvault connector(Get secrets) and SQL server connector(Execute query).
But as per requirement I need to add the dynamic SQL server connector who will fetch the SQL server credentials from secrets and try to login.
So is there any way to make SQL server connector dynamic.
No, this is not possible. Azure stores the service (in this case a SQL database) credentials and connection information in an API Connection resource and this is currently the only way that these actions can work.
As an alternative, you could use Azure Functions to connect to the database, which have many of the same triggering patterns available and allow you to write any code you need (within reason) to acquire secrets through whatever mechanism is most suitable.
I need to lock down access to a linked server object in MSSQL server.
I am building views on a host database, from which, I query to populate a staging table on my warehouse server. I am using Data Tools/SSIS to extract the view data. To simplify the SSIS package, I am using the OPENQUERYsyntax to query the linked server object that exists on my warehouse server, and connects to other SQL servers, Oracle servers, etc., through linked server objects.
To provide access to the linked servers, I have set up a local SQL login on the host db that has read access, then I use 'Be made using this security context:' and pass the local SQL login. That works just fine.
I realize now that I have a problem: any user with warehouse access can query the linked server object because of that stashed security context! I don't want that! I do need folks who should have access to be able to query (so I can write my SSIS packages), as well as the SQL Server Agent service account to have access so when the SQL Server Agent job runs as that user that it can successfully query the linked server.
I believe that the key to locking down query access to the linked server object is somewhere in the 'Local server login to remote server login mappings', but I'm having a hard time figuring that out. When I try to add for instance NT SERVICE\SQLAgent mapped to the local login with access, then save, I hit 'Login failed for 'NT AUTHORITY\ANONYMOUS LOGON' when saving.
Any ideas on how I can allow a security groups that have access, and SQL Server Agent service account to query the linked server, but not the rest of people with warehouse access?
This is known as the 'double hop' problem
(https://blogs.technet.microsoft.com/askds/2008/06/13/understanding-kerberos-double-hop/)
and to get rid of the Anonymous login error you would have to properly set up Kerberos pass-through authentication;
https://blogs.msdn.microsoft.com/farukcelik/2008/01/02/how-to-set-up-a-kerberos-authentication-scenario-with-sql-server-linked-servers/
https://www.databasejournal.com/features/mssql/article.php/3696506/Setting-Up-Delegation-for-Linked-Servers.htm
However this is quite involved - you mention that to 'simplify' the SSIS package you use a linked server, however SSIS solves exactly this problem... Why don't you just use SSIS to copy the data from the other server to avoid using a linked server?
There's a file stored in SharePoint that I want to use as data source in my SSIS package that will be run by SQL Server Agent.
The SQL Server Agent uses an account that doesn't have access to this file, so I want the Excel connection to use different login credentials (you can specify them in OLEDB connections). Is there any way to do this?
I know that the simplest way would be to just grant the permissions to the account that SQL Server Agent uses, but our responsible person is away. Changing the credentials in SQL Server Configuration Manager is not an option.
MS SQL Server 2008R2, Server Integration Services Version 10.50.1600.1, Sharepoint2010,
You can set up a proxy account that has the appropriate permissions to the location of the excel file and then set the job to run as that proxy account.
https://technet.microsoft.com/en-us/library/ms190698%28v=sql.105%29.aspx?f=255&MSPPError=-2147217396
I have a server (2008R2) that has little Access (2010) databases relevant to departments and their needs. I have a new EHR server (2008R2) running SQL (2008R2) servers and am able to establish an ODBC connection between the two. I created the ODBC using the SA / SA password to the SQL Server.
As an administrator, I can log in to the Access database and run queries and reports based off of tables linked back to the SQL DB. No one else can. I did save the password when I created the External table link in Access. My Sys Admin - also Administrator, cannot run queries or reports logged into the Access database server for this DB.
On this particular SQL Server, I am not an admin under my login. I have to use the SA account to login to the backend or through the Management Console.
I need to have the EHR managers run their own reports. Does anyone have any experience with why the ODBC would not be allowing a connection for anyone but me when the connection is server based?
What Gord Thompson said is important. Access is not a database server and its engine runs on the client machine which will need copies of whatever DSNs are used.
But the problem of getting Access to 'remember' credentials is something I recall struggling with in Access 2000. My solution was to create a dummy pass-through query (anything that will run quickly) that stores the credentials. When a new client session starts, first call the dummy query and for the duration of their connection, they'll have access to the DSN in question.
I'm trying to get data from another database using the OPENDATASOURCE command, but I get an error about DisallowAdHocAccess.
The SQL Server version is 2008 Express Edition, running on a remote site.
OPENROWSET can be used to access remote data from OLE DB data sources
only if the DisallowAdhocAccess registry option is explicitly set to
0. When this option is not set, the default behavior does not allow ad
hoc access.
HOW TO: Use the DisallowAdHocAccess Setting to Control Access to Linked Servers
Accessing External Data
An ad hoc name is used for infrequent queries against OLE DB data
sources that are not defined as linked servers. In SQL Server, the
OPENROWSET and OPENDATASOURCE functions provide connection information
for accessing data from OLE DB data sources. By default, ad hoc
names are not supported. The DisallowAdhocAccess provider option must
be set to 0 and the Ad Hoc Distributed Queries advanced configuration
option must be enabled.
Security Note
Enabling the use of ad hoc names means that any authenticated login to
SQL Server can access the provider. SQL Server administrators should
enable this feature only for highly trusted providers that are safe to
be accessed by any local login.
OPENROWSET and OPENDATASOURCE should be used only to reference OLE DB
data sources that are accessed infrequently. For any data sources that
will be accessed more than several times, define a linked server.
Neither OPENDATASOURCE nor OPENROWSET provide all the functionality of
linked server definitions. This includes security management and the
ability to query catalog information. Every time that these functions
are called, all connection information, including passwords, must be
provided.