Passwordless authentication within SAS pass-through statements? - authentication

Thanks to SAS's Personal Login Manager, the initial connection to the remote server works without password (or password hash). However, it seems to be necessary to specify the passwords of the individual databases (user xxuser password xxpwd, see example below).
Is there a way connecting to different databases on a database server without password (hash) in the SAS code?
/* Connect to database server works without password
thanks to SAS's Personal Login Manager */
%dosignon(srvcomponent=xxxremoteSAS);
/* SQL direct pass-through to server */
rsubmit;
/* Define SAS-libraries (on server) */
libname remote_db_a db2 dsn=dbxa schema=xxschema1 user=xxuser password= "xxpwd";
libname remote_db_b db2 dsn=dbxa schema=xxschema2 user=xxuser password= "xxpwd";
endrsubmit;
/* Link local library names with the ones the server */
libname remote_db_a a libref=remote_db_a server=&sessid.;
libname remote_db_b a libref=remote_db_b server=&sessid.;
A work-around is to encode the password string with proc pwencode in="plaintextPassword"; run; and to use this hash instead of xxpwd in the soruce code. A potential attacker can now no longer use the password to access other accounts, but of course can still access any database.
PS: I am new to SAS, so the SAS documentation looks like a book with seven seals to me. I asked various SAS experts, but I am not satisfied with the password-hashing suggestion.
Related questions and answers:
SAS SQL Pass Through
ODBC Password Security in SAS

I am not an expert on how SAS Metadata Manager manages access credentials, but as long as the "remote" SAS session also uses Metadata Manager then you should be able to use it to make your connections.
Here is a blog post about the Personal Login Manager you mentioned.
https://platformadmin.com/blogs/paul/2010/11/sas-personal-login-manager/
At the end of the discussion there is an example of how to create a libref using the metadata manager to supply the credentials
From a user perspective to use the (outbound login) credentials to get
access to third party systems look for authentication domain support
in the SAS feature you are using. For example SAS/ACCESS AUTHDOMAIN=
LIBNAME Option.
https://documentation.sas.com/?cdcId=pgmsascdc&cdcVersion=9.4_3.4&docsetId=acreldb&docsetTarget=n0aiq25zc8u8u6n1i81my0a24sd3.htm&locale=en
Example from that page:
options metauser="metadata-userid" metapass="metadata-password"
metaport=8561 metaprotocol=bridge
metarepository="metadata-repository"
metaserver="server-name";
libname A1 saphana server=mysrv1 port=30015 authodomain="hanaauth";

Related

Is there any way i can create SQL connection string without passing password

Hi I'm new to this and want to know if i can create a connection without passing password in connection string.
I can't use windows authentication because most of users don't have access to database.
$ConnectionString="Data Source=$SqlServer;Initial Catalog=$Database; Integrated Security=True;"
So have to go with SQL Authentication
$connString = "Data Source=$SqlServer;Database=$Database;User ID=$SqlAuthLogin;Password=$SqlAuthPw"
But not to pass password in connection string . Is it possible by any way.
If not then also let me know.
Any help will be thankfull.
SQL does not allow anonymous access. You can create a SQL user with only read permissions to information that you want. The only risk there is that a user could change the password but for a small internal project the risk would probably be acceptable.

Issue while creating a user in azure SQL server

In my application I need to create a user with the email id in the azure Sql server. Eg:
The email id is: xxxx#gmail.com
create user xxxx#gmail.com with password '123131'
The user gets created but when I try to login with that user a message is shown.
Cannot open server "gmail.com" requested by the login. The login failed Click here
The issue is with #. If I change it with some other character it works. Is there any alternative because I need to create user with the email id.
Any help would be greatly appreciated.
SSMS recognize #gmail.com as server name here, and the workaround is simple: Assuming your SQL database server name is testserver.database.windows.net and you have a user username#gmail.com, in SSMS you should specify the username as username#gmail.com#testserver and that would work. This should also applies to JDBC and ODBC connections as well.

SQL Servers: Linked-servers without linking servers?

Both my local (and remote) SQL SERVER 2005 administrators claim that "allowing linked-servers is a security issue" and forbid their use here. (Huh?)
Anyway, is there a way to do something similar WITHOUT linked-servers?
SELECT *
FROM LOCAL_SERVER.MyDatabase.dbo.MyTable AS t1
INNER JOIN REMOTE_SERVER.MyDatabase.dbo.MyTable AS t2
ON t1.MyField = t2.MyField
You could use OPENROWSET, which'll require the connection info, username & password...
While I understand that the administrator believes that having an always-on connection to their data is risky, that's why you lock down the account. OPENROWSET means including the connection info in plain text.
yes you can use OPENDATASOURCE but ad-hoc queries have to be enabled
Opendatasource: Provides ad hoc connection information as part of a four-part object name without using a linked server name.

SQL Profiler 2008 - Shows Passwords

