User management in MSSQL - sql-server

I'm trying to set up security for my application for users. I am not sure about my logic. Is the following possible:
I want to create 1 login for 'all users' in Active Directory. Then I want an admin (in the program self) to choose which user is in which server role (e.g. marketing, sales, ...). Then I want to give those roles permissions to the tables in the database.
Some questions about this:
Is this safe? The admin of the program has to be db owner?
Is it possible to list the users by name, instead of the login 'All users', the admin has to be able to place a user in a role after it is created in Ad.
I use the function SUSER_NAME(), will this return the current user or the groupname 'All Users'
If this isn't the right way to make security, please send me in the right direction.
Thanx!

Part of the best solution already lies in your desire to use the Active Directory to authenticate your users. Let it authorise your users as well. Marketing isn't just a database role that specifies access to your tables. It's a department of your company with file shares, mailing lists as well as a role to play in your application. Get your domain admin to make an AD group called Marketing and let them add and remove people as appropriate. Likewise for the Sales department and other departments who touch your database.
When that is done, add the MYDOMAIN\Marketing group as a login on your server and as a user in your database. It will behave more or less like the roles you've described so you can still go ahead and create the roles, add that domain group to the role and grant to the role or grant to that user directly since it identifies a group of people. This also gives you the chance to reconsider your role definitions. Are they really about Marketing people and Sales people or are they CustomerEditor, CustomerViewer, ProfitAndLossViewer roles?
User and group management is a standard function of AD administration; let them do what they do best. It probably doesn't need to feature too strongly in your solution unless you get very poor service from the domain admins, in which case, why use your AD to manage your users?
This very small change will probably free up a lot of your dev time and release you from reinventing a user management facility that already exists and is easy to use.
Good luck!

here's what i would do:
create two roles on the database, one users, one admin. then create two security groups in ad, SQL.App.Admin, SQL.App.Users (replace app with whatever your app name is). I would then assign those groups to the roles in the database. after that you can drop users and/or security groups into those two groups.

Related

Snowflake: Does anyone have any idea that how to create a snowflake organization to organize all the snowflake accounts

can anyone explain the complete process to create a snowflake organization account and the way to attach/detach account from it? I looked into the snowflake console as well as in documentation but have not gotten clarity
You should submit a ticket to Snowflake Support to enable organization on one of your accounts. This will create the ORGADMIN role in the account. Then you can grant this role to one of your users. The user which has the ORGADMIN role can access the Organization page. From the organization page, you can see your existing accounts, and create new accounts. When you create a new account, it will be in your organization automatically.
If you have an account which you can't see on the organization page, that means the account was created in another organization. In this case, you need to submit a ticket to Snowflake Support and ask them to move your account to your organization.
Normally, it's expected that each customer should have one organization, but if you have multiple organizations, you can also ask Snowflake Support to move your account from one organization to antother (that's how you would detach). If you want to drop an account, you should also contact Snowflake Support, it can't be done through the organization page.

Azure AD - Allow users to update their Job Title / Department

I have Azure AD Premium and O365 Enterprise License assigned for my users. Is it possible for me to allow the users to update their AD profile information, such as Job title, Department ?
Is it possible for me to allow the users to update their AD profile
information, such as Job title, Department ?
Yes, you could make this, you need to Assign roles to users. Because it requires a Global administrator or user administrator to add or update a user's profile information.
For the details, you could read this doc.

Logging in Oracle Application Express as a Database user

As a part of database security I have different access for every user(same as schema in Oracle). Now I want to add these users as Oracle Application Express(Apex) users.
When I try to create new users, APEX does not provide me the ability to have database users as APEX users itself.
Essentially I have three users - STUDENT,TEACHER AND UNIVERSITY.
UNIVERSITY has two table - STUDENT_INFO and TEACHER_INFO
STUDENT DB User is not allowed to view info of TEACHER_INFO and similarly TEACHER DB User is not allowed to view info of STUDENT_INFO.
I wanted to show this information through APEX rather than sqlplus. hence I need STUDENT User to login into the APEX and try to access UNIVERSITY.TEACHER_INFO and UNIVERSITY.STUDENT_INFO to show the difference. How can I add these users as APEX Users if I already have admin privileges to APEX.
First of, APEX users are not database users. Apex users are pseudo users that have schema grants by the Apex administration area.
I am assuming here that you are not trying to create an authentication scheme in Apex, totally different subject.
If you create a workspace in Apex that has access to all 3 schemas (which is no problem). You create a single admin (again pseudo apex user) with full control.
That admin can create other users inside the adminstration->users interface. There he can grant access to all, none or subset of the schemas. Define them as application users, developers (which you want, so they can log into apex) or admins (do not want)
I took this from the internet. Notice the accessible schemas field., There you define it.
As I understand, you want to get access to tables in SQL Workshop?
First you need to know, that oracle database users and oracle APEX users are different things. After creating APEX users you need to go to Administration and find there menu for managing workspaces. I have no APEX now besides account at apex.oracle.com (administration functions there restricted), and don't remember exact names of menus. You need to give that users access to workspace (if necessary), and after that define, which database SCHEMAs this workspace can use (it is also in workspace management section). It can use one SCHEMA by default and other SCHEMAs can be added later. After adding SHEMAs UNIVERSITY and STUDENT you will get access to their objects in SQL Workshop.
Link to documentation: https://docs.oracle.com/cd/B28359_01/appdev.111/b32258/adm_wrkspc.htm#BABDEBHA

