GINA 与 pGINA——实现自定义的 Windows 用户身份认证

2010/05/03 | 01:08 | 分类:Windows开发 | 标签: | 599次阅读

  最近接触到一个 Windows 平台下的开源项目——pGINA。鉴于网上没有较为完整的中文介绍,特在此推介一下。
  要知道 pGINA 做什么,首先需要了解 Windows 的用户管理框架。相关资料推荐阅读 Microsoft Windows Internals,这里不再赘述,只给出我列的一张 Linux 与 Windows 用户管理中的对应技术表格供熟悉 Linux 的开发人员参考。其实 Windows 也像 Linux 一样,开放了用户身份认证与用户管理系统的接口,允许第三方如同开发 Linux PAM/NSS 那样,为 Windows 开发新的认证入口(GINA)与认证包(Windows Authentication Packages)。

Linux 与 Windows 用户管理中的对应技术
  Linux Windows
登录程序 * login Winlogon
认证入口 PAM (Pluggable Authentication Modules) GINA (Graphical Identification and Authentication)
默认认证模块 pam_unix.so msgina.dll
用户系统入口 # NSS (Name Service Switch) LSASS (Local Security Authority Subsystem Service)
默认本地用户系统 files (/etc/passwd, /etc/group, /etc/shadow) SAM (Security Account Manager)
常用目录用户系统 LDAP (Lightweight Directory Access Protocol) AD (Active Directory)
* 仅以 Linux 本地 shell 登录和 Windows 本地图形界面登录为例
# NSS 与 LSASS 功能并不相同,只在用户认证的流程中的位置相似

 
  然而,我们能在网上找到的开源的 GINA 模块和认证包的相关资料远不如 PAM/NSS 丰富,找到的第三方实现几乎都是软硬件厂商用于接入自己基础设施的闭源专有软件(例如某些笔记本电脑的指纹认证)。这一方面可能出于微软商业风格与 Linux 开源风格的差异;而单从技术上看,微软“大而全”的 API 风格相比 Linux 的 KISS 风格对于简单的示例性或改进性开发无疑是一道壁垒。完整的 GINA 模块需要实现数十个接口,而系统中一次只能配置一个有效的 GINA,不像 PAM 那样可以通过配置文件灵活地组合使用只关注特定功能(认证、账户、密码或会话)的小模块。因此连微软自己的文档也告诫开发者,在编写新的 GINA 模块之前看看能不能用 Hook 之类偏 Hack 的技术实现自己所需的功能。
  正是由于 GINA 开发的繁琐性,才蕴生了开源的 pGINA 框架。pGINA 本身是一个 GINA 模块,它提供了一致的图形界面,并将 GINA 的数十个接口二次抽象为几个简单易懂的接口(密码认证、密码修改、会话 Hook 等),允许二次开发人员利用这些接口开发插件,实现自定义的认证交互程序。pGINA 只适用于以密码作为认证凭证,在这一前提下,其功能可以涵盖 GINA 接口的主要功能点(认证管理、密码管理、屏幕锁定等),而且图形界面交互的开发也由必须变为可选。因此,使用 pGINA 将在很大程度上简化自定义用户认证机制的开发。对于最终用户,只需要安装 pGINA 并配置指定的插件,即可使用新的用户名/密码源取代 Windows 默认的 SAM 用户名/密码认证。
  pGINA 的作者和其他志愿者已提供了十余种开源的 Windows 用户认证插件,例如基于既有 LDAP、MySQL、FTP、SSH 用户系统的认证,甚至基于 Slashdot 账号的认证等,可供开发者学习或修改。对于认证通过但在本地系统中尚不存在的用户,pGINA 的默认行为是为之自动创建新账户,这在一些公共计算机中比较有用。
  pGINA 针对 Windows XP 的 1.X 版本代码已在 2006 年底稳定冻结,我测试多个插件(包括自己实验开发的插件)工作正常。而针对 Windows Vista 和 Windows 7 的 2.X 版本目前正在持续开发中(Alpha 阶段),我测试发现部分旧插件不能正确运行。
  有关 pGINA 的 GINA 模块、插件、源代码和开发资源,可在其 SourceForge.net 页面下载。pGINA 给出了 M$ Style to KISS Style 的一个良好范例。

智器(SmartQ)V5 使用半月杂记