I have just noticed that Sql Profiler 2008 is not hiding trace outputs that include sp params called password. In 2005 it used to give me a message saying "The text has been replaced with this comment for security reasons".
Has they removed this security feature?
There is a difference between trapping the string "password" and genuine security holes.
Try this:
CREATE LOGIN foo WITH PASSWORD = 'bar'
In SQL 2005 profiler:
--*CREATE LOGIN-----------------------
Security is maintained.
Now, if you're sending dynamic SQL to a password columns...
But if you pass your passwords as parameters, it should display it. The solution should be storing passwords encrypted at database. By this solution you'll need to pass your passwords encrypted.
Yes, it did use to automatically filter out "password" in Profiler, I believe this was a feature added in maybe in SQL Server 2000 SP4 but I've seen a number of people wanting to switch this off as it was filtering out instances that they actually wanted to see. So whether MS have removed it/made that functionality switchable I'm not sure - can't seem to find anything on it for 2008 atm.
Edit: I can't find any information on this regarding 2008. Everything I can find relates to people wanting to do the opposite - in sql 2000/2005, switch that "feature" off, for which the solution has been to replace use of "password" parameter with an alternative name like "pwd".

How to determine an Oracle query without access to source code?

We have a system with an Oracle backend to which we have access (though possibly not administrative access) and a front end to which we do not have the source code. The database is quite large and not easily understood - we have no documentation. I'm also not particularly knowledgable about Oracle in general.
One aspect of the front end queries the database for a particular set of data and displays it. We have a need to determine what query is being made so that we can replicate and automate it without the front end (e.g. by generating a csv file periodically).
What methods would you use to determine the SQL required to retrieve this set of data?
Currently I'm leaning towards the use of an EeePC, Wireshark and a hub (installing Wireshark on the client machines may not be possible), but I'm curious to hear any other ideas and whether anyone can think of any pitfalls with this particular approach.
Clearly there are many methods. The one that I find easiest is:
(1) Connect to the database as SYS or SYSTEM
(2) Query V$SESSION to identify the database session you are interested in.
Record the SID and SERIAL# values.
(3) Execute the following commands to activate tracing for the session:
exec sys.dbms_system.set_bool_param_in_session( *sid*, *serial#*, 'timed_statistics', true )
exec sys.dbms_system.set_int_param_in_session( *sid*, *serial#*, 'max_dump_file_size', 2000000000 )
exec sys.dbms_system.set_ev( *sid*, *serial#*, 10046, 5, '' )
(4) Perform some actions in the client app
(5) Either terminate the database session (e.g. by closing the client) or deactivate tracing ( exec sys.dbms_system.set_ev( sid, serial#, 10046, 0, '' ) )
(6) Locate the udump folder on the database server. There will be a trace file for the database session showing the statements executed and the bind values used in each execution.
This method does not require any access to the client machine, which could be a benefit. It does require access to the database server, which may be problematic if you're not the DBA and they don't let you onto the machine. Also, identifying the proper session to trace can be difficult if you have many clients or if the client application opens more than one session.
Start with querying Oracle system views like V$SQL, v$sqlarea and
v$sqltext.
Which version of Oracle? If it is 10+ and if you have administrative access (sysdba), then you can relatively easy find executed queries through Oracle enterprise manager.
For older versions, you'll need access to views that tuinstoel mentioned in his answer.
Same data you can get through TOAD for oracle which is quite capable piece of software, but expensive.
Wireshark is indeed a good idea, it has Oracle support and nicely displays the whole conversation.
A packet sniffer like Wireshark is especially interesting if you don't have admin' access to the database server but you have access to the network (for instance because there is port mirroring on the Ethernet switch).
I have used these instructions successfully several times:
http://www.orafaq.com/wiki/SQL_Trace#Tracing_a_SQL_session
"though possibly not administrative access". Someone should have administrative access, probably whoever is responsible for backups. At the very least, I expect you'd have a user with root/Administrator access to the machine on which the oracle database is running. Administrator should be able to login with a
"SQLPLUS / AS SYSDBA" syntax which will give full access (which can be quite dangerous). root could 'su' to the oracle user and do the same.
If you really can't get admin access then as an alternative to wireshark, if your front-end connects to the database through an Oracle client, look for the file sqlnet.ora. You can set trace_level_client, trace_file_client and trace_directory_client and get it to log the Oracle network traffic between the client and database server.
However it is possible that the client will call a stored procedure and retrieve the data as output parameters or a ref cursor, which means you may not see the query being executed through that mechanism. If so, you will need admin access to the db server, and trace as per Dave Costa's answer
A quick and dirty way to do this, if you can catch the SQL statement(s) in the act, is to run this in SQL*Plus:-
set verify off lines 140 head on pagesize 300
column sql_text format a65
column username format a12
column osuser format a15
break on username on sid on osuser
select S.USERNAME, s.sid, s.osuser,sql_text
from v$sqltext_with_newlines t,V$SESSION s
where t.address =s.sql_address
and t.hash_value = s.sql_hash_value
order by s.sid,t.piece
/
You need access those v$ views for this to work. Generally that means connecting as system.