User Profile
hspinto
MicrosoftJoined Nov 10, 2019
User Widgets
Recent Discussions
Re: Connect to Azure AD from Powershell without prompt - what are my options?
Patrick Rote A user principal with a never expiring password and no MFA is the worst you can do for the security of your solution. Use, at least, a service principal - they're meant for non-attended automation. The AzureAD module you are trying to use (Connect-AzureAD) is deprecating and is replaced by the MS Graph SDK I mentioned above. If you want to log into Azure AD with a service principal and MS Graph, you can simply use this: Connect-MgGraph -TenantId "your tenant id" -AppId "service principal app id" -CertificateThumbprint "cert thumbprint" Of course, you must grant to the service principal the required roles/permissions in your Azure AD tenant. If the execution context of your automation allows for it, i.e., it runs from Azure Automation or from an Azure/Arc machine, you can leverage Managed Identities, which are a special type of service principal for which Azure manages the credentials for you. You don't need to use certificates nor passwords. More details here: Managed identities for Azure resources | Microsoft DocsRe: Connect to Azure AD from Powershell without prompt - what are my options?
If you want to automate tasks against Azure AD, you should be leveraging Microsoft Graph instead. There's a PowerShell SDK (https://docs.microsoft.com/en-us/graph/powershell/installation). It supports authenticating with an SPN, but I would recommend using a Managed Identity, if possible.Re: Azure runbook restart during execution
You are probably reaching Azure Automation memory limits for jobs running in Automation sandboxes. You can try to either optimize your scripts to consume less memory or use Hybrid Workers. See references below: https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits#automation-limits https://docs.microsoft.com/en-us/azure/automation/automation-windows-hrw-installRe: FYI: Azure CIS 1.1.0 (New) Approved VM Extensions Type is NOT the Type Shown on VM Extensions Pane
Michael Carrabine You can also use this Azure Resource Graph query to find out all the VM extensions you have in your VMs. The "extensionType" column will help you finding the correct extension type to use in ASC allowed extensions list. resources | where type =~ 'microsoft.compute/virtualmachines/extensions' | extend vmName = tostring(split(id,'/')[8]) | extend extensionType = tostring(properties.type) | project vmName, extensionType, name | order by vmName asc, extensionType ascRe: Azure Hybrid worker not seeing installed modules
Did you install those modules in the Hybrid Worker in an elevated prompt? By default, the hybrid worker job will execute in the Local System context. Therefore, PS modules must be installed system-wide. Can you check if the path C:\Program Files\WindowsPowerShell\Modules contains the required modules?Re: Cannot reuse the automation account for Strat-Stop off hours VMs.
harshvir, you cannot have two resources of the same type+name in the same resource group. This is an Azure Resource Manager limitation coming from its resource ID scheme but it is also a good practice to avoid naming duplicates. Why would you want to have two resources with the same name? More details about Azure naming convention: Define your naming convention - Cloud Adoption Framework | Microsoft DocsRe: Azure Automation - Hybrid Worker - Connect-Azure AD
Dodge-1350, when using a Hybrid Worker to connect to Azure resources, the easiest way is to use the Run As Account certificate associated with the Automation Account. You must install first the certificate in the Hybrid Worker, by following the steps detailed here. Then you call Connect-AzureAD by using the certificate thumbprint, like this: Connect-AzureAD -Tenant <TenantID> -ApplicationId <ApplicationID> -CertificateThumbprint <CertificateThumbprint> Don't forget to install the AzureADPreview module in the Hybrid Worker. Hope this helps.Re: Active Directory admin
ganriver Your DBAs should normally be the database admins. You can assign a Azure AD Group as admin. There is also the possibility of granting the db_owner role to other Azure AD users directly in the databases security model, but the recommended, much simpler way, should be using an Azure AD Group. See other additional considerations here.Re: Active Directory admin
ganriver when using SQL Server-based users for managing your Azure SQL databases, you have additional identities/passwords to manage and you cannot leverage identity security features such as MFA. Your SQL Server-based database admin is, let's say, less secure. If you enable Azure AD-based authentication in your SQL database and make one or (preferably) more Azure AD users (the ones that log in to the Azure Portal) as database admins, you will be able to enforce MFA on those users and leverage other identity security features provided by Azure AD. See more details here.Re: Azure resource group tag requirement exception?
david_milette If you know the name of the temporary resource groups, have you tried to add exclusions or exemptions? Understand scope in Azure Policy - Azure Policy | Microsoft Docs If the resource group name cannot be anticipated, I am afraid you cannot add an exception to something that is unknown.Re: Connecting to VM from Azure Automation Runbook
You can absolutely automate processes inside your network with Azure Automation. But you cannot use the sandbox approach. By "sandbox" a mean using the default cloud workers. What you need is a Hybrid Worker, i.e., a worker that runs your runbooks from your own VMs (either on-premises or in your Azure VNet). Please, see the documentation below: https://docs.microsoft.com/en-us/azure/automation/automation-hybrid-runbook-worker
