slapd-ldap man page on UnixWare

Man page or keyword search:  
man Server   3616 pages
apropos Keyword Search (all sections)
Output format
UnixWare logo
[printable version]

SLAPD-LDAP(5)							 SLAPD-LDAP(5)

NAME
       slapd-ldap - LDAP backend to slapd

SYNOPSIS
       /etc/openldap/slapd.conf

DESCRIPTION
       The LDAP backend to slapd(8) is not an actual database; instead it acts
       as a proxy to forward incoming requests to another LDAP	server.	 While
       processing requests it will also chase referrals, so that referrals are
       fully processed instead of being returned to the slapd client.

       Sessions that explicitly Bind to the back-ldap database	always	create
       their  own private connection to the remote LDAP server. Anonymous ses‐
       sions will share a single anonymous connection to  the  remote  server.
       For sessions bound through other mechanisms, all sessions with the same
       DN will share the same connection. This connection pooling strategy can
       enhance	the  proxy's efficiency by reducing the overhead of repeatedly
       making/breaking multiple connections.

       The ldap database can also act as  an  information  service,  i.e.  the
       identity	 of  locally  authenticated  clients is asserted to the remote
       server, possibly in some modified form.	For this  purpose,  the	 proxy
       binds  to  the remote server with some administrative identity, and, if
       required, authorizes the asserted identity.  See the  idassert-*	 rules
       below.  The administrative identity of the proxy, on the remote server,
       must be allowed to authorize by means of appropriate authzTo rules; see
       slapd.conf(5) for details.

       Note:  When looping back to the same instance of slapd(8), each connec‐
       tion requires a new thread; as a consequence, slapd(8) must be compiled
       with thread support, and the threads parameter may need some tuning; in
       those cases, one may consider using slapd-relay(5) instead, which  per‐
       forms the relayed operation internally and thus reuses the same connec‐
       tion.

