diff --git a/sudoers.ldap.cat b/sudoers.ldap.cat
index 590aecbd0..d650c33ec 100644
--- a/sudoers.ldap.cat
+++ b/sudoers.ldap.cat
@@ -15,17 +15,9 @@ DDEESSCCRRIIPPTTIIOONN
        Using LDAP for _s_u_d_o_e_r_s has several benefits:
 
        +o   ssuuddoo no longer needs to read _s_u_d_o_e_r_s in its entirety.
-           Parsing of _/_e_t_c_/_s_u_d_o_e_r_s requires the entire file to be
-           read.  When LDAP is used, there are only two or three
-           LDAP queries per invocation.  This makes it especially
-           fast and particularly usable in LDAP environments.
-           The first query is to parse global options (see
-           below).  The second is to match against the user's
-           name and the groups that the user belongs to.  (The
-           special ALL tag is matched in this query too.)  If no
-           match is returned for the user's name and groups, a
-           third query returns all entries contain user netgroups
-           and checks to see if the user belongs to any of them.
+           When LDAP is used, there are only two or three LDAP
+           queries per invocation.  This makes it especially fast
+           and particularly usable in LDAP environments.
 
        +o   ssuuddoo no longer exits if there is a typo in _s_u_d_o_e_r_s.
            It is not possible to load LDAP data into the server
@@ -34,23 +26,13 @@ DDEESSCCRRIIPPTTIIOONN
            typos in a user or host name, but this will not pre-
            vent ssuuddoo from running.
 
-       +o   Options inside of entries now override global default
-           options.  _/_e_t_c_/_s_u_d_o_e_r_s only supports default options
-           and limited options associated with user/host/commands
-           and aliases.  The syntax is complicated and can be
-           difficult for users to understand.
-
-           Sudo first looks for an entry called cn=default in the
-           SUDOers container.  If found, the multi-valued sudoOp-
-           tion attribute is parsed the same way the global
-           Defaults line in _/_e_t_c_/_s_u_d_o_e_r_s is parsed.
-
-           If, on the second or third query, a response contains
-           a sudoRole which matches against the user, host, and
-           command, then the matched object is scanned for a
-           additional options that override the top-level
-           defaults.  See the example LDAP content below for more
-           information.
+       +o   It is possible to specify per-entry options that over-
+           ride the global default options.  _/_e_t_c_/_s_u_d_o_e_r_s only
+           supports default options and limited options associ-
+           ated with user/host/commands/aliases.  The syntax is
+           complicated and can be difficult for users to under-
+           stand.  Placing the options directly in the entry is
+           more natural.
 
        +o   vviissuuddoo is no longer needed.  vviissuuddoo provides locking
            and syntax checking of the _/_e_t_c_/_s_u_d_o_e_r_s file.  Since
@@ -59,6 +41,24 @@ DDEESSCCRRIIPPTTIIOONN
            inserted into LDAP, there is no need for a specialized
            tool to check syntax.
 
+       Another major difference between LDAP and file-based _s_u_d_o_-
+       _e_r_s is that in LDAP, ssuuddoo-specific Aliases are not sup-
+       ported.
+
+       For the most part, there is really no need for ssuuddoo-spe-
+       cific Aliases.  Unix groups or user netgroups can be used
+       in place of User_Aliases and RunasAliases.  Host netgroups
+       can be used in place of HostAliases.  Since Unix groups
+       and netgroups can also be stored in LDAP there is no real
+       need for ssuuddoo-specific aliases.
+
+       Cmnd_Aliases are not really required either since it is
+       possible to have multiple users listed in a sudoRole.
+       Instead of defining a Cmnd_Alias that is referenced by
+       multiple users, one can create a sudoRole that contains
+       the commands and assign multiple users to it.
+
+
 
 
 1.7                      January 20, 2008                       1
@@ -70,25 +70,6 @@ DDEESSCCRRIIPPTTIIOONN
 SUDOERS.LDAP(4)        MAINTENANCE COMMANDS       SUDOERS.LDAP(4)
 
 
-       +o   Aliases are no longer needed.  User, Host, and Cmnd
-           Aliases were designed to simplify organization of
-           _s_u_d_o_e_r_s files and to improve readability.  Since an
-           LDAP _s_u_d_o_e_r_s entry allows multiple values for each of
-           its attributes, and since most LDAP browsers are
-           graphical and easy to work with, these aliases are no
-           longer needed.
-
-           If you wish to specify a large number of users into an
-           entry or wish to have similar entries with identical
-           users, then either use groups or user netgroups.
-           Alternately, they can all just be pasted into the LDAP
-           record.
-
-           If you need to specify a large number of hosts in an
-           entry, use netgroups or IP address matches
-           (10.2.3.4/255.255.0.0).  Alternately, they can all
-           just be pasted into the LDAP record.
-
        SSUUDDOOeerrss LLDDAAPP ccoonnttaaiinneerr
 
        The _s_u_d_o_e_r_s configuration is contained in the ou=SUDOers
@@ -111,19 +92,38 @@ SUDOERS.LDAP(4)        MAINTENANCE COMMANDS       SUDOERS.LDAP(4)
        The equivalent of a sudoer in LDAP is a sudoRole.  It con-
        sists of the following components:
 
-       sudoUser
+       ssuuddooUUsseerr
            A user name, uid (prefixed with '#'), Unix group (pre-
            fixed with a '%') or user netgroup (prefixed with a
            '+').
 
-       sudoHost
+       ssuuddooHHoosstt
            A host name, IP address, IP network, or host netgroup
            (prefixed with a '+').  The special value ALL will
            match any host.
 
-       sudoCommand
+       ssuuddooCCoommmmaanndd
            A Unix command with optional command line arguments,
            potentially including globbing characters (aka wild
+           cards).  The special value ALL will match any command.
+           If a command is prefixed with an exclamation point
+           '!', the user will be prohibited from running that
+           command.
+
+       ssuuddooOOppttiioonn
+           Identical in function to the global options described
+           above, but specific to the sudoRole in which it
+           resides.
+
+       ssuuddooRRuunnAAssUUsseerr
+           A user name or uid (prefixed with '#') that commands
+           may be run as or a Unix group (prefixed with a '%') or
+           user netgroup (prefixed with a '+') that contains a
+           list of users that commands may be run as.  The spe-
+           cial value ALL will match any user.
+
+       ssuuddooRRuunnAAssGGrroouupp
+           A Unix group or gid (prefixed with '#') that commands
 
 
 
@@ -136,27 +136,13 @@ SUDOERS.LDAP(4)        MAINTENANCE COMMANDS       SUDOERS.LDAP(4)
 SUDOERS.LDAP(4)        MAINTENANCE COMMANDS       SUDOERS.LDAP(4)
 
 
-           cards).  The special value ALL will match any command.
-
-       sudoOption
-           Similar to the global options described above, but
-           specific to the sudoRole in which it resides.
-
-       sudoRunAsUser
-           A user name or uid (prefixed with '#') that commands
-           may be run as or a Unix group (prefixed with a '%') or
-           user netgroup (prefixed with a '+') that contains a
-           list of users that commands may be run as.  The spe-
-           cial value ALL will match any user.
-
-       sudoRunAsGroup
-           A Unix group or gid (prefixed with '#') that commands
            may be run as.  The special value ALL will match any
            group.
 
-       Each entry listed above contains a single value, but may
-       be repeated multiple times.  A sudoRole must contain at
-       least one sudoUser, sudoHost and sudoCommand.
+       Each component listed above should contain a single value,
+       but there may be multiple instances of each component
+       type.  A sudoRole must contain at least one sudoUser,
+       sudoHost and sudoCommand.
 
        The following example allows users in group wheel to run
        any command on any host via ssuuddoo:
@@ -169,16 +155,27 @@ SUDOERS.LDAP(4)        MAINTENANCE COMMANDS       SUDOERS.LDAP(4)
            sudoHost: ALL
            sudoCommand: ALL
 
+       AAnnaattoommyy ooff LLDDAAPP ssuuddooeerrss llooookkuupp
+
+       When looking up a sudoer using LDAP there are only two or
+       three LDAP queries per invocation.  The first query is to
+       parse the global options.  The second is to match against
+       the user's name and the groups that the user belongs to.
+       (The special ALL tag is matched in this query too.)  If no
+       match is returned for the user's name and groups, a third
+       query returns all entries containing user netgroups and
+       checks to see if the user belongs to any of them.
+
        DDiiffffeerreenncceess bbeettwweeeenn LLDDAAPP aanndd nnoonn--LLDDAAPP ssuuddooeerrss
 
        There are some subtle differences in the way sudoers is
        handled once in LDAP.  Probably the biggest is that
-       according to the RFC, LDAP's ordering is arbitrary and you
+       according to the RFC, LDAP ordering is arbitrary and you
        cannot expect that Attributes and Entries are returned in
