I have access to the apex admin but i could not recall the database name under which the apex url is running.
Is there any way to get the database name from apex url
If you have access to Apex Admin, I guess you also have access to (at least) one of workspaces. If not, you can always create one for you.
So:
pick any of those workspaces
connect as a developer
go to SQL Workshop's SQL Commands
run the following statements; at least one should work and reveal that information
select * from global_name;
select sys_context('USERENV', 'DB_NAME') from dual;
select name from V$database;
The apex url does not contain any information about the database name. Apex uses ORDS to map the http request to a database call and it is in the ORDS configuration file that that the database information is entered (hostname, port, service_name, username)
Related
I have .NET Core 2.1 web application which Identity authentication on and SQL Server 2017 database.
Every table in my database will contain a column (say: change_user) holding info about the user which inserted or last updated the record.
Suppose that user jsmith logins into the web app and clicks the button that deploys the stored proc which inserts a record into sometable table. So, the stored proc needs to set sometable.change_user columnn for that record.
Of course I could pass a param to the stored proc from C# level. I would prefer to handle that completely on server side and take the desired info from some session variable etc. Is such approach possible?
You cannot send the logged in user information to a stored proc without writing code, but you can make that code pretty simple.
Assume you have some service that is called by your controller. You define it as
Servicec(MyDbContext context, IHttpContextAccessor accessor)
Your dbcontext and the IHttpContext accessor are both registered in Startup as scoped services.
This in your service you can do
var userName = accessor.HttpContext.User.Identity.Name;
I think this is the easiest way to describe the process, but you can elaborate on it quite a bit. For example, you can inject the username into the DbContext and have it always add the username to entities that are being changed in an overloaded version of DbContext.SaveChangesAsync before you call base.ChangesAsync.
Our business has just changed Active Directories and the domain changed, from "YMS" to "YMSNET". So I used to be able to log in with "YMS\tkol" and I can now log in with "YMSNET\tkol" (these usernames and domains are faked for the purpose of example), but when I log in as that now, I can't actually expand any of the databases or look at any of the tables, I can just see a list of the database names. When I try to expand a database in the UI it says "This database is not accessible (Object Explorer)."
Now I have another user, called "sqluser", and I keep trying to use that user to log in as well by changing the Authentication Method to SQL Server Authentication rather than Windows Authentication. But I get Microsoft SQL Server, Error: 4064
Now I know this sqluser user exists and the password is correct, because I can authenticate to the server and successfully interact with the tables from an external process on a separate computer on the same network (node.js, package mssql). And I used the query on the accepted answer on this question, and found my sqluser is there, with roles db_accessadmin, db_ddladmin, db_owner. And yet it still won't let me log in with that user in the SQL Server Management Studio UI
How can I get this working again and log in with my sqluser account? Or add the appropriate permissions for my YMSNET\tkol account?
--- edit ---
My first idea is that, because I can log into the UI with YMSNET\tkol, but I can interact with the databases externally with sqluser, that there is some query or command I can run with sqluser that will add permissions for YMSNET\tkol so that that user can now look at all the databases and tables. I don't know which commands I'd run for that.
It can be because your account's default database is mapped to some another db which is not available for you, for instance, you have no permissions there, or that database not exists anymore etc.
Your organization DBA can fix it by:
ALTER LOGIN [sqluser] WITH DEFAULT_DATABASE = [rightDB]
Default db name can be checked by:
select default_database_name from sys.server_principals
where name = 'sqluser'
This property can be overridden by opening "Options" of SSMS connection window and specifying it explicitly:
As we all know that SSRS user can be created using Reporting Manager which can be accesses by the url given in Reporting Service configuration manager utility.
But, my requirement is to create a new SSRS user using a Query. I just want to know whether it is possible to do so or not. If yes, how?
something similar to this should work.
USE ReportServer
GO
IF NOT EXISTS (SELECT * FROM master.dbo.syslogins WHERE loginname = N'loginname')
CREATE LOGIN [loginname] FROM WINDOWS
GO
CREATE USER [loginname] FOR LOGIN [loginname]
GO
You can not create users using the Report Manager URL. The permission management/Role assignment only can be done through it.
Adding Login/User to [ReportServer] database does not mean that user can access the reports.
The Group or user name should be a Windows domain user or group account in this format: <domain>\<account>.
https://msdn.microsoft.com/en-us/library/ms156034.aspx?f=255&MSPPError=-2147217396
There is a way to achieve your requirement of checking users' access in a query. First, in Report Manager, give all users the "Browser" role (for example, "NT AUTHORITY\Authenticated Users"). Then, pass the current user of the report to your database query.
The current user of the report can be retrieved with report expression User!UserID. In my environment, this is returned in the form <DOMAIN>\<WINDOWS USER NAME>. See MSDN Built-in Globals and Users References (Report Builder and SSRS) for more info.
In SQL Server I have a many to many relationship between items and active directory groups. I want to build a query, that based on a supplied active directory user, I would be able to query for all items associated to an active directory group if the user is a member of the group.
I went down the road of using IS_Member, but that only works for the currently connected user. The stored procedure will be called by an asp.net web app, which currently connects with a specific sql user account. I don't think I can connect using integrated authentication and impersonation in the web app, because I don't beleive our infrastructure configuration will allow delegation from the user machine, through the web server, then to the db server (3 hop issue).
What can I do here?
Write a C# or VB.NET .exe that queries AD and populates a table in the database with all the users/groups and call it from a SQL job that you execute daily. Then just use the synched up table data to do the comparisons. This way you can avoid all the other complexity of trying to do it on the fly. Group membership doesn't change that often. Even if something changed in AD you can just manually run your "sync job" and things would be ok. You can use Windows.Identity() or whatever it is from ASP.NET to check the username.
The issue you describe is a classic double-hop scenario, which can be (eventually) resolved through the painstaking process known as Kerberos configuration. A lazier workaround would involve passing the credentials from the asp.net application as a variable to a SQL query on your database.
If the SQL Server has the LDAP Server configured as a linked server, you could rewrite your stored procedures to accept the user as an input variable and check to see if the user is a member of an AD group before proceeding. Consider incorporating OPENQUERY into your stored procedures as shown below:
CREATE PROCEDURE CheckAccess
#CurrentUser varchar(max)
AS
IF #CurrentUser IN
(
SELECT CN
FROM OPENQUERY(ADSI,'<LDAP://DC=Your,DC=DomainComponent,DC=com>;(&(CN=*)
(memberOf=CN=YourADGroupName,OU=Your,OU=OrganizationalUnit,OU=Name,DC=Your,DC=DomainComponent,DC=com));CN')
)
THEN
SELECT 'Authorized User'
ELSE
SELECT 'Unauthorized User'
END
If you can, consult with your LDAP admins to make sure you get the group's correct domainComponents and organizationalUnits to tweak the OPENQUERY. One drawback to this is that it can take a while to query your AD group, obviously depending on the size of membership. It can be a pain, but as long as your app can pass the user as a variable, you can leverage OPENQUERY or even query sys.database_principals to check their access.
My team has a service deployed internally, and part of this service is a list of client accounts stored in a sql table. SSRS is hosted on another server and we have integration jobs which [will eventually] pull these client accounts (along with additional info) from our 3 production environments to this SSRS database.
Also on this SSRS database, I’m creating a new table that will be a mapping of domain accounts and client accounts. I need this table so I can filter my report based on which client accounts the logged on user is allowed to see.
Pretty simple so far.
The next requirement of this is that I need to restrict access to the report itself. I understand I could normally use a security group to do this, but that would result in two separate locations to manage permissions for one resource and this is what I want to avoid.
The solution I’m looking into is to create a security extension to validate the logged in user against the database, allowing them access to the folder/report if they exist in the table. Once in, I can then use that same table again to filter their results.
What I’m not sure of is 1) if this is the best solution and 2) can I use a security extension for just MY portion of the site. There are many other users and reports on this site that I don’t deal with and don’t want to conflict with those.
Could you fill the DB table automatically from AD? Then you can use the standard windows security, but still only do the administration in Active Directory.
link text
You could set up an internal report parameter, called something like UserID, and set its default value to be the non-queried expression =User!UserID . (This user ID can be selected from the list of globals in the Edit Expression dialog.)
You could then add a cartesian/cross join to your users table in your query, with a selection condition based on your internal report parameter - eg. ...and UserTable.ID = #UserID . This would ensure that no records were returned if an unauthorised user was running the report.
Note that the User!UserID field will only return the user for interactively-run reports - in scheduled reports, this will be the account for the scheduling service.
Can't you restrict access to the report by using a security group (either in it's own folder or report level permissions). Use windows authentication in your datasource connection and filter you report retrieving your username using the sql function ORIGINAL_LOGIN?