CONFIGURATION
       These slapd.conf options apply to the LDAP backend database.  That  is,
       they  must follow a "database ldap" line and come before any subsequent
       "backend" or "database" lines.  Other database options are described in
       the slapd.conf(5) manual page.

       Note: In early versions of back-ldap it was recommended to always set

	      lastmod  off

       for  every  ldap	 and  meta  database.	This  is  because  operational
       attributes related to entry creation and	 modification  should  not  be
       proxied,	 as  they could be mistakenly written to the target server(s),
       generating an error.  The  current  implementation  automatically  sets
       lastmod	to off, so its use is redundant and should be omitted, because
       the lastmod directive will be deprecated in the future.

       uri <ldapurl>
	      LDAP server to use.  Multiple URIs can be set  in	 in  a	single
	      ldapurl  argument, resulting in the underlying library automati‐
	      cally call the first server of the list that responds, e.g.

	      uri "ldap://host/ ldap://backup-host/"

	      The URI list is space- or comma-separated.

       acl-bind	      bindmethod=simple|sasl	   [binddn=<simple	  DN>]
	      [credentials=<simple     password>]    [saslmech=<SASL	mech>]
	      [secprops=<properties>] [realm=<realm>] [authcId=<authentication
	      ID>] [authzId=<authorization ID>]
	      Allows  to  define  the  parameters of the authentication method
	      that is internally used by the proxy to collect info related  to
	      access   control.	  The  identity	 defined  by  this  directive,
	      according to the properties  associated  to  the	authentication
	      method,  is supposed to have read access on the target server to
	      attributes used on the proxy for ACL checking.  There is no risk
	      of  giving  away	such  values;  they  are  only	used  to check
	      permissions.  The default is to  use  simple  bind,  with	 empty
	      binddn  and credentials, which means that the related operations
	      will be performed anonymously.

	      This identity is by no means implicitly used by the  proxy  when
	      the  client  connects  anonymously.   The idassert-bind feature,
	      instead,	in  some  cases	 can  be  crafted  to  implement  that
	      behavior,	 which is intrinsically unsafe and should be used with
	      extreme care.  This directive obsoletes  acl-authcDN,  and  acl-
	      passwd.

       chase-referrals {YES|no}
	      enable/disable automatic referral chasing, which is delegated to
	      the underlying libldap, with rebinding eventually	 performed  if
	      the  rebind-as-user  directive is used.  The default is to chase
	      referrals.

       conn-ttl <time>
	      This directive causes a  cached  connection  to  be  dropped  an
	      recreated after a given ttl, regardless of being idle or not.

       idassert-authzFrom <authz-regexp>
	      if  defined,  selects  what  local  identities are authorized to
	      exploit the identity  assertion  feature.	  The  string  <authz-
	      regexp>  follows	the rules defined for the authzFrom attribute.
	      See slapd.conf(5), section related to authz-policy, for  details
	      on the syntax of this field.

       idassert-bind	bindmethod=none|simple|sasl    [binddn=<simple	  DN>]
	      [credentials=<simple    password>]    [saslmech=<SASL	mech>]
	      [secprops=<properties>] [realm=<realm>] [authcId=<authentication
	      ID>]  [authzId=<authorization  ID>]  [authz={native|proxyauthz}]
	      [mode=<mode>] [flags=<flags>]
	      Allows  to  define  the  parameters of the authentication method
	      that is internally used by the proxy  to	authorize  connections
	      that are authenticated by other databases.  The identity defined
	      by this directive, according to the properties associated to the
	      authentication  method,  is  supposed to have auth access on the
	      target server to attributes used on the proxy for authentication
	      and  authorization,  and	to  be allowed to authorize the users.
	      This requires to have proxyAuthz privileges on  a	 wide  set  of
	      DNs,  e.g.  authzTo=dn.subtree:"", and the remote server to have
	      authz-policy set to to or both.  See slapd.conf(5)  for  details
	      on  these	 statements  and for remarks and drawbacks about their
	      usage.  The supported bindmethods are

	      none|simple|sasl

	      where none  is  the  default,  i.e.  no  identity	 assertion  is
	      performed.

	      The authz parameter is used to instruct the SASL bind to exploit
	      native SASL authorization, if available; since  connections  are
	      cached,  this  should only be used when authorizing with a fixed
	      identity (e.g. by means of the authzDN or	 authzID  parameters).
	      Otherwise,  the  default proxyauthz is used, i.e. the proxyAuthz
	      control is added to all operations.

	      The supported modes are:

	      <mode> := {legacy|anonymous|none|self}

	      If <mode> is not present, and authzId is given, the proxy always
	      authorizes that identity.	 <authorization ID> can be

	      u:<user>

	      [dn:]<DN>

	      The  former  is  supposed	 to  be	 expanded by the remote server
	      according to the authz rules; see slapd.conf(5) for details.  In
	      the  latter  case, whether or not the dn: prefix is present, the
	      string must pass DN validation and normalization.

	      The default mode is legacy, which implies that  the  proxy  will
	      either  perform  a  simple bind as the authcDN or a SASL bind as
	      the authcID and assert the client's  identity  when  it  is  not
	      anonymous.   Direct  binds  are always proxied.  The other modes
	      imply that the proxy will always either perform a simple bind as
	      the  authcDN or a SASL bind as the authcID, unless restricted by
	      idassert-authzFrom  rules	 (see  below),	in  which   case   the
	      operation	 will  fail;  eventually,  it  will  assert some other
	      identity according to <mode>.  Other  identity  assertion	 modes
	      are  anonymous  and self, which respectively mean that the empty
	      or the client's identity will be	asserted;  none,  which	 means
	      that  no	proxyAuthz control will be used, so the authcDN or the
	      authcID identity will be asserted.  For all modes	 that  require
	      the  use	of  the	 proxyAuthz  control, on the remote server the
	      proxy identity must have appropriate authzTo permissions, or the
	      asserted identities must have appropriate authzFrom permissions.
	      Note, however, that the ID assertion feature  is	mostly	useful
	      when the asserted identities do not exist on the remote server.

	      Flags can be

	      override,{prescriptive|non-prescriptive}

	      When  the	 override flag is used, identity assertion takes place
	      even when the database is authorizing for the  identity  of  the
	      client,  i.e. after binding with the provided identity, and thus
	      authenticating it, the proxy  performs  the  identity  assertion
	      using the configured identity and authentication method.

	      When  the	 prescriptive  flag  is used (the default), operations
	      fail with inappropriateAuthentication for those identities whose
	      assertion is not allowed by the idassert-authzFrom patterns.  If
	      the non-prescriptive flag	 is  used,  operations	are  performed
	      anonymously  for those identities whose assertion is not allowed
	      by the idassert-authzFrom patterns.

	      This  directive  obsoletes  idassert-authcDN,   idassert-passwd,
	      idassert-mode, and idassert-method.

       idle-timeout <time>
	      This  directive  causes  a  cached  connection  to be dropped an
	      recreated after it has been idle for the specified time.

       protocol-version {0,2,3}
	      This directive indicates what protocol version must be  used  to
	      contact the remote server.  If set to 0 (the default), the proxy
	      uses the same protocol version used by the client, otherwise the
	      requested	   protocol    is    used.     The    proxy    returns
	      unwillingToPerform if an operation that is incompatible with the
	      requested protocol is attempted.

       proxy-whoami {NO|yes}
	      Turns  on	 proxying  of  the  WhoAmI extended operation. If this
	      option is given, back-ldap will replace slapd's original	WhoAmI
	      routine  with its own. On slapd sessions that were authenticated
	      by back-ldap, the WhoAmI request will be forwarded to the remote
	      LDAP  server. Other sessions will be handled by the local slapd,
	      as before. This option is	 mainly	 useful	 in  conjunction  with
	      Proxy Authorization.

       rebind-as-user {NO|yes}
	      If  this	option	is  given,  the	 client's bind credentials are
	      remembered for rebinds  when  chasing  referrals.	  Useful  when
	      chase-referrals is set to yes, useless otherwise.

       t-f-support {NO|yes|discover}
	      enable  if  the  remote  server  supports	 absolute filters (see
	      draft-zeilenga-ldap-t-f  for  details).	If  set	 to  discover,
	      support is detected by reading the remote server's root DSE.

       timeout [{add|delete|modify|modrdn}=]<val> [...]
	      This  directive  allows  to  set	per-operation timeouts.	 If no
	      operation is specified, it affects all.  Currently,  only	 write
	      operations  are  addressed,  because  searches  can  already  be
	      limited by means of the limits directive (see slapd.conf(5)  for
	      details),	 and  other  operations are not supposed to incur into
	      the need for timeouts.  Note: if the timelimit is exceeded,  the
	      operation	 is abandoned; the protocol does not provide any means
	      to rollback the operation, so the client will not	 know  if  the
	      operation eventually succeeded or not.

       tls {[try-]start|[try-]propagate}
	      execute  the  StartTLS extended operation when the connection is
	      initialized; only works if the URI directive protocol scheme  is
	      not  ldaps://.   propagate issues the StartTLS operation only if
	      the original connection did.   The  try-	prefix	instructs  the
	      proxy  to	 continue operations if the StartTLS operation failed;
	      its use is highly deprecated.

