- Writing an Authentication Plug-in for a Sun· ONE Directory Server
- Deciding Whether to Write a Plug-in
- Types of Plug-ins
- Working in the Plug-in Application Program Interface
- Authentication in the Directory Server
- UNIX Authentication Plug-in
- Testing the Plug-in
- About the Author
- Related Resources
- Ordering Sun Documents
- Accessing Sun Documentation Online
Like this article? We recommend
Like this article? We recommend
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
Look at the current setting for the log to determine whether the error logging level is appropriate.
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:
Now, create the ou=unix,dc=sun,dc=com entry.
Next, ask the administrator to create test users on the UNIX box where the directory server runs.
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:
<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.
<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.
You can do this easily with the console or with the ldapmodify command.
In our example, we use sunone with the password sunone0, the system user of the directory server.
<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