2010/02/26 | 23:45 | 分类:IT杂谈 | 标签: | 2,860次阅读

  年前购入一台 智器(SmartQ)V5,使用已有半月。
  我购买 MID 的目的比较明确:折腾为主,实用为辅。
  ● 折腾方面,自然要安装通用的、开放的操作系统,既方便安装应用,也方便开发调试。同时需要提供简单的刷写机制以便在系统级做点文章。同时我对 Android 系统挺有兴趣,也想借此了解学习一下。
  ● 实用方面,主要是在外出或长途旅行时方便上网。WiFi 当然是 MID 的标配,不过国情所限,WiFi 的羽翼在绝大多数户外场合无处施展。因此,3G 网络成为我考虑的重要因素。
  最后是价格,1500 元之内。如果不考虑价格,确实有不少基于 Atom 的、内置 3G 模块的 MID 或 UMPC 可供选择。但我的原则还是应将经济因素列为硬性指标。
  基于这些限制,我最终选择了国产非知名品牌的智器 V5。
智器(SmartQ)V5 使用半月杂记
  我最早了解智器这个品牌是在山寨机网,因此智器给我留下的第一印象便是山寨厂商。这次选机时才发现智器原来是一家有地址、有电话、有网站的相对正规的公司。智器 V5 相比同类产品性价比很高:1000 元出头,配置 ARM11 600MHz 处理器、256MB 内存、2G 闪存、4.3 寸 WVGA 触屏、WiFi、蓝牙、USB(Host Mode & On-The-Go)、HDMI、SD(SDHC),预装 Ubuntu、Windows CE、Android 三系统。虽然没有内置 3G 模块,但可以通过 USB 连接 3G 上网卡,应急时也可使用蓝牙连接手机 GPRS 上网。三个系统各取所长,实用性与可折腾性得到平衡。
  不过这个价位的产品,缺点还是有不少。在购买之前我就已经从其论坛上做了仔细了解:产品做工不佳,尤其是 SD 卡插口无法合上的盖子以及手感明显不一的几个按键。单点触摸的电阻屏,不利于保护屏幕,也无法享受到 Android 的一些高级用户体验。续航能力有限,2000mAh 的电池用来上网也就 2、3 小时,而看视频的话几乎不能保证一部电影的时间。操作系统配置粗糙,预装软件杂而不精,响应速度慢,感觉很“卡”,等等。对于做工的问题,国产小品牌就不要强求了,我们要体谅中国的制造业。电阻屏的问题,主要还是受限于我所划定的价位,贴个膜防划伤吧。电池的问题,看视频不是我的主要需求,长途旅行时可以使用外置电池盒,也将就着吧。至于软件配置和响应速度,我倒认为不是问题。系统和软件是可以配置修改的,而像我这种在 Nokia 6600 上运行一堆后台程序,在五年前买的笔记本上跑 Windows 7 或 Compiz 的用户,对“卡”的敏感度远低于潮人们。
  购入之后,我自然为之选配了 3G 上网卡与外置充电电池(这些也涵盖于 1500 元预算之内)。3G 选择联通 WCDMA,主要还是考虑过年回家的网络覆盖情况。4400mAh 外置充电电池可以保证我 30 小时左右的车程不至于太无聊(充电线 DIY)。注意照片中还有一个 USB 有线网卡,这个遗留资产遇到智器时还是能够发挥一点余热的,特别是在没有 WiFi 覆盖的宿舍里。
  【实用场景一】 回家的 T69 列车上,用智器上网兼测试铁路沿线的 WCDMA 覆盖。京广、陇海沿线,有城镇乡村的地方半数以上能够搜到 WCDMA 信号。列车行驶中网络连接畅通,即使信号一时中断,也能自动恢复,无需重新拨号。而兰新线以及返程 K44 所走的包兰、京包沿线的情况则要差一些,当然这一线的城镇密度也远低于东部地区。
  【实用场景二】 打的从嘉峪关到酒泉的路上,嘉峪关本地的司机不甚清楚我家的所在的小区怎么走(事实上在酒泉居住总时间不到半年的我,也不清楚应该怎么走)。这时我打开智器,联网秀出地图,司机随即确定了路线。
  【实用场景三】 边从电视上看春晚,边从智器上看推友的热议。在看到推友贴出的刘谦魔术揭秘视频链接时,旋即点击播放。
  作为成天与 Linux、Windows 及 Symbian 打交道的用户,使用智器一项重要体会就是 Android 的用户体验。在单点触摸、无重力感应、无 GPS、无电话功能的设备上,Android 的易用性依然远优于并非为掌上设备定制开发的 Ubuntu 和 Windows CE。特别是移动版的 Google 应用令我这个坚守了 S60v2 五年的用户眼前一亮(虽然玩过无数同学的 iPhone,但手里拿着一个属于自己的设备,这种“指”点江山、“掌”控天下的感觉才算最得意的)。
  至于折腾场景,等闲下来再着手研究。从智器论坛上看,还是有不少闲人在智器的早期产品上玩出些花样的。权当它是一个功能完善的 ARM 开发板吧。

