Working with User-ID and OpenLDAP dynamic groups

Revision A ©2013, Palo Alto Networks, Inc. www.paloaltonetworks.com

Working with User-ID and OpenLDAP dynamic groups Tech Note PAN-OS 5.0

©2013, Palo Alto Networks, Inc. [2]

Contents Overview ................................................................................................................................................................................ 3

Summary ............................................................................................................................................................................ 3 Network Architecture ......................................................................................................................................................... 4 Hardware and Software Versions Used ............................................................................................................................... 4

Set Up the OpenLDAP Configuration ..................................................................................................................................... 5 Configuring the OpenLDAP Server to Support Dynamic Groups ........................................................................................ 5 Building the OpenLDAP Users and Attributes ..................................................................................................................... 5 Verifying the OpenLDAP Configuration ............................................................................................................................. 7

Setting up the User-ID Configuration .................................................................................................................................... 9 Setting up the LDAP Server Connection Profile ................................................................................................................... 9 Set Up the Authentication Profile ...................................................................................................................................... 10 Set Up the Group Mapping ............................................................................................................................................... 10 Set Up Captive Portal ........................................................................................................................................................ 13 Set Up the Security Policy ................................................................................................................................................. 15

Verifying the Environment ................................................................................................................................................... 15 Conclusions ......................................................................................................................................................................... 17 Appendix – Full LDAP tree .................................................................................................................................................. 18 Revision History ................................................................................................................................................................... 21


Overview The main purpose of this document is to show administrators how to configure the User-ID module in Palo Alto Networks

next- generation firewalls to integrate with the OpenLDAP dynamic groups (dynlist) to build groups that are based upon

LDAP attributes that the administrators can manipulate (add, delete or modify).

The content of the document is mostly technical and therefore the intended audience is system engineers. We understand that

the reader has already a basic knowledge on how to configure a Palo Alto Networks next-generation firewall; therefore all

the steps required to set up a basic configuration are not covered here. More specifically, we will cover only the following

areas:

• Setting up the required OpenLDAP config for supporting dynamic groups

• Building the OpenLDAP dynamic groups

• Adding the users and the attributes for the dynamic groups

• Setting up the User-ID configuration in Palo Alto Networks firewalls to integrate with dynamic groups

• Verifying the configurations

The content included in this document is not intended to substitute any official documentation from Palo Alto Networks.

The official documentation can be found in the public website and also in the corporate Intranet for the employees.

Summary The User-ID feature within Palo Alto Networks firewalls enables security administrators to gain visibility on the users on

their network based on their identity and not just their IP address. It also enables administrators to establish security rules

correlating the user identity with their roles in the organization through the integration with directory services like LDAP.

For this purpose the firewalls are able to read and periodically update the information that the LDAP servers maintain in

their groups and build internal tables that include the groups and its members. The security admin can then create security

rules based not only on the users’ identity, but also on the groups that they belong to, which makes the process simpler and

more powerful.

In some cases the LDAP directory administrators do not build groups, but use some attribute that they apply to some

specific users, typically an OU attribute (Organizational Unit). They then expect that the firewall will be able to interpret this

attribute and apply some sort of security policy for the users that have the attribute applied to their account.

As of PAN-OS version 5.0.x, Palo Alto Networks firewalls can only read LDAP groups, not LDAP attributes. In order to

implement this configuration, we need to build a dynamic group in the LDAP server that will dynamically include the users

with the specific attribute configured. The firewall will then periodically read this group and its members to keep the groups

up to date, so they can be used in security policies.


Network Architecture Screenshot 1 that follows shows the logical network diagram that we will use in our lab:

Screenshot 1.- Lab logical diagram

Explanation of each element:

ü The Internet Server with IP address 8.8.8.8 will be just used to test the connectivity via ping. Depending on the

user’s role they will be allowed or denied to ping this server.

ü The OpenLDAP server with IP address 192.168.1.91 is where the user and role information is configured. The PA-

200 will connect to it for retrieving the user and group mapping information.

ü The Workstation with IP address 192.168.1.2 is where the end user is placed and will be used to test the

configuration.

Hardware and Software Versions Used

ü OpenLDAP server: OpenLDAP for Microsoft Windows version 2.4.26

ü LDAP browser: Apache Directory Studio version 1.5.3.v20100330

