APEX Domains to Azure Functions in 3 Ways

by Contributed | Oct 11, 2020 | Azure, Technology

This article is contributed. See the original author and article here.

Throughout this series, I’m going to show how an Azure Functions instance can map APEX domains, add an SSL certificate and update its public inbound IP address to DNS.

• APEX Domains to Azure Functions in 3 Ways


• Let’s Encrypt SSL Certificate to Azure Functions


• Updating DNS A Record for Azure Functions Automatically


• Deploying Azure Functions via GitHub Actions without Publish Profile

Let’s say there is an Azure Functions instance. One of your customers wants to add a custom domain to the Function app. As long as the custom domain is a sub-domain type like api.contoso.com, it shouldn’t be an issue because CNAME mapping is supported out-of-the-box. But what if the customer wants to add an APEX domain?

Both APEX domain and root domain point to the same thing like contoso.com.

Adding the root domain through Azure Portal can’t be accomplished with the message above. To add the APEX domain to Azure Functions instance, it requires an A record that needs a public IP address. But Azure Functions instance doesn’t support it via the portal.

Should we give it up now? Well, not really.

As always, there’s a way to get around. Throughout this post, I’m going to show how to map the APEX domain to an Azure Functions instance in three different ways.

Verifying Domain Ownership

First of all, you need to verify the domain ownership at the Custom Domains blade of the Function app instance.

• Get the Custom Domain Verification ID at the picture above.


• Add the TXT record, asuid.contoso.com, to your DNS server.


• Add the A record with the IP address to your DNS server.

The verification process can be done via the portal.

If you want to run the verification with Azure CLI, please have a look at the link.

Now, you’ve verified the domain ownership. But you haven’t still yet made the APEX domain mapping.

1. Through Azure PowerShell