-       any order.  If there are conflicting command rules on an
-       entry, the negative takes precedence.  This is called
-       paranoid behavior (not necessarily the most specific
-       match).
+       any specific order.  If there are conflicting command
+       rules on an entry, the negative takes precedence.  This is
+       called paranoid behavior (not necessarily the most spe-
+       cific match).
 
        Here is an example:
 
@@ -193,6 +190,9 @@ SUDOERS.LDAP(4)        MAINTENANCE COMMANDS       SUDOERS.LDAP(4)
 
 
 
+
+
+
 1.7                      January 20, 2008                       3
 
 
@@ -202,7 +202,7 @@ SUDOERS.LDAP(4)        MAINTENANCE COMMANDS       SUDOERS.LDAP(4)
 SUDOERS.LDAP(4)        MAINTENANCE COMMANDS       SUDOERS.LDAP(4)
 
 
-           # LDAP equivalent of Johnny
+           # LDAP equivalent of johnny
            # Allows all commands except shell
            dn: cn=role1,ou=Sudoers,dc=my-domain,dc=com
            objectClass: sudoRole
@@ -213,7 +213,7 @@ SUDOERS.LDAP(4)        MAINTENANCE COMMANDS       SUDOERS.LDAP(4)
            sudoCommand: ALL
            sudoCommand: !/bin/sh
 
-           # LDAP equivalent of Puddles
+           # LDAP equivalent of puddles
            # Notice that even though ALL comes last, it still behaves like
            # role1 since the LDAP code assumes the more paranoid configuration
            dn: cn=role2,ou=Sudoers,dc=my-domain,dc=com
@@ -227,7 +227,7 @@ SUDOERS.LDAP(4)        MAINTENANCE COMMANDS       SUDOERS.LDAP(4)
 
        Another difference is that negations on the Host, User or
        Runas are currently ignorred.  For example, the following
-       attributes do not do what they might appear to do.
+       attributes do not behave the way one might expect.
 
            # does not match all but joe
            # rather, does not match anyone
@@ -286,7 +286,7 @@ SUDOERS.LDAP(4)        MAINTENANCE COMMANDS       SUDOERS.LDAP(4)
        options are listed below in upper case but are parsed in a
        case-independent manner.
 
-       URI ldap[s]://[hostname[:port]] ...
+       UURRII ldap[s]://[hostname[:port]] ...
            Specifies a whitespace-delimited list of one or more
            URIs describing the LDAP server(s) to connect to.  The
            _p_r_o_t_o_c_o_l may be either llddaapp or llddaappss, the latter being
@@ -299,7 +299,7 @@ SUDOERS.LDAP(4)        MAINTENANCE COMMANDS       SUDOERS.LDAP(4)
            libraries used on most commercial versions of Unix are
            only capable of supporting one or the other.
 
-       HOST name[:port] ...
+       HHOOSSTT name[:port] ...
            If no UURRII is specified, the HHOOSSTT parameter specifies a
            whitespace-delimited list of LDAP servers to connect
            to.  Each host may include an optional _p_o_r_t separated
@@ -307,7 +307,7 @@ SUDOERS.LDAP(4)        MAINTENANCE COMMANDS       SUDOERS.LDAP(4)
            favor of the UURRII specification and is included for
            backwards compatibility.
 
-       PORT port_number
+       PPOORRTT port_number
            If no UURRII is specified, the PPOORRTT parameter specifies
            the default port to connect to on the LDAP server if a
            HHOOSSTT parameter does not specify the port itself.  If
@@ -316,7 +316,7 @@ SUDOERS.LDAP(4)        MAINTENANCE COMMANDS       SUDOERS.LDAP(4)
            parameter is deprecated in favor of the UURRII specifica-
            tion and is included for backwards compatibility.
 
-       BIND_TIMELIMIT seconds
+       BBIINNDD__TTIIMMEELLIIMMIITT seconds
            The BBIINNDD__TTIIMMEELLIIMMIITT parameter specifies the amount of
            time, in seconds, to wait while trying to connect to
            an LDAP server.  If multiple UURRIIs or HHOOSSTTs are speci-
@@ -334,16 +334,16 @@ SUDOERS.LDAP(4)        MAINTENANCE COMMANDS       SUDOERS.LDAP(4)
 SUDOERS.LDAP(4)        MAINTENANCE COMMANDS       SUDOERS.LDAP(4)
 
 
-       TIMELIMIT seconds
+       TTIIMMEELLIIMMIITT seconds
            The TTIIMMEELLIIMMIITT parameter specifies the amount of time,
            in seconds, to wait for a response to an LDAP query.
 
-       SUDOERS_BASE base
+       SSUUDDOOEERRSS__BBAASSEE base
            The base DN to use when performing ssuuddoo LDAP queries.
            Typically this is of the form ou=SUDOers,dc=exam-
            ple,dc=com for the domain example.com.
 
-       SUDOERS_DEBUG debug_level
+       SSUUDDOOEERRSS__DDEEBBUUGG debug_level
            This sets the debug level for ssuuddoo LDAP queries.
            Debugging information is printed to the standard
            error.  A value of 1 results in a moderate amount of
@@ -352,7 +352,7 @@ SUDOERS.LDAP(4)        MAINTENANCE COMMANDS       SUDOERS.LDAP(4)
            be set in a production environment as the extra infor-
            mation is likely to confuse users.
 
-       BINDDN DN
+       BBIINNDDDDNN DN
            The BBIINNDDDDNN parameter specifies the identity, in the
            form of a Distinguished Name (DN), to use when per-
            forming LDAP operations.  If not specified, LDAP oper-
@@ -360,12 +360,12 @@ SUDOERS.LDAP(4)        MAINTENANCE COMMANDS       SUDOERS.LDAP(4)
            default, most LDAP servers will allow anonymous
            access.
 
-       BINDPW secret
+       BBIINNDDPPWW secret
            The BBIINNDDPPWW parameter specifies the password to use
            when performing LDAP operations.  This is typically
            used in conjunction with the BBIINNDDDDNN parameter.
 
-       ROOTBINDDN DN
+       RROOOOTTBBIINNDDDDNN DN
            The RROOOOTTBBIINNDDDDNN parameter specifies the identity, in
            the form of a Distinguished Name (DN), to use when
            performing privileged LDAP operations, such as _s_u_d_o_e_r_s
@@ -373,18 +373,18 @@ SUDOERS.LDAP(4)        MAINTENANCE COMMANDS       SUDOERS.LDAP(4)
            should be stored in _/_e_t_c_/_l_d_a_p_._s_e_c_r_e_t.  If not speci-
            fied, the BBIINNDDDDNN identity is used (if any).
 
-       LDAP_VERSION number
+       LLDDAAPP__VVEERRSSIIOONN number
            The version of the LDAP protocol to use when connect-
            ing to the server.  The default value is protocol ver-
            sion 3.
 
-       SSL on/true/yes/off/false/no
+       SSSSLL on/true/yes/off/false/no
            If the SSSSLL parameter is set to on, true or yes, TLS
            (SSL) encryption is always used when communicating
            with the LDAP server.  Typically, this involves con-
            necting to the server on port 636 (ldaps).
 
-       SSL start_tls
+       SSSSLL start_tls
            If the SSSSLL parameter is set to start_tls, the LDAP
            server connection is initiated normally and TLS
            encryption is begun before the bind credentials are
@@ -405,7 +405,7 @@ SUDOERS.LDAP(4)        MAINTENANCE COMMANDS       SUDOERS.LDAP(4)
            ter is only supported by LDAP servers that honor the
            start_tls extension, such as the OpenLDAP server.
 
