Set someone else as cluster admin via kql syntax - azure-data-explorer

I created a kusto cluster and database as one of my accounts on one Azure subscription, but now I want to grant cluster admin permissions to one of my other accounts that is not part of this subscription.
I have to do this via a kql command, or some other way I can manually pass in which users are becoming admins.
Is there such a thing as Cluster Admin permissions?
I added my other account as an admin to one of the databases in my cluster using
.add database DatabaseName admins ('aaduser=username#email.com')
but I cannot seem to do the same on a cluster level. How can I do this?

Cluster admin isn't a role you can add principals to.
You're likely looking for the All databases admin role: https://learn.microsoft.com/en-us/azure/data-explorer/kusto/management/access-control/role-based-authorization
You can add principals to that role via the Azure portal, or programmatically as explained here (note: there's a dropdown for C#, python, and an ARM template): https://learn.microsoft.com/en-us/azure/data-explorer/cluster-principal-python

Related

List Plans of all groups in my organization using Microsoft Graph SDK

I'm using Microsoft Graph SDK for .NET Core. I'm trying to get a list of all Office 365 plans in all Azure Active Directory groups within my organization.
I have been reading through a lot of questions, but haven't found a clear answer to my problem: As it's stated in the official documentation, you cannot list plans in a group using client credentials (application permissions), which is the exact authentication method I'm using. Given this, how can I achieve my objective?
As per documentation, the only way to list plans in groups is to use Delegated Permissions, but in that case, and according to the Microsoft Graph permissions:
either the user or an administrator consents to the permissions that the app requests and the app can act as the signed-in user when making calls to Microsoft Graph.
If the signed-in user is a regular user then the application will only access the groups that user is a member of. Bear in mind that there may not be a single user that is a member of all groups.
Is there a way to get my application to list all plans in all groups within my organization?
You can now use application permissions.
Outdated Reply:
Planner currently does not support application permissions. Depending
on what your scenario is, you have couple of options. One option is to
create a user account to be used by your app, and add that user to all
the groups. Then you'll be able to query the plans with the
credentials of that user.

Permission error on user management

We just set up elasticsearch, logstash and kibana on our swisscom application cloud instance. Now when I log in into kibana with the full_access_username and full_access_password I can do almost everything except adding new users and manage existing ones under settings - user management.
There I always get a message saying:
You do not have permission to manage users. Please contact your administrator.
Does anyone of you has an idea on how to fix that?
We d like to have different users and give them permissions on some indices and attributes only.
Thanks in advance for your help.
As Swisscom provides their Elasticsearch Service as managed, you have some limitations in terms of administrative functions. At the time of writing this includes cluster and user management as well as watches.
You can provide new users by creating service-keys cf create-service-key <service-instance-name> <service-key-name>.

No permissions to run the selected query in App Insights

When I go to App Insights -> Activity Log I get:
No permissions to run the selected query.
Is that because there are no queries to run? Or is it really a permissions problem?
I have defined two queries but they don't show up in the dropdown. Should they?
Where can I read more about this? The docs page didn't help me very much.
Please ensure that the user has access to the following azure provider in addition to the obvious ones.
"microsoft.insights/eventtypes/*"
you could also try "microsoft.insights/*/read", in case you want the role to view all monitoring data from Azure Monitor.
more on custom roles & RBAC is documented here:
https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles
To configure custom roles in Azure - https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles-powershell
Activity Log interaction is here:
https://learn.microsoft.com/en-us/rest/api/monitor/activitylogs/activitylogs_list

OIM11gR2PS3 Dynamic Manual Fulfillment Task Assignment

Usually when a Disconnected Application Instance is provisioned to a user, the manual fulfillment tasks are by default assigned to "SYSTEM ADMINISTRATORS" Role. We can modify it to any other role directly in SOA Composer so that the Fulfillment tasks are assigned to the newly Updated role. We can also have different rules in place for different application instances.
But the scenario is like We have a Role associated with a access policy which will provision a Disconnected Application Instance to the user upon provisioning the role. The Access Policy is also associated with some entitlements which will require manual fulfillment tasks to be assigned to particular fulfillment role which differs for different roles.
How do we dynamically fetch the Fulfillment Role in order to assign the task to them. I understand we should achieve it using the Oracle Business Rules. But How do I get the catalog attributes in the DisconnectedProvisioning composite.
I am a beginner in SOA - Workflow implementation. So please provide some detailed answers.
Thanks,
Srini
You should be able to assign a role to the Fulfillment Roles on the Disconnected App and it's separate entitlements in the catalog.
Then when the Access Policy triggers First a Provision Task should be generated for the Fulfiller role on the application instance, then once that is completed a Grant Entitlement task will be created for the fulfiller roles associated with each entitlement.

OpenEdge SQL DBA Account Setup

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.

Resources