FleetDM项目中实现Entra设备ID采集与Intune合规报告的技术方案
2025-06-10 19:06:09作者:郜逊炳
背景介绍
在现代企业IT环境中,设备合规性管理是确保网络安全的重要环节。FleetDM作为一个开源的设备管理平台,近期实现了与微软Intune的深度集成,使企业能够通过FleetDM平台直接向Intune报告设备合规状态。
技术挑战
实现这一功能面临两个主要技术挑战:
- 如何从已部署fleetd代理的现有主机获取Entra设备ID
- 如何为新加入网络且尚未在Intune中注册的主机获取Entra设备ID
解决方案探索
开发团队最初考虑了多种技术路径,包括:
- 使用微软官方提供的Microsoft Authentication Library for Objective-C(MSAL)库
- 开发原生客户端应用来获取设备信息
经过深入评估,团队发现这些方案存在以下问题:
- 需要额外的客户端部署
- 增加了系统复杂性
- 可能带来用户体验问题
基于osquery的优雅解决方案
团队最终采用了基于osquery的轻量级解决方案,充分利用了现有基础设施。osquery作为FleetDM的核心组件,提供了强大的系统信息查询能力。
具体实现方案是通过osquery查询以下系统信息:
- 从证书存储中获取设备ID
- 从钥匙串中获取用户主体名称(UPN)
SELECT * FROM (SELECT common_name AS device_id FROM certificates
WHERE issuer LIKE '/DC=net+DC=windows+CN=MS-Organization-Access+OU%' LIMIT 1)
CROSS JOIN (SELECT label as user_principal_name FROM keychain_items
WHERE account = 'com.microsoft.workplacejoin.registeredUserPrincipalName' LIMIT 1);
技术优势
这一方案具有以下显著优势:
- 无需额外部署客户端软件
- 完全基于现有osquery基础设施
- 查询效率高,对系统资源影响小
- 实现简单,维护成本低
- 兼容现有设备管理流程
实现细节
设备ID获取机制
通过查询系统证书存储,筛选出由微软组织颁发的特定证书,从中提取common_name字段作为设备ID。该证书是由Azure AD在设备注册过程中自动安装的。
用户主体名称获取机制
通过查询系统钥匙串,找到由微软工作区加入流程创建的特定条目,从中提取用户主体名称。这一信息对于关联设备和用户身份至关重要。
系统架构影响
这一实现方案对FleetDM系统架构的影响极小:
- 不需要修改数据库schema
- 不需要增加新的API端点
- 不需要改变现有用户界面
- 保持了系统的轻量级特性
性能考量
虽然该方案查询效率很高,但团队仍然考虑了大规模部署时的性能影响:
- 查询频率优化:合理设置查询间隔,平衡实时性和系统负载
- 结果缓存机制:对不变的设备信息进行适当缓存
- 批量处理:对大量设备的查询结果进行批量处理
安全考虑
方案设计充分考虑了安全性:
- 所有查询都在设备本地执行,不暴露敏感信息
- 只读取必要的最小数据集
- 遵循最小权限原则
- 信息传输过程加密
实际应用效果
这一方案在实际测试中表现出色:
- 成功获取了测试环境中所有设备的Entra ID
- 与Intune的集成稳定可靠
- 对终端用户完全透明,无感知
- 系统资源占用极低
未来扩展性
该方案具有良好的扩展性,可以方便地支持:
- 其他Azure AD相关属性的采集
- 更丰富的合规策略检查
- 与其他MDM解决方案的集成
- 更细粒度的设备状态监控
总结
FleetDM通过创新的osquery查询方案,优雅地解决了Entra设备ID采集的技术挑战,实现了与微软Intune的无缝集成。这一方案不仅高效可靠,而且保持了FleetDM一贯的轻量级和易用性特点,为企业设备合规管理提供了强有力的工具。
登录后查看全文
热门项目推荐
相关项目推荐
AutoGLM-Phone-9BAutoGLM-Phone-9B是基于AutoGLM构建的移动智能助手框架,依托多模态感知理解手机屏幕并执行自动化操作。Jinja00
Kimi-K2-ThinkingKimi K2 Thinking 是最新、性能最强的开源思维模型。从 Kimi K2 开始,我们将其打造为能够逐步推理并动态调用工具的思维智能体。通过显著提升多步推理深度,并在 200–300 次连续调用中保持稳定的工具使用能力,它在 Humanity's Last Exam (HLE)、BrowseComp 等基准测试中树立了新的技术标杆。同时,K2 Thinking 是原生 INT4 量化模型,具备 256k 上下文窗口,实现了推理延迟和 GPU 内存占用的无损降低。Python00
GLM-4.6V-FP8GLM-4.6V-FP8是GLM-V系列开源模型,支持128K上下文窗口,融合原生多模态函数调用能力,实现从视觉感知到执行的闭环。具备文档理解、图文生成、前端重构等功能,适用于云集群与本地部署,在同类参数规模中视觉理解性能领先。Jinja00
HunyuanOCRHunyuanOCR 是基于混元原生多模态架构打造的领先端到端 OCR 专家级视觉语言模型。它采用仅 10 亿参数的轻量化设计,在业界多项基准测试中取得了当前最佳性能。该模型不仅精通复杂多语言文档解析,还在文本检测与识别、开放域信息抽取、视频字幕提取及图片翻译等实际应用场景中表现卓越。00
GLM-ASR-Nano-2512GLM-ASR-Nano-2512 是一款稳健的开源语音识别模型,参数规模为 15 亿。该模型专为应对真实场景的复杂性而设计,在保持紧凑体量的同时,多项基准测试表现优于 OpenAI Whisper V3。Python00
GLM-TTSGLM-TTS 是一款基于大语言模型的高质量文本转语音(TTS)合成系统,支持零样本语音克隆和流式推理。该系统采用两阶段架构,结合了用于语音 token 生成的大语言模型(LLM)和用于波形合成的流匹配(Flow Matching)模型。 通过引入多奖励强化学习框架,GLM-TTS 显著提升了合成语音的表现力,相比传统 TTS 系统实现了更自然的情感控制。Python00
Spark-Formalizer-X1-7BSpark-Formalizer 是由科大讯飞团队开发的专用大型语言模型,专注于数学自动形式化任务。该模型擅长将自然语言数学问题转化为精确的 Lean4 形式化语句,在形式化语句生成方面达到了业界领先水平。Python00
项目优选
收起
deepin linux kernel
C
24
9
Ascend Extension for PyTorch
Python
222
238
Nop Platform 2.0是基于可逆计算理论实现的采用面向语言编程范式的新一代低代码开发平台,包含基于全新原理从零开始研发的GraphQL引擎、ORM引擎、工作流引擎、报表引擎、规则引擎、批处理引引擎等完整设计。nop-entropy是它的后端部分,采用java语言实现,可选择集成Spring框架或者Quarkus框架。中小企业可以免费商用
Java
9
1
暂无简介
Dart
671
156
本项目是CANN提供的数学类基础计算算子库,实现网络在NPU上加速计算。
C++
661
312
React Native鸿蒙化仓库
JavaScript
261
322
🔥LeetCode solutions in any programming language | 多种编程语言实现 LeetCode、《剑指 Offer(第 2 版)》、《程序员面试金典(第 6 版)》题解
Java
64
19
仓颉编译器源码及 cjdb 调试工具。
C++
134
867
仓颉编程语言测试用例。
Cangjie
37
859
openGauss kernel ~ openGauss is an open source relational database management system
C++
160
217