This article is contributed. See the original author and article here.
CISA is aware of a misconfiguration vulnerability in Microsoft’s Azure Cosmos DB that may have exposed customer data. Although the misconfiguration appears to have been fixed within the Azure cloud, CISA strongly encourages Azure Cosmos DB customers to roll and regenerate their certificate keys and to review Microsoft’s guidance on how to Secure access to data in Azure Cosmos DB.
This article is contributed. See the original author and article here.
Integrated authentication provides a secure and easy way to connect to Azure SQL Database and SQL Managed Instance. It leverages hybrid identities that coexist both on traditional Active Directory on-premises and in Azure Active Directory.
At the time of writing Azure SQL supports Azure Active Directory Integrated authentication with SQL Server Management Studio (SSMS) either by using credentials from a federated domain or via a managed domain that is configured for seamless single sign-on for pass-through and password hash authentication. More information here Configure Azure Active Directory authentication – Azure SQL Database & SQL Managed Instance & Azure Synapse Analytics | Microsoft Docs
We recently worked on an interesting case where our customer was getting the error “Integrated Windows authentication supported only in federation flow” when trying to use AAD Integrated authentication with SSMS.
Recently they have migrated from using ADFS (Active Directory Federation Services) to SSSO for PTA (Seamless Single Sign-on for Pass-through Authentication). To troubleshoot the issue, we performed the following checks.
Follow the steps here and navigate to https://myapps.microsoft.com Be sure to either clear the browser cache or use a new private browser session with any of the supported browsers in private mode.
If you successfully signed in without providing the password, you have tested that SSSO with PTA is working correctly.
Now the question is. Why the sign in is failing with SSMS?
For that we turned to grab a capture using Fiddler
The following link has a set of instructions on how to go about setting up Fiddler classic to collect a trace. Troubleshooting problems related to Azure AD authentication with Azure SQL DB and DW – Microsoft Tech Community
When we reviewed the trace, we saw a few interesting things
We can only see a call to login.windows.net which is one of the endpoints that helps us use Azure Active Directory authentication.
For SSSO for PTA we would expect to see subsequent calls to https://autologon.microsoftazuread-sso.com which were not present in the trace.
This Azure AD URL should be present in the Intranet zone settings, and it is rolled out by a group policy object in the on premises Active Directory.
A key part on the investigation was finding that the client version is 1.0.x.x as captured on the Request Headers. This indicates the client is using the legacy Active Directory Authentication Library (ADAL)
The SSMS version on the developer machine was the latest one so we needed to understand how the application is loading this library. For that we turned to Process Monitor (thanks Mark Russinovich)
We found that SSMS queries a key in the registry to find what DLL to use to support the Azure Active Directory Integrated authentication.
Using the below PowerShell cmdlets, we were able to find the location of the library on the filesystem
Set-Location -Path HKLM:
Get-ItemProperty -Path SOFTWAREWOW6432NodeMicrosoftMSADALSQL | Select-Object -Property TargetDir
Checking on the adalsql.dll details we confirmed this is the legacy library
As SSMS is a 32 bit application it loads the DLL from the SysWOW64 location. If your application is 64 bit you may opt to check the registry key HKLM:SOFTWAREMicrosoftMSADALSQL
A clean install of the most recent version of SSMS creates a different DLL with the most up to date library
In this case the developer machine ended up having up that registry location modified and pointing to the legacy client (adalsql.dll). As the newer DLL (adal.dll) was already installed on the system the end user simply made the change to use the adal.dll on the registry.
It is important to be aware of this situation. Installing older versions of software like SSMS, SSDT (SQL Server Data Tools), Visual Studio etc. may end up modifying the registry key and pointing to the legacy ADAL client.
Cheers!
This article is contributed. See the original author and article here.
The Federal Bureau of Investigation (FBI) has released a Flash report detailing indicators of compromise (IOCs) and tactics, techniques, and procedures (TTPs) associated with ransomware attacks by Hive, a likely Ransomware-as-a-Service organization consisting of a number of actors using multiple mechanisms to compromise business networks, exfiltrate data and encrypt data on the networks, and attempt to collect a ransom in exchange for access to the decryption software.
CISA encourages users and administrators to review the technical details, IOCs, and TTPs in FBI Flash MC-000150-MW and apply the recommend mitigations.
This article is contributed. See the original author and article here.
The Industrial Control Systems Joint Working Group (ICSJWG) will hold the virtual 2021 ICSJWG Fall Meeting, September 21—22, 2021. ICSJWG meetings facilitate relationship building among critical infrastructure stakeholders and owners/operators of industrial control systems, idea exchange regarding critical issues affecting industrial control systems (ICS) cybersecurity, and information sharing to reduce the risk to the nation’s industrial control systems.
The ICSJWG bi-annual meeting will feature two full days of presentations, a Table-Top Exercise introductory session, technical workshop activities, and a CISA ICS Training overview. Register no later than September 17, 2021 to attend. Visit the ICSJWG website or the ICSJWG 2021 Fall Virtual Meeting website for more information.
This article is contributed. See the original author and article here.
Lead routingthe process of distributing incoming leads among sales repscan be simple or complex. If you have sophisticated requirements for making those lead assignments, review these tips for using the standard seller information and dynamic matching to streamline rule configuration in the Sales Premium for Dynamics 365 Sales.
A simple approach to lead routing is to make a list of all your sales reps, and then assign each new lead to the next seller in sequence (round robin) or based on availability (load balancing). This can be achieved by using the assignment rule shown in the following screenshot. This configuration will assign all the leads that are part of the segment Leads from web to sellers in a round-robin way.
More sophisticated requirements can also be configured by using the lead assignment rules. The rules can identify the most appropriate seller based on the fields of incoming leads. Seller availability and capacity can also be considered in the rule. The following two options are available to select sellers:
Using the first option to manage lead distribution is simpler in terms of onboarding and management because it uses the seller information that already exists in Dynamics 365. The following example shows a rule to assign leads to sellers who are based out of Seattle:
Dynamic matching reduces the effort of having to write and maintain multiple static rules for each permutation and combination of values. Suppose we want to distribute leads based on country. For example, we can have leads from the United States assigned to any seller focused on US clients and leads from India assigned to any seller focused on India.
If we try to create static rules for each assignment by country, we’d need as many rules as countries. If the organization is serving 150 countries, we might need to create 150 static rules. If we wanted to use more attributes, such as Zip Code and currency, the rule count would multiply exponentially. A simpler approach is to use the dynamic match capability. In the scenario described above, where leads are assigned to sellers based on country, we can have a single rule as follows:
Here, the rule will check the country of the lead (Lead.Country) and match it with seller’s country. When there is an exact match, the lead is assigned to the appropriate seller.
Note: Country as used here is a global option set defined for both lead and system user entities. You could instead use the look up mechanism to find a match. In this way, you can use any string type of field (a single line of text). However, the string type of lead field will need a logical name on the right side as shown in the screenshot below:
ZIP/Postal Code as selected for the first field, on the left side, refers to a system user field that needs to match with the lead field called address_1_postalcode, which is the logical name for the field ZIP/Postal Code in Lead.
Once the admin identifies the relevant lead and user fields for lead assignment, the challenge can be to populate the user fields that will be used in lead routing.This can be done by the sales manager using a CSV file. The file is reviewed, and then imported in bulk as shown in How to import data.
Here’s a scenario in which an organization would like to route leads based on a few parameters:country (option set), Zip Code(string), and currency (look up). If all the three parameters match with seller, lead should be routed to that seller, otherwise it should try to match the country only.In this scenario, we can have two assignment rules in the following evaluation order (rules get evaluated in the order specified):
Configuration for the rule to match country, Zip Code, and currency:
Configuration for the rule that finds a match only based on country:
Note that these scenarios simply depend on the user information that is entered into the system whenever a new seller is added. The new seller can begin to get leads right away, as long as all the routing-relevant fields are populated as part of onboarding.
For more information on how to manage assignment rules for lead routing, review the documentation.
The post Route leads with dynamic assignment rules appeared first on Microsoft Dynamics 365 Blog.
Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.
Recent Comments