So the consultant who created our MDS database has left but his account is still the system admin. I looked everywhere online on how to change the old admin and it suggested everywhere to do it through udpSecuritySetAdministrator stored procedure but the problem for me is that I cannot find the udpSecuritySetAdministrator in the MDS database. I looked everywhere in the database but it simply does not exist and I even created a new MDS database and stored procedure still does not exist. Any suggestions? Thanks!
EXECUTE [mdm].[udpSecuritySetAdministrator]
Related
I have a firebird database in a .fdb file, but the database do not have the SYSDBA user and I don't remember the credentials to login into the database. Are there any way that could reset the database credentials?
Like said by Mark, it is not that the database "does not have SYSDBA user" - databases in Firebird 2.x never have users - but that old trick was used to create SYSDBA named role in order to trigger names collision on login.
After scanning through 2007 Security presentation I have two suggestions for you.
You can try some tool that opens Firebird databases without using Firebird itself to learn what username can pull you out of the deadlock.
One such tool is Database Explorer in the IBExpert. Full IBExpert is paid for non-USSR states and free IBExpert Personal probably does not have the tool. But I hope the tool works in IBExpert Trial. Another tool is IBSurgeon FirstAID. And probably there are more tools featuring data extraction from corrupt databases. You only need to find and read one specific row.
The query to create the blocking role is given on the 23rd page of the presentation.
INSERT INTO RDB$ROLES(RDB$ROLE_NAME, RDB$OWNER_NAME)
VALUES (‘SYSDBA’, ‘LOCKSMITH’);
So you would have to look into the said table, find the row with the said role, and learn the username that has authority over that role (in the example it was LOCKSMITH).
After that you connect to any other database on the same server and you create the user with the name you learnt. Then you use that name to login into the problematic database and to DROP ROLE SYSDBA; COMMIT;.
You also can use Firebird Embedded. All server-coded security checks are bypassed in the Embedded edition of FB 2.x (but if DB designer added some ad hoc security checks in triggers - they will work). So you login into the problematic database using Firebird Embedded edition, any username and any password, and after that you drop the access blocking role.
In Firebird database doesn't contain password (until v3.0 as mentioned by #Arioch'The). The password is used only for server. Another words, you can copy database file from existed server to another (with known password) and open the database file.
Is it possible to edit firebird database, alter trigger without connecting to it, using raw .fdb file or .gbak?
Although with sufficient knowledge of the internal structure of Firebird it would be possible to edit the file directly, in practice that is not a viable way (and would be a great way to corrupt your database).
Users with admin rights can disable firing database triggers on connect for a connection, see also Database Triggers.
For example when you use ISQL, you can start it with isql -nodbtriggers. This only works with SYSDBA, or if you have the RDB$ADMIN role and if you specify that role on connect.
I'm trying to deploy Mantis BT on Heroku, using PostgreSQL as the database, as a proof of concept and learning exercise (or perhaps more accurately, as a "climb up a steep learning curve," since I'm a total newbie to all three technologies).
The deploy of the PHP app to Heroku went fine, and accessing the app's URL brings up its admin/install.php page. Provisioning the PostgreSQL database went fine, and gave me a database URL that (obfuscated) looks like this:
postgres://useruseruser:passwordpasswordpassword#ec2-107-21-219-201.compute-1.amazonaws.com:5432/dbnamedbname
I'm able to access the database via psql using those credentials, and the user (predictably) doesn't have the 'usecreatedb' privilege. I can't really make sense of the output of the PostgreSQL \z command, which seems to say I have no privileges on a table I've created:
dbnamedbname=> \z foo;
Access privileges
Schema | Name | Type | Access privileges | Column access privileges
--------+------+-------+-------------------+--------------------------
public | foo | table | |
(1 row)
but I put that impression down to not really knowing PostgreSQL's idioms yet.
Empirically I've been able to determine that I have the privileges CREATE (for both tables & indexes), SELECT, INSERT, UPDATE, DELETE, ALTER and DROP, which seem to be what Mantis BT requires for its "high-privileged database account."
So, it would seem that I have everything I need to fill in the Mantis BT admin/install.php form:
Hostname: ec2-107-21-219-201.compute-1.amazonaws.com
Username: useruseruser
Password: passwordpasswordpassword
Database: dbnamedbname
Admin Username: useruseruser
Admin Password: passwordpasswordpassword
Two notes here:
Yes, I know the regular DB user should not have all the privileges the Admin user has, but Heroku has only given me one DB username, and (because this is for now just a proof of concept) I didn't want to start down a possible blind alley of trying -- and failing -- to create a second user just yet.
The Mantis BT form says that the Admin username and password are "to create Database if required." Since the database ("dbnamedbname") already exists, I initially thought I could leave these blank, but Mantis BT insists on having values for them (and the install documentation says that if they are not supplied, "the database user will be used").
Yet, when I fill in the form using the values above and click the "Install/Upgrade Database" button, I get a failure indicating that the app could not connect to the database with the credentials provided (the exact same credentials, BTW, that I used to connect to the database using psql):
(One suspicious thing in the above screenshot -- that I haven't yet steeled myself to go hunting for in the code: the obscured Admin password in the page returned by the form submission only shows six bullets, whereas the actual password I pasted was 30 characters long.)
So, questions to anyone who understands how Mantis BT database setup works.
Is it actually passing only six characters worth of password to the DB server, or is that just a UI glitch?
Even after I figure out why it's not connecting to the database -- if that's really true -- is the notation "to create Database if required" (on the Admin username and password entries) really significant? Or will the silly thing go and try to create the database even though the specified database already exists?
If the answer to 2 above is "Yes, it will try to create the database anyway," what's the recommended way to work around that, given how Heroku goes about provisioning PostgreSQL databases?
The "Database connection failed" results from an initial connection attempt in which no database name is specified.
Attempting to access the server in this way from psql causes the following error:
$ psql -h ec2-107-21-219-102.compute-1.amazonaws.com -U useruseruser
Password for user useruseruser:
psql: FATAL: database "useruseruser" does not exist
Adding the database name as an additional parameter to that Connect() call causes the connection attempt to succeed, and thereafter all table creation steps and checks succeed.
It's not clear to me whether the problem is with PostgreSQL 9.4.5 per se, or whether it's something in how Heroku in particular configures their PostgreSQL servers.
Issue filed: https://www.mantisbt.org/bugs/view.php?id=20589
So, with the code patched, the answers to the questions I asked are:
It passes all parameters as entered, no truncations.
It doesn't attempt to create the database if it already exists.
N/A: Mantis does the right thing.
As a bonus answer, it's apparently not possible to create a lower-privileged user in a Heroku-provisioned PostgreSQL database -- you're stuck with the one user they give you. Which kinda sucks.
I created a Firebird database by an account other than sysdba. If I put a copy of this db to another machine, I can open it by sysdba account and the 'masterkey' password. Thus this is real risk if some one can take a copy of it.
Is there some way to prevent this scenario?
The user that created a database is "just" the owner of the database, the sysdba user is administrator and is allowed to do anything to all databases on a Firebird server. This is a very good reason to never use masterkey as your password on a production server.
The usernames and passwords in Firebird 2.5 and earlier are stored in a security database (security2.fdb) that is part of the Firebird installation. So moving a database to another server (or replacing the security2.fdb) will allow "unauthorized" persons to access the database. Note that I put unauthorized in quotes here, because if a person has direct file access so they are able to make a copy of the database, or replace the security2.fdb, they have sufficient authorization on your server to do anything they want (or the security of your system has been breached).
In Firebird 3, it will be possible to store users in the database itself, but this still requires server-side configuration, so - as far as I know - this will not restrict much in this scenario. Firebird 3 will also provide support for database encryption which could allow you to only give access on a specific server, or with users that provide a specific key. Unfortunately Firebird 3 only provides the API, but not the encryption. That is left to users or library providers to implement.
There is also a trick to create a role with the name SYSDBA in your database which will prevent a user with username sysdba to connect to the database. But this is easy to circumvent by using a hex editor and some knowledge of the internal structure of a Firebird database to undo this. If the person really wants access to your data, they can also just compile a Firebird server that skips or ignores authentication.
All in all, this means that if someone has direct access to the database file, then they can create a copy and open it on another Firebird install one way or another. So the only real way to protect a database file is to make sure that users can only access the database through the Firebird server, don't have direct access to the database files and - except admins - are not able to create a backup of the database.
Even if users only have access through the server, they can still make a logical copy of the entire database structure, and all data they are allowed to access.
Consider reading Firebird File and Metadata Security
SQL 2008 R2
The below is all being performed within SSMS
I have a Db that sat on a Dev server quite happily and everything ran peachy as sysadmin with sql authentication account.
This code has been migrated to a test box where a reduced permission set exists on the dbo schema, where users have been allocated read/write and execute on the schema through Windows authentication.
Here's where the fun starts, when I run certain stored proc's they show as succesful but error logging on the procedure advised that it cannot see certain tables or it does not have the appropriate permissions to do so.
Oddly though despite all the tables currently sit on the same schema, the same issue is not seen on all others tables.
If I elivate the permission to Db Owner, then the issue disappears completely.
Has anyone else come across this issue before and if so how did you get around it?