BACKWARD COMPATIBILITY
       The LDAP backend has been heavily reworked  between  releases  2.2  and
       2.3;  as	 a  side-effect,  some of the traditional directives have been
       deprecated and should be no longer used, as  they  might	 disappear  in
       future releases.

       server <hostname[:port]>
	      this directive is no longer supported.  Use the uri directive as
	      described above.

       acl-authcDN <administrative DN for access control purposes>
	      DN which is used to query the target server for acl checking; it
	      is  supposed  to	have  read  access  on	the  target  server to
	      attributes used on the proxy for acl checking.  There is no risk
	      of  giving  away	such  values;  they  are  only	used  to check
	      permissions.  The acl-authcDN identity is by no means implicitly
	      used by the proxy when the client connects anonymously.  See the
	      idassert-* feature instead.  This directive is obsoleted by  the
	      binddn  arg  of  acl-bind	 when  bindmethod=simple,  and will be
	      dismissed in the future.

       acl-passwd <password>
	      Password	used  with  the	 above	acl-authcDN  directive.	  This
	      directive	 is  obsoleted	by  the	 binddn	 arg  of acl-bind when
	      bindmethod=simple, and will be dismissed in the future.

       idassert-authcDN <administrative DN for proxyAuthz purposes>
	      DN which is used to  propagate  the  client's  identity  to  the
	      target  by  means of the proxyAuthz control when the client does
	      not belong to the DIT fragment that is being  proxied  by	 back-
	      ldap.   This  directive  is  obsoleted  by  the  binddn  arg  of
	      idassert-bind when bindmethod=simple, and will be	 dismissed  in
	      the future.

       idassert-passwd <password>
	      Password	used  with the idassert-authcDN above.	This directive
	      is  obsoleted  by	 the  crendentials   of	  idassert-bind	  when
	      bindmethod=simple, and will be dismissed in the future.

       idassert-mode <mode> [<flags>]
	      defines what type of identity assertion is used.	This directive
	      is obsoleted by the mode	arg  of	 idassert-bind,	 and  will  be
	      dismissed in the future.

       idassert-method <method> [<saslargs>]
	      This  directive  is obsoleted by the bindmethod arg of idassert-
	      bind, and will be dismissed in the future.

       suffixmassage, map, rewrite*
	      These directives are no longer  supported	 by  back-ldap;	 their
	      functionality is now delegated to the rwm overlay.  Essentially,
	      add a statement

	      overlay rwm

	      first, and prefix all rewrite/map statements with rwm- to obtain
	      the original behavior.  See slapo-rwm(5) for details.

