관리-도구

편집 파일: draft-haripriya-dynamicgroup-xx.txt

Network Working Group S. Haripriya Internet-Draft Jaimon. Jose, Ed. Updates: 02 (if approved) Jim. Sermersheim Intended status: Standards Track Novell, Inc. Expires: July 9, 2007 January 5, 2007 LDAP: Dynamic Groups for LDAPv3 draft-haripriya-dynamicgroup-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 9, 2007. Copyright Notice Copyright (C) The Internet Society (2007). Haripriya, et al. Expires July 9, 2007 [Page 1]  Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 Abstract This document describes the requirements, semantics, schema elements, and operations needed for a dynamic group feature in LDAP. A dynamic group is defined here as a group object with a membership list of distinguished names that is dynamically generated using LDAP search criteria. The dynamic membership list may then be interrogated by LDAP search and compare operations, and may also be used to find the groups that an object is a member of. This feature eliminates a huge amount of the administrative effort required today for maintaining group memberships and role-based operations in large enterprises. Table of Contents 1. Conventions used in this document . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Requirements of a dynamic group feature . . . . . . . . . . . 6 4. Schema and Semantic Definitions for Dynamic Groups . . . . . . 7 4.1. Object Classes . . . . . . . . . . . . . . . . . . . . . . 7 4.1.1. dynamicGroup . . . . . . . . . . . . . . . . . . . . . 7 4.1.2. dynamicGroupOfUniqueNames . . . . . . . . . . . . . . 7 4.1.3. dynamicGroupAux . . . . . . . . . . . . . . . . . . . 7 4.1.4. dynamicGroupOfUniqueNamesAux . . . . . . . . . . . . . 7 4.2. Attributes . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2.1. memberQueryURL . . . . . . . . . . . . . . . . . . . . 8 4.2.2. excludedMember . . . . . . . . . . . . . . . . . . . . 11 4.3. member . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.4. uniqueMember . . . . . . . . . . . . . . . . . . . . . . . 11 4.5. dgIdentity . . . . . . . . . . . . . . . . . . . . . . . . 11 4.5.1. dgIdentity - Security implications . . . . . . . . . . 12 5. Advertisement of support for dynamic groups . . . . . . . . . 13 6. Dynamic Group Operations . . . . . . . . . . . . . . . . . . . 14 6.1. Existing Operations . . . . . . . . . . . . . . . . . . . 14 6.1.1. Access to resources in the directory . . . . . . . . . 14 6.1.2. Reading a dynamic group object . . . . . . . . . . . . 14 6.1.3. 'Is Member Of' functionality . . . . . . . . . . . . . 15 6.2. New Extensions . . . . . . . . . . . . . . . . . . . . . . 16 6.2.1. Managing the static members of a dynamic group . . . . 16 7. Performance Considerations . . . . . . . . . . . . . . . . . . 17 7.1. Caching of Dynamic Members . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. Normative References . . . . . . . . . . . . . . . . . . . . . 21 Appendix A. Example Values for memberQueryURL . . . . . . . . . . 22 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Haripriya, et al. Expires July 9, 2007 [Page 2]  Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 Intellectual Property and Copyright Statements . . . . . . . . . . 25 Haripriya, et al. Expires July 9, 2007 [Page 3]  Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. Haripriya, et al. Expires July 9, 2007 [Page 4]  Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 2. Introduction The LDAP schema described in [4] defines two object classes: 'groupOfNames', and 'groupOfUniqueNames', that hold a static list of distinguished names in their 'member' or 'uniqueMember' attributes respectively, and are typically used to describe a group of objects for various functions. These grouping functions range from simple group membership applications such as email distribution lists to describing common authorization for a set of users The administration and updating of these membership lists must be done by specifically modifying the DN values in the member or uniqueMember attributes. Thus, each time a change in membership happens, a process must exist which adds or removes the particular entry's DN from the member attribute. For example, consider an organization, where the access to its facilities is controlled by membership in a directory group. Assume that all employees in a department have been added to the group that provides access to the required department facility. If an employee moves from one department to another, the administrator must remove the employee from one group and add him to another. Similarly consider an organization that wants to provide access to its facility, to both interns and employees on weekdays, but only to employees on weekends. It would be effort-consuming to achieve this with static groups. "Dynamic groups" are like normal groups, but they let one specify criteria to be used for evaluating membership to a group; the membership of the group is determined dynamically by the directory servers involved. This lets the group administrator define the membership in terms of attributes, and let the DSAs worry about who are the actual members. This solution is more scalable and reduces administrative costs. This can also supplement static groups in LDAP to provide flexibility to the user. Haripriya, et al. Expires July 9, 2007 [Page 5]  Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 3. Requirements of a dynamic group feature The following requirements SHOULD be met by a proposal for the dynamic groups feature: 1. Creation and administration of dynamic groups should be done using normal LDAP operations. 2. Applications must be able to use dynamic groups in the same way that they are able to use static groups for listing members and for membership evaluation. 3. Interrogation of a dynamic group's membership should be done using normal LDAP operations, and should be consistent. This means that all authorization identities with the same permission to the membership attribute of a dynamic group (such as 'read') should be presented with the same membership list. Haripriya, et al. Expires July 9, 2007 [Page 6]  Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 4. Schema and Semantic Definitions for Dynamic Groups The dynamic group classes are defined by the following schema 4.1. Object Classes The following object classes MUST be supported, and their semantics understood by the server, for it to support the dynamic groups feature. 4.1.1. dynamicGroup ( <OID.TBD> NAME 'dynamicGroup' SUP groupOfNames STRUCTURAL MAY (memberQueryURL $ excludedMember $ dgIdentity )) This structural object class is used to create a dynamic group object. It is derived from groupOfNames, which is defined in [4]. 4.1.2. dynamicGroupOfUniqueNames ( <OID.TBD> NAME 'dynamicGroupOfUniqueNames' SUP groupOfUniqueNames STRUCTURAL MAY (memberQueryURL $ excludedMember $ dgIdentity )) This structural object class is used to create a dynamic group object whose membership list is held in a uniqueMember attribute. It is derived from groupOfUniqueNames, which is defined in [4]. 4.1.3. dynamicGroupAux ( <OID.TBD> NAME 'dynamicGroupAux' SUP groupOfNames AUXILIARY MAY (memberQueryURL $ excludedMember $ dgIdentity )) This auxiliary object class is used to convert an existing object to a dynamic group or to create an object of another object class but with dynamic group capabilities. This is derived from groupOfNames which is defined in [4]. 4.1.4. dynamicGroupOfUniqueNamesAux ( <OID.TBD> NAME 'dynamicGroupOfUniqueNamesAux' SUP groupOfUniqueNames AUXILIARY MAY (memberQueryURL $ excludedMember $ dgIdentity )) This auxiliary object class is used to convert an existing object to a dynamic group of unique names or to create an object of another object class but with dynamic group capabilities. This is derived from groupOfUniqueNames which is defined in [4]. Haripriya, et al. Expires July 9, 2007 [Page 7]  Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 4.2. Attributes The following attribute names MUST be supported by the server. 4.2.1. memberQueryURL This attribute describes the membership of the list using an LDAPURL [3]. (<OID.TBD> NAME 'memberQueryURL' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) The value of memberQueryURL is encoded as an LDAPURL [3] Haripriya, et al. Expires July 9, 2007 [Page 8]  Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 The BNF from [3] is listed here for reference. ldapurl = scheme COLON SLASH SLASH [host [COLON port]] [SLASH dn [QUESTION [attributes] [QUESTION [scope] [QUESTION [filter] [QUESTION extensions]]]]] ; <host> and <port> are defined ; in Sections 3.2.2 and 3.2.3 ; of [RFC3986]. ; <filter> is from Section 3 of ; [RFC4515], subject to the ; provisions of the ; "Percent-Encoding" section ; below. scheme = "ldap" dn = distinguishedName ; From Section 3 of [RFC4514], ; subject to the provisions of ; the "Percent-Encoding" ; section below. attributes = attrdesc *(COMMA attrdesc) attrdesc = selector *(COMMA selector) selector = attributeSelector ; From Section 4.5.1 of ; [RFC4511], subject to the ; provisions of the ; "Percent-Encoding" section ; below. scope = "base" / "one" / "sub" extensions = extension *(COMMA extension) extension = [EXCLAMATION] extype [EQUALS exvalue] extype = oid ; From section 1.4 of [RFC4512]. exvalue = LDAPString ; From section 4.1.2 of ; [RFC4511], subject to the ; provisions of the ; "Percent-Encoding" section ; below. EXCLAMATION = %x21 ; exclamation mark ("!") SLASH = %x2F ; forward slash ("/") COLON = %x3A ; colon (":") QUESTION = %x3F ; question mark ("?") For the purpose of evaluating dynamic members, the directory server uses only the dn, scope, filter and extensions fields. All remaining fields are ignored if specified. If other fields are specified, the server SHALL ignore them and MAY omit them when presenting the value to a client. The dn is used to specify the base dn from which to start the search for dynamic members. The scope specifies the scope with respect to the dn in which to search for dynamic members. The filter specifies the criteria with which to select objects for dynamic membership. Haripriya, et al. Expires July 9, 2007 [Page 9]  Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 4.2.1.1. The x-chain extension A new extension is defined for use of the memberQueryURL in dynamic groups, named 'x-chain'. x-chain does not take a value. When x-chain is present, the server must follow any search continuation references to other servers while searching for dynamic members. When x-chain is absent, the dynamic members computed will be only those that are present on the server from which the search is made. A directory server supporting the memberQueryURL MAY support the x-chain extension, thus the x-chain extension could be critical or non- critical as specified by the '!' prefix to the extension type. 4.2.1.2. Semantics of multiple values for memberQueryURL The memberQueryURL MAY have multiple values, and in that case, the members of the dynamic group will be the union of the members computed using each individual URL value. This is useful in specifying a group membership that is made up from subtrees rooted at different base DNs, and possibly using different filters. 4.2.1.3. Condition of membership An object O is a member of a dynamic group G if and only if (( O is a value of the 'member' or 'uniqueMember' attribute of G) OR (( O is selected by the membership criteria specified in the 'memberQueryURL' attribute values of G) AND ( O is not listed in the 'excludedMember' attribute of G) )) If a member M of a dynamic group G happens to be a dynamic or a static group, the static or dynamic members of M SHALL NOT be considered as members of G. M is a member of G though. The last condition is imposed because o Recursively evaluating members of members may degrade the performance of the server drastically. o Looping may occur particularly in situations where the search chains across multiple-servers. Haripriya, et al. Expires July 9, 2007 [Page 10]  Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 o Dynamic membership assertions (compare operation) cannot be optimized if recursive memberships are allowed. Without recursion, comparisons can be made light-weight. 4.2.2. excludedMember ( <OID.TBD> NAME 'excludedMember' SUP distinguishedName ) This attribute is used to exclude entries from being a dynamic member of a dynamic group. Thus an entry is a dynamic member of a dynamic group if and only if it is selected by the member criteria specified by the 'memberQueryURL' attribute or explicitly added to the member or uniqueMember attribute, and it is not listed in the 'excludedMember' attribute. 4.3. member ( 2.5.4.31 NAME 'member' SUP distinguishedName ) Defined in [4], this attribute is overloaded when used in the context of a dynamic group. It is used to explicitly specify static members of a dynamic group. If the same entry is listed in both the 'member' and 'excludedMember' attributes, the 'member' overrides the 'excludedMember', and the entry is considered to be a member of the group. This attribute is also used to interrogate both the static and dynamic member values of a dynamic group object. Subclasses of this attribute are NOT considered in this manner. 4.4. uniqueMember ( 2.5.4.32 NAME 'uniqueMember' SUP distinguishedName ) Defined in [4], this attribute is overloaded when used in the context of a dynamic group. It is used to specify the static members of a dynamic group. If the same entry is listed in both the 'uniqueMember' and 'excludedMember' attributes, the 'uniqueMember' overrides the 'excludedMember', and the entry is considered to be a member of the group. This attribute is also used to interrogate both the static and dynamic member values of a dynamic group object. Subclasses of this attribute are NOT considered in this manner. 4.5. dgIdentity ( <OID.TBD> NAME 'identity' SUP distinguishedName SINGLE-VALUE ) In order to provide consistent results when processing the search criteria, the server must use a single authorization identity. If the authorization of the bound identity is used, the membership list Haripriya, et al. Expires July 9, 2007 [Page 11]  Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 will vary, from identity to identity due to differing access controls. This may either be done by the server authenticating as the dgIdentity prior to performing a search or compare operation, or may be done by simply assuming the authorization of the dgIdentity when performing those operations. As server implementations vary, so may the mechanisms to achieve consistent results through the use of the dgIdentity. In the case that the server authenticates as the dgIdentity, it may be required by the server that this identity have proper authentication credentials, and it may be required that this identity reside in the DIB of the local server. In the absence of an identity value, or in case the identity value cannot be used, the server will process the memberQueryURL as the anonymous identity. This attribute MAY be supported, and represents the identity the server will use for processing the memberQueryURL. 4.5.1. dgIdentity - Security implications Because this attribute indirectly but effectively grants anyone with read or compare access to the member or uniqueMember attribute sufficient permission to gain a DN result set from the memberQueryURL, server implementations SHOULD NOT allow this attribute to be populated with the DN of any object that is not administered by the identity making the change to this attribute. For purposes of this document, to "administer an object" indicates that the administrative identity has the ability to fully update the access control mechanism in place the object in question. As of this writing, there is no way to describe further what it means to be fully able to administer the access control mechanism for an object, so this definition is left as implementation-specific. This requirement will allow an entity that has privileges to administer a particular subtree (meaning that entity can add, delete, and update objects in that subtree), to place in the dgIdentity DNs of only those objects it administers. Haripriya, et al. Expires July 9, 2007 [Page 12]  Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 5. Advertisement of support for dynamic groups If the dynamic groups schema is not present on an LDAP server, it MUST be assumed that the dynamic groups feature is not supported. Haripriya, et al. Expires July 9, 2007 [Page 13]  Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 6. Dynamic Group Operations 6.1. Existing Operations The following operations SHOULD expose the dynamic groups functionality. These operations do not require any change in the LDAP protocol to be exchanged between the client and server. 6.1.1. Access to resources in the directory If access control items are set on a target resource object in the directory, with the subject being a dynamic group object, then all the members of the group object, including the dynamic members, will get the same permissions on the target entry. This would be the most useful application of dynamic groups as seen by an administrator because it lets the server control access to resources based on dynamic membership to a trustee (subject of ACI) of the resource. The way to specify a dynamic ACL is currently implementation specific, as there is no common ACL definition for LDAP, and hence will be dealt with in a separate document or later (TO BE DONE). 6.1.2. Reading a dynamic group object When the member attributes of a dynamic group object is listed by the client using an LDAP search operation, the member values returned SHOULD contain both the static and dynamic members of the group object. This functionality will not require a change to the protocol, and the clients need not be aware of dynamic groups to exploit this functionality. This feature is useful for clients that determine access privileges to a resource by themselves, by reading the members of a group object. It will also be useful to administrators who want to see the result of the query URL that they set on the dynamic group entry. Note that this overloads the semantics of the 'member' and 'uniqueMember' attributes. This could lead to some surprises for the client . for example: Clients that read the member attribute of a dynamic group object and then attempt to remove values (which were dynamic) could get an error specifying such a value was not there. Example: Let cn=dg1,o=myorg be a dynamic group object with the following attributes stored in the directory. Haripriya, et al. Expires July 9, 2007 [Page 14]  Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 member: cn=admin,o=myorg excludedMember: cn=guest,ou=finance,o=myorg excludedMember: cn=robin,ou=finance,o=myorg memberQueryURL: ldap:///ou=finance,o=myorg??sub?(objectclass=organizationalPerson) If there are 5 organizationalPerson objects under ou=finance,o=myorg with common names bob, alice, john, robin, and guest, then the output of a base-scope LDAP search at cn=dg1,o=myorg, with the attribute list containing 'member' will be as follows: dn: cn=dg1,o=myorg member: cn=admin,o=myorg member: cn=bob,ou=finance,o=myorg member: cn=alice,ou=finance,o=myorg member: cn=john,ou=finance,o=myorg 6.1.3. 'Is Member Of' functionality The LDAP compare operation allows one to discover whether a given DN is in the membership list of a dynamic group. Again, the server SHOULD produce consistent results among different authorization identities when processing this request, as long as those identities have the same access to the member or uniqueMember attribute. Using the data from the example in Section 6.1.2, a compare on cn=dg1,o=myorg, for the AVA member=cn=bob,ou=finance,o=myorg would result in a response of compareTrue (assuming the bound identity was authorized to compare the member attribute of cn=dg1,o=myorg). Likewise, a search operation that contains an equalityMatch or presence filter, naming the member or uniqueMember attribute as the attribute (such as (member= cn=bob,ou=finance,o=myorg), or (member=*)), will cause the server to evaluate this filter against the rules given in Section 4.2.1.3 in the event that the search is performed on a dynamic group object. As of this writing, no other matching rules exist for the distinguished name syntax, thus no requirements beyond equalityMatch are given here. Haripriya, et al. Expires July 9, 2007 [Page 15]  Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 6.2. New Extensions The following new extensions are added for dynamic group support. 6.2.1. Managing the static members of a dynamic group Because a dynamic group overloads the semantics of the member and uniqueMember attributes, a mechanism is needed to retrieve the static values found in these attributes for management purposes. To serve this need, a new attribute option is defined here called 'x-static'. Attribute options are discussed in Section 2.5 of [2]. This option SHALL only be specified with the 'member' or 'uniqueMember' attribute. When the LDAP server does not understand the semantics of this option on a given attribute, the option SHOULD be ignored. This attribute option is only used to affect the transmitted values, and does not impose sub-typing semantics on the attribute. This option MAY be specified by a client during a search request in the list of attributes to be returned, i.e. member;x-static. In this case, the server SHALL only return those members of the dynamic group that are statically listed as values of the member or uniqueMember attribute. The evaluation process listed in Section 9 SHALL NOT be used to populate the values to be returned. This option MAY be specified is either an equalityMatch or presence search filter. In this case, the server evaluates only the values statically listed in the member or uniqueMember attribute, and does not apply the evaluation process listed in Section 9. This option MAY be specified in update operations such as add and modify, but SHOULD be ignored, as its presence is semantically the same as its non-presence. Note to user: Performing a search to read a dynamic group, with a filter item such as (member=*), and specifying member;x-static, may result in a search result entry that has no member attribute. This may seem counter-intuitive. Haripriya, et al. Expires July 9, 2007 [Page 16]  Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 7. Performance Considerations When the x-chain extension is present on the memberQueryURL, the server MUST follow any search continuation references to other servers while searching for dynamic members. This may be expensive and slow in a true distributed environment. The dynamicGroup implementation can consider a distributed caching feature to improve the performance. An outline of such a distributed caching is given below. 7.1. Caching of Dynamic Members Since the dynamic members of a group are computed every time the group is accessed, the performance could be affected. An implementation of dynamic groups can get around this problem by caching the computed members of a dynamic group locally and using the cached data subsequently. One way to do this is to create pseudo- objects for each dynamic group on every server that holds an object that is a dynamic member of the group. With this, the computation of the dynamic members of a group reduces to the task of reading the pseudo-objects from each server. These pseudo-objects need to be linked from the original dynamic group to speed up the member computation. Also, since these are cached objects, appropriate timeouts need to be associated with the cache after which the cache should be invalidated or refreshed Haripriya, et al. Expires July 9, 2007 [Page 17]  Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 8. Security Considerations This document discusses the use of one object as the identity (Section 4.5) with which to read information for another object. If the creation of the dgIdentity attribute is uncontrolled, an intruder could potentially create a dynamic group with the identity of, say, the administrator, to be able to read the directory as the administrator, and see information which would be otherwise unavailable to him. Thus, a person adding an object as identity of a dynamic group should have appropriate permissions on the object being added as identity. This document also discusses using dynamic memberships to provide access for resources in a directory. As the dynamic members are not created by the administrator, there could be surprises for the administrator in the form of certain objects getting access to certain resources through dynamic membership, which the administrator never intended. So the administrator should be wary of such problems. The administrator could view the memberships and make sure that anybody who is not supposed to be a member of a group is added to the excludedMember list. Denial of service attacks can be launched on an LDAP server, by repeatedly searching for a dynamic group with a large membership list and listing the member attribute. A more effective form of denial of service attack could be launched by making searches of the form (member="somedn") at the top of tree and closing the client connection as soon as the search starts. Some administrative limits be imposed to avoid such situations. The dynamic groups feature could be potentially misused by a user to circumvent any administrative size-limit restriction placed on the server. In order to search an LDAP server and obtain the names of all the objects on the server irrespective of admin size-limit restriction on the server, the LDAP user could create a dynamic group with a memberQueryURL which matches all objects in the tree, and list just that one object. Haripriya, et al. Expires July 9, 2007 [Page 18]  Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 9. IANA Considerations There are no IANA considerations. Haripriya, et al. Expires July 9, 2007 [Page 19]  Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 10. Conclusions This document discusses the syntax, semantics and usage of dynamic groups in LDAPv3. Haripriya, et al. Expires July 9, 2007 [Page 20]  Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 11. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006. [3] Smith, M. and T. Howes, "Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator", RFC 4516, June 2006. [4] Sciberras, A., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, June 2006. Haripriya, et al. Expires July 9, 2007 [Page 21]  Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 Appendix A. Example Values for memberQueryURL 1. This memberQueryURL value specifies the membership criteria for a dynamic group entry as "all inetorgperson entries that also have their title attribute set to 'manager', and are in the DIT-wide subtree under ou=hr,o=myorg ". memberQueryURL: ldap:/// ou=hr,o=myorg??sub?(& (objectclass=inetorgperson)(title=manager))? x-chain 2. This value lets the user specify the membership criteria for a dynamic group entry as "all entries on the local server, that either have unix accounts or belong to the unix department, and are under the engineering container ". memberQueryURL: ldap:///ou=eng,o=myorg??sub? (|(objectclass=posixaccount)(department=unix)) 3. These values let the user specify the membership criteria as "all inetorgperson entries on the local server, in either the ou=eng,o=myorg or ou=support,o=myorg" subtrees. memberQueryURL: ldap:///ou=eng,o=myorg??sub?(objectclass=inetorgperson) memberQueryURL: ldap:///ou=support,o=myorg??sub?(objectclass=inetorgperson) Haripriya, et al. Expires July 9, 2007 [Page 22]  Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 Appendix B. Acknowledgments Funding for the RFC Editor function is currently provided by the Internet Society. Haripriya, et al. Expires July 9, 2007 [Page 23]  Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 Authors' Addresses Haripriya S Novell, Inc. 49/1 & 49/3 Garvebhavi Palya, 7th Mile, Hosur Road Bangalore, Karnataka 560068 India Email: sharipriya@novell.com Jaimon Jose (editor) Novell, Inc. 49/1 & 49/3 Garvebhavi Palya, 7th Mile, Hosur Road Bangalore, Karnataka 560068 India Email: jjaimon@novell.com Jim Sermersheim Novell, Inc. 1800 South Novell Place Provo, Utah 84606 US Email: jimse@novell.com Haripriya, et al. Expires July 9, 2007 [Page 24]  Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 Full Copyright Statement Copyright (C) The Internet Society (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Haripriya, et al. Expires July 9, 2007 [Page 25]