正文
该员工入职以后，他所有的电脑和办公自动化软件就可以立即使用，并能迅速查找任何同事的联系方式。
可以想象，如果没有基于
整个组织
的
目录数据
，而需要他本人手动添加同事的电子邮件或者即时通讯地址的的话，将是效率低下而且容易出错的过程。
假设该员工入职以后需要报销入职的差旅费，于是他使用公司的电脑自动登录到相应的 ERP 系统提交了报销的表格和收据的照片，ERP 系统会将该报销请求以电子邮件的方式发到各级领导处等待批复，并发送通知短信。当报销单被批准后，ERP 系统会发邮件通知该员工。
在这个流程里面 ERP 系统需要获得员工和领导的电子邮件和手机号，而且可能根据组织结构图决定谁需要批复、谁需要收到抄送邮件等。可以看出，对于这样的 ERP 系统，一个可靠的目录服务是该类型软件业务逻辑的基础。
目录服务从广义上讲是一种提供通用对象信息的
数据库服务
，通常包括用户信息的浏览和查找、身份验证等功能。这种类型数据库一般来说有以下特性：
部分读者可能对微软的
活动目录 Active Directory
（以下简称 AD）有所了解，也许还知道早些年一个叫做 MCSE 的微软认证。
AD 是最具有代表性的目录服务，除了支持微软自己的多个服务器或客户端软件之外，也是大量第三方软件的用户平台。
但 AD 是 Windows Server 的一部分，是一套典型的
组织内部
部署的系统，也就是平时说的 on-premises 解决方案，并且对网络拓扑结构和安全模型都有要求，不容易用来支撑来自互联网的外部应用。
随着计算逐渐移到云端，企业 SaaS 应用的发展，验证方式和协议的完全 HTTP 化，
目录服务也顺应需求成为了云计算服务的一部分
。
微软借助其 Office 365 的市场地位，在 Azure 上推出了全托管（fully-managed，即客户完全通过 Internet 访问而无需关心物理服务器的部署）的
Azure AD
。
AWS 最初只提供基于 AD 的托管目录服务，后来也推出了完全自主设计的目录服务。
云目录服务促进了 SaaS 产品的开发和市场采用，同时也简化了行业（Line of Business）应用程序的开发和部署。一些面向个人用户的网站和服务在稍加修改后，也可以支持企业用户登录和使用。
理论上目录服务可以支持
任何对象类型
，但现实情况下
通用的数据类型
才有作为目录服务的价值。常见的数据类型包括：
-
用户 User
-
群组 Group （包括角色 Role）
-
应用程序 App （一般意义上指 OAuth 中的 app）
-
程序账户 Service Account 和 Security Principal
-
设备资源 Device（包括会议室、仓库、打印机、工作站、货车、IoT 等）
基于这些基本对象可以实现大量的办公自动化和 ERP 相关的功能，举几个最简单的例子：