ACCESS CONTROL
       The  ldap  backend  does	 not  honor  all ACL semantics as described in
       slapd.access(5).	 In general,  access  checking	is  delegated  to  the
       remote  server(s).  Only read (=r) access to the entry pseudo-attribute
       and to the other attribute values of the entries returned by the search
       operation is honored, which is performed by the frontend.

OVERLAYS
       The  LDAP  backend  provides  basic  proxying  functionalities  to many
       overlays.  The chain overlay,  described	 in  slapo-chain(5),  and  the
       translucent  overlay,  described	 in  slapo-translucent(5),  deserve  a
       special mention.

       Conversely, there are many overlays that are best used  in  conjunction
       with  the  LDAP backend.	 The proxycache overlay allows caching of LDAP
       search requests (queries) in a local database.  See slapo-pcache(5) for
       details.	 The rwm overlay provides DN rewrite and attribute/objectClass
       mapping capabilities to the underlying database.	 See slapo-rwm(5)  for
       details.

FILES
       /etc/openldap/slapd.conf
	      default slapd configuration file

SEE ALSO
       slapd.conf(5),	 slapd-meta(5),	   slapo-chain(5),    slapo-pcache(5),
       slapo-rwm(5), slapo-translucent(5), slapd(8), ldap(3).

AUTHOR
       Howard Chu, with enhancements by Pierangelo Masarati

OpenLDAP 2.3.27			  2006/08/19			 SLAPD-LDAP(5)
[top]
                             _         _         _ 
                            | |       | |       | |     
                            | |       | |       | |     
                         __ | | __ __ | | __ __ | | __  
                         \ \| |/ / \ \| |/ / \ \| |/ /  
                          \ \ / /   \ \ / /   \ \ / /   
                           \   /     \   /     \   /    
                            \_/       \_/       \_/ 
More information is available in HTML format for server UnixWare

List of man pages available for UnixWare

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net