How to securely store my CouchDB admin password?

I spent a long time yesterday to configure for my CouchDB instance in order to create a little app and letting CouchDB manage authentication and authorizations for me.
So I ended up with something like that :
On top of everything I've got a server admin, who basically is god on my CouchBD instance.
Then I created a database named "mydatabase" (for example) and added the role "mydatabase_dba" as admin and also the role "mydatabase_user" as reader.
I also created a database named "_users" which contains all the database admins and users with their roles and also a design document named "_auth" which manages authorizations.
Only the server admin is admin of this database, and I added users with role "mydatabase_dba" as readers. Then, for those of you who knows about it, I modified the "validate_doc_update" field o the "_auth" document so that users with role "mydatabase_dba" can only deals with users with role "mydatabase_user".
So, to summarize at this point :
server admin is still god
users with role "mydatabase_user" can connect to "mydatabase" but they are just readers
users with role "mydatabase_dba" are admins of "mydatabase"
users with role "mydatabase_dba" can connect to database "_users" where they are readers
users with role "mydatabase_dba" can only manage users of role "mydatabase_user" in "_users"
Hope this is clear :D
What I can do now is create an application that will not manage users itself, but let users connect to CouchDB directly (transparently).
The problem come when it deals with users creation/update/deletion.
Because only users with role "mydatabase_dba" can access to the "_users" database and work on users with roles "mydatabase_user", I need at some point to connect to CouchDB as this db admin.
I have two solutions :
Create a user interface into my app that will let the admin connect and do what he has to do
or
Make some more code and let the app do it automatically, this is the solution I prefer, but the problem is : I have to store the admin credentials...
Sorry for the long introduction but I had to describe the landscape first :)
I created a post yesterday about how I could secure the connection between my app and the CouchDB instance : here
The solution I was given is to use HTTP over SSL (/TLS) to secure the communication. I'm okay with that, but now I have another concern, maybe I'm paranoid, but because my app will need to connect as "mydatabase_dba", I have to store its credential somewhere.
But how to store them securely ? As said in my previous post, even if I store the hashed password instead of the plain text password, if an attacker access my app source code, he'll have my admin credentials...
An application should never have an administrative rights. It should only be given the bare minim rights it needs to function. If the application needs some administrative rights, make sure it has as few as possible. Other than that, most of the time these credentials are stored in plain text in some file that only your application can access.
Never commit this text file into your source code manager (Subversion, Git, etc.)! Placing the file into a running system must be a step in the installation procedure.

SQL Server 2005 Security

Here is the scenario. I have a SQL Server 2005 production database/server. It currently has developers and supporters who can connect to it. I need to create a security module that gives developers read-only access to all areas of the database. This means that a developer should be able to view all objects as well as scheduled activities/jobs only.
Is it possible to enable security in this way and if so can I be gently guided on how to achieve this. I am learning to be a DBA and creating snapshots of the databases are not an option.
Thank you all in advance.
There is permission to every object.
Create a stored procedure that grant each gruop the exact permission you need on the objects you need to protect.
I'm not quite sure I follow where this "security module" will be in the architecture. Anyhow, here's one possibility that secures it from the database end.
I'm going to assume you already have users created.
Create a new role (yourdb > security > roles > new database role), say "ReadOnlyDevelopers". Make the owner dbo or whatever makes sense. Do not select any schemas to be owned by the role. Populate the "Role Members" with your developers.
Next, open the properties page on your database. Go to the permissions page. Click Add... and add the new role. Under the permissions grid at the bottom, Grant SELECT to the role.
Now assuming your developers already belong to some other role, you'll need to go into the user properties and under Database Role Membership restrict them to just the new role. At this point they should be able to just read
I'm guessing that I'm missing a detail or two (the role may need to be grated a few additional rights to "see" the database, alter passwords, etc.) but I can't get to that level of detail without setting up the entire scenario. Hopefully this pushes you in the right direction.

Resources