I'm having around 2000 Inactive account on AD server.
For some reasons, we cannot remove these accounts out of system.
I'm not see any impact when leaving a huge amount of those inactivate account in our AD server except of slow loading and cannot show all users when we access to the UserOU folder.
So what I consider now is that if any impact to the performance of AD sever later on or any risk when leaving this much disabled accounts?
It should be no problem, but you might still to consider to delete them as described at https://serverfault.com/questions/64175/active-directory-delete-vs-disable-departed-employees
Note, keeping accounts might impact licensing (quote from above link)
that accounts in your AD require a "per-seat" license (if you are
swinging that way), whether or not they are a real person and whether
or not the person is still present. So there is an argument to be made
for deletion!
Related
We have a big system running with thousands of users (some from android apps, other from the web app, etc.).
The system is distributed, with databases in two locations (within the same country). In one location there are 5 servers in the same network, and each one has a copy of the database (via replication).
Among the software developers, a few have direct access to the production databases. Sometimes due to technical support requested by users to modify some operations not possible from the system itself, the developers/support team have to access the database directly and modify some records.
We know this is not the ideal manner of working. But it's been like this since years.
Recently we have found a few problems. One day one person updated hundreds of records from a table by mistake.
Since then we are analyzing how to improve this access.
We are looking for some way of improving the security. We would like to have a two-phase authentication system in place. Something that asks the user for two passwords when accessing from Sql Server Management Studio...
Is that possible? Or is there any other approach we can use to improve the security but still allow devs/support team to access the production database when necessary?
Users also (currenty) have access via remote desktop to all servers.
At least we would like to KNOW when this access is being done.
Make access to PROD read only for those users. Allow them to write their scripts and then submit them for review at a minimum and testing if possible like any other deployable. Then follow standard deployment processes with someone who has access.
If my other answer isn't workable and these updates are always the same kind of fixes...you could create support stored procs maybe to do the fixes and only give permission on the procs...but this is highly dependent on the commonality of fixes being made and less preferable to my other answer.
I haven't used it myself but EXECUTE AS might let you give the users read-only permission while the procs would execute under credentials with higher access.
Background: [No copyright implementation]
[No copyright implementation] My company develops inventory control application for clients in the area where we don't have copyright protection by the government. The only option is to hide and protect things by ourselves. It is common for competitors here to copy other company's database and build front end on it and then start selling their own app.
The Problem
We use MS SQL server express edition and some times standard edition. We have found that any of customer can stop sql engine, copy the files from the pc where application was installed and then attach that database files into another system where they have full windows admin rights and that's it they can fully explore our database.
I am looking for
Is there any reliable solution to protect our database design being viewed by other people. Only our application may connect through the users we have created inside the db?
In past i had heard that sybase adaptive server has such functionality, windows users had no access in it and users were stored inside each db itself. there was no way to login if someone don't have password of the users stored in db itself.
Thanks
Your help will be highly appreciated.
As suggested by Sean, hosting it yourself or in a cloud service like Azure SQL DB is your best bet. Still no guarantee but makes it significantly harder to get everything but a lot easier to lockdown than alternatives. It's also a lot easier to manage and handle user requests for restricted data compared to something deployed onsite.
Outside of that, there's really no practical way to do it if deployed at the customer's site. Even if you lock down all logins and users (regardless of Windows or SQL Server logins) so no customer login has admin level privileges, you still can't prevent them from copying the database file, mounting it on a different instance where they have admin privileges or even just running it as an app to reset SA password. If they have physical access, all bets are off. It's only a matter of knowledge and time.
You can make it harder by encrypting the entire database and only your app holds the key. Users then have to either break the encryption algorithm (hard if done right) or your application that holds the key (easier but still not trivial). Both are expensive to do correctly and they really just delay, not prevent access. You will also introduce other problems like key management and rotation which, if not done right can result in customers losing access to their data.
You could leave a cookie trail (e.g. functions and tables that are active,look like they're part of the app and are tightly coupled to useful parts of the app but actually aren't related to the application's core functionality). That makes it easier to prosecute later but if the country has no laws protecting intellectual property, this will only be useful if the software is re-used or resold in a country that has such laws.
This is a long question, but please bear with me as I believe it raises important issues about database ownership and access.
I manage and internationally market a "universal" geothermal data management program, written in Delphi, that is a front end to a SQL Server database. The data in the database is derived from many diverse measurements generated and used by the program users over time periods of 30 years or more - i.e. they "own" the data, and the database is primarily a way to efficiently store and manage the data.
Like all databases, the database structure needs to be modified from time to time, including new tables, and this modification is delivered by the release of a new version of the program. The program prompts for a database upgrade, which has to be carried out by a dbo user so that all new tables can be accessed by the other program users. Unfortunately, the program may be used in remote sites and the IT personnel may not be readily available, so that the new version may get installed but the databases are not upgraded. What has frequently happened in such locations is that a program user will upgrade the databases without appropriate SQL Server permissions, and then the other users cannot access the new tables and the program crashes.
One of the program customers has taken another approach. They have created a db_owner role for all the databases used by the program and then make all program users members of the db_owner role. The program has inbuilt permission levels that can restrict the ability to upgrade databases, so normally only one or two users have this permission. However, with everyone a member of the db_owner role, it doesn't matter who upgrades the database, all tables will be accessible to all program users.
The advantage of this approach include the following:
Access permissions can be granted by the group who uses the program, and who has ultimate responsibility for the database.
Knowledge and understanding of the program is passed on within the program users group when staff changes, rather than relying on the IT department as the repository of information on "how it works" (and often they do not know).
Direct data-mining and back-door data modification is possible to selected user experts. While the program has extensive datasearch and editing tools, sometimes these are not enough and the users need hands-on access.
The program users retain "ownership" of their data.
I would appreciate your comments. I believe that in circumstances such as these, it is important that all the database users are db_owners, and the group of users controls access. Not allowing db_owner roles (a strategy commonly employed by IT departments) fails to recognize the importance of data ownership and data accessibility, and the responsibility of the database users to manage their own data.
The way you've stated your question makes it sound like you've already arrived at a conclusion. The one question that I always ask when someone comes to me (a DBA) with this sort of situation is: if someone accidentally deletes data, am I on the hook to get it back? If the answer is "yes", then they don't get db_owner. If the answer is "no", then the db gets moved to its own server and I get the contract in writing.
The only time I wouldn't bother with access control would be with a simple app running on a local single-user database like SqlExpress. As soon as there are multiple users on a centralised database and important data to protect, restricted access is important. I'm not familiar with your domain (geothermal data management), but surely this data is important to your customers, from integrity, tampering and even a data access point of view (theft of data could be resold to a competitor).
the program may be used in remote sites and the IT personnel may not
be readily available, so that the new version may get installed but
the databases are not upgraded
(i.e. I'm assuming an upgrade script needs to be manually and independently run on the database). It is common nowadays for apps to check the database for schema versioning and even for static data population, e.g. Entity Framework code-first migrations on the .net stack. The app will then have the ability to actually perform the schema and data upgrade automatically. It should be quite straightforward for you to add the last N versions of your DB upgrade scripts into your app and then do a version check? (Obviously the app itself would need to prompt for dbo access, assuming that even the app should not have dbo access).
with everyone a member of the db_owner role, it doesn't matter who
upgrades the database
I believe this may place unnecessary responsibility (and power) in the hands of unqualified customer users.
Even the ad-hoc data mining (SELECT) access should be reconsidered, as a badly formed query without consideration can cause performance degradation or block other concurrent writers. If nothing else, providing a few well formed views will at least ensure decent query plans.
/10c
We have a requirement from a client to protect the database our application uses, even from their local administrators (Auditors just gave them that requirement).
In their requirement, protecting the data means that the Sql Server admin cannot read, nor modify sensitive data stored in tables.
We could do that with Encryption in Sql Server 2005, but that would interfere with our third party ORM, and it has other cons, like indexing, etc.
In Sql Server 2008 we could use TDE, but I understand that this solution doesn't protect against a user with Sql Server admin rights to query the database.
Is there any best practice or known solution to this problem?
This problem could be similar to the one of having an application hosted by a host provider, and you want to protect the data from the host admins.
We can use Sql Server 2005 or 2008.
This has been asked a lot in the last few weeks. The answers usually boil down to:
(
a) If you don't control the application you are doomed to trust the DBA
or
b) If you do control the application you can encrypt everything with a key only known to the application, and decrypt on the way out. It'll hurt performance a bit (or a lot) though, that's why TDE exists. A variant of this to prevent tampering is to use a cryptographic hash of the values in the column, checking them upon application access.
)
and
c) Do extensive auditing, so you can control what are your admins doing.
I might have salary information in my tables, and I don't want my trusted dba's to see.
Faced with the same problem we have narrowed are options to:
1- Encrypt outside SQLServer, before inserts and updates and decrypt after selects. ie: Using .net encryption.
Downside: You loose some indexing and searching capabilities, cannot use like and betweens.
2- Use third party tools (at io level) that block crud to the database unless a password is provided. ie: www.Blockkk.com
Downside: You will need to trust a third party tool installed in your server. It might not keep up with SQL Server patches, etc...
3- Use an Auditing Solution that will keep track of selects, inserts, deletes, etc... And will notify (by email or event log)if violations occurred. A sample violation could be a dba running a select on your Salaries table. then fire the dba and change everyone salaries.
Auditors always ask for this, like they ask for other things that can never be done.
What you need to do is put it into risk-mitigation terms and show what controls you do have (tracking when users are elevated to administrators, what they did and that they were de-elevated afterwards) instead of in absolutes.
I once had a boss ask for total system redundancy without defining what he meant or how much he was willing to pay and sacrifice.
I think the right solution would be to only allow trusted people be DBA's.
It is implicit in being DBA, that you have full access, so in my opinion, your auditor should demand that you have procedures for restricting who has DBA access.
That way you work with the system through processes in stead of working aginst the system (ie. sql server).
To have person you don't trust be DBA would be nuts...
If you don't want any people in the admin group on the server to be able to access the database, then remove the "BUILTIN\Administrators" user on the server.
However, make sure you have another user that is a sysadmin on the server!
another way i heard that a company has implemented but i haven't seen it is:
there's a government body which issues kind of timestamped certificate.
each db change is sent to async queue and is timestamped with this certificate and is stored off site. this way noone can delete anything without breaking the timestamp chain.
i don't know how exactly this works on a deeper level.
Working with an application that needs to provide row and column level security for user reports. The logic for the row filtering an column masking is in place, but there are still decisions to be made about identifying users at report execution time.
The application uses a single SQL Server login to authenticate, as all rights are data driven within the application itself. This mechanism does not carry well to reports, as clients like Crystal and MS Office do not authenticate through the application (web and WinForms).
The traditional approach of using SQL Server logins and database users will work will, but may have one issue. In some implementations of the application, the number of users who run reports and need to be uniquely identified may run into the hundreds.
Are there any practical limits to the number of logins or users on a SQL Server database (v 2005+) where this approach may cause problems? Administration of the users on the database server can be automated by the application, but the potential number of credentials may be a concern.
We have looked into user impersonation techniques, but they become difficult to implement when a report client such as Excel authenticates directly to the server.
Edit: The concern is not concurrency or workload, but rather administration issues on remote instances where a local DBA is not available, especially when the server is not dedicated to the application. Interested in scenarios where the numbers of logins were problematic.
I've used your described approach (SQL Server accounts managed automatically by our application) and we didn't have any trouble. However, we only ever had a maximum of perhaps 200 SQL accounts. But we didn't experience any kind of administrative overhead except when "power users" restored databases without telling us, causing the SQL login account to become out of synch with the database*.
I think your approach is sound.
EDIT: Our solution for this was a proc that simply ran through the user accounts and called our procs that deleted/created the user accounts. When the power users called this proc all was well, and it was reasonably fast.