解决 IPv6 路由发现协议得到错误地址的问题

2010/01/15 | 23:59 | 分类:Windows应用 | 标签: | 854次阅读

  IPv6 环境一般使用 DHCPv6ICMPv6 协议自动配置网络参数,网关配置错误或多个网关的存在会导致客户端得到错误或冲突的配置参数。最近在我使用的 IPv6 环境中,就出现了网关同时给一个客户端分配多组 IPv6 地址、两个 IPv6 路由的问题,这使得路由发生混乱,IPv6 网络无法连通。由于种种原因,网管一直未能解决此问题,我们只好试图在客户端动动脑筋。
  按照 IPv4 的经验,如果 DHCP 有问题,直接手工配置静态地址即可。但我们的环境中,即使手工配置了静态的 IPv6 地址和路由,发现没过多久又会恢复原状。看来还是有一定的自动配置机制在作祟。经搜索得知,这是 ICMPv6 的路由发现(Router Discovery)特性,系统会根据其收到的 ICMPv6 包自动修改 IPv6 配置。下面要做的就是过滤与路由发现相关的包。
  在 Linux 下,可以使用 ip6tables(即 iptables 的 IPv6 版本)过滤相应的 ICMPv6 包:

  1. /sbin/ip6tables -A INPUT -p icmpv6 --icmpv6-type router-advertisement -j DROP

  可以将上述命令加入 /etc/rc.local。或使用 ip6tables-save 导出到文件,在启动网络前使用 ip6tables-restore 恢复。
  在 Windows Vista/7 或 Windows Server 2008 以后的版本,可以使用这条命令:

  1. netsh interface ipv6 set interface "[你的网卡名称,比如 Local Area Connection]" routerdiscovery=disable

  执行一次之后持久生效,重启后不用再次执行。
  而在 Windows XP 下,目前还没有发现很好的办法。XP 对 IPv6 的支持仅仅是一个“预发行版”,实现并不完善。手工配置 IPv6 地址和路由只能使用“ipv6 adu”、“ipv6 rtu”命令,而没有图形界面支持;虽然 XP SP2 以后 Windows 防火墙加入了 IPv6 支持,但仍不支持 ICMPv6。我没有查到 XP 下屏蔽路由发现协议的标准方法,目前可行的办法是使用支持 ICMPv6 的第三方防火墙软件,比如 ZONEALARM Internet Security 8 以上版本。

Windows Live Messenger drag & drop 小技巧

2009/06/16 | 21:35 | 分类:Windows应用 | 标签: | 822次阅读

  无意中发现 Windows Live Messenger 的一个小技巧:把联系人拖放到 gtalk 或 Fetion、Baidu Hi 的聊天窗口本文输入框中,相应区域就会显示这个联系人的 Live ID(Email)。其实 Windows 的 drag & drop 的原理挺简单的,但 Live Messenger 使用文本格式的 drag & drop 数据,这倒是增强了程序的互操作性。Fetion 和 Baidu Hi 的联系人也是可以 drag & drop 的,但它们使用的是封装过的对象,所以不能把账号什么的以文本形式拖放到别的软件的窗口中。有趣的是,Live Messenger 不能把联系人的 Live ID 拖放到自身的聊天窗口中,如果拖放到非文本区域代表的是加入多人会话。
  顺手写了一个查看 drag & drop 信息的小程序(需要安装 .Net Framework 3.5),含 C# 源代码,需要的朋友可以下载:
  http://files.linjian.org/dotNet/dragdroppad.zip
  http://www.linjian.cn/files/dotNet/dragdroppad.zip
Windows Live Messenger drag & drop 小技巧

试用Windows的UNIX/POSIX子系统(SUA)