If you can’t make it through Azure Portal, Azure PowerShell will be one alternative. Use the Set-AzWebApp cmdlet to map your APEX domain.

    $resourceGroupName = “[RESOURCE_GROUP_NAME]”

    $functionAppName = “[FUNCTION_APP_NAME]”

    $domainName = “contoso.com”

    Set-AzWebApp `

        -ResourceGroupName $resourceGroupName `

        -Name $functionAppName `

        -HostNames @( $domainName, “$functionAppName.azurewebsites.net” )

When you use Azure PowerShell, you MUST make sure one thing. The -HostNames parameter specified above MUST include the existing domain names (line #7). Otherwise, all existing domains will be removed, and you will get the warning like below:

If you add all custom domains including the default domain name like *.azurewebsites.net, you will be able to see the screen below:

2. Through Azure CLI

If you prefer to using Azure CLI, use the command, az functionapp config hostname add.

    az functionapp config hostname add

        -g [RESOURCE_GROUP_NAME]

        -n [FUNCTIONAPP_NAME]

        –hostname “contoso.com”

Unlike Azure PowerShell, you can add one hostname at a time and won’t lose the ones already added.

3. Through ARM Template

You can also use ARM Template instead of command-line commands. Here’s the bicep code for it (line #5-8).

    resource fncapp ‘Microsoft.Web/sites@2020-06-01’ = {

        name: functionApp.name

        …

    }

    resource fncappHostname ‘Microsoft.Web/sites/hostNameBindings@2020-06-01’ = {

        name: ‘${fncapp.name}/contoso.com’

        location: fncapp.location

    }

When the bicep file is compiled to ARM Template, it looks like:

    {

      …

      “resources”: [

        …

        {

          “type”: “Microsoft.Web/sites/hostNameBindings”,

          “apiVersion”: “2020-06-01”,

          “name”: “[format(‘{0}/{1}’, variables(‘functionApp’).name, ‘contoso.com’)]”,

          “location”: “[variables(‘functionApp’).location]”,

          “dependsOn”: [

            “[resourceId(‘Microsoft.Web/sites’, variables(‘functionApp’).name)]”

          ]

        },

        …

      ]

      …

    }

So far, we’ve used three different ways to map an APEX domain to Azure Functions instance. Generally speaking, it’s rare to map a custom domain to an Azure Functions instance. It’s even rarer to map the APEX domain. Therefore, the Azure Portal doesn’t support this feature. However, as we already saw, we can use either Azure PowerShell or Azure CLI, or ARM templates to add the root domain. I hope this post helps if one of your clients’ requests is the one described in this post.

In the next post, I’ll discuss how to bind a Let’s Encrypt generated SSL certificate to the custom APEX domain on Azure Function app.

This article was originally published on Dev Kimchi.

Aggregating Insider Risk Management Information via Azure Sentinel

by Contributed | Oct 11, 2020 | Azure, Technology

This article is contributed. See the original author and article here.

Overview

Thanks to @Enrique Saggese  and @Yaniv Shasha for the brainstorming and proof reading!

Managing and minimizing risk in your organization starts with understanding the types of risks found in the modern workplace. Some risks are driven by external events and factors that are outside of direct control. Other risks are driven by internal events and user activities that can be minimized and avoided. Some examples are risks from illegal, inappropriate, unauthorized, or unethical behavior and actions by users in your organization. These behaviors include a broad range of internal risks from users:

• Leaks of sensitive data and data spillage


• Confidentiality violations


• Intellectual property (IP) theft


• Fraud


• Insider trading


• Regulatory compliance violations

Insider risk management uses the full breadth of service and 3rd-party indicators to help you quickly identify, triage, and act on risk activity. By using logs from Microsoft 365 and Microsoft Graph, insider risk management allows you to define specific policies to identify risk indicators. These policies allow you to identify risky activities and to act to mitigate these risks, for more details Insider Risk Management in Microsoft 365

Alerts in M365 Compliance Insider Risk Management dashboard are automatically generated by risk indicators that match policy conditions . This dashboard enables a quick view of all alerts needing review, open alerts over time, and alert statistics for your organization. All policy alerts are displayed with the following information to help you quickly identify the status of existing alerts and new alerts that need action:

• Status


• Severity


• Time detected


• Case


• Case status

Case & Architecture

SOC team asked how to export Insider Risk Management alerts to Azure Sentinel for enrichment and aggregate these insider risk information with other data sources for monitoring, detection & hunting ?

Our use case for today is a corporate policy – standard communications to detect, alert and report on “Offensive language in email”, a built-in classifiers in Microsoft 365 scan sent email messages from Exchange Online mailboxes in your organization for different types of compliance issues. These classifiers use a combination of artificial intelligence and keywords to identify language in email likely to violate anti-harassment policies.

Starting October 16, 2020, you will no longer be able to create policies using "Offensive Language in email" template. Any active policies that use this template will work until they're permanently removed in January 2021. We are deprecating the Offensive Language built-in classifier that supports this template to optimize and fine tune false positives. To address risk issues for offensive language, we recommend using Microsoft 365 communication compliance policies.

Here’s the high-level architecture design / flow:

Insider risk management alert information is exportable to Azure Sentinel via the Office 365 Management Activity API schema. You can use the Office 365 Management Activity APIs to export alert information to other applications your organization may use to manage, enrich or aggregate insider risk information.

Implementation

• Sign in to your Office 365 Security & Compliance Portal and ensure that Audit log feature is enabled and retrieving data

• Sign in to Microsoft 365 Compliance Portal


• Under Solutions > … Show All > Insider risk management


• Click at Insider risk settings
  
  
  
  • Define and check “Policy indicators”, “Policy timeframes”
  
  
  • Exports Alerts  > Office 365 Management Activity API (On)
  
  
  
  


• Click at Policies
  
  
  
  • Create Policy > type a Name and choose a policy template, our use case today to detect and alert on an “offensive language in email” > Next
  
  
  • Define target users & groups
  
  
  • Specify what content to prioritize 
  
  
  • Select policy indicators 
  
  
  • Set policy timeframes
  
  
  • Review and Submit
  
  
  
  

• Open Outlook and send a test message with an offensive language keywords to trigger the alert, usually it might take up to 24 hrs to start capturing communications and generate the alert based on the classifiers detection

• Go to Insider Risk Management blade, and check the alerts:

• Sign in to Azure Portal and create a new App-registration:
  
  
  
  • API permissions: Office 365 Management APIs  > Application Permissions (ActivityFeed.Read)
  
  
  • Grant admin consent
  
  
  • Certificates & secrets: add new client secret
  
  
  • Keep a note for client secret, application-client ID, tenant ID and domain name to register the API subscription
  
  
  • Register the API subscription via PowerShell, open PowerShell as admin, connect to your tenant with a privileged account to register the API subscription ensure that you add the proper client secret, application-ID, tenant ID and domain name & ensure that the content-type is Audit.General a direct link to download the raw script at github:
  
  
  
  

$ClientID = "<app_id>"  
$ClientSecret = "<client_secret>"  
$loginURL = "https://login.microsoftonline.com/"  
$tenantdomain = "<domain>.onmicrosoft.com"  
$TenantGUID = "<Tenant GUID>"  
$resource = "https://manage.office.com"  
$body = @{grant_type="client_credentials";resource=$resource;client_id=$ClientID;client_secret=$ClientSecret} 
$oauth = Invoke-RestMethod -Method Post -Uri $loginURL/$tenantdomain/oauth2/token?api-version=1.0 -Body $body  
$headerParams = @{'Authorization'="$($oauth.token_type) $($oauth.access_token)"}   
$publisher = New-Guid
Invoke-WebRequest -Method Post -Headers $headerParams -Uri "https://manage.office.com/api/v1.0/$tenantGuid/activity/feed/subscriptions/start?contentType=Audit.General&PublisherIdentifier=$Publisher" 

• Deploy IRM-Alerts Connector:
  
  
  
  • Sign in to Azure Sentinel
    
    
    
    • Playbooks > Add Playbook
    
    
    • Logic app designer:
      
      
      
      • Recurrence (step):
        
        
        
        • Interval: 1
        
        
        • Frequency: Day
        
        
        
        
      
      
      • Variable (step):
        
        
        
        • Name: AuditGeneral
        
        
        • Type: String
        
        
        • Value:
          
          
          

          • https://manage.office.com/api/v1.0/2006d214-5f91-4166-8d92-95f5e3ad9ec6/activity/feed/subscriptions/content?contentType=Audit.General&PublisherIdentifier=Microsoft

          
          
          
          
        
        
        
        
      
      
      • HTTP (step):
        
        
        
        • Method: GET
        
        
        • URI: Dynamic Content > AuditGeneral
        
        
        • Headers:
        
        
        • (Accept) – (application/json)
        
        
        • (Content-Type ) – (application/json)
        
        
        • Authentication: Active Directory OAuth
          
          
          
          • Tenant ID value
          
          
          • Audience: https://manage.office.com
          
          
          • Client ID value
          
          
          • Credential Type: Secret
          
          
          • Secret value
          
          
          
          
        
        
        
        
      
      
      • Parse JSON (step):
        
        
        
        • Content: Dynamic Content > Body
        
        
        • Use sample payload to generate schema:
          
          
          

          • {
                "items": {
                    "properties": {
                        "contentCreated": {
                            "type": "string"
                        },
                        "contentExpiration": {
                            "type": "string"
                        },
                        "contentId": {
                            "type": "string"
                        },
                        "contentType": {
                            "type": "string"
                        },
                        "contentUri": {
                            "type": "string"
                        }
                    },
                    "required": [
                        "contentUri",
                        "contentId",
                        "contentType",
                        "contentCreated",
                        "contentExpiration"
                    ],
                    "type": "object"
                },
                "type": "array"
            }

          
          
          
          
        
        
        
        
      
      
      • For each (step):
        
        
        
        • Select an output from previous steps: Dynamic Content > Body
        
        
        • HTTP (step):
          
          
          
          • Method: GET
          
          
          • URI: Dynamic Content > contentUri
          
          
          • Headers:
            
            
            
            • (Accept) – (application/json)
            
            
            • (Content-Type) – (application/json)
            
            
            
            
          
          
          • Authentication: Active Directory OAuth
          
          
          
          
        
        
        • Send data (step):
          
          
          
          • JSON Request body: Dynamic Content > Body
          
          
          • Custom Log Name: Compliance_IRM_AuditGeneral
          
          
          
          
        
        
        
        
      
      
      
      
    
    
    
    
  
  
  • Save the playbook steps and hit run for triggering
  
  
  
  

The logic app code view have been uploaded as well to github, please ensure to change the subscription ID and resource group values.

Monitoring, Aggregating, Parsing and Enriching

• Under Azure Sentinel general section > Logs
  
  
  
  • A new custom log table been generated “Compliance_IRM_AuditGeneral_CL”
  
  
  • Here’s the Insider Risk Management alert(s) schema structure pulled from Office 365 Management API to Azure Sentinel Log Analytics workspace:
    
    
    
    • Alert Type: Custom
    
    
    • Category: InsiderRiskManagement
    
    
    • Name: alert title
    
    
    • Source: Office 365 Security & Compliance
    
    
    • Status: Investigating
    
    
    • Creation time
    
    
    • Operation: Alert Triggered, Alert Updated
    
    
    • Record Type: 40
    
    
    • Workload: Security Compliance Center
    
    
    • Data:
      
      
      
      • UPN
      
      
      • Risky User ID
      
      
      • Activation DateTime
      
      
      
      
    
    
    • Severity
    
    
    
    
  
  
  
  

Parsing the data can be done easily via a function, the function query have been uploaded to github as well:

A couple of enriching queries (for example):

Monitoring operations activities and result status of the alerted IRM UPN user

let IRMAlertsLog = Compliance_IRM_AuditGeneral_CL | where Category == "InsiderRiskManagement" | where RecordType_d == "40" | extend IRM_UPN = tostring(parse_json(Data_s).userPrincipalName);
IRMAlertsLog
| project AlertType_s, Category, Comments_s, IRM_UPN, Name_s, Severity_s, Source_s, Status_s
| join (AuditLogs
        | extend AuditLogs_UPN = tostring(parse_json(tostring(InitiatedBy.user)).userPrincipalName)
        | project TimeGenerated, AuditLogs_UPN, OperationName, Result)
        on $left.IRM_UPN == $right.AuditLogs_UPN
| project TimeGenerated, AlertType_s, Category, Comments_s, IRM_UPN, Name_s, Severity_s, Source_s, Status_s, OperationName, Result

Monitoring signin logs locations and status of the alerted IRM UPN user

Compliance_IRM_AuditGeneral_CL
| where Category == "InsiderRiskManagement"
| where RecordType_d == "40"
| extend IRM_UPN = tostring(parse_json(Data_s).userPrincipalName)
| join (SigninLogs
        | project UserPrincipalName, IPAddress, Location) 
on $left.IRM_UPN == $right.UserPrincipalName
| project TimeGenerated, AlertType_s, Category, Comments_s, IRM_UPN, Name_s, Severity_s, Source_s, Status_s, IPAddress, Location, CreationTime_t, Operation_s, RecordType_d, ResultStatus_s

Get started today!

We encourage you to try it now and start hunting in your environment. 

You can also contribute new connectors, workbooks, analytics and more in Azure Sentinel. Get started now by joining the Azure Sentinel Threat Hunters GitHub community.

How to enable SNI(Service Name Indication) for your Azure Cloud Service

by Contributed | Oct 11, 2020 | Azure, Technology

This article is contributed. See the original author and article here.

Pre-requirement:  

• Prepare an Azure Cloud Service: https://docs.microsoft.com/en-us/azure/cloud-services/cloud-services-dotnet-get-started#create-an-azure-cloud-service 

• Prepare two custom domain names: https://docs.microsoft.com/en-us/azure/cloud-services/cloud-services-custom-domain-name-portal 


• Prepare two certificates for these two custom domain names: https://docs.microsoft.com/en-us/azure/cloud-services/cloud-services-certs-create 


• Configure the Cloud Service with SSL: https://docs.microsoft.com/en-us/azure/cloud-services/cloud-services-configure-ssl-certificate-portal#step-1-get-a-tlsssl-certificate 

Now, have two domain names: www.haileyding.site, and www.dinghan.site 

Also, two certificates uploaded to my Cloud Service:  

Steps: 

The main changes happen on the .csdef file, .cscofg file, and also the OnStart method in the WebRole.cs. 

1. Add the two domain name in the definition file,  named with ‘ServiceDefinition.csdef’.  

Refer to this document about how to modify the service definition and configuration files. 

1. Add my two certificates into the configuration file, named with ‘ServiceConfiguration.Cloud.cscfg’ 

1. Since we cannot assign the same local port to multiple endpoints, so we need to override the OnStart method of the RoleEntryPoint class to overcome this issue.  

Please be noticed that the executionContext must be set to elevated, otherwise it is not possible for the OnStart method to edit the bindings. 

Navigate to the WebRole1 -> WebRole.cs, in this file, we can configure our OnStart method as below: 

namespace WebRole1 

{ 

    public class WebRole : RoleEntryPoint 

    { 

        public override bool OnStart() 

        { 

            using (var serverManager = new ServerManager()) 

            { 

                foreach (var site in serverManager.Sites.ToArray()) 

                { 

                    foreach (var binding in site.Bindings.ToList()) 

                    { 

                        if (binding.Protocol == “https”) 

                        { 

                            var newbinding = site.Bindings.CreateElement(“binding”); 

                            newbinding.SetAttributeValue(“sslFlags“, 1); 

                            newbinding.BindingInformation = binding.BindingInformation.Replace(“:444:”, “:443:”); 

                            newbinding.CertificateHash = binding.CertificateHash; 

                            newbinding.CertificateStoreName = binding.CertificateStoreName; 

                            newbinding.Protocol = “https”; 

                            site.Bindings.Remove(binding); 

                            site.Bindings.Add(newbinding); 

                        } 

                    } 

                } 

                serverManager.CommitChanges(); 

            } 

            RoleEnvironment.Changing += RoleEnvironmentChanging; 

            return base.OnStart(); 

        } 

        private void RoleEnvironmentChanging(object sender, RoleEnvironmentChangingEventArgs e) 

        { 

            e.Cancel = true; 

        } 

    } 

} 

1. Deploy the changes to my Cloud Service, then verify my custom domain name with HTTPS 

Reference: https://raflrx.wordpress.com/2017/08/08/enable-sni-on-a-windows-azure-cloud-service/ 

Continuous Access Evaluation in Azure AD is now in public preview!

by Contributed | Oct 9, 2020 | Azure, Technology

This article is contributed. See the original author and article here.

Howdy folks,

A few months back, we introduced Continuous Access Evaluation (CAE) for tenants who had not configured any Conditional Access policies. CAE provides the next level of identity security by terminating active user sessions to a subset of Microsoft services (Exchange and Teams) in real-time on changes such as account disable, password reset, and admin initiated user revocation.

Today marks an important milestone in bringing this capability to everyone – now CAE is available in public preview for Azure AD tenants who have configured Conditional Access policies. Microsoft services, like Exchange and SharePoint, can terminate active user sessions as soon as a Conditional Access policy violation is detected. More Microsoft services, such as Dynamics and Azure, will be enabled in the future. You can turn on CAE to improve the security posture in your tenant with just a few clicks!

Getting started

For tenants with Azure AD Premium subscription, you can configure CAE in our portal by going to Azure Active Directory -> Security -> Continuous Access Evaluation. There you can Enable Preview and you can also choose to configure this initially for a select set of users and groups.

If there are no conditional access policies configured in your tenant. CAE is already enabled for all users in your tenant and there are no additional actions you need to take. This is enabled even if your tenant has no Azure AD premium subscription.

To learn more about these changes, check out here: continuous access evaluation.

As always, we’d love to hear any feedback or suggestions you have. Let us know what you think in the comments below or on the Azure AD feedback forum. 

Best regards,

Alex Simons (twitter: @alex_a_simons)

Corporate Vice President Program Management

Microsoft Identity Division

Learn more about Microsoft identity: 

• Related Articles: Continuous Access Evaluation 


• Return to the Azure Active Directory Identity blog home 


• Join the conversation on Twitter and LinkedIn 


• Share product suggestions on the Azure Feedback Forum 

Friday Five: AI-Powered Fintech, Azure Managed Identity, More!

by Contributed | Oct 9, 2020 | Azure, Technology

This article is contributed. See the original author and article here.

TCA Podcast Episode 42: Multi-Vendor Cloud Management with Azure

Chris Goosen is an Office Apps & Services MVP with a passion for technology and almost two decades’ experience working with Microsoft technologies. As a solutions architect and consultant, Chris has many years’ experience helping organizations around the world design and implement Microsoft Exchange Server and other Microsoft technologies. Chris has been a speaker at conferences such as Microsoft TechEd and Ignite. For more on Chris, check out his blog and Twitter @chrisgoosen

Import existing resources as Terraform using Terraformer

Kasun Rajapakse is a cloud enthusiast based in Sri Lanka. Currently working as a Senior System/Automation Engineer, Kasun has more than 8 years of experience in cloud technologies and is well versed in multiple cloud technologies. Kusan actively contributes to the community by speaking in user groups, conferences, and content creating. For more on Kusan, see his blog.

AI-powered FinTech: The drivers of Digital India

Sray Agarwal is an AI MVP based out of London. Sray’s expertise lies in Predictive Modelling, Forecasting and advanced Machine Learning. He possesses a deep understanding of algorithms and advanced statistics with a background in management and economics. Moreover, Sray has completed a Master equivalent program in Data Science and Analytics. For mmore on Sray, check out his Twitter @srayagarwal

Teams Real Simple with Pictures: Group Policy Assignment

Chris Hoard is a Microsoft Certified Trainer Regional Lead (MCT RL), Educator (MCEd) and Teams MVP. With over 10 years of cloud computing experience, he is currently building an education practice for Vuzion (Tier 2 UK CSP). His focus areas are Microsoft Teams, Microsoft 365 and entry-level Azure. Follow Chris on Twitter at @Microsoft365Pro and check out his blog here.

Keyless Authentication using Azure Managed Identity

Garry Trinder is a Microsoft Office Development MVP from the UK. Garry has specialised in SharePoint and Office 356 development for the past 10 years with varying roles, including administrator, developer and consultant. In recent years, his focus has been on integration and automation in Microsoft 365 using Microsoft Azure platform. Passionate about community, Garry is a member of the Microsoft 365 Patterns and Practices (PnP) team, maintainer of the ‘CLI for Microsoft 365’ open source project and co-organiser of the PowerPlatform User Group in Leeds, UK. For more, visit Garry’s blog and Twitter @garrytrinder