README
1This directory contains a slapd overlay, nssov, that handles
2NSS lookup requests through a local Unix Domain socket. It uses the
3same IPC protocol as Arthur de Jong's nss-ldapd, and a complete
4copy of the nss-ldapd source is included here. It also handles
5PAM requests.
6
7To use this code, you will need the client-side stuf library from
8nss-pam-ldapd. You can get it from:
9http://arthurdejong.org/nss-pam-ldapd
10You will not need the nslcd daemon; this overlay replaces that part.
11To disable building of the nslcd daemon in nss-pam-ldapd, add the
12--disable-nslcd option to the nss-pam-ldapd configure script. You
13should already be familiar with the RFC2307 and RFC2307bis schema
14to use this overlay. See the nss-pam-ldapd README for more information
15on the schema and which features are supported.
16
17To use the overlay, add:
18
19 include <path to>nis.schema
20
21 moduleload <path to>nssov.so
22 ...
23
24 database hdb
25 ...
26 overlay nssov
27
28to your slapd configuration file. (The nis.schema file contains
29the original RFC2307 schema. Some modifications will be needed to
30use RFC2307bis.)
31
32The overlay may be configured with Service Search Descriptors (SSDs)
33for each NSS service that will be used. SSDs are configured using
34
35 nssov-ssd <service> <url>
36
37where the <service> may be one of
38 aliases
39 ethers
40 group
41 hosts
42 netgroup
43 networks
44 passwd
45 protocols
46 rpc
47 services
48 shadow
49
50and the <url> must be of the form
51 ldap:///[<basedn>][??[<scope>][?<filter>]]
52
53The <basedn> will default to the first suffix of the current database.
54The <scope> defaults to "subtree". The default <filter> depends on which
55service is being used.
56
57If the local database is actually a proxy to a foreign LDAP server, some
58mapping of schema may be needed. Some simple attribute substitutions may
59be performed using
60
61 nssov-map <service> <orig> <new>
62
63See the nss-ldapd/README for the original attribute names used in this code.
64
65The overlay also supports dynamic configuration in cn=config. The layout
66of the config entry is
67
68 dn: olcOverlay={0}nssov,ocDatabase={1}hdb,cn=config
69 objectClass: olcOverlayConfig
70 objectClass: olcNssOvConfig
71 olcOverlay: {0}nssov
72 olcNssSsd: passwd ldap:///ou=users,dc=example,dc=com??one
73 olcNssMap: passwd uid accountName
74
75which enables the passwd service, and uses the accountName attribute to
76fetch what is usually retrieved from the uid attribute.
77
78PAM authentication, account management, session management, and password
79management are supported.
80
81Authentication is performed using Simple Binds. Since all operations occur
82inside the slapd overlay, "fake" connections are used and they are
83inherently secure. Two methods of mapping the PAM username to an LDAP DN
84are provided:
85 the mapping can be accomplished using slapd's authz-regexp facility. In
86this case, a DN of the form
87 cn=<service>+uid=<user>,cn=<hostname>,cn=pam,cn=auth
88is fed into the regexp matcher. If a match is produced, the resulting DN
89is used.
90 otherwise, the NSS passwd map is invoked (which means it must already
91be configured).
92
93If no DN is found, the overlay returns PAM_USER_UNKNOWN. If the DN is
94found, and Password Policy is supported, then the Bind will use the
95Password Policy control and return expiration information to PAM.
96
97Account management also uses two methods. These methods depend on the
98ldapns.schema included with the nssov source.
99 The first is identical to the method used in PADL's pam_ldap module:
100host and authorizedService attributes may be looked up in the user's entry,
101and checked to determine access. Also a check may be performed to see if
102the user is a member of a particular group. This method is pretty
103inflexible and doesn't scale well to large networks of users, hosts,
104and services.
105 The second uses slapd's ACL engine to check if the user has "compare"
106privilege on an ipHost object whose name matches the current hostname, and
107whose authorizedService attribute matches the current service name. This
108method is preferred, since it allows authorization to be centralized in
109the ipHost entries instead of scattered across the entire user population.
110The ipHost entries must have an authorizedService attribute (e.g. by way
111of the authorizedServiceObject auxiliary class) to use this method.
112
113Session management: the overlay may optionally add a "logged in" attribute
114to a user's entry for successful logins, and delete the corresponding
115value upon logout. The attribute value is of the form
116 <generalizedTime> <host> <service> <tty> (<ruser@rhost>)
117
118Password management: the overlay will perform a PasswordModify exop
119in the server for the given user.
120
121---
122This work is part of OpenLDAP Software <http://www.openldap.org/>.
123
124Copyright 1998-2011 The OpenLDAP Foundation.
125Portions Copyright 2008-2009 Howard Chu, Symas Corp. All rights reserved.
126
127Redistribution and use in source and binary forms, with or without
128modification, are permitted only as authorized by the OpenLDAP
129Public License.
130
131A copy of this license is available in the file LICENSE in the
132top-level directory of the distribution or, alternatively, at
133<http://www.OpenLDAP.org/license.html>.
134
135