[Updated 2020] Introducing the SensorExplorer App

by Scott Muniz | Sep 17, 2020 | Uncategorized

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

How to get the app

1. From the Microsoft Store: Search “SensorExplorer” or follow this link https://aka.ms/sensorexplorer

2. From GitHub: Go to https://aka.ms/sensorstrace, the app package is available inside the SensorExplorer folder for sideloading.

* The source code is available at https://github.com/Microsoft/busiotools/tree/master/sensors/SensorExplorer/code/SensorExplorer

Overview

SensorExplorer is an app available on the Microsoft Store (https://aka.ms/sensorexplorer) and the app package can be accessed through GitHub (https://aka.ms/sensorstrace). The app offers tests that allow you to quickly verify the installation of supported sensors such as orientation sensors (accelerometer, simple orientation sensors, etc.), and detailed tables and plots that enable you to monitor different sensors. In addition, logs can be conveniently saved later for debugging.

There are three modes (menu bar on the left-hand side) in SensorExplorer:

1. Test: This mode is used for manual testing of supported sensors. The orientation test verifies orientation sensors are installed in the correct position and the sensor data is as expected. Other tests, such as frequency, offset and jitter test, are also available. The sensor data is read using the UWP Sensors API (Windows.Devices.Sensors: https://docs.microsoft.com/en-us/uwp/api/Windows.Devices.Sensors).

2. View: This mode is used for viewing sensor data and properties. In this mode, the app displays a data visualization from a variety of sensors (such as accelerometer, compass, gyrometer, inclinometer, light sensor, and orientation sensor, etc.), and shows detailed sensor information in tabular format. It can help you monitor the abnormal behaviors of the sensors, and you can also use this mode to set the report interval of sensors.

3. MALT: This mode is used for connecting to and controlling MALT (Microsoft Ambient Light Tool), a simple low-cost light testing apparatus. The tool combines a microcontroller, light sensors, and a controllable light panel to calibrate light sensors and visually measure a panel’s light curve.

How to test your sensors

You may explore what tests are available for each sensor on your system by scrolling the top menu bar (highlighted in the screen shot below as a red box).

1. Orientation test

This test asks you to orient the device in different directions and then checks the sensor reading accordingly.

A pass/fail result will be displayed at the end of the test.

1.1 Before you begin the tests

• Under the test mode, if you find that the display rotates when you rotate your device, please turn off auto-rotation on your device (Search “Rotation Lock” in Settings and turn it on). Otherwise, you do not need to turn off auto-rotation.
• Please refer to the Device Reference Frame section found in the whitepaper at https://msdn.microsoft.com/en-us/library/windows/hardware/dn642102(v=vs.85).aspx) for more information on orientation and reference frame.

1.2 During the tests

• Click the “Start” button to begin the tests.
• For each test, you have 10 seconds to orient your device so that the arrow on the screen is pointing down toward the ground.

Note:

(1).You may click the icon (highlighted in the screen shot below as a red box) to hide the menu bar during the test.

(2). The menu bar is disabled during the test and will be enabled once the test finishes.

(3). For the Simple Orientation Sensor, the four directions tested are face up, face down, left, and right. For all other sensors, the four directions tested are up, down, left and right.

• Once the sensor data reflects that your device is indeed in the desired orientation, a green checkmark will be displayed. And you will automatically move on to the next test.

  

     

• Otherwise, after 10 sec, a red x will be displayed as this round of tests has failed. 

  

   
  

1.3 After the tests

• Click the “Save Log” button to save the log file(data for all rounds of tests will be saved).
• Or click the “Restart” button to start another test.

2. Frequency Test

This test calculates the number of sensor readings received/60 seconds.

A numeric value will be displayed at the end of the test.

3. Offset Test

This test calculates the average error in sensor readings compared with the expected value.

A numeric value will be displayed at the end of the test.

4. Jitter Test

This test calculates the maximum difference in sensor readings during a period of time, compared with the initial reading.

A numeric value will be displayed at the end of the test.

5. Resolution Noise Density Test

How to monitor your sensors

The View mode will automatically detect any sensors that are attached to or embedded in your platform. It will then display the information that it reads from the sensors.

1. View

• You may scroll the top menu bar (highlighted in the screen shot below as a red box) to change the sensor being displayed.
• For each sensor, the current data and properties are shown in a table and plotted as moving waveforms.
• The report interval of a specific sensor can be changed here.

  

   

More on Logging

When you click the “Save Log” button, you may choose the location to save the log file. The default name of the ETL (Event Trace Log) file is “SensorExplorerLog”, but you may change it.

To view the ETL file, you may use the tracerpt command (https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/tracerpt_1).

1. Test

The following will be logged:

• Properties of the selected sensor
• Information about each test
• For orientation test: 
  • The sensor reading when you pass a test
  • The last sensor reading before the countdown ends, in the case you fail the test
• For other tests:
  • All sensor readings collected during the test
  • The final result

Future Work

Some of the functionalities that we are planning to add to SensorExplorer include:

• Integrate all functions of MALT (Microsoft Ambient Light Tool)
• Other types of sensor tests
• Improve logging infrastructure

Best practices to simplify governing employee access across your applications, groups and teams

by Scott Muniz | Sep 17, 2020 | Uncategorized

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

In the modern workforce, the emergence of hybrid cloud deployments and collaborative applications make it easy for employees to share information, data, and files with other internal as well as external users, helping them collaborate easily with vendors, business partners, contractors and customers. Managing all the access across different resources – Office groups, Teams, SharePoint sites, as well as your own applications and SaaS applications – is challenging. As requirements change with new applications being added, or users needing additional access rights, IT staff may not know who should have access or to which applications. To succeed at scale, an identity governance process must enable all users’ access to be able to change with their needs, without burdening IT staff to be involved in each access request.

Azure AD entitlement management, a feature of Azure AD identity governance, helps organizations manage their access lifecycle at scale by automating request workflows, assignments, reviews, and expiration. You can empower users to request access to the resources they need. These requests and the resulting access can be approved and regularly reviewed by people across the organization who know whether someone should still have access

Here are some common questions we’ve received from customers about how to manage employee access.

Question 1. In the past we’ve configured that our AD- and ADFS-connected applications were open to everyone in the directory to access, as we only had employees and vendors in our AD.  Now that we’ve moved these applications to Azure AD, we want to lock down access to those apps and move to app assignments so that users don’t inadvertently have access.  What are the best ways to manage application assignments to make sure users don’t have access they don’t need?

Azure Active Directory (Azure AD) supports multiple approaches for access management for your own applications, including SaaS apps, cloud-based federation-based apps and on-premises AD-connected applications via the Azure AD app proxy, enabling organizations to easily achieve the right balance of access policies ranging including automatic, attribute-based assignment, as well as delegated assignment.

As described in the article managing access to apps, traditionally access management starts with either individual assignment, one for each user, or group-based assignment. Group–based assignment works well if you have an existing security group that you could re-use. However, keeping the membership consistent could be challenging if you have multiple applications. Suppose a user named Alice, and others in the same department as her, need access today to two apps. If there’s a group that has Alice and the other users as members, you could assign that group to those two apps. However, if Alice no longer needs one of the apps, that would require restructuring the groups to avoid audit findings of users having excessive access, and could lead to a proliferation of groups, potentially as many as there are apps. 

Another way to manage access to applications is for the users to receive entitlement management assignments for an access package that includes those applications and have those assignments set to expire or be regularly reviewed.  Through Azure AD entitlement management in the Azure portal, an administrator or a resource owner can create an access package with one or more applications. A user can request access to that access package through the myaccess.microsoft.com UI, or an access package catalog owner can assign access to users in the Azure portal. You can also have users request or create assignments programmatically, through Microsoft Graph, as shown in the tutorial for how to create an access package using Microsoft Graph APIs. When a user is approved for access to the access package, they are assigned to the application.

You can ensure that users do not have access indefinitely by configuring automatic access reviews as part of the policy. You could have different policies for different collections of users so that their review schedule is based on the likelihood of the user no longer needing access or the risk of inadvertent continued access.  Each policy in an access package can have a different access review frequency for reoccurrence or different reviewers.

The “Create policy” screen in the Azure portal for an Azure AD access package, showing the lifecycle tab in which quarterly reviewing access reviews are required.

For example, you could have one policy that gives users in the IT department a shorter maximum duration of access as they’re performing administrative tasks and another policy from users in other departments.

Question 2.  What about giving users access to Office 365 and other Microsoft applications?  Not everyone in the directory has a license, and we don’t have relevant data in our HR system to be able to create a dynamic group of just those people who need a license.

For applications in Office 365 or other paid suites, users can be granted access through license assignment either directly to their user account or through a group using the group-based license assignment. 

Combining group-based licensing and entitlement management for users to request an access package that results in license assignments simplifies giving users licenses they need.

First, in the Azure portal, create an Azure AD security group, and configure that group to give license assignments.

Then, create an access package containing membership in that group as a resource. If you select  to have the requestor’s manager as approver in the policy, then each requestor’s manager can decide if the requesting user has a need for the license for these applications.

The “New access package” screen in the Azure portal, for a policy configuring manager as approver.

Once a user requests and is approved, they’re automatically added to the security group, and Group-based license assignment gives them a license.

In access packages which give licenses, you may wish to configure a long duration prior to access package expiration or a “Never” setting with access reviews to avoid a user inadvertently losing their access package assignment and their use of Office while on vacation or on leave.

Question 3.  As we roll out Office groups and Microsoft Teams in our organizations, employees may inadvertently try to join public teams that sound relevant but aren’t the appropriate team for them. How can we cut down on unnecessary work for teams owners to approve requests and maintain their memberships?

An organization can publish a curated collection of teams that they want to make available for users to join by creating access packages for each one (they can include multiple teams in a single access package as well). They can then configure the requestor’s manager as needed for approval, approval by a departmental list of approvers, or both.  Once approved, the user is then added to the Office group and team, and can collaborate.

For example, if it wasn’t known in advance everyone who might need to be a member of a team, such as for a marketing launch, the marketing department could create the team as private. Next, the team owners could manually add or share a code with those individuals who are known and likely to need to be part of that team. 

To bring in the rest of the necessary members from other departments who aren’t known but avoid users being added who do not have a business requirement, they could create an access package for that team.

The “New access package” screen in the Azure portal.

If there are additional resources, such as a SharePoint Online site or applications, those could be added to the access package as well.

The policies for the access package could scope to only allowing certain users to request access, and could also require approval by both the requestor’s manager, and by the members of a departmental group. 

The “New access package” screen in the Azure portal, creating a policy for all member users to be able to request.

The first stage would specify the manager as approver. You can also configure a fallback approver for requestors who don’t have a manager.

The “New access package” screen in the Azure portal, setting the first approver stage in a multi-stage approval workflow.

And the second stage could have a different approver, such as members of a group. 

The assignments created through that access package could also be set to expire automatically on a predefined date, to avoid users remaining in the team indefinitely.

The “New access package” screen in the Azure portal, setting the access package assignment lifecycle for the policy.

Furthermore, additional resources that users might need access to,including access to SaaS applications, in-house developed applications, other existing security and Office groups, and SharePoint Online sites, can be added to the access package. Users with assignments to the access package will then automatically be given access to those resources as well. 

To find out more about Azure AD identity governance, including access reviews, privileged identity management, and how to manage the lifecycle of business partner guests see What is Azure AD identity governance? and What is Azure AD entitlement management?.  There are also case studies for how digital innovator Avanade chose Azure AD Identity Governance for streamlined, highly secure collaboration and how the leading energy and services company Centrica solved collaboration challenges with Azure Active Directory entitlement management.

• Return to the Azure Active Directory Identity blog home
• Join the conversation on Twitter and LinkedIn