For history, I just recently wrote this question:
This has led to a follow up question. In the User Profile, "Roles" Tab (which I'm assuming is a table somewhere), is there a table I can report on that will get me what was changed and possibly by which user account (and maybe even the IP address of the user account)?
The path is:
Main Menu->PeopleTools->Security->User Profiles (and then the 'Roles' Tab).
Ultimately I need to figure out what change was made (when a role name was added) and by what user account and as of what date/time. If possible I need to link it to the IP address (which I think is found here: PSACCESSLOG).
what you need is audit on the PSROLEUSER table: you need to build an audit table for it and fill it either by a database trigger or through a PeopleSoft development: adding record audit to the PSROLEUSER table.
The PSROLEUSER table stores the roles a user is assigned. By default there is no history. To get that you would need to enable auditing, either record auditing through App Designer or setting up database trigger auditing. The database trigger audits can actually capture changes made either online or through the database so could be considered more complete, but can take some effort to get working properly. However, the database triggers also allow capturing some additional user information at the time of the transaction.
See http://peoplesoft.wikidot.com/auditing-user-profiles, particularly the section on using the the GET_PS_OPRID functions for Oracle or the SQL Server equivalent. Capturing the OSUSER and IP here would more reliable than trying to tie back to PSACCESSLOG.
Related
I have multi-vendor project which some variables should set by admin, For instance when User wants to pay his/her cart, fee should be specify and it defined by admin of system. (And it could be change passing of time.)
So what's the best approach for keeping this variables?
Note:
I'm running server with Nodejs and I use MongoDB as database.
I have following ideas which has pros and cons in my opinion:
Save these variables in document (in database), which I guess it's not good since I have to for each payment (or other actions which need these variables) send request to database. These variables seems to be fixed and can change after a while. I mean it's not like a user profile information which could change
frequently and when user wants to see his/her profile request should send to database. (further more it's just seems not good create new collection for storing just a document)
Save this in .env file (as environment variables) and I think we keep configuration variables in this file (application layer, not keeping the variables for business) and also updating this file is not good as database.
Please aware me if I make a mistake or there is common way which I don't know. (Also I searched for that and I couldn't find any proper keyword : ( )
My approach has been the following:
If the values can be updated by business administrator in normal course of operation - then they should have Admin UI and be stored in the database. Fees are a good example.
If the values hardly ever change; or changed by IT staff - put them in the configuration file. Endpoint of Vendor API, or mail server configuration would go there.
We are developing an intranet application using the Business Connector with our Dynamics AX 2009 installation.
We want to allow users to update the data from certain tables if the user already as permission to do so in AX. That is, if the user's effective permissions would allow them to update data using the AX Windows client, then they should be able to update the data using the intranet application.
We are using the LogonAs method and passing in the current user's logon name. That all works. But, for users that ARE ALLOWED to save data, I want to show an update button. For those that are NOT ALLOWED, I don't want any button to show.
Is there a way to query a user's permissions for a given update without trying to perform the update?
Have a look at the static method Global::hasTableAccess(tableId, AccessType)
So a call like
hasTableAccess(tablenum(SalesLine), AccessType::Edit)
would check whether the user has sufficient rights to edit that table - in this case SalesLine
Via CallStaticClassMethod you can call it directly passing both arguments or write a simple thin wrapper in X++ with a new class which just accepts the table name and calls this method with proper values on your behalf - the latter having the benefit of not exposing the raw numeric table ID and enumeration value which may change in a future version.
I'm setting up SQL access in a newly created OpenEdge 11.5 database.
In checking the contents of the sysdbauth table using "select * from sysprogress.sysdbauth", I see that there are two users setup by default: sysprogress and a user with the name of the Linux user account that was used to create the database.
I'm looking for recommendations as to how to handle these two accounts. Obviously I want to have an account to use for DBA tasks. Should I use one of these accounts for the purpose? If so, what should I do with the other account?
Is it possible (and safe) to be deleting either of these predefined accounts?
On page 175 of the Database Administration guide you can read about default users and why they are created:
Tables used from SQL only
An SQL database administrator (DBA) is a person assigned a sysdbauth record in the database.
SQL DBAs have access to all meta data and data in the database. To support internal schema
caching, every OpenEdge database begins with a DBA defined as "sysprogress." However,
OpenEdge restricts the use of "sysprogress."
When you create an OpenEdge database using the PROCOPY or PRODB commands, and the
database does not have any _User records defined (from the source database, for example), then
a DBA is automatically designated with the login ID of the person who creates the database. This
person can log into the database and use the GRANT statement to designate additional SQL DBAs,
and use the CREATE USER and DROP USER statements to add and delete user IDs.When creating
users, this DBA can also specify users as SQL-only users, who can only access the database
through SQL.
There are several knowledge base entries around the task of deleting or disabling the default users.
http://knowledgebase.progress.com/articles/Article/P5094
http://knowledgebase.progress.com/articles/Article/P161411
This suggests that it's really safe to delete or disable these accounts but you should:
1) Create replacing accounts first.
2) As always: test in a separate environment first and not in production!
Yes, in fact Progress kind of expects you to do so. Create a root account and get rid of both. It's fine.
I'm constructing a website.
In this website, people will be able to manipulate several DB tables data.
Everytime someone wants to make a CUD operation I want to log it (like and audit).
The way I see it, I should use triggers for CUD operations, but I can't understand how do I log the user, since triggers don't accept any input parameter.
NOTE: the user I want to log is the network user. I know this user when they access the website (user to log <> user logged to DB).
ANOTHER NOTE: None of my tables saves creation date, creator, update date and updator. Just don't know why they should when I have the audit tables.
So this is the basic problem with web apps. If you have a huge user base ( more then say 500 ), then provisioning them in the database, while this is very easily doable, it is something most web programmers, sadly, don't want to deal with and want only ONE connection user for the database. You have already shot yourself in the foot because you don't have the created_by,modified_by, created_date, modified_date in the tables. To fix this you really only have one choice:
Put the columns on the tables and force the UI people to push the "network" user name through. The rest of the columns can be handled by one very simple trigger.
Why DB audit will not help you:
The DB audit feature ONLY deals with users defined as actual users in the database, sorry that is just the way it is.
Here are some things to look at when dealing with a front end system.
You can write SP's or Packages that execute as the schema owner, but can be run by ANYONE who is defined in the database and those can handle all the INSERT, UPDATE, DELETE operations on the schema they are defined in by simply giving other users the EXECUTE privilege on that set of SP's. This give the DB fine grain control over how tables are manipulated and you only have to grans the select privilege to all the users.
You can write a SP or Package in the SYSTEM schema that allows a group of people to provision users on the system by granting the execute privilege on that SP. Within that SP you define what ROLES they are assigned and therefor can control all their access.
In the past, when I implemented my own authentication mechanisms I would have a user table with relationships to other tables in my application's MySQL database. However, now that I'm considering using ActiveDirectoryMembershipProvider, I see no way to create similar relationships between AD users and those tables.
What's the normal way to resolve this issue? Should I just accept the fact that someone could potentially insert records with user IDs that don't correspond to existing users? I don't realistically expect this to happen, but I'm used to ensuring integrity at the database level.
I think you'll have to give up on database referential integrity in this case. Just have your application code check for the existence of the Active Directory account before adding the record to the DB.
In theory, some user could go in manually and type a SQL INSERT statement which refers to an invalid AD account. But in practice, hopefully you aren't giving a bunch of users direct table access. If the application code is the only thing accessing the DB, the application code is validating the account before inserting the row, and that validation code is tested, then you should be OK.
Just to be safe, you could have a nightly batch process that validates all rows in your referencing table(s) against Active Directory. If it finds any inconsistency, it can send you an email. This won't prevent integrity violations, but at least it will let you know about them.
I don't know of anyway you could do this via MySQL. If you were using SQL server, you could write a trigger that would call a C# dll that would verify that they were an AD member. Then if they weren't you could block the insertion into the DB. You might be able to do something like this with MySQL, but my knowledge of MySQL is pretty slim.