-       TLS_CHECKPEER on/true/yes/off/false/no
+       TTLLSS__CCHHEECCKKPPEEEERR on/true/yes/off/false/no
            If enabled, TTLLSS__CCHHEECCKKPPEEEERR will cause the LDAP server's
            TLS certificated to be verified.  If the server's TLS
            certificate cannot be verified (usually because it is
@@ -413,14 +413,14 @@ SUDOERS.LDAP(4)        MAINTENANCE COMMANDS       SUDOERS.LDAP(4)
            be unable to connect to it.  If TTLLSS__CCHHEECCKKPPEEEERR is dis-
            abled, no check is made.
 
-       TLS_CACERTFILE file name
+       TTLLSS__CCAACCEERRTTFFIILLEE file name
            The path to a certificate authority bundle which con-
            tains the certificates for all the Certificate Author-
            ities the client knows to be valid, e.g.
            _/_e_t_c_/_s_s_l_/_c_a_-_b_u_n_d_l_e_._p_e_m.  This option is only supported
            by the OpenLDAP libraries.
 
-       TLS_CACERTDIR directory
+       TTLLSS__CCAACCEERRTTDDIIRR directory
            Similar to TTLLSS__CCAACCEERRTTFFIILLEE but instead of a file, it is
            a directory containing individual Certificate Author-
            ity certificates, e.g. _/_e_t_c_/_s_s_l_/_c_e_r_t_s.  The directory
@@ -428,32 +428,32 @@ SUDOERS.LDAP(4)        MAINTENANCE COMMANDS       SUDOERS.LDAP(4)
            EERRTTFFIILLEE.  This option is only supported by the OpenL-
            DAP libraries.
 
-       TLS_CERT file name
+       TTLLSS__CCEERRTT file name
            The path to a file containing the client certificate
            which can be used to authenticate the client to the
-           LDAP server.
+           LDAP server.  The certificate type depends on the LDAP
+           libraries used.
 
-           OpenLDAP          tls_cert /etc/ssl/client_cert.pem
+           OpenLDAP:
+               tls_cert /etc/ssl/client_cert.pem
 
-           Netscape-derived  tls_cert /var/ldap/cert7.db
+           Netscape-derived:
+               tls_cert /var/ldap/cert7.db
 
            When using Netscape-derived libraries, this file may
            also contain Certificate Authority certificates.
 
-       TLS_KEY file name
+       TTLLSS__KKEEYY file name
            The path to a file containing the private key which
            matches the certificate specified by TTLLSS__CCEERRTT.  The
-           private key must not be password-protected.
+           private key must not be password-protected.  The key
+           type depends on the LDAP libraries used.
 
-           OpenLDAP          tls_cert /etc/ssl/client_key.pem
+           OpenLDAP:
+               tls_cert /etc/ssl/client_key.pem
 
-           Netscape-derived  tls_cert /var/ldap/key3.db
-
-       TLS_RANDFILE file name
-           The TTLLSS__RRAANNDDFFIILLEE parameter specifies the path to an
-           entropy source for systems that lack a random device.
-           It is generally used in conjunction with _p_r_n_g_d or _e_g_d.
-           This option is only supported by the OpenLDAP
+           Netscape-derived:
+               tls_cert /var/ldap/key3.db
 
 
 
@@ -466,38 +466,43 @@ SUDOERS.LDAP(4)        MAINTENANCE COMMANDS       SUDOERS.LDAP(4)
 SUDOERS.LDAP(4)        MAINTENANCE COMMANDS       SUDOERS.LDAP(4)
 
 
+       TTLLSS__RRAANNDDFFIILLEE file name
+           The TTLLSS__RRAANNDDFFIILLEE parameter specifies the path to an
+           entropy source for systems that lack a random device.
+           It is generally used in conjunction with _p_r_n_g_d or _e_g_d.
+           This option is only supported by the OpenLDAP
            libraries.
 
-       TLS_CIPHERS cipher list
+       TTLLSS__CCIIPPHHEERRSS cipher list
            The TTLLSS__CCIIPPHHEERRSS parameter allows the administer to
            restrict which encryption algorithms may be used for
            TLS (SSL) connections.  See the OpenSSL manual for a
            list of valid ciphers.  This option is only supported
            by the OpenLDAP libraries.
 
-       USE_SASL on/true/yes/off/false/no
+       UUSSEE__SSAASSLL on/true/yes/off/false/no
            Enable UUSSEE__SSAASSLL for LDAP servers that support SASL
            authentication.
 
-       SASL_AUTH_ID identity
+       SSAASSLL__AAUUTTHH__IIDD identity
            The SASL user name to use when connecting to the LDAP
            server.  By default, ssuuddoo will use an anonymous con-
            nection.
 
-       ROOTUSE_SASL on/true/yes/off/false/no
+       RROOOOTTUUSSEE__SSAASSLL on/true/yes/off/false/no
            Enable RROOOOTTUUSSEE__SSAASSLL to enable SASL authentication when
            connecting to an LDAP server from a privileged pro-
            cess, such as ssuuddoo.
 
-       ROOTSASL_AUTH_ID identity
+       RROOOOTTSSAASSLL__AAUUTTHH__IIDD identity
            The SASL user name to use when RROOOOTTUUSSEE__SSAASSLL is
            enabled.
 
-       SASL_SECPROPS none/properties
+       SSAASSLL__SSEECCPPRROOPPSS none/properties
            SASL security properties or _n_o_n_e for no properties.
            See the SASL programmer's manual for details.
 
-       KRB5_CCNAME file name
+       KKRRBB55__CCCCNNAAMMEE file name
            The path to the Kerberos 5 credential cache to use
            when authenticating with the remote server.
 
@@ -514,12 +519,7 @@ SUDOERS.LDAP(4)        MAINTENANCE COMMANDS       SUDOERS.LDAP(4)
 
        The following sources are recognized:
 
-           files       read sudoers from a file (usually F</etc/sudoers>)
-           ldap        read sudoers from LDAP
 
-       In addition, the entry [NOTFOUND=return] will short-cir-
-       cuit the search if the user was not found in the preceding
-       source.
 
 
 
@@ -532,6 +532,13 @@ SUDOERS.LDAP(4)        MAINTENANCE COMMANDS       SUDOERS.LDAP(4)
 SUDOERS.LDAP(4)        MAINTENANCE COMMANDS       SUDOERS.LDAP(4)
 
 
+           files       read sudoers from F</etc/sudoers>
+           ldap        read sudoers from LDAP
+
+       In addition, the entry [NOTFOUND=return] will short-cir-
+       cuit the search if the user was not found in the preceding
+       source.
+
        To consult LDAP first followed by the local sudoers file
        (if it exists), use:
 
@@ -574,13 +581,6 @@ EEXXAAMMPPLLEESS
 
 
 
-
-
-
-
-
-
-
 
 
 
@@ -803,10 +803,14 @@ SUDOERS.LDAP(4)        MAINTENANCE COMMANDS       SUDOERS.LDAP(4)
 
 
 SSEEEE AALLSSOO
-       _l_d_a_p_._c_o_n_f(4), _s_u_d_o_e_r_s(4)
+       _l_d_a_p_._c_o_n_f(4), _s_u_d_o_e_r_s(5)
 
 CCAAVVEEAATTSS
-       parsing differences between LDAP and file sudoers
+       The way that _s_u_d_o_e_r_s is parsed differs between Note that
+       there are differences in the way that LDAP-based _s_u_d_o_e_r_s
+       is parsed compared to file-based _s_u_d_o_e_r_s.  See the "Dif-
+       ferences between LDAP and non-LDAP sudoers" section for
+       more information.
 
 BBUUGGSS
        If you feel you have found a bug in ssuuddoo, please submit a
@@ -844,10 +848,6 @@ DDIISSCCLLAAIIMMEERR
 
 
 
-
-
-
-
 
 
 
diff --git a/sudoers.ldap.man.in b/sudoers.ldap.man.in
index d1952a680..a9ba18438 100644
--- a/sudoers.ldap.man.in
+++ b/sudoers.ldap.man.in
@@ -157,16 +157,10 @@ in a large, distributed environment.
 .PP
 Using \s-1LDAP\s0 for \fIsudoers\fR has several benefits:
 .IP "\(bu" 4
-\&\fBsudo\fR no longer needs to read \fIsudoers\fR in its entirety.  Parsing
-of \fI/etc/sudoers\fR requires the entire file to be read.  When \s-1LDAP\s0
-is used, there are only two or three \s-1LDAP\s0 queries per invocation.
+\&\fBsudo\fR no longer needs to read \fIsudoers\fR in its entirety.  When
+\&\s-1LDAP\s0 is used, there are only two or three \s-1LDAP\s0 queries per invocation.
 This makes it especially fast and particularly usable in \s-1LDAP\s0
-environments.  The first query is to parse global options (see
-below).  The second is to match against the user's name and the
-groups that the user belongs to.  (The special \s-1ALL\s0 tag is matched
-in this query too.)  If no match is returned for the user's name
-and groups, a third query returns all entries contain user netgroups
-and checks to see if the user belongs to any of them.
+environments.
 .IP "\(bu" 4
 \&\fBsudo\fR no longer exits if there is a typo in \fIsudoers\fR.
 It is not possible to load \s-1LDAP\s0 data into the server that does
@@ -174,42 +168,32 @@ not conform to the sudoers schema, so proper syntax is guaranteed.
 It is still possible to have typos in a user or host name, but
 this will not prevent \fBsudo\fR from running.
 .IP "\(bu" 4
-Options inside of entries now override global default options.
-\&\fI/etc/sudoers\fR only supports default options and limited options
-associated with user/host/commands and aliases.  The syntax is
-complicated and can be difficult for users to understand.
-.Sp
-Sudo first looks for an entry called \f(CW\*(C`cn=default\*(C'\fR in the \f(CW\*(C`SUDOers\*(C'\fR
-container.  If found, the multi-valued \f(CW\*(C`sudoOption\*(C'\fR attribute is
-parsed the same way the global \f(CW\*(C`Defaults\*(C'\fR line in \fI/etc/sudoers\fR
-is parsed.
-.Sp
-If, on the second or third query, a response contains a sudoRole
-which matches against the user, host, and command, then the matched
-object is scanned for a additional options that override the top-level
-defaults.  See the example \s-1LDAP\s0 content below for more information.
+It is possible to specify per-entry options that override the global
+default options.  \fI@sysconfdir@/sudoers\fR only supports default options and
+limited options associated with user/host/commands/aliases.  The
+syntax is complicated and can be difficult for users to understand.
+Placing the options directly in the entry is more natural.
 .IP "\(bu" 4
 \&\fBvisudo\fR is no longer needed.  \fBvisudo\fR provides locking and
-syntax checking of the \fI/etc/sudoers\fR file.  Since \s-1LDAP\s0 updates
+syntax checking of the \fI@sysconfdir@/sudoers\fR file.  Since \s-1LDAP\s0 updates
 are atomic, locking is no longer necessary.  Because syntax is
 checked when the data is inserted into \s-1LDAP\s0, there is no need
 for a specialized tool to check syntax.
-.IP "\(bu" 4
-Aliases are no longer needed.  User, Host, and Cmnd Aliases were
-designed to simplify organization of \fIsudoers\fR files and to
-improve readability.  Since an \s-1LDAP\s0 \fIsudoers\fR entry allows multiple
-values for each of its attributes, and since most \s-1LDAP\s0 browsers are
-graphical and easy to work with, these aliases are no longer
-needed.
-.Sp
-If you wish to specify a large number of users into an entry or
-wish to have similar entries with identical users, then either use
-groups or user netgroups.  Alternately, they can all just be pasted
-into the \s-1LDAP\s0 record.
-.Sp
-If you need to specify a large number of hosts in an entry, use
-netgroups or \s-1IP\s0 address matches (10.2.3.4/255.255.0.0).  Alternately,
-they can all just be pasted into the \s-1LDAP\s0 record.
+.PP
+Another major difference between \s-1LDAP\s0 and file-based \fIsudoers\fR
+is that in \s-1LDAP\s0, \fBsudo\fR\-specific Aliases are not supported.
+.PP
+For the most part, there is really no need for \fBsudo\fR\-specific
+Aliases.  Unix groups or user netgroups can be used in place of
+User_Aliases and RunasAliases.  Host netgroups can be used in place
+of HostAliases.  Since Unix groups and netgroups can also be stored
+in \s-1LDAP\s0 there is no real need for \fBsudo\fR\-specific aliases.
+.PP
+Cmnd_Aliases are not really required either since it is possible
+to have multiple users listed in a sudoRole.  Instead of defining
+a Cmnd_Alias that is referenced by multiple users, one can create
+a sudoRole that contains the commands and assign multiple users
+to it.
 .Sh "SUDOers \s-1LDAP\s0 container"
 .IX Subsection "SUDOers LDAP container"
 The \fIsudoers\fR configuration is contained in the \f(CW\*(C`ou=SUDOers\*(C'\fR \s-1LDAP\s0
@@ -217,7 +201,7 @@ container.
 .PP
 Sudo first looks for the \f(CW\*(C`cn=default\*(C'\fR entry in the SUDOers container.
 If found, the multi-valued \f(CW\*(C`sudoOption\*(C'\fR attribute is parsed in the
-same manner as a global \f(CW\*(C`Defaults\*(C'\fR line in \fI/etc/sudoers\fR.  In
+same manner as a global \f(CW\*(C`Defaults\*(C'\fR line in \fI@sysconfdir@/sudoers\fR.  In
 the following example, the \f(CW\*(C`SSH_AUTH_SOCK\*(C'\fR variable will be preserved
 in the environment for all users.
 .PP
@@ -232,39 +216,41 @@ in the environment for all users.
 .PP
 The equivalent of a sudoer in \s-1LDAP\s0 is a \f(CW\*(C`sudoRole\*(C'\fR.  It consists of
 the following components:
-.IP "sudoUser" 4
+.IP "\fBsudoUser\fR" 4
 .IX Item "sudoUser"
 A user name, uid (prefixed with \f(CW'#'\fR), Unix group (prefixed with
 a \f(CW'%'\fR) or user netgroup (prefixed with a \f(CW'+'\fR).
-.IP "sudoHost" 4
+.IP "\fBsudoHost\fR" 4
 .IX Item "sudoHost"
 A host name, \s-1IP\s0 address, \s-1IP\s0 network, or host netgroup (prefixed
 with a \f(CW'+'\fR).
 The special value \f(CW\*(C`ALL\*(C'\fR will match any host.
-.IP "sudoCommand" 4
+.IP "\fBsudoCommand\fR" 4
 .IX Item "sudoCommand"
 A Unix command with optional command line arguments, potentially
 including globbing characters (aka wild cards).
 The special value \f(CW\*(C`ALL\*(C'\fR will match any command.
-.IP "sudoOption" 4
+If a command is prefixed with an exclamation point \f(CW'!'\fR, the
+user will be prohibited from running that command.
+.IP "\fBsudoOption\fR" 4
 .IX Item "sudoOption"
-Similar to the global options described above, but specific to the
-\&\f(CW\*(C`sudoRole\*(C'\fR in which it resides.
-.IP "sudoRunAsUser" 4
+Identical in function to the global options described above, but
+specific to the \f(CW\*(C`sudoRole\*(C'\fR in which it resides.
+.IP "\fBsudoRunAsUser\fR" 4
 .IX Item "sudoRunAsUser"
 A user name or uid (prefixed with \f(CW'#'\fR) that commands may be run
 as or a Unix group (prefixed with a \f(CW'%'\fR) or user netgroup (prefixed
 with a \f(CW'+'\fR) that contains a list of users that commands may be
 run as.
 The special value \f(CW\*(C`ALL\*(C'\fR will match any user.
-.IP "sudoRunAsGroup" 4
+.IP "\fBsudoRunAsGroup\fR" 4
 .IX Item "sudoRunAsGroup"
 A Unix group or gid (prefixed with \f(CW'#'\fR) that commands may be run as.
 The special value \f(CW\*(C`ALL\*(C'\fR will match any group.
 .PP
-Each entry listed above contains a single value, but may be repeated
-multiple times.  A sudoRole must contain at least one \f(CW\*(C`sudoUser\*(C'\fR,
-\&\f(CW\*(C`sudoHost\*(C'\fR and \f(CW\*(C`sudoCommand\*(C'\fR.
+Each component listed above should contain a single value, but there
+may be multiple instances of each component type.  A sudoRole must
+contain at least one \f(CW\*(C`sudoUser\*(C'\fR, \f(CW\*(C`sudoHost\*(C'\fR and \f(CW\*(C`sudoCommand\*(C'\fR.
 .PP
 The following example allows users in group wheel to run any command
 on any host via \fBsudo\fR:
@@ -278,14 +264,24 @@ on any host via \fBsudo\fR:
 \&    sudoHost: ALL
 \&    sudoCommand: ALL
 .Ve
+.Sh "Anatomy of \s-1LDAP\s0 sudoers lookup"
+.IX Subsection "Anatomy of LDAP sudoers lookup"
+When looking up a sudoer using \s-1LDAP\s0 there are only two or three
+\&\s-1LDAP\s0 queries per invocation.  The first query is to parse the global
+options.  The second is to match against the user's name and the
+groups that the user belongs to.  (The special \s-1ALL\s0 tag is matched
+in this query too.)  If no match is returned for the user's name
+and groups, a third query returns all entries containing user
+netgroups and checks to see if the user belongs to any of them.
 .Sh "Differences between \s-1LDAP\s0 and non-LDAP sudoers"
 .IX Subsection "Differences between LDAP and non-LDAP sudoers"
 There are some subtle differences in the way sudoers is handled
 once in \s-1LDAP\s0.  Probably the biggest is that according to the \s-1RFC\s0,
-\&\s-1LDAP\s0's ordering is arbitrary and you cannot expect that Attributes
-and Entries are returned in any order.  If there are conflicting
-command rules on an entry, the negative takes precedence.  This is
-called paranoid behavior (not necessarily the most specific match).
+\&\s-1LDAP\s0 ordering is arbitrary and you cannot expect that Attributes
+and Entries are returned in any specific order.  If there are
+conflicting command rules on an entry, the negative takes precedence.
+This is called paranoid behavior (not necessarily the most specific
+match).
 .PP
 Here is an example:
 .PP
@@ -298,7 +294,7 @@ Here is an example:
 .Ve
 .PP
 .Vb 10
-\&    # LDAP equivalent of Johnny
+\&    # LDAP equivalent of johnny
 \&    # Allows all commands except shell
 \&    dn: cn=role1,ou=Sudoers,dc=my-domain,dc=com
 \&    objectClass: sudoRole
@@ -311,7 +307,7 @@ Here is an example:
 .Ve
 .PP
 .Vb 11
-\&    # LDAP equivalent of Puddles
+\&    # LDAP equivalent of puddles
 \&    # Notice that even though ALL comes last, it still behaves like
 \&    # role1 since the LDAP code assumes the more paranoid configuration
 \&    dn: cn=role2,ou=Sudoers,dc=my-domain,dc=com
@@ -326,7 +322,7 @@ Here is an example:
 .PP
 Another difference is that negations on the Host, User or Runas are
 currently ignorred.  For example, the following attributes do not
-do what they might appear to do.
+behave the way one might expect.
 .PP
 .Vb 3
 \&    # does not match all but joe
@@ -374,7 +370,7 @@ values specified in \fI/etc/openldap/ldap.conf\fR or the user's
 Only those options explicitly listed in \fI@ldap_conf@\fR that are
 supported by \fBsudo\fR are honored.  Configuration options are listed
 below in upper case but are parsed in a case-independent manner.
-.IP "\s-1URI\s0 ldap[s]://[hostname[:port]] ..." 4
+.IP "\fB\s-1URI\s0\fR ldap[s]://[hostname[:port]] ..." 4
 .IX Item "URI ldap[s]://[hostname[:port]] ..."
 Specifies a whitespace-delimited list of one or more URIs describing
 the \s-1LDAP\s0 server(s) to connect to.  The \fIprotocol\fR may be either \fBldap\fR
@@ -385,14 +381,14 @@ encryption.  If no \fIport\fR is specified, the default is port 389 for
 libraries support the mixing of \f(CW\*(C`ldap://\*(C'\fR and \f(CW\*(C`ldaps://\*(C'\fR URIs.
 The Netscape-derived libraries used on most commercial versions of
 Unix are only capable of supporting one or the other.
-.IP "\s-1HOST\s0 name[:port] ..." 4
+.IP "\fB\s-1HOST\s0\fR name[:port] ..." 4
 .IX Item "HOST name[:port] ..."
 If no \fB\s-1URI\s0\fR is specified, the \fB\s-1HOST\s0\fR parameter specifies a
 whitespace-delimited list of \s-1LDAP\s0 servers to connect to.  Each host
 may include an optional \fIport\fR separated by a colon (':').  The
 \&\fB\s-1HOST\s0\fR parameter is deprecated in favor of the \fB\s-1URI\s0\fR specification
 and is included for backwards compatibility.
-.IP "\s-1PORT\s0 port_number" 4
+.IP "\fB\s-1PORT\s0\fR port_number" 4
 .IX Item "PORT port_number"
 If no \fB\s-1URI\s0\fR is specified, the \fB\s-1PORT\s0\fR parameter specifies the
 default port to connect to on the \s-1LDAP\s0 server if a \fB\s-1HOST\s0\fR parameter
@@ -400,22 +396,22 @@ does not specify the port itself.  If no \fB\s-1PORT\s0\fR parameter is used,
 the default is port 389 for \s-1LDAP\s0 and port 636 for \s-1LDAP\s0 over \s-1TLS\s0
 (\s-1SSL\s0).  The \fB\s-1PORT\s0\fR parameter is deprecated in favor of the \fB\s-1URI\s0\fR
 specification and is included for backwards compatibility.
-.IP "\s-1BIND_TIMELIMIT\s0 seconds" 4
+.IP "\fB\s-1BIND_TIMELIMIT\s0\fR seconds" 4
 .IX Item "BIND_TIMELIMIT seconds"
 The \fB\s-1BIND_TIMELIMIT\s0\fR parameter specifies the amount of time, in seconds,
 to wait while trying to connect to an \s-1LDAP\s0 server.  If multiple \fB\s-1URI\s0\fRs or
 \&\fB\s-1HOST\s0\fRs are specified, this is the amount of time to wait before trying
 the next one in the list.
-.IP "\s-1TIMELIMIT\s0 seconds" 4
+.IP "\fB\s-1TIMELIMIT\s0\fR seconds" 4
 .IX Item "TIMELIMIT seconds"
 The \fB\s-1TIMELIMIT\s0\fR parameter specifies the amount of time, in seconds,
 to wait for a response to an \s-1LDAP\s0 query.
-.IP "\s-1SUDOERS_BASE\s0 base" 4
+.IP "\fB\s-1SUDOERS_BASE\s0\fR base" 4
 .IX Item "SUDOERS_BASE base"
 The base \s-1DN\s0 to use when performing \fBsudo\fR \s-1LDAP\s0 queries.  Typically
 this is of the form \f(CW\*(C`ou=SUDOers,dc=example,dc=com\*(C'\fR for the domain
 \&\f(CW\*(C`example.com\*(C'\fR.
-.IP "\s-1SUDOERS_DEBUG\s0 debug_level" 4
+.IP "\fB\s-1SUDOERS_DEBUG\s0\fR debug_level" 4
 .IX Item "SUDOERS_DEBUG debug_level"
 This sets the debug level for \fBsudo\fR \s-1LDAP\s0 queries.  Debugging
 information is printed to the standard error.  A value of 1 results
@@ -423,35 +419,35 @@ in a moderate amount of debugging information.  A value of 2 shows
 the results of the matches themselves.  This parameter should not
 be set in a production environment as the extra information is
 likely to confuse users.
-.IP "\s-1BINDDN\s0 \s-1DN\s0" 4
+.IP "\fB\s-1BINDDN\s0\fR \s-1DN\s0" 4
 .IX Item "BINDDN DN"
 The \fB\s-1BINDDN\s0\fR parameter specifies the identity, in the form of a
 Distinguished Name (\s-1DN\s0), to use when performing \s-1LDAP\s0 operations.
 If not specified, \s-1LDAP\s0 operations are performed with an anonymous
 identity.  By default, most \s-1LDAP\s0 servers will allow anonymous access.
-.IP "\s-1BINDPW\s0 secret" 4
+.IP "\fB\s-1BINDPW\s0\fR secret" 4
 .IX Item "BINDPW secret"
 The \fB\s-1BINDPW\s0\fR parameter specifies the password to use when performing
 \&\s-1LDAP\s0 operations.  This is typically used in conjunction with the
 \&\fB\s-1BINDDN\s0\fR parameter.
-.IP "\s-1ROOTBINDDN\s0 \s-1DN\s0" 4
+.IP "\fB\s-1ROOTBINDDN\s0\fR \s-1DN\s0" 4
 .IX Item "ROOTBINDDN DN"
 The \fB\s-1ROOTBINDDN\s0\fR parameter specifies the identity, in the form of
 a Distinguished Name (\s-1DN\s0), to use when performing privileged \s-1LDAP\s0
 operations, such as \fIsudoers\fR queries.  The password corresponding
 to the identity should be stored in \fI@ldap_secret@\fR.
 If not specified, the \fB\s-1BINDDN\s0\fR identity is used (if any).
-.IP "\s-1LDAP_VERSION\s0 number" 4
+.IP "\fB\s-1LDAP_VERSION\s0\fR number" 4
 .IX Item "LDAP_VERSION number"
 The version of the \s-1LDAP\s0 protocol to use when connecting to the server.
 The default value is protocol version 3.
-.IP "\s-1SSL\s0 on/true/yes/off/false/no" 4
+.IP "\fB\s-1SSL\s0\fR on/true/yes/off/false/no" 4
 .IX Item "SSL on/true/yes/off/false/no"
 If the \fB\s-1SSL\s0\fR parameter is set to \f(CW\*(C`on\*(C'\fR, \f(CW\*(C`true\*(C'\fR or \f(CW\*(C`yes\*(C'\fR, \s-1TLS\s0
 (\s-1SSL\s0) encryption is always used when communicating with the \s-1LDAP\s0
 server.  Typically, this involves connecting to the server on port
 636 (ldaps).
-.IP "\s-1SSL\s0 start_tls" 4
+.IP "\fB\s-1SSL\s0\fR start_tls" 4
 .IX Item "SSL start_tls"
 If the \fB\s-1SSL\s0\fR parameter is set to \f(CW\*(C`start_tls\*(C'\fR, the \s-1LDAP\s0 server
 connection is initiated normally and \s-1TLS\s0 encryption is begun before
@@ -459,20 +455,20 @@ the bind credentials are sent.  This has the advantage of not
 requiring a dedicated port for encrypted communications.  This
 parameter is only supported by \s-1LDAP\s0 servers that honor the \f(CW\*(C`start_tls\*(C'\fR
 extension, such as the OpenLDAP server.
-.IP "\s-1TLS_CHECKPEER\s0 on/true/yes/off/false/no" 4
+.IP "\fB\s-1TLS_CHECKPEER\s0\fR on/true/yes/off/false/no" 4
 .IX Item "TLS_CHECKPEER on/true/yes/off/false/no"
 If enabled, \fB\s-1TLS_CHECKPEER\s0\fR will cause the \s-1LDAP\s0 server's \s-1TLS\s0
 certificated to be verified.  If the server's \s-1TLS\s0 certificate cannot
 be verified (usually because it is signed by an unknown certificate
 authority), \fBsudo\fR will be unable to connect to it.  If \fB\s-1TLS_CHECKPEER\s0\fR
 is disabled, no check is made.
-.IP "\s-1TLS_CACERTFILE\s0 file name" 4
+.IP "\fB\s-1TLS_CACERTFILE\s0\fR file name" 4
 .IX Item "TLS_CACERTFILE file name"
 The path to a certificate authority bundle which contains the certificates
 for all the Certificate Authorities the client knows to be valid,
 e.g. \fI/etc/ssl/ca\-bundle.pem\fR.
 This option is only supported by the OpenLDAP libraries.
-.IP "\s-1TLS_CACERTDIR\s0 directory" 4
+.IP "\fB\s-1TLS_CACERTDIR\s0\fR directory" 4
 .IX Item "TLS_CACERTDIR directory"
 Similar to \fB\s-1TLS_CACERTFILE\s0\fR but instead of a file, it is a
 directory containing individual Certificate Authority certificates,
@@ -480,69 +476,63 @@ e.g. \fI/etc/ssl/certs\fR.
 The directory specified by \fB\s-1TLS_CACERTDIR\s0\fR is checked after
 \&\fB\s-1TLS_CACERTFILE\s0\fR.
 This option is only supported by the OpenLDAP libraries.
-.IP "\s-1TLS_CERT\s0 file name" 4
+.IP "\fB\s-1TLS_CERT\s0\fR file name" 4
 .IX Item "TLS_CERT file name"
 The path to a file containing the client certificate which can
 be used to authenticate the client to the \s-1LDAP\s0 server.
-.RS 4
-.IP "OpenLDAP" 18
-.IX Item "OpenLDAP"
-\&\f(CW\*(C`tls_cert /etc/ssl/client_cert.pem\*(C'\fR
-.IP "Netscape-derived" 18
-.IX Item "Netscape-derived"
-\&\f(CW\*(C`tls_cert /var/ldap/cert7.db\*(C'\fR
-.RE
-.RS 4
+The certificate type depends on the \s-1LDAP\s0 libraries used.
+.Sp
+OpenLDAP:
+    \f(CW\*(C`tls_cert /etc/ssl/client_cert.pem\*(C'\fR
+.Sp
+Netscape\-derived:
+    \f(CW\*(C`tls_cert /var/ldap/cert7.db\*(C'\fR
 .Sp
 When using Netscape-derived libraries, this file may also contain
 Certificate Authority certificates.
-.RE
-.IP "\s-1TLS_KEY\s0 file name" 4
+.IP "\fB\s-1TLS_KEY\s0\fR file name" 4
 .IX Item "TLS_KEY file name"
 The path to a file containing the private key which matches the
 certificate specified by \fB\s-1TLS_CERT\s0\fR.  The private key must not be
-password\-protected.
-.RS 4
-.IP "OpenLDAP" 18
-.IX Item "OpenLDAP"
-\&\f(CW\*(C`tls_cert /etc/ssl/client_key.pem\*(C'\fR
-.IP "Netscape-derived" 18
-.IX Item "Netscape-derived"
-\&\f(CW\*(C`tls_cert /var/ldap/key3.db\*(C'\fR
-.RE
-.RS 4
-.RE
-.IP "\s-1TLS_RANDFILE\s0 file name" 4
+password\-protected.  The key type depends on the \s-1LDAP\s0 libraries
+used.
+.Sp
+OpenLDAP:
+    \f(CW\*(C`tls_cert /etc/ssl/client_key.pem\*(C'\fR
+.Sp
+Netscape\-derived:
+    \f(CW\*(C`tls_cert /var/ldap/key3.db\*(C'\fR
+.IP "\fB\s-1TLS_RANDFILE\s0\fR file name" 4
 .IX Item "TLS_RANDFILE file name"
 The \fB\s-1TLS_RANDFILE\s0\fR parameter specifies the path to an entropy
 source for systems that lack a random device.  It is generally used
 in conjunction with \fIprngd\fR or \fIegd\fR.
 This option is only supported by the OpenLDAP libraries.
-.IP "\s-1TLS_CIPHERS\s0 cipher list" 4
+.IP "\fB\s-1TLS_CIPHERS\s0\fR cipher list" 4
 .IX Item "TLS_CIPHERS cipher list"
 The \fB\s-1TLS_CIPHERS\s0\fR parameter allows the administer to restrict
 which encryption algorithms may be used for \s-1TLS\s0 (\s-1SSL\s0) connections.
 See the OpenSSL manual for a list of valid ciphers.
 This option is only supported by the OpenLDAP libraries.
-.IP "\s-1USE_SASL\s0 on/true/yes/off/false/no" 4
+.IP "\fB\s-1USE_SASL\s0\fR on/true/yes/off/false/no" 4
 .IX Item "USE_SASL on/true/yes/off/false/no"
 Enable \fB\s-1USE_SASL\s0\fR for \s-1LDAP\s0 servers that support \s-1SASL\s0 authentication.
-.IP "\s-1SASL_AUTH_ID\s0 identity" 4
+.IP "\fB\s-1SASL_AUTH_ID\s0\fR identity" 4
 .IX Item "SASL_AUTH_ID identity"
 The \s-1SASL\s0 user name to use when connecting to the \s-1LDAP\s0 server.
 By default, \fBsudo\fR will use an anonymous connection.
-.IP "\s-1ROOTUSE_SASL\s0 on/true/yes/off/false/no" 4
+.IP "\fB\s-1ROOTUSE_SASL\s0\fR on/true/yes/off/false/no" 4
 .IX Item "ROOTUSE_SASL on/true/yes/off/false/no"
 Enable \fB\s-1ROOTUSE_SASL\s0\fR to enable \s-1SASL\s0 authentication when connecting
 to an \s-1LDAP\s0 server from a privileged process, such as \fBsudo\fR.
-.IP "\s-1ROOTSASL_AUTH_ID\s0 identity" 4
+.IP "\fB\s-1ROOTSASL_AUTH_ID\s0\fR identity" 4
 .IX Item "ROOTSASL_AUTH_ID identity"
 The \s-1SASL\s0 user name to use when \fB\s-1ROOTUSE_SASL\s0\fR is enabled.
-.IP "\s-1SASL_SECPROPS\s0 none/properties" 4
+.IP "\fB\s-1SASL_SECPROPS\s0\fR none/properties" 4
 .IX Item "SASL_SECPROPS none/properties"
 \&\s-1SASL\s0 security properties or \fInone\fR for no properties.  See the
 \&\s-1SASL\s0 programmer's manual for details.
-.IP "\s-1KRB5_CCNAME\s0 file name" 4
+.IP "\fB\s-1KRB5_CCNAME\s0\fR file name" 4
 .IX Item "KRB5_CCNAME file name"
 The path to the Kerberos 5 credential cache to use when authenticating
 with the remote server.
@@ -559,7 +549,7 @@ match and later matches take precedence over earlier ones.
 The following sources are recognized:
 .PP
 .Vb 2
-\&    files       read sudoers from a file (usually F</etc/sudoers>)
+\&    files       read sudoers from F<@sysconfdir@/sudoers>
 \&    ldap        read sudoers from LDAP
 .Ve
 .PP
@@ -775,10 +765,12 @@ schema directory (e.g. \fI/etc/openldap/schema\fR), add the proper
 .IX Subsection "XXX more exhaustive sudoers ldif example?"
 .SH "SEE ALSO"
 .IX Header "SEE ALSO"
-\&\fIldap.conf\fR\|(4), \fIsudoers\fR\|(4)
+\&\fIldap.conf\fR\|(@mansectform@), \fIsudoers\fR\|(5)
 .SH "CAVEATS"
 .IX Header "CAVEATS"
-parsing differences between \s-1LDAP\s0 and file sudoers
+The way that \fIsudoers\fR is parsed differs between Note that there
+are differences in the way that LDAP-based \fIsudoers\fR is parsed
+compared to file-based \fIsudoers\fR.  See the \*(L"Differences between \s-1LDAP\s0 and non-LDAP sudoers\*(R" section for more information.
 .SH "BUGS"
 .IX Header "BUGS"
 If you feel you have found a bug in \fBsudo\fR, please submit a bug report
diff --git a/sudoers.ldap.pod b/sudoers.ldap.pod
index 000b860e0..64b969a4d 100644
--- a/sudoers.ldap.pod
+++ b/sudoers.ldap.pod
@@ -34,16 +34,10 @@ Using LDAP for I<sudoers> has several benefits:
 
 =item *
 
-B<sudo> no longer needs to read I<sudoers> in its entirety.  Parsing
-of F</etc/sudoers> requires the entire file to be read.  When LDAP
-is used, there are only two or three LDAP queries per invocation.
+B<sudo> no longer needs to read I<sudoers> in its entirety.  When
+LDAP is used, there are only two or three LDAP queries per invocation.
 This makes it especially fast and particularly usable in LDAP
-environments.  The first query is to parse global options (see
-below).  The second is to match against the user's name and the
-groups that the user belongs to.  (The special ALL tag is matched
-in this query too.)  If no match is returned for the user's name
-and groups, a third query returns all entries contain user netgroups
-and checks to see if the user belongs to any of them.
+environments.
 
 =item *
 
@@ -55,49 +49,37 @@ this will not prevent B<sudo> from running.
 
 =item *
 
-Options inside of entries now override global default options.
-F</etc/sudoers> only supports default options and limited options
-associated with user/host/commands and aliases.  The syntax is
-complicated and can be difficult for users to understand.
-
-Sudo first looks for an entry called C<cn=default> in the C<SUDOers>
-container.  If found, the multi-valued C<sudoOption> attribute is
-parsed the same way the global C<Defaults> line in F</etc/sudoers>
-is parsed.
-
-If, on the second or third query, a response contains a sudoRole
-which matches against the user, host, and command, then the matched
-object is scanned for a additional options that override the top-level
-defaults.  See the example LDAP content below for more information.
+It is possible to specify per-entry options that override the global
+default options.  F<@sysconfdir@/sudoers> only supports default options and
+limited options associated with user/host/commands/aliases.  The
+syntax is complicated and can be difficult for users to understand.
+Placing the options directly in the entry is more natural.
 
 =item *
 
 B<visudo> is no longer needed.  B<visudo> provides locking and
-syntax checking of the F</etc/sudoers> file.  Since LDAP updates
+syntax checking of the F<@sysconfdir@/sudoers> file.  Since LDAP updates
 are atomic, locking is no longer necessary.  Because syntax is
 checked when the data is inserted into LDAP, there is no need
 for a specialized tool to check syntax.
 
-=item *
-
-Aliases are no longer needed.  User, Host, and Cmnd Aliases were
-designed to simplify organization of I<sudoers> files and to
-improve readability.  Since an LDAP I<sudoers> entry allows multiple
-values for each of its attributes, and since most LDAP browsers are
-graphical and easy to work with, these aliases are no longer
-needed.
-
-If you wish to specify a large number of users into an entry or
-wish to have similar entries with identical users, then either use
-groups or user netgroups.  Alternately, they can all just be pasted
-into the LDAP record.
-
-If you need to specify a large number of hosts in an entry, use
-netgroups or IP address matches (10.2.3.4/255.255.0.0).  Alternately,
-they can all just be pasted into the LDAP record.
-
 =back
 
+Another major difference between LDAP and file-based I<sudoers>
+is that in LDAP, B<sudo>-specific Aliases are not supported.
+
+For the most part, there is really no need for B<sudo>-specific
+Aliases.  Unix groups or user netgroups can be used in place of
+User_Aliases and RunasAliases.  Host netgroups can be used in place
+of HostAliases.  Since Unix groups and netgroups can also be stored
+in LDAP there is no real need for B<sudo>-specific aliases.
+
+Cmnd_Aliases are not really required either since it is possible
+to have multiple users listed in a sudoRole.  Instead of defining
+a Cmnd_Alias that is referenced by multiple users, one can create
+a sudoRole that contains the commands and assign multiple users
+to it.
+
 =head2 SUDOers LDAP container
 
 The I<sudoers> configuration is contained in the C<ou=SUDOers> LDAP
@@ -105,7 +87,7 @@ container.
 
 Sudo first looks for the C<cn=default> entry in the SUDOers container.
 If found, the multi-valued C<sudoOption> attribute is parsed in the
-same manner as a global C<Defaults> line in F</etc/sudoers>.  In
+same manner as a global C<Defaults> line in F<@sysconfdir@/sudoers>.  In
 the following example, the C<SSH_AUTH_SOCK> variable will be preserved
 in the environment for all users.
 
@@ -121,29 +103,31 @@ the following components:
 
 =over 4
 
-=item sudoUser
+=item B<sudoUser>
 
 A user name, uid (prefixed with C<'#'>), Unix group (prefixed with
 a C<'%'>) or user netgroup (prefixed with a C<'+'>).
 
-=item sudoHost
+=item B<sudoHost>
 
 A host name, IP address, IP network, or host netgroup (prefixed
 with a C<'+'>).
 The special value C<ALL> will match any host.
 
-=item sudoCommand
+=item B<sudoCommand>
 
 A Unix command with optional command line arguments, potentially
 including globbing characters (aka wild cards).
 The special value C<ALL> will match any command.
+If a command is prefixed with an exclamation point C<'!'>, the
+user will be prohibited from running that command.
 
-=item sudoOption
+=item B<sudoOption>
 
-Similar to the global options described above, but specific to the
-C<sudoRole> in which it resides.
+Identical in function to the global options described above, but
+specific to the C<sudoRole> in which it resides.
 
-=item sudoRunAsUser
+=item B<sudoRunAsUser>
 
 A user name or uid (prefixed with C<'#'>) that commands may be run
 as or a Unix group (prefixed with a C<'%'>) or user netgroup (prefixed
@@ -151,16 +135,16 @@ with a C<'+'>) that contains a list of users that commands may be
 run as.
 The special value C<ALL> will match any user.
 
-=item sudoRunAsGroup
+=item B<sudoRunAsGroup>
 
 A Unix group or gid (prefixed with C<'#'>) that commands may be run as.
 The special value C<ALL> will match any group.
 
 =back
 
-Each entry listed above contains a single value, but may be repeated
-multiple times.  A sudoRole must contain at least one C<sudoUser>,
-C<sudoHost> and C<sudoCommand>.
+Each component listed above should contain a single value, but there
+may be multiple instances of each component type.  A sudoRole must
+contain at least one C<sudoUser>, C<sudoHost> and C<sudoCommand>.
 
 The following example allows users in group wheel to run any command
 on any host via B<sudo>:
@@ -173,14 +157,25 @@ on any host via B<sudo>:
     sudoHost: ALL
     sudoCommand: ALL
 
+=head2 Anatomy of LDAP sudoers lookup
+
+When looking up a sudoer using LDAP there are only two or three
+LDAP queries per invocation.  The first query is to parse the global
+options.  The second is to match against the user's name and the
+groups that the user belongs to.  (The special ALL tag is matched
+in this query too.)  If no match is returned for the user's name
+and groups, a third query returns all entries containing user
+netgroups and checks to see if the user belongs to any of them.
+
 =head2 Differences between LDAP and non-LDAP sudoers
 
 There are some subtle differences in the way sudoers is handled
 once in LDAP.  Probably the biggest is that according to the RFC,
-LDAP's ordering is arbitrary and you cannot expect that Attributes
-and Entries are returned in any order.  If there are conflicting
-command rules on an entry, the negative takes precedence.  This is
-called paranoid behavior (not necessarily the most specific match).
+LDAP ordering is arbitrary and you cannot expect that Attributes
+and Entries are returned in any specific order.  If there are
+conflicting command rules on an entry, the negative takes precedence.
+This is called paranoid behavior (not necessarily the most specific
+match).
 
 Here is an example:
 
@@ -190,7 +185,7 @@ Here is an example:
     # Always allows all commands because ALL is matched last
     puddles ALL=(root) !/bin/sh,ALL
 
-    # LDAP equivalent of Johnny
+    # LDAP equivalent of johnny
     # Allows all commands except shell
     dn: cn=role1,ou=Sudoers,dc=my-domain,dc=com
     objectClass: sudoRole
@@ -201,7 +196,7 @@ Here is an example:
     sudoCommand: ALL
     sudoCommand: !/bin/sh
 
-    # LDAP equivalent of Puddles
+    # LDAP equivalent of puddles
     # Notice that even though ALL comes last, it still behaves like
     # role1 since the LDAP code assumes the more paranoid configuration
     dn: cn=role2,ou=Sudoers,dc=my-domain,dc=com
@@ -215,7 +210,7 @@ Here is an example:
 
 Another difference is that negations on the Host, User or Runas are
 currently ignorred.  For example, the following attributes do not
-do what they might appear to do.
+behave the way one might expect.
 
     # does not match all but joe
     # rather, does not match anyone
@@ -262,7 +257,7 @@ below in upper case but are parsed in a case-independent manner.
 
 =over 4
 
-=item URI ldap[s]://[hostname[:port]] ...
+=item B<URI> ldap[s]://[hostname[:port]] ...
 
 Specifies a whitespace-delimited list of one or more URIs describing
 the LDAP server(s) to connect to.  The I<protocol> may be either B<ldap>
@@ -274,7 +269,7 @@ libraries support the mixing of C<ldap://> and C<ldaps://> URIs.
 The Netscape-derived libraries used on most commercial versions of
 Unix are only capable of supporting one or the other.
 
-=item HOST name[:port] ...
+=item B<HOST> name[:port] ...
 
 If no B<URI> is specified, the B<HOST> parameter specifies a
 whitespace-delimited list of LDAP servers to connect to.  Each host
@@ -282,7 +277,7 @@ may include an optional I<port> separated by a colon (':').  The
 B<HOST> parameter is deprecated in favor of the B<URI> specification
 and is included for backwards compatibility.
 
-=item PORT port_number
+=item B<PORT> port_number
 
 If no B<URI> is specified, the B<PORT> parameter specifies the
 default port to connect to on the LDAP server if a B<HOST> parameter
@@ -291,25 +286,25 @@ the default is port 389 for LDAP and port 636 for LDAP over TLS
 (SSL).  The B<PORT> parameter is deprecated in favor of the B<URI>
 specification and is included for backwards compatibility.
 
-=item BIND_TIMELIMIT seconds
+=item B<BIND_TIMELIMIT> seconds
 
 The B<BIND_TIMELIMIT> parameter specifies the amount of time, in seconds,
 to wait while trying to connect to an LDAP server.  If multiple B<URI>s or
 B<HOST>s are specified, this is the amount of time to wait before trying
 the next one in the list.
 
-=item TIMELIMIT seconds
+=item B<TIMELIMIT> seconds
 
 The B<TIMELIMIT> parameter specifies the amount of time, in seconds,
 to wait for a response to an LDAP query.
 
-=item SUDOERS_BASE base
+=item B<SUDOERS_BASE> base
 
 The base DN to use when performing B<sudo> LDAP queries.  Typically
 this is of the form C<ou=SUDOers,dc=example,dc=com> for the domain
 C<example.com>.
 
-=item SUDOERS_DEBUG debug_level
+=item B<SUDOERS_DEBUG> debug_level
 
 This sets the debug level for B<sudo> LDAP queries.  Debugging
 information is printed to the standard error.  A value of 1 results
@@ -318,20 +313,20 @@ the results of the matches themselves.  This parameter should not
 be set in a production environment as the extra information is
 likely to confuse users.
 
-=item BINDDN DN
+=item B<BINDDN> DN
 
 The B<BINDDN> parameter specifies the identity, in the form of a
 Distinguished Name (DN), to use when performing LDAP operations.
 If not specified, LDAP operations are performed with an anonymous
 identity.  By default, most LDAP servers will allow anonymous access.
 
-=item BINDPW secret
+=item B<BINDPW> secret
 
 The B<BINDPW> parameter specifies the password to use when performing
 LDAP operations.  This is typically used in conjunction with the
 B<BINDDN> parameter.
 
-=item ROOTBINDDN DN
+=item B<ROOTBINDDN> DN
 
 The B<ROOTBINDDN> parameter specifies the identity, in the form of
 a Distinguished Name (DN), to use when performing privileged LDAP
@@ -339,19 +334,19 @@ operations, such as I<sudoers> queries.  The password corresponding
 to the identity should be stored in F<@ldap_secret@>.
 If not specified, the B<BINDDN> identity is used (if any).
 
-=item LDAP_VERSION number
+=item B<LDAP_VERSION> number
 
 The version of the LDAP protocol to use when connecting to the server.
 The default value is protocol version 3.
 
-=item SSL on/true/yes/off/false/no
+=item B<SSL> on/true/yes/off/false/no
 
 If the B<SSL> parameter is set to C<on>, C<true> or C<yes>, TLS
 (SSL) encryption is always used when communicating with the LDAP
 server.  Typically, this involves connecting to the server on port
 636 (ldaps).
 
-=item SSL start_tls
+=item B<SSL> start_tls
 
 If the B<SSL> parameter is set to C<start_tls>, the LDAP server
 connection is initiated normally and TLS encryption is begun before
@@ -360,7 +355,7 @@ requiring a dedicated port for encrypted communications.  This
 parameter is only supported by LDAP servers that honor the C<start_tls>
 extension, such as the OpenLDAP server.
 
-=item TLS_CHECKPEER on/true/yes/off/false/no
+=item B<TLS_CHECKPEER> on/true/yes/off/false/no
 
 If enabled, B<TLS_CHECKPEER> will cause the LDAP server's TLS
 certificated to be verified.  If the server's TLS certificate cannot
@@ -368,14 +363,14 @@ be verified (usually because it is signed by an unknown certificate
 authority), B<sudo> will be unable to connect to it.  If B<TLS_CHECKPEER>
 is disabled, no check is made.
 
-=item TLS_CACERTFILE file name
+=item B<TLS_CACERTFILE> file name
 
 The path to a certificate authority bundle which contains the certificates
 for all the Certificate Authorities the client knows to be valid,
 e.g. F</etc/ssl/ca-bundle.pem>.
 This option is only supported by the OpenLDAP libraries.
 
-=item TLS_CACERTDIR directory
+=item B<TLS_CACERTDIR> directory
 
 Similar to B<TLS_CACERTFILE> but instead of a file, it is a
 directory containing individual Certificate Authority certificates,
@@ -384,82 +379,72 @@ The directory specified by B<TLS_CACERTDIR> is checked after
 B<TLS_CACERTFILE>.
 This option is only supported by the OpenLDAP libraries.
 
-=item TLS_CERT file name
+=item B<TLS_CERT> file name
 
 The path to a file containing the client certificate which can
 be used to authenticate the client to the LDAP server.
+The certificate type depends on the LDAP libraries used.
 
-=over 18
+OpenLDAP:
+    C<tls_cert /etc/ssl/client_cert.pem>
 
-=item OpenLDAP
-
-C<tls_cert /etc/ssl/client_cert.pem>
-
-=item Netscape-derived
-
-C<tls_cert /var/ldap/cert7.db>
-
-=back
+Netscape-derived:
+    C<tls_cert /var/ldap/cert7.db>
 
 When using Netscape-derived libraries, this file may also contain
 Certificate Authority certificates.
 
-=item TLS_KEY file name
+=item B<TLS_KEY> file name
 
 The path to a file containing the private key which matches the
 certificate specified by B<TLS_CERT>.  The private key must not be
-password-protected.
+password-protected.  The key type depends on the LDAP libraries
+used.
 
-=over 18
+OpenLDAP:
+    C<tls_cert /etc/ssl/client_key.pem>
 
-=item OpenLDAP
+Netscape-derived:
+    C<tls_cert /var/ldap/key3.db>
 
-C<tls_cert /etc/ssl/client_key.pem>
-
-=item Netscape-derived
-
-C<tls_cert /var/ldap/key3.db>
-
-=back
-
-=item TLS_RANDFILE file name
+=item B<TLS_RANDFILE> file name
 
 The B<TLS_RANDFILE> parameter specifies the path to an entropy
 source for systems that lack a random device.  It is generally used
 in conjunction with I<prngd> or I<egd>.
 This option is only supported by the OpenLDAP libraries.
 
-=item TLS_CIPHERS cipher list
+=item B<TLS_CIPHERS> cipher list
 
 The B<TLS_CIPHERS> parameter allows the administer to restrict
 which encryption algorithms may be used for TLS (SSL) connections.
 See the OpenSSL manual for a list of valid ciphers.
 This option is only supported by the OpenLDAP libraries.
 
-=item USE_SASL on/true/yes/off/false/no
+=item B<USE_SASL> on/true/yes/off/false/no
 
 Enable B<USE_SASL> for LDAP servers that support SASL authentication.
 
-=item SASL_AUTH_ID identity
+=item B<SASL_AUTH_ID> identity
 
 The SASL user name to use when connecting to the LDAP server.
 By default, B<sudo> will use an anonymous connection.
 
-=item ROOTUSE_SASL on/true/yes/off/false/no
+=item B<ROOTUSE_SASL> on/true/yes/off/false/no
 
 Enable B<ROOTUSE_SASL> to enable SASL authentication when connecting
 to an LDAP server from a privileged process, such as B<sudo>.
 
-=item ROOTSASL_AUTH_ID identity
+=item B<ROOTSASL_AUTH_ID> identity
 
 The SASL user name to use when B<ROOTUSE_SASL> is enabled.
 
-=item SASL_SECPROPS none/properties
+=item B<SASL_SECPROPS> none/properties
 
 SASL security properties or I<none> for no properties.  See the
 SASL programmer's manual for details.
 
-=item KRB5_CCNAME file name
+=item B<KRB5_CCNAME> file name
 
 The path to the Kerberos 5 credential cache to use when authenticating
 with the remote server.
@@ -478,7 +463,7 @@ match and later matches take precedence over earlier ones.
 
 The following sources are recognized:
 
-    files	read sudoers from a file (usually F</etc/sudoers>)
+    files	read sudoers from F<@sysconfdir@/sudoers>
     ldap	read sudoers from LDAP
 
 In addition, the entry C<[NOTFOUND=return]> will short-circuit the
@@ -678,11 +663,14 @@ C<include> line in C<slapd.conf> and restart B<slapd>.
 
 =head1 SEE ALSO
 
-L<ldap.conf(4)>, L<sudoers(4)>
+L<ldap.conf(5)>, L<sudoers(5)>
 
 =head1 CAVEATS
 
-parsing differences between LDAP and file sudoers
+The way that I<sudoers> is parsed differs between Note that there
+are differences in the way that LDAP-based I<sudoers> is parsed
+compared to file-based I<sudoers>.  See the L<Differences between
+LDAP and non-LDAP sudoers> section for more information.
 
 =head1 BUGS
 
