闹心的ldap
最近领导要求使用ldap来解决多个系统n个账号的问题。一搜一箩筐。现在也没找到ldap到底是谁负责,谁维护、官方网站是哪个,
网上一搜一大堆,各种解释而且都不系统,介绍也不统一。
但很多开源的软件还支持他,硬着头皮上。。。下面的是各个博客复制粘贴和自己总结的一些。希望能给入坑的小伙伴一些提示就好。
我主要是粘贴到一起省的来回搜索和翻找了,如果侵权请通知我删除。
定义
别人的话:简单说LDAP首先它是一种协议.它是一种关于数据存取的协议.它存取的内容是目录.
这里的目录是一种广义的,可以指具有层次结构的任何数据.
自己的理解就是咱们电脑里面的文件夹层次,因为理解了多年的关系型数据库,所以总也绕不过来。
目录服务器
目录服务器(在技术上更称为目录服务器代理,目录系统代理或DSA)是一种网络数据库,用于存储表示为条目树的信息。
基本术语
条目(Entry)
条目(Entry)就是目录管理的对象,他是LDAP中最基本的单元,就像字典中的词条,或者是数据库中的记录。通常对LDAP的添加、删除、更改、检索都是以条目为基本对象的,它是有关实体的信息的集合。
每个条目包含三个主要组成部分:唯一的标识名或者专有名称(dn),属性集合(Attributes)和对象类集合(Object Classes)。下面将更详细地描述这些内容。
DN
条目的专有名称(通常称为DN)唯一标识该条目及其在目录信息树(DIT)层次结构中的位置。LDAP条目的DN非常类似于文件系统上文件的路径。
每一个条目都有一个唯一的标识名(distinguished Name ,DN),:比如cn=ceshi,dc=bjpxw,dc=com。
DN在语法上是由零个或多个相对的标识名(relative distinguished Name ,RDN)组成的,他们之间由逗号分隔。如果把DN看做对象的全路径,那么RDN就是其中的每一段路径。通过DN的层次型语法结构,可以方便地表示出条目在LDAP树中的位置。有时在不一致引起歧义的情况下,RDN也特指DN中最靠前的一段,而剩余的部分称为父标识(Parent DN,PDN)。
RDN本身也可以由一个或者多个(通常是一个)值构成,用 + (加号) 分隔,
例子1 :uid = zhangjuntao,dc=bjpxw,dc=com 表示由名称为“uid” 的属性组成的RDN,其值为“zhangjuntao”
例子2 :OU=Tech+CN=zjt,dc=bjpxw,dc=com中的RDN为OU=Tech+CN=zjt,由2个值OU=Tech和CN=zjt组成,他们之间由+(加号)隔开。
如果DN中含有一些特殊字符,比如:,=+<>;\”,他们需要转转义符(\)来帮助表述。
由零个RDN组成的特殊DN(因此具有一个表示为空字符串)有时被称为“空DN”,并引用一种称为根DSE的特殊条目,该条目提供有关以下的内容和功能的信息:目录服务器。有关根DSE条目的更多信息,请参见DIT和LDAP根DSE。
https://ldap.com/dit-and-the-ldap-root-dse/
属性(Attributes)
属性类型
属性类型约定属性值的数据格式和语法类型(Syntax)。 指定可存储在该类型的属性中的数据的类型
比如,属性cellPhone的类型为telephoneNumber,它规定了电话号码是由数字组成的,其中允许插入一些分隔符,如连接符、括号、空格等。
属性类型是架构元素,用于指定LDAP客户端和服务器应如何对待属性。所有属性类型都必须具有一个对象标识符(OID)以及零个或多个可用于引用该类型属性的名称。
属性类型还必须具有一组匹配规则,这些规则指示应如何对该类型的属性值进行比较。
大致意思就是比较的时候是否区分大小写,比如zjt 和ZJT 电话号码数字是否注意- 等等问题
属性类型还可以指示在同一条目中是否允许一个属性具有多个值,多值属性类型也可以使人员信息的组织变得更加灵活并接近现实情况,比如:人员的手机、地址、邮箱等属性都可以有多个值。这样,用ldap组织的信息会比简单的表结构更加理想。
了解架构请查看 https://ldap.com/understanding-ldap-schema/
属性值保存条目的数据,
可以有很多属性(Attribute)比如常见的人都有姓名、地址、电话等属性。每个属性都有名称及对应的值,属性值可以有单个、多个。比如你有多个电话。
LDAP为人员组织机构中常见的对象都设计了属性(比如commonName,surname)。下面有一些常用的别名
属性 | 别名 | 语法 | 描述 | 值(举例) |
commonName | cn | Directory String | 姓名 | sanfeng |
surname | sn | Directory String | 姓 | Zhang |
organizationalUnitName | ou | Directory String | 单位(部门)名称 | Tech |
organization | o | Directory String | 组织(公司)名称 | AAA |
telephoneNumber | Telephone Number | 电话号码 | 110 | |
owner | DN | 该条目的拥有者 | cn=sanfeng,ou=ops,dc=bjpxw | |
jpegPhoto | Binary | JPEG照片 | .. |
关键字 | 英文全称 | 含义 |
dc | domain component | 域名的部分,将域名分成几部分 |
ou | organization Unit | 组织单位 oa组 部门 |
uid | userId | 用户的id zjt (一个记录的id) |
cn | common name | 公共名称 (一个记录的名称) 常用名称 (继承自person对象的对象类必须有值的属性,否则无法创建) |
sn | sarname | 姓 或者真实姓名 全名(继承自person对象的对象类必须有值的属性,否则无法创建) |
dn | distinguished name | 一条记录的位置,全局唯一 节点绝对路径,例如:uid=admin,ou=users,dc=eruipan,dc=com |
o | Organizational | 组织 |
ObjectClass | 对象类(不同的对象类存在某些不同的属性,根据自己需要选择对象类) |
objectClass
解释版本1
对象类是模式元素,它们指定可能与特定类型的对象,过程或其他实体相关的属性类型的集合。每个条目都有一个结构化的对象类,该类指示一个条目代表什么类型的对象(例如,是否是有关一个人,一个组,一个设备,一个服务等的信息),并且还可以具有零个或多个辅助对象类提示该条目其他特征的类。
通过对象类可以方便的定义条目类型。每个条目可以直接继承多个对象类,这样就继承了各种属性。如果2个对象类中有相同的属性,则条目继承后只会保留1个属性。
对象类同时也规定了那些属性是基本信息,必须含有(Must 或者Required,必要属性)
(以便具有该对象类的任何条目也必须包括那些属性)
对象类同时也列出了哪些属性是扩展信息,可以含有(May或Optional,可选属性)(以便具有该对象类的任何条目可以有选择地包括那些属性)。
对象类(ObjectClass)是属性的集合,LDAP预想了很多人员组织机构中常见的对象,并将其封装成对象类。比如人员(person)含有姓(sn)、名(cn)、电话(telephoneNumber)、密码(userPassword)等属性,单位职工(organizationalPerson)是人员(person)的继承类,除了上述属性之外还含有职务(title)、邮政编码(postalCode)、通信地址(postalAddress)等属性。
与属性类型一样,对象类必须具有对象标识符
解释版本2
LDAP目录中的每个对象都有至少一个与之关联的对象类。对象类确定该对象的特征,尤其是对象可以具有的属性集(以及它必须具有的属性)。
对象类是在LDAP目录模式中定义的-它们在那里构成一个类层次结构,存在一个中央顶级类(称为“ top ”),所有其他类均从该类派生。
这导致一个事实,通常某个类的每个对象实际上都具有所有父类,也都具有关联的类。如果查看所有LDAP目录中所有对象都存在的' objectClass '属性,则会看到以下信息:
这些对象类之一是定义对象性质的主类,有时也称为“ 结构类 ”。某些目录为每个对象存储一个名为structureClass的属性-在其他目录环境中,您可以从类在多值属性objectClass中的存储顺序中得出主对象类。
objectClass有着严格的等级之分,最顶层是top和alias。
例如,organizationalPerson这个objectClass就隶属于person,而person又隶属于top。
objectClass可分为以下3类:
结构型(Structural):如person和organizationUnit;
辅助型(Auxiliary): 如extensibeObject;
抽象型(Abstract):如top,抽象型的objectClass不能直接使用。
在OpenLDAP的schema中定义了很多objectClass,下面列出部分常用的objectClass的名称。
- account
- alias
- dcobject
- domain
- ipHost
- organization
- organizationalRole
- organizationalUnit
- person
- organizationalPerson
- inetOrgPerson 用户基本都是这个家伙了
- residentialPerson
- posixAccount
- posixGroup
关于人的objectClass
原来用户的ObjectClass,有三种:Person、OrganizationalPerson、inetOrgPerson。三种ObejctClass都可以用来表示人。从属性数量的角度来说,inetOrgPerson的属性最多、Person的属性最少。
如果将其中一支 top–>person–>organizationalPerson–>inetOrgPerson的必要属性和可选属性列表(下表),就会发现这种设计还是非常合理的。我们可以从任何一个对象派生出自己的对象类,比如organizationalPerson派生出职工(employee)对象类,那么它可以含有工号(employeeNumber)、工种(employeeType)等属性。注意,对象类继承的时候会把属性是必须(Must)还是可选(May)的特性也一并继承。也就是说person有cn和sn两个Must属性,organizationalPerson和inetOrgPerson由于直接或间接继承了person,也会有这两个Must属性。
对象类 | 必要属性(Required) | 可选属性(Optional) | ||
top | objectClass | 无 | ||
person | cn | description | seeAlso | telephoneNumber |
sn | userPassword | |||
organizationalPerson | 无 | destinationIndicator | facsimileTelephoneNumber | internationalISDNNumber |
1 | ou | physicalDeliveryOfficeName | ||
postalAddress | postalCode | postOfficeBox | ||
preferredDeliveryMethod | registeredAddress | st | ||
street | teletexTerminalIdentifier | telexNumber | ||
title | x121Address |
对象类 | 必要属性(Required) | 可选属性(Optional) | ||
inetOrgPerson | audio | businessCategory | carLicense | |
departmentNumber | displayName | employNumber | ||
employeeType | givenName | homePhone | ||
homePostalAddress | initals | jpegPhoto | ||
labeledURL | manager | |||
mobile | o | pager | ||
photo | preferredLanguage | roomNumber | ||
secretary | uid | userCertificate | ||
userOKCS12 | userSMIMECertificate | x500UniqueIdentifier |
1.6、模式(Schema)
模式(Schema)、其他说明对象标识符(OID)、搜索过滤器、搜索基本DN和范围、修改和修改类型、LDAP URL、控制项、推荐人、别名条目就不说明了,以后有时间就补充。
学习资源
Ldap中文网 http://www.ldap.org.cn/
英文网站 www.ldap.com 很全也很系统,直接google翻译
客户端工具
Apache Directory Studio https://directory.apache.org/studio/ 这个软件各种不太会用 推荐指数 ★★★
phpldapadmin docker 镜像 dinkel/phpldapadmin 这个 推荐指数 ★★★★
php https://www.php.net/manual/zh/function.ldap-add.php ★★
java 、python (不会)^ - ^ 推荐指数 ★★
bash ldap 等等 推荐指数 ★★
别人示例1
这里我们将会聚焦于下图灰色部分的创建,这也是实际项目中使用的最多的一种,在这系列的文章中将会使用openldap的osixia的镜像所内置的缺省的dc: example.org(这里的信息是openldap官方例子的信息,在例子中我们实际使用的是example.org而不是example.com)。通过设定环境变量即可简单改变此处,因为此部分更多与LDAP基本服务设定相关,所以使用客户端的命令或者编程接口对其进行操作的部分主要聚焦于从Organisation开始的部分。
————————————————
原文链接:https://blog.csdn.net/liumiaocn/article/details/83990960
示例
dn: dc=contoso,dc=com
dc: contoso
objectClass: top
objectClass: domain
# People, contoso.com
dn: ou=People,dc=contoso,dc=com
ou: People
objectClass: top
objectClass: organizationalUnit
# Group, contoso.com
dn: ou=Group,dc=contoso,dc=com
ou: Group
objectClass: top
objectClass: organizationalUnit
# zhangsan, People, contoso.com
dn: uid=zhangsan,ou=People,dc=contoso,dc=com
objectClass: posixAccount
objectClass: top
objectClass: inetOrgPerson
givenName: zhang
sn: san
displayName: zhang san
uid: zhangsan
homeDirectory: /home/zhangsan
loginShell: /bin/bash
physicalDeliveryOfficeName: 1001
o: contoso.com
title: IT
cn: zhang san
uidNumber: 16474
gidNumber: 10001
userPassword:: 123456