We have several subscriptions in a Tennant and we have one restricted subscription which only a few have access to.
We need to configure diagnostic settings using Azure automation Runbooks for several resources across subscriptions and and point it to a log analytics workspace in the restricted subscription.
How do we do this? Do we need to create service principals? Or run as accounts? Or something else ?
Thank you for your help,
Kelly
Based on this reference, your requirement should be feasible by having one Azure RunAs Automation account in a subscription and running it's runbook(s) across multiple subscriptions. Having said that, the RunAs account would need appropriate permissions on all those multiple subscriptions. For more information w.r.t configuring permissions to access resources in another subscription, please refer this document.
Hope this helps!!
Related
I'm not able to access any tabs in AAD. What could be the issue?
Please check if below points can be worked around in your case.
Buttions or options being greyed out maybe because , you may not have had global admin rights/user administrator rights on the azure AD tenant. There are a few roles which can create users within the directory. You may not have any roles within the directory which permit the operations.
Reference: github issue.
Even in Azure AD free edition ,one should be able to create the users if you have proper roles .
On completion of the first 30 days of Microsoft Azure’s free trial,
your ‘Free Trial’ Azure Subscription will be disabled. To fix this,
the subscription needs to be changed to the ‘Pay-As-You-Go’ plan
instead of the ‘Free Trial’ plan which it is currently on.
For example :For applications under Enterprise application, one of the following roles: Global Administrator, Cloud Application
Administrator, Application Administrator, or owner of the service
principal.
You can check Azure AD built-in roles, and by checking the
description of role , assign the required one to manage identity .
You can Assign Azure AD roles to users to manage the identities
if you have global or role administrator rights. Approach the
admin to assign the roles .Also see custom roles in Azure AD
if needed.
Please check if this issue in - Microsoft Q&A can relate .
If issue still remains you can raise a support request in troubleshoot+support blade.
I have a question on administrative units in Azure AD -
If someone has User Administrator Role scoped to their administrative unit, how do we add a new user?
The reason behind the query is that I've found that because the user is not yet in that unit, and administrator has no privileges to add new one the only option is to add to the User Administrator Role without administrative unit ( entire ad) - but I want to avoid that if possible.
Anyone has come across a similar situation? Any input is appreciated.
I contacted MS Support and got a reply that it's the expected behavior currently.
Adding a member into an administrative unit is an option relating to the entire tenant so it requires a directory role rather than a unit role.
But this feature is in preview and your requirement is reasonable. So it may be changed in the future.
I am looking at these examples in the Snowflake documentation for creating OAuth integration with Tableau. I have noticed that there is a parameter called BLOCKED_ROLES_LIST which allows you to list specific roles which should not be able to use the integration.
Is there an equivalent parameter that I can use to list the allowed roles instead? Hypothetically, if we have 100 roles and only want to allow this integration for 1 of them, it seems overly cumbersome to have to list all 99 that we want to block, instead of the 1 to allow?
I have looked through the parameters in the documentation and cannot see a parameter to support this. There is a parameter called PRE_AUTHORIZED_ROLES_LIST however this is only supported for confidential clients only and appears to skip the authorisation entirely.
Can you configure a Snowflake Security Integration with Tableau to only allow specific roles?
I couldn't find an easy way to accomplish this.
The best I can recommend in the meantime is setting up an audit process that could constantly monitor the usage of the Tableau integration in Snowflake - and then trigger the automatic revoking of the privilege.
The basic element in this process is the ability to list the delegated authorizations:
SHOW DELEGATED AUTHORIZATION
TO SECURITY INTEGRATION td_oauth_int1;
Then to immediately revoke access (unless from the one role allowed):
ALTER USER fhoffa REMOVE DELEGATED AUTHORIZATION
OF ROLE sysadmin
FROM SECURITY INTEGRATION td_oauth_int1;
Sometimes you ask yourself a question and cannot answer or google the answer.
Question:
Is there any way to turn a single "on-premises mastered Directory Sync objects", to a "cloud mastered object"? Specificly a user account.
Can I revert this if I try with a real account?
And the major question: Thoughts about the consequences?
Background:
We move more and more processes to the cloud and I am beginning to "feel the need" for changing this. So I want to investigate the consequenses of changing, what breaks and what makes the change (if possible).
We have:
Office365 (mail,sharepoint, etc), onprem ADFS, AzureAD Sync. I am most worried about ADFS, since the account must be able to authenticate onprem. ~20.000 users and a applications onprem of all sorts.
As you aware in synced identities objects are mastered in our on-premise AD structure and cannot change it. If we need to make changes and edits to any of our users, this needs to be made on our on-premises AD structure. Once those changes are made, Azure AD Connect will then synchronize those up to Azure AD, and you'll see those changes after the next synchronization run.
Mostly Azure AD Connect assumes you start with a new Azure AD tenant and that there are no users or other objects there. But if you have started with an Azure AD tenant, populated it with users and other objects, and now want to use Connect, then kindly check this link.
I want to authorize several Logic Apps to access operations on an API secured by an app registration, which has several app roles describing different operations. Currently a directory administrator is doing this manually using New-AzureADServiceAppRoleAssignment once the Logic Apps are created, because the associated service principal doesn't exist until then.
I'd rather this were automated, because especially in development, the manual work of asking a directory administrator to re-run this script is very tedious. However I don't know how to grant the scripting account - a service principal linked to a DevOps service connection - only the permissions to do this, and not make it a directory administrator able to do anything. If the service connection is a directory administrator, developers would be able to supply it scripts to tell it to create or delete any combination of role assignments, enabling them to let themselves into anything, and also shut out people who should be able to prevent this. This is an unacceptable security hole.
What is the minimal permission needed to allow an automated process to script the creation of app role assignments but nothing else, and where is this documented?
For this requirement, you can just add the scripting account as owner of your app(just create a new user without any roles and add it as the app's owner). Then it can just add role assignment in this app but can't do other operations on role assignment of other apps.