ü Palo Alto Networks: PA-200 firewall running PAN-OS version 5.0.5


Set Up the OpenLDAP Configuration

Configuring the OpenLDAP Server to Support Dynamic Groups In order to start using the dynamic groups in OpenLDAP, we need first to enable this feature in the configuration file. For

this purpose we will use the dynlist overlay. Most of the information on this specific feature has been obtained from the

following URL, where more information can be found: http://www.openldap.org/faq/data/cache/1209.html.

The dynlist overlay provides the capability to collect attribute values resulting from the search specified by an LDAP URI-

valued attribute into the base entry.

The dynamic collection occurs when an entry with a specified objectClass is being accessed, either for search or comparison.

All values of a specified LDAP URI-valued attribute are parsed and executed. Only the <DN>, <attrs>, <scope> and <filter>

portions of the URI are honored. The attributes resulting from the intersection of those requested in the search and those

listed in the <attrs> field of the URI are merged from all the resulting entries.

In order to start using this feature you first need to enable it and configure it in the slapd.conf file. You have to edit the file

and add the dyngroup schema to the include section of the file. The following is what is defined in our example:

include ./schema/dyngroup.schema

Then also add the following content to the slapd.conf file. The following is added to the end of our file:

overlay dynlist

dynlist-attrset groupOfURLs memberURL

The first instruction enables the dynlist overlay in OpenLDAP. The second one specifies the dynamic group objectclass and

the attributedescription that, once expanded, will list the members of the group. In our example the object class is

groupOfURLs and the members will be listed by expanding the content of the attribute description memberURL.

Once the slapd.conf file has been edited, you need to restart your slapd daemon or service and the system will be ready to

start using dynamic groups.

Building the OpenLDAP Users and Attributes The next step is to add the dynamic group and some members to our LDAP directory. In our example, we will add a

dynamic group named not_ping, where we will dynamically include all the users that will have the ping application blocked.

Following we show in LDIF format the creation of the dynamic group (there’s a full LDIF listing, including the whole LDAP

tree from the lab, at the end of this document in the Appendix chapter):

dn: cn=not_ping,ou=dynamic-groups,dc=panmadrid,dc=es

objectClass: groupOfURLs

cn: not_ping

memberURL: ldap:///ou=users,dc=panmadrid,dc=es?uid?sub?(&(objectClass=inetOrgPerson)(ou=not-ping))


As you can see in our example, the dynamic group has been named as “not_ping”. Its object class is groupOfURLs, as we

defined it in the previous step in the slapd.conf file. The attribute description is memberURL, also defined previously, and its

value is: ldap:///ou=users,dc=panmadrid,dc=es?uid?sub?(&(objectClass=inetOrgPerson)(ou=not-‐ping))

Each time the group “not_ping” is invoked, the previous LDAP search is executed and the members that are qualified to this

regexp are added dynamically to the group. Following you can find a short explanation on the meaning of the LDAP search

if you are not familiar with it:

ldap:///—The triple slash indicates that the search is within this LDAP server itself (opposed to ldap://host/)

ou=users,dc=panmadrid,dc=es—Base root where the search will start

?uid—The attribute that will be retrieved in the search, which will be the uid

?sub—Scope subtree, which will cause a search of all entries at all levels under and including the specified base DN

?(&(objectClass=inetOrgPerson)(ou=not-‐ping))—AND regexp indicating that the object class has to be

inetOrgPerson and also that the attribute ou=not-ping has to exist

Now we add also our users to the LDAP tree. Some will have the “not-ping” attribute set it up and others will not.

Following you can find the LDIF definition for both types of users.

User without the “not-ping” attribute:

dn: cn=Angel Serrano,ou=users,dc=panmadrid,dc=es

objectClass: inetOrgPerson

cn: Angel Serrano

sn: Serrano

carLicense: HISCAR 123

description: swell guy

homePhone: 555-‐111-‐2222

mail: [email protected]

uid: aserrano

userPassword:: YXNlcnJhbm8=

User with the “not-ping” attribute:

dn: cn=Jesus Diaz,ou=users,dc=panmadrid,dc=es


cn: Jesus Diaz

sn: Diaz



homePhone: 555-‐111-‐2222


ou: not-‐ping

