In Microsoft Dynamics 365 Customer Engagement/ Sales, is it possible that an application user who has been assigned system administrator for the environment, might not have the privileges to access some of the data in the tables?
I have an application user who has system administrator permission, and while accessing some of the data using that application user, I am seeing:
Unable to enumerate rows. Error:0x80040220 - SecLib::CheckPrivilege failed. User: <id>, PrivilegeName: prvReadmsdyn_caseenrichment, PrivilegeId: 41f6f2f1-30c0-431f-b6c7-b8c97a274f5f, Required Depth: Basic, BusinessUnitId: <id>, MetadataCache Privileges Count: 5995, User Privileges Count: 4624
https://learn.microsoft.com/en-us/power-platform/admin/database-security#assign-security-roles-to-users-in-an-environment-that-has-a-dataverse-database
In this link, it has been mentioned that the system administrator permissions application user has full access to the Dataverse environment, with CRUD permissions on all entities.
A user that has the System Administrator role should be able to access all data in the system, so you are right to question why the error is happening.
The end of this article says that the msdyn_caseenrichment entity is part of the Customer Service Intelligence solution.
I'm not up to speed on that particular solution, but maybe the user is unlicensed for it, or something along those lines.
On Dynamics 365 CE On-line this is indeed possible. There are certain actions that cannot be performed by application users. One example is turning on cloud flows, which can only be done by regular user accounts.
You can work around this limitation by making the application account impersonate a regular user.
Related
My organisation has a number of schemas within an Oracle database that need to be accessed by a number of individual developers. In most cases, the developers can login with their own id and access these other schemas through role permissions, but for certain tasks the individual developers need to log into these schemas directly.
An example of this would be schema A which needs to be accessed by users X and Y. User X and user Y can log in with their own ids, but to fully leverage the potential of schema A, they would need the schema A password.
I am interested in tracking if and when user Y for example logs into schema A, using the schema A password. Can this be done?
My need for this is primarily in relation to password security and leaving procedures when staff depart our organisation. For example, if I have schema A and the password is known by at least some of users X, Y, Z and Q, and user Q leaves, is this a threast? If the checks show the password for schema A was not known by user Q, then I don't have a security risk, but if the checks show that user Q knew the password for schema A, then I need to change the password for schema A, potentially impacting users X, Y and Z.
Therefore, my question is, is there a method within Oracle that would enable me as DBA to identify which individuals logged into these schemas, whether it be by tracking their client identifiers or some other route?
Thanks
For this specific scenario, use proxy authentication: it kills several problems related to development environments in a single stroke.
[Proxy authentication] allows a user to connect to a database as one user and on connection
become a different user. This capability was originally deployed by
Oracle as a way for applications to authenticate end users to
individual database accounts through a common application account, but
it works just as effectively the other way around.
In this model ... each developer is given a separate,
personal account in the database. Most application development can now
be handled – and audited – through these personal accounts. Because
the login accounts are associated with individual users there is no
incentive for the developer to share their credentials with anyone
else. It would be relatively simple to tell if a personal account was
being shared, and doing so would be grounds for termination with most
companies.
To demonstrate this in action, I’ll create an application schema and
configure it so that it can only be accessed by means of proxy
authentication:
Connected to: Oracle Database 19c Enterprise Edition Release
19.0.0.0.0 - Production Version 19.3.0.0.0
SQL> create user app_schema no authentication proxy only connect;
User created.
SQL> grant connect, resource to app_schema;
Grant succeeded.
The “no authentication” option creates the shared
account without credentials. [This is not strictly required, but] it eliminates the need to maintain a
password or certificate for an account that will never be used
directly. The “proxy only connect” option allows only proxy
connections to the shared account. [This too is not required, but could be useful depending on your situation.] The “connect” and “resource” roles
grant basic privileges to use the account and create objects. Next, I
will create a sample development user:
SQL> create user dev_user identified by oracle;
User created.
Now the application schema can be altered to allow
connections from individual developer accounts, like this:
alter user app_owner grant connect through dev_user;
Note the syntax:
the APP_OWNER schema is altered to allow connection by or through the
DEV_USER account. This is not a privilege that is assigned directly to
the development user. Once this proxy privilege has been assigned, the
developer can connect to the application schema using their personal
credentials. All they need do is append the application account name
in brackets to the end of their development account name, like this:
SQL> connect dev_user[app_schema]/oracle
Connected.
SQL> show user;
USER is "APP_SCHEMA"
By connecting in this way, the developer can
still perform needed actions but need never be aware of the
application owner account’s real password (assuming one was even
assigned). The proxy account name (the developer’s personal account)
is available in the system session context, and can be automatically
made visible in the v$session view through a database trigger so that
the DBA can tell who is connected to shared accounts at all times.
CREATE OR REPLACE TRIGGER db_session_trig
AFTER LOGON ON DATABASE
v_proxy_user varchar2;
BEGIN
v_proxy_user := sys_context('userenv','proxy_user');
if v_proxy_user is not null then
dbms_session.set_identifier(v_proxy_user);
end if;
END;
select username, osuser, client_identifier
from v$session where username='APEX_040000';
USERNAME OSUSER CLIENT_IDENTIFIER
----------------- --------------- ----------------------
APEX_040000 oracle PETE
Using the PROXY_USERS view it is easy to
determine exactly which developers have access to each application
owner account as well.
PROXY CLIENT AUTHENTICATION FLAGS
------- -------------- -------------- -----------------------------------
PETE APEX_040000 NO PROXY MAY ACTIVATE ALL CLIENT ROLES
Because even basic auditing
captures the OS username of the developer, the audit trail will record
the actual developer behind DDL operations executed as the application
owner.
Sep 4 10:04:07 testdb Oracle Audit: SESSIONID: "12345" ENTRYID: "1"
STATEMENT: "6" USERID: "APP_SCHEMA" USERHOST: "myserver" TERMINAL:
"pts/2" ACTION: "7" RETURNCODE: "0" OBJ$CREATOR: "APP_SCHEMA"
OBJ$NAME: "TEST_TABLE" SES$TID "4567" OS$USERID: "PETE"
Using
individual developer user accounts with proxy account access to
application schemas, it is possible to allow developers to work in
shared accounts while still maintaining account credential security,
visibility of connected users, and an accurate audit history.
Full article here: https://pmdba.wordpress.com/2021/10/15/shared-application-accounts-revisited/
You could use proxy users for this. That way there is no need to share a password and regular auditing can do its job.
An other option could be to define packages in the other schemas that can be called by the developers. The packages need to be defined with definers rights so when a dev calls the package, the execution is done using the privileges that are directly granted to the schema. Doing so avoids nasty ‘any’ privileges.
I'm new to Oracle and I'm currently hardening a database.
It's a good idea to drop SYS and SYSTEM users? normally default accounts are dropped because of security reasons, I can do that on Oracle, or I will break something?
From the documentation (emphasis added):
All databases include the administrative accounts SYS, SYSTEM, and DBSNMP. Administrative accounts are highly privileged accounts, and are needed only by individuals authorized to perform administrative tasks such as starting and stopping the database, managing database memory and storage, creating and managing database users, and so on. You log in to Oracle Enterprise Manager Database Express (EM Express) with SYS or SYSTEM. You assign the passwords for these accounts when you create the database with Oracle Database Configuration Assistant (DBCA). You must not delete or rename these accounts.
And:
All base (underlying) tables and views for the database data dictionary are stored in the SYS schema. These base tables and views are critical for the operation of Oracle Database.
So no, it is not a good idea, and it would destroy your database.
normally default accounts are dropped because of security reasons, I can do that on Oracle, or I will break something?
The first documentation link above also says (emphasis added again):
All databases also include internal accounts, which are automatically created so that individual Oracle Database features or components such as Oracle Application Express can have their own schemas. To protect these accounts from unauthorized access, they are initially locked and their passwords are expired. (A locked account is an account for which login is disabled.) You must not delete internal accounts, and you must not use them to log in to the database.
And it mentions sample schema accounts, which you can choose not to install in the first place, but which could be dropped if required.
The main thing is to secure all accounts, and you should limit any accounts you create to only have the minimum privileges necessary.
You can also read more about this in the database administrator's guide,
It is a very bad idea. I don't think the database will even work without them and doubt that the drop is allowed. Make sure the accounts are safe instead.
I exported a SharePoint list to Excel and then tried Data -> Entities -> Get Data to create entities in CDS uploading data from Excel. It says 'You are missing privileges to create entities in this environment.' What could I do?
Possibilities of this error while creating entity are:
You are trying to create entity in some environment where you don't have security role/privilege to do this operation, viz Environment Admin, System Admin, System Customizer or custom Admin role
Trying this operation in Default or a CDS environment without database provisioning (highly unlikely)
Probably you have Environment maker role, client assumes that it is enough which is not the case
Try to get Admin privileges in Dev/sandbox environment from your client or create a trial org to try out things. You may have license but the basic role to access the system as an end user will not help you to do such stuffs.
I created instance at user level.but I am not getting same instance in oracle SOA BPM 11g workspace. these same issue facing in all the BPM interfaces in (DEV Environment ). please give me the solution for this...
Create a User and assign the role to the user in the "Security Realm" under user tab of weblogic console.
After adding user, make sure you have the role available under the groups tab. Add the respected role to user and logout from workspace and retry to login and verify for the instance. The instance should be visible in the workspace.
For instance, the lane participant for the User task is Approver as shown above. The user should be assigned to this role in order to retrieve the task. Please make sure that the user is assign to the Approver role and this role is exist in the Application roles under Security Realm. HTH.
We're installing some Oracle XE servers (the free one) on people's desktops for development use.
What's a good default role to assign to these developers? Since these instances contain scratch data only, data security is not a concern.
If you want the developers to be able to do anything grant the DBA on the development DB. Of course there is a risk with this; if they develop and run the code as themselves they will not address the security needs of the application.
If you want the developers to work with the security context of the application grant them the same roles that the application has in Prod.
So; if you want them to be able to do anything on the Dev instance but still code in the same security context as on Prod, create 2 users for them. The first is there usual users with the same rights as the code will execute under in Prod and the second is a DBA user with teh DBA role.
Its odd to some people who are used to the Windows approach (where a domain admin user reads email, browses the web, etc with domain admin rights) but very familiar to a Unix user who redas email as a low level user but can SUDO if needed.
As a developer all I ask for on dev databases is the SYSTEM password, as well as enough space in some tablespace(s) to create my objects. That gives me enough to get going - I can create my users, grant them the access they need, and get started developing.