#17230
Fix for the following scenarios:
- Team has only one policy with calendar enabled. Events are created on
user calendars. Then the user disables the calendar on such policy.
Expected behavior: Events on the user calendar should be cleaned up in
that scenario.
- Policy `platform` is edited (which removes `policy_membership`
entries) and we'd like to have the calendar event removed for the hosts
that do not apply anymore.
To cover these scenarios I changed `ds.GetTeamHostsPolicyMemberships` so
that it also returns hosts that have a calendar event AND have no
results on policies (returned as passing=1).
E.g. this could happen if there ARE calendar events for a team but with
a platform that doesn't match the host (so it has no results).
#17692
Recently there was a change that filtered out hosts in `EnrollmentState`
3. This change may cause some hosts that are in otherwise good health to
appear unresponsive to MDM in the management UI.
This change will allow hosts with `EnrollmentStatus` 3 show as enrolled.
The root cause of some hosts being in state 3 is still not entirely
clear, but may have to do with either trying to re-enroll once already
enrolled, or windows updates causing some sort of issue with fleet.
Despite the "failed" `EnrollmentState` 3, the host will still display
that the system is managed by Fleet, and will actively sync.
- Updated calendar interface to use updated `genBodyFn`
- The mock calendar is enabled by specifying `calendar-mock@example.com`
as the service account email.
# Checklist for submitter
- [ ] Changes file added for user-visible changes in `changes/` or
`orbit/changes/`.
See [Changes
files](https://fleetdm.com/docs/contributing/committing-changes#changes-files)
for more information.
- [x] Added/updated tests
- [x] If database migrations are included, checked table schema to
confirm autoupdate
- For database migrations:
- [x] Checked schema for all modified table for columns that will
auto-update timestamps during migration.
- [x] Confirmed that updating the timestamps is acceptable, and will not
cause unwanted side effects.
- [x] Manual QA for all new/changed functionality
# Checklist for submitter
- [ ] Changes file added for user-visible changes in `changes/` or
`orbit/changes/`.
See [Changes
files](https://fleetdm.com/docs/contributing/committing-changes#changes-files)
for more information.
- [ ] Added support on fleet's osquery simulator `cmd/osquery-perf` for
new osquery data ingestion features.
- [ ] Added/updated tests
- [x] Manual QA for all new/changed functionality
Sub-task for #17230
# Configuration changes
App configuration:
```yaml
integrations:
google_calendar:
- email: name@service-account.com
private_key: ***
domain: fleetdm.com
```
Team configuration:
```yaml
integrations:
google_calendar:
email: name@service-account.com
enable_calendar_events: true
policies:
- name: My policy
id: 12
webhook_url: https://example.com/policy-remediation
```
Note: Policy is looked up by name when configuration is set. The policy
id is set/updated by the server for internal use.
# Checklist for submitter
<!-- Note that API documentation changes are now addressed by the
product design team. -->
- [ ] Changes file added for user-visible changes in `changes/` or
`orbit/changes/`.
- [x] Added/updated tests
- [x] Manual QA for all new/changed functionality
#15565
Replace the use of the isFederated registry key with a keys that check
for AAD (Azure Active Directory, now Entra ID)
Federated enrollment (`isFederated`) seems to be when windows uses a
Discovery MDM endpoint to get its policy and management endpoint
configuration. This is always the case when a client is enrolled with
fleet, so installations always show up as automatic.
It's being replaced by a different key, `AADResourceID`, which appears
to identify the resource that controls the automated deployment. In my
tests it only appears to be populated when the computer is enrolled
through automated deployments. This key appears on both Windows 10 and
11.
There is a similar key, `AADTenantID`, which appears to identify the
client (tenant) to the Azure cloud. I haven't seen this ID in our
systems, so it is likely exclusively used in Azure. Both this key and
`AADResourceID` seem to always be set at the same time, so we only
check for the `AADResourceID`.
I've also added documentation on the registry keys I've analyzed for future reference.
Improvements and fixes I found while integrating this
- Renamed db columns to match the profile tables for consistency
- Added columns to `host_mdm_apple_declarations`
- Removed `team_declaration_checksum_view`
- Remove the ad-hoc `MDMAppleRecordDeclarativeCheckIn`, I confused
myself by developing this using tests, the device actually sends an
`Acknowledged` response, which is recorded by nano
- Fixed bugs in the `declaration/../..` endpoints
- The prefix for the endpoint is `declaration` without `s`
- The response needs to include a `ServerToken`, otherwise the
declaration fails
#17061
TODO: Need to also merge this fix into patch branch.
# Checklist for submitter
- [x] Changes file added for user-visible changes in `changes/` or
`orbit/changes/`.
See [Changes
files](https://fleetdm.com/docs/contributing/committing-changes#changes-files)
for more information.
- [x] Added/updated tests
- [x] Manual QA for all new/changed functionality
it delegates any extra unmarshaling to the caller. We might consider
building our own types in the future instead of relying on micromdm, but
these are used only for tests right now.
