intune

通过排错 Intune 80180014 了解注册限制

        今天 gOxiA 开通了一套教育版的 M365 测试环境,对其功能和特性进行简单和快速的体验。M365 for EDU 完全基于现有的 AAD、Intune 等云服务,在面向教育领域和其 IT 人员的操作页面等方面进行了优化,显得更为直观和友好。我们可以通过域名“https://intuneeducation.portal.azure.com”访问 Intune for Education 管理门户。当然也可以继续通过“Azure Portal”访问管理。

        在 Intune for Education 门户,我们可以通过“启动快速配置”为教育场景完成了应用的分配和客户端系统的配置。对于国内一些学校,其 IT 人员通常都由计算机课老师担当,虽然有一定的 IT 基础,但由于行业不同在上手配置时可能还是会存在一些问题,所以 Intune for Education 提供了换一套非常便捷的配置向导,可以帮助学校 IT 人员快速继续配置。

intune_edu_quicksetup

        接着 gOxiA 开启了一台安装有 Windows 10 Pro 1903 的虚拟机,在 Windows 10 的 OOBE 阶段通过“针对组织进行配置”进行了安装配置。这个过程非常简单。

8-1-lan-chooseaccount

        但在开始进行配置时发生了错误,服务器错误代码给出的是 80180014,通过微软官方文档“MDM 注册错误值”查询到该错误代码是因为“不支持特定平台(例如Windows)或版本。此错误的一般解决方法是升级设备。”针对这一提示,gOxiA 首先想到的“难道是因为需要Windows 10 教育版才能注册到 Intune for Education?!”,但回过神一想,很明显这个“认为”是错误的!!!即使真的对 Windows SKU 有限制,也应该是后台某个设置中对其进行了配置,所以我们需要进入后台去找到它。

intune_80180014

        如果进入的是 Intune for Education 的管理门户,将无法找到这些设置,正如前面 gOxiA 所讲的教育版也同样基于 Intune,所以我们需要转到 Azure Portal 下的 “Microsoft Intune” 管理界面。如果你经常与 Intune 和 Autopilot 打交道,相信会了解到一项管理功能 - “注册限制”,利用该项功能 Intune 管理员可以创建和管理注册限制,例如限制用户的设备注册数量,或注册设备的操作系统和版本。这些系统可以是基于 Android 的,也可以是基于 iOS/iPadOS 或 macOS 的,当然也包括我们常用的 Windows,此外还可以针对这些平台的版本进行限制。除此之外,还可以对注册的设备类型进行限制,如:公司拥有的设备COD),或 个人设备 即 自带设备办公(BYOD)。

        针对出现的故障现象,对“注册限制”策略进行了检查,发现评估环境默认会阻止个人设备的注册,为此更改为“允许”,保存后生效速度很快,可以马上在客户端进行测试。

intune_80180014-1

        如果作为 Intune 管理员需要结合公司安规对注册设备继续限制,例如需要对注册的设备系统版本进行限制,则参考如下:

  • Android 版本格式为:major.minor.rev.build
  • iOS/iPadOS版本格式为:major.minor.rev
  • Windows 仅对 Windows 10 支持 major.minor.build.rev(如:10.0.18363.657)

        注:要按照厂商进行配置,则可以输入厂商名称并以逗号进行分隔。


引用参考:https://docs.microsoft.com/zh-cn/intune/enrollment/enrollment-restrictions-set

ICD