2009/05/04 | 20:07 | 分类:Windows应用 | 标签: | 2,393次阅读

  以前研究Windows的基本概念时,我就知道它有一个POSIX子系统,可以在Windows下编译运行使用了POSIX库的程序。但这一直停留在书本概念层面,直到昨天看到Jeep同学的Windows系统上安装了一个Subsystem for UNIX-based Applications时,我便决定也安装试用一下。
  有关Windows的POSIX子系统是什么、怎么用的问题,可以参考Wikipedia或Microsoft TechNet [英文][中文]上的介绍。它历经了NT时代的Microsoft POSIX subsystem、XP/2000时代的Microsoft Windows Services for UNIX (SFU)以及2003 R2/Vista/2008时代的Subsystem for UNIX-based Applications (SUA)等版本,对POSIX标准的支持日臻完善。我的系统是来自MSDNAA/IEEE的Windows Server 2008,自然要使用最新版的SUA。至于SUA和cygwin在实现机理和功能性能上有什么区别,我还没有仔细研究。但从直观感觉上,Windows原生支持的SUA是比cygwin快一点儿;按照Wikipedia上的这个说法,cygwin是对POSIX是“partial”兼容,而SFU/SUA则是“full”兼容。
  很多人安装SUA的目的并不是要向Windows移植什么重要的UNIX/Linux应用,有时候我们仅仅是为了在Windows中使用一个类UNIX的Shell以及丰富的GNU utilities,毕竟这类久经考验的命令行工具比Windows Command Prompt的那些命令好使很多。对于工作环境要求在Windows和Linux间来来回回切换的人们,也省得敲错命令。安装SUA之后,预装的Shell是C Shell和Korn Shell,还安装了包括vi、gcc在内的300多个命令行工具。同时,Windows的Path环境变量中自动添加了SUA相关目录,这样在Windows Command Prompt和Power Shell中也可以使用很多GNU utilities了。当然,UNIX Shell的内部命令是不可以在这里使用的。此外,在Power Shell中,Power Shell命令别名(如ls、cp)会优先于同名的GNU utilities调用。总之,使用SUA或cygwin这类UNIX Shell+GNU utilities的模拟环境,相比手工添加的“容错”命令或者GnuWin32这类独立命令级的移植要“真实”和顺手得多,但缺点就是体积庞大。
  为了检验SUA的能力,我拿我相对熟悉的GNU bash做了实验。从官方下载bash-4.0版源代码,在SUA的C Shell环境中解压,运行./configure通过。但在make时报错:

  1. execute_cmd.c: In function `time_command':
  2. execute_cmd.c:1145: error: storage size of `dtz' isn't known

  查看execute_cmd.c源代码,发现这句代码有注释:

  1. struct timezone dtz; /* posix doesn't define this */

  看来这个struct timezone不是POSIX标准的东西。通过上下文,我发现这里是处理time(计时)关键字的函数。于是查看configure的帮助,得知只要加一个“--disable-command-timing”参数即可禁用time关键字(这时输入time将改用/bin/time程序做计时)。再次make,execute_cmd.c通过,但又出现以下错误:

  1. getcwd.c: In function `_path_checkino':
  2. getcwd.c:80: error: `MP_RMDOT' undeclared (first use in this function)
  3. getcwd.c:80: error: (Each undeclared identifier is reported only once
  4. getcwd.c:80: error: for each function it appears in.)

  查看./lib/sh/getcwd.c的源代码,果然没有找到MP_RMDOT宏的定义。在全部源代码中搜索,发现这一定义在externs.h中,在./lib/sh/makepath.c中也有使用,唯独在./lib/sh/getcwd.c中使用了却没有引用其定义。也许这是bash-4.0的一个bug?使用Linux下的gcc编译连接是通过的,但SUA下的gcc版本也许有更严格的名字连接策略,导致无法编译通过。于是我将“#define MP_RMDOT 0x04”的定义手工加入./lib/sh/getcwd.c,再次make,全部通过。实验运行无误!
  需要注意的是,SUA提供的是编译和运行使用了POSIX库的程序的环境,并不提供UNIX二进制文件的运行支持。它编译生成和支持运行的可执行文件仍然是Windows的PE格式,而不是ELF之类。SUA支持的只是仅使用了标准库和POSIX库的程序的源代码级移植,对于使用了Linux等环境特有的系统调用的程序,也不可能不加修改地编译运行。
  有空再研究一下SUA在我们的工程中能有什么实际点的应用。

页面存档: 上页 1 2 下页