openldap用ACL控制访问权限.docx

OpenLDAP：用ACL控制访问权限说明：这段时间我在学习Openldap的知识，关于访问控制权限这一块遇上较大的麻烦。我在网上看到了一些人的帖子，有些写的不错，有些写的不全，还有些完全是照抄别人的，还不注明出处。因此我把我搜集到的东西整理出一个文档，献给各位正在学习openldap的朋友，我的初衷是回馈社会，支持免费和开源，水平有限，诸多包涵。我所引用到的东西，我都将注明出处，感谢提供我信息的人，我想说，you are the greatest。第一部分 语法综述1.用ACL控制授权我们在LDAP中创建目录树后,最感兴趣的就是如何控制用户在目录树中的权限(读写)。谁在什么条件下有记录权限，我们有权限看到哪些信息。ACL（Access Control List）访问控制列表就是解决用户权限问题的。2.我们要把ACL写在哪里？ACL写在OpenLDAP的服务端全局配置文件slapd.conf中，如下这段即为其指令：# access to dn.base= by * read# access to dn.base=cn=Subschema by * read# access to *# by self write# by users read# by anonymous auth也可以写在一个单独的文件中，如access.conf，然后在全局配置文件slapd.conf中调用，在配置文件中引入这个文件即可，如下：include /etc/openldap/access.confinclude后面的路径为该文件的放置地址。3.ACL语法基础怎么看懂ACL指令？首先看下ACL访问指令的格式：#access to resourcesby who type of access granted controlby who type of access granted control# More by clauses, if necessary.#指令中包含1个to语句，多个by语句。这个指令的大体意思是，通过access to约束我们访问的范围（resources），通过by设定哪个用户（who）获取对这个约束范围有什么权限（type of access granted）,并控制（control）这个by语句完成后是否继续执行下一个by语句或者下一个ACL指令。Access to resourcesresources可以有多种形式，如DN，attrs，Filters.以下即详细说明。3.1.通过约束DN进行访问（同层级访问）如下所示，access to dn=uid=matt,ou=Users,dc=example,dc=comby * none这个指令是指访问uid=matt,ou=Users,dc=example,dc=com这个DN，即把访问的范围约束在这个DN中。by * none是指对于任何人的访问都是拒绝的。总体的意思就是，任何人都没有权限访问uid=matt,ou=Users,dc=example,dc=com这个DN，当然，服务器管理员是可以访问的，不然它无法维护这个OpenLDAP中的用户信息。再来看一个，access to dn.subtree=ou=Users,dc=example,dc=comby * none在这个例子中，我们用了dn.subtree。在我们的目录信息树中，在ou=Users子树下可能有多个用户。举例来说，DN为uid=matt,ou=Users,dc=example,dc=com就是ou=Users, dc=example,dc=com的子树，当要试图访问他时，这个ACL指令就起了作用。总体的意思是，任何人都没有权限访问ou=Users，dc=example,dc=com以及其子树的信息。#dn.base: Restrict access to this particular DN. This is the default, anddn.exact and dn.baselevel are synonyms（同义词）of dn.base.dn.one: Restrict access to any entries immediately below this DN.dn.onelevel is a synonym.dn.children: Restrict access to the children (subordinate) entries of this DN.This is similar to subtree, except that the given DN itself is not restricted by the rule.以上内容意思是，dn.base: 约束这个特定DN的访问。他和dn.exact和dn.baselevel是相同的意思。dn.one: 约束这个特定的DN第一级子树的访问。dn.onelevel是同义词。dn.children: 这个和dn.subtree类似,都是对其以下的子树访问权的约束。不同点在于，这个的约束是不包含自己本身DN。而subtree包含了本身的DN。#对于dn的约束条件还可以利用模糊约束，如下：access to dn.regex=uid=,+,ou=Users,dc=example,dc=comby * nonedn.regex是用来做匹配（match）用的。这个指令将约束所有uid=(任何值),ou=Users,dc=example,dc=com的DN，其中的任何值是用 ,+ 这个符号组合来表示的，他可以代表任何至少有1个字符，且字符当中没有逗号（,）的值。更明确点说，意思就是在ou=Users,dc=example,dc=com这个DN下的所有以uid为属性的一级子树都属于这个约束的范围。3.2.通过约束attrs访问（跨层级访问）对于DN的约束大多用在对某个层级的约束，而用attrs的话，就可以跨层级（或者说跨越父类树），通过属性来约束访问的范围。access to attrs=homePhoneby * none这个例子意思是，任何人都没有权限访问属性为homePhone的信息。在attrs后面的值可以多个，如access to attrs=homePhone,homePostalAddress如果想约束某个对象类(Object class)的所有属性，我们或许可以有这样的形式：access to attrs = title, registeredAddress, destinationIndicator,但这个方法太耗时，也难以阅读，显得笨重，以下给出一个好的方法：access to attrs=organizationalPersonby * none用的方法必须谨慎，这段指令不仅仅约束了organizationalPerson里的属性，也约束了person对象类的属性。为什么？因为organizationalPerson对象类是person的子类，因此，所有person中的属性就当然也是organizationalPerson的属性了。如果想做除了organizationalPerson的其他对象类的约束，可以用！来表示：access to attrs=!organizationalPerson也可以加入属性的值，具体约束某个值：access to attrs=givenName val=Matt这个指令也可以用模糊约束的方法，如下：access to attrs=givenName val.regex=M.*最后给个一般情况下用到的利用属性约束的例子：access to attrs=member val.children=ou=Users,dc=example,dc=comby * none3.3.通过Filters访问Filters提供一种支持条目记录匹配的方法，如下：access to filter=(objectClass=simpleSecurityObject)by * none这表示我们可以约束所有记录中包含对象类为simpleSecurityObject的信息。与编程语言类似, ACL指令也有类似与或的条件判断,如下:access tofilter=(|(|(givenName=Matt)(givenName=Barbara)(sn=Kant)by * none这段代码过滤出givenName为Matt或者Barbara，或者surname为Kant的信息。第二部分 例子说明例子1#ACL configure以下内容定义访问控制access to attr=userPassword #只能由自已修改usrPassword，有效验证用户查询。by self writeby anonymous authaccess to attr=mailby dn=cn=root,dc=it,dc=com write #只能由自已修改mail，有效验证用户查询。by self writeby anonymous authaccess to dn=.*,dc=it,dc=com #允许所有人查询没受控制访问限制的信息。by self writeby * read例子2The access control facility described above is quite powerful. This section shows some examples of its use for descriptive purposes.A simple example:access to * by * read /所有用户可以readThis access directive grants read access to everyone.access to *by self writeby anonymous authby * readThis directive allows the user to modify their entry, allows anonymous to authentication against these entries, and allows all others to read these entries. Note that only the first by clause which matches applies. Hence, the anonymous users are granted auth, not read. The last clause could just as well have been by users read.It is often desirable to restrict operations based upon the level of protection in place. The following shows how security strength factors (SSF) can be used. access to *by ssf=128 self writeby ssf=64 anonymous authby ssf=64 users readThis directive allows users to modify their own entries if security protections have of strength 128 or better have been established, allows authentication access to anonymous users, and read access when 64 or better security protections have been established. If client has not establish sufficient security protections, the implicit by * none clause would be applied.The following example shows the use of a style specifiers to select the entries by DN in two access directives where ordering is significant.access to dn.children=dc=example,dc=comby * searchaccess to dn.children=dc=comby * readRead access is granted to entries under the dc=com subtree, except for those entries under the dc=example, dc=com subtree, to which search access is granted. No access is granted to dc=com as neither access directive matches this DN. If the order of these access directives was reversed, the trailing directive would never be reached, since all entries under dc=example, dc=com are also under dc=com entries.Also note that if no access to directive matches or no by clause, access is denied. That is, every access to directive ends with an implicit by * none clause and every access list ends with an implicit access to * by * none directive.The next example again shows the importance of ordering, both of the access directives and the by clauses. It also shows the use of an attribute selector to grant access to a specific attribute and various selectors.access to dn.subtree=dc=example,dc=com attr=homePhoneby self writeby dn.children=dc=example,dc=com searchby peername.regex=IP:10.+ readaccess to dn.subtree=dc=example,dc=comby self writeby dn.children=dc=example,dc=com searchby anonymous authThis example applies to entries in the dc=example, dc=com subtree. To all attributes except homePhone, an entry can write to itself, entries under entries can search by them, anybody else has no access (implicit by * none) excepting for authentication/authorization (which is always done anonymously). The homePhone attribute is writable by the entry, searchable by entries under , readable by clients connecting from network 10, and otherwise not readable (implicit by * none). All other access is denied by the implicit access to * by * none.Sometimes it is useful to permit a particular DN to add or remove itself from an attribute. For example, if you would like to create a group and allow people to add and remove only their own DN from the member attribute, you could accomplish it with an access directive like this:access to attr=member,entryby dnattr=member selfwriteThe dnattr selector says that the access applies to entries listed in the member attribute. The selfwrite access selector says that such members can only add or delete their own DN from the attribute, not other values. The addition of the entry attribute is required because access to the entry is required to access any of the entrys attributes.例子3access to dn=”.*,dc=it,dc=com” attr=userPasswordby dn=”cn=root,dc=it,dc=com” writeby self writeby * authaccess to dn=”.*,dc=it,dc=com” attr=mailby dn=”cn=root,dc=it,dc=com” writeby self write by * readaccess to dn=”.*,ou=people,dc=it,dc=com”by * readaccess to dn=”.*,dc=it,dc=com”by self writeby * read上面的配置仅允许 userPassword 属性的所有者修改项，但仅当所有者提供他或她的优先密码时才允许进行修改。在所有其它情况下，只能出于认证目的来访问该项，而不能查看它。第二个access to项允许用户修改自己的电子邮件地址（attr=mail）。第三个项指定除了 rootdn 外，对于所有人，ou=people,dc=it,dc=com 中的任何 DN 都是只读的。这可防止用户更改其用户名、uid、gid 和主目录等。最后，最后一项是包容前面访问控制中未涉及的任何东西的安全的“大杂烩”。例如，它允许用户更改其自己地址簿中的项。第三部分 总结访问控制列表的最后说明：3.1语法access to by +其中,access to指示启用访问控制，上句大致可以理解为: access to by +3.2 剖析3.2.1 控制目标这一域主要是实现对ACL应用对象的指定，对象可以是记录和属性。选择ACL目标记录的方法一般有两种：DN和filter,语法为： := * |dn.= | dn.=filter= attrs= 指定所有的记录access to * 通过DN指定语法如下：to dn.= := regex | exact to dn.= := base | one | subtree | children第一种方法是使用正则表达式(dn.regex)或精确匹配(dn.style)的方式来匹配符合条件的记录（这个好像不像想象的那么简单，实现起来颇为费脑筋），例如：access to dn=.*,uid=(,+),ou=users,(.*)$第二种方法通过“区域”选择的方法进行目标记录的选取，对以指定的DN开始的目录树区域进行目标记录匹配。匹配区域的方式共有四种：base只匹配DN本身一条记录one匹配以给定DN为父目录的所有记录subtree匹配以给定DN为根目录的所有子树内的记录children匹配给定DN下的所有记录，但应该不包括以DN直接命名的那条记录(参见例子的解释)例如：对于0: dc=mydomain,dc=org1: cn=root,dc=mydomain,dc=org2: ou=users,dc=mydomain,dc=org3: uid=samba,ou=users,dc=mydomain,dc=org4: cn=Administator,uid=samba,ou=users,dc=mydomain,dc=org5: uid=guest,ou=users,dc=mydomain,dc=org规则 dn.base=ou=users,dc=mydomain,dc=org 只会匹配记录2规则 dn.one=ou=users,dc=mydomain,dc=org 匹配记录3和记录5，记录4是记录3的子目录，故不算在内规则 dn.subtree=ou=users,dc=mydomain,dc=org 匹配记录2、3、4、5规则 dn.children=ou=users,dc=mydomain,dc=org 匹配记录3、4、5,因为记录0、1和2都是以DN直接命名的，故不匹配 通过filter匹配记录通过filter指定过滤规则进行记录过虑，语法如下：access to filter=其中filter指定的为search的过滤规则，这类同于linux系统中grep的匹配方式。如：access to filter=(objectClass=sambaSamAccount)也可以结合使用DN和filter进行记录的匹配，例如：access to dn.subtree=ou=users,dc=mydomain,dc=org filter=(objectClass=posixAccount) 通过attrs选取匹配记录语法:attrs=例如：access to attrs=uid,uidNumber,gidNumber也可以结合使用DN和attrs进行记录的匹配，例如：access to dn.subtree=ou=users,dc=mydomain,dc=org attrs=uid3.2.2 被用来授权的访问者的指定指定被授权的用户范围的方法大致有以下几种：所有的访问者，包括匿名的用户anonymous非认证的匿名用户user