uid: jdiaz

userPassword:: amRpYXo=


Verifying the OpenLDAP Configuration Once that you have finished your basic LDAP tree configuration you can connect to it with a browser, such as the Apache

Directory Studio, to review that everything is ok in a graphical way, which makes it easy to view. The following Screenshots

show some screenshots of our LDAP configuration:

Screenshot 2.- Base DN for the Lab LDAP tree

As Screenshot 2 shows the base DN is dc=panmadrid,dc=es and includes three main branches, ou=dynamic-groups,

ou=static-groups and ou=users.

The following two Screenshots show the definition for the ou=dynamic-groups and the cn=not_ping:

Screenshot 3.- Example definition for one of the OU containers

Screenshot 4.- Definition of the dynamic group

Note: The object class here is groupOfURLs and that the memberURL attribute includes the LDAP search explained

previously. You can also see that at this point there are three uid attributes retrieved that qualify with the LDAP search.


The following Screenshot shows an example config for one of the static groups that we have also set up in the tree, as

opposed to the dynamic group:

Screenshot 5.- Example definition of the static groups

As shown in Screenshot 5 the object class for the static groups is groupOfNames. We will use this attribute later on in the

group-mapping configuration in the Palo Alto Networks firewall to indicate which groups should be listed. Note also that

the group members are classified with the attribute member that we will also use later in this lab.

The following Screenshot shows the configuration for one of the users. The object class in this case is InetOrgPerson that

will be used later for instructing the firewall on how to search for the users in the directory:

Screenshot 6.- Example definition of the users

Note: The user showed in the example in Screenshot 6 has the attribute not-ping enabled and also note that his uid is

therefore listed in the dynamic group showed previously in Screenshot 4 (uid=aestevez in this example).

You can now do some testing with this attribute and add it or remove it to other users. By doing this, you will see that the

dynamic group called cn=not_ping is updated accordingly; adding or removing the uids.


Setting up the User-ID Configuration In this section we will cover the main steps required to configure the firewall to use the dynamic group explained previously.

The basic concept is to configure a Captive Portal that will use the LDAP tree, where we will set up or remove the ou=not-

ping attribute. We will also create a security policy that will block the ping application for the users included in the group

cn=not_ping and we will test that it’s indeed updated dynamically. As mentioned previously, we will not detail all of the

configurations steps; only the most relevant points for this lab will be listed as follows:

• Setting up the LDAP server connection profile

• Setting up the authentication profile

• Setting up the group mapping

• Setting up the Captive Portal

• Setting up the security policy

Setting up the LDAP Server Connection Profile Screenshot 6 that follows shows the configuration for the LDAP server profile that will connect the firewall management

with the LDAP server. This configuration is done in the GUI under the menu Device > Setup > Server Profiles > LDAP:

Screenshot 7.- Configuration of the OpenLDAP Server profile

Note: In the Servers section, we have configured the IP address of the LDAP server (192.168.1.91) and the TCP port for the

connection (389 is used because we are not using SSL). We have also added the domain (panmadrid.es in our example), the

base root as shown before (dc=panmadrid,dc=es) and the bind DN for this LDAP server (cn=manager,dc=panmadrid,dc=es).


Set Up the Authentication Profile The authentication profile will be configured later in this document when Captive Portal is configured to validate the users.

The configuration of this profile is also fairly simple. The following Screenshot shows the details (Device > Setup >

Authentication Profile):

Screenshot 8.- Configuration of the OpenLDAP authentication profile

As Screenshot 8 shows, we have configured an allow list that permits all the users to authenticate (Allow List = all, you can

also select only some of the groups or users to be allowed). We have then selected the authentication to be LDAP, with the

OpenLDAP server defined in the previous step and with the Login Attribute that we want to use to validate the users

configured to be the uid.

Set Up the Group Mapping Now we have to configure the firewall with the groups that we want to map. This configuration is done in Device > Setup >

User Identification > Group Mapping Settings and includes two parts: first we need to configure the Server Profile and

attributes that we want to use. Then we configure the Group Include List, that indicates the groups whose members we want

the firewall to learn. Screenshot 9 and Screenshot 10 show the config for the Group Mapping:


Screenshot 9.- Configuration of the group-mapping server profile