使用 Provisioning Packages 帮助企业 IT 人员快速交付 Windows 10 设备

        在前段时间 gOxiA 分享了一篇文章 - “虚拟环境下在 Windows 10 OOBE 阶段测试部署 PPKG”,详细介绍了如何在虚拟机环境下 OOBE 阶段测试 PPKG 的方法。并且还分享了一些重点知识。今天我们将介绍使用 Provisioning Packages(预配包)帮助企业 IT 人员快速交付 Windows 设备。

        在过去的传统部署方案中,企业IT通常会根据组织的需求和规则策略重新定制标准化系统映像,在新设备到来后首先会进入 IT 桌面部门,通常会在 IT 服务台使用 WDS、MDT 或 SCCM OSD 等方案,重新为设备部署 Windows 操作系统。并且 IT 桌面部门还需要根据其他诸如业务或安全部门不断提出的新需求或变更重新生成映像。可以想象这是一件非常庞大且复杂的项目工作。

        自 Windows 10 发布以来,提出了 WaaS – Windows 即服务的概念,随之为这一“现代桌面”提供了一系列的“现代部署”方案可满足不同场景的需求。在这些方案中,IT 人员可以利用“动态部署方案”轻松便捷地为企业交付新的 Windows 10 设备。

        假设我们有一个场景,企业订购了一批新的 Surface 设备,其预装了 Windows 10 的专业版,随机搭载了 Office 应用程序,并且设备驱动也是内置的,由于随机系统非常干净,而且是最佳的运行状态,企业希望基于现有的系统进行定制和交付,由于 OEM 系统不支持映像的重新定制和生成,按照过去传统的做法企业IT桌面人员需要使用批量授权重新为 Surface 生成定制的企业标准化映像,这一过程所付出的工作量是相当繁重的,而且企业可能会重复使用专业版的授权。最后,企业IT桌面部门还需要不基于网络的部署。

        在以上这种场景下,如何选择一种快速高效的部署方法呢?!

        综合比较动态部署方案中的 Provisioning Packages(预配包)更容易满足这一部署场景的需求。利用预配包我们可以快速配置新的设备,而无需完成准备和安装新映像的过程;生成的预配包可以配置多个设备来节省时间;在准备和部署过程中不需要设备管理基础架构;预配包可以应用在没有网络连接的设备上。由于预配包是一个扩展名为 PPKG 的文件,我们可以多种形式进行预配包的分发,如:可移动磁盘,电子邮件,网络共享等。部署方式也随之灵活许多,除了可以双击预配包手动安装,也可以利用命令行编写脚本,尤为重要的是在 Windows 10 的 OOBE 阶段也可以应用预配包,这样一来我们就可以实现自动化的部署交付过程。

        到这里,您可能希望知道预配包都能为我们做些什么?是否可以像以往的部署方案那样利用 Unattend 实现无应答安装和配置,加载一系列的脚本程序进行高级的自动化配置……等等?!

        Provisioning Packages 为我们提供了丰富的预配设置选项,可以分配设备名称、输入产品密钥以升级 Windows,删除预安装的软件,连接到 WiFi,加入到 AD 或侦测到 AAD,当然也可以创建本地账号,还可以添加应用程序、证书……更多具体的细节可以参考微软官方文档。https://docs.microsoft.com/en-us/windows/configuration/wcd/wcd

        那么我们如何生成预配包(Provisioning Packages - PPKG)呢?如果您是一位经验丰富的桌面标准化 IT 人员,应该知道 Windows ADK,其中的“配置设计器”(Windows Configuration Designer - ICD)便是 PPKG 的生成工具。我们也可以在“Microsoft Store”中安装它“Windows Configuration Designer”。

icd-adk

        打开 ICD,默认会提供几个预配模板,如果是新手可以先从“预配桌面设备”开始,它提供了向导式的配置过程,可满足基本需求。通常 gOxiA 会使用“高级预配”来创建 PPKG 以满足不同的需求。

ICD-Main

        在“高级预配”模式下,通过左边提供的配置项来进行预配设置,如果您所需的需求未能满足,则需要考虑配合其他方法,如:命令行、脚本……或基于 AD 的组策略进行后续的配置管理。当预配包设计完毕后,就可以利用导出功能生成 PPKG 文件,在生成过程中我们可以为预配包起一个便于识别的名称,版本号会根据每次生成递增,利用“所有者”和“等级”我们可以为当前预配包设置优先级别。

ICD-Main-PPKG

        创建好的PPKG就可以按照前文介绍的那样以不同形式分发给用户,或在 OOBE 阶段应用。

正确认识和理解 Windows Hello 的人脸验证

        今天 gOxiA 来分享这个话题的起因是因为回到家中按照社区要求需要独自隔离14天,所以也就一直没有刮胡子,今天是最后一天于是一早在微信上发了一条关于 Windows Hello 的信息,说自己即使满脸长胡子也能够被 Windows Hello 识别出来,感觉非常惊喜。也正是因为这条信息,了解到圈里的一些朋友对微软的 Windows Hello 没有正确的理解,一直认为是与市面上其他识别技术一样采集“用户的图像”来进行比对认证,所以 gOxiA 认为非常有必要整理一下 Windows Hello 的知识,让广大用户正确认识 Windows Hello。

        本文不会做与其他识别技术的对比和分析,只从 Windows Hello 和 Surface 设备角度来进行介绍。

        相信大家有知道 Surface 的都会了解其出彩之一的功能特性就是带有支持 Windows Hello 人脸识别的红外摄像头(近红外传感器),通过 Windows 10 中的 Microsoft人脸身份验证(一种企业级身份验证机制)可以用来进行身份验证和解锁 Windows 设备,而且现在已经支持解锁 Microsoft Passport(在使用微软账号访问相关服务时可通过人脸识别进行登录验证)。

        那么在使用 Surface 的近红外成像摄像头(IR Camera)通过 Windows Hello 进行人脸识别登录时是怎样的一种机制或者说过程呢?!其会有普通大众所担心的安全问题吗?因为从开篇曾提到 gOxiA 的一些朋友会认为“这是一种采集更多人脸图片来进行比对的一种功能”,恐会担心隐私问题。那么接下来我们先了解 Windows Hello 的运行方式。

        首先,用户需要发起一个脸部识别的注册,如下图在 Windows 设置中找到 账户 设置,里面有个 登录选项,你就能看到 Windows Hello 人脸,它就是人脸识别注册入口。

