Microsoft IP-Based Presence Overview
This article provides an overview of the technical information and answers some frequently asked questions.
Contact Us
If you still have questions or prefer to get help directly, please reach out to your technical contact.
Table of Contents
Using Maptician’s integration with Microsoft Azure Active Directory, and an easy to configure set of tools within Maptician, it is now possible for many organizations to effectively capture and display live employee presence data without sensors, installed tracking software, or cameras. Activating the integration usually takes about 30 minutes and employee presence tracking can be active the same day.
![](https://static.helpjuice.com/helpjuice_production/uploads/upload/image/21971/direct/1724342045512/image.png)
Presence data lets your employees see who is currently in the office – and provides powerful occupancy data
What is “Presence” in Maptician?
Presence is a status that can be set automatically or manually for each user in Maptician and is intended to provide a confirmed current physical location or remote/non-presence status or even indicate when someone is on leave. Maptician presence differs from presence in many other web applications that focus on current activity statuses such as “Available”, “Away”, or “Busy”. Instead, Maptician focuses on physical location so that employees can see when their coworkers are in the office and financial and office managers can make data-driven decisions on facility needs and effective capacities.
While Maptician presence can be set manually by a user, using their mobile or desktop Maptician applications, or by an administrator on the user’s behalf, we have generally found that it is more accurate and less burdensome to employees to establish presence using some automatic mechanism. Typical options include access control systems (door card readers), local network access logs, and IP addresses used for access.
How does Microsoft Azure Active Directory Help Provide Presence Information?
Microsoft Azure AD does not generally track a user’s current physical location directly – it does not have the ability to display a list of users and their current location. However, it does track IP addresses used by each user when authenticating for access to various Microsoft software and services (Exchange/Outlook, Office, SharePoint, etc.), including periodic background reauthorizations. This results in a robust log often covering most (if not all) employees during their workday, with many employees being covered by multiple log events throughout the day.
Converting these sign-in/authentication events into location data is accomplished using Maptician’s IP Range Management tools, which help discover and associate IP addresses and ranges with physical office locations. Maptician’s Azure AD integration can be granted access to the “Sign-In Log”, which Maptician uses to pull your organization’s sign-in events every 5 minutes, guaranteeing a nearly real-time stream of sign-in information to Maptician. After proper configuration, this data can be used to provide accurate and timely physical presence information for employees without the need for sensors, geo-location tracking, or specialized software.
What are the Limitations of Using Microsoft IP Address Data to Establish Presence?
Just about every method for determining a person’s physical location is subject to limitations, avoidance strategies, false positives and/or false negatives, and IP address-based locations are no different. The following are some typical situations where IP-based locations will not provide an accurate location:
- The user does not utilize a device that connects with a Microsoft service while at the office. This will result in the user not showing up as present.
- The user is not in the office but has a powered-on computer/device in the office not in sleep or hibernate mode. This device could authenticate with Microsoft in the background and create a false positive, showing the user as being in the office.
- The user uses a remote desktop connection, or similar tool, to access a computer in the office while they are physically outside of the office. If that computer is used to access one of the Microsoft services, then it may show the user as being in the office, even though they are accessing remotely.
- The network forwards all outbound web traffic through a proxy/VPN, rather than routing it directly to the public internet. This would result in the authentication events displaying the IP address for the proxy network rather than the office’s network. This becomes an issue if multiple locations forward traffic to the same proxy network and so the tool cannot distinguish between offices, or if the proxy network does not result in a consistent public IP address/range.
What Microsoft Security Permissions Must Maptician be Granted to Enable this Feature?
Maptician accesses the Sign-In Log report using Microsoft’s Graph API, using application-level access permissions (rather than delegated to a specific user account). The required permissions for IP Address-based Presence Tracking are:
- AuditLog.Read.All
- Directory.Read.All
Note: Microsoft’s documentation currently indicates that the requirement for “Directory.Read.All” access permission was not intended for this report and is listed as a “known issue”. We will update the required permissions within Maptician to reflect the reduced requirements if/when Microsoft resolves this issue.
What Information Does Maptician Get Access to Through this Integration?
While it is not possible to restrict the data fields permitted to Maptician, or for Maptician to restrict the fields returned by the report API, Maptician only processes three fields as part of the IP Presence tracking feature.
- Date – The time of the access event
- IP Address – The public IP address of the device authenticating with Microsoft
- User Principal Name – Typically the primary email address associated with the user account authenticating with Microsoft.
A full list of data fields provided by this report is available in Addendum 1. Maptician discards all non-used data, which is never used or stored by Maptician.
What Information Does Maptician Store as Part of this Process?
Each time Maptician receives a Microsoft log entry, there are two possible sets of data that are potentially logged within Maptician. Due to privacy considerations, we have attempted to provide multiple options to reduce the amount of data that Maptician stores for these events.
-
IP Access Event – Each time Maptician receives an access event (Microsoft authentication log in this case), several checks occur which determines whether this event data is stored within Maptician’s servers.
- Maptician checks the User Principal Name for the event against the existing user directory in Maptician. Maptician only logs access events for individuals who have active Maptician user accounts.
- Maptician checks to see if the IP address falls within an existing IP range set within Maptician’s IP Range Management tool. If a match isn’t found, and if range auto-create is not active, then events non-matching IP addresses are immediately discarded.
- If a matching IP Range is found, then there is an app-wide configuration option to enable/disable IP Access Event logging altogether, or there is an ability to enable/disable logging for individual ranges (app-wide must be enabled for range-specific settings to function). If tracking is enabled for the app and the range, then the User Principal Name, IP address, and Date are logged in Maptician. Logs are stored for up to 90 days, but this duration can be reduced as a configuration option within Maptician. – Note: If an IP Access Event is not logged due to tracking restrictions, it can still result in a Presence Event.
Note: Only one record is made for each calendar day per user per IP Address, and only the date – not the specific time – is recorded.
-
Presence Event – IP Ranges can be associated with physical office locations within Maptician, as well as triggering “Remote” presence status (i.e. an offsite location, or home office). The following conditions control when a Presence Event is created based on an IP Access Event.
- An IP Range must be set to have Presence “enabled” for a matched IP Access Event to trigger a presence status change for the accessing user. This is controlled on a per-range basis from the IP Range Management tool.
- An IP Range must also be associated with a location or be set to result in a presence status of “Remote” for presence status to be triggered by the range.
- The user whose Microsoft account’s authentication resulted in the IP Access Event must also be configured within Maptician as having their presence mode as “Track Only” or “Track and Display”. If neither of those two options are set, the presence event will not be logged.
Notes:
- Presence Events will set the presence status of the specified user for the rest of the calendar day unless their presence status is subsequently cleared or switched to a different location or status. Unlike IP Access Events, presence events include a time component indicating when the presence status was set.
- Presence Events include a user identifier, a date/timestamp, and an office location or “remote” designation.
Addendum 1
Microsoft Sign-In Data Schema
Property | Type | Description |
---|---|---|
appDisplayName | String |
App name displayed in the Azure Portal. Supports $filter (eq and startsWith operators only). |
appId | String |
Unique GUID representing the app ID in the Azure Active Directory. Supports $filter (eq operator only). |
appliedConditionalAccessPolicy | appliedConditionalAccessPolicy collection | Provides a list of conditional access policies that are triggered by the corresponding sign-in activity. |
clientAppUsed | String |
Identifies the client used for the sign-in activity. Modern authentication clients include Browser and modern clients. Legacy authentication clients include Exchange ActiveSync, IMAP, MAPI, SMTP, POP, and other clients. Supports $filter (eq operator only). |
conditionalAccessStatus | conditionalAccessStatus |
Reports status of an activated conditional access policy. Possible values are: success, failure, notApplied, and unknownFutureValue. Supports $filter (eq operator only). |
correlationId | String |
The request ID sent from the client when the sign-in is initiated; used to troubleshoot sign-in activity. Supports $filter (eq operator only). |
createdDateTime | DateTimeOffset |
Date and time (UTC) the sign-in was initiated. Example: midnight on Jan 1, 2014 is reported as 2014-01-01T00:00:00Z. Supports $orderby and $filter (eq, le, and ge operators only). |
deviceDetail | deviceDetail |
Device information from where the sign-in occurred; includes device ID, operating system, and browser. Supports $filter (eq and startsWith operators only) on browser and operatingSystem properties. |
id | String |
Unique ID representing the sign-in activity. Supports $filter (eq operator only). |
ipAddress | String |
IP address of the client used to sign in. Supports $filter (eq and startsWith operators only). |
isInteractive | Boolean | Indicates if a sign-in is interactive or not. |
location | signInLocation |
Provides the city, state, and country code where the sign-in originated. Supports $filter (eq and startsWith operators only) on city, state, and countryOrRegion properties. |
resourceDisplayName | String |
Name of the resource the user signed into. Supports $filter (eq operator only). |
resourceId | String |
ID of the resource that the user signed into. Supports $filter (eq operator only). |
riskDetail | riskDetail | Provides the 'reason' behind a specific state of a risky user, sign-in or a risk event. Possible values: none, adminGeneratedTemporaryPassword, userPerformedSecuredPasswordChange, userPerformedSecuredPasswordReset, adminConfirmedSigninSafe, aiConfirmedSigninSafe, userPassedMFADrivenByRiskBasedPolicy, adminDismissedAllRiskForUser, adminConfirmedSigninCompromised, unknownFutureValue. |
riskEventTypes | riskEventType collection |
Risk event types associated with the sign-in. Possible values: unlikelyTravel, anonymizedIPAddress, maliciousIPAddress, unfamiliarFeatures, malwareInfectedIPAddress, suspiciousIPAddress, leakedCredentials, investigationsThreatIntelligence, generic, and unknownFutureValue. Supports $filter (eq operator only). |
riskEventTypes_v2 | String collection |
The list of risk event types associated with the sign-in. Possible values: unlikelyTravel, anonymizedIPAddress, maliciousIPAddress, unfamiliarFeatures, malwareInfectedIPAddress, suspiciousIPAddress, leakedCredentials, investigationsThreatIntelligence, generic, or unknownFutureValue. Supports $filter (eq and startsWith operators only). |
riskLevelAggregated | riskLevel |
Aggregated risk level. Possible values: none, low, medium, high, hidden, and unknownFutureValue. The value hidden means the user or sign-in was not enabled for Azure AD Identity Protection. Supports $filter (eq operator only). Note: Details for this property are only available for Azure AD Premium P2 customers. All other customers will be returned hidden. |
riskLevelDuringSignIn | riskLevel |
Risk level during sign-in. Possible values: none, low, medium, high, hidden, and unknownFutureValue. The value hidden means the user or sign-in was not enabled for Azure AD Identity Protection. Supports $filter (eq operator only). Note: Details for this property are only available for Azure AD Premium P2 customers. All other customers will be returned hidden. |
riskState | riskState |
Reports status of the risky user, sign-in, or a risk event. Possible values: none, confirmedSafe, remediated, dismissed, atRisk, confirmedCompromised, unknownFutureValue. Supports $filter (eq operator only). |
status | signInStatus |
Sign-in status. Includes the error code and description of the error (in case of a sign-in failure). Supports $filter (eq operator only) on errorCode property. |
userDisplayName | String |
Display name of the user that initiated the sign-in. Supports $filter (eq and startsWith operators only). |
userId | String |
ID of the user that initiated the sign-in. Supports $filter (eq operator only). |
userPrincipalName | String |
User principal name of the user that initiated the sign-in. Supports $filter (eq and startsWith operators only). |