The information in this section will define the attributes for the group objects and the user objects that the firewall will use.

For the group, we have two object classes comma separated: groupOfURLs for the dynamic group and groupOfNames for

the static group. The group name is defined via the cn attribute and the group members with the uid and the member

attribute. Screenshot 4 and Screenshot 5 show these details; uid is for the dynamic group and member is used for the static

group. The update interval field is also important because it defines the frequency to which the updates will occur. We have

configured the minimum value, 60 seconds, so that the firewall will reflect any new changes as soon as possible.

Screenshot 10.- Configuration of the group-mapping group include list


The information in this section will define the groups that will be used by the firewall to retrieve user membership

information. In our example, we have selected the dynamic group, “not_ping”, and also a static group, “engineers”. If you

do not select any group, all of the groups will be used.

Important Note: As of PAN-OS version 5.0.5, the firewall will attempt (by default) to use the modifytimestamp attribute in

the LDAP searches that are made periodically. This attribute is intended to perform incremental searches, so that the firewall

only retrieves group modifications instead of retrieving all information on each search. This configuration works only for

Microsoft Active Directory and because this is OpenLDAP, we need to deactivate it. The behavior that will occur if you do

not deactivate this parameter is that the device will properly learn the users the first time that it runs after committing the

configuration, but in the next refreshes it will remove the users. In order to deactivate this parameter, you need to execute

the following command on the firewall in configuration mode (PAN-OS ≥ 5.0.x):

admin@PA-‐200# set group-‐mapping Grupos-‐OpenLDAP use-‐modify-‐timestamp no

In early versions of PAN-OS 5.0.x, the command was not located in configuration mode and the setting was not maintained

after a reboot. The previous command was:

admin@PA-‐200> debug user-‐id use-‐modify-‐for-‐group-‐mapping no

At this point, after committing the configuration, you can check that the group retrieval functions as expected. For this

purpose, you can use the CLI. First we check the connection between the firewall and the LDAP server and then verify that

the firewall has retrieved the two expected groups:

admin@PA-‐200> show user group-‐mapping state Grupos-‐OpenLDAP

Group Mapping(vsys1, type: other): Grupos-‐OpenLDAP

Bind DN : cn=manager,dc=panmadrid,dc=es

Base : dc=panmadrid,dc=es

Group Filter: (None)

User Filter: (None)

Servers : configured 1 servers

192.168.1.91(389)

Last Action Time: 53 secs ago(took 0 secs)

Next Action Time: In 7 secs

Number of Groups: 2

cn=engineers,ou=static-‐groups,dc=panmadrid,dc=es

cn=not_ping,ou=dynamic-‐groups,dc=panmadrid,dc=es


Next we can verify the contents of each group and check that they are in accordance with the LDAP structure that we have

defined in our OpenLDAP server. The following output is an example of the dynamic and static groups in our lab

configuration:

admin@PA-‐200> show user group name panmadrid.es\not_ping

short name: panmadrid.es\not_ping

source type: ldap

source: Grupos-‐OpenLDAP

[1 ] panmadrid.es\aestevez

[2 ] panmadrid.es\fanaya

[3 ] panmadrid.es\jdiaz

admin@PA-‐200> show user group name panmadrid.es\engineers

short name: panmadrid.es\engineers

source type: ldap

source: Grupos-‐OpenLDAP

[1 ] panmadrid.es\aserrano

[2 ] panmadrid.es\jdiaz

[3 ] panmadrid.es\xhoms

The first output shows the dynamic group and the second output shows the static group. You can test further by adding or

removing the ou=not-ping attribute to other users. You can then check that the firewall updated the members after a 60

seconds interval after making the change in the LDAP server. Remember that we configured the Update Interval to 60 secs,

which is the minimum value.

Set Up Captive Portal The following stage of this example is to configure Captive Portal to validate the users. It includes two steps: configuring

Captive Portal under User-ID and then add a Captive Portal rule that will trigger the portal when the users open the browser

and try to access the Internet. The following Screenshots (Screenshot 11 and Screenshot 12) shows this configuration:


Screenshot 11.- Configuration of the OpenLDAP Server profile

This configuration is made on the firewall using the web interface at Device > User Identification > Captive Portal Settings.

As you can see, we have selected the authentication profile based on the LDAP configuration that was performed previously