faceid

        接下来 Windows Hello 会通过 Surface 的 IR Camera 识别人脸,其算法将检测 IR Camera 中的用户面部,然后找到与眼睛,鼻子,嘴巴等相应的面部界标点(也称为对齐点)。为了确保算法有足够的面孔来做出认证决策,还会识别头部的方向。然后使用地标位置作为锚点,这种算法将从人脸的不同区域获取数千个样本来构建表示,其基本形式的表示即直方图,表示特点点周围的明暗差异。

        可以理解,以上过程中通过人脸识别出来的只是一种“代表”,不是存储脸部的图像。通俗理解就是利用算法识别出当前脸部特征用作后续的验证,这一过程是生成自己的一个表示或一组表示的步骤(例如,如果我们有眼镜,则可能需要在不戴眼镜的情况下进行注册),这种表示形式的集合称为我们的注册资料,并存储在本地系统上以备将来比较。

        所以呢,进一步的认识是:微软不会且永远不会存储实际的图像来用于对比验证。而且,这些注册数据也不会发送到网站或应用程序进行身份验证。当然,也不用想什么脸部注册漫游了,不要指望换台电脑登录账号就能直接启用脸部识别,需要在当前设备的 Windows 系统上重新注册以生成脸部特征表示。

        接下来,当我们要通过 Windows Hello 进行人脸识别登录时,只需要面对 Surface 的 IR Camera,其会将获取的当前面部特征表示与当前设备系统上的已注册用户进行比较,该表示形式必须超过机器学习的阈值,然后算法才能将其接受为正确的匹配项。

        前面,我们提过在过程中要生成自己的一个表示或一组表示步骤,其中的"一组"表示步骤会发生在以下几个情形中,此时我们可以通过“提高识别能力”再次进行识别,例如摘掉眼镜做一次识别。

  • 偶尔戴某些类型的眼镜
  • 面部形状或质地发生了重大变化
  • 转移到周围环境光线较近的红外光下(例如:设备在室外阳光下)

        转回 Surface 来说说它采用 IR Camera 的好处或优势,可以通过下面几张图来进行了解。

        在以弱光为代表的如看电视或做PPT演示文稿情景下,使用普通摄像头和 Surface 近红外摄像头获取到的图像如下,可以看出 IR Camera 不会受到弱光和摄像头彩色成像系统的影响,能够生成清晰的图像。

hello1(普通摄像头获取到的彩色图像)          hello2(IR Camera 获取到的红外图像)


        下来,再看看如果在窗户或台灯前受到侧面照明时的情景,图像如下,IR Camera 仍能生成清晰完整的图像。

hello3(普通摄像头获取到的彩色图像)         hello4(IR Camera 获取到的红外图像)


        此外,由于使用了 IR Camera 还可以防止图像欺骗,因为红外采像时物体的波长会有所不同,也就是说你拿一张人像照片在 IR Camera 下是获取不到照片中的人像的,只能生成照片这个物体的外观,而其他材质下也是一样,例如手机的屏幕或者电脑屏幕。如下图所示:

hello5

        在测量精度方面,微软的 Windows Hello 又是如何做的呢?!它使用了三种主要度量:错误肯定,正确肯定,错误否定。

  • 错误肯定:有时也被计算为错误接受率,表示获得对你设备的物理访问权的随机用户被识别为你的可能性。该数字应尽可能的低。基线为小于0.001%或1/100000FAR。
  • 正确肯定:即:真实肯定率,表示用户每次位于传感器前面时,将正确匹配其已注册个人资料的可能性。该数字应该尽可能的高。基线为单个注册用户大于95%。
  • 错误否定:表示用户与他们的注册个人资料不匹配的可能性。该数字应尽可能的低。基线为单个注册用户不到5%。

        考虑到测量误差非常重要,因此微软还通过两种方式对它们进行了分类:偏差误差(系统误差)和随机误差(采样)。

  • 偏差误差:由于不使用 代表使用算法的环境和条件的数据,可能会导致偏差错误。此类错误可能是由于不同的环境条件(例如:照明,与传感器的角度,距离等)以及硬件导致的。
  • 随机误差:随机错误是由于使用的数据与实际使用该功能的总体多样性不匹配而导致的。(例如:专注于少数没有眼镜,胡须或独特面部特征的脸部。)


        通过以上内容的学习和理解,希望有助于大家正确认识 Windows Hello,排除误解。我们要知道 Windows Hello 的人脸识别技术不是靠存储图像来进行比对分析的!!!“Windows Hello 是科学、智能、严谨、合规,具备操守的。-- gOxiA”


引自微软官方文档:
https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/windows-hello-face-authentication

分页: 40/472 第一页 上页 35 36 37 38 39 40 41 42 43 44 下页 最后页 [ 显示模式: 摘要 | 列表 ]