Home > Articles

  • Print
  • + Share This
Like this article? We recommend

Testing the Plug-in

Testing your plug-in is a good opportunity to look at the directory server in action, but from the internal point of view. In our case, we can see the call stack behind a bind operation.

To have an accurate understanding of what happens when the plug-in is used, we must:

  • Enable heavy trace on directory server

  • Enable debug/trace in our plug-in (we get it from the installation LDIF file)

  • Create an ou=unix subentry and some test users

To Test the Plug-in

  1. Look at the current setting for the log to determine whether the error logging level is appropriate.

  2. <nico@lunarossa>~$ ldapsearch -1 -p 11389 -D "cn=dman" 
    -w manager0 -b "cn=config" -s base "objectclass=*" nsslapd-errorlog-level
    dn: cn=config
    nsslapd-errorlog-level: 0

    By looking at the nsslapd-errorlog-level: 0 setting, we can see that the error logging level is not high enough and we must raise it.

  3. Use nsslapd-errorlog-level=65536 to raise the level of error logging and to enable plug-in debugging. (The value to set for this function depends on the severity in slapi_log_error(severity,...).) For consistency, you must use SLAPI_LOG_PLUGIN and enable the related error log level in cn=config. The following example shows how to enable plug-in debugging cn=config:

  4. <nico@lunarossa> ~$ ldapmodify -p 11389 -D "cn=dman" -w manager0
    dn:cn=config
    changetype: modify
    replace: nsslapd-errorlog-level
    nsslapd-errorlog-level: 65536
    modifying entry cn=config

    NOTE

    If you do not feel confident with command line tools, use the console.

  5. Now, create the ou=unix,dc=sun,dc=com entry.

  6. You can do this easily with the console or with the ldapmodify command.

  7. Next, ask the administrator to create test users on the UNIX box where the directory server runs.

  8. In our example, we use sunone with the password sunone0, the system user of the directory server.

  9. To test the plug-in, simply perform a search that requires a binding. By the way, you must disable anonymous access in the server, removing the correspondent access control instruction (ACI). The following is the search test:

  10. <nico@lunarossa> ~$ ldapsearch -p 11389 -D 
    "uid=sunone,ou=unix,dc=sun,dc=com" -w sunone0 -b "dc=sun,dc=com" 
    "objectclass=*"
    ldap_simple_bind: No such object
    ldap_simple_bind: additional info: User not found in /etc/shadow

    From the output messages, we realize that something went wrong with binding. Let's check the log file ($DIR_HOME/slapd-<serverid>/logs/errors):

    ...
    [10/Nov/2002:17:06:23 +0100] roles-plugin - <-- roles_post_op
    [10/Nov/2002:17:06:29 +0100] passthru-plugin - => passthru_bindpreop
    [10/Nov/2002:17:06:29 +0100] passthru-plugin - <= not handled
     (not one of our suffixes)
    [10/Nov/2002:17:06:29 +0100] passwd_bind_fn - Entering...
    [10/Nov/2002:17:06:29 +0100] passwd_bind_fn - Bind DN: 
    uid=sunone,ou=unix,dc=sun,dc=com
    [10/Nov/2002:17:06:29 +0100] passwd_bind_fn - Bind cred(ln): 6
    [10/Nov/2002:17:06:29 +0100] passwd_bind_fn - Bind cred(pw): sunone0
    [10/Nov/2002:17:06:29 +0100] passwd_bind_fn - Bind method: 128
    [10/Nov/2002:17:06:29 +0100] authenticate_unix_user - Authenticating user 
    'kemer' using password 'sunone0'
    [10/Nov/2002:17:06:29 +0100] authenticate_unix_user - User kemer does not 
    exist
    [10/Nov/2002:17:06:29 +0100] passwd_bind_fn - User not found in /etc/shadow

    Our first bug seems to be in authenticate_unix_user(). In fact, to authenticate the user, this routine must have read access to /etc/shadow. With the default UNIX configuration, you cannot read this file unless you have superuser privileges. To solve this problem, simply run the server with root privileges.

    Before running the plug-in again, note the first three lines of log. The first line seems to close a postoperation of the roles plug-in; the second and third lines are traced by the so-called pass-through authentication (PTA) plug-in. Note that the PTA plugin is not installed by default on all directory servers, but installs only on those who have a remote Configuration Directory. With this plug-in, you can specify one or more directories that must pass through the bind operation to another directory server. The PTA plug-in then checks if the entry the user is trying to bind is in one of these directories. If the entry is in one of the directories, it binds the alternative server. In our case, "not handled" is correctly reported because ou=unix,dc=sun,dc=com has not been configured as a pass-through directory.

    There is a clear hint that the directory server effectively chains plug-in preoperations.

    Going back to our tests, after changing /etc/shadow permissions, the plug-in must be readable by the server's system user (the user id used by the server). Or, after running the server again with root privileges, we can repeat our previous search to check if binding is correct:

    <nico@lunarossa> ~$ ldapsearch -p 11389 -D 
    "uid=sunone,ou=unix,dc=sun,dc=com" -w sunone0 -b "dc=sun,dc=com" 
    "objectclass=*"
    ...(output trimmed)...

    The error log now reports successful messages, as you can see in the following excerpt:

    [10/Nov/2002:17:47:08 +0100] passthru-plugin - => passthru_bindpreop
    [10/Nov/2002:17:47:08 +0100] passthru-plugin - <= not handled 
    (not one of our suffixes)
    [10/Nov/2002:17:47:08 +0100] passwd_bind_fn - Entering...
    [10/Nov/2002:17:47:08 +0100] passwd_bind_fn - Bind DN: 
    uid=sunone,ou=unix,dc=sun,dc=com
    [10/Nov/2002:17:47:08 +0100] passwd_bind_fn - Bind cred(ln): 7
    [10/Nov/2002:17:47:08 +0100] passwd_bind_fn - Bind cred(pw): sunone0
    [10/Nov/2002:17:47:08 +0100] passwd_bind_fn - Bind method: 128
    [10/Nov/2002:17:47:08 +0100] authenticate_unix_user - Authenticating user 
    'sunone' using password 'sunone0'
    [10/Nov/2002:17:47:08 +0100] authenticate_unix_user - Maching password 
    7l8cAu1DEIBh. against 7l8cAu1DEIBh.
    [10/Nov/2002:17:47:08 +0100] authenticate_unix_user - User sunone 
    authenticated
    [10/Nov/2002:17:47:08 +0100] passwd_bind_fn - User authenticated
  • + Share This
  • 🔖 Save To Your Account