(“Auth-OpenLDAP”). The configuration is set to redirect mode, so that the firewall will intercept the original session of the

client and send a HTTP 302 redirection code, pointing to the IP address in the internal interface of the firewall where the

Captive Portal page will be displayed.

For a full explanation of all the configuration and parameters related to Captive Portal, refer to

https://live.paloaltonetworks.com/docs/DOC-1159.

The following steps describe the configuration needed for Captive Portal to intercept the users and validate them against the

LDAP server. Screenshot 12 shows the configuration which is under Policies > Captive Portal. The captive portal policy is

triggered for any user going from zone LAN to zone Internet that starts a TCP session with destination port 80 (service-

http). The configured action is set to receive the web form page:

Screenshot 12.- Configuration of captive portal rule


Set Up the Security Policy The final step in the configuration is to configure a security policy that will block the ping application for the IP address

8.8.8.8 for all of the members in the dynamic group “not_ping”. We have also added another policy below this policy that

allows all other access, which will simplify our policy. Obviously, this is not a recommended practice for a production

environment.

Screenshot 13 shows this configuration:

Screenshot 13.- Configuration of the security policy rule

After the entire configuration has been completed, a full commit is performed and the environment can be validated using

the steps in the following section “Verifying the Environment”.

Verifying the Environment The verification process should be very straightforward and will be performed from the workstation 192.168.1.2 in our lab:

1. Open a browser and you should receive the captive portal 302 redirection to the web form.

2. Authenticate with a user that has the ou=not-ping attribute set and therefore belongs to the dynamic group.

3. Check that the ping to 8.8.8.8 is blocked.

4. Verify the logs.

5. Close the browser and remove the user mapping in the firewall, so that you will authenticate from the same station

with a different user.

6. Open the browser again and authenticate with a user without the ou=not-ping attribute.

7. Check that the ping to 8.8.8.8 now works.

8. Verify the logs.

The following screenshots show part of the proposed validation process and the expected output.

Screenshot 14 shows the Captive Portal web form that the user receives when the browser first opens. Note that in the

address bar it appears the redirection that have been done through the HTTP 302 code:


Screenshot 14.- Captive portal web form for the user authentication

After the user has been authenticated, we can check firewall using the CLI to verify the information:

admin@PA-‐200> show user ip-‐user-‐mapping all

IP Vsys From User IdleTimeout(s) MaxTimeout(s)

-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐

192.168.1.2 vsys1 CP panmadrid.es\jdiaz 899 3394

Total: 1 users

If the user now runs a ping against 8.8.8.8, it should not work. If we check the logs, we see that the user has been blocked by

the appropriate rule, as shown in Screenshot 15:

Screenshot 15.- Traffic logs demonstrating that the ping application is blocked for this user

Now the testing workstation closes the browser and the security administrator clears the IP address-to-user name mapping

via the CLI with the following two commands:


admin@PA-‐200> clear user-‐cache-‐mp all

All entries in user cache removed!

admin@PA-‐200> clear user-‐cache all

All entries in user cache removed!

If the ping is still running at this point, it should start to work because the traffic will match the second rule that allows

everything because the user is now “unknown”. The user on the test workstation opens the browser again and is redirected

to the Captive Portal web form. In this case, authentication occurs from a user that does not have the ou=not-ping attribute

set. The ping will continue to work because the user does not belong to the dynamic group.

Screenshot 16 shows the logs for a user that does not belong to the dynamic group (therefore it does not have the attribute

ou=not-ping enabled).

Screenshot 16.- Traffic logs demonstrating that the ping application is permitted for this user

At this point you can test again with the ou=not-ping attribute in the LDAP server and check how the users are

included/excluded from the dynamic group and how the firewall allows or denies the ping application accordingly.

Conclusions There are some LDAP installations that do not have user groups and some that may have groups, but require the utilization

of user attributes for mapping security policies based on those attributes. The user attributes can be set manually by the

LDAP admins or automatically through some process that assigns or removes the attributes to the users based on certain

conditions. This document described a flexible approach for integrating the LDAP user attributes as part of a Palo Alto

Networks next-generation firewall policy, through the use of OpenLDAP dynamic groups. The configuration of the dynamic

groups in the OpenLDAP server is simple and the integration with the firewall allows Palo Alto Networks User-ID to be

deployed successfully in these environments.


Appendix – Full LDAP tree Following is the full LDAP tree used for this lab in LDIF format:

version: 1

dn: dc=panmadrid,dc=es

objectClass: dcObject

objectClass: organization

dc: panmadrid

o: Palo Alto Networks

description: Palo Alto Networks en Madrid

dn: ou=users,dc=panmadrid,dc=es

objectClass: organizationalUnit

ou: users

description: People in my organization

dn: cn=Tony Hadzima,ou=users,dc=panmadrid,dc=es


cn: Tony Hadzima

sn: hadzima



homePhone: 555-111-2222


uid: thadzima

userPassword:: dGhhZHppbWE=

dn: cn=Fernando Anaya,ou=users,dc=panmadrid,dc=es


cn: Fernando Anaya

sn: Anaya



homePhone: 555-111-2222


ou: not-ping

uid: fanaya

userPassword:: ZmFuYXlh

dn: cn=Jesus Diaz,ou=users,dc=panmadrid,dc=es



cn: Jesus Diaz

sn: Diaz



homePhone: 555-111-2222


ou: not-ping

uid: jdiaz

userPassword:: amRpYXo=

dn: cn=Angel Serrano,ou=users,dc=panmadrid,dc=es


cn: Angel Serrano

sn: Serrano



homePhone: 555-111-2222


uid: aserrano

userPassword:: YXNlcnJhbm8=

dn: cn=Javier Molinos,ou=users,dc=panmadrid,dc=es


cn: Javier Molinos

sn: Molinos



homePhone: 555-111-2222


uid: jmolinos

userPassword:: am1vbGlub3M=

dn: cn=Albert Estevez,ou=users,dc=panmadrid,dc=es


cn: Albert Estevez

sn: Estevez



homePhone: 555-111-2222


ou: not-ping

uid: aestevez


userPassword:: YWVzdGV2ZXo=

dn: cn=Xavier Homs,ou=users,dc=panmadrid,dc=es


cn: Xavier Homs

sn: Homs



homePhone: 555-111-2222


uid: xhoms

userPassword:: eGhvbXM=

dn: cn=Marc Sarrias,ou=users,dc=panmadrid,dc=es


cn: Marc Sarrias

sn: Sarrias



homePhone: 555-111-2222


uid: msarrias

userPassword:: eGhvbXM=

dn: ou=dynamic-groups,dc=panmadrid,dc=es

objectClass: top


ou: dynamic-groups

dn: cn=not_ping,ou=dynamic-groups,dc=panmadrid,dc=es

objectClass: groupOfURLs

cn: not_ping

memberURL: ldap:///ou=users,dc=panmadrid,dc=es?uid?sub?(&(objectClass=inetOr

gPerson)(ou=not-ping))

uid: fanaya

uid: jdiaz

uid: aestevez

dn: ou=static-groups,dc=panmadrid,dc=es


ou: static-groups

description: Grupos de personas


dn: cn=Sales,ou=static-groups,dc=panmadrid,dc=es

objectClass: groupOfNames

objectClass: top

cn: Sales

member: cn=Fernando Anaya,ou=usuarios,dc=panmadrid,dc=es

member: cn=Javier Molinos,ou=usuarios,dc=panmadrid,dc=es

member: cn=Tony Hadzima,ou=usuarios,dc=panmadrid,dc=es

member: cn=Marc Sarrias,ou=usuarios,dc=panmadrid,dc=es

dn: cn=Engineers,ou=static-groups,dc=panmadrid,dc=es


objectClass: top

cn: Engineers

member: cn=Angel Serrano,ou=usuarios,dc=panmadrid,dc=es

member: cn=Jesus Diaz,ou=usuarios,dc=panmadrid,dc=es

member: cn=Xavi Homs,ou=usuarios,dc=panmadrid,dc=es

dn: cn=Professional Services,ou=static-groups,dc=panmadrid,dc=es


objectClass: top

cn: Professional Services

member: cn=Albert Estevez,ou=usuarios,dc=panmadrid,dc=es

Revision History Date Revision Comment 2013/06/14 A First version of this document. 2013/06/27 B Language revision.

Documents

Working with User-ID and OpenLDAP dynamic groups