diff options
| author | bubulle <bubulle@alioth.debian.org> | 2010-01-15 21:59:36 +0000 |
|---|---|---|
| committer | bubulle <bubulle@alioth.debian.org> | 2010-01-15 21:59:36 +0000 |
| commit | 4689cc0418955c954941e513b6e65747b10695af (patch) | |
| tree | 0e30a8cc95d344c11f201ac8a938e8e263358be0 | |
| parent | dfd163a320555d5e2674a49005327c516074472f (diff) | |
| download | samba-4689cc0418955c954941e513b6e65747b10695af.tar.gz | |
Merge upstream 3.5.0~rc1~dfsg
git-svn-id: svn://svn.debian.org/svn/pkg-samba/branches/samba/experimental@3228 fc4039ab-9d04-0410-8cac-899223bdd6b0
175 files changed, 5262 insertions, 44870 deletions
diff --git a/WHATSNEW.txt b/WHATSNEW.txt index d165113710..26205e5f24 100644 --- a/WHATSNEW.txt +++ b/WHATSNEW.txt @@ -1,9 +1,9 @@ - ================================= - Release Notes for Samba 3.5.0pre2 - December 15, 2009 - ================================= + ================================ + Release Notes for Samba 3.5.0rc1 + January 7, 2010 + ================================ -This is the second preview release of Samba 3.5. This is *not* +This is the first release candidate of Samba 3.5. This is *not* intended for production environments and is designed for testing purposes only. Please report any defects via the Samba bug reporting system at https://bugzilla.samba.org/. @@ -73,7 +73,7 @@ smb.conf changes New configure options --------------------- ---enable-external-libtalloc Enable external tdb +--enable-external-libtdb Enable external tdb --enable-netapi Turn on netapi support --enable-pthreadpool Enable pthreads pool helper support --with-cifsumount Include umount.cifs (Linux only) support @@ -97,6 +97,103 @@ o Stefan Metzmacher <metze@samba.org> * Implement the new SMB2 protocol (experimental). +Changes since 3.5.0pre2 +----------------------- + +o Jeremy Allison <jra@samba.org> + * BUG 6837: Fix "Too many open files" when trying to access large number of + files with Windows 7. + * BUG 6939: Fix long filenames when "mangling method" is set to "hash". + * BUG 7020: Fix smbd using 2G memory. + * Ensure dos_mode can return FILE_ATTRIBUTE_NORMAL, then filter the returned + attributes by protocol level. + * Vector correctly through reply_openerror() (which uses the same logic). + * Fix bugs with the full Windows ACL support. + + +o Kai Blin <kai@samba.org> + * Add a few missing gettext calls to the 'net' command. + * Fix up a share type translation and translate some more strings in 'net'. + + +o Günther Deschner <gd@samba.org> + * Allow to call "pdbedit -N description -u user" without specifiyng "-r". + * Add spoolss_DriverInfo7. + * Fix rpcclient after setprinter IDL fixes. + * Use generated krb5.conf in 'net ads testjoin'. + + +o Jonas Gorski <jonas.gorski+samba@gmail.com> + * BUG 6992: make test for getgrouplist cacheable. + + +o André Hentschel <nerv@dawncrow.de> + * Add some German translations for the 'net' command. + + +o Suresh Jayaraman <sjayaraman@suse.de> + * Update mount.cifs man page with nounix option. + + +o Volker Lendecke <vl@samba.org> + * Fix _samr_GetAliasMembership for results with 0 rids. + * Fix an error case in cli_negprot. + * Add a lower-cost alternative to wbinfo -t: wbinfo --ping-dc. + * Restore correct timeouts for SMB requests. + * Fix a 64-bit error in libsmb. + * Replace IS_DOMAIN_OFFLINE by a function in Winbind. + * Simplify/cleanup Winbind code. + + +o Kamen Mazdrashki <kamen.mazdrashki@postpath.com> + * Fix write behind memory block in libtalloc. + * Fix result check for getaddrinfo(). + + +o Jim McDonough <jmcd@samba.org> + * BUG 7014: Fix Winbind crash when retrieving empty group members. + + +o Brian Lu <brian.lu@sun.com> + * BUG 6991: Create symbol links to shared libraries. + + +o Stefan Metzmacher <metze@samba.org> + * Add tsocket_address_bsd_sockaddr() and tsocket_address_bsd_from_sockaddr() + to tsocket. + * Always set tdb->tracefd to -1 to be safe on goto fail in libtdb. + * Add TDB_DISALLOW_NESTING and make TDB_ALLOW_NESTING the default behavior. + * Fix standalone 'make installdocs'. + + +o Peter Rosin <peda@lysator.liu.se> + * Output %p as unsigned in snprintf replacement. + + +o Ronnie Sahlberg <ronniesahlberg@gmail.com> + * New attempt at TDB transaction nesting allow/disallow. + + +o Kirill Smelkov <kirr@mns.spb.ru> + * Remove swig stuff from libtdb. + * Reset tdb->fd to -1 in tdb_close() in libtdb. + + +o Simo Sorce <idra@samba.org> + * Change the way mksysms work in libtalloc. + + +o Jelmer Vernooij <jelmer@samba.org> + * Also build and install tdb manpages from standalone tdb. + + +o Bo Yang <boyang@samba.org> + * Fix infinite loop in NCACN_IP_TCP as there is no timeout. + * Make winbindd_cache.c aware of domain offline to avoid unnecessary backend + query. + * List trusted domains from wcache when domain is offline. + + Changes since 3.5.0pre1 ----------------------- diff --git a/docs-xml/build/DTD/samba.entities b/docs-xml/build/DTD/samba.entities index 2e924d46ba..4ad65ca7c5 100644 --- a/docs-xml/build/DTD/samba.entities +++ b/docs-xml/build/DTD/samba.entities @@ -50,8 +50,8 @@ <!ENTITY person.gd ' <firstname>Guenther</firstname><surname>Deschner</surname> <affiliation> - <orgname>SuSE</orgname> - <address><email>gd@suse.de</email></address> + <orgname>Samba Team</orgname> + <address><email>gd@samba.org</email></address> </affiliation>'> <!ENTITY author.gd '<author>&person.gd;</author>'> @@ -214,7 +214,7 @@ in the &smb.conf; file.</para> <!ENTITY stdarg.configfile ' <varlistentry> -<term>-s <configuration file></term> +<term>-s|--configfile <configuration file></term> <listitem><para>The file specified contains the configuration details required by the server. The information in this file includes server-specific @@ -227,7 +227,7 @@ compile time.</para></listitem> <!ENTITY stdarg.version ' <varlistentry> -<term>-V</term> +<term>-V|--version</term> <listitem><para>Prints the program version number. </para></listitem> </varlistentry>'> @@ -249,7 +249,7 @@ log.smbd, etc...). The log file is never removed by the client. <!ENTITY stdarg.resolve.order ' <varlistentry> -<term>-R <name resolve order></term> +<term>-R|--name-resolve <name resolve order></term> <listitem><para>This option is used to determine what naming services and in what order to resolve host names to IP addresses. The option takes a space-separated @@ -307,7 +307,7 @@ resolution methods will be attempted in this order. </para></listitem> <!ENTITY stdarg.netbios.name ' <varlistentry> -<term>-n <primary NetBIOS name></term> +<term>-n|--netbiosname <primary NetBIOS name></term> <listitem><para>This option allows you to override the NetBIOS name that Samba uses for itself. This is identical to setting the <smbconfoption><name>netbios name</name></smbconfoption> parameter in the &smb.conf; file. @@ -318,7 +318,7 @@ line setting will take precedence over settings in <!ENTITY stdarg.scope ' <varlistentry> -<term>-i <scope></term> +<term>-i|--scope <scope></term> <listitem><para>This specifies a NetBIOS scope that <command>nmblookup</command> will use to communicate with when generating NetBIOS names. For details on the use of NetBIOS @@ -340,7 +340,7 @@ SAM (as opposed to the Domain SAM). </para></listitem> <!ENTITY stdarg.socket.options ' <varlistentry> -<term>-O socket options</term> +<term>-O|--socket-options socket options</term> <listitem><para>TCP socket options to set on the client socket. See the socket options parameter in the &smb.conf; manual page for the list of valid @@ -357,7 +357,7 @@ options. </para></listitem> <!ENTITY stdarg.nopass ' <varlistentry> -<term>-N</term> +<term>-N|--no-pass</term> <listitem><para>If specified, this parameter suppresses the normal password prompt from the client to the user. This is useful when accessing a service that does not require a password. </para> @@ -420,7 +420,7 @@ access from unwanted users. </para></listitem> <!ENTITY stdarg.kerberos ' <varlistentry> -<term>-k</term> +<term>-k|--kerberos</term> <listitem><para> Try to authenticate with kerberos. Only useful in an Active Directory environment. diff --git a/docs-xml/manpages-3/mount.cifs.8.xml b/docs-xml/manpages-3/mount.cifs.8.xml index 0beb96882a..c4fe2e8933 100644 --- a/docs-xml/manpages-3/mount.cifs.8.xml +++ b/docs-xml/manpages-3/mount.cifs.8.xml @@ -477,12 +477,35 @@ permissions in memory that can't be stored on the server. This information can d <varlistentry> <term>noserverino</term> - <listitem><para>client generates inode numbers (rather than using the actual one - from the server) by default. + <listitem> + <para> + Client generates inode numbers (rather than + using the actual one from the server) by default. + </para> + <para> + See section <emphasis>INODE NUMBERS</emphasis> for + more information. </para></listitem> </varlistentry> <varlistentry> + <term>nounix</term> + <listitem> + <para> + Disable the CIFS Unix Extensions for this mount. This + can be useful in order to turn off multiple settings at once. + This includes POSIX acls, POSIX locks, POSIX paths, symlink + support and retrieving uids/gids/mode from the server. This + can also be useful to work around a bug in a server that + supports Unix Extensions. + </para> + <para> + See section <emphasis>INODE NUMBERS</emphasis> for + more information. + </para> </listitem> + </varlistentry> + + <varlistentry> <term>nouser_xattr</term> <listitem><para>(default) Do not allow getfattr/setfattr to get/set xattrs, even if server would support it otherwise. </para></listitem> </varlistentry> @@ -533,6 +556,33 @@ permissions in memory that can't be stored on the server. This information can d </refsect1> <refsect1> + <title>INODE NUMBERS</title> + <para> + When Unix Extensions are enabled, we use the actual inode + number provided by the server in response to the POSIX calls as an + inode number. + </para> + <para> + When Unix Extensions are disabled and "serverino" mount option + is enabled there is no way to get the server inode number. The + client typically maps the server-assigned "UniqueID" onto an inode + number. + </para> + <para> + Note that the UniqueID is a different value from the server + inode number. The UniqueID value is unique over the scope of the entire + server and is often greater than 2 power 32. This value often makes + programs that are not compiled with LFS (Large File Support), to + trigger a glibc EOVERFLOW error as this won't fit in the target + structure field. It is strongly recommended to compile your programs + with LFS support (i.e. with -D_FILE_OFFSET_BITS=64) to prevent this + problem. You can also use "noserverino" mount option to generate inode + numbers smaller than 2 power 32 on the client. But you may not be able + to detect hardlinks properly. + </para> +</refsect1> + +<refsect1> <title>FILE AND DIRECTORY OWNERSHIP AND PERMISSIONS</title> <para> The core CIFS protocol does not provide unix ownership diff --git a/docs-xml/manpages-3/pam_winbind.8.xml b/docs-xml/manpages-3/pam_winbind.8.xml index ae29c40c57..47cf998b13 100644 --- a/docs-xml/manpages-3/pam_winbind.8.xml +++ b/docs-xml/manpages-3/pam_winbind.8.xml @@ -62,7 +62,9 @@ file situated at <filename>/etc/security/pam_winbind.conf</filename>. Options from the PAM configuration file take precedence to those from - the configuration file. + the configuration file. See + <citerefentry><refentrytitle>pam_winbind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for further details. <variablelist> @@ -231,6 +233,8 @@ <refsect1> <title>SEE ALSO</title> <para><citerefentry> + <refentrytitle>pam_winbind.conf</refentrytitle> + <manvolnum>5</manvolnum></citerefentry>, <citerefentry> <refentrytitle>wbinfo</refentrytitle> <manvolnum>1</manvolnum></citerefentry>, <citerefentry> <refentrytitle>winbindd</refentrytitle> diff --git a/docs-xml/manpages-3/pam_winbind.conf.5.xml b/docs-xml/manpages-3/pam_winbind.conf.5.xml new file mode 100644 index 0000000000..113515ce84 --- /dev/null +++ b/docs-xml/manpages-3/pam_winbind.conf.5.xml @@ -0,0 +1,190 @@ +<?xml version="1.0" encoding="iso-8859-1"?> +<!DOCTYPE refentry PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc"> +<refentry id="pam_winbind.conf.5"> + +<refmeta> + <refentrytitle>pam_winbind.conf</refentrytitle> + <manvolnum>5</manvolnum> + <refmiscinfo class="source">Samba</refmiscinfo> + <refmiscinfo class="manual">5</refmiscinfo> + <refmiscinfo class="version">3.6</refmiscinfo> +</refmeta> + + +<refnamediv> + <refname>pam_winbind.conf</refname> + <refpurpose>Configuration file of PAM module for Winbind</refpurpose> +</refnamediv> + +<refsect1> + <title>DESCRIPTION</title> + + <para>This configuration file is part of the <citerefentry><refentrytitle>samba</refentrytitle> + <manvolnum>7</manvolnum></citerefentry> suite.</para> + + <para> + pam_winbind.conf is the configuration file for the pam_winbind PAM + module. See + <citerefentry><refentrytitle>pam_winbind</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for further details. + </para> +</refsect1> + +<refsect1> + <title>SYNOPSIS</title> + + <para> + The pam_winbind.conf configuration file is a classic ini-style + configuration file. There is only one section (global) where + various options are defined. + </para> +</refsect1> + +<refsect1> + <title>OPTIONS</title> + <para> + + pam_winbind supports several options which can either be set in + the PAM configuration files or in the pam_winbind configuration + file situated at + <filename>/etc/security/pam_winbind.conf</filename>. Options + from the PAM configuration file take precedence to those from + the pam_winbind.conf configuration file. + + <variablelist> + + <varlistentry> + <term>debug = yes|no</term> + <listitem><para>Gives debugging output to syslog. Defaults to "no".</para></listitem> + </varlistentry> + + <varlistentry> + <term>debug_state = yes|no</term> + <listitem><para>Gives detailed PAM state debugging output to syslog. Defaults to "no".</para></listitem> + </varlistentry> + + <varlistentry> + <term>require_membership_of = [SID or NAME]</term> + <listitem><para> + If this option is set, pam_winbind will only succeed if the user is a member of the given SID or NAME. A SID + can be either a group-SID, an alias-SID or even an user-SID. It is also possible to give a NAME instead of the + SID. That name must have the form: <parameter>MYDOMAIN\\mygroup</parameter> or + <parameter>MYDOMAIN\\myuser</parameter>. pam_winbind will, in that case, lookup the SID internally. Note that + NAME may not contain any spaces. It is thus recommended to only use SIDs. You can verify the list of SIDs a + user is a member of with <command>wbinfo --user-sids=SID</command>. This setting is empty by default. + </para></listitem> + </varlistentry> + + <varlistentry> + <term>try_first_pass = yes|no</term> + <listitem><para> + By default, pam_winbind tries to get the authentication token from a previous module. If no token is available + it asks the user for the old password. With this option, pam_winbind aborts with an error if no authentication + token from a previous module is available. If a primary password is not valid, PAM will prompt for a password. + Default to "no". + </para></listitem> + </varlistentry> + + <varlistentry> + <term>krb5_auth = yes|no</term> + <listitem><para> + + pam_winbind can authenticate using Kerberos when winbindd is + talking to an Active Directory domain controller. Kerberos + authentication must be enabled with this parameter. When + Kerberos authentication can not succeed (e.g. due to clock + skew), winbindd will fallback to samlogon authentication over + MSRPC. When this parameter is used in conjunction with + <parameter>winbind refresh tickets</parameter>, winbind will + keep your Ticket Granting Ticket (TGT) uptodate by refreshing + it whenever necessary. Defaults to "no". + + </para></listitem> + </varlistentry> + + <varlistentry> + <term>krb5_ccache_type = [type]</term> + <listitem><para> + + When pam_winbind is configured to try kerberos authentication + by enabling the <parameter>krb5_auth</parameter> option, it can + store the retrieved Ticket Granting Ticket (TGT) in a + credential cache. The type of credential cache can be set with + this option. Currently the only supported value is: + <parameter>FILE</parameter>. In that case a credential cache in + the form of /tmp/krb5cc_UID will be created, where UID is + replaced with the numeric user id. Leave empty to just do + kerberos authentication without having a ticket cache after the + logon has succeeded. This setting is empty by default. + + </para></listitem> + </varlistentry> + + <varlistentry> + <term>cached_login = yes|no</term> + <listitem><para> + Winbind allows to logon using cached credentials when <parameter>winbind offline logon</parameter> is enabled. To use this feature from the PAM module this option must be set. Defaults to "no". + </para></listitem> + </varlistentry> + + <varlistentry> + <term>silent = yes|no</term> + <listitem><para> + Do not emit any messages. Defaults to "no". + </para></listitem> + </varlistentry> + + <varlistentry> + <term>mkhomedir = yes|no</term> + <listitem><para> + Create homedirectory for a user on-the-fly, option is valid in + PAM session block. Defaults to "no". + </para></listitem> + </varlistentry> + + <varlistentry> + <term>warn_pwd_expire = days</term> + <listitem><para> + Defines number of days before pam_winbind starts to warn about passwords that are + going to expire. Defaults to 14 days. + </para></listitem> + </varlistentry> + + </variablelist> + + </para> + +</refsect1> + +<refsect1> + <title>SEE ALSO</title> + <para><citerefentry> + <refentrytitle>pam_winbind</refentrytitle> + <manvolnum>8</manvolnum></citerefentry>, <citerefentry> + <refentrytitle>wbinfo</refentrytitle> + <manvolnum>1</manvolnum></citerefentry>, <citerefentry> + <refentrytitle>winbindd</refentrytitle> + <manvolnum>8</manvolnum></citerefentry>, <citerefentry> + <refentrytitle>smb.conf</refentrytitle> + <manvolnum>5</manvolnum></citerefentry></para> +</refsect1> + +<refsect1> + <title>VERSION</title> + + <para>This man page is correct for version 3 of Samba.</para> +</refsect1> + +<refsect1> + <title>AUTHOR</title> + + <para> + The original Samba software and related utilities were created by Andrew Tridgell. Samba is now developed by + the Samba Team as an Open Source project similar to the way the Linux kernel is developed. + </para> + + <para>This manpage was written by Jelmer Vernooij and Guenther Deschner.</para> + +</refsect1> + +</refentry> diff --git a/docs-xml/manpages-3/pdbedit.8.xml b/docs-xml/manpages-3/pdbedit.8.xml index 15be78a1ad..eaafb9713c 100644 --- a/docs-xml/manpages-3/pdbedit.8.xml +++ b/docs-xml/manpages-3/pdbedit.8.xml @@ -19,30 +19,40 @@ <refsynopsisdiv> <cmdsynopsis> <command>pdbedit</command> - <arg choice="opt">-L</arg> - <arg choice="opt">-v</arg> - <arg choice="opt">-w</arg> - <arg choice="opt">-u username</arg> - <arg choice="opt">-f fullname</arg> - <arg choice="opt">-h homedir</arg> - <arg choice="opt">-D drive</arg> - <arg choice="opt">-S script</arg> - <arg choice="opt">-p profile</arg> - <arg choice="opt">-a</arg> - <arg choice="opt">-t, --password-from-stdin</arg> - <arg choice="opt">-m</arg> - <arg choice="opt">-r</arg> - <arg choice="opt">-x</arg> - <arg choice="opt">-i passdb-backend</arg> - <arg choice="opt">-e passdb-backend</arg> + <arg choice="opt">-a</arg> <arg choice="opt">-b passdb-backend</arg> - <arg choice="opt">-g</arg> + <arg choice="opt">-c account-control</arg> + <arg choice="opt">-C value</arg> <arg choice="opt">-d debuglevel</arg> - <arg choice="opt">-s configfile</arg> + <arg choice="opt">-D drive</arg> + <arg choice="opt">-e passdb-backend</arg> + <arg choice="opt">-f fullname</arg> + <arg choice="opt">--force-initialized-passwords</arg> + <arg choice="opt">-g</arg> + <arg choice="opt">-h homedir</arg> + <arg choice="opt">-i passdb-backend</arg> + <arg choice="opt">-I domain</arg> + <arg choice="opt">-L </arg> + <arg choice="opt">-m</arg> + <arg choice="opt">-M SID|RID</arg> + <arg choice="opt">-N description</arg> <arg choice="opt">-P account-policy</arg> - <arg choice="opt">-C value</arg> - <arg choice="opt">-c account-control</arg> + <arg choice="opt">-p profile</arg> + <arg choice="opt">--policies-reset</arg> + <arg choice="opt">-r</arg> + <arg choice="opt">-s configfile</arg> + <arg choice="opt">-S script</arg> + <arg choice="opt">-t</arg> + <arg choice="opt">--time-format</arg> + <arg choice="opt">-u username</arg> + <arg choice="opt">-U SID|RID</arg> + <arg choice="opt">-v</arg> + <arg choice="opt">-V</arg> + <arg choice="opt">-w</arg> + <arg choice="opt">-x</arg> <arg choice="opt">-y</arg> + <arg choice="opt">-z</arg> + <arg choice="opt">-Z</arg> </cmdsynopsis> </refsynopsisdiv> @@ -69,7 +79,7 @@ <title>OPTIONS</title> <variablelist> <varlistentry> - <term>-L</term> + <term>-L|--list</term> <listitem><para>This option lists all the user accounts present in the users database. This option prints a list of user/uid pairs separated by @@ -85,7 +95,7 @@ samba:45:Test User <varlistentry> - <term>-v</term> + <term>-v|--verbose</term> <listitem><para>This option enables the verbose listing format. It causes pdbedit to list the users in the database, printing out the account fields in a descriptive format.</para> @@ -117,7 +127,7 @@ Profile Path: \\BERSERKER\profile <varlistentry> - <term>-w</term> + <term>-w|--smbpasswd-style</term> <listitem><para>This option sets the "smbpasswd" listing format. It will make pdbedit list the users in the database, printing out the account fields in a format compatible with the @@ -139,7 +149,7 @@ samba:45:0F2B255F7B67A7A9AAD3B435B51404EE: <varlistentry> - <term>-u username</term> + <term>-u|--user username</term> <listitem><para>This option specifies the username to be used for the operation requested (listing, adding, removing). It is <emphasis>required</emphasis> in add, remove and modify @@ -149,7 +159,7 @@ samba:45:0F2B255F7B67A7A9AAD3B435B51404EE: </varlistentry> <varlistentry> - <term>-f fullname</term> + <term>-f|--fullname fullname</term> <listitem><para>This option can be used while adding or modifing a user account. It will specify the user's full name. </para> @@ -159,7 +169,7 @@ samba:45:0F2B255F7B67A7A9AAD3B435B51404EE: </varlistentry> <varlistentry> - <term>-h homedir</term> + <term>-h|--homedir homedir</term> <listitem><para>This option can be used while adding or modifing a user account. It will specify the user's home directory network path.</para> @@ -170,7 +180,7 @@ samba:45:0F2B255F7B67A7A9AAD3B435B51404EE: </varlistentry> <varlistentry> - <term>-D drive</term> + <term>-D|--drive drive</term> <listitem><para>This option can be used while adding or modifing a user account. It will specify the windows drive letter to be used to map the home directory.</para> @@ -182,7 +192,7 @@ samba:45:0F2B255F7B67A7A9AAD3B435B51404EE: <varlistentry> - <term>-S script</term> + <term>-S|--script script</term> <listitem><para>This option can be used while adding or modifing a user account. It will specify the user's logon script path.</para> @@ -194,7 +204,7 @@ samba:45:0F2B255F7B67A7A9AAD3B435B51404EE: <varlistentry> - <term>-p profile</term> + <term>-p|--profile profile</term> <listitem><para>This option can be used while adding or modifing a user account. It will specify the user's profile directory.</para> @@ -205,29 +215,32 @@ samba:45:0F2B255F7B67A7A9AAD3B435B51404EE: </varlistentry> <varlistentry> - <term>-G SID|rid</term> + <term>-M|'--machine SID' SID|rid</term> <listitem><para> - This option can be used while adding or modifying a user account. It - will specify the users' new primary group SID (Security Identifier) or + This option can be used while adding or modifying a machine account. It + will specify the machines' new primary group SID (Security Identifier) or rid. </para> - <para>Example: <command>-G S-1-5-21-2447931902-1787058256-3961074038-1201</command></para> + <para>Example: <command>-M S-1-5-21-2447931902-1787058256-3961074038-1201</command></para> </listitem> </varlistentry> <varlistentry> - <term>-U SID|rid</term> + <term>-U|'--user SID' SID|rid</term> <listitem><para> This option can be used while adding or modifying a user account. It will specify the users' new SID (Security Identifier) or rid. </para> <para>Example: <command>-U S-1-5-21-2447931902-1787058256-3961074038-5004</command></para> + <para>Example: <command>'--user SID' S-1-5-21-2447931902-1787058256-3961074038-5004</command></para> + <para>Example: <command>-U 5004</command></para> + <para>Example: <command>'--user SID' 5004</command></para> </listitem> </varlistentry> <varlistentry> - <term>-c account-control</term> + <term>-c|--account-control account-control</term> <listitem><para>This option can be used while adding or modifying a user account. It will specify the users' account control property. Possible flags are listed below. </para> @@ -263,7 +276,7 @@ samba:45:0F2B255F7B67A7A9AAD3B435B51404EE: </varlistentry> <varlistentry> - <term>-a</term> + <term>-a|--create</term> <listitem><para>This option is used to add a user into the database. This command needs a user name specified with the -u switch. When adding a new user, pdbedit will also @@ -289,7 +302,7 @@ retype new password </varlistentry> <varlistentry> - <term>-t, --password-from-stdin</term> + <term>-t|--password-from-stdin</term> <listitem><para>This option causes pdbedit to read the password from standard input, rather than from /dev/tty (like the <command>passwd(1)</command> program does). The password has @@ -298,7 +311,7 @@ retype new password </varlistentry> <varlistentry> - <term>-r</term> + <term>-r|--modify</term> <listitem><para>This option is used to modify an existing user in the database. This command needs a user name specified with the -u switch. Other options can be specified to modify the properties of @@ -308,7 +321,7 @@ retype new password </varlistentry> <varlistentry> - <term>-m</term> + <term>-m|--machine</term> <listitem><para>This option may only be used in conjunction with the <parameter>-a</parameter> option. It will make pdbedit to add a machine trust account instead of a user @@ -321,7 +334,7 @@ retype new password <varlistentry> - <term>-x</term> + <term>-x|--delete</term> <listitem><para>This option causes pdbedit to delete an account from the database. It needs a username specified with the -u switch.</para> @@ -332,7 +345,7 @@ retype new password <varlistentry> - <term>-i passdb-backend</term> + <term>-i|--import passdb-backend</term> <listitem><para>Use a different passdb backend to retrieve users than the one specified in smb.conf. Can be used to import data into your local user database.</para> @@ -346,7 +359,7 @@ retype new password </varlistentry> <varlistentry> - <term>-e passdb-backend</term> + <term>-e|--export passdb-backend</term> <listitem><para>Exports all currently available users to the specified password database backend.</para> @@ -358,7 +371,7 @@ retype new password </varlistentry> <varlistentry> - <term>-g</term> + <term>-g|--group</term> <listitem><para>If you specify <parameter>-g</parameter>, then <parameter>-i in-backend -e out-backend</parameter> applies to the group mapping instead of the user database.</para> @@ -370,7 +383,7 @@ retype new password </varlistentry> <varlistentry> - <term>-b passdb-backend</term> + <term>-b|--backend passdb-backend</term> <listitem><para>Use a different default passdb backend. </para> <para>Example: <command>pdbedit -b xml:/root/pdb-backup.xml -l</command></para> @@ -378,7 +391,7 @@ retype new password </varlistentry> <varlistentry> - <term>-P account-policy</term> + <term>-P|--account-policy account-policy</term> <listitem><para>Display an account policy</para> <para>Valid policies are: minimum password age, reset count minutes, disconnect time, user must logon to change password, password history, lockout duration, min password length, @@ -394,7 +407,7 @@ account policy value for bad lockout attempt is 0 <varlistentry> - <term>-C account-policy-value</term> + <term>-C|--value account-policy-value</term> <listitem><para>Sets an account policy to a specified value. This option may only be used in conjunction with the <parameter>-P</parameter> option. @@ -409,7 +422,7 @@ account policy value for bad lockout attempt is now 3 </varlistentry> <varlistentry> - <term>-y</term> + <term>-y|--policies</term> <listitem><para>If you specify <parameter>-y</parameter>, then <parameter>-i in-backend -e out-backend</parameter> applies to the account policies instead of the user database.</para> @@ -422,6 +435,73 @@ account policy value for bad lockout attempt is now 3 </listitem> </varlistentry> + <varlistentry> + <term>--force-initialized-passwords</term> + <listitem><para>This option forces all users to change their + password upon next login. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>-N|--account-desc description</term> + <listitem><para>This option can be used while adding or + modifing a user account. It will specify the user's description + field.</para> + + <para>Example: <command>-N "test description"</command> + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>-Z|--logon-hours-reset</term> + <listitem><para>This option can be used while adding or + modifing a user account. It will reset the user's allowed logon + hours. A user may login at any time afterwards.</para> + + <para>Example: <command>-Z</command> + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>-z|--bad-password-count-reset</term> + <listitem><para>This option can be used while adding or + modifing a user account. It will reset the stored bad login + counter from a specified user.</para> + + <para>Example: <command>-z</command> + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>--policies-reset</term> + <listitem><para>This option can be used to reset the general + password policies stored for a domain to their + default values.</para> + <para>Example: <command>--policies-reset</command> + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>-I|--domain</term> + <listitem><para>This option can be used while adding or + modifing a user account. It will specify the user's domain field.</para> + + <para>Example: <command>-I "MYDOMAIN"</command> + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>--time-format</term> + <listitem><para>This option is currently not being used.</para> + </listitem> + </varlistentry> + &stdarg.help; &stdarg.server.debug; &popt.common.samba; diff --git a/docs-xml/manpages-3/rpcclient.1.xml b/docs-xml/manpages-3/rpcclient.1.xml index 79bb9289e5..1f6187ac60 100644 --- a/docs-xml/manpages-3/rpcclient.1.xml +++ b/docs-xml/manpages-3/rpcclient.1.xml @@ -29,7 +29,6 @@ <arg choice="opt">-s <smb config file></arg> <arg choice="opt">-U username[%password]</arg> <arg choice="opt">-W workgroup</arg> - <arg choice="opt">-N</arg> <arg choice="opt">-I destinationIP</arg> <arg choice="req">server</arg> </cmdsynopsis> @@ -70,7 +69,7 @@ <varlistentry> - <term>-I IP-address</term> + <term>-I|--dest-ip IP-address</term> <listitem><para><replaceable>IP address</replaceable> is the address of the server to connect to. It should be specified in standard "a.b.c.d" notation. </para> @@ -87,6 +86,14 @@ above. </para></listitem> </varlistentry> + <varlistentry> + <term>-p|--port port</term> + <listitem><para>This number is the TCP port number that will be used + when making connections to the server. The standard (well-known) + TCP port number for an SMB/CIFS server is 139, which is the + default. </para></listitem> + </varlistentry> + &stdarg.server.debug; &popt.common.samba; &popt.common.credentials; diff --git a/docs-xml/manpages-3/smbcacls.1.xml b/docs-xml/manpages-3/smbcacls.1.xml index b7d0a54b3d..16915bb617 100644 --- a/docs-xml/manpages-3/smbcacls.1.xml +++ b/docs-xml/manpages-3/smbcacls.1.xml @@ -55,7 +55,7 @@ <variablelist> <varlistentry> - <term>-a acls</term> + <term>-a|--add acls</term> <listitem><para>Add the ACLs specified to the ACL list. Existing access control entries are unchanged. </para></listitem> </varlistentry> @@ -63,7 +63,7 @@ <varlistentry> - <term>-M acls</term> + <term>-M|--modify acls</term> <listitem><para>Modify the mask value (permissions) for the ACLs specified on the command line. An error will be printed for each ACL specified that was not already present in the ACL list @@ -73,7 +73,7 @@ <varlistentry> - <term>-D acls</term> + <term>-D|--delete acls</term> <listitem><para>Delete any ACLs specified on the command line. An error will be printed for each ACL specified that was not already present in the ACL list. </para></listitem> @@ -82,7 +82,7 @@ <varlistentry> - <term>-S acls</term> + <term>-S|--set acls</term> <listitem><para>This command sets the ACLs on the file with only the ones specified on the command line. All other ACLs are erased. Note that the ACL specified must contain at least a revision, @@ -92,20 +92,7 @@ <varlistentry> - <term>-U username</term> - <listitem><para>Specifies a username used to connect to the - specified service. The username may be of the form "username" in - which case the user is prompted to enter in a password and the - workgroup specified in the <citerefentry><refentrytitle>smb.conf</refentrytitle> - <manvolnum>5</manvolnum></citerefentry> file is - used, or "username%password" or "DOMAIN\username%password" and the - password and workgroup names are used as provided. </para></listitem> - </varlistentry> - - - - <varlistentry> - <term>-C name</term> + <term>-C|--chown name</term> <listitem><para>The owner of a file or directory can be changed to the name given using the <parameter>-C</parameter> option. The name can be a sid in the form S-1-x-y-z or a name resolved @@ -118,7 +105,7 @@ <varlistentry> - <term>-G name</term> + <term>-G|--chgrp name</term> <listitem><para>The group owner of a file or directory can be changed to the name given using the <parameter>-G</parameter> option. The name can be a sid in the form S-1-x-y-z or a name @@ -138,7 +125,7 @@ </varlistentry> <varlistentry> - <term>-t</term> + <term>-t|--test-args</term> <listitem><para> Don't actually do anything, only validate the correctness of the arguments. @@ -148,6 +135,7 @@ &stdarg.help; &stdarg.server.debug; &popt.common.samba; + &popt.common.credentials; </variablelist> </refsect1> diff --git a/docs-xml/manpages-3/smbclient.1.xml b/docs-xml/manpages-3/smbclient.1.xml index dc948943b4..6b5a8c5d8a 100644 --- a/docs-xml/manpages-3/smbclient.1.xml +++ b/docs-xml/manpages-3/smbclient.1.xml @@ -144,7 +144,7 @@ </varlistentry> <varlistentry> - <term>-R <name resolve order></term> + <term>-R|--name-resolve <name resolve order></term> <listitem><para>This option is used by the programs in the Samba suite to determine what naming services and in what order to resolve host names to IP addresses. The option takes a space-separated @@ -201,7 +201,7 @@ <varlistentry> - <term>-M NetBIOS name</term> + <term>-M|--message NetBIOS name</term> <listitem><para>This options allows you to send messages, using the "WinPopup" protocol, to another computer. Once a connection is established you then type your message, pressing ^D (control-D) to @@ -237,7 +237,7 @@ </varlistentry> <varlistentry> - <term>-p port</term> + <term>-p|--port port</term> <listitem><para>This number is the TCP port number that will be used when making connections to the server. The standard (well-known) TCP port number for an SMB/CIFS server is 139, which is the @@ -245,7 +245,7 @@ </varlistentry> <varlistentry> - <term>-g</term> + <term>-g|--grepable</term> <listitem><para>This parameter provides combined with <parameter>-L</parameter> easy parseable output that allows processing with utilities such as grep and cut. @@ -253,6 +253,12 @@ </varlistentry> <varlistentry> + <term>-m|--max-protocol protocol</term> + <listitem><para>This parameter sets the maximum protocol version announced by the client. + </para></listitem> + </varlistentry> + + <varlistentry> <term>-P</term> <listitem><para> Make queries to the external server using the machine account of the local server. @@ -262,7 +268,7 @@ &stdarg.help; <varlistentry> - <term>-I IP-address</term> + <term>-I|--ip-address IP-address</term> <listitem><para><replaceable>IP address</replaceable> is the address of the server to connect to. It should be specified in standard "a.b.c.d" notation. </para> @@ -280,7 +286,7 @@ </varlistentry> <varlistentry> - <term>-E</term> + <term>-E|--stderr</term> <listitem><para>This parameter causes the client to write messages to the standard error stream (stderr) rather than to the standard output stream. </para> @@ -290,7 +296,7 @@ </varlistentry> <varlistentry> - <term>-L</term> + <term>-L|--list</term> <listitem><para>This option allows you to look at what services are available on a server. You use it as <command>smbclient -L host</command> and a list should appear. The <parameter>-I @@ -300,7 +306,7 @@ </varlistentry> <varlistentry> - <term>-b buffersize</term> + <term>-b|--send-buffer buffersize</term> <listitem><para>This option changes the transmit/send buffer size when getting or putting a file from/to the server. The default is 65520 bytes. Setting this value smaller (to 1200 bytes) has been @@ -326,7 +332,7 @@ &popt.common.connection; <varlistentry> - <term>-T tar options</term> + <term>-T|--tar tar options</term> <listitem><para>smbclient may be used to create <command>tar(1) </command> compatible backups of all the files on an SMB/CIFS share. The secondary tar flags that can be given to this option @@ -455,13 +461,13 @@ </varlistentry> <varlistentry> - <term>-D initial directory</term> + <term>-D|--directory initial directory</term> <listitem><para>Change to initial directory before starting. Probably only of any use with the tar -T option. </para></listitem> </varlistentry> <varlistentry> - <term>-c command string</term> + <term>-c|--comand command string</term> <listitem><para>command string is a semicolon-separated list of commands to be executed instead of prompting from stdin. <parameter> -N</parameter> is implied by <parameter>-c</parameter>.</para> diff --git a/docs-xml/manpages-3/smbget.1.xml b/docs-xml/manpages-3/smbget.1.xml index d38935904c..7170f466f3 100644 --- a/docs-xml/manpages-3/smbget.1.xml +++ b/docs-xml/manpages-3/smbget.1.xml @@ -34,6 +34,7 @@ <arg choice="opt">-q, --quiet</arg> <arg choice="opt">-v, --verbose</arg> <arg choice="opt">-b, --blocksize</arg> + <arg choice="opt">-O, --stdout</arg> <arg choice="opt">-?, --help</arg> <arg choice="opt">--usage</arg> <arg choice="req">smb://host/share/path/to/file</arg> @@ -112,7 +113,12 @@ <varlistentry> <term>-o, --outputfile</term> - <listitem><para>Write the file that is being download to the specified file. Can not be used together with -R.</para></listitem> + <listitem><para>Write the file that is being downloaded to the specified file. Can not be used together with -R.</para></listitem> + </varlistentry> + + <varlistentry> + <term>-O, --stdout</term> + <listitem><para>Write the file that is being downloaded to standard output.</para></listitem> </varlistentry> <varlistentry> diff --git a/docs-xml/manpages-3/smbtree.1.xml b/docs-xml/manpages-3/smbtree.1.xml index b94a700f78..9693338ce4 100644 --- a/docs-xml/manpages-3/smbtree.1.xml +++ b/docs-xml/manpages-3/smbtree.1.xml @@ -46,21 +46,21 @@ <variablelist> <varlistentry> - <term>-b</term> + <term>-b|--broadcast</term> <listitem><para>Query network nodes by sending requests as broadcasts instead of querying the local master browser. </para></listitem> </varlistentry> <varlistentry> - <term>-D</term> + <term>-D|--domains</term> <listitem><para>Only print a list of all the domains known on broadcast or by the master browser</para></listitem> </varlistentry> <varlistentry> - <term>-S</term> + <term>-S|--servers</term> <listitem><para>Only print a list of all the domains and servers responding on broadcast or known by the master browser. diff --git a/docs-xml/manpages-3/tdbbackup.8.xml b/docs-xml/manpages-3/tdbbackup.8.xml index c3a6e2b051..aaf46ac0a1 100644 --- a/docs-xml/manpages-3/tdbbackup.8.xml +++ b/docs-xml/manpages-3/tdbbackup.8.xml @@ -1,5 +1,5 @@ <?xml version="1.0" encoding="iso-8859-1"?> -<!DOCTYPE refentry PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc"> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> <refentry id="tdbbackup.8"> <refmeta> diff --git a/docs-xml/manpages-3/tdbdump.8.xml b/docs-xml/manpages-3/tdbdump.8.xml index 5c0028db42..719e43625a 100644 --- a/docs-xml/manpages-3/tdbdump.8.xml +++ b/docs-xml/manpages-3/tdbdump.8.xml @@ -1,5 +1,5 @@ <?xml version="1.0" encoding="iso-8859-1"?> -<!DOCTYPE refentry PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc"> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> <refentry id="tdbdump.8"> <refmeta> diff --git a/docs-xml/manpages-3/tdbtool.8.xml b/docs-xml/manpages-3/tdbtool.8.xml index a755653106..05d2ecb6d2 100644 --- a/docs-xml/manpages-3/tdbtool.8.xml +++ b/docs-xml/manpages-3/tdbtool.8.xml @@ -1,5 +1,5 @@ <?xml version="1.0" encoding="iso-8859-1"?> -<!DOCTYPE refentry PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc"> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> <refentry id="tdbtool.8"> <refmeta> diff --git a/docs-xml/smbdotconf/tuning/maxopenfiles.xml b/docs-xml/smbdotconf/tuning/maxopenfiles.xml index ea0a33980a..8c1a49f686 100644 --- a/docs-xml/smbdotconf/tuning/maxopenfiles.xml +++ b/docs-xml/smbdotconf/tuning/maxopenfiles.xml @@ -4,17 +4,20 @@ advanced="1" developer="1" xmlns:samba="http://www.samba.org/samba/DTD/samba-doc"> <description> - <para>This parameter limits the maximum number of + <para>This parameter limits the maximum number of open files that one <citerefentry><refentrytitle>smbd</refentrytitle> - <manvolnum>8</manvolnum></citerefentry> file - serving process may have open for a client at any one time. The - default for this parameter is set very high (10,000) as Samba uses - only one bit per unopened file.</para> - - <para>The limit of the number of open files is usually set - by the UNIX per-process file descriptor limit rather than + <manvolnum>8</manvolnum></citerefentry> file + serving process may have open for a client at any one time. The + This parameter can be set very high (16404) as Samba uses + only one bit per unopened file. Setting this parameter lower than + 16404 will cause Samba to complain and set this value back to + the minimum of 16404, as Windows 7 depends on this number of + open file handles being available.</para> + + <para>The limit of the number of open files is usually set + by the UNIX per-process file descriptor limit rather than this parameter so you should never need to touch this parameter.</para> </description> -<value type="default">10000</value> +<value type="default">16404</value> </samba:parameter> diff --git a/lib/replace/snprintf.c b/lib/replace/snprintf.c index c54d721ce5..bca774263e 100644 --- a/lib/replace/snprintf.c +++ b/lib/replace/snprintf.c @@ -504,6 +504,7 @@ static int dopr(char *buffer, size_t maxlen, const char *format, va_list args_in break; case 'p': cnk->type = CNK_PTR; + cnk->flags |= DP_F_UNSIGNED; break; case 'n': cnk->type = CNK_NUM; diff --git a/lib/talloc/configure.ac b/lib/talloc/configure.ac index a169f79724..c1b1d2e4a1 100644 --- a/lib/talloc/configure.ac +++ b/lib/talloc/configure.ac @@ -1,5 +1,5 @@ AC_PREREQ(2.50) -AC_INIT(talloc, 2.0.0) +AC_INIT(talloc, 2.0.1) AC_CONFIG_SRCDIR([talloc.c]) AC_SUBST(datarootdir) AC_CONFIG_HEADER(config.h) diff --git a/lib/talloc/script/abi_checks.sh b/lib/talloc/script/abi_checks.sh index ba60ed003a..66c4e60e45 100755 --- a/lib/talloc/script/abi_checks.sh +++ b/lib/talloc/script/abi_checks.sh @@ -33,6 +33,7 @@ LANG=C; export LANG LC_ALL=C; export LC_ALL LC_COLLATE=C; export LC_COLLATE +exit_status=0 script=$0 dir_name=$(dirname ${script}) @@ -58,34 +59,22 @@ signatures_file_check=${signatures_file}.check ${dir_name}/mksyms.sh awk ${exports_file_check} ${headers} 2>&1 > /dev/null +cat ${headers} | ${dir_name}/mksigs.pl | sort| uniq > ${signatures_file_check} 2> /dev/null -cat ${headers} | ${dir_name}/mksigs.pl > ${signatures_file_check} 2> /dev/null - -normalize_exports_file() { - filename=$1 - cat ${filename} \ - | sed -e 's/^[ \t]*//g' \ - | sed -e 's/^$//g' \ - | sed -e 's/^#.*$//g' \ - | sort | uniq > ${filename}.sort -} - -normalize_exports_file ${exports_file} -normalize_exports_file ${exports_file_check} - -normalize_exports_file ${signatures_file} -normalize_exports_file ${signatures_file_check} - -diff -u ${exports_file}.sort ${exports_file_check}.sort +diff -u ${exports_file} ${exports_file_check} if test "x$?" != "x0" ; then echo "WARNING: possible ABI change detected in exports!" + let exit_status++ else echo "exports check: OK" fi -diff -u ${signatures_file}.sort ${signatures_file_check}.sort +diff -u ${signatures_file} ${signatures_file_check} if test "x$?" != "x0" ; then echo "WARNING: possible ABI change detected in signatures!" + let exit_status++ else echo "signatures check: OK" fi + +exit $exit_status diff --git a/lib/talloc/script/mksyms.awk b/lib/talloc/script/mksyms.awk index ca14da0f21..8775faff3f 100644 --- a/lib/talloc/script/mksyms.awk +++ b/lib/talloc/script/mksyms.awk @@ -8,25 +8,12 @@ # BEGIN { inheader=0; - current_file=""; - print "#" - print "# This file is automatically generated with \"make symbols\". DO NOT EDIT " - print "#" - print "{" - print "\tglobal:" } END { - print"" - print "\tlocal: *;" - print "};" } { - if (FILENAME!=current_file) { - print "\t\t# The following definitions come from",FILENAME - current_file=FILENAME - } if (inheader) { if (match($0,"[)][^()]*[;][ \t]*$")) { inheader = 0; @@ -42,7 +29,7 @@ END { /^extern[ \t]+[^()]+[;][ \t]*$/ { gsub(/[^ \t]+[ \t]+/, ""); sub(/[;][ \t]*$/, ""); - printf "\t\t%s;\n", $0; + printf " %s;\n", $0; next; } @@ -61,7 +48,7 @@ END { sub(/[(].*$/, ""); gsub(/[^ \t]+[ \t]+/, ""); gsub(/^[*]+/, ""); - printf "\t\t%s;\n",$0; + printf " %s;\n",$0; next; } @@ -70,7 +57,7 @@ END { sub(/[(].*$/, ""); gsub(/[^ \t]+[ \t]+/, ""); gsub(/^[*]/, ""); - printf "\t\t%s;\n",$0; + printf " %s;\n",$0; next; } diff --git a/lib/talloc/script/mksyms.sh b/lib/talloc/script/mksyms.sh index 714d55abae..089344f8f0 100755 --- a/lib/talloc/script/mksyms.sh +++ b/lib/talloc/script/mksyms.sh @@ -34,7 +34,24 @@ echo creating $symsfile mkdir -p `dirname $symsfile` -${awk} -f `dirname $0`/mksyms.awk $proto_src > $symsfile_tmp +#Write header +cat > $symsfile_tmp << EOF +# This file is autogenerated, please DO NOT EDIT +{ + global: +EOF + +#loop on each header +for i in $proto_src; do +${awk} -f `dirname $0`/mksyms.awk $i | sort >> $symsfile_tmp +done; + +#Write tail +cat >> $symsfile_tmp << EOF + + local: *; +}; +EOF if cmp -s $symsfile $symsfile_tmp 2>/dev/null then diff --git a/lib/talloc/release-script.sh b/lib/talloc/script/release-script.sh index 6b6c0e7aad..fd5c1eff5d 100755 --- a/lib/talloc/release-script.sh +++ b/lib/talloc/script/release-script.sh @@ -10,10 +10,20 @@ if [ ! -d "lib/talloc" ]; then exit 1 fi +# Check exports and signatures are up to date +pushd lib/talloc +./script/abi_checks.sh talloc talloc.h +abicheck=$? +popd +if [ ! "$abicheck" = "0" ]; then + echo "ERROR: ABI Checks produced warnings!" + exit 1 +fi + git clean -f -x -d lib/talloc git clean -f -x -d lib/replace -curbranch=`git-branch |grep "^*" | tr -d "* "` +curbranch=`git branch |grep "^*" | tr -d "* "` version=$1 strver=`echo ${version} | tr "." "-"` diff --git a/lib/talloc/talloc.c b/lib/talloc/talloc.c index 7beda4b0f5..f7b1ac3dbd 100644 --- a/lib/talloc/talloc.c +++ b/lib/talloc/talloc.c @@ -1184,7 +1184,7 @@ void *_talloc_realloc(const void *context, void *ptr, size_t size, const char *n #if ALWAYS_REALLOC new_ptr = malloc(size + TC_HDR_SIZE); if (new_ptr) { - memcpy(new_ptr, tc, tc->size + TC_HDR_SIZE); + memcpy(new_ptr, tc, MIN(tc->size, size) + TC_HDR_SIZE); free(tc); } #else diff --git a/lib/talloc/talloc.exports b/lib/talloc/talloc.exports index 75134c0802..1b8062f4a0 100644 --- a/lib/talloc/talloc.exports +++ b/lib/talloc/talloc.exports @@ -1,7 +1,19 @@ +# This file is autogenerated, please DO NOT EDIT { global: _talloc; _talloc_array; + _talloc_free; + _talloc_get_type_abort; + _talloc_memdup; + _talloc_move; + _talloc_realloc; + _talloc_realloc_array; + _talloc_reference_loc; + _talloc_set_destructor; + _talloc_steal_loc; + _talloc_zero; + _talloc_zero_array; talloc_asprintf; talloc_asprintf_append; talloc_asprintf_append_buffer; @@ -11,40 +23,32 @@ talloc_enable_leak_report; talloc_enable_leak_report_full; talloc_enable_null_tracking; + talloc_enable_null_tracking_no_autofree; talloc_find_parent_byname; - _talloc_free; talloc_free_children; talloc_get_name; talloc_get_size; - _talloc_get_type_abort; talloc_increase_ref_count; talloc_init; talloc_is_parent; - _talloc_memdup; - _talloc_move; talloc_named; talloc_named_const; talloc_parent; talloc_parent_name; talloc_pool; - _talloc_realloc; - _talloc_realloc_array; talloc_realloc_fn; talloc_reference_count; - _talloc_reference_loc; talloc_reparent; talloc_report; talloc_report_depth_cb; talloc_report_depth_file; talloc_report_full; talloc_set_abort_fn; - _talloc_set_destructor; talloc_set_log_fn; talloc_set_log_stderr; talloc_set_name; talloc_set_name_const; talloc_show_parents; - _talloc_steal_loc; talloc_strdup; talloc_strdup_append; talloc_strdup_append_buffer; @@ -59,8 +63,6 @@ talloc_vasprintf_append_buffer; talloc_version_major; talloc_version_minor; - _talloc_zero; - _talloc_zero_array; local: *; }; diff --git a/lib/talloc/talloc.mk b/lib/talloc/talloc.mk index a563d613d6..fc90f4d41e 100644 --- a/lib/talloc/talloc.mk +++ b/lib/talloc/talloc.mk @@ -1,5 +1,6 @@ TALLOC_OBJ = $(tallocdir)/talloc.o +TALLOC_SHLIB = libtalloc.$(SHLIBEXT) TALLOC_SOLIB = libtalloc.$(SHLIBEXT).$(TALLOC_VERSION) TALLOC_SONAME = libtalloc.$(SHLIBEXT).$(TALLOC_VERSION_MAJOR) TALLOC_STLIB = libtalloc.a @@ -25,6 +26,10 @@ install:: all if [ -f talloc.3 ];then ${INSTALLCMD} -m 644 talloc.3 $(DESTDIR)$(mandir)/man3; fi which swig >/dev/null 2>&1 && ${INSTALLCMD} -d $(DESTDIR)`swig -swiglib` || true which swig >/dev/null 2>&1 && ${INSTALLCMD} -m 644 talloc.i $(DESTDIR)`swig -swiglib` || true + rm -f $(DESTDIR)$(libdir)/$(TALLOC_SONAME) + ln -s $(TALLOC_SOLIB) $(DESTDIR)$(libdir)/$(TALLOC_SONAME) + rm -f $(DESTDIR)$(libdir)/$(TALLOC_SHLIB) + ln -s $(TALLOC_SOLIB) $(DESTDIR)$(libdir)/$(TALLOC_SHLIB) doc:: talloc.3 talloc.3.html diff --git a/lib/talloc/talloc.signatures b/lib/talloc/talloc.signatures index 00fb4a3296..f2868e8269 100644 --- a/lib/talloc/talloc.signatures +++ b/lib/talloc/talloc.signatures @@ -1,15 +1,15 @@ -char *talloc_asprintf_append_buffer (char *, const char *, ...); -char *talloc_asprintf_append (char *, const char *, ...); char *talloc_asprintf (const void *, const char *, ...); -char *talloc_strdup_append_buffer (char *, const char *); -char *talloc_strdup_append (char *, const char *); +char *talloc_asprintf_append (char *, const char *, ...); +char *talloc_asprintf_append_buffer (char *, const char *, ...); char *talloc_strdup (const void *, const char *); -char *talloc_strndup_append_buffer (char *, const char *, size_t); -char *talloc_strndup_append (char *, const char *, size_t); +char *talloc_strdup_append (char *, const char *); +char *talloc_strdup_append_buffer (char *, const char *); char *talloc_strndup (const void *, const char *, size_t); -char *talloc_vasprintf_append_buffer (char *, const char *, va_list); -char *talloc_vasprintf_append (char *, const char *, va_list); +char *talloc_strndup_append (char *, const char *, size_t); +char *talloc_strndup_append_buffer (char *, const char *, size_t); char *talloc_vasprintf (const void *, const char *, va_list); +char *talloc_vasprintf_append (char *, const char *, va_list); +char *talloc_vasprintf_append_buffer (char *, const char *, va_list); const char *talloc_get_name (const void *); const char *talloc_parent_name (const void *); const char *talloc_set_name (const void *, const char *, ...); @@ -23,39 +23,40 @@ size_t talloc_get_size (const void *); size_t talloc_reference_count (const void *); size_t talloc_total_blocks (const void *); size_t talloc_total_size (const void *); +void *_talloc (const void *, size_t); void *_talloc_array (const void *, size_t, unsigned int, const char *); +void *_talloc_get_type_abort (const void *, const char *, const char *); +void *_talloc_memdup (const void *, const void *, size_t, const char *); +void *_talloc_move (const void *, const void *); +void *_talloc_realloc (const void *, void *, size_t, const char *); +void *_talloc_realloc_array (const void *, void *, size_t, unsigned int, const char *); +void *_talloc_reference_loc (const void *, const void *, const char *); +void *_talloc_steal_loc (const void *, const void *, const char *); +void *_talloc_zero (const void *, size_t, const char *); +void *_talloc_zero_array (const void *, size_t, unsigned int, const char *); void *talloc_autofree_context (void); void *talloc_check_name (const void *, const char *); -void *_talloc (const void *, size_t); -void talloc_disable_null_tracking (void); -void talloc_enable_leak_report_full (void); -void talloc_enable_leak_report (void); -void talloc_enable_null_tracking (void); void *talloc_find_parent_byname (const void *, const char *); -void talloc_free_children (void *); -void *_talloc_get_type_abort (const void *, const char *, const char *); void *talloc_init (const char *, ...); -void *_talloc_memdup (const void *, const void *, size_t, const char *); -void *_talloc_move (const void *, const void *); -void *talloc_named_const (const void *, size_t, const char *); void *talloc_named (const void *, size_t, const char *, ...); +void *talloc_named_const (const void *, size_t, const char *); void *talloc_parent (const void *); void *talloc_pool (const void *, size_t); -void *_talloc_realloc_array (const void *, void *, size_t, unsigned int, const char *); -void *_talloc_realloc (const void *, void *, size_t, const char *); void *talloc_realloc_fn (const void *, void *, size_t); -void *_talloc_reference_loc (const void *, const void *, const char *); void *talloc_reparent (const void *, const void *, const void *); +void _talloc_set_destructor (const void *, int (*) (void *)); +void talloc_disable_null_tracking (void); +void talloc_enable_leak_report (void); +void talloc_enable_leak_report_full (void); +void talloc_enable_null_tracking (void); +void talloc_enable_null_tracking_no_autofree (void); +void talloc_free_children (void *); void talloc_report (const void *, FILE *); void talloc_report_depth_cb (const void *, int, int, void (*) (const void *, int, int, int, void *), void *); void talloc_report_depth_file (const void *, int, int, FILE *); void talloc_report_full (const void *, FILE *); void talloc_set_abort_fn (void (*) (const char *)); -void _talloc_set_destructor (const void *, int (*) (void *)); void talloc_set_log_fn (void (*) (const char *)); void talloc_set_log_stderr (void); void talloc_set_name_const (const void *, const char *); void talloc_show_parents (const void *, FILE *); -void *_talloc_steal_loc (const void *, const void *, const char *); -void *_talloc_zero_array (const void *, size_t, unsigned int, const char *); -void *_talloc_zero (const void *, size_t, const char *); diff --git a/lib/tdb/Makefile.in b/lib/tdb/Makefile.in index 93bfe37f4f..dc22ee3fea 100644 --- a/lib/tdb/Makefile.in +++ b/lib/tdb/Makefile.in @@ -9,6 +9,7 @@ exec_prefix = @exec_prefix@ bindir = @bindir@ includedir = @includedir@ libdir = @libdir@ +mandir = @mandir@ VPATH = @srcdir@:@libreplacedir@ srcdir = @srcdir@ builddir = @builddir@ @@ -31,18 +32,22 @@ PYTHON_CHECK_TARGET = @PYTHON_CHECK_TARGET@ LIB_PATH_VAR = @LIB_PATH_VAR@ tdbdir = @tdbdir@ +EXTRA_TARGETS = @DOC_TARGET@ + TDB_OBJ = @TDB_OBJ@ @LIBREPLACEOBJ@ SONAMEFLAG = @SONAMEFLAG@ VERSIONSCRIPT = @VERSIONSCRIPT@ EXPORTSFILE = @EXPORTSFILE@ +XSLTPROC = @XSLTPROC@ + default: all include $(tdbdir)/tdb.mk include $(tdbdir)/rules.mk -all:: showflags dirs $(PROGS) $(TDB_SOLIB) libtdb.a $(PYTHON_BUILD_TARGET) +all:: showflags dirs $(PROGS) $(TDB_SOLIB) libtdb.a $(PYTHON_BUILD_TARGET) $(EXTRA_TARGETS) install:: all $(TDB_SOLIB): $(TDB_OBJ) diff --git a/lib/tdb/common/open.c b/lib/tdb/common/open.c index 1ba2e7bd11..4d4f95a3da 100644 --- a/lib/tdb/common/open.c +++ b/lib/tdb/common/open.c @@ -163,6 +163,9 @@ struct tdb_context *tdb_open_ex(const char *name, int hash_size, int tdb_flags, } tdb_io_init(tdb); tdb->fd = -1; +#ifdef TDB_TRACE + tdb->tracefd = -1; +#endif tdb->name = NULL; tdb->map_ptr = NULL; tdb->flags = tdb_flags; @@ -199,6 +202,23 @@ struct tdb_context *tdb_open_ex(const char *name, int hash_size, int tdb_flags, tdb->flags &= ~TDB_CLEAR_IF_FIRST; } + if ((tdb->flags & TDB_ALLOW_NESTING) && + (tdb->flags & TDB_DISALLOW_NESTING)) { + tdb->ecode = TDB_ERR_NESTING; + TDB_LOG((tdb, TDB_DEBUG_FATAL, "tdb_open_ex: " + "allow_nesting and disallow_nesting are not allowed together!")); + errno = EINVAL; + goto fail; + } + + /* + * TDB_ALLOW_NESTING is the default behavior. + * Note: this may change in future versions! + */ + if (!(tdb->flags & TDB_DISALLOW_NESTING)) { + tdb->flags |= TDB_ALLOW_NESTING; + } + /* internal databases don't mmap or lock, and start off cleared */ if (tdb->flags & TDB_INTERNAL) { tdb->flags |= (TDB_NOLOCK | TDB_NOMMAP); @@ -207,10 +227,6 @@ struct tdb_context *tdb_open_ex(const char *name, int hash_size, int tdb_flags, TDB_LOG((tdb, TDB_DEBUG_ERROR, "tdb_open_ex: tdb_new_database failed!")); goto fail; } -#ifdef TDB_TRACE - /* All tracing will fail. That's ok. */ - tdb->tracefd = -1; -#endif goto internal; } @@ -403,8 +419,10 @@ int tdb_close(struct tdb_context *tdb) tdb_munmap(tdb); } SAFE_FREE(tdb->name); - if (tdb->fd != -1) + if (tdb->fd != -1) { ret = close(tdb->fd); + tdb->fd = -1; + } SAFE_FREE(tdb->lockrecs); /* Remove from contexts list */ diff --git a/lib/tdb/common/tdb.c b/lib/tdb/common/tdb.c index 564c5fed5c..d2688def04 100644 --- a/lib/tdb/common/tdb.c +++ b/lib/tdb/common/tdb.c @@ -730,11 +730,41 @@ int tdb_get_flags(struct tdb_context *tdb) void tdb_add_flags(struct tdb_context *tdb, unsigned flags) { + if ((flags & TDB_ALLOW_NESTING) && + (flags & TDB_DISALLOW_NESTING)) { + tdb->ecode = TDB_ERR_NESTING; + TDB_LOG((tdb, TDB_DEBUG_FATAL, "tdb_add_flags: " + "allow_nesting and disallow_nesting are not allowed together!")); + return; + } + + if (flags & TDB_ALLOW_NESTING) { + tdb->flags &= ~TDB_DISALLOW_NESTING; + } + if (flags & TDB_DISALLOW_NESTING) { + tdb->flags &= ~TDB_ALLOW_NESTING; + } + tdb->flags |= flags; } void tdb_remove_flags(struct tdb_context *tdb, unsigned flags) { + if ((flags & TDB_ALLOW_NESTING) && + (flags & TDB_DISALLOW_NESTING)) { + tdb->ecode = TDB_ERR_NESTING; + TDB_LOG((tdb, TDB_DEBUG_FATAL, "tdb_remove_flags: " + "allow_nesting and disallow_nesting are not allowed together!")); + return; + } + + if (flags & TDB_ALLOW_NESTING) { + tdb->flags |= TDB_DISALLOW_NESTING; + } + if (flags & TDB_DISALLOW_NESTING) { + tdb->flags |= TDB_ALLOW_NESTING; + } + tdb->flags &= ~flags; } diff --git a/lib/tdb/common/transaction.c b/lib/tdb/common/transaction.c index 035b4e1d54..20f2bfc2cd 100644 --- a/lib/tdb/common/transaction.c +++ b/lib/tdb/common/transaction.c @@ -85,6 +85,21 @@ still available, but no transaction recovery area is used and no fsync/msync calls are made. + - if TDB_ALLOW_NESTING is passed to flags in tdb open, or added using + tdb_add_flags() transaction nesting is enabled. + It resets the TDB_DISALLOW_NESTING flag, as both cannot be used together. + The default is that transaction nesting is allowed. + Note: this default may change in future versions of tdb. + + Beware. when transactions are nested a transaction successfully + completed with tdb_transaction_commit() can be silently unrolled later. + + - if TDB_DISALLOW_NESTING is passed to flags in tdb open, or added using + tdb_add_flags() transaction nesting is disabled. + It resets the TDB_ALLOW_NESTING flag, as both cannot be used together. + An attempt create a nested transaction will fail with TDB_ERR_NESTING. + The default is that transaction nesting is allowed. + Note: this default may change in future versions of tdb. */ @@ -427,6 +442,10 @@ int tdb_transaction_start(struct tdb_context *tdb) /* cope with nested tdb_transaction_start() calls */ if (tdb->transaction != NULL) { + if (!(tdb->flags & TDB_ALLOW_NESTING)) { + tdb->ecode = TDB_ERR_NESTING; + return -1; + } tdb->transaction->nesting++; TDB_LOG((tdb, TDB_DEBUG_TRACE, "tdb_transaction_start: nesting %d\n", tdb->transaction->nesting)); diff --git a/lib/tdb/configure.ac b/lib/tdb/configure.ac index 52ecff4bbb..dac7bb2673 100644 --- a/lib/tdb/configure.ac +++ b/lib/tdb/configure.ac @@ -2,7 +2,7 @@ AC_PREREQ(2.50) AC_DEFUN([SMB_MODULE_DEFAULT], [echo -n ""]) AC_DEFUN([SMB_LIBRARY_ENABLE], [echo -n ""]) AC_DEFUN([SMB_ENABLE], [echo -n ""]) -AC_INIT(tdb, 1.1.7) +AC_INIT(tdb, 1.2.0) AC_CONFIG_SRCDIR([common/tdb.c]) AC_CONFIG_HEADER(include/config.h) AC_LIBREPLACE_ALL_CHECKS @@ -38,6 +38,13 @@ AC_ARG_ENABLE(python, fi ]) +AC_PATH_PROG(XSLTPROC,xsltproc) +DOC_TARGET="" +if test -n "$XSLTPROC"; then + DOC_TARGET=doc +fi +AC_SUBST(DOC_TARGET) + m4_include(build_macros.m4) BUILD_WITH_SHARED_BUILD_DIR diff --git a/lib/tdb/docs/README b/lib/tdb/docs/README index 4eb809fdf4..c02ee0e030 100644 --- a/lib/tdb/docs/README +++ b/lib/tdb/docs/README @@ -69,11 +69,15 @@ TDB_CONTEXT *tdb_open(char *name, int hash_size, int tdb_flags, TDB_NOLOCK - don't do any locking TDB_NOMMAP - don't use mmap TDB_NOSYNC - don't synchronise transactions to disk + TDB_SEQNUM - maintain a sequence number + TDB_VOLATILE - activate the per-hashchain freelist, default 5 + TDB_ALLOW_NESTING - allow transactions to nest + TDB_DISALLOW_NESTING - disallow transactions to nest ---------------------------------------------------------------------- TDB_CONTEXT *tdb_open_ex(char *name, int hash_size, int tdb_flags, int open_flags, mode_t mode, - tdb_log_func log_fn, + const struct tdb_logging_context *log_ctx, tdb_hash_func hash_fn) This is like tdb_open(), but allows you to pass an initial logging and @@ -93,13 +97,6 @@ int tdb_close(TDB_CONTEXT *tdb); close a database ---------------------------------------------------------------------- -int tdb_update(TDB_CONTEXT *tdb, TDB_DATA key, TDB_DATA dbuf); - - update an entry in place - this only works if the new data size - is <= the old data size and the key exists. - on failure return -1 - ----------------------------------------------------------------------- TDB_DATA tdb_fetch(TDB_CONTEXT *tdb, TDB_DATA key); fetch an entry in the database given a key diff --git a/lib/tdb/include/tdb.h b/lib/tdb/include/tdb.h index e849f20641..c9e946a885 100644 --- a/lib/tdb/include/tdb.h +++ b/lib/tdb/include/tdb.h @@ -48,11 +48,14 @@ extern "C" { #define TDB_NOSYNC 64 /* don't use synchronous transactions */ #define TDB_SEQNUM 128 /* maintain a sequence number */ #define TDB_VOLATILE 256 /* Activate the per-hashchain freelist, default 5 */ +#define TDB_ALLOW_NESTING 512 /* Allow transactions to nest */ +#define TDB_DISALLOW_NESTING 1024 /* Disallow transactions to nest */ /* error codes */ enum TDB_ERROR {TDB_SUCCESS=0, TDB_ERR_CORRUPT, TDB_ERR_IO, TDB_ERR_LOCK, TDB_ERR_OOM, TDB_ERR_EXISTS, TDB_ERR_NOLOCK, TDB_ERR_LOCK_TIMEOUT, - TDB_ERR_NOEXIST, TDB_ERR_EINVAL, TDB_ERR_RDONLY}; + TDB_ERR_NOEXIST, TDB_ERR_EINVAL, TDB_ERR_RDONLY, + TDB_ERR_NESTING}; /* debugging uses one of the following levels */ enum tdb_debug_level {TDB_DEBUG_FATAL = 0, TDB_DEBUG_ERROR, @@ -140,7 +143,7 @@ void tdb_remove_flags(struct tdb_context *tdb, unsigned flag); void tdb_enable_seqnum(struct tdb_context *tdb); void tdb_increment_seqnum_nonblock(struct tdb_context *tdb); int tdb_check(struct tdb_context *tdb, - int (*check)(TDB_DATA key, TDB_DATA data, void *private_data), + int (*check) (TDB_DATA key, TDB_DATA data, void *private_data), void *private_data); /* Low level locking functions: use with care */ diff --git a/lib/tdb/manpages/tdbbackup.8.xml b/lib/tdb/manpages/tdbbackup.8.xml new file mode 100644 index 0000000000..c3a6e2b051 --- /dev/null +++ b/lib/tdb/manpages/tdbbackup.8.xml @@ -0,0 +1,136 @@ +<?xml version="1.0" encoding="iso-8859-1"?> +<!DOCTYPE refentry PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc"> +<refentry id="tdbbackup.8"> + +<refmeta> + <refentrytitle>tdbbackup</refentrytitle> + <manvolnum>8</manvolnum> + <refmiscinfo class="source">Samba</refmiscinfo> + <refmiscinfo class="manual">System Administration tools</refmiscinfo> + <refmiscinfo class="version">3.5</refmiscinfo> +</refmeta> + + +<refnamediv> + <refname>tdbbackup</refname> + <refpurpose>tool for backing up and for validating the integrity of samba .tdb files</refpurpose> +</refnamediv> + +<refsynopsisdiv> + <cmdsynopsis> + <command>tdbbackup</command> + <arg choice="opt">-s suffix</arg> + <arg choice="opt">-v</arg> + <arg choice="opt">-h</arg> + </cmdsynopsis> +</refsynopsisdiv> + +<refsect1> + <title>DESCRIPTION</title> + + <para>This tool is part of the <citerefentry><refentrytitle>samba</refentrytitle> + <manvolnum>1</manvolnum></citerefentry> suite.</para> + + <para><command>tdbbackup</command> is a tool that may be used to backup samba .tdb + files. This tool may also be used to verify the integrity of the .tdb files prior + to samba startup or during normal operation. If it finds file damage and it finds + a prior backup the backup file will be restored. + </para> +</refsect1> + + +<refsect1> + <title>OPTIONS</title> + + <variablelist> + + <varlistentry> + <term>-h</term> + <listitem><para> + Get help information. + </para></listitem> + </varlistentry> + + <varlistentry> + <term>-s suffix</term> + <listitem><para> + The <command>-s</command> option allows the adminisistrator to specify a file + backup extension. This way it is possible to keep a history of tdb backup + files by using a new suffix for each backup. + </para> </listitem> + </varlistentry> + + <varlistentry> + <term>-v</term> + <listitem><para> + The <command>-v</command> will check the database for damages (currupt data) + which if detected causes the backup to be restored. + </para></listitem> + </varlistentry> + + </variablelist> +</refsect1> + + +<refsect1> + <title>COMMANDS</title> + + <para><emphasis>GENERAL INFORMATION</emphasis></para> + + <para> + The <command>tdbbackup</command> utility can safely be run at any time. It was designed so + that it can be used at any time to validate the integrity of tdb files, even during Samba + operation. Typical usage for the command will be: + </para> + + <para>tdbbackup [-s suffix] *.tdb</para> + + <para> + Before restarting samba the following command may be run to validate .tdb files: + </para> + + <para>tdbbackup -v [-s suffix] *.tdb</para> + + <para> + Samba .tdb files are stored in various locations, be sure to run backup all + .tdb file on the system. Important files includes: + </para> + + <itemizedlist> + <listitem><para> + <command>secrets.tdb</command> - usual location is in the /usr/local/samba/private + directory, or on some systems in /etc/samba. + </para></listitem> + + <listitem><para> + <command>passdb.tdb</command> - usual location is in the /usr/local/samba/private + directory, or on some systems in /etc/samba. + </para></listitem> + + <listitem><para> + <command>*.tdb</command> located in the /usr/local/samba/var directory or on some + systems in the /var/cache or /var/lib/samba directories. + </para></listitem> + </itemizedlist> + +</refsect1> + +<refsect1> + <title>VERSION</title> + + <para>This man page is correct for version 3 of the Samba suite.</para> +</refsect1> + +<refsect1> + <title>AUTHOR</title> + + <para> + The original Samba software and related utilities were created by Andrew Tridgell. + Samba is now developed by the Samba Team as an Open Source project similar to the way + the Linux kernel is developed. + </para> + + <para>The tdbbackup man page was written by John H Terpstra.</para> +</refsect1> + +</refentry> diff --git a/lib/tdb/manpages/tdbdump.8.xml b/lib/tdb/manpages/tdbdump.8.xml new file mode 100644 index 0000000000..5c0028db42 --- /dev/null +++ b/lib/tdb/manpages/tdbdump.8.xml @@ -0,0 +1,61 @@ +<?xml version="1.0" encoding="iso-8859-1"?> +<!DOCTYPE refentry PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc"> +<refentry id="tdbdump.8"> + +<refmeta> + <refentrytitle>tdbdump</refentrytitle> + <manvolnum>8</manvolnum> + <refmiscinfo class="source">Samba</refmiscinfo> + <refmiscinfo class="manual">System Administration tools</refmiscinfo> + <refmiscinfo class="version">3.5</refmiscinfo> +</refmeta> + + +<refnamediv> + <refname>tdbdump</refname> + <refpurpose>tool for printing the contents of a TDB file</refpurpose> +</refnamediv> + +<refsynopsisdiv> + <cmdsynopsis> + <command>tdbdump</command> + <arg choice="req">filename</arg> + </cmdsynopsis> +</refsynopsisdiv> + +<refsect1> + <title>DESCRIPTION</title> + + <para>This tool is part of the <citerefentry><refentrytitle>samba</refentrytitle> + <manvolnum>1</manvolnum></citerefentry> suite.</para> + + <para><command>tdbdump</command> is a very simple utility that 'dumps' the + contents of a TDB (Trivial DataBase) file to standard output in a + human-readable format. + </para> + + <para>This tool can be used when debugging problems with TDB files. It is + intended for those who are somewhat familiar with Samba internals. + </para> +</refsect1> + + +<refsect1> + <title>VERSION</title> + + <para>This man page is correct for version 3 of the Samba suite.</para> +</refsect1> + +<refsect1> + <title>AUTHOR</title> + + <para> + The original Samba software and related utilities were created by Andrew Tridgell. + Samba is now developed by the Samba Team as an Open Source project similar to the way + the Linux kernel is developed. + </para> + + <para>The tdbdump man page was written by Jelmer Vernooij.</para> +</refsect1> + +</refentry> diff --git a/lib/tdb/manpages/tdbtool.8.xml b/lib/tdb/manpages/tdbtool.8.xml new file mode 100644 index 0000000000..a755653106 --- /dev/null +++ b/lib/tdb/manpages/tdbtool.8.xml @@ -0,0 +1,235 @@ +<?xml version="1.0" encoding="iso-8859-1"?> +<!DOCTYPE refentry PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc"> +<refentry id="tdbtool.8"> + +<refmeta> + <refentrytitle>tdbtool</refentrytitle> + <manvolnum>8</manvolnum> + <refmiscinfo class="source">Samba</refmiscinfo> + <refmiscinfo class="manual">System Administration tools</refmiscinfo> + <refmiscinfo class="version">3.5</refmiscinfo> +</refmeta> + + +<refnamediv> + <refname>tdbtool</refname> + <refpurpose>manipulate the contents TDB files</refpurpose> +</refnamediv> + +<refsynopsisdiv> + + <cmdsynopsis> + <command>tdbtool</command> + </cmdsynopsis> + + <cmdsynopsis> + <command>tdbtool</command> + <arg choice="plain"> + <replaceable>TDBFILE</replaceable> + </arg> + <arg rep="repeat" choice="opt"> + <replaceable>COMMANDS</replaceable> + </arg> + </cmdsynopsis> + +</refsynopsisdiv> + +<refsect1> + <title>DESCRIPTION</title> + + <para>This tool is part of the + <citerefentry><refentrytitle>samba</refentrytitle> + <manvolnum>1</manvolnum></citerefentry> suite.</para> + + <para><command>tdbtool</command> a tool for displaying and + altering the contents of Samba TDB (Trivial DataBase) files. Each + of the commands listed below can be entered interactively or + provided on the command line.</para> + +</refsect1> + + +<refsect1> + <title>COMMANDS</title> + + <variablelist> + + <varlistentry> + <term><option>create</option> + <replaceable>TDBFILE</replaceable></term> + <listitem><para>Create a new database named + <replaceable>TDBFILE</replaceable>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>open</option> + <replaceable>TDBFILE</replaceable></term> + <listitem><para>Open an existing database named + <replaceable>TDBFILE</replaceable>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>erase</option></term> + <listitem><para>Erase the current database. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>dump</option></term> + <listitem><para>Dump the current database as strings. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>cdump</option></term> + <listitem><para>Dump the current database as connection records. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>keys</option></term> + <listitem><para>Dump the current database keys as strings. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>hexkeys</option></term> + <listitem><para>Dump the current database keys as hex values. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>info</option></term> + <listitem><para>Print summary information about the + current database. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>insert</option> + <replaceable>KEY</replaceable> + <replaceable>DATA</replaceable> + </term> + <listitem><para>Insert a record into the + current database. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>move</option> + <replaceable>KEY</replaceable> + <replaceable>TDBFILE</replaceable> + </term> + <listitem><para>Move a record from the + current database into <replaceable>TDBFILE</replaceable>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>store</option> + <replaceable>KEY</replaceable> + <replaceable>DATA</replaceable> + </term> + <listitem><para>Store (replace) a record in the + current database. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>show</option> + <replaceable>KEY</replaceable> + </term> + <listitem><para>Show a record by key. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>delete</option> + <replaceable>KEY</replaceable> + </term> + <listitem><para>Delete a record by key. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>list</option> + </term> + <listitem><para>Print the current database hash table and free list. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>free</option> + </term> + <listitem><para>Print the current database and free list. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>!</option> + <replaceable>COMMAND</replaceable> + </term> + <listitem><para>Execute the given system command. + </para></listitem> + </varlistentry> + + <varlistentry> + <term> + <option>first</option> + </term> + <listitem><para>Print the first record in the current database. + </para></listitem> + </varlistentry> + + <varlistentry> + <term> + <option>next</option> + </term> + <listitem><para>Print the next record in the current database. + </para></listitem> + </varlistentry> + + <varlistentry> + <term> + <option>check</option> + </term> + <listitem><para>Check the integrity of the current database. + </para></listitem> + </varlistentry> + + <varlistentry> + <term> + <option>quit</option> + </term> + <listitem><para>Exit <command>tdbtool</command>. + </para></listitem> + </varlistentry> + + </variablelist> +</refsect1> + +<refsect1> + <title>CAVEATS</title> + <para>The contents of the Samba TDB files are private + to the implementation and should not be altered with + <command>tdbtool</command>. + </para> +</refsect1> + +<refsect1> + <title>VERSION</title> + <para>This man page is correct for version 3.0.25 of the Samba suite.</para> +</refsect1> + +<refsect1> + <title>AUTHOR</title> + + <para> The original Samba software and related utilities were + created by Andrew Tridgell. Samba is now developed by the + Samba Team as an Open Source project similar to the way the + Linux kernel is developed.</para> +</refsect1> + +</refentry> diff --git a/lib/tdb/pytdb.c b/lib/tdb/pytdb.c index 159bc4dce5..202dca1571 100644 --- a/lib/tdb/pytdb.c +++ b/lib/tdb/pytdb.c @@ -1,7 +1,7 @@ /* Unix SMB/CIFS implementation. - Swig interface to tdb. + Python interface to tdb. Copyright (C) 2004-2006 Tim Potter <tpot@samba.org> Copyright (C) 2007-2008 Jelmer Vernooij <jelmer@samba.org> @@ -337,7 +337,7 @@ static PyMethodDef tdb_object_methods[] = { { "read_lock_all", (PyCFunction)obj_lockall_read, METH_NOARGS, NULL }, { "read_unlock_all", (PyCFunction)obj_unlockall_read, METH_NOARGS, NULL }, { "close", (PyCFunction)obj_close, METH_NOARGS, NULL }, - { "get", (PyCFunction)obj_get, METH_VARARGS, "S.fetch(key) -> value\n" + { "get", (PyCFunction)obj_get, METH_VARARGS, "S.get(key) -> value\n" "Fetch a value." }, { "append", (PyCFunction)obj_append, METH_VARARGS, "S.append(key, value) -> None\n" "Append data to an existing key." }, diff --git a/lib/tdb/python/tests/simple.py b/lib/tdb/python/tests/simple.py index d242e665be..c7443c0d43 100644 --- a/lib/tdb/python/tests/simple.py +++ b/lib/tdb/python/tests/simple.py @@ -15,6 +15,15 @@ class OpenTdbTests(TestCase): def test_nonexistant_read(self): self.assertRaises(IOError, tdb.Tdb, "/some/nonexistant/file", 0, tdb.DEFAULT, os.O_RDWR) +class CloseTdbTests(TestCase): + def test_double_close(self): + self.tdb = tdb.Tdb(tempfile.mkstemp()[1], 0, tdb.DEFAULT, os.O_CREAT|os.O_RDWR) + self.assertNotEqual(None, self.tdb) + + # ensure that double close does not crash python + self.tdb.close() + self.tdb.close() + class SimpleTdbTests(TestCase): def setUp(self): diff --git a/lib/tdb/release-script.sh b/lib/tdb/release-script.sh index ddeb753b97..273ca30be8 100755 --- a/lib/tdb/release-script.sh +++ b/lib/tdb/release-script.sh @@ -13,7 +13,7 @@ fi git clean -f -x -d lib/tdb git clean -f -x -d lib/replace -curbranch=`git-branch |grep "^*" | tr -d "* "` +curbranch=`git branch |grep "^*" | tr -d "* "` version=$1 strver=`echo ${version} | tr "." "-"` diff --git a/lib/tdb/rules.mk b/lib/tdb/rules.mk index 73ab771c5c..023e0ce534 100644 --- a/lib/tdb/rules.mk +++ b/lib/tdb/rules.mk @@ -1,8 +1,3 @@ -.SUFFIXES: .i _wrap.c - -.i_wrap.c: - $(SWIG) -O -Wall -python -keyword $< - showflags:: @echo 'tdb will be compiled with flags:' @echo ' CFLAGS = $(CFLAGS)' diff --git a/lib/tdb/tdb.mk b/lib/tdb/tdb.mk index 267c2d1c85..ecc6f9fd08 100644 --- a/lib/tdb/tdb.mk +++ b/lib/tdb/tdb.mk @@ -51,7 +51,20 @@ tdb.$(SHLIBEXT): libtdb.$(SHLIBEXT) pytdb.o $(SHLD) $(SHLD_FLAGS) -o $@ pytdb.o -L. -ltdb `$(PYTHON_CONFIG) --ldflags` install:: installdirs installbin installheaders installlibs \ - $(PYTHON_INSTALL_TARGET) + $(PYTHON_INSTALL_TARGET) installdocs + +doc:: manpages/tdbbackup.8 manpages/tdbdump.8 manpages/tdbtool.8 + +.SUFFIXES: .8.xml .8 + +.8.xml.8: + -test -z "$(XSLTPROC)" || $(XSLTPROC) -o $@ http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl $< + +installdocs:: + ${INSTALLCMD} -d $(DESTDIR)$(mandir)/man8 + for I in manpages/*.8; do \ + ${INSTALLCMD} -m 644 $$I $(DESTDIR)$(mandir)/man8; \ + done install-python:: build-python mkdir -p $(DESTDIR)`$(PYTHON) -c "import distutils.sysconfig; print distutils.sysconfig.get_python_lib(1, prefix='$(prefix)')"` @@ -78,6 +91,10 @@ installheaders:: installdirs installlibs:: all installdirs cp tdb.pc $(DESTDIR)$(libdir)/pkgconfig cp $(TDB_STLIB) $(TDB_SOLIB) $(DESTDIR)$(libdir) + rm -f $(DESTDIR)$(libdir)/libtdb.$(SHLIBEXT) + ln -s $(TDB_SOLIB) $(DESTDIR)$(libdir)/libtdb.$(SHLIBEXT) + rm -f $(DESTDIR)$(libdir)/$(TDB_SONAME) + ln -s $(TDB_SOLIB) $(DESTDIR)$(libdir)/$(TDB_SONAME) $(TDB_STLIB): $(TDB_OBJ) ar -rv $(TDB_STLIB) $(TDB_OBJ) diff --git a/lib/tdb/tools/tdbdump.c b/lib/tdb/tools/tdbdump.c index 8d930383b0..027fda3d42 100644 --- a/lib/tdb/tools/tdbdump.c +++ b/lib/tdb/tools/tdbdump.c @@ -65,8 +65,8 @@ static int dump_tdb(const char *fname, const char *keyname) if (!keyname) { tdb_traverse(tdb, traverse_fn, NULL); } else { - key.dptr = discard_const_p(uint8_t,keyname); - key.dsize = strlen( keyname); + key.dptr = discard_const_p(uint8_t, keyname); + key.dsize = strlen(keyname); value = tdb_fetch(tdb, key); if (!value.dptr) { return 1; diff --git a/lib/tdb/tools/tdbtool.c b/lib/tdb/tools/tdbtool.c index d646515a04..2ba7efc8ab 100644 --- a/lib/tdb/tools/tdbtool.c +++ b/lib/tdb/tools/tdbtool.c @@ -419,6 +419,7 @@ static void info_tdb(void) static void speed_tdb(const char *tlimit) { + const char *str = "store test", *str2 = "transaction test"; unsigned timelimit = tlimit?atoi(tlimit):0; double t; int ops; @@ -430,9 +431,9 @@ static void speed_tdb(const char *tlimit) do { long int r = random(); TDB_DATA key, dbuf; - key.dptr = (unsigned char *)"store test"; + key.dptr = discard_const_p(uint8_t, str); key.dsize = strlen((char *)key.dptr); - dbuf.dptr = (unsigned char *)&r; + dbuf.dptr = (uint8_t *) &r; dbuf.dsize = sizeof(r); tdb_store(tdb, key, dbuf, TDB_REPLACE); t = _end_timer(); @@ -446,9 +447,9 @@ static void speed_tdb(const char *tlimit) do { long int r = random(); TDB_DATA key, dbuf; - key.dptr = (unsigned char *)"store test"; + key.dptr = discard_const_p(uint8_t, str); key.dsize = strlen((char *)key.dptr); - dbuf.dptr = (unsigned char *)&r; + dbuf.dptr = (uint8_t *) &r; dbuf.dsize = sizeof(r); tdb_fetch(tdb, key); t = _end_timer(); @@ -462,9 +463,9 @@ static void speed_tdb(const char *tlimit) do { long int r = random(); TDB_DATA key, dbuf; - key.dptr = (unsigned char *)"transaction test"; + key.dptr = discard_const_p(uint8_t, str2); key.dsize = strlen((char *)key.dptr); - dbuf.dptr = (unsigned char *)&r; + dbuf.dptr = (uint8_t *) &r; dbuf.dsize = sizeof(r); tdb_transaction_start(tdb); tdb_store(tdb, key, dbuf, TDB_REPLACE); @@ -537,9 +538,9 @@ static void next_record(TDB_CONTEXT *the_tdb, TDB_DATA *pkey) print_rec(the_tdb, *pkey, dbuf, NULL); } -static int count(TDB_DATA key, TDB_DATA data, void *private) +static int count(TDB_DATA key, TDB_DATA data, void *private_data) { - (*(unsigned int *)private)++; + (*(unsigned int *)private_data)++; return 0; } diff --git a/lib/tevent/tevent.mk b/lib/tevent/tevent.mk index 694d082c4a..57bfd81222 100644 --- a/lib/tevent/tevent.mk +++ b/lib/tevent/tevent.mk @@ -26,6 +26,10 @@ installheaders:: installdirs installlibs:: installdirs cp tevent.pc $(DESTDIR)$(libdir)/pkgconfig cp $(TEVENT_STLIB) $(TEVENT_SOLIB) $(DESTDIR)$(libdir) + rm -f $(DESTDIR)$(libdir)/$(TEVENT_SONAME) + ln -s $(TEVENT_SOLIB) $(DESTDIR)$(libdir)/$(TEVENT_SONAME) + rm -f $(DESTDIR)$(libdir)/$(TEVENT_SOBASE) + ln -s $(TEVENT_SOLIB) $(DESTDIR)$(libdir)/$(TEVENT_SOBASE) install:: all installdirs installheaders installlibs $(PYTHON_INSTALL_TARGET) diff --git a/lib/tevent/tevent_signal.c b/lib/tevent/tevent_signal.c index ab170a66cf..0f3d83e877 100644 --- a/lib/tevent/tevent_signal.c +++ b/lib/tevent/tevent_signal.c @@ -30,23 +30,23 @@ #include "tevent_internal.h" #include "tevent_util.h" -#define NUM_SIGNALS 64 +#define TEVENT_NUM_SIGNALS 64 /* maximum number of SA_SIGINFO signals to hold in the queue. NB. This *MUST* be a power of 2, in order for the ring buffer wrap to work correctly. Thanks to Petr Vandrovec <petr@vandrovec.name> for this. */ -#define SA_INFO_QUEUE_COUNT 64 +#define TEVENT_SA_INFO_QUEUE_COUNT 64 -struct sigcounter { +struct tevent_sigcounter { uint32_t count; uint32_t seen; }; -#define SIG_INCREMENT(s) (s).count++ -#define SIG_SEEN(s, n) (s).seen += (n) -#define SIG_PENDING(s) ((s).seen != (s).count) +#define TEVENT_SIG_INCREMENT(s) (s).count++ +#define TEVENT_SIG_SEEN(s, n) (s).seen += (n) +#define TEVENT_SIG_PENDING(s) ((s).seen != (s).count) struct tevent_common_signal_list { struct tevent_common_signal_list *prev, *next; @@ -56,22 +56,22 @@ struct tevent_common_signal_list { /* the poor design of signals means that this table must be static global */ -static struct sig_state { - struct tevent_common_signal_list *sig_handlers[NUM_SIGNALS+1]; - struct sigaction *oldact[NUM_SIGNALS+1]; - struct sigcounter signal_count[NUM_SIGNALS+1]; - struct sigcounter got_signal; +static struct tevent_sig_state { + struct tevent_common_signal_list *sig_handlers[TEVENT_NUM_SIGNALS+1]; + struct sigaction *oldact[TEVENT_NUM_SIGNALS+1]; + struct tevent_sigcounter signal_count[TEVENT_NUM_SIGNALS+1]; + struct tevent_sigcounter got_signal; #ifdef SA_SIGINFO /* with SA_SIGINFO we get quite a lot of info per signal */ - siginfo_t *sig_info[NUM_SIGNALS+1]; - struct sigcounter sig_blocked[NUM_SIGNALS+1]; + siginfo_t *sig_info[TEVENT_NUM_SIGNALS+1]; + struct tevent_sigcounter sig_blocked[TEVENT_NUM_SIGNALS+1]; #endif } *sig_state; /* return number of sigcounter events not processed yet */ -static uint32_t sig_count(struct sigcounter s) +static uint32_t tevent_sig_count(struct tevent_sigcounter s) { return s.count - s.seen; } @@ -87,8 +87,8 @@ static void tevent_common_signal_handler(int signum) struct tevent_context *ev = NULL; int saved_errno = errno; - SIG_INCREMENT(sig_state->signal_count[signum]); - SIG_INCREMENT(sig_state->got_signal); + TEVENT_SIG_INCREMENT(sig_state->signal_count[signum]); + TEVENT_SIG_INCREMENT(sig_state->got_signal); /* Write to each unique event context. */ for (sl = sig_state->sig_handlers[signum]; sl; sl = sl->next) { @@ -109,24 +109,24 @@ static void tevent_common_signal_handler(int signum) static void tevent_common_signal_handler_info(int signum, siginfo_t *info, void *uctx) { - uint32_t count = sig_count(sig_state->signal_count[signum]); - /* sig_state->signal_count[signum].seen % SA_INFO_QUEUE_COUNT + uint32_t count = tevent_sig_count(sig_state->signal_count[signum]); + /* sig_state->signal_count[signum].seen % TEVENT_SA_INFO_QUEUE_COUNT * is the base of the unprocessed signals in the ringbuffer. */ uint32_t ofs = (sig_state->signal_count[signum].seen + count) % - SA_INFO_QUEUE_COUNT; + TEVENT_SA_INFO_QUEUE_COUNT; sig_state->sig_info[signum][ofs] = *info; tevent_common_signal_handler(signum); /* handle SA_SIGINFO */ - if (count+1 == SA_INFO_QUEUE_COUNT) { + if (count+1 == TEVENT_SA_INFO_QUEUE_COUNT) { /* we've filled the info array - block this signal until these ones are delivered */ sigset_t set; sigemptyset(&set); sigaddset(&set, signum); sigprocmask(SIG_BLOCK, &set, NULL); - SIG_INCREMENT(sig_state->sig_blocked[signum]); + TEVENT_SIG_INCREMENT(sig_state->sig_blocked[signum]); } } #endif @@ -196,7 +196,7 @@ struct tevent_signal *tevent_common_add_signal(struct tevent_context *ev, struct tevent_common_signal_list *sl; sigset_t set, oldset; - if (signum >= NUM_SIGNALS) { + if (signum >= TEVENT_NUM_SIGNALS) { errno = EINVAL; return NULL; } @@ -204,7 +204,7 @@ struct tevent_signal *tevent_common_add_signal(struct tevent_context *ev, /* the sig_state needs to be on a global context as it can last across multiple event contexts */ if (sig_state == NULL) { - sig_state = talloc_zero(talloc_autofree_context(), struct sig_state); + sig_state = talloc_zero(talloc_autofree_context(), struct tevent_sig_state); if (sig_state == NULL) { return NULL; } @@ -267,7 +267,9 @@ struct tevent_signal *tevent_common_add_signal(struct tevent_context *ev, act.sa_handler = NULL; act.sa_sigaction = tevent_common_signal_handler_info; if (sig_state->sig_info[signum] == NULL) { - sig_state->sig_info[signum] = talloc_zero_array(sig_state, siginfo_t, SA_INFO_QUEUE_COUNT); + sig_state->sig_info[signum] = + talloc_zero_array(sig_state, siginfo_t, + TEVENT_SA_INFO_QUEUE_COUNT); if (sig_state->sig_info[signum] == NULL) { talloc_free(se); return NULL; @@ -310,14 +312,14 @@ int tevent_common_check_signal(struct tevent_context *ev) { int i; - if (!sig_state || !SIG_PENDING(sig_state->got_signal)) { + if (!sig_state || !TEVENT_SIG_PENDING(sig_state->got_signal)) { return 0; } - for (i=0;i<NUM_SIGNALS+1;i++) { + for (i=0;i<TEVENT_NUM_SIGNALS+1;i++) { struct tevent_common_signal_list *sl, *next; - struct sigcounter counter = sig_state->signal_count[i]; - uint32_t count = sig_count(counter); + struct tevent_sigcounter counter = sig_state->signal_count[i]; + uint32_t count = tevent_sig_count(counter); #ifdef SA_SIGINFO /* Ensure we null out any stored siginfo_t entries * after processing for debugging purposes. */ @@ -338,11 +340,11 @@ int tevent_common_check_signal(struct tevent_context *ev) for (j=0;j<count;j++) { /* sig_state->signal_count[i].seen - * % SA_INFO_QUEUE_COUNT is + * % TEVENT_SA_INFO_QUEUE_COUNT is * the base position of the unprocessed * signals in the ringbuffer. */ uint32_t ofs = (counter.seen + j) - % SA_INFO_QUEUE_COUNT; + % TEVENT_SA_INFO_QUEUE_COUNT; se->handler(ev, se, i, 1, (void*)&sig_state->sig_info[i][ofs], se->private_data); @@ -364,7 +366,7 @@ int tevent_common_check_signal(struct tevent_context *ev) uint32_t j; for (j=0;j<count;j++) { uint32_t ofs = (counter.seen + j) - % SA_INFO_QUEUE_COUNT; + % TEVENT_SA_INFO_QUEUE_COUNT; memset((void*)&sig_state->sig_info[i][ofs], '\0', sizeof(siginfo_t)); @@ -372,23 +374,23 @@ int tevent_common_check_signal(struct tevent_context *ev) } #endif - SIG_SEEN(sig_state->signal_count[i], count); - SIG_SEEN(sig_state->got_signal, count); + TEVENT_SIG_SEEN(sig_state->signal_count[i], count); + TEVENT_SIG_SEEN(sig_state->got_signal, count); #ifdef SA_SIGINFO - if (SIG_PENDING(sig_state->sig_blocked[i])) { + if (TEVENT_SIG_PENDING(sig_state->sig_blocked[i])) { /* We'd filled the queue, unblock the signal now the queue is empty again. Note we MUST do this after the - SIG_SEEN(sig_state->signal_count[i], count) + TEVENT_SIG_SEEN(sig_state->signal_count[i], count) call to prevent a new signal running out of room in the sig_state->sig_info[i][] ring buffer. */ sigset_t set; sigemptyset(&set); sigaddset(&set, i); - SIG_SEEN(sig_state->sig_blocked[i], - sig_count(sig_state->sig_blocked[i])); + TEVENT_SIG_SEEN(sig_state->sig_blocked[i], + tevent_sig_count(sig_state->sig_blocked[i])); sigprocmask(SIG_UNBLOCK, &set, NULL); } #endif diff --git a/lib/tsocket/tsocket.c b/lib/tsocket/tsocket.c index 55f1af3894..b8dd6c8936 100644 --- a/lib/tsocket/tsocket.c +++ b/lib/tsocket/tsocket.c @@ -3,7 +3,7 @@ Copyright (C) Stefan Metzmacher 2009 - ** NOTE! The following LGPL license applies to the tevent + ** NOTE! The following LGPL license applies to the tsocket ** library. This does NOT imply that all of Samba is released ** under the LGPL diff --git a/lib/tsocket/tsocket.h b/lib/tsocket/tsocket.h index ae73113b5a..7e9cf9eb19 100644 --- a/lib/tsocket/tsocket.h +++ b/lib/tsocket/tsocket.h @@ -3,7 +3,7 @@ Copyright (C) Stefan Metzmacher 2009 - ** NOTE! The following LGPL license applies to the tevent + ** NOTE! The following LGPL license applies to the tsocket ** library. This does NOT imply that all of Samba is released ** under the LGPL @@ -179,6 +179,21 @@ int _tstream_unix_socketpair(TALLOC_CTX *mem_ctx1, _tstream_unix_socketpair(mem_ctx1, stream1, mem_ctx2, stream2, \ __location__) +struct sockaddr; + +int _tsocket_address_bsd_from_sockaddr(TALLOC_CTX *mem_ctx, + struct sockaddr *sa, + size_t sa_socklen, + struct tsocket_address **_addr, + const char *location); +#define tsocket_address_bsd_from_sockaddr(mem_ctx, sa, sa_socklen, _addr) \ + _tsocket_address_bsd_from_sockaddr(mem_ctx, sa, sa_socklen, _addr, \ + __location__) + +ssize_t tsocket_address_bsd_sockaddr(const struct tsocket_address *addr, + struct sockaddr *sa, + size_t sa_socklen); + int _tstream_bsd_existing_socket(TALLOC_CTX *mem_ctx, int fd, struct tstream_context **_stream, diff --git a/lib/tsocket/tsocket_bsd.c b/lib/tsocket/tsocket_bsd.c index 05f5be19cb..1c1e58099b 100644 --- a/lib/tsocket/tsocket_bsd.c +++ b/lib/tsocket/tsocket_bsd.c @@ -3,7 +3,7 @@ Copyright (C) Stefan Metzmacher 2009 - ** NOTE! The following LGPL license applies to the tevent + ** NOTE! The following LGPL license applies to the tsocket ** library. This does NOT imply that all of Samba is released ** under the LGPL @@ -201,11 +201,11 @@ struct tsocket_address_bsd { } u; }; -static int _tsocket_address_bsd_from_sockaddr(TALLOC_CTX *mem_ctx, - struct sockaddr *sa, - socklen_t sa_socklen, - struct tsocket_address **_addr, - const char *location) +int _tsocket_address_bsd_from_sockaddr(TALLOC_CTX *mem_ctx, + struct sockaddr *sa, + size_t sa_socklen, + struct tsocket_address **_addr, + const char *location) { struct tsocket_address *addr; struct tsocket_address_bsd *bsda; @@ -259,6 +259,50 @@ static int _tsocket_address_bsd_from_sockaddr(TALLOC_CTX *mem_ctx, return 0; } +ssize_t tsocket_address_bsd_sockaddr(const struct tsocket_address *addr, + struct sockaddr *sa, + size_t sa_socklen) +{ + struct tsocket_address_bsd *bsda = talloc_get_type(addr->private_data, + struct tsocket_address_bsd); + ssize_t rlen = 0; + + if (!bsda) { + errno = EINVAL; + return -1; + } + + switch (bsda->u.sa.sa_family) { + case AF_UNIX: + rlen = sizeof(struct sockaddr_un); + break; + case AF_INET: + rlen = sizeof(struct sockaddr_in); + break; +#ifdef HAVE_IPV6 + case AF_INET6: + rlen = sizeof(struct sockaddr_in6); + break; +#endif + default: + errno = EAFNOSUPPORT; + return -1; + } + + if (sa_socklen < rlen) { + errno = EINVAL; + return -1; + } + + if (sa_socklen > sizeof(struct sockaddr_storage)) { + memset(sa, 0, sa_socklen); + sa_socklen = sizeof(struct sockaddr_storage); + } + + memcpy(sa, &bsda->u.ss, sa_socklen); + return rlen; +} + int _tsocket_address_inet_from_strings(TALLOC_CTX *mem_ctx, const char *fam, const char *addr, diff --git a/lib/tsocket/tsocket_guide.txt b/lib/tsocket/tsocket_guide.txt index ed903c6027..dfe2dd44e1 100644 --- a/lib/tsocket/tsocket_guide.txt +++ b/lib/tsocket/tsocket_guide.txt @@ -32,15 +32,15 @@ endpoint for debugging. Callers should not try to parse the string! The should use additional methods of the specific tsocket_address implemention to get more details. - char *tsocket_address_string(const struct tsocket_address *addr, - TALLOC_CTX *mem_ctx); + char *tsocket_address_string(const struct tsocket_address *addr, + TALLOC_CTX *mem_ctx); There's a function to create a copy of the tsocket_address. This is useful when before doing modifications to a socket via additional methods of the specific tsocket_address implementation. - struct tsocket_address *tsocket_address_copy(const struct tsocket_address *addr, - TALLOC_CTX *mem_ctx); + struct tsocket_address *tsocket_address_copy(const struct tsocket_address *addr, + TALLOC_CTX *mem_ctx); The tdgram_context abstraction ============================== @@ -58,23 +58,24 @@ when a datagram is available or an error happened. The callback is then supposed to get the result by calling tdgram_recvfrom_recv() on the 'tevent_req'. It returns -1 -and sets *perrno to the actual 'errno' on failure. +and sets '*perrno' to the actual 'errno' on failure. Otherwise it returns the length of the datagram -(0 is never returned!). *buf will contain the buffer of the -datagram and *src the abstracted tsocket_address of the sender +(0 is never returned!). '*buf' will contain the buffer of the +datagram and '*src' the abstracted tsocket_address of the sender of the received datagram. The caller can only have one outstanding tdgram_recvfrom_send() -at a time otherwise the caller will get *perrno = EBUSY. +at a time otherwise the caller will get '*perrno = EBUSY'. + + struct tevent_req *tdgram_recvfrom_send(TALLOC_CTX *mem_ctx, + struct tevent_context *ev, + struct tdgram_context *dgram); -struct tevent_req *tdgram_recvfrom_send(TALLOC_CTX *mem_ctx, - struct tevent_context *ev, - struct tdgram_context *dgram); -ssize_t tdgram_recvfrom_recv(struct tevent_req *req, - int *perrno, - TALLOC_CTX *mem_ctx, - uint8_t **buf, - struct tsocket_address **src); + ssize_t tdgram_recvfrom_recv(struct tevent_req *req, + int *perrno, + TALLOC_CTX *mem_ctx, + uint8_t **buf, + struct tsocket_address **src); The tdgram_sendto_send() method can be called to send a datagram (specified by a buf/len) to a destination endpoint @@ -86,35 +87,37 @@ has delivered the datagram to the "wire". The callback is then supposed to get the result by calling tdgram_sendto_recv() on the 'tevent_req'. It returns -1 -and sets *perrno to the actual 'errno' on failure. +and sets '*perrno' to the actual 'errno' on failure. Otherwise it returns the length of the datagram (0 is never returned!). The caller can only have one outstanding tdgram_sendto_send() -at a time otherwise the caller will get *perrno = EBUSY. +at a time otherwise the caller will get '*perrno = EBUSY'. -struct tevent_req *tdgram_sendto_send(TALLOC_CTX *mem_ctx, - struct tevent_context *ev, - struct tdgram_context *dgram, - const uint8_t *buf, size_t len, - const struct tsocket_address *dst); -ssize_t tdgram_sendto_recv(struct tevent_req *req, - int *perrno); + struct tevent_req *tdgram_sendto_send(TALLOC_CTX *mem_ctx, + struct tevent_context *ev, + struct tdgram_context *dgram, + const uint8_t *buf, size_t len, + const struct tsocket_address *dst); + + ssize_t tdgram_sendto_recv(struct tevent_req *req, + int *perrno); The tdgram_disconnect_send() method should be used to normally shutdown/close the abstracted socket. The caller should make sure there're no outstanding tdgram_recvfrom_send() -and tdgram_sendto_send() calls otherwise the caller will get *perrno = EBUSY. +and tdgram_sendto_send() calls otherwise the caller will get '*perrno = EBUSY'. Note: you can always use talloc_free(tdgram) to cleanup the resources of the tdgram_context on a fatal error. -struct tevent_req *tdgram_disconnect_send(TALLOC_CTX *mem_ctx, - struct tevent_context *ev, - struct tdgram_context *dgram); -int tdgram_disconnect_recv(struct tevent_req *req, - int *perrno); + struct tevent_req *tdgram_disconnect_send(TALLOC_CTX *mem_ctx, + struct tevent_context *ev, + struct tdgram_context *dgram); + + int tdgram_disconnect_recv(struct tevent_req *req, + int *perrno); The tstream_context abstraction =============================== @@ -130,7 +133,7 @@ but not consumed yet. It returns -1 and sets 'errno' on failure. Otherwise it returns the number of uncomsumed bytes (it can return 0!). -ssize_t tstream_pending_bytes(struct tstream_context *stream); + ssize_t tstream_pending_bytes(struct tstream_context *stream); The tstream_readv_send() method can be called to read for a specific amount of bytes from the stream into the buffers @@ -144,20 +147,21 @@ filled with bytes from the socket or an error happened. The callback is then supposed to get the result by calling tstream_readv_recv() on the 'tevent_req'. It returns -1 -and sets *perrno to the actual 'errno' on failure. +and sets '*perrno' to the actual 'errno' on failure. Otherwise it returns the length of the datagram (0 is never returned!). The caller can only have one outstanding tstream_readv_send() at a time otherwise the caller will get *perrno = EBUSY. -struct tevent_req *tstream_readv_send(TALLOC_CTX *mem_ctx, - struct tevent_context *ev, - struct tstream_context *stream, - struct iovec *vector, - size_t count); -int tstream_readv_recv(struct tevent_req *req, - int *perrno); + struct tevent_req *tstream_readv_send(TALLOC_CTX *mem_ctx, + struct tevent_context *ev, + struct tstream_context *stream, + struct iovec *vector, + size_t count); + + int tstream_readv_recv(struct tevent_req *req, + int *perrno); The tstream_writev_send() method can be called to write buffers in the given iovec vector into the stream socket. @@ -169,35 +173,37 @@ has delivered the all buffers to the "wire". The callback is then supposed to get the result by calling tstream_writev_recv() on the 'tevent_req'. It returns -1 -and sets *perrno to the actual 'errno' on failure. +and sets '*perrno' to the actual 'errno' on failure. Otherwise it returns the total amount of bytes sent. (0 is never returned!). The caller can only have one outstanding tstream_writev_send() -at a time otherwise the caller will get *perrno = EBUSY. +at a time otherwise the caller will get '*perrno = EBUSY'. -struct tevent_req *tstream_writev_send(TALLOC_CTX *mem_ctx, - struct tevent_context *ev, - struct tstream_context *stream, - const struct iovec *vector, - size_t count); -int tstream_writev_recv(struct tevent_req *req, - int *perrno); + struct tevent_req *tstream_writev_send(TALLOC_CTX *mem_ctx, + struct tevent_context *ev, + struct tstream_context *stream, + const struct iovec *vector, + size_t count); + + int tstream_writev_recv(struct tevent_req *req, + int *perrno); The tstream_disconnect_send() method should be used to normally shutdown/close the abstracted socket. The caller should make sure there're no outstanding tstream_readv_send() -and tstream_writev_send() calls otherwise the caller will get *perrno = EBUSY. +and tstream_writev_send() calls otherwise the caller will get '*perrno = EBUSY'. Note: you can always use talloc_free(tstream) to cleanup the resources of the tstream_context on a fatal error. -struct tevent_req *tstream_disconnect_send(TALLOC_CTX *mem_ctx, - struct tevent_context *ev, - struct tstream_context *stream); -int tstream_disconnect_recv(struct tevent_req *req, - int *perrno); + struct tevent_req *tstream_disconnect_send(TALLOC_CTX *mem_ctx, + struct tevent_context *ev, + struct tstream_context *stream); + + int tstream_disconnect_recv(struct tevent_req *req, + int *perrno); PDU receive helper functions ============================ @@ -221,17 +227,19 @@ and it's private state. See the 'dcerpc_read_ncacn_packet_send/recv' functions in Samba as an example. -typedef int (*tstream_readv_pdu_next_vector_t)(struct tstream_context *stream, - void *private_data, - TALLOC_CTX *mem_ctx, - struct iovec **vector, - size_t *count); -struct tevent_req *tstream_readv_pdu_send(TALLOC_CTX *mem_ctx, - struct tevent_context *ev, - struct tstream_context *stream, - tstream_readv_pdu_next_vector_t next_vector_fn, - void *next_vector_private); -int tstream_readv_pdu_recv(struct tevent_req *req, int *perrno); + typedef int (*tstream_readv_pdu_next_vector_t)(struct tstream_context *stream, + void *private_data, + TALLOC_CTX *mem_ctx, + struct iovec **vector, + size_t *count); + + struct tevent_req *tstream_readv_pdu_send(TALLOC_CTX *mem_ctx, + struct tevent_context *ev, + struct tstream_context *stream, + tstream_readv_pdu_next_vector_t next_vector_fn, + void *next_vector_private); + + int tstream_readv_pdu_recv(struct tevent_req *req, int *perrno); Async 'tevent_queue' based helper functions =========================================== @@ -245,30 +253,33 @@ There're some helpers using 'tevent_queue' to make it easier for callers. The functions just get a 'queue' argument and serialize the operations. -struct tevent_req *tdgram_sendto_queue_send(TALLOC_CTX *mem_ctx, - struct tevent_context *ev, - struct tdgram_context *dgram, - struct tevent_queue *queue, - const uint8_t *buf, - size_t len, - struct tsocket_address *dst); -ssize_t tdgram_sendto_queue_recv(struct tevent_req *req, int *perrno); - -struct tevent_req *tstream_readv_pdu_queue_send(TALLOC_CTX *mem_ctx, - struct tevent_context *ev, - struct tstream_context *stream, - struct tevent_queue *queue, - tstream_readv_pdu_next_vector_t next_vector_fn, - void *next_vector_private); -int tstream_readv_pdu_queue_recv(struct tevent_req *req, int *perrno); - -struct tevent_req *tstream_writev_queue_send(TALLOC_CTX *mem_ctx, - struct tevent_context *ev, - struct tstream_context *stream, - struct tevent_queue *queue, - const struct iovec *vector, - size_t count); -int tstream_writev_queue_recv(struct tevent_req *req, int *perrno); + struct tevent_req *tdgram_sendto_queue_send(TALLOC_CTX *mem_ctx, + struct tevent_context *ev, + struct tdgram_context *dgram, + struct tevent_queue *queue, + const uint8_t *buf, + size_t len, + struct tsocket_address *dst); + + ssize_t tdgram_sendto_queue_recv(struct tevent_req *req, int *perrno); + + struct tevent_req *tstream_readv_pdu_queue_send(TALLOC_CTX *mem_ctx, + struct tevent_context *ev, + struct tstream_context *stream, + struct tevent_queue *queue, + tstream_readv_pdu_next_vector_t next_vector_fn, + void *next_vector_private); + + int tstream_readv_pdu_queue_recv(struct tevent_req *req, int *perrno); + + struct tevent_req *tstream_writev_queue_send(TALLOC_CTX *mem_ctx, + struct tevent_context *ev, + struct tstream_context *stream, + struct tevent_queue *queue, + const struct iovec *vector, + size_t count); + + int tstream_writev_queue_recv(struct tevent_req *req, int *perrno); BSD sockets: ipv4, ipv6 and unix ================================ @@ -286,26 +297,26 @@ ip address string based on the selected family which gets mapped to "0.0.0.0" or "::". It return -1 and set errno on error. Otherwise it returns 0. -int tsocket_address_inet_from_strings(TALLOC_CTX *mem_ctx, - const char *family, - const char *addr_string, - uint16_t port, - struct tsocket_address **addr); + int tsocket_address_inet_from_strings(TALLOC_CTX *mem_ctx, + const char *family, + const char *addr_string, + uint16_t port, + struct tsocket_address **addr); To get the ip address string of an existing 'inet' tsocket_address you can use the tsocket_address_inet_addr_string() function. It will return NULL and set errno to EINVAL if the tsocket_address doesn't represent an ipv4 or ipv6 endpoint address. -char *tsocket_address_inet_addr_string(const struct tsocket_address *addr, - TALLOC_CTX *mem_ctx); + char *tsocket_address_inet_addr_string(const struct tsocket_address *addr, + TALLOC_CTX *mem_ctx); To get the port number of an existing 'inet' tsocket_address you can use the tsocket_address_inet_port() function. It will return 0 and set errno to EINVAL if the tsocket_address doesn't represent an ipv4 or ipv6 endpoint address. -uint16_t tsocket_address_inet_port(const struct tsocket_address *addr); + uint16_t tsocket_address_inet_port(const struct tsocket_address *addr); To set the port number of an existing 'inet' tsocket_address you can use the tsocket_address_inet_set_port() function. @@ -313,8 +324,8 @@ It will return -1 and set errno to EINVAL if the tsocket_address doesn't represent an ipv4 or ipv6 endpoint address. It returns 0 on success. -int tsocket_address_inet_set_port(struct tsocket_address *addr, - uint16_t port); + int tsocket_address_inet_set_port(struct tsocket_address *addr, + uint16_t port); You can use the tsocket_address_unix_from_path() function to create a tsocket_address for unix domain @@ -324,17 +335,17 @@ the low level kernel supports the function will return -1 and set errno to ENAMETOOLONG. On success it returns 0. -int tsocket_address_unix_from_path(TALLOC_CTX *mem_ctx, - const char *path, - struct tsocket_address **addr); + int tsocket_address_unix_from_path(TALLOC_CTX *mem_ctx, + const char *path, + struct tsocket_address **addr); To get the path of an 'unix' tsocket_address you can use the tsocket_address_unix_path() function. It will return NULL and set errno to EINVAL if the tsocket_address doesn't represent an unix domain endpoint path. -char *tsocket_address_unix_path(const struct tsocket_address *addr, - TALLOC_CTX *mem_ctx); + char *tsocket_address_unix_path(const struct tsocket_address *addr, + TALLOC_CTX *mem_ctx); You can use tdgram_inet_udp_socket() to create a tdgram_context for ipv4 or ipv6 UDP communication. "local_address" has to be @@ -343,10 +354,10 @@ endpoint. "remote_address" can be NULL or an 'inet' tsocket_address presenting a remote endpoint. It returns -1 ans sets errno on error and it returns 0 on success. -int tdgram_inet_udp_socket(const struct tsocket_address *local_address, - const struct tsocket_address *remote_address, - TALLOC_CTX *mem_ctx, - struct tdgram_context **dgram); + int tdgram_inet_udp_socket(const struct tsocket_address *local_address, + const struct tsocket_address *remote_address, + TALLOC_CTX *mem_ctx, + struct tdgram_context **dgram); You can use tdgram_unix_socket() to create a tdgram_context for unix domain datagram communication. "local_address" has to be @@ -355,10 +366,10 @@ endpoint. "remote_address" can be NULL or an 'unix' tsocket_address presenting a remote endpoint. It returns -1 ans sets errno on error and it returns 0 on success. -int tdgram_unix_socket(const struct tsocket_address *local, - const struct tsocket_address *remote, - TALLOC_CTX *mem_ctx, - struct tdgram_context **dgram); + int tdgram_unix_socket(const struct tsocket_address *local, + const struct tsocket_address *remote, + TALLOC_CTX *mem_ctx, + struct tdgram_context **dgram); You can use tstream_inet_tcp_connect_send to async connect to a remote ipv4 or ipv6 TCP endpoint and create a @@ -372,18 +383,19 @@ or an error happened. The callback is then supposed to get the result by calling tstream_inet_tcp_connect_recv() on the 'tevent_req'. It returns -1 -and sets *perrno to the actual 'errno' on failure. +and sets '*perrno' to the actual 'errno' on failure. It returns 0 on success and returns the new tstream_context -in *stream. +in '*stream'. -struct tevent_req *tstream_inet_tcp_connect_send(TALLOC_CTX *mem_ctx, - struct tevent_context *ev, - const struct tsocket_address *local_address, - const struct tsocket_address *remote_address); -int tstream_inet_tcp_connect_recv(struct tevent_req *req, - int *perrno, - TALLOC_CTX *mem_ctx, - struct tstream_context **stream); + struct tevent_req *tstream_inet_tcp_connect_send(TALLOC_CTX *mem_ctx, + struct tevent_context *ev, + const struct tsocket_address *local_address, + const struct tsocket_address *remote_address); + + int tstream_inet_tcp_connect_recv(struct tevent_req *req, + int *perrno, + TALLOC_CTX *mem_ctx, + struct tstream_context **stream); You can use tstream_unix_connect_send to async connect to a unix domain endpoint and create a @@ -398,39 +410,62 @@ or an error happened. The callback is then supposed to get the result by calling tstream_unix_connect_recv() on the 'tevent_req'. It returns -1 -and sets *perrno to the actual 'errno' on failure. +and sets '*perrno' to the actual 'errno' on failure. It returns 0 on success and returns the new tstream_context -in *stream. +in '*stream'. + + struct tevent_req *tstream_unix_connect_send(TALLOC_CTX *mem_ctx, + struct tevent_context *ev, + const struct tsocket_address *local, + const struct tsocket_address *remote); -struct tevent_req *tstream_unix_connect_send(TALLOC_CTX *mem_ctx, - struct tevent_context *ev, - const struct tsocket_address *local, - const struct tsocket_address *remote); -int _tstream_unix_connect_recv(struct tevent_req *req, - int *perrno, - TALLOC_CTX *mem_ctx, - struct tstream_context **stream); + int _tstream_unix_connect_recv(struct tevent_req *req, + int *perrno, + TALLOC_CTX *mem_ctx, + struct tstream_context **stream); You can use tstream_unix_socketpair to create two connected 'unix' tsocket_contexts for the stream based communication. It returns -1 and sets errno on error and it returns 0 on success. -int tstream_unix_socketpair(TALLOC_CTX *mem_ctx1, - struct tstream_context **stream1, - TALLOC_CTX *mem_ctx2, - struct tstream_context **stream2); + int tstream_unix_socketpair(TALLOC_CTX *mem_ctx1, + struct tstream_context **stream1, + TALLOC_CTX *mem_ctx2, + struct tstream_context **stream2); + +In some situations it's needed to create a tsocket_address from +a given 'struct sockaddr'. You can use tsocket_address_bsd_from_sockaddr() +for that. This should only be used if really needed, because of +already existing fixed APIs. Only AF_INET, AF_INET6 and AF_UNIX +sockets are allowed. The function returns -1 and set errno on error. +Otherwise it returns 0. + + int tsocket_address_bsd_from_sockaddr(TALLOC_CTX *mem_ctx, + struct sockaddr *sa, + socklen_t sa_socklen, + struct tsocket_address **addr); + +In some situations it's needed to get a 'struct sockaddr' from a +given tsocket_address . You can use tsocket_address_bsd_sockaddr() +for that. This should only be used if really needed. Only AF_INET, +AF_INET6 and AF_UNIX are supported. It returns the size of '*sa' on +success, otherwise it returns -1 and sets 'errno'. + + ssize_t tsocket_address_bsd_sockaddr(const struct tsocket_address *addr, + struct sockaddr *sa, + socklen_t sa_socklen); In some situations it's needed to wrap existing file descriptors into the tstream abstraction. You can use tstream_bsd_existing_socket() for that. But you should read the tsocket_bsd.c code and unterstand it in order use this function. E.g. the fd has to be non blocking already. It will return -1 and set errno on error. Otherwise it returns 0 -and sets *stream to point to the new tstream_context. +and sets '*stream' to point to the new tstream_context. -int tstream_bsd_existing_socket(TALLOC_CTX *mem_ctx, - int fd, - struct tstream_context **stream); + int tstream_bsd_existing_socket(TALLOC_CTX *mem_ctx, + int fd, + struct tstream_context **stream); Virtual Sockets =============== diff --git a/lib/tsocket/tsocket_helpers.c b/lib/tsocket/tsocket_helpers.c index 6c673a354d..d8db864058 100644 --- a/lib/tsocket/tsocket_helpers.c +++ b/lib/tsocket/tsocket_helpers.c @@ -3,7 +3,7 @@ Copyright (C) Stefan Metzmacher 2009 - ** NOTE! The following LGPL license applies to the tevent + ** NOTE! The following LGPL license applies to the tsocket ** library. This does NOT imply that all of Samba is released ** under the LGPL diff --git a/lib/tsocket/tsocket_internal.h b/lib/tsocket/tsocket_internal.h index eba064cea5..154b2ce6f8 100644 --- a/lib/tsocket/tsocket_internal.h +++ b/lib/tsocket/tsocket_internal.h @@ -3,7 +3,7 @@ Copyright (C) Stefan Metzmacher 2009 - ** NOTE! The following LGPL license applies to the tevent + ** NOTE! The following LGPL license applies to the tsocket ** library. This does NOT imply that all of Samba is released ** under the LGPL diff --git a/librpc/gen_ndr/ndr_spoolss.c b/librpc/gen_ndr/ndr_spoolss.c index 4467087422..9cb83b50ea 100644 --- a/librpc/gen_ndr/ndr_spoolss.c +++ b/librpc/gen_ndr/ndr_spoolss.c @@ -6616,12 +6616,12 @@ static enum ndr_err_code ndr_push_spoolss_SetPrinterInfo2(struct ndr_push *ndr, NDR_CHECK(ndr_push_unique_ptr(ndr, r->drivername)); NDR_CHECK(ndr_push_unique_ptr(ndr, r->comment)); NDR_CHECK(ndr_push_unique_ptr(ndr, r->location)); - NDR_CHECK(ndr_push_unique_ptr(ndr, r->devmode)); + NDR_CHECK(ndr_push_uint32(ndr, NDR_SCALARS, r->devmode_ptr)); NDR_CHECK(ndr_push_unique_ptr(ndr, r->sepfile)); NDR_CHECK(ndr_push_unique_ptr(ndr, r->printprocessor)); NDR_CHECK(ndr_push_unique_ptr(ndr, r->datatype)); NDR_CHECK(ndr_push_unique_ptr(ndr, r->parameters)); - NDR_CHECK(ndr_push_unique_ptr(ndr, r->secdesc)); + NDR_CHECK(ndr_push_uint32(ndr, NDR_SCALARS, r->secdesc_ptr)); NDR_CHECK(ndr_push_spoolss_PrinterAttributes(ndr, NDR_SCALARS, r->attributes)); NDR_CHECK(ndr_push_uint32(ndr, NDR_SCALARS, r->priority)); NDR_CHECK(ndr_push_uint32(ndr, NDR_SCALARS, r->defaultpriority)); @@ -6675,14 +6675,6 @@ static enum ndr_err_code ndr_push_spoolss_SetPrinterInfo2(struct ndr_push *ndr, NDR_CHECK(ndr_push_uint3264(ndr, NDR_SCALARS, ndr_charset_length(r->location, CH_UTF16))); NDR_CHECK(ndr_push_charset(ndr, NDR_SCALARS, r->location, ndr_charset_length(r->location, CH_UTF16), sizeof(uint16_t), CH_UTF16)); } - if (r->devmode) { - { - struct ndr_push *_ndr_devmode; - NDR_CHECK(ndr_push_subcontext_start(ndr, &_ndr_devmode, 0, -1)); - NDR_CHECK(ndr_push_spoolss_DeviceMode(_ndr_devmode, NDR_SCALARS, r->devmode)); - NDR_CHECK(ndr_push_subcontext_end(ndr, _ndr_devmode, 0, -1)); - } - } if (r->sepfile) { NDR_CHECK(ndr_push_uint3264(ndr, NDR_SCALARS, ndr_charset_length(r->sepfile, CH_UTF16))); NDR_CHECK(ndr_push_uint3264(ndr, NDR_SCALARS, 0)); @@ -6707,14 +6699,6 @@ static enum ndr_err_code ndr_push_spoolss_SetPrinterInfo2(struct ndr_push *ndr, NDR_CHECK(ndr_push_uint3264(ndr, NDR_SCALARS, ndr_charset_length(r->parameters, CH_UTF16))); NDR_CHECK(ndr_push_charset(ndr, NDR_SCALARS, r->parameters, ndr_charset_length(r->parameters, CH_UTF16), sizeof(uint16_t), CH_UTF16)); } - if (r->secdesc) { - { - struct ndr_push *_ndr_secdesc; - NDR_CHECK(ndr_push_subcontext_start(ndr, &_ndr_secdesc, 0, -1)); - NDR_CHECK(ndr_push_security_descriptor(_ndr_secdesc, NDR_SCALARS|NDR_BUFFERS, r->secdesc)); - NDR_CHECK(ndr_push_subcontext_end(ndr, _ndr_secdesc, 0, -1)); - } - } } return NDR_ERR_SUCCESS; } @@ -6735,8 +6719,6 @@ static enum ndr_err_code ndr_pull_spoolss_SetPrinterInfo2(struct ndr_pull *ndr, TALLOC_CTX *_mem_save_comment_0; uint32_t _ptr_location; TALLOC_CTX *_mem_save_location_0; - uint32_t _ptr_devmode; - TALLOC_CTX *_mem_save_devmode_0; uint32_t _ptr_sepfile; TALLOC_CTX *_mem_save_sepfile_0; uint32_t _ptr_printprocessor; @@ -6745,8 +6727,6 @@ static enum ndr_err_code ndr_pull_spoolss_SetPrinterInfo2(struct ndr_pull *ndr, TALLOC_CTX *_mem_save_datatype_0; uint32_t _ptr_parameters; TALLOC_CTX *_mem_save_parameters_0; - uint32_t _ptr_secdesc; - TALLOC_CTX *_mem_save_secdesc_0; if (ndr_flags & NDR_SCALARS) { NDR_CHECK(ndr_pull_align(ndr, 5)); NDR_CHECK(ndr_pull_generic_ptr(ndr, &_ptr_servername)); @@ -6791,12 +6771,7 @@ static enum ndr_err_code ndr_pull_spoolss_SetPrinterInfo2(struct ndr_pull *ndr, } else { r->location = NULL; } - NDR_CHECK(ndr_pull_generic_ptr(ndr, &_ptr_devmode)); - if (_ptr_devmode) { - NDR_PULL_ALLOC(ndr, r->devmode); - } else { - r->devmode = NULL; - } + NDR_CHECK(ndr_pull_uint32(ndr, NDR_SCALARS, &r->devmode_ptr)); NDR_CHECK(ndr_pull_generic_ptr(ndr, &_ptr_sepfile)); if (_ptr_sepfile) { NDR_PULL_ALLOC(ndr, r->sepfile); @@ -6821,12 +6796,7 @@ static enum ndr_err_code ndr_pull_spoolss_SetPrinterInfo2(struct ndr_pull *ndr, } else { r->parameters = NULL; } - NDR_CHECK(ndr_pull_generic_ptr(ndr, &_ptr_secdesc)); - if (_ptr_secdesc) { - NDR_PULL_ALLOC(ndr, r->secdesc); - } else { - r->secdesc = NULL; - } + NDR_CHECK(ndr_pull_uint32(ndr, NDR_SCALARS, &r->secdesc_ptr)); NDR_CHECK(ndr_pull_spoolss_PrinterAttributes(ndr, NDR_SCALARS, &r->attributes)); NDR_CHECK(ndr_pull_uint32(ndr, NDR_SCALARS, &r->priority)); if (r->priority > 99) { @@ -6925,17 +6895,6 @@ static enum ndr_err_code ndr_pull_spoolss_SetPrinterInfo2(struct ndr_pull *ndr, NDR_CHECK(ndr_pull_charset(ndr, NDR_SCALARS, &r->location, ndr_get_array_length(ndr, &r->location), sizeof(uint16_t), CH_UTF16)); NDR_PULL_SET_MEM_CTX(ndr, _mem_save_location_0, 0); } - if (r->devmode) { - _mem_save_devmode_0 = NDR_PULL_GET_MEM_CTX(ndr); - NDR_PULL_SET_MEM_CTX(ndr, r->devmode, 0); - { - struct ndr_pull *_ndr_devmode; - NDR_CHECK(ndr_pull_subcontext_start(ndr, &_ndr_devmode, 0, -1)); - NDR_CHECK(ndr_pull_spoolss_DeviceMode(_ndr_devmode, NDR_SCALARS, r->devmode)); - NDR_CHECK(ndr_pull_subcontext_end(ndr, _ndr_devmode, 0, -1)); - } - NDR_PULL_SET_MEM_CTX(ndr, _mem_save_devmode_0, 0); - } if (r->sepfile) { _mem_save_sepfile_0 = NDR_PULL_GET_MEM_CTX(ndr); NDR_PULL_SET_MEM_CTX(ndr, r->sepfile, 0); @@ -6984,17 +6943,6 @@ static enum ndr_err_code ndr_pull_spoolss_SetPrinterInfo2(struct ndr_pull *ndr, NDR_CHECK(ndr_pull_charset(ndr, NDR_SCALARS, &r->parameters, ndr_get_array_length(ndr, &r->parameters), sizeof(uint16_t), CH_UTF16)); NDR_PULL_SET_MEM_CTX(ndr, _mem_save_parameters_0, 0); } - if (r->secdesc) { - _mem_save_secdesc_0 = NDR_PULL_GET_MEM_CTX(ndr); - NDR_PULL_SET_MEM_CTX(ndr, r->secdesc, 0); - { - struct ndr_pull *_ndr_secdesc; - NDR_CHECK(ndr_pull_subcontext_start(ndr, &_ndr_secdesc, 0, -1)); - NDR_CHECK(ndr_pull_security_descriptor(_ndr_secdesc, NDR_SCALARS|NDR_BUFFERS, r->secdesc)); - NDR_CHECK(ndr_pull_subcontext_end(ndr, _ndr_secdesc, 0, -1)); - } - NDR_PULL_SET_MEM_CTX(ndr, _mem_save_secdesc_0, 0); - } } return NDR_ERR_SUCCESS; } @@ -7045,12 +6993,7 @@ _PUBLIC_ void ndr_print_spoolss_SetPrinterInfo2(struct ndr_print *ndr, const cha ndr_print_string(ndr, "location", r->location); } ndr->depth--; - ndr_print_ptr(ndr, "devmode", r->devmode); - ndr->depth++; - if (r->devmode) { - ndr_print_spoolss_DeviceMode(ndr, "devmode", r->devmode); - } - ndr->depth--; + ndr_print_uint32(ndr, "devmode_ptr", r->devmode_ptr); ndr_print_ptr(ndr, "sepfile", r->sepfile); ndr->depth++; if (r->sepfile) { @@ -7075,12 +7018,7 @@ _PUBLIC_ void ndr_print_spoolss_SetPrinterInfo2(struct ndr_print *ndr, const cha ndr_print_string(ndr, "parameters", r->parameters); } ndr->depth--; - ndr_print_ptr(ndr, "secdesc", r->secdesc); - ndr->depth++; - if (r->secdesc) { - ndr_print_security_descriptor(ndr, "secdesc", r->secdesc); - } - ndr->depth--; + ndr_print_uint32(ndr, "secdesc_ptr", r->secdesc_ptr); ndr_print_spoolss_PrinterAttributes(ndr, "attributes", r->attributes); ndr_print_uint32(ndr, "priority", r->priority); ndr_print_uint32(ndr, "defaultpriority", r->defaultpriority); @@ -7423,6 +7361,70 @@ _PUBLIC_ void ndr_print_spoolss_SetPrinterInfo7(struct ndr_print *ndr, const cha ndr->depth--; } +static enum ndr_err_code ndr_push_spoolss_SetPrinterInfo8(struct ndr_push *ndr, int ndr_flags, const struct spoolss_SetPrinterInfo8 *r) +{ + if (ndr_flags & NDR_SCALARS) { + NDR_CHECK(ndr_push_align(ndr, 4)); + NDR_CHECK(ndr_push_uint32(ndr, NDR_SCALARS, r->devmode_ptr)); + NDR_CHECK(ndr_push_trailer_align(ndr, 4)); + } + if (ndr_flags & NDR_BUFFERS) { + } + return NDR_ERR_SUCCESS; +} + +static enum ndr_err_code ndr_pull_spoolss_SetPrinterInfo8(struct ndr_pull *ndr, int ndr_flags, struct spoolss_SetPrinterInfo8 *r) +{ + if (ndr_flags & NDR_SCALARS) { + NDR_CHECK(ndr_pull_align(ndr, 4)); + NDR_CHECK(ndr_pull_uint32(ndr, NDR_SCALARS, &r->devmode_ptr)); + NDR_CHECK(ndr_pull_trailer_align(ndr, 4)); + } + if (ndr_flags & NDR_BUFFERS) { + } + return NDR_ERR_SUCCESS; +} + +_PUBLIC_ void ndr_print_spoolss_SetPrinterInfo8(struct ndr_print *ndr, const char *name, const struct spoolss_SetPrinterInfo8 *r) +{ + ndr_print_struct(ndr, name, "spoolss_SetPrinterInfo8"); + ndr->depth++; + ndr_print_uint32(ndr, "devmode_ptr", r->devmode_ptr); + ndr->depth--; +} + +static enum ndr_err_code ndr_push_spoolss_SetPrinterInfo9(struct ndr_push *ndr, int ndr_flags, const struct spoolss_SetPrinterInfo9 *r) +{ + if (ndr_flags & NDR_SCALARS) { + NDR_CHECK(ndr_push_align(ndr, 4)); + NDR_CHECK(ndr_push_uint32(ndr, NDR_SCALARS, r->devmode_ptr)); + NDR_CHECK(ndr_push_trailer_align(ndr, 4)); + } + if (ndr_flags & NDR_BUFFERS) { + } + return NDR_ERR_SUCCESS; +} + +static enum ndr_err_code ndr_pull_spoolss_SetPrinterInfo9(struct ndr_pull *ndr, int ndr_flags, struct spoolss_SetPrinterInfo9 *r) +{ + if (ndr_flags & NDR_SCALARS) { + NDR_CHECK(ndr_pull_align(ndr, 4)); + NDR_CHECK(ndr_pull_uint32(ndr, NDR_SCALARS, &r->devmode_ptr)); + NDR_CHECK(ndr_pull_trailer_align(ndr, 4)); + } + if (ndr_flags & NDR_BUFFERS) { + } + return NDR_ERR_SUCCESS; +} + +_PUBLIC_ void ndr_print_spoolss_SetPrinterInfo9(struct ndr_print *ndr, const char *name, const struct spoolss_SetPrinterInfo9 *r) +{ + ndr_print_struct(ndr, name, "spoolss_SetPrinterInfo9"); + ndr->depth++; + ndr_print_uint32(ndr, "devmode_ptr", r->devmode_ptr); + ndr->depth--; +} + static enum ndr_err_code ndr_push_spoolss_SetPrinterInfo(struct ndr_push *ndr, int ndr_flags, const union spoolss_SetPrinterInfo *r) { if (ndr_flags & NDR_SCALARS) { @@ -7528,13 +7530,13 @@ static enum ndr_err_code ndr_push_spoolss_SetPrinterInfo(struct ndr_push *ndr, i case 8: if (r->info8) { - NDR_CHECK(ndr_push_spoolss_DeviceModeInfo(ndr, NDR_SCALARS|NDR_BUFFERS, r->info8)); + NDR_CHECK(ndr_push_spoolss_SetPrinterInfo8(ndr, NDR_SCALARS, r->info8)); } break; case 9: if (r->info9) { - NDR_CHECK(ndr_push_spoolss_DeviceModeInfo(ndr, NDR_SCALARS|NDR_BUFFERS, r->info9)); + NDR_CHECK(ndr_push_spoolss_SetPrinterInfo9(ndr, NDR_SCALARS, r->info9)); } break; @@ -7751,7 +7753,7 @@ static enum ndr_err_code ndr_pull_spoolss_SetPrinterInfo(struct ndr_pull *ndr, i if (r->info8) { _mem_save_info8_0 = NDR_PULL_GET_MEM_CTX(ndr); NDR_PULL_SET_MEM_CTX(ndr, r->info8, 0); - NDR_CHECK(ndr_pull_spoolss_DeviceModeInfo(ndr, NDR_SCALARS|NDR_BUFFERS, r->info8)); + NDR_CHECK(ndr_pull_spoolss_SetPrinterInfo8(ndr, NDR_SCALARS, r->info8)); NDR_PULL_SET_MEM_CTX(ndr, _mem_save_info8_0, 0); } break; @@ -7760,7 +7762,7 @@ static enum ndr_err_code ndr_pull_spoolss_SetPrinterInfo(struct ndr_pull *ndr, i if (r->info9) { _mem_save_info9_0 = NDR_PULL_GET_MEM_CTX(ndr); NDR_PULL_SET_MEM_CTX(ndr, r->info9, 0); - NDR_CHECK(ndr_pull_spoolss_DeviceModeInfo(ndr, NDR_SCALARS|NDR_BUFFERS, r->info9)); + NDR_CHECK(ndr_pull_spoolss_SetPrinterInfo9(ndr, NDR_SCALARS, r->info9)); NDR_PULL_SET_MEM_CTX(ndr, _mem_save_info9_0, 0); } break; @@ -7855,7 +7857,7 @@ _PUBLIC_ void ndr_print_spoolss_SetPrinterInfo(struct ndr_print *ndr, const char ndr_print_ptr(ndr, "info8", r->info8); ndr->depth++; if (r->info8) { - ndr_print_spoolss_DeviceModeInfo(ndr, "info8", r->info8); + ndr_print_spoolss_SetPrinterInfo8(ndr, "info8", r->info8); } ndr->depth--; break; @@ -7864,7 +7866,7 @@ _PUBLIC_ void ndr_print_spoolss_SetPrinterInfo(struct ndr_print *ndr, const char ndr_print_ptr(ndr, "info9", r->info9); ndr->depth++; if (r->info9) { - ndr_print_spoolss_DeviceModeInfo(ndr, "info9", r->info9); + ndr_print_spoolss_SetPrinterInfo9(ndr, "info9", r->info9); } ndr->depth--; break; @@ -12844,6 +12846,196 @@ _PUBLIC_ size_t ndr_size_spoolss_DriverInfo6(const struct spoolss_DriverInfo6 *r return ndr_size_struct(r, flags, (ndr_push_flags_fn_t)ndr_push_spoolss_DriverInfo6, ic); } +_PUBLIC_ enum ndr_err_code ndr_push_spoolss_DriverInfo7(struct ndr_push *ndr, int ndr_flags, const struct spoolss_DriverInfo7 *r) +{ + if (ndr_flags & NDR_SCALARS) { + NDR_CHECK(ndr_push_align(ndr, 5)); + NDR_CHECK(ndr_push_uint32(ndr, NDR_SCALARS, r->size)); + NDR_CHECK(ndr_push_spoolss_DriverOSVersion(ndr, NDR_SCALARS, r->version)); + { + uint32_t _flags_save_string = ndr->flags; + ndr_set_flags(&ndr->flags, LIBNDR_FLAG_STR_NULLTERM); + NDR_CHECK(ndr_push_relative_ptr1(ndr, r->driver_name)); + ndr->flags = _flags_save_string; + } + { + uint32_t _flags_save_string = ndr->flags; + ndr_set_flags(&ndr->flags, LIBNDR_FLAG_STR_NULLTERM); + NDR_CHECK(ndr_push_relative_ptr1(ndr, r->inf_name)); + ndr->flags = _flags_save_string; + } + { + uint32_t _flags_save_string = ndr->flags; + ndr_set_flags(&ndr->flags, LIBNDR_FLAG_STR_NULLTERM); + NDR_CHECK(ndr_push_relative_ptr1(ndr, r->install_source_root)); + ndr->flags = _flags_save_string; + } + NDR_CHECK(ndr_push_trailer_align(ndr, 5)); + } + if (ndr_flags & NDR_BUFFERS) { + { + uint32_t _flags_save_string = ndr->flags; + ndr_set_flags(&ndr->flags, LIBNDR_FLAG_STR_NULLTERM); + if (r->driver_name) { + NDR_CHECK(ndr_push_relative_ptr2(ndr, r->driver_name)); + NDR_CHECK(ndr_push_string(ndr, NDR_SCALARS, r->driver_name)); + } + ndr->flags = _flags_save_string; + } + { + uint32_t _flags_save_string = ndr->flags; + ndr_set_flags(&ndr->flags, LIBNDR_FLAG_STR_NULLTERM); + if (r->inf_name) { + NDR_CHECK(ndr_push_relative_ptr2(ndr, r->inf_name)); + NDR_CHECK(ndr_push_string(ndr, NDR_SCALARS, r->inf_name)); + } + ndr->flags = _flags_save_string; + } + { + uint32_t _flags_save_string = ndr->flags; + ndr_set_flags(&ndr->flags, LIBNDR_FLAG_STR_NULLTERM); + if (r->install_source_root) { + NDR_CHECK(ndr_push_relative_ptr2(ndr, r->install_source_root)); + NDR_CHECK(ndr_push_string(ndr, NDR_SCALARS, r->install_source_root)); + } + ndr->flags = _flags_save_string; + } + } + return NDR_ERR_SUCCESS; +} + +_PUBLIC_ enum ndr_err_code ndr_pull_spoolss_DriverInfo7(struct ndr_pull *ndr, int ndr_flags, struct spoolss_DriverInfo7 *r) +{ + uint32_t _ptr_driver_name; + TALLOC_CTX *_mem_save_driver_name_0; + uint32_t _ptr_inf_name; + TALLOC_CTX *_mem_save_inf_name_0; + uint32_t _ptr_install_source_root; + TALLOC_CTX *_mem_save_install_source_root_0; + if (ndr_flags & NDR_SCALARS) { + NDR_CHECK(ndr_pull_align(ndr, 5)); + NDR_CHECK(ndr_pull_uint32(ndr, NDR_SCALARS, &r->size)); + NDR_CHECK(ndr_pull_spoolss_DriverOSVersion(ndr, NDR_SCALARS, &r->version)); + { + uint32_t _flags_save_string = ndr->flags; + ndr_set_flags(&ndr->flags, LIBNDR_FLAG_STR_NULLTERM); + NDR_CHECK(ndr_pull_generic_ptr(ndr, &_ptr_driver_name)); + if (_ptr_driver_name) { + NDR_PULL_ALLOC(ndr, r->driver_name); + NDR_CHECK(ndr_pull_relative_ptr1(ndr, r->driver_name, _ptr_driver_name)); + } else { + r->driver_name = NULL; + } + ndr->flags = _flags_save_string; + } + { + uint32_t _flags_save_string = ndr->flags; + ndr_set_flags(&ndr->flags, LIBNDR_FLAG_STR_NULLTERM); + NDR_CHECK(ndr_pull_generic_ptr(ndr, &_ptr_inf_name)); + if (_ptr_inf_name) { + NDR_PULL_ALLOC(ndr, r->inf_name); + NDR_CHECK(ndr_pull_relative_ptr1(ndr, r->inf_name, _ptr_inf_name)); + } else { + r->inf_name = NULL; + } + ndr->flags = _flags_save_string; + } + { + uint32_t _flags_save_string = ndr->flags; + ndr_set_flags(&ndr->flags, LIBNDR_FLAG_STR_NULLTERM); + NDR_CHECK(ndr_pull_generic_ptr(ndr, &_ptr_install_source_root)); + if (_ptr_install_source_root) { + NDR_PULL_ALLOC(ndr, r->install_source_root); + NDR_CHECK(ndr_pull_relative_ptr1(ndr, r->install_source_root, _ptr_install_source_root)); + } else { + r->install_source_root = NULL; + } + ndr->flags = _flags_save_string; + } + NDR_CHECK(ndr_pull_trailer_align(ndr, 5)); + } + if (ndr_flags & NDR_BUFFERS) { + { + uint32_t _flags_save_string = ndr->flags; + ndr_set_flags(&ndr->flags, LIBNDR_FLAG_STR_NULLTERM); + if (r->driver_name) { + uint32_t _relative_save_offset; + _relative_save_offset = ndr->offset; + NDR_CHECK(ndr_pull_relative_ptr2(ndr, r->driver_name)); + _mem_save_driver_name_0 = NDR_PULL_GET_MEM_CTX(ndr); + NDR_PULL_SET_MEM_CTX(ndr, r->driver_name, 0); + NDR_CHECK(ndr_pull_string(ndr, NDR_SCALARS, &r->driver_name)); + NDR_PULL_SET_MEM_CTX(ndr, _mem_save_driver_name_0, 0); + ndr->offset = _relative_save_offset; + } + ndr->flags = _flags_save_string; + } + { + uint32_t _flags_save_string = ndr->flags; + ndr_set_flags(&ndr->flags, LIBNDR_FLAG_STR_NULLTERM); + if (r->inf_name) { + uint32_t _relative_save_offset; + _relative_save_offset = ndr->offset; + NDR_CHECK(ndr_pull_relative_ptr2(ndr, r->inf_name)); + _mem_save_inf_name_0 = NDR_PULL_GET_MEM_CTX(ndr); + NDR_PULL_SET_MEM_CTX(ndr, r->inf_name, 0); + NDR_CHECK(ndr_pull_string(ndr, NDR_SCALARS, &r->inf_name)); + NDR_PULL_SET_MEM_CTX(ndr, _mem_save_inf_name_0, 0); + ndr->offset = _relative_save_offset; + } + ndr->flags = _flags_save_string; + } + { + uint32_t _flags_save_string = ndr->flags; + ndr_set_flags(&ndr->flags, LIBNDR_FLAG_STR_NULLTERM); + if (r->install_source_root) { + uint32_t _relative_save_offset; + _relative_save_offset = ndr->offset; + NDR_CHECK(ndr_pull_relative_ptr2(ndr, r->install_source_root)); + _mem_save_install_source_root_0 = NDR_PULL_GET_MEM_CTX(ndr); + NDR_PULL_SET_MEM_CTX(ndr, r->install_source_root, 0); + NDR_CHECK(ndr_pull_string(ndr, NDR_SCALARS, &r->install_source_root)); + NDR_PULL_SET_MEM_CTX(ndr, _mem_save_install_source_root_0, 0); + ndr->offset = _relative_save_offset; + } + ndr->flags = _flags_save_string; + } + } + return NDR_ERR_SUCCESS; +} + +_PUBLIC_ void ndr_print_spoolss_DriverInfo7(struct ndr_print *ndr, const char *name, const struct spoolss_DriverInfo7 *r) +{ + ndr_print_struct(ndr, name, "spoolss_DriverInfo7"); + ndr->depth++; + ndr_print_uint32(ndr, "size", r->size); + ndr_print_spoolss_DriverOSVersion(ndr, "version", r->version); + ndr_print_ptr(ndr, "driver_name", r->driver_name); + ndr->depth++; + if (r->driver_name) { + ndr_print_string(ndr, "driver_name", r->driver_name); + } + ndr->depth--; + ndr_print_ptr(ndr, "inf_name", r->inf_name); + ndr->depth++; + if (r->inf_name) { + ndr_print_string(ndr, "inf_name", r->inf_name); + } + ndr->depth--; + ndr_print_ptr(ndr, "install_source_root", r->install_source_root); + ndr->depth++; + if (r->install_source_root) { + ndr_print_string(ndr, "install_source_root", r->install_source_root); + } + ndr->depth--; + ndr->depth--; +} + +_PUBLIC_ size_t ndr_size_spoolss_DriverInfo7(const struct spoolss_DriverInfo7 *r, struct smb_iconv_convenience *ic, int flags) +{ + return ndr_size_struct(r, flags, (ndr_push_flags_fn_t)ndr_push_spoolss_DriverInfo7, ic); +} + _PUBLIC_ enum ndr_err_code ndr_push_spoolss_DriverInfo8(struct ndr_push *ndr, int ndr_flags, const struct spoolss_DriverInfo8 *r) { if (ndr_flags & NDR_SCALARS) { @@ -14088,6 +14280,12 @@ _PUBLIC_ enum ndr_err_code ndr_push_spoolss_DriverInfo(struct ndr_push *ndr, int NDR_CHECK(ndr_push_spoolss_DriverInfo6(ndr, NDR_SCALARS, &r->info6)); break; } + case 7: { + NDR_CHECK(ndr_push_align(ndr, 5)); + NDR_CHECK(ndr_push_setup_relative_base_offset1(ndr, r, ndr->offset)); + NDR_CHECK(ndr_push_spoolss_DriverInfo7(ndr, NDR_SCALARS, &r->info7)); + break; } + case 8: { NDR_CHECK(ndr_push_align(ndr, 8)); NDR_CHECK(ndr_push_setup_relative_base_offset1(ndr, r, ndr->offset)); @@ -14133,6 +14331,10 @@ _PUBLIC_ enum ndr_err_code ndr_push_spoolss_DriverInfo(struct ndr_push *ndr, int NDR_CHECK(ndr_push_spoolss_DriverInfo6(ndr, NDR_BUFFERS, &r->info6)); break; + case 7: + NDR_CHECK(ndr_push_spoolss_DriverInfo7(ndr, NDR_BUFFERS, &r->info7)); + break; + case 8: NDR_CHECK(ndr_push_spoolss_DriverInfo8(ndr, NDR_BUFFERS, &r->info8)); break; @@ -14194,6 +14396,12 @@ _PUBLIC_ enum ndr_err_code ndr_pull_spoolss_DriverInfo(struct ndr_pull *ndr, int NDR_CHECK(ndr_pull_spoolss_DriverInfo6(ndr, NDR_SCALARS, &r->info6)); break; } + case 7: { + NDR_CHECK(ndr_pull_align(ndr, 5)); + NDR_CHECK(ndr_pull_setup_relative_base_offset1(ndr, r, ndr->offset)); + NDR_CHECK(ndr_pull_spoolss_DriverInfo7(ndr, NDR_SCALARS, &r->info7)); + break; } + case 8: { NDR_CHECK(ndr_pull_align(ndr, 8)); NDR_CHECK(ndr_pull_setup_relative_base_offset1(ndr, r, ndr->offset)); @@ -14238,6 +14446,10 @@ _PUBLIC_ enum ndr_err_code ndr_pull_spoolss_DriverInfo(struct ndr_pull *ndr, int NDR_CHECK(ndr_pull_spoolss_DriverInfo6(ndr, NDR_BUFFERS, &r->info6)); break; + case 7: + NDR_CHECK(ndr_pull_spoolss_DriverInfo7(ndr, NDR_BUFFERS, &r->info7)); + break; + case 8: NDR_CHECK(ndr_pull_spoolss_DriverInfo8(ndr, NDR_BUFFERS, &r->info8)); break; @@ -14285,6 +14497,10 @@ _PUBLIC_ void ndr_print_spoolss_DriverInfo(struct ndr_print *ndr, const char *na ndr_print_spoolss_DriverInfo6(ndr, "info6", &r->info6); break; + case 7: + ndr_print_spoolss_DriverInfo7(ndr, "info7", &r->info7); + break; + case 8: ndr_print_spoolss_DriverInfo8(ndr, "info8", &r->info8); break; diff --git a/librpc/gen_ndr/ndr_spoolss.h b/librpc/gen_ndr/ndr_spoolss.h index b368006572..ee74c78b87 100644 --- a/librpc/gen_ndr/ndr_spoolss.h +++ b/librpc/gen_ndr/ndr_spoolss.h @@ -340,6 +340,8 @@ void ndr_print_spoolss_SetPrinterInfo4(struct ndr_print *ndr, const char *name, void ndr_print_spoolss_SetPrinterInfo5(struct ndr_print *ndr, const char *name, const struct spoolss_SetPrinterInfo5 *r); void ndr_print_spoolss_SetPrinterInfo6(struct ndr_print *ndr, const char *name, const struct spoolss_SetPrinterInfo6 *r); void ndr_print_spoolss_SetPrinterInfo7(struct ndr_print *ndr, const char *name, const struct spoolss_SetPrinterInfo7 *r); +void ndr_print_spoolss_SetPrinterInfo8(struct ndr_print *ndr, const char *name, const struct spoolss_SetPrinterInfo8 *r); +void ndr_print_spoolss_SetPrinterInfo9(struct ndr_print *ndr, const char *name, const struct spoolss_SetPrinterInfo9 *r); void ndr_print_spoolss_SetPrinterInfo(struct ndr_print *ndr, const char *name, const union spoolss_SetPrinterInfo *r); void ndr_print_spoolss_SetPrinterInfoCtr(struct ndr_print *ndr, const char *name, const struct spoolss_SetPrinterInfoCtr *r); enum ndr_err_code ndr_push_spoolss_StringArray(struct ndr_push *ndr, int ndr_flags, const struct spoolss_StringArray *r); @@ -381,6 +383,10 @@ enum ndr_err_code ndr_push_spoolss_DriverInfo6(struct ndr_push *ndr, int ndr_fla enum ndr_err_code ndr_pull_spoolss_DriverInfo6(struct ndr_pull *ndr, int ndr_flags, struct spoolss_DriverInfo6 *r); void ndr_print_spoolss_DriverInfo6(struct ndr_print *ndr, const char *name, const struct spoolss_DriverInfo6 *r); size_t ndr_size_spoolss_DriverInfo6(const struct spoolss_DriverInfo6 *r, struct smb_iconv_convenience *ic, int flags); +enum ndr_err_code ndr_push_spoolss_DriverInfo7(struct ndr_push *ndr, int ndr_flags, const struct spoolss_DriverInfo7 *r); +enum ndr_err_code ndr_pull_spoolss_DriverInfo7(struct ndr_pull *ndr, int ndr_flags, struct spoolss_DriverInfo7 *r); +void ndr_print_spoolss_DriverInfo7(struct ndr_print *ndr, const char *name, const struct spoolss_DriverInfo7 *r); +size_t ndr_size_spoolss_DriverInfo7(const struct spoolss_DriverInfo7 *r, struct smb_iconv_convenience *ic, int flags); enum ndr_err_code ndr_push_spoolss_DriverInfo8(struct ndr_push *ndr, int ndr_flags, const struct spoolss_DriverInfo8 *r); enum ndr_err_code ndr_pull_spoolss_DriverInfo8(struct ndr_pull *ndr, int ndr_flags, struct spoolss_DriverInfo8 *r); void ndr_print_spoolss_DriverInfo8(struct ndr_print *ndr, const char *name, const struct spoolss_DriverInfo8 *r); diff --git a/librpc/gen_ndr/spoolss.h b/librpc/gen_ndr/spoolss.h index 5b88e08ac3..08d1a38829 100644 --- a/librpc/gen_ndr/spoolss.h +++ b/librpc/gen_ndr/spoolss.h @@ -1144,12 +1144,12 @@ struct spoolss_SetPrinterInfo2 { const char *drivername;/* [unique,charset(UTF16)] */ const char *comment;/* [unique,charset(UTF16)] */ const char *location;/* [unique,charset(UTF16)] */ - struct spoolss_DeviceMode *devmode;/* [unique,subcontext(0)] */ + uint32_t devmode_ptr; const char *sepfile;/* [unique,charset(UTF16)] */ const char *printprocessor;/* [unique,charset(UTF16)] */ const char *datatype;/* [unique,charset(UTF16)] */ const char *parameters;/* [unique,charset(UTF16)] */ - struct security_descriptor *secdesc;/* [unique,subcontext(0)] */ + uint32_t secdesc_ptr; uint32_t attributes; uint32_t priority;/* [range(0,99)] */ uint32_t defaultpriority; @@ -1187,6 +1187,14 @@ struct spoolss_SetPrinterInfo7 { uint32_t action; }; +struct spoolss_SetPrinterInfo8 { + uint32_t devmode_ptr; +}; + +struct spoolss_SetPrinterInfo9 { + uint32_t devmode_ptr; +}; + union spoolss_SetPrinterInfo { struct spoolss_SetPrinterInfo0 *info0;/* [unique,case(0)] */ struct spoolss_SetPrinterInfo1 *info1;/* [unique,case] */ @@ -1196,8 +1204,8 @@ union spoolss_SetPrinterInfo { struct spoolss_SetPrinterInfo5 *info5;/* [unique,case(5)] */ struct spoolss_SetPrinterInfo6 *info6;/* [unique,case(6)] */ struct spoolss_SetPrinterInfo7 *info7;/* [unique,case(7)] */ - struct spoolss_DeviceModeInfo *info8;/* [unique,case(8)] */ - struct spoolss_DeviceModeInfo *info9;/* [unique,case(9)] */ + struct spoolss_SetPrinterInfo8 *info8;/* [unique,case(8)] */ + struct spoolss_SetPrinterInfo9 *info9;/* [unique,case(9)] */ }/* [switch_type(uint32)] */; struct spoolss_SetPrinterInfoCtr { @@ -1425,6 +1433,14 @@ struct spoolss_DriverInfo6 { const char * provider;/* [relative,flag(LIBNDR_FLAG_STR_NULLTERM)] */ }/* [gensize,public] */; +struct spoolss_DriverInfo7 { + uint32_t size; + enum spoolss_DriverOSVersion version; + const char * driver_name;/* [relative,flag(LIBNDR_FLAG_STR_NULLTERM)] */ + const char * inf_name;/* [relative,flag(LIBNDR_FLAG_STR_NULLTERM)] */ + const char * install_source_root;/* [relative,flag(LIBNDR_FLAG_STR_NULLTERM)] */ +}/* [gensize,public] */; + struct spoolss_DriverInfo8 { enum spoolss_DriverOSVersion version; const char * driver_name;/* [relative,flag(LIBNDR_FLAG_STR_NULLTERM)] */ @@ -1502,6 +1518,7 @@ union spoolss_DriverInfo { struct spoolss_DriverInfo4 info4;/* [case(4)] */ struct spoolss_DriverInfo5 info5;/* [case(5)] */ struct spoolss_DriverInfo6 info6;/* [case(6)] */ + struct spoolss_DriverInfo7 info7;/* [case(7)] */ struct spoolss_DriverInfo8 info8;/* [case(8)] */ struct spoolss_DriverInfo101 info101;/* [case(101)] */ }/* [relative_base,gensize,public,nodiscriminant] */; diff --git a/librpc/idl/spoolss.idl b/librpc/idl/spoolss.idl index 1695c5a8cc..259ffd4d7e 100644 --- a/librpc/idl/spoolss.idl +++ b/librpc/idl/spoolss.idl @@ -891,12 +891,12 @@ import "misc.idl", "security.idl", "winreg.idl"; [string,charset(UTF16)] uint16 *drivername; [string,charset(UTF16)] uint16 *comment; [string,charset(UTF16)] uint16 *location; - [subcontext(0)] spoolss_DeviceMode *devmode; + uint32 devmode_ptr; [string,charset(UTF16)] uint16 *sepfile; [string,charset(UTF16)] uint16 *printprocessor; [string,charset(UTF16)] uint16 *datatype; [string,charset(UTF16)] uint16 *parameters; - [subcontext(0)] security_descriptor *secdesc; + uint32 secdesc_ptr; spoolss_PrinterAttributes attributes; [range(0,99)] uint32 priority; uint32 defaultpriority; @@ -934,6 +934,14 @@ import "misc.idl", "security.idl", "winreg.idl"; spoolss_DsPrintAction action; } spoolss_SetPrinterInfo7; + typedef struct { + uint32 devmode_ptr; + } spoolss_SetPrinterInfo8; + + typedef struct { + uint32 devmode_ptr; + } spoolss_SetPrinterInfo9; + typedef [switch_type(uint32)] union { [case(0)] spoolss_SetPrinterInfo0 *info0; [case(1)] spoolss_SetPrinterInfo1 *info1; @@ -943,8 +951,8 @@ import "misc.idl", "security.idl", "winreg.idl"; [case(5)] spoolss_SetPrinterInfo5 *info5; [case(6)] spoolss_SetPrinterInfo6 *info6; [case(7)] spoolss_SetPrinterInfo7 *info7; - [case(8)] spoolss_DeviceModeInfo *info8; - [case(9)] spoolss_DeviceModeInfo *info9; + [case(8)] spoolss_SetPrinterInfo8 *info8; + [case(9)] spoolss_SetPrinterInfo9 *info9; [default]; } spoolss_SetPrinterInfo; @@ -1192,6 +1200,14 @@ import "misc.idl", "security.idl", "winreg.idl"; } spoolss_DriverInfo6; typedef [public,gensize] struct { + uint32 size; + spoolss_DriverOSVersion version; + [relative] nstring *driver_name; + [relative] nstring *inf_name; + [relative] nstring *install_source_root; + } spoolss_DriverInfo7; + + typedef [public,gensize] struct { spoolss_DriverOSVersion version; [relative] nstring *driver_name; [relative] nstring *architecture; @@ -1257,6 +1273,7 @@ import "misc.idl", "security.idl", "winreg.idl"; [case(4)] spoolss_DriverInfo4 info4; [case(5)] spoolss_DriverInfo5 info5; [case(6)] spoolss_DriverInfo6 info6; + [case(7)] spoolss_DriverInfo7 info7; [case(8)] spoolss_DriverInfo8 info8; [case(101)] spoolss_DriverInfo101 info101; [default]; diff --git a/nsswitch/libwbclient/wbc_pam.c b/nsswitch/libwbclient/wbc_pam.c index 7a66a7fe82..00863a0d54 100644 --- a/nsswitch/libwbclient/wbc_pam.c +++ b/nsswitch/libwbclient/wbc_pam.c @@ -5,6 +5,7 @@ Copyright (C) Gerald (Jerry) Carter 2007 Copyright (C) Guenther Deschner 2008 + Copyright (C) Volker Lendecke 2009 This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public @@ -570,6 +571,50 @@ wbcErr wbcChangeTrustCredentials(const char *domain, return wbc_status; } +/* + * Trigger a no-op NETLOGON call. Lightweight version of + * wbcCheckTrustCredentials + */ +wbcErr wbcPingDc(const char *domain, struct wbcAuthErrorInfo **error) +{ + struct winbindd_request request; + struct winbindd_response response; + wbcErr wbc_status = WBC_ERR_UNKNOWN_FAILURE; + + if (domain) { + /* + * the current protocol doesn't support + * specifying a domain + */ + wbc_status = WBC_ERR_NOT_IMPLEMENTED; + BAIL_ON_WBC_ERROR(wbc_status); + } + + ZERO_STRUCT(request); + ZERO_STRUCT(response); + + /* Send request */ + + wbc_status = wbcRequestResponse(WINBINDD_PING_DC, + &request, + &response); + if (response.data.auth.nt_status != 0) { + if (error) { + wbc_status = wbc_create_error_info(NULL, + &response, + error); + BAIL_ON_WBC_ERROR(wbc_status); + } + + wbc_status = WBC_ERR_AUTH_ERROR; + BAIL_ON_WBC_ERROR(wbc_status); + } + BAIL_ON_WBC_ERROR(wbc_status); + + done: + return wbc_status; +} + /* Trigger an extended logoff notification to Winbind for a specific user */ wbcErr wbcLogoffUserEx(const struct wbcLogoffUserParams *params, struct wbcAuthErrorInfo **error) diff --git a/nsswitch/libwbclient/wbclient.h b/nsswitch/libwbclient/wbclient.h index 1efd90f6f8..8bbbfbc55d 100644 --- a/nsswitch/libwbclient/wbclient.h +++ b/nsswitch/libwbclient/wbclient.h @@ -4,6 +4,7 @@ Winbind client API Copyright (C) Gerald (Jerry) Carter 2007 + Copyright (C) Volker Lendecke 2009 This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public @@ -1203,6 +1204,19 @@ wbcErr wbcCheckTrustCredentials(const char *domain, wbcErr wbcChangeTrustCredentials(const char *domain, struct wbcAuthErrorInfo **error); +/** + * @brief Trigger a no-op call through the NETLOGON pipe. Low-cost + * version of wbcCheckTrustCredentials + * + * @param *domain The name of the domain, only NULL for the default domain is + * supported yet. Other values than NULL will result in + * WBC_ERR_NOT_IMPLEMENTED. + * @param error Output details on WBC_ERR_AUTH_ERROR + * + * @return #wbcErr + **/ +wbcErr wbcPingDc(const char *domain, struct wbcAuthErrorInfo **error); + /********************************************************** * Helper functions **********************************************************/ diff --git a/nsswitch/wbinfo.c b/nsswitch/wbinfo.c index d3d9250e81..45d8684bad 100644 --- a/nsswitch/wbinfo.c +++ b/nsswitch/wbinfo.c @@ -5,6 +5,7 @@ Copyright (C) Tim Potter 2000-2003 Copyright (C) Andrew Bartlett 2002-2007 + Copyright (C) Volker Lendecke 2009 This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by @@ -779,6 +780,30 @@ static bool wbinfo_change_secret(const char *domain) return true; } +/* Check DC connection */ + +static bool wbinfo_ping_dc(void) +{ + wbcErr wbc_status = WBC_ERR_UNKNOWN_FAILURE; + struct wbcAuthErrorInfo *error = NULL; + + wbc_status = wbcPingDc(NULL, &error); + + d_printf("checking the NETLOGON dc connection %s\n", + WBC_ERROR_IS_OK(wbc_status) ? "succeeded" : "failed"); + + if (wbc_status == WBC_ERR_AUTH_ERROR) { + d_fprintf(stderr, "error code was %s (0x%x)\n", + error->nt_string, error->nt_status); + wbcFreeMemory(error); + } + if (!WBC_ERROR_IS_OK(wbc_status)) { + return false; + } + + return true; +} + /* Convert uid to sid */ static bool wbinfo_uid_to_sid(uid_t uid) @@ -1710,6 +1735,7 @@ enum { OPT_VERBOSE, OPT_ONLINESTATUS, OPT_CHANGE_USER_PASSWORD, + OPT_PING_DC, OPT_SID_TO_FULLNAME, OPT_NTLMV2, OPT_LANMAN @@ -1759,6 +1785,8 @@ int main(int argc, char **argv, char **envp) { "remove-gid-mapping", 0, POPT_ARG_STRING, &string_arg, OPT_REMOVE_GID_MAPPING, "Remove gid to sid mapping in idmap", "GID,SID" }, { "check-secret", 't', POPT_ARG_NONE, 0, 't', "Check shared secret" }, { "change-secret", 'c', POPT_ARG_NONE, 0, 'c', "Change shared secret" }, + { "ping-dc", 0, POPT_ARG_NONE, 0, OPT_PING_DC, + "Check the NETLOGON connection" }, { "trusted-domains", 'm', POPT_ARG_NONE, 0, 'm', "List trusted domains" }, { "all-domains", 0, POPT_ARG_NONE, 0, OPT_LIST_ALL_DOMAINS, "List all domains (trusted and own domain)" }, { "own-domain", 0, POPT_ARG_NONE, 0, OPT_LIST_OWN_DOMAIN, "List own domain" }, @@ -1995,6 +2023,12 @@ int main(int argc, char **argv, char **envp) goto done; } break; + case OPT_PING_DC: + if (!wbinfo_ping_dc()) { + d_fprintf(stderr, "Could not ping our DC\n"); + goto done; + } + break; case 'm': if (!wbinfo_list_domains(false, verbose)) { d_fprintf(stderr, diff --git a/nsswitch/winbind_struct_protocol.h b/nsswitch/winbind_struct_protocol.h index 3056e25905..4d27d5283c 100644 --- a/nsswitch/winbind_struct_protocol.h +++ b/nsswitch/winbind_struct_protocol.h @@ -47,8 +47,9 @@ typedef char fstring[FSTRING_LEN]; /* Update this when you change the interface. * 21: added WINBINDD_GETPWSID * added WINBINDD_GETSIDALIASES + * 22: added WINBINDD_PING_DC */ -#define WINBIND_INTERFACE_VERSION 21 +#define WINBIND_INTERFACE_VERSION 22 /* Have to deal with time_t being 4 or 8 bytes due to structure alignment. On a 64bit Linux box, we have to support a constant structure size @@ -119,6 +120,7 @@ enum winbindd_cmd { WINBINDD_CHECK_MACHACC, /* Check machine account pw works */ WINBINDD_CHANGE_MACHACC, /* Change machine account pw */ + WINBINDD_PING_DC, /* Ping the DC through NETLOGON */ WINBINDD_PING, /* Just tell me winbind is running */ WINBINDD_INFO, /* Various bit of info. Currently just tidbits */ WINBINDD_DOMAIN_NAME, /* The domain this winbind server is a member of (lp_workgroup()) */ diff --git a/packaging/RHEL-CTDB/samba.spec b/packaging/RHEL-CTDB/samba.spec index 25d0ed236d..73b87d1f20 100644 --- a/packaging/RHEL-CTDB/samba.spec +++ b/packaging/RHEL-CTDB/samba.spec @@ -5,7 +5,7 @@ Summary: Samba SMB client and server Vendor: Samba Team Packager: Samba Team <samba@samba.org> Name: samba -Version: 3.5.0pre2 +Version: 3.5.0rc1 Release: 1GITHASH Epoch: 0 License: GNU GPL version 3 diff --git a/packaging/RHEL/makerpms.sh b/packaging/RHEL/makerpms.sh index 1f53432cc8..83d8c196d7 100644 --- a/packaging/RHEL/makerpms.sh +++ b/packaging/RHEL/makerpms.sh @@ -20,7 +20,7 @@ SRCDIR=`rpm --eval %_sourcedir` USERID=`id -u` GRPID=`id -g` -VERSION='3.5.0pre2' +VERSION='3.5.0rc1' REVISION='' SPECFILE="samba.spec" RPMVER=`rpm --version | awk '{print $3}'` diff --git a/packaging/RHEL/samba.spec b/packaging/RHEL/samba.spec index 301c74cddd..c42e3ac397 100644 --- a/packaging/RHEL/samba.spec +++ b/packaging/RHEL/samba.spec @@ -5,7 +5,7 @@ Summary: Samba SMB client and server Vendor: Samba Team Packager: Samba Team <samba@samba.org> Name: samba -Version: 3.5.0pre2 +Version: 3.5.0rc1 Release: 1 Epoch: 0 License: GNU GPL version 3 diff --git a/source3/Makefile.in b/source3/Makefile.in index 3fcc486288..66f51e2478 100644 --- a/source3/Makefile.in +++ b/source3/Makefile.in @@ -1146,7 +1146,6 @@ IDMAP_ADEX_OBJ = \ WINBINDD_OBJ1 = \ winbindd/winbindd.o \ - winbindd/winbindd_user.o \ winbindd/winbindd_group.o \ winbindd/winbindd_util.o \ winbindd/winbindd_cache.o \ @@ -1224,6 +1223,7 @@ WINBINDD_OBJ1 = \ winbindd/winbindd_list_groups.o \ winbindd/winbindd_check_machine_acct.o \ winbindd/winbindd_change_machine_acct.o \ + winbindd/winbindd_ping_dc.o \ winbindd/winbindd_set_mapping.o \ winbindd/winbindd_remove_mapping.o \ winbindd/winbindd_set_hwm.o \ diff --git a/source3/VERSION b/source3/VERSION index e06aae604b..3addc63acb 100644 --- a/source3/VERSION +++ b/source3/VERSION @@ -46,7 +46,7 @@ SAMBA_VERSION_REVISION= # e.g. SAMBA_VERSION_PRE_RELEASE=1 # # -> "2.2.9pre1" # ######################################################## -SAMBA_VERSION_PRE_RELEASE=2 +SAMBA_VERSION_PRE_RELEASE= ######################################################## # For 'rc' releases the version will be # @@ -56,7 +56,7 @@ SAMBA_VERSION_PRE_RELEASE=2 # e.g. SAMBA_VERSION_RC_RELEASE=1 # # -> "3.0.0rc1" # ######################################################## -SAMBA_VERSION_RC_RELEASE= +SAMBA_VERSION_RC_RELEASE=1 ######################################################## # To mark SVN snapshots this should be set to 'yes' # diff --git a/source3/configure b/source3/configure index 73d1433fb6..689c08816c 100755 --- a/source3/configure +++ b/source3/configure @@ -45482,7 +45482,12 @@ rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext case "$host_os" in *linux* | gnu* | k*bsd*-gnu | kopensolaris*-gnu) # glibc <= 2.3.2 has a broken getgrouplist - if test "$cross_compiling" = yes; then + { $as_echo "$as_me:$LINENO: checking for good getgrouplist" >&5 +$as_echo_n "checking for good getgrouplist... " >&6; } +if test "${samba_cv_linux_getgrouplist_ok+set}" = set; then + $as_echo_n "(cached) " >&6 +else + if test "$cross_compiling" = yes; then { { $as_echo "$as_me:$LINENO: error: in \`$ac_pwd':" >&5 $as_echo "$as_me: error: in \`$ac_pwd':" >&2;} { { $as_echo "$as_me:$LINENO: error: cannot run test program while cross compiling @@ -45537,21 +45542,24 @@ $as_echo "$ac_try_echo") >&5 ac_status=$? $as_echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); }; }; then - linux_getgrouplist_ok=yes + samba_cv_linux_getgrouplist_ok=yes else $as_echo "$as_me: program exited with status $ac_status" >&5 $as_echo "$as_me: failed program was:" >&5 sed 's/^/| /' conftest.$ac_ext >&5 ( exit $ac_status ) -linux_getgrouplist_ok=no +samba_cv_linux_getgrouplist_ok=no fi rm -rf conftest.dSYM rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext conftest.$ac_objext conftest.$ac_ext fi - if test x"$linux_getgrouplist_ok" = x"yes"; then +fi +{ $as_echo "$as_me:$LINENO: result: $samba_cv_linux_getgrouplist_ok" >&5 +$as_echo "$samba_cv_linux_getgrouplist_ok" >&6; } + if test x"$samba_cv_linux_getgrouplist_ok" = x"yes"; then cat >>confdefs.h <<\_ACEOF #define HAVE_GETGROUPLIST 1 diff --git a/source3/configure.in b/source3/configure.in index 2da1f9e8ef..e527a1896b 100644 --- a/source3/configure.in +++ b/source3/configure.in @@ -1194,7 +1194,7 @@ AC_DEFINE(HAVE_PRCTL, 1, [Whether prctl is available]),[]) case "$host_os" in *linux* | gnu* | k*bsd*-gnu | kopensolaris*-gnu) # glibc <= 2.3.2 has a broken getgrouplist - AC_TRY_RUN([ + AC_CACHE_CHECK([for good getgrouplist],samba_cv_linux_getgrouplist_ok,[AC_TRY_RUN([ #include <unistd.h> #include <sys/utsname.h> main() { @@ -1210,8 +1210,8 @@ main() { #endif exit(0); } -], [linux_getgrouplist_ok=yes], [linux_getgrouplist_ok=no]) - if test x"$linux_getgrouplist_ok" = x"yes"; then +], [samba_cv_linux_getgrouplist_ok=yes], [samba_cv_linux_getgrouplist_ok=no])]) + if test x"$samba_cv_linux_getgrouplist_ok" = x"yes"; then AC_DEFINE(HAVE_GETGROUPLIST, 1, [Have good getgrouplist]) fi ;; diff --git a/source3/include/async_smb.h b/source3/include/async_smb.h index 03dd274539..47fed92739 100644 --- a/source3/include/async_smb.h +++ b/source3/include/async_smb.h @@ -22,11 +22,6 @@ #include "includes.h" -bool smb_splice_chain(uint8_t **poutbuf, uint8_t smb_command, - uint8_t wct, const uint16_t *vwv, - size_t bytes_alignment, - uint32_t num_bytes, const uint8_t *bytes); - /* * Fetch an error out of a NBT packet */ diff --git a/source3/include/local.h b/source3/include/local.h index de54ea5886..a88b17be13 100644 --- a/source3/include/local.h +++ b/source3/include/local.h @@ -56,17 +56,6 @@ #define SYSLOG_FACILITY LOG_DAEMON #endif -/* - * Default number of maximum open files per smbd. This is - * also limited by the maximum available file descriptors - * per process and can also be set in smb.conf as "max open files" - * in the [global] section. - */ - -#ifndef MAX_OPEN_FILES -#define MAX_OPEN_FILES 10000 -#endif - /* * Fudgefactor required for open tdb's, etc. */ @@ -82,7 +71,18 @@ */ #ifndef MIN_OPEN_FILES_WINDOWS -#define MIN_OPEN_FILES_WINDOWS 1050 +#define MIN_OPEN_FILES_WINDOWS 16384 +#endif + +/* + * Default number of maximum open files per smbd. This is + * also limited by the maximum available file descriptors + * per process and can also be set in smb.conf as "max open files" + * in the [global] section. + */ + +#ifndef MAX_OPEN_FILES +#define MAX_OPEN_FILES (MIN_OPEN_FILES_WINDOWS + MAX_OPEN_FUDGEFACTOR) #endif #define WORDMAX 0xFFFF diff --git a/source3/include/proto.h b/source3/include/proto.h index eba9fd5579..b3512d9c70 100644 --- a/source3/include/proto.h +++ b/source3/include/proto.h @@ -3044,8 +3044,6 @@ NTSTATUS cli_trans(TALLOC_CTX *mem_ctx, struct cli_state *cli, NTSTATUS check_negative_conn_cache_timeout( const char *domain, const char *server, unsigned int failed_cache_timeout ); NTSTATUS check_negative_conn_cache( const char *domain, const char *server); void add_failed_connection_entry(const char *domain, const char *server, NTSTATUS result) ; -void delete_negative_conn_cache(const char *domain, const char *server); -void flush_negative_conn_cache( void ); void flush_negative_conn_cache_for_domain(const char *domain); /* The following definitions come from ../librpc/rpc/dcerpc_error.c */ @@ -5379,6 +5377,7 @@ NTSTATUS rpc_transport_np_init(TALLOC_CTX *mem_ctx, struct cli_state *cli, const struct ndr_syntax_id *abstract_syntax, struct rpc_cli_transport **presult); struct cli_state *rpc_pipe_np_smb_conn(struct rpc_pipe_client *p); +void rpccli_close_np_fd(struct rpc_pipe_client *p); /* The following definitions come from rpc_client/rpc_transport_smbd.c */ @@ -5409,11 +5408,15 @@ NTSTATUS rpc_transport_smbd_init(TALLOC_CTX *mem_ctx, struct rpc_cli_smbd_conn *conn, const struct ndr_syntax_id *abstract_syntax, struct rpc_cli_transport **presult); +struct cli_state *rpc_pipe_smbd_smb_conn(struct rpc_pipe_client *p); /* The following definitions come from rpc_client/rpc_transport_sock.c */ NTSTATUS rpc_transport_sock_init(TALLOC_CTX *mem_ctx, int fd, struct rpc_cli_transport **presult); +int rpccli_set_sock_timeout(struct rpc_pipe_client *rpccli, int timeout); +void rpccli_close_sock_fd(struct rpc_pipe_client *rpccli); +bool rpc_pipe_tcp_connection_ok(struct rpc_pipe_client *rpccli); /* The following definitions come from rpc_client/cli_samr.c */ @@ -6261,9 +6264,7 @@ void error_packet_set(char *outbuf, uint8 eclass, uint32 ecode, NTSTATUS ntstatu int error_packet(char *outbuf, uint8 eclass, uint32 ecode, NTSTATUS ntstatus, int line, const char *file); void reply_nt_error(struct smb_request *req, NTSTATUS ntstatus, int line, const char *file); -void reply_force_nt_error(struct smb_request *req, NTSTATUS ntstatus, - int line, const char *file); -void reply_dos_error(struct smb_request *req, uint8 eclass, uint32 ecode, +void reply_force_dos_error(struct smb_request *req, uint8 eclass, uint32 ecode, int line, const char *file); void reply_both_error(struct smb_request *req, uint8 eclass, uint32 ecode, NTSTATUS status, int line, const char *file); @@ -6721,6 +6722,10 @@ void reply_pipe_close(connection_struct *conn, struct smb_request *req); void create_file_sids(const SMB_STRUCT_STAT *psbuf, DOM_SID *powner_sid, DOM_SID *pgroup_sid); bool nt4_compatible_acls(void); +uint32_t map_canon_ace_perms(int snum, + enum security_ace_type *pacl_type, + mode_t perms, + bool directory_ace); NTSTATUS unpack_nt_owners(int snum, uid_t *puser, gid_t *pgrp, uint32 security_info_sent, const SEC_DESC *psd); SMB_ACL_T free_empty_sys_acl(connection_struct *conn, SMB_ACL_T the_acl); NTSTATUS posix_fget_nt_acl(struct files_struct *fsp, uint32_t security_info, diff --git a/source3/include/smb.h b/source3/include/smb.h index 4affd4a8cf..b23ea647ec 100644 --- a/source3/include/smb.h +++ b/source3/include/smb.h @@ -27,7 +27,7 @@ #define _SMB_H /* logged when starting the various Samba daemons */ -#define COPYRIGHT_STARTUP_MESSAGE "Copyright Andrew Tridgell and the Samba Team 1992-2009" +#define COPYRIGHT_STARTUP_MESSAGE "Copyright Andrew Tridgell and the Samba Team 1992-2010" #if defined(LARGE_SMB_OFF_T) diff --git a/source3/include/smb_macros.h b/source3/include/smb_macros.h index 10ee78b394..bc5d9a7fe1 100644 --- a/source3/include/smb_macros.h +++ b/source3/include/smb_macros.h @@ -112,8 +112,7 @@ #define ERROR_BOTH(status,class,code) error_packet(outbuf,class,code,status,__LINE__,__FILE__) #define reply_nterror(req,status) reply_nt_error(req,status,__LINE__,__FILE__) -#define reply_force_nterror(req,status) reply_force_nt_error(req,status,__LINE__,__FILE__) -#define reply_doserror(req,eclass,ecode) reply_dos_error(req,eclass,ecode,__LINE__,__FILE__) +#define reply_force_doserror(req,eclass,ecode) reply_force_dos_error(req,eclass,ecode,__LINE__,__FILE__) #define reply_botherror(req,status,eclass,ecode) reply_both_error(req,eclass,ecode,status,__LINE__,__FILE__) #if 0 diff --git a/source3/include/version.h b/source3/include/version.h index 5dcc7cc216..5f59302f5b 100644 --- a/source3/include/version.h +++ b/source3/include/version.h @@ -2,8 +2,8 @@ #define SAMBA_VERSION_MAJOR 3 #define SAMBA_VERSION_MINOR 5 #define SAMBA_VERSION_RELEASE 0 -#define SAMBA_VERSION_PRE_RELEASE 2 -#define SAMBA_VERSION_OFFICIAL_STRING "3.5.0pre2" +#define SAMBA_VERSION_RC_RELEASE 1 +#define SAMBA_VERSION_OFFICIAL_STRING "3.5.0rc1" #ifdef SAMBA_VERSION_VENDOR_FUNCTION # define SAMBA_VERSION_STRING SAMBA_VERSION_VENDOR_FUNCTION #else /* SAMBA_VERSION_VENDOR_FUNCTION */ diff --git a/source3/librpc/gen_ndr/cli_wbint.c b/source3/librpc/gen_ndr/cli_wbint.c index 3115a20d9d..592b27b50d 100644 --- a/source3/librpc/gen_ndr/cli_wbint.c +++ b/source3/librpc/gen_ndr/cli_wbint.c @@ -2901,6 +2901,136 @@ NTSTATUS rpccli_wbint_ChangeMachineAccount(struct rpc_pipe_client *cli, return r.out.result; } +struct rpccli_wbint_PingDc_state { + struct wbint_PingDc orig; + struct wbint_PingDc tmp; + TALLOC_CTX *out_mem_ctx; + NTSTATUS (*dispatch_recv)(struct tevent_req *req, TALLOC_CTX *mem_ctx); +}; + +static void rpccli_wbint_PingDc_done(struct tevent_req *subreq); + +struct tevent_req *rpccli_wbint_PingDc_send(TALLOC_CTX *mem_ctx, + struct tevent_context *ev, + struct rpc_pipe_client *cli) +{ + struct tevent_req *req; + struct rpccli_wbint_PingDc_state *state; + struct tevent_req *subreq; + + req = tevent_req_create(mem_ctx, &state, + struct rpccli_wbint_PingDc_state); + if (req == NULL) { + return NULL; + } + state->out_mem_ctx = NULL; + state->dispatch_recv = cli->dispatch_recv; + + /* In parameters */ + + /* Out parameters */ + + /* Result */ + ZERO_STRUCT(state->orig.out.result); + + /* make a temporary copy, that we pass to the dispatch function */ + state->tmp = state->orig; + + subreq = cli->dispatch_send(state, ev, cli, + &ndr_table_wbint, + NDR_WBINT_PINGDC, + &state->tmp); + if (tevent_req_nomem(subreq, req)) { + return tevent_req_post(req, ev); + } + tevent_req_set_callback(subreq, rpccli_wbint_PingDc_done, req); + return req; +} + +static void rpccli_wbint_PingDc_done(struct tevent_req *subreq) +{ + struct tevent_req *req = tevent_req_callback_data( + subreq, struct tevent_req); + struct rpccli_wbint_PingDc_state *state = tevent_req_data( + req, struct rpccli_wbint_PingDc_state); + NTSTATUS status; + TALLOC_CTX *mem_ctx; + + if (state->out_mem_ctx) { + mem_ctx = state->out_mem_ctx; + } else { + mem_ctx = state; + } + + status = state->dispatch_recv(subreq, mem_ctx); + TALLOC_FREE(subreq); + if (!NT_STATUS_IS_OK(status)) { + tevent_req_nterror(req, status); + return; + } + + /* Copy out parameters */ + + /* Copy result */ + state->orig.out.result = state->tmp.out.result; + + /* Reset temporary structure */ + ZERO_STRUCT(state->tmp); + + tevent_req_done(req); +} + +NTSTATUS rpccli_wbint_PingDc_recv(struct tevent_req *req, + TALLOC_CTX *mem_ctx, + NTSTATUS *result) +{ + struct rpccli_wbint_PingDc_state *state = tevent_req_data( + req, struct rpccli_wbint_PingDc_state); + NTSTATUS status; + + if (tevent_req_is_nterror(req, &status)) { + tevent_req_received(req); + return status; + } + + /* Steal possbile out parameters to the callers context */ + talloc_steal(mem_ctx, state->out_mem_ctx); + + /* Return result */ + *result = state->orig.out.result; + + tevent_req_received(req); + return NT_STATUS_OK; +} + +NTSTATUS rpccli_wbint_PingDc(struct rpc_pipe_client *cli, + TALLOC_CTX *mem_ctx) +{ + struct wbint_PingDc r; + NTSTATUS status; + + /* In parameters */ + + status = cli->dispatch(cli, + mem_ctx, + &ndr_table_wbint, + NDR_WBINT_PINGDC, + &r); + + if (!NT_STATUS_IS_OK(status)) { + return status; + } + + if (NT_STATUS_IS_ERR(status)) { + return status; + } + + /* Return variables */ + + /* Return result */ + return r.out.result; +} + struct rpccli_wbint_SetMapping_state { struct wbint_SetMapping orig; struct wbint_SetMapping tmp; diff --git a/source3/librpc/gen_ndr/cli_wbint.h b/source3/librpc/gen_ndr/cli_wbint.h index b08ef3fef1..4528d43efc 100644 --- a/source3/librpc/gen_ndr/cli_wbint.h +++ b/source3/librpc/gen_ndr/cli_wbint.h @@ -248,6 +248,14 @@ NTSTATUS rpccli_wbint_ChangeMachineAccount_recv(struct tevent_req *req, NTSTATUS *result); NTSTATUS rpccli_wbint_ChangeMachineAccount(struct rpc_pipe_client *cli, TALLOC_CTX *mem_ctx); +struct tevent_req *rpccli_wbint_PingDc_send(TALLOC_CTX *mem_ctx, + struct tevent_context *ev, + struct rpc_pipe_client *cli); +NTSTATUS rpccli_wbint_PingDc_recv(struct tevent_req *req, + TALLOC_CTX *mem_ctx, + NTSTATUS *result); +NTSTATUS rpccli_wbint_PingDc(struct rpc_pipe_client *cli, + TALLOC_CTX *mem_ctx); struct tevent_req *rpccli_wbint_SetMapping_send(TALLOC_CTX *mem_ctx, struct tevent_context *ev, struct rpc_pipe_client *cli, diff --git a/source3/librpc/gen_ndr/ndr_wbint.c b/source3/librpc/gen_ndr/ndr_wbint.c index 97b29761ee..50f781cc20 100644 --- a/source3/librpc/gen_ndr/ndr_wbint.c +++ b/source3/librpc/gen_ndr/ndr_wbint.c @@ -2232,6 +2232,47 @@ _PUBLIC_ void ndr_print_wbint_ChangeMachineAccount(struct ndr_print *ndr, const ndr->depth--; } +static enum ndr_err_code ndr_push_wbint_PingDc(struct ndr_push *ndr, int flags, const struct wbint_PingDc *r) +{ + if (flags & NDR_IN) { + } + if (flags & NDR_OUT) { + NDR_CHECK(ndr_push_NTSTATUS(ndr, NDR_SCALARS, r->out.result)); + } + return NDR_ERR_SUCCESS; +} + +static enum ndr_err_code ndr_pull_wbint_PingDc(struct ndr_pull *ndr, int flags, struct wbint_PingDc *r) +{ + if (flags & NDR_IN) { + } + if (flags & NDR_OUT) { + NDR_CHECK(ndr_pull_NTSTATUS(ndr, NDR_SCALARS, &r->out.result)); + } + return NDR_ERR_SUCCESS; +} + +_PUBLIC_ void ndr_print_wbint_PingDc(struct ndr_print *ndr, const char *name, int flags, const struct wbint_PingDc *r) +{ + ndr_print_struct(ndr, name, "wbint_PingDc"); + ndr->depth++; + if (flags & NDR_SET_VALUES) { + ndr->flags |= LIBNDR_PRINT_SET_VALUES; + } + if (flags & NDR_IN) { + ndr_print_struct(ndr, "in", "wbint_PingDc"); + ndr->depth++; + ndr->depth--; + } + if (flags & NDR_OUT) { + ndr_print_struct(ndr, "out", "wbint_PingDc"); + ndr->depth++; + ndr_print_NTSTATUS(ndr, "result", r->out.result); + ndr->depth--; + } + ndr->depth--; +} + static enum ndr_err_code ndr_push_wbint_SetMapping(struct ndr_push *ndr, int flags, const struct wbint_SetMapping *r) { if (flags & NDR_IN) { @@ -2567,6 +2608,14 @@ static const struct ndr_interface_call wbint_calls[] = { false, }, { + "wbint_PingDc", + sizeof(struct wbint_PingDc), + (ndr_push_flags_fn_t) ndr_push_wbint_PingDc, + (ndr_pull_flags_fn_t) ndr_pull_wbint_PingDc, + (ndr_print_function_t) ndr_print_wbint_PingDc, + false, + }, + { "wbint_SetMapping", sizeof(struct wbint_SetMapping), (ndr_push_flags_fn_t) ndr_push_wbint_SetMapping, @@ -2619,7 +2668,7 @@ const struct ndr_interface_table ndr_table_wbint = { NDR_WBINT_VERSION }, .helpstring = NDR_WBINT_HELPSTRING, - .num_calls = 23, + .num_calls = 24, .calls = wbint_calls, .endpoints = &wbint_endpoints, .authservices = &wbint_authservices diff --git a/source3/librpc/gen_ndr/ndr_wbint.h b/source3/librpc/gen_ndr/ndr_wbint.h index e163ff3674..4a381ccfb2 100644 --- a/source3/librpc/gen_ndr/ndr_wbint.h +++ b/source3/librpc/gen_ndr/ndr_wbint.h @@ -51,13 +51,15 @@ extern const struct ndr_interface_table ndr_table_wbint; #define NDR_WBINT_CHANGEMACHINEACCOUNT (0x13) -#define NDR_WBINT_SETMAPPING (0x14) +#define NDR_WBINT_PINGDC (0x14) -#define NDR_WBINT_REMOVEMAPPING (0x15) +#define NDR_WBINT_SETMAPPING (0x15) -#define NDR_WBINT_SETHWM (0x16) +#define NDR_WBINT_REMOVEMAPPING (0x16) -#define NDR_WBINT_CALL_COUNT (23) +#define NDR_WBINT_SETHWM (0x17) + +#define NDR_WBINT_CALL_COUNT (24) enum ndr_err_code ndr_push_wbint_userinfo(struct ndr_push *ndr, int ndr_flags, const struct wbint_userinfo *r); enum ndr_err_code ndr_pull_wbint_userinfo(struct ndr_pull *ndr, int ndr_flags, struct wbint_userinfo *r); void ndr_print_wbint_userinfo(struct ndr_print *ndr, const char *name, const struct wbint_userinfo *r); @@ -99,6 +101,7 @@ void ndr_print_wbint_DsGetDcName(struct ndr_print *ndr, const char *name, int fl void ndr_print_wbint_LookupRids(struct ndr_print *ndr, const char *name, int flags, const struct wbint_LookupRids *r); void ndr_print_wbint_CheckMachineAccount(struct ndr_print *ndr, const char *name, int flags, const struct wbint_CheckMachineAccount *r); void ndr_print_wbint_ChangeMachineAccount(struct ndr_print *ndr, const char *name, int flags, const struct wbint_ChangeMachineAccount *r); +void ndr_print_wbint_PingDc(struct ndr_print *ndr, const char *name, int flags, const struct wbint_PingDc *r); void ndr_print_wbint_SetMapping(struct ndr_print *ndr, const char *name, int flags, const struct wbint_SetMapping *r); void ndr_print_wbint_RemoveMapping(struct ndr_print *ndr, const char *name, int flags, const struct wbint_RemoveMapping *r); void ndr_print_wbint_SetHWM(struct ndr_print *ndr, const char *name, int flags, const struct wbint_SetHWM *r); diff --git a/source3/librpc/gen_ndr/srv_wbint.c b/source3/librpc/gen_ndr/srv_wbint.c index 0f39cd93e1..efd9be6b7a 100644 --- a/source3/librpc/gen_ndr/srv_wbint.c +++ b/source3/librpc/gen_ndr/srv_wbint.c @@ -1610,6 +1610,79 @@ static bool api_wbint_ChangeMachineAccount(pipes_struct *p) return true; } +static bool api_wbint_PingDc(pipes_struct *p) +{ + const struct ndr_interface_call *call; + struct ndr_pull *pull; + struct ndr_push *push; + enum ndr_err_code ndr_err; + DATA_BLOB blob; + struct wbint_PingDc *r; + + call = &ndr_table_wbint.calls[NDR_WBINT_PINGDC]; + + r = talloc(talloc_tos(), struct wbint_PingDc); + if (r == NULL) { + return false; + } + + if (!prs_data_blob(&p->in_data.data, &blob, r)) { + talloc_free(r); + return false; + } + + pull = ndr_pull_init_blob(&blob, r, NULL); + if (pull == NULL) { + talloc_free(r); + return false; + } + + pull->flags |= LIBNDR_FLAG_REF_ALLOC; + ndr_err = call->ndr_pull(pull, NDR_IN, r); + if (!NDR_ERR_CODE_IS_SUCCESS(ndr_err)) { + talloc_free(r); + return false; + } + + if (DEBUGLEVEL >= 10) { + NDR_PRINT_IN_DEBUG(wbint_PingDc, r); + } + + r->out.result = _wbint_PingDc(p, r); + + if (p->rng_fault_state) { + talloc_free(r); + /* Return true here, srv_pipe_hnd.c will take care */ + return true; + } + + if (DEBUGLEVEL >= 10) { + NDR_PRINT_OUT_DEBUG(wbint_PingDc, r); + } + + push = ndr_push_init_ctx(r, NULL); + if (push == NULL) { + talloc_free(r); + return false; + } + + ndr_err = call->ndr_push(push, NDR_OUT, r); + if (!NDR_ERR_CODE_IS_SUCCESS(ndr_err)) { + talloc_free(r); + return false; + } + + blob = ndr_push_blob(push); + if (!prs_copy_data_in(&p->out_data.rdata, (const char *)blob.data, (uint32_t)blob.length)) { + talloc_free(r); + return false; + } + + talloc_free(r); + + return true; +} + static bool api_wbint_SetMapping(pipes_struct *p) { const struct ndr_interface_call *call; @@ -1853,6 +1926,7 @@ static struct api_struct api_wbint_cmds[] = {"WBINT_LOOKUPRIDS", NDR_WBINT_LOOKUPRIDS, api_wbint_LookupRids}, {"WBINT_CHECKMACHINEACCOUNT", NDR_WBINT_CHECKMACHINEACCOUNT, api_wbint_CheckMachineAccount}, {"WBINT_CHANGEMACHINEACCOUNT", NDR_WBINT_CHANGEMACHINEACCOUNT, api_wbint_ChangeMachineAccount}, + {"WBINT_PINGDC", NDR_WBINT_PINGDC, api_wbint_PingDc}, {"WBINT_SETMAPPING", NDR_WBINT_SETMAPPING, api_wbint_SetMapping}, {"WBINT_REMOVEMAPPING", NDR_WBINT_REMOVEMAPPING, api_wbint_RemoveMapping}, {"WBINT_SETHWM", NDR_WBINT_SETHWM, api_wbint_SetHWM}, @@ -2115,6 +2189,12 @@ NTSTATUS rpc_wbint_dispatch(struct rpc_pipe_client *cli, TALLOC_CTX *mem_ctx, co return NT_STATUS_OK; } + case NDR_WBINT_PINGDC: { + struct wbint_PingDc *r = (struct wbint_PingDc *)_r; + r->out.result = _wbint_PingDc(cli->pipes_struct, r); + return NT_STATUS_OK; + } + case NDR_WBINT_SETMAPPING: { struct wbint_SetMapping *r = (struct wbint_SetMapping *)_r; r->out.result = _wbint_SetMapping(cli->pipes_struct, r); diff --git a/source3/librpc/gen_ndr/srv_wbint.h b/source3/librpc/gen_ndr/srv_wbint.h index c8c04fb3cc..716f1ac9d1 100644 --- a/source3/librpc/gen_ndr/srv_wbint.h +++ b/source3/librpc/gen_ndr/srv_wbint.h @@ -21,6 +21,7 @@ NTSTATUS _wbint_DsGetDcName(pipes_struct *p, struct wbint_DsGetDcName *r); NTSTATUS _wbint_LookupRids(pipes_struct *p, struct wbint_LookupRids *r); NTSTATUS _wbint_CheckMachineAccount(pipes_struct *p, struct wbint_CheckMachineAccount *r); NTSTATUS _wbint_ChangeMachineAccount(pipes_struct *p, struct wbint_ChangeMachineAccount *r); +NTSTATUS _wbint_PingDc(pipes_struct *p, struct wbint_PingDc *r); NTSTATUS _wbint_SetMapping(pipes_struct *p, struct wbint_SetMapping *r); NTSTATUS _wbint_RemoveMapping(pipes_struct *p, struct wbint_RemoveMapping *r); NTSTATUS _wbint_SetHWM(pipes_struct *p, struct wbint_SetHWM *r); @@ -46,6 +47,7 @@ NTSTATUS _wbint_DsGetDcName(pipes_struct *p, struct wbint_DsGetDcName *r); NTSTATUS _wbint_LookupRids(pipes_struct *p, struct wbint_LookupRids *r); NTSTATUS _wbint_CheckMachineAccount(pipes_struct *p, struct wbint_CheckMachineAccount *r); NTSTATUS _wbint_ChangeMachineAccount(pipes_struct *p, struct wbint_ChangeMachineAccount *r); +NTSTATUS _wbint_PingDc(pipes_struct *p, struct wbint_PingDc *r); NTSTATUS _wbint_SetMapping(pipes_struct *p, struct wbint_SetMapping *r); NTSTATUS _wbint_RemoveMapping(pipes_struct *p, struct wbint_RemoveMapping *r); NTSTATUS _wbint_SetHWM(pipes_struct *p, struct wbint_SetHWM *r); diff --git a/source3/librpc/gen_ndr/wbint.h b/source3/librpc/gen_ndr/wbint.h index 962a87ea26..96b7800624 100644 --- a/source3/librpc/gen_ndr/wbint.h +++ b/source3/librpc/gen_ndr/wbint.h @@ -303,6 +303,14 @@ struct wbint_ChangeMachineAccount { }; +struct wbint_PingDc { + struct { + NTSTATUS result; + } out; + +}; + + struct wbint_SetMapping { struct { struct dom_sid *sid;/* [ref] */ diff --git a/source3/librpc/idl/wbint.idl b/source3/librpc/idl/wbint.idl index e44f179723..432d59e086 100644 --- a/source3/librpc/idl/wbint.idl +++ b/source3/librpc/idl/wbint.idl @@ -150,6 +150,9 @@ interface wbint NTSTATUS wbint_ChangeMachineAccount( ); + NTSTATUS wbint_PingDc( + ); + typedef [public] enum { WBINT_ID_TYPE_NOT_SPECIFIED, WBINT_ID_TYPE_UID, diff --git a/source3/libsmb/async_smb.c b/source3/libsmb/async_smb.c index 6edfe514b8..8b9cf091c6 100644 --- a/source3/libsmb/async_smb.c +++ b/source3/libsmb/async_smb.c @@ -153,180 +153,6 @@ void cli_set_error(struct cli_state *cli, NTSTATUS status) } /** - * @brief Find the smb_cmd offset of the last command pushed - * @param[in] buf The buffer we're building up - * @retval Where can we put our next andx cmd? - * - * While chaining requests, the "next" request we're looking at needs to put - * its SMB_Command before the data the previous request already built up added - * to the chain. Find the offset to the place where we have to put our cmd. - */ - -static bool find_andx_cmd_ofs(uint8_t *buf, size_t *pofs) -{ - uint8_t cmd; - size_t ofs; - - cmd = CVAL(buf, smb_com); - - SMB_ASSERT(is_andx_req(cmd)); - - ofs = smb_vwv0; - - while (CVAL(buf, ofs) != 0xff) { - - if (!is_andx_req(CVAL(buf, ofs))) { - return false; - } - - /* - * ofs is from start of smb header, so add the 4 length - * bytes. The next cmd is right after the wct field. - */ - ofs = SVAL(buf, ofs+2) + 4 + 1; - - SMB_ASSERT(ofs+4 < talloc_get_size(buf)); - } - - *pofs = ofs; - return true; -} - -/** - * @brief Do the smb chaining at a buffer level - * @param[in] poutbuf Pointer to the talloc'ed buffer to be modified - * @param[in] smb_command The command that we want to issue - * @param[in] wct How many words? - * @param[in] vwv The words, already in network order - * @param[in] bytes_alignment How shall we align "bytes"? - * @param[in] num_bytes How many bytes? - * @param[in] bytes The data the request ships - * - * smb_splice_chain() adds the vwv and bytes to the request already present in - * *poutbuf. - */ - -bool smb_splice_chain(uint8_t **poutbuf, uint8_t smb_command, - uint8_t wct, const uint16_t *vwv, - size_t bytes_alignment, - uint32_t num_bytes, const uint8_t *bytes) -{ - uint8_t *outbuf; - size_t old_size, new_size; - size_t ofs; - size_t chain_padding = 0; - size_t bytes_padding = 0; - bool first_request; - - old_size = talloc_get_size(*poutbuf); - - /* - * old_size == smb_wct means we're pushing the first request in for - * libsmb/ - */ - - first_request = (old_size == smb_wct); - - if (!first_request && ((old_size % 4) != 0)) { - /* - * Align the wct field of subsequent requests to a 4-byte - * boundary - */ - chain_padding = 4 - (old_size % 4); - } - - /* - * After the old request comes the new wct field (1 byte), the vwv's - * and the num_bytes field. After at we might need to align the bytes - * given to us to "bytes_alignment", increasing the num_bytes value. - */ - - new_size = old_size + chain_padding + 1 + wct * sizeof(uint16_t) + 2; - - if ((bytes_alignment != 0) && ((new_size % bytes_alignment) != 0)) { - bytes_padding = bytes_alignment - (new_size % bytes_alignment); - } - - new_size += bytes_padding + num_bytes; - - if ((smb_command != SMBwriteX) && (new_size > 0xffff)) { - DEBUG(1, ("splice_chain: %u bytes won't fit\n", - (unsigned)new_size)); - return false; - } - - outbuf = TALLOC_REALLOC_ARRAY(NULL, *poutbuf, uint8_t, new_size); - if (outbuf == NULL) { - DEBUG(0, ("talloc failed\n")); - return false; - } - *poutbuf = outbuf; - - if (first_request) { - SCVAL(outbuf, smb_com, smb_command); - } else { - size_t andx_cmd_ofs; - - if (!find_andx_cmd_ofs(outbuf, &andx_cmd_ofs)) { - DEBUG(1, ("invalid command chain\n")); - *poutbuf = TALLOC_REALLOC_ARRAY( - NULL, *poutbuf, uint8_t, old_size); - return false; - } - - if (chain_padding != 0) { - memset(outbuf + old_size, 0, chain_padding); - old_size += chain_padding; - } - - SCVAL(outbuf, andx_cmd_ofs, smb_command); - SSVAL(outbuf, andx_cmd_ofs + 2, old_size - 4); - } - - ofs = old_size; - - /* - * Push the chained request: - * - * wct field - */ - - SCVAL(outbuf, ofs, wct); - ofs += 1; - - /* - * vwv array - */ - - memcpy(outbuf + ofs, vwv, sizeof(uint16_t) * wct); - ofs += sizeof(uint16_t) * wct; - - /* - * bcc (byte count) - */ - - SSVAL(outbuf, ofs, num_bytes + bytes_padding); - ofs += sizeof(uint16_t); - - /* - * padding - */ - - if (bytes_padding != 0) { - memset(outbuf + ofs, 0, bytes_padding); - ofs += bytes_padding; - } - - /* - * The bytes field - */ - - memcpy(outbuf + ofs, bytes, num_bytes); - - return true; -} - -/** * Figure out if there is an andx command behind the current one * @param[in] buf The smb buffer to look at * @param[in] ofs The offset to the wct field that is followed by the cmd @@ -556,6 +382,7 @@ struct tevent_req *cli_smb_req_create(TALLOC_CTX *mem_ctx, { struct tevent_req *result; struct cli_smb_state *state; + struct timeval endtime; if (iov_count > MAX_SMB_IOV) { /* @@ -596,6 +423,10 @@ struct tevent_req *cli_smb_req_create(TALLOC_CTX *mem_ctx, } state->iov_count = iov_count + 3; + endtime = timeval_current_ofs(0, cli->timeout * 1000); + if (!tevent_req_set_endtime(result, ev, endtime)) { + tevent_req_nomem(NULL, result); + } return result; } @@ -679,12 +510,10 @@ static NTSTATUS cli_smb_req_iov_send(struct tevent_req *req, } iov[0].iov_base = (void *)buf; iov[0].iov_len = talloc_get_size(buf); - subreq = writev_send(state, state->ev, state->cli->outgoing, - state->cli->fd, false, iov, 1); - } else { - subreq = writev_send(state, state->ev, state->cli->outgoing, - state->cli->fd, false, iov, iov_count); + iov_count = 1; } + subreq = writev_send(state, state->ev, state->cli->outgoing, + state->cli->fd, false, iov, iov_count); if (subreq == NULL) { return NT_STATUS_NO_MEMORY; } diff --git a/source3/libsmb/cliconnect.c b/source3/libsmb/cliconnect.c index 112143ca96..715ea91382 100644 --- a/source3/libsmb/cliconnect.c +++ b/source3/libsmb/cliconnect.c @@ -1671,6 +1671,7 @@ static void cli_negprot_done(struct tevent_req *subreq) status = cli_smb_recv(subreq, 1, &wct, &vwv, &num_bytes, &bytes); if (!NT_STATUS_IS_OK(status)) { TALLOC_FREE(subreq); + tevent_req_nterror(req, status); return; } diff --git a/source3/libsmb/conncache.c b/source3/libsmb/conncache.c index b440d61048..85a09cc9ce 100644 --- a/source3/libsmb/conncache.c +++ b/source3/libsmb/conncache.c @@ -7,17 +7,18 @@ Copyright (C) Andrew Bartlett 2002 Copyright (C) Gerald (Jerry) Carter 2003 Copyright (C) Marc VanHeyningen 2008 - + Copyright (C) Volker Lendecke 2009 + This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. - + This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. - + You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/>. */ @@ -37,11 +38,6 @@ /** - * prefix used for all entries put into the general cache - */ -static const char NEGATIVE_CONN_CACHE_PREFIX[] = "NEG_CONN_CACHE"; - -/** * Marshalls the domain and server name into the key for the gencache * record * @@ -53,15 +49,16 @@ static const char NEGATIVE_CONN_CACHE_PREFIX[] = "NEG_CONN_CACHE"; */ static char *negative_conn_cache_keystr(const char *domain, const char *server) { - const char NEGATIVE_CONN_CACHE_KEY_FMT[] = "%s/%s,%s"; char *keystr = NULL; - SMB_ASSERT(domain != NULL); + if (domain == NULL) { + return NULL; + } if (server == NULL) server = ""; - keystr = talloc_asprintf(talloc_tos(),NEGATIVE_CONN_CACHE_KEY_FMT, - NEGATIVE_CONN_CACHE_PREFIX, domain, server); + keystr = talloc_asprintf(talloc_tos(), "NEG_CONN_CACHE/%s,%s", + domain, server); if (keystr == NULL) { DEBUG(0, ("negative_conn_cache_keystr: malloc error\n")); } @@ -100,13 +97,16 @@ static char *negative_conn_cache_valuestr(NTSTATUS status) */ static NTSTATUS negative_conn_cache_valuedecode(const char *value) { - NTSTATUS result = NT_STATUS_OK; + unsigned int v = NT_STATUS_V(NT_STATUS_INTERNAL_ERROR);; - SMB_ASSERT(value != NULL); - if (sscanf(value, "%x", &(NT_STATUS_V(result))) != 1) - DEBUG(0, ("negative_conn_cache_valuestr: unable to parse " + if (value != NULL) { + return NT_STATUS_INTERNAL_ERROR; + } + if (sscanf(value, "%x", &v) != 1) { + DEBUG(0, ("negative_conn_cache_valuedecode: unable to parse " "value field '%s'\n", value)); - return result; + } + return NT_STATUS(v); } /** @@ -143,7 +143,7 @@ NTSTATUS check_negative_conn_cache( const char *domain, const char *server) if (key == NULL) goto done; - if (gencache_get(key, &value, (time_t *) NULL)) + if (gencache_get(key, &value, NULL)) result = negative_conn_cache_valuedecode(value); done: DEBUG(9,("check_negative_conn_cache returning result %d for domain %s " @@ -154,29 +154,6 @@ NTSTATUS check_negative_conn_cache( const char *domain, const char *server) } /** - * Delete any negative cache entry for the given domain/server - * - * @param[in] domain - * @param[in] server may be either a FQDN or an IP address - */ -void delete_negative_conn_cache(const char *domain, const char *server) -{ - char *key = NULL; - - key = negative_conn_cache_keystr(domain, server); - if (key == NULL) - goto done; - - gencache_del(key); - DEBUG(9,("delete_negative_conn_cache removing domain %s server %s\n", - domain, server)); - done: - TALLOC_FREE(key); - return; -} - - -/** * Add an entry to the failed connection cache * * @param[in] domain @@ -189,7 +166,10 @@ void add_failed_connection_entry(const char *domain, const char *server, char *key = NULL; char *value = NULL; - SMB_ASSERT(!NT_STATUS_IS_OK(result)); + if (NT_STATUS_IS_OK(result)) { + /* Nothing failed here */ + return; + } key = negative_conn_cache_keystr(domain, server); if (key == NULL) { @@ -204,15 +184,14 @@ void add_failed_connection_entry(const char *domain, const char *server, } if (gencache_set(key, value, - time((time_t *) NULL) - + FAILED_CONNECTION_CACHE_TIMEOUT)) + time(NULL) + FAILED_CONNECTION_CACHE_TIMEOUT)) DEBUG(9,("add_failed_connection_entry: added domain %s (%s) " "to failed conn cache\n", domain, server )); else DEBUG(1,("add_failed_connection_entry: failed to add " "domain %s (%s) to failed conn cache\n", domain, server)); - + done: TALLOC_FREE(key); TALLOC_FREE(value); @@ -220,15 +199,6 @@ void add_failed_connection_entry(const char *domain, const char *server, } /** - * Deletes all records from the negative connection cache in all domains - */ -void flush_negative_conn_cache( void ) -{ - flush_negative_conn_cache_for_domain("*"); -} - - -/** * Deletes all records for a specified domain from the negative connection * cache * @@ -246,10 +216,10 @@ void flush_negative_conn_cache_for_domain(const char *domain) goto done; } - gencache_iterate(delete_matches, (void *) NULL, key_pattern); + gencache_iterate(delete_matches, NULL, key_pattern); DEBUG(8, ("flush_negative_conn_cache_for_domain: flushed domain %s\n", domain)); - + done: TALLOC_FREE(key_pattern); return; diff --git a/source3/libsmb/errormap.c b/source3/libsmb/errormap.c index 0285f22be4..48b3eb32d9 100644 --- a/source3/libsmb/errormap.c +++ b/source3/libsmb/errormap.c @@ -146,7 +146,7 @@ static const struct { {ERRDOS, 87, NT_STATUS_BAD_WORKING_SET_LIMIT}, {ERRDOS, 87, NT_STATUS_INCOMPATIBLE_FILE_MAP}, {ERRDOS, 87, NT_STATUS_SECTION_PROTECTION}, - {ERRDOS, 282, NT_STATUS_EAS_NOT_SUPPORTED}, + {ERRDOS, ERReasnotsupported, NT_STATUS_EAS_NOT_SUPPORTED}, {ERRDOS, 255, NT_STATUS_EA_TOO_LARGE}, {ERRHRD, ERRgeneral, NT_STATUS_NONEXISTENT_EA_ENTRY}, {ERRHRD, ERRgeneral, NT_STATUS_NO_EAS_ON_FILE}, @@ -708,7 +708,7 @@ static const struct { {ERRDOS, 276, NT_STATUS_NONEXISTENT_EA_ENTRY}, {ERRDOS, 277, NT_STATUS_NONEXISTENT_EA_ENTRY}, {ERRDOS, 278, NT_STATUS_NONEXISTENT_EA_ENTRY}, - {ERRDOS, 282, NT_STATUS_EAS_NOT_SUPPORTED}, + {ERRDOS, ERReasnotsupported, NT_STATUS_EAS_NOT_SUPPORTED}, {ERRDOS, 288, NT_STATUS_MUTANT_NOT_OWNED}, {ERRDOS, 298, NT_STATUS_SEMAPHORE_LIMIT_EXCEEDED}, {ERRDOS, 299, NT_STATUS(0x8000000d)}, @@ -841,7 +841,7 @@ static const struct { {ERRHRD, 276, NT_STATUS_NONEXISTENT_EA_ENTRY}, {ERRHRD, 277, NT_STATUS_NONEXISTENT_EA_ENTRY}, {ERRHRD, 278, NT_STATUS_NONEXISTENT_EA_ENTRY}, - {ERRHRD, 282, NT_STATUS_EAS_NOT_SUPPORTED}, + {ERRHRD, ERReasnotsupported, NT_STATUS_EAS_NOT_SUPPORTED}, {ERRHRD, 288, NT_STATUS_MUTANT_NOT_OWNED}, {ERRHRD, 298, NT_STATUS_SEMAPHORE_LIMIT_EXCEEDED}, {ERRHRD, 299, NT_STATUS(0x8000000d)}, diff --git a/source3/locale/net/de.po b/source3/locale/net/de.po index a336936343..e1ccb32ad7 100644 --- a/source3/locale/net/de.po +++ b/source3/locale/net/de.po @@ -1,5 +1,6 @@ # net message translation (german). # Copyright (C) 2009 Kai Blin <kai@samba.org> +# Copyright (C) 2009 André Hentschel <nerv@dawncrow.de> # This file is distributed under the same license as the samba package. # #, fuzzy @@ -7,9 +8,10 @@ msgid "" msgstr "" "Project-Id-Version: @PACKAGE@\n" "Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2009-08-11 09:01+0200\n" -"PO-Revision-Date: 2009-08-06 20:45+0200\n" -"Last-Translator: Kai Blin <kai@samba.org>\n" +"POT-Creation-Date: 2010-01-05 09:23+0100\n" +"PO-Revision-Date: 2009-12-26 19:20+0100\n" +"Last-Translator: André Hentschel <nerv@dawncrow.de>\n" +"Language-Team: \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" @@ -33,216 +35,269 @@ msgid "" "This function will change the ADS Domain member machine account password in the secrets.tdb file!\n" msgstr "" -#: ../../utils/net.c:150 ../../utils/net.c:228 +#: ../../utils/net.c:132 +msgid "Failed to open secrets.tdb.\n" +msgstr "" + +#: ../../utils/net.c:139 ../../utils/net.c:157 ../../utils/net_conf.c:1136 ../../utils/net_help.c:36 ../../utils/net_rap.c:161 ../../utils/net_rap.c:302 ../../utils/net_rap.c:467 ../../utils/net_rap.c:750 ../../utils/net_rap.c:891 +#: ../../utils/net_rap.c:1002 ../../utils/net_rap.c:1193 ../../utils/net_rpc.c:979 ../../utils/net_rpc.c:2820 ../../utils/net_rpc.c:4923 ../../utils/net_rpc.c:6962 ../../utils/net_rpc.c:7067 ../../utils/net_util.c:586 +msgid "Usage:\n" +msgstr "Verwendung:\n" + +#: ../../utils/net.c:141 +#, c-format +msgid "" +" net setauthuser -U user[%%password] \n" +" Set the auth user account to userpassword. Prompt for password if not specified.\n" +msgstr "" + +#: ../../utils/net.c:146 ../../utils/net.c:164 +msgid "" +" net setauthuser delete\n" +" Delete the auth user setting.\n" +msgstr "" + +#: ../../utils/net.c:159 +#, c-format +msgid "" +" net setauthuser -U user[%%password]\n" +" Set the auth user account to userpassword. Prompt for password if not specified.\n" +msgstr "" + +#: ../../utils/net.c:169 +msgid "the auth user" +msgstr "" + +#: ../../utils/net.c:171 +msgid "Failed to get the auth users password.\n" +msgstr "" + +#: ../../utils/net.c:177 +msgid "error storing auth user name\n" +msgstr "" + +#: ../../utils/net.c:183 +msgid "error storing auth user domain\n" +msgstr "" + +#: ../../utils/net.c:189 +msgid "error storing auth user password\n" +msgstr "" + +#: ../../utils/net.c:213 +msgid "No authorised user configured\n" +msgstr "" + +#: ../../utils/net.c:255 ../../utils/net.c:333 #, c-format msgid "Unable to open secrets.tdb. Can't fetch domain SID for name: %s\n" msgstr "" -#: ../../utils/net.c:163 ../../utils/net.c:251 +#: ../../utils/net.c:268 ../../utils/net.c:356 #, c-format msgid "SID for domain %s is: %s\n" msgstr "" -#: ../../utils/net.c:175 +#: ../../utils/net.c:280 msgid "usage: net setlocalsid S-1-5-21-x-y-z\n" msgstr "" -#: ../../utils/net.c:195 +#: ../../utils/net.c:300 msgid "usage: net setdomainsid S-1-5-21-x-y-z\n" msgstr "" -#: ../../utils/net.c:213 +#: ../../utils/net.c:318 msgid "usage: net getdomainsid\n" msgstr "" -#: ../../utils/net.c:238 +#: ../../utils/net.c:343 msgid "Could not fetch local SID\n" msgstr "" -#: ../../utils/net.c:242 +#: ../../utils/net.c:347 #, c-format msgid "SID for local machine %s is: %s\n" msgstr "" -#: ../../utils/net.c:246 +#: ../../utils/net.c:351 msgid "Could not fetch domain SID\n" msgstr "" -#: ../../utils/net.c:263 +#: ../../utils/net.c:368 #, c-format msgid "get_maxrid: Could not search %s\n" msgstr "" -#: ../../utils/net.c:297 +#: ../../utils/net.c:402 msgid "usage: net maxrid\n" msgstr "" -#: ../../utils/net.c:302 +#: ../../utils/net.c:407 msgid "can't get current maximum rid\n" msgstr "" -#: ../../utils/net.c:306 +#: ../../utils/net.c:411 #, c-format msgid "Currently used maximum rid: %d\n" msgstr "" -#: ../../utils/net.c:317 +#: ../../utils/net.c:422 msgid "Run functions using RPC transport" -msgstr "" +msgstr "RPC Protokoll nutzen" -#: ../../utils/net.c:318 +#: ../../utils/net.c:423 msgid " Use 'net help rpc' to get more extensive information about 'net rpc' commands." msgstr "" -#: ../../utils/net.c:325 +#: ../../utils/net.c:430 msgid "Run functions using RAP transport" -msgstr "" +msgstr "RAP Protokoll nutzen" -#: ../../utils/net.c:326 +#: ../../utils/net.c:431 msgid " Use 'net help rap' to get more extensive information about 'net rap' commands." msgstr "" -#: ../../utils/net.c:333 +#: ../../utils/net.c:438 msgid "Run functions using ADS transport" -msgstr "" +msgstr "ADS Protokoll nutzen" -#: ../../utils/net.c:334 +#: ../../utils/net.c:439 msgid " Use 'net help ads' to get more extensive information about 'net ads' commands." msgstr "" -#: ../../utils/net.c:343 +#: ../../utils/net.c:448 msgid "Functions on remote opened files" -msgstr "" +msgstr "Freigegebene Dateien verwalten" -#: ../../utils/net.c:344 +#: ../../utils/net.c:449 msgid " Use 'net help file' to get more information about 'net file' commands." msgstr "" -#: ../../utils/net.c:351 +#: ../../utils/net.c:456 msgid "Functions on shares" -msgstr "" +msgstr "Freigaben verwalten" -#: ../../utils/net.c:352 +#: ../../utils/net.c:457 msgid " Use 'net help share' to get more information about 'net share' commands." msgstr "" -#: ../../utils/net.c:359 +#: ../../utils/net.c:464 msgid "Manage sessions" -msgstr "" +msgstr "Sitzungen verwalten" -#: ../../utils/net.c:360 +#: ../../utils/net.c:465 msgid " Use 'net help session' to get more information about 'net session' commands." msgstr "" -#: ../../utils/net.c:367 ../../utils/net_rap.c:1291 +#: ../../utils/net.c:472 ../../utils/net_rap.c:1291 msgid "List servers in workgroup" -msgstr "" +msgstr "Server der Arbeitsgruppe auflisten" -#: ../../utils/net.c:368 +#: ../../utils/net.c:473 msgid " Use 'net help server' to get more information about 'net server' commands." msgstr "" -#: ../../utils/net.c:375 +#: ../../utils/net.c:480 msgid "List domains/workgroups on network" -msgstr "" +msgstr "Domänen/Arbeitsgruppen im Netzwerk auflisten" -#: ../../utils/net.c:376 +#: ../../utils/net.c:481 msgid " Use 'net help domain' to get more information about 'net domain' commands." msgstr "" -#: ../../utils/net.c:383 +#: ../../utils/net.c:488 msgid "Modify printer queue" msgstr "" -#: ../../utils/net.c:384 +#: ../../utils/net.c:489 msgid " Use 'net help printq' to get more information about 'net printq' commands." msgstr "" -#: ../../utils/net.c:391 +#: ../../utils/net.c:496 msgid "Manage users" -msgstr "" +msgstr "Benutzer verwalten" -#: ../../utils/net.c:392 +#: ../../utils/net.c:497 msgid " Use 'net help user' to get more information about 'net user' commands." msgstr "" -#: ../../utils/net.c:399 +#: ../../utils/net.c:504 msgid "Manage groups" -msgstr "" +msgstr "Gruppen verwalten" -#: ../../utils/net.c:400 +#: ../../utils/net.c:505 msgid " Use 'net help group' to get more information about 'net group' commands." msgstr "" -#: ../../utils/net.c:407 +#: ../../utils/net.c:512 msgid "Manage group mappings" -msgstr "" +msgstr "Gruppenzuweisungen verwalten" -#: ../../utils/net.c:408 +#: ../../utils/net.c:513 msgid " Use 'net help groupmap' to get more information about 'net groupmap' commands." msgstr "" -#: ../../utils/net.c:415 +#: ../../utils/net.c:520 msgid "Functions on the SAM database" msgstr "" -#: ../../utils/net.c:416 +#: ../../utils/net.c:521 msgid " Use 'net help sam' to get more information about 'net sam' commands." msgstr "" -#: ../../utils/net.c:423 +#: ../../utils/net.c:528 msgid "Validate username and password" msgstr "" -#: ../../utils/net.c:424 +#: ../../utils/net.c:529 msgid " Use 'net help validate' to get more information about 'net validate' commands." msgstr "" -#: ../../utils/net.c:431 +#: ../../utils/net.c:536 msgid "Modify group memberships" -msgstr "" +msgstr "Gruppenzugehörigkeiten verwalten" -#: ../../utils/net.c:432 +#: ../../utils/net.c:537 msgid " Use 'net help groupmember' to get more information about 'net groupmember' commands." msgstr "" -#: ../../utils/net.c:438 +#: ../../utils/net.c:543 msgid "Execute remote command on a remote OS/2 server" -msgstr "" +msgstr "Befehl auf einem entfernten OS/2 Server ausführen" -#: ../../utils/net.c:439 +#: ../../utils/net.c:544 msgid " Use 'net help admin' to get more information about 'net admin' commands." msgstr "" -#: ../../utils/net.c:445 +#: ../../utils/net.c:550 msgid "List/modify running services" -msgstr "" +msgstr "Zeige/Ändere laufende Dienste" -#: ../../utils/net.c:446 +#: ../../utils/net.c:551 msgid " Use 'net help service' to get more information about 'net service' commands." msgstr "" -#: ../../utils/net.c:453 +#: ../../utils/net.c:558 msgid "Change user password on target server" msgstr "" -#: ../../utils/net.c:454 +#: ../../utils/net.c:559 msgid " Use 'net help password' to get more information about 'net password' commands." msgstr "" -#: ../../utils/net.c:460 +#: ../../utils/net.c:565 msgid "Change the trust password" msgstr "" -#: ../../utils/net.c:461 +#: ../../utils/net.c:566 msgid " Use 'net help changetrustpw' to get more information about 'net changetrustpw'." msgstr "" -#: ../../utils/net.c:467 +#: ../../utils/net.c:572 msgid "Change the secret password" -msgstr "" +msgstr "Das geheime Passwort ändern" -#: ../../utils/net.c:468 +#: ../../utils/net.c:573 msgid "" " net [options] changesecretpw\n" " Change the ADS domain member machine account password in secrets.tdb.\n" @@ -250,169 +305,193 @@ msgid "" " Requires the -f flag to work." msgstr "" -#: ../../utils/net.c:477 -msgid "Show/set time" +#: ../../utils/net.c:583 +msgid "Set the winbind auth user" msgstr "" -#: ../../utils/net.c:478 +#: ../../utils/net.c:584 +#, c-format +msgid "" +" net -U user[%%password] [-W domain] setauthuser\n" +" Set the auth user, password (and optionally domain\n" +" Will prompt for password if not given.\n" +" net setauthuser delete\n" +" Delete the existing auth user settings." +msgstr "" + +#: ../../utils/net.c:594 +msgid "Get the winbind auth user settings" +msgstr "" + +#: ../../utils/net.c:595 +msgid "" +" net getauthuser\n" +" Get the current winbind auth user settings." +msgstr "" + +#: ../../utils/net.c:601 +msgid "Show/set time" +msgstr "Zeigt/Setzt die Systemzeit" + +#: ../../utils/net.c:602 msgid " Use 'net help time' to get more information about 'net time' commands." msgstr "" -#: ../../utils/net.c:484 +#: ../../utils/net.c:608 msgid "Look up host names/IP addresses" msgstr "" -#: ../../utils/net.c:485 +#: ../../utils/net.c:609 msgid " Use 'net help lookup' to get more information about 'net lookup' commands." msgstr "" -#: ../../utils/net.c:491 +#: ../../utils/net.c:615 msgid "Join a domain/AD" -msgstr "" +msgstr "Einer Domäne/AD beitreten" -#: ../../utils/net.c:492 +#: ../../utils/net.c:616 msgid " Use 'net help join' to get more information about 'net join'." msgstr "" -#: ../../utils/net.c:498 +#: ../../utils/net.c:622 msgid "Join/unjoin (remote) machines to/from a domain/AD" msgstr "" -#: ../../utils/net.c:499 +#: ../../utils/net.c:623 msgid " Use 'net help dom' to get more information about 'net dom' commands." msgstr "" -#: ../../utils/net.c:505 +#: ../../utils/net.c:629 msgid "Operate on the cache tdb file" msgstr "" -#: ../../utils/net.c:506 +#: ../../utils/net.c:630 msgid " Use 'net help cache' to get more information about 'net cache' commands." msgstr "" -#: ../../utils/net.c:512 +#: ../../utils/net.c:636 msgid "Get the SID for the local domain" msgstr "" -#: ../../utils/net.c:513 +#: ../../utils/net.c:637 msgid " net getlocalsid" msgstr "" -#: ../../utils/net.c:518 +#: ../../utils/net.c:642 msgid "Set the SID for the local domain" msgstr "" -#: ../../utils/net.c:519 +#: ../../utils/net.c:643 msgid " net setlocalsid S-1-5-21-x-y-z" msgstr "" -#: ../../utils/net.c:524 +#: ../../utils/net.c:648 msgid "Set domain SID on member servers" msgstr "" -#: ../../utils/net.c:525 +#: ../../utils/net.c:649 msgid " net setdomainsid S-1-5-21-x-y-z" msgstr "" -#: ../../utils/net.c:530 +#: ../../utils/net.c:654 msgid "Get domain SID on member servers" msgstr "" -#: ../../utils/net.c:531 +#: ../../utils/net.c:655 msgid " net getdomainsid" msgstr "" -#: ../../utils/net.c:536 +#: ../../utils/net.c:660 msgid "Display the maximul RID currently used" msgstr "" -#: ../../utils/net.c:537 +#: ../../utils/net.c:661 msgid " net maxrid" msgstr "" -#: ../../utils/net.c:542 +#: ../../utils/net.c:666 msgid "IDmap functions" msgstr "" -#: ../../utils/net.c:543 +#: ../../utils/net.c:667 msgid " Use 'net help idmap to get more information about 'net idmap' commands." msgstr "" -#: ../../utils/net.c:549 +#: ../../utils/net.c:673 msgid "Display server status" -msgstr "" +msgstr "Zeigt den Server Status" -#: ../../utils/net.c:550 +#: ../../utils/net.c:674 msgid " Use 'net help status' to get more information about 'net status' commands." msgstr "" -#: ../../utils/net.c:556 +#: ../../utils/net.c:680 msgid "Manage user-modifiable shares" -msgstr "" +msgstr "Benutzerfreigaben verwalten" -#: ../../utils/net.c:557 +#: ../../utils/net.c:681 msgid " Use 'net help usershare to get more information about 'net usershare' commands." msgstr "" -#: ../../utils/net.c:563 +#: ../../utils/net.c:687 msgid "Display list of all users with SID" -msgstr "" +msgstr "Zeigt eine Liste aller SID-Benutzer" -#: ../../utils/net.c:564 +#: ../../utils/net.c:688 msgid " Use 'net help usersidlist' to get more information about 'net usersidlist'." msgstr "" -#: ../../utils/net.c:570 +#: ../../utils/net.c:694 msgid "Manage Samba registry based configuration" -msgstr "" +msgstr "Konfiguration ändern" -#: ../../utils/net.c:571 +#: ../../utils/net.c:695 msgid " Use 'net help conf' to get more information about 'net conf' commands." msgstr "" -#: ../../utils/net.c:577 +#: ../../utils/net.c:701 msgid "Manage the Samba registry" msgstr "" -#: ../../utils/net.c:578 +#: ../../utils/net.c:702 msgid " Use 'net help registry' to get more information about 'net registry' commands." msgstr "" -#: ../../utils/net.c:591 +#: ../../utils/net.c:708 msgid "Process Win32 *.evt eventlog files" -msgstr "" +msgstr "Arbeitet mit Win32 *.evt Eventlog Dateien" -#: ../../utils/net.c:592 +#: ../../utils/net.c:709 msgid " Use 'net help eventlog' to get more information about 'net eventlog' commands." msgstr "" -#: ../../utils/net.c:600 +#: ../../utils/net.c:717 msgid "Manage AFS tokens" msgstr "" -#: ../../utils/net.c:601 +#: ../../utils/net.c:718 msgid " Use 'net help afs' to get more information about 'net afs' commands." msgstr "" -#: ../../utils/net.c:609 +#: ../../utils/net.c:726 msgid "Print usage information" -msgstr "" +msgstr "Zeigt die Hilfe an" -#: ../../utils/net.c:610 +#: ../../utils/net.c:727 msgid " Use 'net help help' to list usage information for 'net' commands." msgstr "" -#: ../../utils/net.c:639 +#: ../../utils/net.c:756 msgid "Encrypt SMB transport (UNIX extended servers only)" msgstr "" -#: ../../utils/net.c:703 +#: ../../utils/net.c:824 msgid "" "\n" "Invalid ip address specified\n" msgstr "" -#: ../../utils/net.c:718 +#: ../../utils/net.c:839 #, c-format msgid "" "\n" @@ -421,27 +500,27 @@ msgstr "" "\n" "Ungültige Option %s: %s\n" -#: ../../utils/net_ads.c:52 ../../utils/net_ads.c:392 +#: ../../utils/net_ads.c:53 ../../utils/net_ads.c:393 msgid "CLDAP query failed!\n" msgstr "" -#: ../../utils/net_ads.c:56 +#: ../../utils/net_ads.c:57 #, c-format msgid "" "Information for Domain Controller: %s\n" "\n" msgstr "" -#: ../../utils/net_ads.c:59 +#: ../../utils/net_ads.c:60 msgid "Response Type: " msgstr "" -#: ../../utils/net_ads.c:72 +#: ../../utils/net_ads.c:73 #, c-format msgid "GUID: %s\n" msgstr "" -#: ../../utils/net_ads.c:74 +#: ../../utils/net_ads.c:75 #, c-format msgid "" "Flags:\n" @@ -459,369 +538,376 @@ msgid "" "\tIs NT6 DC that has all secrets: %s\n" msgstr "" -#: ../../utils/net_ads.c:87 ../../utils/net_ads.c:88 ../../utils/net_ads.c:89 ../../utils/net_ads.c:90 ../../utils/net_ads.c:91 ../../utils/net_ads.c:92 ../../utils/net_ads.c:93 ../../utils/net_ads.c:94 ../../utils/net_ads.c:95 ../../utils/net_ads.c:96 -#: ../../utils/net_ads.c:97 ../../utils/net_ads.c:98 ../../utils/net_rap.c:376 ../../utils/net_rpc_sh_acct.c:203 ../../utils/net_rpc_sh_acct.c:206 +#: ../../utils/net_ads.c:88 ../../utils/net_ads.c:89 ../../utils/net_ads.c:90 ../../utils/net_ads.c:91 ../../utils/net_ads.c:92 ../../utils/net_ads.c:93 ../../utils/net_ads.c:94 ../../utils/net_ads.c:95 ../../utils/net_ads.c:96 ../../utils/net_ads.c:97 +#: ../../utils/net_ads.c:98 ../../utils/net_ads.c:99 ../../utils/net_rap.c:376 ../../utils/net_rpc_sh_acct.c:204 ../../utils/net_rpc_sh_acct.c:207 msgid "yes" -msgstr "" +msgstr "Ja" -#: ../../utils/net_ads.c:87 ../../utils/net_ads.c:88 ../../utils/net_ads.c:89 ../../utils/net_ads.c:90 ../../utils/net_ads.c:91 ../../utils/net_ads.c:92 ../../utils/net_ads.c:93 ../../utils/net_ads.c:94 ../../utils/net_ads.c:95 ../../utils/net_ads.c:96 -#: ../../utils/net_ads.c:97 ../../utils/net_ads.c:98 ../../utils/net_rap.c:376 ../../utils/net_rpc_sh_acct.c:203 ../../utils/net_rpc_sh_acct.c:206 +#: ../../utils/net_ads.c:88 ../../utils/net_ads.c:89 ../../utils/net_ads.c:90 ../../utils/net_ads.c:91 ../../utils/net_ads.c:92 ../../utils/net_ads.c:93 ../../utils/net_ads.c:94 ../../utils/net_ads.c:95 ../../utils/net_ads.c:96 ../../utils/net_ads.c:97 +#: ../../utils/net_ads.c:98 ../../utils/net_ads.c:99 ../../utils/net_rap.c:376 ../../utils/net_rpc_sh_acct.c:204 ../../utils/net_rpc_sh_acct.c:207 msgid "no" -msgstr "" +msgstr "Nein" -#: ../../utils/net_ads.c:101 +#: ../../utils/net_ads.c:102 #, c-format msgid "Forest:\t\t\t%s\n" msgstr "" -#: ../../utils/net_ads.c:102 +#: ../../utils/net_ads.c:103 #, c-format msgid "Domain:\t\t\t%s\n" -msgstr "" +msgstr "Domäne:\t\t\t%s\n" -#: ../../utils/net_ads.c:103 +#: ../../utils/net_ads.c:104 #, c-format msgid "Domain Controller:\t%s\n" msgstr "" -#: ../../utils/net_ads.c:105 +#: ../../utils/net_ads.c:106 #, c-format msgid "Pre-Win2k Domain:\t%s\n" msgstr "" -#: ../../utils/net_ads.c:106 +#: ../../utils/net_ads.c:107 #, c-format msgid "Pre-Win2k Hostname:\t%s\n" msgstr "" -#: ../../utils/net_ads.c:108 +#: ../../utils/net_ads.c:109 #, c-format msgid "User name:\t%s\n" msgstr "" -#: ../../utils/net_ads.c:110 +#: ../../utils/net_ads.c:111 #, c-format msgid "Server Site Name :\t\t%s\n" msgstr "" -#: ../../utils/net_ads.c:111 +#: ../../utils/net_ads.c:112 #, c-format msgid "Client Site Name :\t\t%s\n" msgstr "" -#: ../../utils/net_ads.c:113 +#: ../../utils/net_ads.c:114 #, c-format msgid "NT Version: %d\n" -msgstr "" +msgstr "NT Version: %d\n" -#: ../../utils/net_ads.c:114 +#: ../../utils/net_ads.c:115 #, c-format msgid "LMNT Token: %.2x\n" msgstr "" -#: ../../utils/net_ads.c:115 +#: ../../utils/net_ads.c:116 #, c-format msgid "LM20 Token: %.2x\n" msgstr "" -#: ../../utils/net_ads.c:130 +#: ../../utils/net_ads.c:131 msgid "" "Usage:\n" "net ads lookup\n" " Find the ADS DC using CLDAP lookup.\n" msgstr "" -#: ../../utils/net_ads.c:137 ../../utils/net_ads.c:381 +#: ../../utils/net_ads.c:138 ../../utils/net_ads.c:382 msgid "Didn't find the cldap server!\n" msgstr "" -#: ../../utils/net_ads.c:160 +#: ../../utils/net_ads.c:161 msgid "" "Usage:\n" "net ads info\n" " Display information about an Active Directory server.\n" msgstr "" -#: ../../utils/net_ads.c:168 ../../utils/net_ads.c:173 +#: ../../utils/net_ads.c:169 ../../utils/net_ads.c:174 msgid "Didn't find the ldap server!\n" msgstr "" -#: ../../utils/net_ads.c:182 +#: ../../utils/net_ads.c:183 msgid "Failed to get server's current time!\n" msgstr "" -#: ../../utils/net_ads.c:187 +#: ../../utils/net_ads.c:188 #, c-format msgid "LDAP server: %s\n" msgstr "" -#: ../../utils/net_ads.c:188 +#: ../../utils/net_ads.c:189 #, c-format msgid "LDAP server name: %s\n" msgstr "" -#: ../../utils/net_ads.c:189 +#: ../../utils/net_ads.c:190 #, c-format msgid "Realm: %s\n" msgstr "" -#: ../../utils/net_ads.c:190 +#: ../../utils/net_ads.c:191 #, c-format msgid "Bind Path: %s\n" msgstr "" -#: ../../utils/net_ads.c:191 +#: ../../utils/net_ads.c:192 #, c-format msgid "LDAP port: %d\n" msgstr "" -#: ../../utils/net_ads.c:192 +#: ../../utils/net_ads.c:193 #, c-format msgid "Server time: %s\n" msgstr "" -#: ../../utils/net_ads.c:195 +#: ../../utils/net_ads.c:196 #, c-format msgid "KDC server: %s\n" msgstr "" -#: ../../utils/net_ads.c:196 +#: ../../utils/net_ads.c:197 #, c-format msgid "Server time offset: %d\n" msgstr "" -#: ../../utils/net_ads.c:374 +#: ../../utils/net_ads.c:375 msgid "" "Usage:\n" "net ads workgroup\n" " Print the workgroup name\n" msgstr "" -#: ../../utils/net_ads.c:397 +#: ../../utils/net_ads.c:398 #, c-format msgid "Workgroup: %s\n" msgstr "" -#: ../../utils/net_ads.c:458 +#: ../../utils/net_ads.c:459 #, c-format msgid "ads_user_add: %s\n" msgstr "" -#: ../../utils/net_ads.c:463 +#: ../../utils/net_ads.c:464 #, c-format msgid "ads_user_add: User %s already exists\n" msgstr "" -#: ../../utils/net_ads.c:477 +#: ../../utils/net_ads.c:478 #, c-format msgid "Could not add user %s: %s\n" msgstr "" -#: ../../utils/net_ads.c:484 ../../utils/net_ads.c:497 +#: ../../utils/net_ads.c:485 ../../utils/net_ads.c:498 #, c-format msgid "User %s added\n" msgstr "" #. password didn't set, delete account -#: ../../utils/net_ads.c:503 +#: ../../utils/net_ads.c:504 #, c-format msgid "Could not add user %s. Error setting password %s\n" msgstr "" -#: ../../utils/net_ads.c:551 +#: ../../utils/net_ads.c:552 #, c-format msgid "ads_user_info: failed to escape user %s\n" msgstr "" -#: ../../utils/net_ads.c:569 +#: ../../utils/net_ads.c:570 #, c-format msgid "ads_search: %s\n" msgstr "" -#: ../../utils/net_ads.c:575 +#: ../../utils/net_ads.c:576 msgid "ads_pull_uint32 failed\n" msgstr "" -#: ../../utils/net_ads.c:582 +#: ../../utils/net_ads.c:583 #, c-format msgid "ads_domain_sid: %s\n" msgstr "" -#: ../../utils/net_ads.c:642 +#: ../../utils/net_ads.c:643 #, c-format msgid "User %s does not exist.\n" msgstr "" -#: ../../utils/net_ads.c:652 +#: ../../utils/net_ads.c:653 #, c-format msgid "User %s deleted\n" msgstr "" -#: ../../utils/net_ads.c:656 +#: ../../utils/net_ads.c:657 #, c-format msgid "Error deleting user %s: %s\n" msgstr "" -#: ../../utils/net_ads.c:669 +#: ../../utils/net_ads.c:670 msgid "Add an AD user" msgstr "" -#: ../../utils/net_ads.c:670 +#: ../../utils/net_ads.c:671 msgid "" "net ads user add\n" " Add an AD user" msgstr "" -#: ../../utils/net_ads.c:677 +#: ../../utils/net_ads.c:678 msgid "Display information about an AD user" msgstr "" -#: ../../utils/net_ads.c:678 +#: ../../utils/net_ads.c:679 msgid "" "net ads user info\n" " Display information about an AD user" msgstr "" -#: ../../utils/net_ads.c:685 +#: ../../utils/net_ads.c:686 msgid "Delete an AD user" msgstr "" -#: ../../utils/net_ads.c:686 +#: ../../utils/net_ads.c:687 msgid "" "net ads user delete\n" " Delete an AD user" msgstr "" -#: ../../utils/net_ads.c:699 +#: ../../utils/net_ads.c:700 msgid "" "Usage:\n" "net ads user\n" " List AD users\n" msgstr "" -#: ../../utils/net_ads.c:711 ../../utils/net_rap.c:901 ../../utils/net_rpc.c:852 +#: ../../utils/net_ads.c:712 ../../utils/net_rap.c:901 ../../utils/net_rpc.c:871 msgid "" "\n" "User name Comment\n" "-----------------------------\n" msgstr "" -#: ../../utils/net_ads.c:751 +#: ../../utils/net_ads.c:752 #, c-format msgid "ads_group_add: %s\n" msgstr "" -#: ../../utils/net_ads.c:756 +#: ../../utils/net_ads.c:757 #, c-format msgid "ads_group_add: Group %s already exists\n" msgstr "" -#: ../../utils/net_ads.c:769 +#: ../../utils/net_ads.c:770 #, c-format msgid "Group %s added\n" msgstr "" -#: ../../utils/net_ads.c:772 +#: ../../utils/net_ads.c:773 #, c-format msgid "Could not add group %s: %s\n" msgstr "" -#: ../../utils/net_ads.c:801 +#: ../../utils/net_ads.c:802 #, c-format msgid "Group %s does not exist.\n" msgstr "" -#: ../../utils/net_ads.c:811 +#: ../../utils/net_ads.c:812 #, c-format msgid "Group %s deleted\n" msgstr "" -#: ../../utils/net_ads.c:815 +#: ../../utils/net_ads.c:816 #, c-format msgid "Error deleting group %s: %s\n" msgstr "" -#: ../../utils/net_ads.c:828 +#: ../../utils/net_ads.c:829 msgid "Add an AD group" -msgstr "" +msgstr "AD Gruppe hinzufügen" -#: ../../utils/net_ads.c:829 +#: ../../utils/net_ads.c:830 msgid "" "net ads group add\n" " Add an AD group" msgstr "" +"net ads group add\n" +" AD Gruppe hinzufügen" -#: ../../utils/net_ads.c:836 +#: ../../utils/net_ads.c:837 msgid "Delete an AD group" -msgstr "" +msgstr "AD Gruppe entfernen" -#: ../../utils/net_ads.c:837 +#: ../../utils/net_ads.c:838 msgid "" "net ads group delete\n" " Delete an AD group" msgstr "" +"net ads group delete\n" +" AD Gruppe entfernen" -#: ../../utils/net_ads.c:850 +#: ../../utils/net_ads.c:851 msgid "" "Usage:\n" "net ads group\n" " List AD groups\n" msgstr "" -#: ../../utils/net_ads.c:862 ../../utils/net_rpc.c:2230 +#: ../../utils/net_ads.c:863 ../../utils/net_rpc.c:2249 msgid "" "\n" "Group name Comment\n" "-----------------------------\n" msgstr "" +"\n" +"Gruppenname Kommentar\n" +"-----------------------------\n" -#: ../../utils/net_ads.c:884 +#: ../../utils/net_ads.c:885 msgid "" "Usage:\n" "net ads status\n" " Display machine account details\n" msgstr "" -#: ../../utils/net_ads.c:896 +#: ../../utils/net_ads.c:897 #, c-format msgid "ads_find_machine_acct: %s\n" msgstr "" -#: ../../utils/net_ads.c:902 +#: ../../utils/net_ads.c:903 #, c-format msgid "No machine account for '%s' found\n" msgstr "" -#: ../../utils/net_ads.c:926 +#: ../../utils/net_ads.c:927 msgid "" "Usage:\n" "net ads leave\n" " Leave an AD domain\n" msgstr "" -#: ../../utils/net_ads.c:933 +#: ../../utils/net_ads.c:934 msgid "No realm set, are we joined ?\n" msgstr "" -#: ../../utils/net_ads.c:938 ../../utils/net_ads.c:1260 +#: ../../utils/net_ads.c:939 ../../utils/net_ads.c:1265 msgid "Could not initialise talloc context.\n" msgstr "" -#: ../../utils/net_ads.c:948 +#: ../../utils/net_ads.c:949 msgid "Could not initialise unjoin context.\n" msgstr "" -#: ../../utils/net_ads.c:968 +#: ../../utils/net_ads.c:969 #, c-format msgid "Failed to leave domain: %s\n" msgstr "" -#: ../../utils/net_ads.c:975 +#: ../../utils/net_ads.c:976 #, c-format msgid "Deleted account for '%s' in realm '%s'\n" msgstr "" -#: ../../utils/net_ads.c:982 +#: ../../utils/net_ads.c:983 #, c-format msgid "Disabled account for '%s' in realm '%s'\n" msgstr "" @@ -829,60 +915,60 @@ msgstr "" #. Based on what we requseted, we shouldn't get here, but if #. we did, it means the secrets were removed, and therefore #. we have left the domain -#: ../../utils/net_ads.c:991 +#: ../../utils/net_ads.c:992 #, c-format msgid "Machine '%s' Left domain '%s'\n" msgstr "" -#: ../../utils/net_ads.c:1035 +#: ../../utils/net_ads.c:1040 msgid "" "Usage:\n" "net ads testjoin\n" " Test if the existing join is ok\n" msgstr "" -#: ../../utils/net_ads.c:1044 +#: ../../utils/net_ads.c:1049 #, c-format msgid "Join to domain is not valid: %s\n" msgstr "" -#: ../../utils/net_ads.c:1049 -#, c-format +#: ../../utils/net_ads.c:1054 +#, fuzzy, c-format msgid "Join is OK\n" -msgstr "" +msgstr "Beitritt ist OK\n" -#: ../../utils/net_ads.c:1060 +#: ../../utils/net_ads.c:1065 msgid "Host is not configured as a member server.\n" msgstr "" -#: ../../utils/net_ads.c:1065 ../../utils/net_rpc.c:436 +#: ../../utils/net_ads.c:1070 ../../utils/net_rpc.c:455 #, c-format msgid "Our netbios name can be at most 15 chars long, \"%s\" is %u chars long\n" msgstr "" -#: ../../utils/net_ads.c:1072 +#: ../../utils/net_ads.c:1077 #, c-format msgid "realm must be set in in %s for ADS join to succeed.\n" msgstr "" -#: ../../utils/net_ads.c:1105 +#: ../../utils/net_ads.c:1110 #, c-format msgid "No DNS domain configured for %s. Unable to perform DNS Update.\n" msgstr "" -#: ../../utils/net_ads.c:1212 +#: ../../utils/net_ads.c:1217 msgid "" "net ads join [options]\n" "Valid options:\n" msgstr "" -#: ../../utils/net_ads.c:1214 +#: ../../utils/net_ads.c:1219 msgid "" " createupn[=UPN] Set the userPrincipalName attribute during the join.\n" " The deault UPN is in the form host/netbiosname@REALM.\n" msgstr "" -#: ../../utils/net_ads.c:1216 +#: ../../utils/net_ads.c:1221 msgid "" " createcomputer=OU Precreate the computer account in a specific OU.\n" " The OU string read from top to bottom without RDNs and delimited by a '/'.\n" @@ -891,11 +977,11 @@ msgid "" " need to be doubled or even quadrupled. It is not used as a separator.\n" msgstr "" -#: ../../utils/net_ads.c:1221 +#: ../../utils/net_ads.c:1226 msgid " osName=string Set the operatingSystem attribute during the join.\n" msgstr "" -#: ../../utils/net_ads.c:1222 +#: ../../utils/net_ads.c:1227 msgid "" " osVer=string Set the operatingSystemVersion attribute during the join.\n" " NB: osName and osVer must be specified together for either to take effect.\n" @@ -903,27 +989,27 @@ msgid "" " the two other attributes.\n" msgstr "" -#: ../../utils/net_ads.c:1254 +#: ../../utils/net_ads.c:1259 msgid "Invalid configuration. Exiting....\n" msgstr "" -#: ../../utils/net_ads.c:1283 +#: ../../utils/net_ads.c:1288 msgid "Please supply a valid OU path.\n" msgstr "" -#: ../../utils/net_ads.c:1290 +#: ../../utils/net_ads.c:1295 msgid "Please supply a operating system name.\n" msgstr "" -#: ../../utils/net_ads.c:1297 +#: ../../utils/net_ads.c:1302 msgid "Please supply a valid operating system version.\n" msgstr "" -#: ../../utils/net_ads.c:1308 +#: ../../utils/net_ads.c:1313 msgid "Please supply a valid domain name\n" msgstr "" -#: ../../utils/net_ads.c:1339 +#: ../../utils/net_ads.c:1344 #, c-format msgid "" "The workgroup in %s does not match the short\n" @@ -932,51 +1018,51 @@ msgid "" "You should set \"workgroup = %s\" in %s.\n" msgstr "" -#: ../../utils/net_ads.c:1347 +#: ../../utils/net_ads.c:1352 #, c-format msgid "Using short domain name -- %s\n" msgstr "" -#: ../../utils/net_ads.c:1350 +#: ../../utils/net_ads.c:1355 #, c-format msgid "Joined '%s' to realm '%s'\n" msgstr "" -#: ../../utils/net_ads.c:1353 +#: ../../utils/net_ads.c:1358 #, c-format msgid "Joined '%s' to domain '%s'\n" msgstr "" -#: ../../utils/net_ads.c:1377 ../../utils/net_ads.c:1433 +#: ../../utils/net_ads.c:1382 ../../utils/net_ads.c:1438 msgid "DNS update failed!\n" msgstr "" #. issue an overall failure message at the end. -#: ../../utils/net_ads.c:1391 ../../utils/net_dom.c:198 +#: ../../utils/net_ads.c:1396 ../../utils/net_dom.c:199 #, c-format msgid "Failed to join domain: %s\n" msgstr "" -#: ../../utils/net_ads.c:1414 +#: ../../utils/net_ads.c:1419 msgid "" "Usage:\n" "net ads dns register\n" " Register hostname with DNS\n" msgstr "" -#: ../../utils/net_ads.c:1421 +#: ../../utils/net_ads.c:1426 msgid "Could not initialise talloc context\n" msgstr "" -#: ../../utils/net_ads.c:1439 +#: ../../utils/net_ads.c:1444 msgid "Successfully registered hostname with DNS\n" msgstr "" -#: ../../utils/net_ads.c:1447 +#: ../../utils/net_ads.c:1452 msgid "DNS update support not enabled at compile time!\n" msgstr "" -#: ../../utils/net_ads.c:1466 +#: ../../utils/net_ads.c:1471 msgid "" "Usage:\n" "net ads dns gethostbyname <server> <name>\n" @@ -985,32 +1071,32 @@ msgid "" " name\tName to look up\n" msgstr "" -#: ../../utils/net_ads.c:1476 +#: ../../utils/net_ads.c:1481 #, c-format msgid "do_gethostbyname returned %d\n" msgstr "" -#: ../../utils/net_ads.c:1488 +#: ../../utils/net_ads.c:1493 msgid "Add host dns entry to AD" msgstr "" -#: ../../utils/net_ads.c:1489 +#: ../../utils/net_ads.c:1494 msgid "" "net ads dns register\n" " Add host dns entry to AD" msgstr "" -#: ../../utils/net_ads.c:1496 +#: ../../utils/net_ads.c:1501 msgid "Look up host" msgstr "" -#: ../../utils/net_ads.c:1497 +#: ../../utils/net_ads.c:1502 msgid "" "net ads dns gethostbyname\n" " Look up host" msgstr "" -#: ../../utils/net_ads.c:1512 +#: ../../utils/net_ads.c:1517 msgid "" "\n" "net ads printer search <printer>\n" @@ -1029,23 +1115,23 @@ msgid "" "\t(note: printer name is required)\n" msgstr "" -#: ../../utils/net_ads.c:1536 +#: ../../utils/net_ads.c:1541 msgid "" "Usage:\n" "net ads printer search\n" " List printers in the AD\n" msgstr "" -#: ../../utils/net_ads.c:1549 +#: ../../utils/net_ads.c:1554 #, c-format msgid "ads_find_printer: %s\n" msgstr "" -#: ../../utils/net_ads.c:1556 +#: ../../utils/net_ads.c:1561 msgid "No results found\n" msgstr "" -#: ../../utils/net_ads.c:1576 +#: ../../utils/net_ads.c:1581 msgid "" "Usage:\n" "net ads printer info [printername [servername]]\n" @@ -1054,17 +1140,17 @@ msgid "" " servername\tName of the print server\n" msgstr "" -#: ../../utils/net_ads.c:1603 +#: ../../utils/net_ads.c:1608 #, c-format msgid "Server '%s' not found: %s\n" msgstr "" -#: ../../utils/net_ads.c:1611 ../../utils/net_ads.c:1794 +#: ../../utils/net_ads.c:1616 ../../utils/net_ads.c:1799 #, c-format msgid "Printer '%s' not found\n" msgstr "" -#: ../../utils/net_ads.c:1640 +#: ../../utils/net_ads.c:1645 msgid "" "Usage:\n" "net ads printer publish <printername> [servername]\n" @@ -1073,26 +1159,26 @@ msgid "" " servername\tName of the print server\n" msgstr "" -#: ../../utils/net_ads.c:1675 +#: ../../utils/net_ads.c:1680 #, c-format msgid "Unable to open a connnection to %s to obtain data for %s\n" msgstr "" -#: ../../utils/net_ads.c:1688 +#: ../../utils/net_ads.c:1693 #, c-format msgid "Could not find machine account for server %s\n" msgstr "" -#: ../../utils/net_ads.c:1704 ../../utils/net_ads.c:1713 +#: ../../utils/net_ads.c:1709 ../../utils/net_ads.c:1718 msgid "Internal error, out of memory!" msgstr "" -#: ../../utils/net_ads.c:1724 +#: ../../utils/net_ads.c:1729 #, c-format msgid "Unable to open a connnection to the spoolss pipe on %s\n" msgstr "" -#: ../../utils/net_ads.c:1766 +#: ../../utils/net_ads.c:1771 msgid "" "Usage:\n" "net ads printer remove <printername> [servername]\n" @@ -1101,57 +1187,57 @@ msgid "" " servername\tName of the print server\n" msgstr "" -#: ../../utils/net_ads.c:1787 +#: ../../utils/net_ads.c:1792 #, c-format msgid "ads_find_printer_on_server: %s\n" msgstr "" -#: ../../utils/net_ads.c:1806 +#: ../../utils/net_ads.c:1811 #, c-format msgid "ads_del_dn: %s\n" msgstr "" -#: ../../utils/net_ads.c:1822 +#: ../../utils/net_ads.c:1827 msgid "Search for a printer" msgstr "" -#: ../../utils/net_ads.c:1823 +#: ../../utils/net_ads.c:1828 msgid "" "net ads printer search\n" " Search for a printer" msgstr "" -#: ../../utils/net_ads.c:1830 +#: ../../utils/net_ads.c:1835 msgid "Display printer information" msgstr "" -#: ../../utils/net_ads.c:1831 +#: ../../utils/net_ads.c:1836 msgid "" "net ads printer info\n" " Display printer information" msgstr "" -#: ../../utils/net_ads.c:1838 +#: ../../utils/net_ads.c:1843 msgid "Publish a printer" msgstr "" -#: ../../utils/net_ads.c:1839 +#: ../../utils/net_ads.c:1844 msgid "" "net ads printer publish\n" " Publish a printer" msgstr "" -#: ../../utils/net_ads.c:1846 +#: ../../utils/net_ads.c:1851 msgid "Delete a printer" msgstr "" -#: ../../utils/net_ads.c:1847 +#: ../../utils/net_ads.c:1852 msgid "" "net ads printer remove\n" " Delete a printer" msgstr "" -#: ../../utils/net_ads.c:1869 +#: ../../utils/net_ads.c:1874 msgid "" "Usage:\n" "net ads password <username>\n" @@ -1159,59 +1245,59 @@ msgid "" " username\tName of user to change password for\n" msgstr "" -#: ../../utils/net_ads.c:1877 +#: ../../utils/net_ads.c:1882 msgid "You must supply an administrator username/password\n" msgstr "" -#: ../../utils/net_ads.c:1883 +#: ../../utils/net_ads.c:1888 msgid "ERROR: You must say which username to change password for\n" msgstr "" -#: ../../utils/net_ads.c:1915 +#: ../../utils/net_ads.c:1920 msgid "Didn't find the kerberos server!\n" msgstr "" -#: ../../utils/net_ads.c:1923 ../../utils/net_rpc.c:756 +#: ../../utils/net_ads.c:1928 ../../utils/net_rpc.c:775 #, c-format msgid "Enter new password for %s:" msgstr "Bitte neues Passwort für %s eingeben: " -#: ../../utils/net_ads.c:1933 ../../utils/net_ads.c:1982 +#: ../../utils/net_ads.c:1938 ../../utils/net_ads.c:1987 #, c-format msgid "Password change failed: %s\n" msgstr "" -#: ../../utils/net_ads.c:1938 +#: ../../utils/net_ads.c:1943 #, c-format msgid "Password change for %s completed.\n" msgstr "" -#: ../../utils/net_ads.c:1952 +#: ../../utils/net_ads.c:1957 msgid "" "Usage:\n" "net ads changetrustpw\n" " Change the machine account's trust password\n" msgstr "" -#: ../../utils/net_ads.c:1977 +#: ../../utils/net_ads.c:1982 #, c-format msgid "Changing password for principal: %s\n" msgstr "" -#: ../../utils/net_ads.c:1988 +#: ../../utils/net_ads.c:1993 #, c-format msgid "Password change for principal %s succeeded.\n" msgstr "" -#: ../../utils/net_ads.c:1991 +#: ../../utils/net_ads.c:1996 msgid "Attempting to update system keytab with new password.\n" msgstr "" -#: ../../utils/net_ads.c:1993 +#: ../../utils/net_ads.c:1998 msgid "Failed to update system keytab.\n" msgstr "" -#: ../../utils/net_ads.c:2009 +#: ../../utils/net_ads.c:2014 msgid "" "\n" "net ads search <expression> <attributes...>\n" @@ -1224,19 +1310,19 @@ msgid "" "\n" msgstr "" -#: ../../utils/net_ads.c:2046 ../../utils/net_ads.c:2107 ../../utils/net_ads.c:2171 ../../utils/net_ads_gpo.c:250 +#: ../../utils/net_ads.c:2051 ../../utils/net_ads.c:2112 ../../utils/net_ads.c:2176 ../../utils/net_ads_gpo.c:250 #, c-format msgid "search failed: %s\n" -msgstr "" +msgstr "Suche fehlgeschlagen: %s\n" -#: ../../utils/net_ads.c:2051 ../../utils/net_ads.c:2176 ../../utils/net_ads_gpo.c:256 +#: ../../utils/net_ads.c:2056 ../../utils/net_ads.c:2181 ../../utils/net_ads_gpo.c:256 #, c-format msgid "" "Got %d replies\n" "\n" msgstr "" -#: ../../utils/net_ads.c:2069 +#: ../../utils/net_ads.c:2074 msgid "" "\n" "net ads dn <dn> <attributes...>\n" @@ -1251,7 +1337,7 @@ msgid "" "\n" msgstr "" -#: ../../utils/net_ads.c:2129 +#: ../../utils/net_ads.c:2134 msgid "" "\n" "net ads sid <sid> <attributes...>\n" @@ -1264,18 +1350,18 @@ msgid "" "\n" msgstr "" -#: ../../utils/net_ads.c:2164 +#: ../../utils/net_ads.c:2169 msgid "could not convert sid\n" msgstr "" -#: ../../utils/net_ads.c:2193 +#: ../../utils/net_ads.c:2198 msgid "" "Usage:\n" "net ads keytab flush\n" " Delete the whole keytab\n" msgstr "" -#: ../../utils/net_ads.c:2214 +#: ../../utils/net_ads.c:2219 msgid "" "Usage:\n" "net ads keytab add <principal> [principal ...]\n" @@ -1283,18 +1369,18 @@ msgid "" " principal\tKerberos principal to add to keytab\n" msgstr "" -#: ../../utils/net_ads.c:2222 +#: ../../utils/net_ads.c:2227 msgid "Processing principals to add...\n" msgstr "" -#: ../../utils/net_ads.c:2239 +#: ../../utils/net_ads.c:2244 msgid "" "Usage:\n" "net ads keytab create\n" " Create new default keytab\n" msgstr "" -#: ../../utils/net_ads.c:2258 +#: ../../utils/net_ads.c:2263 msgid "" "Usage:\n" "net ads keytab list [keytab]\n" @@ -1302,314 +1388,314 @@ msgid "" " keytab\tKeytab to list\n" msgstr "" -#: ../../utils/net_ads.c:2280 +#: ../../utils/net_ads.c:2285 msgid "Add a service principal" msgstr "" -#: ../../utils/net_ads.c:2281 +#: ../../utils/net_ads.c:2286 msgid "" "net ads keytab add\n" " Add a service principal" msgstr "" -#: ../../utils/net_ads.c:2288 +#: ../../utils/net_ads.c:2293 msgid "Create a fresh keytab" msgstr "" -#: ../../utils/net_ads.c:2289 +#: ../../utils/net_ads.c:2294 msgid "" "net ads keytab create\n" " Create a fresh keytab" msgstr "" -#: ../../utils/net_ads.c:2296 +#: ../../utils/net_ads.c:2301 msgid "Remove all keytab entries" msgstr "" -#: ../../utils/net_ads.c:2297 +#: ../../utils/net_ads.c:2302 msgid "" "net ads keytab flush\n" " Remove all keytab entries" msgstr "" -#: ../../utils/net_ads.c:2304 +#: ../../utils/net_ads.c:2309 msgid "List a keytab" msgstr "" -#: ../../utils/net_ads.c:2305 +#: ../../utils/net_ads.c:2310 msgid "" "net ads keytab list\n" " List a keytab" msgstr "" -#: ../../utils/net_ads.c:2312 +#: ../../utils/net_ads.c:2317 msgid "" "\n" "Warning: \"kerberos method\" must be set to a keytab method to use keytab functions.\n" msgstr "" -#: ../../utils/net_ads.c:2324 +#: ../../utils/net_ads.c:2329 msgid "" "Usage:\n" "net ads kerberos renew\n" " Renew TGT from existing credential cache\n" msgstr "" -#: ../../utils/net_ads.c:2332 +#: ../../utils/net_ads.c:2337 #, c-format msgid "failed to renew kerberos ticket: %s\n" msgstr "" -#: ../../utils/net_ads.c:2347 +#: ../../utils/net_ads.c:2353 msgid "" "Usage:\n" "net ads kerberos pac\n" " Dump the Kerberos PAC\n" msgstr "" -#: ../../utils/net_ads.c:2372 +#: ../../utils/net_ads.c:2383 #, c-format msgid "failed to query kerberos PAC: %s\n" msgstr "" -#: ../../utils/net_ads.c:2381 +#: ../../utils/net_ads.c:2392 #, c-format msgid "The Pac: %s\n" msgstr "" -#: ../../utils/net_ads.c:2397 +#: ../../utils/net_ads.c:2408 msgid "" "Usage:\n" "net ads kerberos kinit\n" " Get Ticket Granting Ticket (TGT) for the user\n" msgstr "" -#: ../../utils/net_ads.c:2421 +#: ../../utils/net_ads.c:2432 #, c-format msgid "failed to kinit password: %s\n" msgstr "" -#: ../../utils/net_ads.c:2435 +#: ../../utils/net_ads.c:2446 msgid "Retrieve Ticket Granting Ticket (TGT)" msgstr "" -#: ../../utils/net_ads.c:2436 +#: ../../utils/net_ads.c:2447 msgid "" "net ads kerberos kinit\n" " Receive Ticket Granting Ticket (TGT)" msgstr "" -#: ../../utils/net_ads.c:2443 +#: ../../utils/net_ads.c:2454 msgid "Renew Ticket Granting Ticket from credential cache" msgstr "" -#: ../../utils/net_ads.c:2444 +#: ../../utils/net_ads.c:2455 msgid "" "net ads kerberos renew\n" " Renew Ticket Granting Ticket (TGT) from credential cache" msgstr "" -#: ../../utils/net_ads.c:2452 +#: ../../utils/net_ads.c:2463 msgid "Dump Kerberos PAC" msgstr "" -#: ../../utils/net_ads.c:2453 +#: ../../utils/net_ads.c:2464 msgid "" "net ads kerberos pac\n" " Dump Kerberos PAC" msgstr "" -#: ../../utils/net_ads.c:2469 +#: ../../utils/net_ads.c:2480 msgid "Display details on remote ADS server" msgstr "" -#: ../../utils/net_ads.c:2470 +#: ../../utils/net_ads.c:2481 msgid "" "net ads info\n" " Display details on remote ADS server" msgstr "" -#: ../../utils/net_ads.c:2477 +#: ../../utils/net_ads.c:2488 msgid "Join the local machine to ADS realm" msgstr "" -#: ../../utils/net_ads.c:2478 +#: ../../utils/net_ads.c:2489 msgid "" "net ads join\n" " Join the local machine to ADS realm" msgstr "" -#: ../../utils/net_ads.c:2485 +#: ../../utils/net_ads.c:2496 msgid "Validate machine account" msgstr "" -#: ../../utils/net_ads.c:2486 +#: ../../utils/net_ads.c:2497 msgid "" "net ads testjoin\n" " Validate machine account" msgstr "" -#: ../../utils/net_ads.c:2493 +#: ../../utils/net_ads.c:2504 msgid "Remove the local machine from ADS" msgstr "" -#: ../../utils/net_ads.c:2494 +#: ../../utils/net_ads.c:2505 msgid "" "net ads leave\n" " Remove the local machine from ADS" msgstr "" -#: ../../utils/net_ads.c:2501 +#: ../../utils/net_ads.c:2512 msgid "Display machine account details" msgstr "" -#: ../../utils/net_ads.c:2502 +#: ../../utils/net_ads.c:2513 msgid "" "net ads status\n" " Display machine account details" msgstr "" -#: ../../utils/net_ads.c:2509 ../../utils/net_rpc.c:7110 +#: ../../utils/net_ads.c:2520 ../../utils/net_rpc.c:7139 msgid "List/modify users" msgstr "" -#: ../../utils/net_ads.c:2510 +#: ../../utils/net_ads.c:2521 msgid "" "net ads user\n" " List/modify users" msgstr "" -#: ../../utils/net_ads.c:2517 ../../utils/net_rpc.c:7127 +#: ../../utils/net_ads.c:2528 ../../utils/net_rpc.c:7156 msgid "List/modify groups" msgstr "" -#: ../../utils/net_ads.c:2518 +#: ../../utils/net_ads.c:2529 msgid "" "net ads group\n" " List/modify groups" msgstr "" -#: ../../utils/net_ads.c:2525 +#: ../../utils/net_ads.c:2536 msgid "Issue dynamic DNS update" msgstr "" -#: ../../utils/net_ads.c:2526 +#: ../../utils/net_ads.c:2537 msgid "" "net ads dns\n" " Issue dynamic DNS update" msgstr "" -#: ../../utils/net_ads.c:2533 +#: ../../utils/net_ads.c:2544 msgid "Change user passwords" msgstr "" -#: ../../utils/net_ads.c:2534 +#: ../../utils/net_ads.c:2545 msgid "" "net ads password\n" " Change user passwords" msgstr "" -#: ../../utils/net_ads.c:2541 ../../utils/net_rpc.c:7159 +#: ../../utils/net_ads.c:2552 ../../utils/net_rpc.c:7188 msgid "Change trust account password" msgstr "Trust account Passwort ändern" -#: ../../utils/net_ads.c:2542 +#: ../../utils/net_ads.c:2553 msgid "" "net ads changetrustpw\n" " Change trust account password" msgstr "" -#: ../../utils/net_ads.c:2549 +#: ../../utils/net_ads.c:2560 msgid "List/modify printer entries" msgstr "" -#: ../../utils/net_ads.c:2550 +#: ../../utils/net_ads.c:2561 msgid "" "net ads printer\n" " List/modify printer entries" msgstr "" -#: ../../utils/net_ads.c:2557 +#: ../../utils/net_ads.c:2568 msgid "Issue LDAP search using filter" msgstr "" -#: ../../utils/net_ads.c:2558 +#: ../../utils/net_ads.c:2569 msgid "" "net ads search\n" " Issue LDAP search using filter" msgstr "" -#: ../../utils/net_ads.c:2565 +#: ../../utils/net_ads.c:2576 msgid "Issue LDAP search by DN" msgstr "" -#: ../../utils/net_ads.c:2566 +#: ../../utils/net_ads.c:2577 msgid "" "net ads dn\n" " Issue LDAP search by DN" msgstr "" -#: ../../utils/net_ads.c:2573 +#: ../../utils/net_ads.c:2584 msgid "Issue LDAP search by SID" msgstr "" -#: ../../utils/net_ads.c:2574 +#: ../../utils/net_ads.c:2585 msgid "" "net ads sid\n" " Issue LDAP search by SID" msgstr "" -#: ../../utils/net_ads.c:2581 +#: ../../utils/net_ads.c:2592 msgid "Display workgroup name" msgstr "" -#: ../../utils/net_ads.c:2582 +#: ../../utils/net_ads.c:2593 msgid "" "net ads workgroup\n" " Display the workgroup name" msgstr "" -#: ../../utils/net_ads.c:2589 +#: ../../utils/net_ads.c:2600 msgid "Perfom CLDAP query on DC" msgstr "" -#: ../../utils/net_ads.c:2590 +#: ../../utils/net_ads.c:2601 msgid "" "net ads lookup\n" " Find the ADS DC using CLDAP lookups" msgstr "" -#: ../../utils/net_ads.c:2597 +#: ../../utils/net_ads.c:2608 msgid "Manage local keytab file" msgstr "" -#: ../../utils/net_ads.c:2598 +#: ../../utils/net_ads.c:2609 msgid "" "net ads keytab\n" " Manage local keytab file" msgstr "" -#: ../../utils/net_ads.c:2605 +#: ../../utils/net_ads.c:2616 msgid "Manage group policy objects" msgstr "" -#: ../../utils/net_ads.c:2606 +#: ../../utils/net_ads.c:2617 msgid "" "net ads gpo\n" " Manage group policy objects" msgstr "" -#: ../../utils/net_ads.c:2613 +#: ../../utils/net_ads.c:2624 msgid "Manage kerberos keytab" msgstr "" -#: ../../utils/net_ads.c:2614 +#: ../../utils/net_ads.c:2625 msgid "" "net ads kerberos\n" " Manage kerberos keytab" msgstr "" -#: ../../utils/net_ads.c:2627 +#: ../../utils/net_ads.c:2638 msgid "ADS support not compiled in\n" msgstr "" @@ -1842,7 +1928,7 @@ msgstr "" #: ../../utils/net_afs.c:48 #, c-format msgid "Could not open %s\n" -msgstr "" +msgstr "Konnte %s nicht öffnen\n" #: ../../utils/net_afs.c:53 msgid "Could not read keyfile\n" @@ -2242,11 +2328,6 @@ msgstr "" msgid "error deleting includes: %s\n" msgstr "" -#: ../../utils/net_conf.c:1136 ../../utils/net_help.c:36 ../../utils/net_rap.c:161 ../../utils/net_rap.c:302 ../../utils/net_rap.c:467 ../../utils/net_rap.c:750 ../../utils/net_rap.c:891 ../../utils/net_rap.c:1002 ../../utils/net_rap.c:1193 -#: ../../utils/net_rpc.c:960 ../../utils/net_rpc.c:2801 ../../utils/net_rpc.c:4897 ../../utils/net_rpc.c:6933 ../../utils/net_rpc.c:7038 -msgid "Usage:\n" -msgstr "" - #: ../../utils/net_conf.c:1160 msgid "Dump the complete configuration in smb.conf like format." msgstr "" @@ -2377,72 +2458,72 @@ msgid "" " Delete includes from a share definition." msgstr "" -#: ../../utils/net_dom.c:25 +#: ../../utils/net_dom.c:26 msgid "" "usage: net dom join <domain=DOMAIN> <ou=OU> <account=ACCOUNT> <password=PASSWORD> <reboot>\n" " Join a remote machine\n" msgstr "" -#: ../../utils/net_dom.c:28 +#: ../../utils/net_dom.c:29 msgid "" "usage: net dom unjoin <account=ACCOUNT> <password=PASSWORD> <reboot>\n" " Unjoin a remote machine\n" msgstr "" -#: ../../utils/net_dom.c:31 +#: ../../utils/net_dom.c:32 msgid "" "usage: net dom renamecomputer <newname=NEWNAME> <account=ACCOUNT> <password=PASSWORD> <reboot>\n" " Rename joined computer\n" msgstr "" -#: ../../utils/net_dom.c:91 +#: ../../utils/net_dom.c:92 #, c-format msgid "Failed to unjoin domain: %s\n" msgstr "" -#: ../../utils/net_dom.c:97 ../../utils/net_dom.c:204 +#: ../../utils/net_dom.c:98 ../../utils/net_dom.c:205 msgid "Shutting down due to a domain membership change" msgstr "" -#: ../../utils/net_dom.c:290 +#: ../../utils/net_dom.c:291 #, c-format msgid "Failed to rename machine: " msgstr "" -#: ../../utils/net_dom.c:292 +#: ../../utils/net_dom.c:293 #, c-format msgid "Computer is not joined to a Domain\n" msgstr "" -#: ../../utils/net_dom.c:301 +#: ../../utils/net_dom.c:302 msgid "Shutting down due to a computer rename" msgstr "" -#: ../../utils/net_dom.c:338 +#: ../../utils/net_dom.c:339 msgid "Join a remote machine" msgstr "" -#: ../../utils/net_dom.c:339 +#: ../../utils/net_dom.c:340 msgid "" "net dom join <domain=DOMAIN> <ou=OU> <account=ACCOUNT> <password=PASSWORD> <reboot>\n" " Join a remote machine" msgstr "" -#: ../../utils/net_dom.c:347 +#: ../../utils/net_dom.c:348 msgid "Unjoin a remote machine" msgstr "" -#: ../../utils/net_dom.c:348 +#: ../../utils/net_dom.c:349 msgid "" "net dom unjoin <account=ACCOUNT> <password=PASSWORD> <reboot>\n" " Unjoin a remote machine" msgstr "" -#: ../../utils/net_dom.c:356 +#: ../../utils/net_dom.c:357 msgid "Rename a computer that is joined to a domain" msgstr "" -#: ../../utils/net_dom.c:357 +#: ../../utils/net_dom.c:358 msgid "" "net dom renamecomputer <newname=NEWNAME> <account=ACCOUNT> <password=PASSWORD> <reboot>\n" " Rename joined computer" @@ -3479,7 +3560,7 @@ msgid "" " List all shares on remote server\n" msgstr "" -#: ../../utils/net_rap.c:314 ../../utils/net_rpc.c:3046 +#: ../../utils/net_rap.c:314 ../../utils/net_rpc.c:3065 msgid "" "\n" "Enumerating shared resources (exports) on remote server:\n" @@ -3730,7 +3811,7 @@ msgid "" " List the print queue\n" msgstr "" -#: ../../utils/net_rap.c:864 ../../utils/net_rpc.c:909 +#: ../../utils/net_rap.c:864 ../../utils/net_rpc.c:928 msgid "Add specified user" msgstr "" @@ -3750,7 +3831,7 @@ msgid "" " List domain groups of specified user" msgstr "" -#: ../../utils/net_rap.c:881 ../../utils/net_rpc.c:925 +#: ../../utils/net_rap.c:881 ../../utils/net_rpc.c:944 msgid "Remove specified user" msgstr "" @@ -3781,7 +3862,7 @@ msgid "" " Add specified group" msgstr "" -#: ../../utils/net_rap.c:991 ../../utils/net_rpc.c:2742 +#: ../../utils/net_rap.c:991 ../../utils/net_rpc.c:2761 msgid "Delete specified group" msgstr "" @@ -3916,7 +3997,7 @@ msgid "" "\texecutes a remote command on an os/2 target server\n" msgstr "" -#: ../../utils/net_rap.c:1267 ../../utils/net_rpc.c:7143 +#: ../../utils/net_rap.c:1267 ../../utils/net_rpc.c:7172 msgid "List open files" msgstr "" @@ -4032,7 +4113,7 @@ msgid "" " Start/stop remote service" msgstr "" -#: ../../utils/net_rap.c:1363 ../../utils/net_rpc.c:933 +#: ../../utils/net_rap.c:1363 ../../utils/net_rpc.c:952 msgid "Change user password" msgstr "" @@ -4082,16 +4163,16 @@ msgstr "" msgid "reg_createkey failed: %s\n" msgstr "" -#: ../../utils/net_registry.c:211 ../../utils/net_rpc_registry.c:681 +#: ../../utils/net_registry.c:211 ../../utils/net_rpc_registry.c:722 msgid "createkey did nothing -- huh?\n" msgstr "" -#: ../../utils/net_registry.c:214 ../../utils/net_rpc_registry.c:684 +#: ../../utils/net_registry.c:214 ../../utils/net_rpc_registry.c:725 #, c-format msgid "createkey created %s\n" msgstr "" -#: ../../utils/net_registry.c:217 ../../utils/net_rpc_registry.c:687 +#: ../../utils/net_registry.c:217 ../../utils/net_rpc_registry.c:728 #, c-format msgid "createkey opened existing %s\n" msgstr "" @@ -4109,7 +4190,7 @@ msgstr "" msgid "reg_deletekey failed: %s\n" msgstr "" -#: ../../utils/net_registry.c:279 ../../utils/net_rpc_registry.c:601 ../../utils/net_rpc_registry.c:628 +#: ../../utils/net_registry.c:279 ../../utils/net_rpc_registry.c:642 ../../utils/net_rpc_registry.c:669 msgid "usage: net rpc registry getvalue <key> <valuename>\n" msgstr "" @@ -4118,16 +4199,16 @@ msgstr "" msgid "reg_queryvalue failed: %s\n" msgstr "" -#: ../../utils/net_registry.c:328 ../../utils/net_rpc_registry.c:433 +#: ../../utils/net_registry.c:328 ../../utils/net_rpc_registry.c:474 msgid "usage: net rpc registry setvalue <key> <valuename> <type> [<val>]+\n" msgstr "" -#: ../../utils/net_registry.c:334 ../../utils/net_rpc_registry.c:395 +#: ../../utils/net_registry.c:334 ../../utils/net_rpc_registry.c:436 #, c-format msgid "Too many args for type %s\n" msgstr "" -#: ../../utils/net_registry.c:350 ../../utils/net_rpc_registry.c:409 +#: ../../utils/net_registry.c:350 ../../utils/net_rpc_registry.c:450 #, c-format msgid "type \"%s\" not implemented\n" msgstr "" @@ -4137,7 +4218,7 @@ msgstr "" msgid "reg_setvalue failed: %s\n" msgstr "" -#: ../../utils/net_registry.c:383 ../../utils/net_rpc_registry.c:486 +#: ../../utils/net_registry.c:383 ../../utils/net_rpc_registry.c:527 msgid "usage: net rpc registry deletevalue <key> <valuename>\n" msgstr "" @@ -4154,7 +4235,7 @@ msgstr "" msgid "reg_getkeysecurity failed: %s\n" msgstr "" -#: ../../utils/net_registry.c:468 ../../utils/net_rpc_registry.c:1234 +#: ../../utils/net_registry.c:468 ../../utils/net_rpc_registry.c:1273 msgid "Enumerate registry keys and values" msgstr "" @@ -4164,7 +4245,7 @@ msgid "" " Enumerate registry keys and values" msgstr "" -#: ../../utils/net_registry.c:476 ../../utils/net_rpc_registry.c:1242 +#: ../../utils/net_registry.c:476 ../../utils/net_rpc_registry.c:1281 msgid "Create a new registry key" msgstr "" @@ -4174,7 +4255,7 @@ msgid "" " Create a new registry key" msgstr "" -#: ../../utils/net_registry.c:484 ../../utils/net_rpc_registry.c:1250 +#: ../../utils/net_registry.c:484 ../../utils/net_rpc_registry.c:1289 msgid "Delete a registry key" msgstr "" @@ -4184,7 +4265,7 @@ msgid "" " Delete a registry key" msgstr "" -#: ../../utils/net_registry.c:492 ../../utils/net_rpc_registry.c:1258 ../../utils/net_rpc_registry.c:1266 +#: ../../utils/net_registry.c:492 ../../utils/net_rpc_registry.c:1297 ../../utils/net_rpc_registry.c:1305 msgid "Print a registry value" msgstr "" @@ -4204,7 +4285,7 @@ msgid "" " Print a registry value (raw format)" msgstr "" -#: ../../utils/net_registry.c:508 ../../utils/net_rpc_registry.c:1274 +#: ../../utils/net_registry.c:508 ../../utils/net_rpc_registry.c:1313 msgid "Set a new registry value" msgstr "" @@ -4214,7 +4295,7 @@ msgid "" " Set a new registry value" msgstr "" -#: ../../utils/net_registry.c:516 ../../utils/net_rpc_registry.c:1282 +#: ../../utils/net_registry.c:516 ../../utils/net_rpc_registry.c:1321 msgid "Delete a registry value" msgstr "" @@ -4224,7 +4305,7 @@ msgid "" " Delete a registry value" msgstr "" -#: ../../utils/net_registry.c:524 ../../utils/net_rpc_registry.c:1314 +#: ../../utils/net_registry.c:524 ../../utils/net_rpc_registry.c:1353 msgid "Get security descriptor" msgstr "" @@ -4280,44 +4361,49 @@ msgstr "" msgid "Valuename = %s\n" msgstr "" -#: ../../utils/net_rpc.c:66 ../../utils/net_util.c:43 +#: ../../utils/net_rpc.c:73 ../../utils/net_util.c:45 msgid "Could not initialise lsa pipe\n" msgstr "" -#: ../../utils/net_rpc.c:74 ../../utils/net_util.c:51 +#: ../../utils/net_rpc.c:81 ../../utils/net_util.c:53 #, c-format msgid "open_policy failed: %s\n" msgstr "" -#: ../../utils/net_rpc.c:84 +#: ../../utils/net_rpc.c:91 #, c-format msgid "lsaquery failed: %s\n" msgstr "" -#: ../../utils/net_rpc.c:257 +#: ../../utils/net_rpc.c:254 +#, fuzzy, c-format +msgid "Failed to change machine account password: %s\n" +msgstr "Konnte Passwort für trust account nicht stetzen: %s\n" + +#: ../../utils/net_rpc.c:275 msgid "" "Usage:\n" "net rpc changetrustpw\n" " Change the machine trust password\n" msgstr "" -#: ../../utils/net_rpc.c:341 ../../utils/net_rpc_join.c:470 +#: ../../utils/net_rpc.c:360 ../../utils/net_rpc_join.c:477 #, c-format msgid "Joined domain %s.\n" msgstr "" -#: ../../utils/net_rpc.c:387 +#: ../../utils/net_rpc.c:406 msgid "" "Usage:\n" "net rpc oldjoin\n" " Join a domain the old way\n" msgstr "" -#: ../../utils/net_rpc.c:396 +#: ../../utils/net_rpc.c:415 msgid "Failed to join domain\n" msgstr "" -#: ../../utils/net_rpc.c:417 +#: ../../utils/net_rpc.c:436 #, c-format msgid "" "Usage:\n" @@ -4330,375 +4416,375 @@ msgid "" "\t\tPDC\tJoin as PDC\n" msgstr "" -#: ../../utils/net_rpc.c:431 +#: ../../utils/net_rpc.c:450 msgid "cannot join as standalone machine\n" msgstr "" -#: ../../utils/net_rpc.c:486 +#: ../../utils/net_rpc.c:505 #, c-format msgid "Could not connect to SAM: %s\n" msgstr "" -#: ../../utils/net_rpc.c:498 +#: ../../utils/net_rpc.c:517 #, c-format msgid "Could not open domain: %s\n" msgstr "" -#: ../../utils/net_rpc.c:508 +#: ../../utils/net_rpc.c:527 #, c-format msgid "Domain Name: %s\n" msgstr "" -#: ../../utils/net_rpc.c:510 +#: ../../utils/net_rpc.c:529 #, c-format msgid "Domain SID: %s\n" msgstr "" -#: ../../utils/net_rpc.c:511 +#: ../../utils/net_rpc.c:530 #, c-format msgid "Sequence number: %llu\n" msgstr "" -#: ../../utils/net_rpc.c:513 +#: ../../utils/net_rpc.c:532 #, c-format msgid "Num users: %u\n" msgstr "" -#: ../../utils/net_rpc.c:514 +#: ../../utils/net_rpc.c:533 #, c-format msgid "Num domain groups: %u\n" msgstr "" -#: ../../utils/net_rpc.c:515 +#: ../../utils/net_rpc.c:534 #, c-format msgid "Num local groups: %u\n" msgstr "" -#: ../../utils/net_rpc.c:532 +#: ../../utils/net_rpc.c:551 msgid "" "Usage:\n" "net rpc info\n" " Display information about the domain\n" msgstr "" -#: ../../utils/net_rpc.c:571 +#: ../../utils/net_rpc.c:590 #, c-format msgid "Storing SID %s for Domain %s in secrets.tdb\n" msgstr "" -#: ../../utils/net_rpc.c:592 +#: ../../utils/net_rpc.c:611 msgid "" "Usage:\n" "net rpc getsid\n" " Fetch domain SID into local secrets.tdb\n" msgstr "" -#: ../../utils/net_rpc.c:649 +#: ../../utils/net_rpc.c:668 #, c-format msgid "Failed to add user '%s' with error: %s.\n" msgstr "" -#: ../../utils/net_rpc.c:654 +#: ../../utils/net_rpc.c:673 #, c-format msgid "Added user '%s'.\n" msgstr "" -#: ../../utils/net_rpc.c:687 +#: ../../utils/net_rpc.c:706 #, c-format msgid "Failed to rename user from %s to %s - %s\n" msgstr "" -#: ../../utils/net_rpc.c:691 +#: ../../utils/net_rpc.c:710 #, c-format msgid "Renamed user from %s to %s\n" msgstr "" -#: ../../utils/net_rpc.c:719 +#: ../../utils/net_rpc.c:738 #, c-format msgid "Failed to delete user '%s' with: %s.\n" msgstr "" -#: ../../utils/net_rpc.c:724 +#: ../../utils/net_rpc.c:743 #, c-format msgid "Deleted user '%s'.\n" msgstr "" -#: ../../utils/net_rpc.c:770 +#: ../../utils/net_rpc.c:789 #, c-format msgid "Failed to set password for '%s' with error: %s.\n" msgstr "" -#: ../../utils/net_rpc.c:813 +#: ../../utils/net_rpc.c:832 #, c-format msgid "Failed to get groups for '%s' with error: %s.\n" msgstr "" -#: ../../utils/net_rpc.c:910 +#: ../../utils/net_rpc.c:929 msgid "" "net rpc user add\n" " Add specified user" msgstr "" -#: ../../utils/net_rpc.c:917 +#: ../../utils/net_rpc.c:936 msgid "List domain groups of user" msgstr "" -#: ../../utils/net_rpc.c:918 +#: ../../utils/net_rpc.c:937 msgid "" "net rpc user info\n" " Lis domain groups of user" msgstr "" -#: ../../utils/net_rpc.c:926 +#: ../../utils/net_rpc.c:945 msgid "" "net rpc user delete\n" " Remove specified user" msgstr "" -#: ../../utils/net_rpc.c:934 +#: ../../utils/net_rpc.c:953 msgid "" "net rpc user password\n" " Change user password" msgstr "" -#: ../../utils/net_rpc.c:941 +#: ../../utils/net_rpc.c:960 msgid "Rename specified user" msgstr "" -#: ../../utils/net_rpc.c:942 +#: ../../utils/net_rpc.c:961 msgid "" "net rpc user rename\n" " Rename specified user" msgstr "" -#: ../../utils/net_rpc.c:961 +#: ../../utils/net_rpc.c:980 msgid "" "net rpc user\n" " List all users\n" msgstr "" -#: ../../utils/net_rpc.c:1011 +#: ../../utils/net_rpc.c:1030 #, c-format msgid "usage: %s <username>\n" msgstr "" -#: ../../utils/net_rpc.c:1022 +#: ../../utils/net_rpc.c:1041 #, c-format msgid "Could not lookup %s: %s\n" msgstr "" -#: ../../utils/net_rpc.c:1028 ../../utils/net_sam.c:52 ../../utils/net_sam.c:157 ../../utils/net_sam.c:249 +#: ../../utils/net_rpc.c:1047 ../../utils/net_sam.c:52 ../../utils/net_sam.c:157 ../../utils/net_sam.c:249 #, c-format msgid "%s is a %s, not a user\n" msgstr "" -#: ../../utils/net_rpc.c:1035 +#: ../../utils/net_rpc.c:1054 #, c-format msgid "%s is not in our domain\n" msgstr "" -#: ../../utils/net_rpc.c:1092 +#: ../../utils/net_rpc.c:1111 #, c-format msgid "usage: %s show <username>\n" msgstr "" -#: ../../utils/net_rpc.c:1104 +#: ../../utils/net_rpc.c:1123 #, c-format msgid "user rid: %d, group rid: %d\n" msgstr "" -#: ../../utils/net_rpc.c:1145 +#: ../../utils/net_rpc.c:1164 #, c-format msgid "usage: %s <username> [new value|NULL]\n" msgstr "" -#: ../../utils/net_rpc.c:1168 +#: ../../utils/net_rpc.c:1187 #, c-format msgid "%s's %s: [%s]\n" msgstr "" -#: ../../utils/net_rpc.c:1190 +#: ../../utils/net_rpc.c:1209 #, c-format msgid "Set %s's %s from [%s] to [%s]\n" msgstr "" #. TRANSATORS: The yes|no here are program keywords. Please do #. not translate. -#: ../../utils/net_rpc.c:1236 +#: ../../utils/net_rpc.c:1255 #, c-format msgid "usage: %s <username> [yes|no]\n" msgstr "" -#: ../../utils/net_rpc.c:1261 +#: ../../utils/net_rpc.c:1280 #, c-format msgid "%s's %s flag: %s\n" msgstr "" -#: ../../utils/net_rpc.c:1277 +#: ../../utils/net_rpc.c:1296 #, c-format msgid "Set %s's %s flag from [%s] to [%s]\n" msgstr "" -#: ../../utils/net_rpc.c:1303 +#: ../../utils/net_rpc.c:1322 msgid "Show/Set a user's full name" msgstr "" -#: ../../utils/net_rpc.c:1306 +#: ../../utils/net_rpc.c:1325 msgid "Show/Set a user's home directory" msgstr "" -#: ../../utils/net_rpc.c:1309 +#: ../../utils/net_rpc.c:1328 msgid "Show/Set a user's home drive" msgstr "" -#: ../../utils/net_rpc.c:1312 +#: ../../utils/net_rpc.c:1331 msgid "Show/Set a user's logon script" msgstr "" -#: ../../utils/net_rpc.c:1315 +#: ../../utils/net_rpc.c:1334 msgid "Show/Set a user's profile path" msgstr "" -#: ../../utils/net_rpc.c:1318 +#: ../../utils/net_rpc.c:1337 msgid "Show/Set a user's description" msgstr "" -#: ../../utils/net_rpc.c:1321 +#: ../../utils/net_rpc.c:1340 msgid "Show/Set whether a user is disabled" msgstr "" -#: ../../utils/net_rpc.c:1324 +#: ../../utils/net_rpc.c:1343 msgid "Show/Set whether a user locked out" msgstr "" -#: ../../utils/net_rpc.c:1327 +#: ../../utils/net_rpc.c:1346 msgid "Show/Set whether a user does not need a password" msgstr "" -#: ../../utils/net_rpc.c:1330 +#: ../../utils/net_rpc.c:1349 msgid "Show/Set whether a user's password does not expire" msgstr "" -#: ../../utils/net_rpc.c:1345 +#: ../../utils/net_rpc.c:1364 msgid "List available users" msgstr "" -#: ../../utils/net_rpc.c:1348 +#: ../../utils/net_rpc.c:1367 msgid "List the domain groups a user is member of" msgstr "" -#: ../../utils/net_rpc.c:1351 +#: ../../utils/net_rpc.c:1370 msgid "Show info about a user" msgstr "" -#: ../../utils/net_rpc.c:1354 +#: ../../utils/net_rpc.c:1373 msgid "Show/Modify a user's fields" msgstr "" -#: ../../utils/net_rpc.c:1425 +#: ../../utils/net_rpc.c:1444 msgid "Request samr_Connect2 failed\n" msgstr "" -#: ../../utils/net_rpc.c:1436 +#: ../../utils/net_rpc.c:1455 msgid "Request open_domain failed\n" msgstr "" -#: ../../utils/net_rpc.c:1449 +#: ../../utils/net_rpc.c:1468 #, c-format msgid "Lookup of '%s' failed\n" msgstr "" -#: ../../utils/net_rpc.c:1462 +#: ../../utils/net_rpc.c:1481 msgid "Request open_group failed" msgstr "" -#: ../../utils/net_rpc.c:1474 +#: ../../utils/net_rpc.c:1493 #, c-format msgid "Unable to query group members of %s" msgstr "" -#: ../../utils/net_rpc.c:1481 +#: ../../utils/net_rpc.c:1500 #, c-format msgid "Domain Group %s (rid: %d) has %d members\n" msgstr "" -#: ../../utils/net_rpc.c:1496 +#: ../../utils/net_rpc.c:1515 #, c-format msgid "Unable to open group member %d\n" msgstr "" -#: ../../utils/net_rpc.c:1508 +#: ../../utils/net_rpc.c:1527 #, c-format msgid "Unable to lookup userinfo for group member %d\n" msgstr "" -#: ../../utils/net_rpc.c:1516 +#: ../../utils/net_rpc.c:1535 #, c-format msgid "Group is primary group of %s\n" msgstr "" -#: ../../utils/net_rpc.c:1527 +#: ../../utils/net_rpc.c:1546 msgid "Unable to delete group because some of it's members have it as primary group\n" msgstr "" -#: ../../utils/net_rpc.c:1538 +#: ../../utils/net_rpc.c:1557 #, c-format msgid "Remove group member %d..." msgstr "" -#: ../../utils/net_rpc.c:1546 ../../utils/net_rpc_registry.c:1053 ../../utils/net_rpc_registry.c:1073 ../../utils/net_rpc_registry.c:1098 ../../utils/net_rpc_registry.c:1105 ../../utils/net_rpc_registry.c:1125 ../../utils/net_rpc_registry.c:1131 +#: ../../utils/net_rpc.c:1565 ../../utils/net_rpc_registry.c:1092 ../../utils/net_rpc_registry.c:1112 ../../utils/net_rpc_registry.c:1137 ../../utils/net_rpc_registry.c:1144 ../../utils/net_rpc_registry.c:1164 ../../utils/net_rpc_registry.c:1170 msgid "ok\n" msgstr "" -#: ../../utils/net_rpc.c:1549 +#: ../../utils/net_rpc.c:1568 msgid "failed\n" msgstr "" -#: ../../utils/net_rpc.c:1567 +#: ../../utils/net_rpc.c:1586 msgid "Request open_alias failed\n" msgstr "" -#: ../../utils/net_rpc.c:1575 +#: ../../utils/net_rpc.c:1594 #, c-format msgid "%s is of type %s. This command is only for deleting local or global groups\n" msgstr "" -#: ../../utils/net_rpc.c:1584 +#: ../../utils/net_rpc.c:1603 #, c-format msgid "Deleted %s '%s'\n" msgstr "" -#: ../../utils/net_rpc.c:1587 +#: ../../utils/net_rpc.c:1606 #, c-format msgid "Deleting of %s failed: %s\n" msgstr "" -#: ../../utils/net_rpc.c:1624 +#: ../../utils/net_rpc.c:1643 #, c-format msgid "Failed to add group '%s' with error: %s.\n" msgstr "" -#: ../../utils/net_rpc.c:1629 +#: ../../utils/net_rpc.c:1648 #, c-format msgid "Added group '%s'.\n" msgstr "" -#: ../../utils/net_rpc.c:1657 +#: ../../utils/net_rpc.c:1676 #, c-format msgid "Failed to add alias '%s' with error: %s.\n" msgstr "" -#: ../../utils/net_rpc.c:1662 +#: ../../utils/net_rpc.c:1681 #, c-format msgid "Added alias '%s'.\n" msgstr "" -#: ../../utils/net_rpc.c:1782 ../../utils/net_rpc.c:1832 ../../utils/net_rpc.c:1989 ../../utils/net_rpc.c:2036 +#: ../../utils/net_rpc.c:1801 ../../utils/net_rpc.c:1851 ../../utils/net_rpc.c:2008 ../../utils/net_rpc.c:2055 #, c-format msgid "Could not lookup up group member %s\n" msgstr "" -#: ../../utils/net_rpc.c:1892 +#: ../../utils/net_rpc.c:1911 msgid "" "Usage:\n" "net rpc group addmem <group> <member>\n" @@ -4707,22 +4793,22 @@ msgid "" " member\tMember to add to group\n" msgstr "" -#: ../../utils/net_rpc.c:1902 ../../utils/net_rpc.c:2104 +#: ../../utils/net_rpc.c:1921 ../../utils/net_rpc.c:2123 #, c-format msgid "Could not lookup group name %s\n" msgstr "" -#: ../../utils/net_rpc.c:1912 ../../utils/net_rpc.c:1923 +#: ../../utils/net_rpc.c:1931 ../../utils/net_rpc.c:1942 #, c-format msgid "Could not add %s to %s: %s\n" msgstr "" -#: ../../utils/net_rpc.c:1929 +#: ../../utils/net_rpc.c:1948 #, c-format msgid "Can only add members to global or local groups which %s is not\n" msgstr "" -#: ../../utils/net_rpc.c:2094 +#: ../../utils/net_rpc.c:2113 msgid "" "Usage:\n" "net rpc group delmem <group> <member>\n" @@ -4731,17 +4817,17 @@ msgid "" " member\tMember to delete from group\n" msgstr "" -#: ../../utils/net_rpc.c:2114 ../../utils/net_rpc.c:2125 +#: ../../utils/net_rpc.c:2133 ../../utils/net_rpc.c:2144 #, c-format msgid "Could not del %s from %s: %s\n" msgstr "" -#: ../../utils/net_rpc.c:2131 +#: ../../utils/net_rpc.c:2150 #, c-format msgid "Can only delete members from global or local groups which %s is not\n" msgstr "" -#: ../../utils/net_rpc.c:2178 +#: ../../utils/net_rpc.c:2197 msgid "" "Usage:\n" "net rpc group list [global] [local] [builtin]\n" @@ -4752,333 +4838,338 @@ msgid "" " If none of global, local or builtin is specified, all three options are considered set\n" msgstr "" -#: ../../utils/net_rpc.c:2499 +#: ../../utils/net_rpc.c:2518 msgid "Couldn't list alias members\n" msgstr "" -#: ../../utils/net_rpc.c:2513 +#: ../../utils/net_rpc.c:2532 #, c-format msgid "Couldn't open LSA pipe. Error was %s\n" msgstr "" -#: ../../utils/net_rpc.c:2522 +#: ../../utils/net_rpc.c:2541 msgid "Couldn't open LSA policy handle\n" msgstr "" -#: ../../utils/net_rpc.c:2529 +#: ../../utils/net_rpc.c:2548 msgid "Out of memory\n" msgstr "" -#: ../../utils/net_rpc.c:2544 +#: ../../utils/net_rpc.c:2563 msgid "Couldn't lookup SIDs\n" msgstr "" -#: ../../utils/net_rpc.c:2555 ../../utils/net_rpc.c:2556 +#: ../../utils/net_rpc.c:2574 ../../utils/net_rpc.c:2575 msgid "*unknown*" msgstr "" -#: ../../utils/net_rpc.c:2630 ../../utils/net_rpc.c:2643 ../../utils/net_rpc.c:2650 +#: ../../utils/net_rpc.c:2649 ../../utils/net_rpc.c:2662 ../../utils/net_rpc.c:2669 #, c-format msgid "Couldn't find group %s\n" msgstr "" -#: ../../utils/net_rpc.c:2687 +#: ../../utils/net_rpc.c:2706 msgid "Usage: 'net rpc group rename group newname'\n" msgstr "" -#: ../../utils/net_rpc.c:2700 +#: ../../utils/net_rpc.c:2719 #, c-format msgid "Renaming group %s failed with: %s\n" msgstr "" -#: ../../utils/net_rpc.c:2734 +#: ../../utils/net_rpc.c:2753 msgid "Create specified group" msgstr "" -#: ../../utils/net_rpc.c:2735 +#: ../../utils/net_rpc.c:2754 msgid "" "net rpc group add\n" " Create specified group" msgstr "" -#: ../../utils/net_rpc.c:2743 +#: ../../utils/net_rpc.c:2762 msgid "" "net rpc group delete\n" " Delete specified group" msgstr "" -#: ../../utils/net_rpc.c:2750 +#: ../../utils/net_rpc.c:2769 msgid "Add member to group" msgstr "" -#: ../../utils/net_rpc.c:2751 +#: ../../utils/net_rpc.c:2770 msgid "" "net rpc group addmem\n" " Add member to group" msgstr "" -#: ../../utils/net_rpc.c:2758 +#: ../../utils/net_rpc.c:2777 msgid "Remove member from group" msgstr "" -#: ../../utils/net_rpc.c:2759 +#: ../../utils/net_rpc.c:2778 msgid "" "net rpc group delmem\n" " Remove member from group" msgstr "" -#: ../../utils/net_rpc.c:2766 +#: ../../utils/net_rpc.c:2785 msgid "List groups" msgstr "" -#: ../../utils/net_rpc.c:2767 +#: ../../utils/net_rpc.c:2786 msgid "" "net rpc group list\n" " List groups" msgstr "" -#: ../../utils/net_rpc.c:2774 ../../utils/net_sam.c:2053 +#: ../../utils/net_rpc.c:2793 ../../utils/net_sam.c:2053 msgid "List group members" msgstr "" -#: ../../utils/net_rpc.c:2775 +#: ../../utils/net_rpc.c:2794 msgid "" "net rpc group members\n" " List group members" msgstr "" -#: ../../utils/net_rpc.c:2782 +#: ../../utils/net_rpc.c:2801 msgid "Rename group" msgstr "" -#: ../../utils/net_rpc.c:2783 +#: ../../utils/net_rpc.c:2802 msgid "" "net rpc group rename\n" " Rename group" msgstr "" -#: ../../utils/net_rpc.c:2802 +#: ../../utils/net_rpc.c:2821 msgid "" "net rpc group\n" " Alias for net rpc group list global local builtin\n" msgstr "" -#: ../../utils/net_rpc.c:2874 +#: ../../utils/net_rpc.c:2893 #, c-format msgid "NetShareAdd failed with: %s\n" msgstr "" -#: ../../utils/net_rpc.c:3025 +#: ../../utils/net_rpc.c:3044 msgid "" "Usage\n" "net rpc share list\n" " List shares on remote server\n" msgstr "" -#: ../../utils/net_rpc.c:3059 +#: ../../utils/net_rpc.c:3081 #, c-format msgid "skipping [%s]: not a file share.\n" msgstr "" -#: ../../utils/net_rpc.c:3074 +#: ../../utils/net_rpc.c:3087 +#, c-format +msgid "cli_tdis returned %s\n" +msgstr "" + +#: ../../utils/net_rpc.c:3099 #, c-format msgid "share [%s] is not a diskshare (type: %x)\n" msgstr "" -#: ../../utils/net_rpc.c:3086 +#: ../../utils/net_rpc.c:3111 #, c-format msgid "excluding [%s]\n" msgstr "" #. finally add the share on the dst server -#: ../../utils/net_rpc.c:3153 +#: ../../utils/net_rpc.c:3178 #, c-format msgid "migrating: [%s], path: %s, comment: %s, without share-ACLs\n" msgstr "" -#: ../../utils/net_rpc.c:3167 +#: ../../utils/net_rpc.c:3192 #, c-format msgid " [%s] does already exist\n" msgstr "" -#: ../../utils/net_rpc.c:3173 +#: ../../utils/net_rpc.c:3198 #, c-format msgid "cannot add share: %s\n" msgstr "" -#: ../../utils/net_rpc.c:3203 +#: ../../utils/net_rpc.c:3228 msgid "" "Usage:\n" "net rpc share migrate shares\n" " Migrate shares to local server\n" msgstr "" -#: ../../utils/net_rpc.c:3210 ../../utils/net_rpc.c:3543 ../../utils/net_rpc.c:3668 ../../utils/net_rpc.c:3701 ../../utils/net_rpc.c:6476 ../../utils/net_rpc.c:6530 ../../utils/net_rpc.c:6560 ../../utils/net_rpc.c:6590 ../../utils/net_rpc.c:6620 -#: ../../utils/net_rpc.c:6651 +#: ../../utils/net_rpc.c:3235 ../../utils/net_rpc.c:3568 ../../utils/net_rpc.c:3693 ../../utils/net_rpc.c:3726 ../../utils/net_rpc.c:6505 ../../utils/net_rpc.c:6559 ../../utils/net_rpc.c:6589 ../../utils/net_rpc.c:6619 ../../utils/net_rpc.c:6649 +#: ../../utils/net_rpc.c:6680 #, c-format msgid "no server to migrate\n" msgstr "" -#: ../../utils/net_rpc.c:3270 ../../utils/net_rpc.c:3382 ../../utils/net_rpc.c:3465 +#: ../../utils/net_rpc.c:3295 ../../utils/net_rpc.c:3407 ../../utils/net_rpc.c:3490 #, c-format msgid "Unsupported mode %d\n" msgstr "" -#: ../../utils/net_rpc.c:3275 +#: ../../utils/net_rpc.c:3300 #, c-format msgid "could not handle dir %s: %s\n" msgstr "" -#: ../../utils/net_rpc.c:3285 +#: ../../utils/net_rpc.c:3310 #, c-format msgid "could not handle files\n" msgstr "" -#: ../../utils/net_rpc.c:3312 +#: ../../utils/net_rpc.c:3337 #, c-format msgid "Unsupported file mode %d\n" msgstr "" -#: ../../utils/net_rpc.c:3318 +#: ../../utils/net_rpc.c:3343 #, c-format msgid "could not handle file %s: %s\n" msgstr "" -#: ../../utils/net_rpc.c:3341 +#: ../../utils/net_rpc.c:3366 #, c-format msgid "cli_resolve_path %s failed with error: %s\n" msgstr "" -#: ../../utils/net_rpc.c:3348 +#: ../../utils/net_rpc.c:3373 #, c-format msgid "listing %s failed with error: %s\n" msgstr "" -#: ../../utils/net_rpc.c:3387 +#: ../../utils/net_rpc.c:3412 #, c-format msgid "Could handle directory attributes for top level directory of share %s. Error %s\n" msgstr "" -#: ../../utils/net_rpc.c:3454 +#: ../../utils/net_rpc.c:3479 #, c-format msgid "skipping [%s]: builtin/hidden share\n" msgstr "" -#: ../../utils/net_rpc.c:3469 +#: ../../utils/net_rpc.c:3494 #, c-format msgid " [%s] files and directories %s ACLs, %s DOS Attributes %s\n" msgstr "" -#: ../../utils/net_rpc.c:3472 ../../utils/net_rpc.c:3473 +#: ../../utils/net_rpc.c:3497 ../../utils/net_rpc.c:3498 msgid "including" msgstr "" -#: ../../utils/net_rpc.c:3472 ../../utils/net_rpc.c:3473 ../../utils/net_rpc_printer.c:371 ../../utils/net_rpc_printer.c:372 +#: ../../utils/net_rpc.c:3497 ../../utils/net_rpc.c:3498 ../../utils/net_rpc_printer.c:370 ../../utils/net_rpc_printer.c:371 msgid "without" msgstr "" -#: ../../utils/net_rpc.c:3474 ../../utils/net_rpc_printer.c:373 +#: ../../utils/net_rpc.c:3499 ../../utils/net_rpc_printer.c:372 msgid "(preserving timestamps)" msgstr "" -#: ../../utils/net_rpc.c:3503 +#: ../../utils/net_rpc.c:3528 #, c-format msgid "Could not handle the top level directory permissions for the share: %s\n" msgstr "" -#: ../../utils/net_rpc.c:3511 +#: ../../utils/net_rpc.c:3536 #, c-format msgid "could not handle files for share: %s\n" msgstr "" -#: ../../utils/net_rpc.c:3536 +#: ../../utils/net_rpc.c:3561 msgid "" "Usage:\n" "net share migrate files\n" " Migrate files to local server\n" msgstr "" -#: ../../utils/net_rpc.c:3611 +#: ../../utils/net_rpc.c:3636 #, c-format msgid "migrating: [%s], path: %s, comment: %s, including share-ACLs\n" msgstr "" -#: ../../utils/net_rpc.c:3630 +#: ../../utils/net_rpc.c:3655 #, c-format msgid "cannot set share-acl: %s\n" msgstr "" -#: ../../utils/net_rpc.c:3661 +#: ../../utils/net_rpc.c:3686 msgid "" "Usage:\n" "net rpc share migrate security\n" " Migrate share-acls to local server\n" msgstr "" -#: ../../utils/net_rpc.c:3694 +#: ../../utils/net_rpc.c:3719 msgid "" "Usage:\n" "net rpc share migrate all\n" " Migrates shares including all share settings\n" msgstr "" -#: ../../utils/net_rpc.c:3738 ../../utils/net_rpc.c:3762 +#: ../../utils/net_rpc.c:3763 ../../utils/net_rpc.c:3787 msgid "Migrate shares from remote to local server" msgstr "" -#: ../../utils/net_rpc.c:3739 +#: ../../utils/net_rpc.c:3764 msgid "" "net rpc share migrate all\n" " Migrate shares from remote to local server" msgstr "" -#: ../../utils/net_rpc.c:3746 +#: ../../utils/net_rpc.c:3771 msgid "Migrate files from remote to local server" msgstr "" -#: ../../utils/net_rpc.c:3747 +#: ../../utils/net_rpc.c:3772 msgid "" "net rpc share migrate files\n" " Migrate files from remote to local server" msgstr "" -#: ../../utils/net_rpc.c:3754 +#: ../../utils/net_rpc.c:3779 msgid "Migrate share-ACLs from remote to local server" msgstr "" -#: ../../utils/net_rpc.c:3755 +#: ../../utils/net_rpc.c:3780 msgid "" "net rpc share migrate security\n" " Migrate share-ACLs from remote to local server" msgstr "" -#: ../../utils/net_rpc.c:3763 +#: ../../utils/net_rpc.c:3788 msgid "" "net rpc share migrate shares\n" " Migrate shares from remote to local server" msgstr "" -#: ../../utils/net_rpc.c:3991 +#: ../../utils/net_rpc.c:4016 msgid "malloc failed\n" msgstr "" -#: ../../utils/net_rpc.c:4178 +#: ../../utils/net_rpc.c:4203 msgid "winbind use default domain = yes set, please specify a workgroup\n" msgstr "" -#: ../../utils/net_rpc.c:4187 +#: ../../utils/net_rpc.c:4212 #, c-format msgid "winbind could not list users: %s\n" msgstr "" -#: ../../utils/net_rpc.c:4496 +#: ../../utils/net_rpc.c:4522 msgid "" "Usage:\n" "net rpc share allowedusers\n" " List allowed users\n" msgstr "" -#: ../../utils/net_rpc.c:4546 +#: ../../utils/net_rpc.c:4572 msgid "" "net usersidlist\n" "\tprints out a list of all users the running winbind knows\n" @@ -5087,57 +5178,57 @@ msgid "" "\n" msgstr "" -#: ../../utils/net_rpc.c:4571 +#: ../../utils/net_rpc.c:4597 msgid "Add share" msgstr "" -#: ../../utils/net_rpc.c:4572 +#: ../../utils/net_rpc.c:4598 msgid "" "net rpc share add\n" " Add share" msgstr "" -#: ../../utils/net_rpc.c:4579 +#: ../../utils/net_rpc.c:4605 msgid "Remove share" msgstr "" -#: ../../utils/net_rpc.c:4580 +#: ../../utils/net_rpc.c:4606 msgid "" "net rpc share delete\n" " Remove share" msgstr "" -#: ../../utils/net_rpc.c:4587 +#: ../../utils/net_rpc.c:4613 msgid "Modify allowed users" msgstr "" -#: ../../utils/net_rpc.c:4588 +#: ../../utils/net_rpc.c:4614 msgid "" "net rpc share allowedusers\n" " Modify allowed users" msgstr "" -#: ../../utils/net_rpc.c:4595 +#: ../../utils/net_rpc.c:4621 msgid "Migrate share to local server" msgstr "" -#: ../../utils/net_rpc.c:4596 +#: ../../utils/net_rpc.c:4622 msgid "" "net rpc share migrate\n" " Migrate share to local server" msgstr "" -#: ../../utils/net_rpc.c:4603 +#: ../../utils/net_rpc.c:4629 msgid "List shares" msgstr "" -#: ../../utils/net_rpc.c:4604 +#: ../../utils/net_rpc.c:4630 msgid "" "net rpc share list\n" " List shares" msgstr "" -#: ../../utils/net_rpc.c:4622 +#: ../../utils/net_rpc.c:4648 msgid "" "Usage:\n" "net rpc share\n" @@ -5145,53 +5236,53 @@ msgid "" " Alias for net rpc share list\n" msgstr "" -#: ../../utils/net_rpc.c:4657 +#: ../../utils/net_rpc.c:4683 #, c-format msgid "usage: %s <share> <path> [comment]\n" msgstr "" -#: ../../utils/net_rpc.c:4686 ../../utils/net_rpc.c:4704 +#: ../../utils/net_rpc.c:4712 ../../utils/net_rpc.c:4730 #, c-format msgid "usage: %s <share>\n" msgstr "" -#: ../../utils/net_rpc.c:4718 +#: ../../utils/net_rpc.c:4744 #, c-format msgid "Name: %s\n" msgstr "" -#: ../../utils/net_rpc.c:4719 +#: ../../utils/net_rpc.c:4745 #, c-format msgid "Comment: %s\n" msgstr "" -#: ../../utils/net_rpc.c:4720 +#: ../../utils/net_rpc.c:4746 #, c-format msgid "Path: %s\n" msgstr "" -#: ../../utils/net_rpc.c:4721 +#: ../../utils/net_rpc.c:4747 #, c-format msgid "Password: %s\n" msgstr "" -#: ../../utils/net_rpc.c:4733 +#: ../../utils/net_rpc.c:4759 msgid "List available shares" msgstr "" -#: ../../utils/net_rpc.c:4736 +#: ../../utils/net_rpc.c:4762 msgid "Add a share" msgstr "" -#: ../../utils/net_rpc.c:4739 +#: ../../utils/net_rpc.c:4765 msgid "Delete a share" msgstr "" -#: ../../utils/net_rpc.c:4742 +#: ../../utils/net_rpc.c:4768 msgid "Get information about a share" msgstr "" -#: ../../utils/net_rpc.c:4834 +#: ../../utils/net_rpc.c:4860 msgid "" "\n" "Enumerating open files on remote server:\n" @@ -5201,134 +5292,134 @@ msgid "" "------ --------- ----- ----- ---- \n" msgstr "" -#: ../../utils/net_rpc.c:4860 +#: ../../utils/net_rpc.c:4886 msgid "Close opened file" msgstr "" -#: ../../utils/net_rpc.c:4861 +#: ../../utils/net_rpc.c:4887 msgid "" "net rpc file close\n" " Close opened file" msgstr "" -#: ../../utils/net_rpc.c:4868 +#: ../../utils/net_rpc.c:4894 msgid "List files opened by user" msgstr "" -#: ../../utils/net_rpc.c:4869 +#: ../../utils/net_rpc.c:4895 msgid "" "net rpc file user\n" " List files opened by user" msgstr "" -#: ../../utils/net_rpc.c:4877 +#: ../../utils/net_rpc.c:4903 msgid "Display information about opened file" msgstr "" -#: ../../utils/net_rpc.c:4878 +#: ../../utils/net_rpc.c:4904 msgid "" "net rpc file info\n" " Display information about opened file" msgstr "" -#: ../../utils/net_rpc.c:4898 +#: ../../utils/net_rpc.c:4924 msgid "" "net rpc file\n" " List opened files\n" msgstr "" -#: ../../utils/net_rpc.c:4941 ../../utils/net_rpc.c:4980 +#: ../../utils/net_rpc.c:4967 ../../utils/net_rpc.c:5006 msgid "" "\n" "Shutdown successfully aborted\n" msgstr "" -#: ../../utils/net_rpc.c:5004 +#: ../../utils/net_rpc.c:5030 msgid "" "Usage:\n" "net rpc abortshutdown\n" " Abort a scheduled shutdown\n" msgstr "" -#: ../../utils/net_rpc.c:5050 ../../utils/net_rpc.c:5103 +#: ../../utils/net_rpc.c:5076 ../../utils/net_rpc.c:5129 msgid "This machine will be shutdown shortly" msgstr "" -#: ../../utils/net_rpc.c:5069 ../../utils/net_rpc.c:5124 +#: ../../utils/net_rpc.c:5095 ../../utils/net_rpc.c:5150 msgid "" "\n" "Shutdown of remote machine succeeded\n" msgstr "" -#: ../../utils/net_rpc.c:5151 +#: ../../utils/net_rpc.c:5177 msgid "" "Usage:\n" "net rpc shutdown\n" " Shut down a remote RPC server\n" msgstr "" -#: ../../utils/net_rpc.c:5210 +#: ../../utils/net_rpc.c:5236 msgid "Usage: net rpc trustdom add <domain_name> <trust password>\n" msgstr "" -#: ../../utils/net_rpc.c:5272 +#: ../../utils/net_rpc.c:5298 #, c-format msgid "net rpc trustdom add: create user %s failed %s\n" msgstr "" -#: ../../utils/net_rpc.c:5323 +#: ../../utils/net_rpc.c:5349 msgid "" "Usage:\n" "net rpc trustdom add <domain_name> <trust password>\n" msgstr "" -#: ../../utils/net_rpc.c:5364 +#: ../../utils/net_rpc.c:5390 msgid "Usage: net rpc trustdom del <domain_name>\n" msgstr "" -#: ../../utils/net_rpc.c:5407 +#: ../../utils/net_rpc.c:5433 #, c-format msgid "net rpc trustdom del: LookupNames on user %s failed %s\n" msgstr "" -#: ../../utils/net_rpc.c:5420 +#: ../../utils/net_rpc.c:5446 #, c-format msgid "net rpc trustdom del: OpenUser on user %s failed %s\n" msgstr "" -#: ../../utils/net_rpc.c:5438 +#: ../../utils/net_rpc.c:5464 #, c-format msgid "net rpc trustdom del: RemoveMemberFromForeignDomain on user %s failed %s\n" msgstr "" -#: ../../utils/net_rpc.c:5450 +#: ../../utils/net_rpc.c:5476 #, c-format msgid "net rpc trustdom del: DeleteUser on user %s failed %s\n" msgstr "" -#: ../../utils/net_rpc.c:5457 +#: ../../utils/net_rpc.c:5483 #, c-format msgid "Could not set trust account password: %s\n" msgstr "Konnte Passwort für trust account nicht stetzen: %s\n" -#: ../../utils/net_rpc.c:5481 +#: ../../utils/net_rpc.c:5507 msgid "" "Usage:\n" "net rpc trustdom del <domain>\n" msgstr "" -#: ../../utils/net_rpc.c:5564 +#: ../../utils/net_rpc.c:5590 msgid "" "Usage:\n" "net rpc trustdom establish <domain_name>\n" msgstr "" -#: ../../utils/net_rpc.c:5707 +#: ../../utils/net_rpc.c:5733 #, c-format msgid "Trust to domain %s established\n" msgstr "" -#: ../../utils/net_rpc.c:5728 +#: ../../utils/net_rpc.c:5754 msgid "" "Usage:\n" "net rpc trustdom revoke <domain_name>\n" @@ -5336,7 +5427,7 @@ msgid "" " domain_name\tName of domain to revoke trust\n" msgstr "" -#: ../../utils/net_rpc.c:5863 +#: ../../utils/net_rpc.c:5885 msgid "" "Usage:\n" "net rpc trustdom vampire\n" @@ -5347,7 +5438,7 @@ msgstr "" #. * Keep calling LsaEnumTrustdom over opened pipe until #. * the end of enumeration is reached #. -#: ../../utils/net_rpc.c:5939 +#: ../../utils/net_rpc.c:5961 msgid "" "Vampire trusted domains:\n" "\n" @@ -5357,22 +5448,22 @@ msgstr "" #. * in case of no trusted domains say something rather #. * than just display blank line #. -#: ../../utils/net_rpc.c:5974 ../../utils/net_rpc.c:6121 +#: ../../utils/net_rpc.c:5996 ../../utils/net_rpc.c:6150 msgid "none\n" msgstr "" -#: ../../utils/net_rpc.c:6020 +#: ../../utils/net_rpc.c:6042 msgid "" "Usage:\n" "net rpc trustdom list\n" -" List trust relationships\n" +" List in- and outgoing trust relationships\n" msgstr "" #. #. * Keep calling LsaEnumTrustdom over opened pipe until #. * the end of enumeration is reached #. -#: ../../utils/net_rpc.c:6096 +#: ../../utils/net_rpc.c:6118 msgid "" "Trusted domains list:\n" "\n" @@ -5381,332 +5472,336 @@ msgstr "" #. #. * Listing trusting domains (stored in passdb backend, if local) #. -#: ../../utils/net_rpc.c:6141 +#: ../../utils/net_rpc.c:6169 msgid "" "\n" "Trusting domains list:\n" "\n" msgstr "" -#: ../../utils/net_rpc.c:6244 -msgid "couldn't get domain's sid\n" +#: ../../utils/net_rpc.c:6270 +msgid "strange - couldn't get domain's sid\n" msgstr "" -#: ../../utils/net_rpc.c:6249 +#: ../../utils/net_rpc.c:6275 #, c-format msgid "domain controller is not responding: %s\n" msgstr "" -#: ../../utils/net_rpc.c:6293 -msgid "Add trusted domain's account" +#: ../../utils/net_rpc.c:6278 +msgid "couldn't get domain's sid\n" +msgstr "" + +#: ../../utils/net_rpc.c:6322 +msgid "Add trusting domain's account" msgstr "" -#: ../../utils/net_rpc.c:6294 +#: ../../utils/net_rpc.c:6323 msgid "" "net rpc trustdom add\n" -" Add trusted domain's account" +" Add trusting domain's account" msgstr "" -#: ../../utils/net_rpc.c:6301 -msgid "Remove trusted domain's account" +#: ../../utils/net_rpc.c:6330 +msgid "Remove trusting domain's account" msgstr "" -#: ../../utils/net_rpc.c:6302 +#: ../../utils/net_rpc.c:6331 msgid "" "net rpc trustdom del\n" -" Remove trusted domain's account" +" Remove trusting domain's account" msgstr "" -#: ../../utils/net_rpc.c:6309 -msgid "Establish trust relationship" +#: ../../utils/net_rpc.c:6338 +msgid "Establish outgoing trust relationship" msgstr "" -#: ../../utils/net_rpc.c:6310 +#: ../../utils/net_rpc.c:6339 msgid "" "net rpc trustdom establish\n" -" Establish trust relationship" +" Establish outgoing trust relationship" msgstr "" -#: ../../utils/net_rpc.c:6317 -msgid "Revoke trust relationship" +#: ../../utils/net_rpc.c:6346 +msgid "Revoke outgoing trust relationship" msgstr "" -#: ../../utils/net_rpc.c:6318 +#: ../../utils/net_rpc.c:6347 msgid "" "net rpc trustdom revoke\n" -" Revoke trust relationship" +" Revoke outgoing trust relationship" msgstr "" -#: ../../utils/net_rpc.c:6325 -msgid "List domain trusts" +#: ../../utils/net_rpc.c:6354 +msgid "List in- and outgoing domain trusts" msgstr "" -#: ../../utils/net_rpc.c:6326 +#: ../../utils/net_rpc.c:6355 msgid "" "net rpc trustdom list\n" -" List domain trusts" +" List in- and outgoing domain trusts" msgstr "" -#: ../../utils/net_rpc.c:6333 +#: ../../utils/net_rpc.c:6362 msgid "Vampire trusts from remote server" msgstr "" -#: ../../utils/net_rpc.c:6334 +#: ../../utils/net_rpc.c:6363 msgid "" "net rpc trustdom vampire\n" " Vampire trusts from remote server" msgstr "" -#: ../../utils/net_rpc.c:6386 +#: ../../utils/net_rpc.c:6415 msgid "" "Usage:\n" "net rpc samdump\n" " Dump remote SAM database\n" msgstr "" -#: ../../utils/net_rpc.c:6405 +#: ../../utils/net_rpc.c:6434 msgid "Dump remote SAM database to ldif" msgstr "" -#: ../../utils/net_rpc.c:6406 +#: ../../utils/net_rpc.c:6435 msgid "" "net rpc vampire ldif\n" " Dump remote SAM database to LDIF file or stdout" msgstr "" -#: ../../utils/net_rpc.c:6414 +#: ../../utils/net_rpc.c:6443 msgid "Dump remote SAM database to Kerberos Keytab" msgstr "" -#: ../../utils/net_rpc.c:6415 +#: ../../utils/net_rpc.c:6444 msgid "" "net rpc vampire keytab\n" " Dump remote SAM database to Kerberos keytab file" msgstr "" -#: ../../utils/net_rpc.c:6423 +#: ../../utils/net_rpc.c:6452 msgid "Dump remote SAM database to passdb" msgstr "" -#: ../../utils/net_rpc.c:6424 +#: ../../utils/net_rpc.c:6453 msgid "" "net rpc vampire passdb\n" " Dump remote SAM database to passdb" msgstr "" -#: ../../utils/net_rpc.c:6433 +#: ../../utils/net_rpc.c:6462 msgid "" "Usage:\n" "net rpc vampire\n" " Vampire remote SAM database\n" msgstr "" -#: ../../utils/net_rpc.c:6469 +#: ../../utils/net_rpc.c:6498 msgid "" "Usage:\n" "net rpc printer migrate all\n" " Migrate everything from a print server\n" msgstr "" -#: ../../utils/net_rpc.c:6523 +#: ../../utils/net_rpc.c:6552 msgid "" "Usage:\n" "net rpc printer migrate drivers\n" " Migrate print-drivers from a print-server\n" msgstr "" -#: ../../utils/net_rpc.c:6553 +#: ../../utils/net_rpc.c:6582 msgid "" "Usage:\n" "net rpc printer migrate forms\n" " Migrate print-forms from a print-server\n" msgstr "" -#: ../../utils/net_rpc.c:6583 +#: ../../utils/net_rpc.c:6612 msgid "" "Usage:\n" "net rpc printer migrate printers\n" " Migrate printers from a print-server\n" msgstr "" -#: ../../utils/net_rpc.c:6613 +#: ../../utils/net_rpc.c:6642 msgid "" "Usage:\n" "net rpc printer migrate security\n" " Migrate printer-ACLs from a print-server\n" msgstr "" -#: ../../utils/net_rpc.c:6643 +#: ../../utils/net_rpc.c:6672 msgid "" "Usage:\n" "net rpc printer migrate settings\n" " Migrate printer-settings from a print-server\n" msgstr "" -#: ../../utils/net_rpc.c:6681 +#: ../../utils/net_rpc.c:6710 msgid "Migrate all from remote to local print server" msgstr "" -#: ../../utils/net_rpc.c:6682 +#: ../../utils/net_rpc.c:6711 msgid "" "net rpc printer migrate all\n" " Migrate all from remote to local print server" msgstr "" -#: ../../utils/net_rpc.c:6689 +#: ../../utils/net_rpc.c:6718 msgid "Migrate drivers to local server" msgstr "" -#: ../../utils/net_rpc.c:6690 +#: ../../utils/net_rpc.c:6719 msgid "" "net rpc printer migrate drivers\n" " Migrate drivers to local server" msgstr "" -#: ../../utils/net_rpc.c:6697 +#: ../../utils/net_rpc.c:6726 msgid "Migrate froms to local server" msgstr "" -#: ../../utils/net_rpc.c:6698 +#: ../../utils/net_rpc.c:6727 msgid "" "net rpc printer migrate forms\n" " Migrate froms to local server" msgstr "" -#: ../../utils/net_rpc.c:6705 +#: ../../utils/net_rpc.c:6734 msgid "Migrate printers to local server" msgstr "" -#: ../../utils/net_rpc.c:6706 +#: ../../utils/net_rpc.c:6735 msgid "" "net rpc printer migrate printers\n" " Migrate printers to local server" msgstr "" -#: ../../utils/net_rpc.c:6713 +#: ../../utils/net_rpc.c:6742 msgid "Mirgate printer ACLs to local server" msgstr "" -#: ../../utils/net_rpc.c:6714 +#: ../../utils/net_rpc.c:6743 msgid "" "net rpc printer migrate security\n" " Mirgate printer ACLs to local server" msgstr "" -#: ../../utils/net_rpc.c:6721 +#: ../../utils/net_rpc.c:6750 msgid "Migrate printer settings to local server" msgstr "" -#: ../../utils/net_rpc.c:6722 +#: ../../utils/net_rpc.c:6751 msgid "" "net rpc printer migrate settings\n" " Migrate printer settings to local server" msgstr "" -#: ../../utils/net_rpc.c:6745 +#: ../../utils/net_rpc.c:6774 msgid "" "Usage:\n" "net rpc printer list\n" " List printers on a remote RPC server\n" msgstr "" -#: ../../utils/net_rpc.c:6770 +#: ../../utils/net_rpc.c:6799 msgid "" "Usage:\n" "net rpc printer driver\n" " List printer-drivers on a remote RPC server\n" msgstr "" -#: ../../utils/net_rpc.c:6795 +#: ../../utils/net_rpc.c:6824 msgid "" "Usage:\n" "net rpc printer publish publish\n" " Publish printer in ADS via MSRPC\n" msgstr "" -#: ../../utils/net_rpc.c:6819 +#: ../../utils/net_rpc.c:6848 msgid "" "Usage:\n" "net rpc printer publish update\n" " Update printer in ADS via MSRPC\n" msgstr "" -#: ../../utils/net_rpc.c:6844 +#: ../../utils/net_rpc.c:6873 msgid "" "Usage:\n" "net rpc printer publish unpublish\n" " UnPublish printer in ADS via MSRPC\n" msgstr "" -#: ../../utils/net_rpc.c:6869 +#: ../../utils/net_rpc.c:6898 msgid "" "Usage:\n" "net rpc printer publish list\n" " List published printers via MSRPC\n" msgstr "" -#: ../../utils/net_rpc.c:6900 ../../utils/net_rpc.c:7029 +#: ../../utils/net_rpc.c:6929 ../../utils/net_rpc.c:7058 msgid "Publish printer in AD" msgstr "" -#: ../../utils/net_rpc.c:6901 +#: ../../utils/net_rpc.c:6930 msgid "" "net rpc printer publish publish\n" " Publish printer in AD" msgstr "" -#: ../../utils/net_rpc.c:6908 +#: ../../utils/net_rpc.c:6937 msgid "Update printer in AD" msgstr "" -#: ../../utils/net_rpc.c:6909 +#: ../../utils/net_rpc.c:6938 msgid "" "net rpc printer publish update\n" " Update printer in AD" msgstr "" -#: ../../utils/net_rpc.c:6916 +#: ../../utils/net_rpc.c:6945 msgid "Unpublish printer" msgstr "" -#: ../../utils/net_rpc.c:6917 +#: ../../utils/net_rpc.c:6946 msgid "" "net rpc printer publish unpublish\n" " Unpublish printer" msgstr "" -#: ../../utils/net_rpc.c:6924 +#: ../../utils/net_rpc.c:6953 msgid "List published printers" msgstr "" -#: ../../utils/net_rpc.c:6925 +#: ../../utils/net_rpc.c:6954 msgid "" "net rpc printer publish list\n" " List published printers" msgstr "" -#: ../../utils/net_rpc.c:6934 +#: ../../utils/net_rpc.c:6963 msgid "" "net rpc printer publish\n" " List published printers\n" " Alias of net rpc printer publish list\n" msgstr "" -#: ../../utils/net_rpc.c:6961 +#: ../../utils/net_rpc.c:6990 msgid "" "net rpc printer LIST [printer] [misc. options] [targets]\n" "\tlists all printers on print-server\n" "\n" msgstr "" -#: ../../utils/net_rpc.c:6963 +#: ../../utils/net_rpc.c:6992 msgid "" "net rpc printer DRIVER [printer] [misc. options] [targets]\n" "\tlists all printer-drivers on print-server\n" "\n" msgstr "" -#: ../../utils/net_rpc.c:6965 +#: ../../utils/net_rpc.c:6994 msgid "" "net rpc printer PUBLISH action [printer] [misc. options] [targets]\n" "\tpublishes printer settings in Active Directory\n" @@ -5714,42 +5809,42 @@ msgid "" "\n" msgstr "" -#: ../../utils/net_rpc.c:6968 +#: ../../utils/net_rpc.c:6997 msgid "" "net rpc printer MIGRATE PRINTERS [printer] [misc. options] [targets]\n" "\tmigrates printers from remote to local server\n" "\n" msgstr "" -#: ../../utils/net_rpc.c:6970 +#: ../../utils/net_rpc.c:6999 msgid "" "net rpc printer MIGRATE SETTINGS [printer] [misc. options] [targets]\n" "\tmigrates printer-settings from remote to local server\n" "\n" msgstr "" -#: ../../utils/net_rpc.c:6972 +#: ../../utils/net_rpc.c:7001 msgid "" "net rpc printer MIGRATE DRIVERS [printer] [misc. options] [targets]\n" "\tmigrates printer-drivers from remote to local server\n" "\n" msgstr "" -#: ../../utils/net_rpc.c:6974 +#: ../../utils/net_rpc.c:7003 msgid "" "net rpc printer MIGRATE FORMS [printer] [misc. options] [targets]\n" "\tmigrates printer-forms from remote to local server\n" "\n" msgstr "" -#: ../../utils/net_rpc.c:6976 +#: ../../utils/net_rpc.c:7005 msgid "" "net rpc printer MIGRATE SECURITY [printer] [misc. options] [targets]\n" "\tmigrates printer-ACLs from remote to local server\n" "\n" msgstr "" -#: ../../utils/net_rpc.c:6978 +#: ../../utils/net_rpc.c:7007 msgid "" "net rpc printer MIGRATE ALL [printer] [misc. options] [targets]\n" "\tmigrates drivers, forms, queues, settings and acls from\n" @@ -5757,1172 +5852,1169 @@ msgid "" "\n" msgstr "" -#: ../../utils/net_rpc.c:6984 +#: ../../utils/net_rpc.c:7013 msgid "" "\t-v or --verbose\t\t\tgive verbose output\n" "\t --destination\t\tmigration target server (default: localhost)\n" msgstr "" -#: ../../utils/net_rpc.c:7005 +#: ../../utils/net_rpc.c:7034 msgid "List all printers on print server" msgstr "" -#: ../../utils/net_rpc.c:7006 +#: ../../utils/net_rpc.c:7035 msgid "" "net rpc printer list\n" " List all printers on print server" msgstr "" -#: ../../utils/net_rpc.c:7013 +#: ../../utils/net_rpc.c:7042 msgid "Migrate printer to local server" msgstr "" -#: ../../utils/net_rpc.c:7014 +#: ../../utils/net_rpc.c:7043 msgid "" "net rpc printer migrate\n" " Migrate printer to local server" msgstr "" -#: ../../utils/net_rpc.c:7021 +#: ../../utils/net_rpc.c:7050 msgid "List printer drivers" msgstr "" -#: ../../utils/net_rpc.c:7022 +#: ../../utils/net_rpc.c:7051 msgid "" "net rpc printer driver\n" " List printer drivers" msgstr "" -#: ../../utils/net_rpc.c:7030 +#: ../../utils/net_rpc.c:7059 msgid "" "net rpc printer publish\n" " Publish printer in AD" msgstr "" -#: ../../utils/net_rpc.c:7039 +#: ../../utils/net_rpc.c:7068 msgid "" "net rpc printer\n" " List printers\n" msgstr "" -#: ../../utils/net_rpc.c:7070 +#: ../../utils/net_rpc.c:7099 msgid "Modify global audit settings" msgstr "" -#: ../../utils/net_rpc.c:7071 +#: ../../utils/net_rpc.c:7100 msgid "" "net rpc audit\n" " Modify global audit settings" msgstr "" -#: ../../utils/net_rpc.c:7078 +#: ../../utils/net_rpc.c:7107 msgid "Show basic info about a domain" msgstr "" -#: ../../utils/net_rpc.c:7079 +#: ../../utils/net_rpc.c:7108 msgid "" "net rpc info\n" " Show basic info about a domain" msgstr "" -#: ../../utils/net_rpc.c:7086 +#: ../../utils/net_rpc.c:7115 msgid "Join a domain" msgstr "" -#: ../../utils/net_rpc.c:7087 +#: ../../utils/net_rpc.c:7116 msgid "" "net rpc join\n" " Join a domain" msgstr "" -#: ../../utils/net_rpc.c:7094 +#: ../../utils/net_rpc.c:7123 msgid "Join a domain created in server manager" msgstr "" -#: ../../utils/net_rpc.c:7095 +#: ../../utils/net_rpc.c:7124 msgid "" "net rpc oldjoin\n" " Join a domain created in server manager" msgstr "" -#: ../../utils/net_rpc.c:7102 +#: ../../utils/net_rpc.c:7131 msgid "Test that a join is valid" msgstr "" -#: ../../utils/net_rpc.c:7103 +#: ../../utils/net_rpc.c:7132 msgid "" "net rpc testjoin\n" " Test that a join is valid" msgstr "" -#: ../../utils/net_rpc.c:7111 +#: ../../utils/net_rpc.c:7140 msgid "" "net rpc user\n" " List/modify users" msgstr "" -#: ../../utils/net_rpc.c:7118 +#: ../../utils/net_rpc.c:7147 msgid "Change a user password" msgstr "Benutzerpasswort ändern" -#: ../../utils/net_rpc.c:7119 +#: ../../utils/net_rpc.c:7148 msgid "" "net rpc password\n" " Change a user password\n" " Alias for net rpc user password" msgstr "" -#: ../../utils/net_rpc.c:7128 +#: ../../utils/net_rpc.c:7157 msgid "" "net rpc group\n" " List/modify groups" msgstr "" -#: ../../utils/net_rpc.c:7135 +#: ../../utils/net_rpc.c:7164 msgid "List/modify shares" msgstr "" -#: ../../utils/net_rpc.c:7136 +#: ../../utils/net_rpc.c:7165 msgid "" "net rpc share\n" " List/modify shares" msgstr "" -#: ../../utils/net_rpc.c:7144 +#: ../../utils/net_rpc.c:7173 msgid "" "net rpc file\n" " List open files" msgstr "" -#: ../../utils/net_rpc.c:7151 +#: ../../utils/net_rpc.c:7180 msgid "List/modify printers" msgstr "" -#: ../../utils/net_rpc.c:7152 +#: ../../utils/net_rpc.c:7181 msgid "" "net rpc printer\n" " List/modify printers" msgstr "" -#: ../../utils/net_rpc.c:7160 +#: ../../utils/net_rpc.c:7189 msgid "" "net rpc changetrustpw\n" " Change trust account password" -msgstr "net rpc changetrustpw\n" +msgstr "" +"net rpc changetrustpw\n" " trust account Passwort ändern" -#: ../../utils/net_rpc.c:7167 +#: ../../utils/net_rpc.c:7196 msgid "Modify domain trusts" msgstr "" -#: ../../utils/net_rpc.c:7168 +#: ../../utils/net_rpc.c:7197 msgid "" "net rpc trustdom\n" " Modify domain trusts" msgstr "" -#: ../../utils/net_rpc.c:7175 +#: ../../utils/net_rpc.c:7204 msgid "Abort a remote shutdown" msgstr "" -#: ../../utils/net_rpc.c:7176 +#: ../../utils/net_rpc.c:7205 msgid "" "net rpc abortshutdown\n" " Abort a remote shutdown" msgstr "" -#: ../../utils/net_rpc.c:7183 +#: ../../utils/net_rpc.c:7212 msgid "Shutdown a remote server" msgstr "" -#: ../../utils/net_rpc.c:7184 +#: ../../utils/net_rpc.c:7213 msgid "" "net rpc shutdown\n" " Shutdown a remote server" msgstr "" -#: ../../utils/net_rpc.c:7191 +#: ../../utils/net_rpc.c:7220 msgid "Dump SAM data of remote NT PDC" msgstr "" -#: ../../utils/net_rpc.c:7192 +#: ../../utils/net_rpc.c:7221 msgid "" "net rpc samdump\n" " Dump SAM data of remote NT PDC" msgstr "" -#: ../../utils/net_rpc.c:7199 +#: ../../utils/net_rpc.c:7228 msgid "Sync a remote NT PDC's data into local passdb" msgstr "" -#: ../../utils/net_rpc.c:7200 +#: ../../utils/net_rpc.c:7229 msgid "" "net rpc vampire\n" " Sync a remote NT PDC's data into local passdb" msgstr "" -#: ../../utils/net_rpc.c:7207 +#: ../../utils/net_rpc.c:7236 msgid "Fetch the domain sid into local secrets.tdb" msgstr "" -#: ../../utils/net_rpc.c:7208 +#: ../../utils/net_rpc.c:7237 msgid "" "net rpc getsid\n" " Fetch the domain sid into local secrets.tdb" msgstr "" -#: ../../utils/net_rpc.c:7215 +#: ../../utils/net_rpc.c:7244 msgid "Manage privileges assigned to SID" msgstr "" -#: ../../utils/net_rpc.c:7216 +#: ../../utils/net_rpc.c:7245 msgid "" "net rpc rights\n" " Manage privileges assigned to SID" msgstr "" -#: ../../utils/net_rpc.c:7223 +#: ../../utils/net_rpc.c:7252 msgid "Start/stop/query remote services" msgstr "" -#: ../../utils/net_rpc.c:7224 +#: ../../utils/net_rpc.c:7253 msgid "" "net rpc service\n" " Start/stop/query remote services" msgstr "" -#: ../../utils/net_rpc.c:7231 +#: ../../utils/net_rpc.c:7260 msgid "Manage registry hives" msgstr "" -#: ../../utils/net_rpc.c:7232 +#: ../../utils/net_rpc.c:7261 msgid "" "net rpc registry\n" " Manage registry hives" msgstr "" -#: ../../utils/net_rpc.c:7239 +#: ../../utils/net_rpc.c:7268 msgid "Open interactive shell on remote server" msgstr "" -#: ../../utils/net_rpc.c:7240 +#: ../../utils/net_rpc.c:7269 msgid "" "net rpc shell\n" " Open interactive shell on remote server" msgstr "" -#: ../../utils/net_rpc_audit.c:27 +#: ../../utils/net_rpc_audit.c:28 msgid "net rpc audit list View configured Auditing policies\n" msgstr "" -#: ../../utils/net_rpc_audit.c:28 +#: ../../utils/net_rpc_audit.c:29 msgid "net rpc audit enable Enable Auditing\n" msgstr "" -#: ../../utils/net_rpc_audit.c:29 +#: ../../utils/net_rpc_audit.c:30 msgid "net rpc audit disable Disable Auditing\n" msgstr "" -#: ../../utils/net_rpc_audit.c:30 +#: ../../utils/net_rpc_audit.c:31 msgid "net rpc audit get <category> View configured Auditing policy setting\n" msgstr "" -#: ../../utils/net_rpc_audit.c:31 +#: ../../utils/net_rpc_audit.c:32 msgid "" "net rpc audit set <category> <policy> Set Auditing policies\n" "\n" msgstr "" -#: ../../utils/net_rpc_audit.c:32 +#: ../../utils/net_rpc_audit.c:33 msgid "\tcategory can be one of: SYSTEM, LOGON, OBJECT, PRIVILEGE, PROCESS, POLICY, SAM, DIRECTORY or ACCOUNT\n" msgstr "" -#: ../../utils/net_rpc_audit.c:33 +#: ../../utils/net_rpc_audit.c:34 msgid "" "\tpolicy can be one of: SUCCESS, FAILURE, ALL or NONE\n" "\n" msgstr "" -#: ../../utils/net_rpc_audit.c:47 ../../utils/net_util.c:611 +#: ../../utils/net_rpc_audit.c:45 ../../utils/net_util.c:613 msgid "Unknown" msgstr "" -#: ../../utils/net_rpc_audit.c:50 +#: ../../utils/net_rpc_audit.c:48 msgid "Invalid" msgstr "" -#: ../../utils/net_rpc_audit.c:58 +#: ../../utils/net_rpc_audit.c:51 #, c-format -msgid "\t%s%s%s\n" +msgid "\t%-30s%s\n" msgstr "" -#: ../../utils/net_rpc_audit.c:80 ../../utils/net_rpc_audit.c:147 +#: ../../utils/net_rpc_audit.c:73 ../../utils/net_rpc_audit.c:140 msgid "insufficient arguments\n" msgstr "" -#: ../../utils/net_rpc_audit.c:86 ../../utils/net_rpc_audit.c:153 +#: ../../utils/net_rpc_audit.c:79 ../../utils/net_rpc_audit.c:146 #, c-format msgid "invalid auditing category: %s\n" msgstr "Ungültige Audit-Kategorie: %s\n" -#: ../../utils/net_rpc_audit.c:122 +#: ../../utils/net_rpc_audit.c:115 #, c-format msgid "failed to get auditing policy: %s\n" msgstr "" -#: ../../utils/net_rpc_audit.c:168 +#: ../../utils/net_rpc_audit.c:161 #, c-format msgid "invalid auditing policy: %s\n" msgstr "Ungültige Audit-Regel: %s\n" -#: ../../utils/net_rpc_audit.c:212 +#: ../../utils/net_rpc_audit.c:205 #, c-format msgid "failed to set audit policy: %s\n" msgstr "" -#: ../../utils/net_rpc_audit.c:261 +#: ../../utils/net_rpc_audit.c:254 #, c-format msgid "%s: %s\n" msgstr "" -#: ../../utils/net_rpc_audit.c:262 +#: ../../utils/net_rpc_audit.c:255 msgid "failed to enable audit policy" msgstr "" -#: ../../utils/net_rpc_audit.c:263 +#: ../../utils/net_rpc_audit.c:256 msgid "failed to disable audit policy" msgstr "" -#: ../../utils/net_rpc_audit.c:335 +#: ../../utils/net_rpc_audit.c:328 #, c-format msgid "Auditing:\t\t" msgstr "" -#: ../../utils/net_rpc_audit.c:338 +#: ../../utils/net_rpc_audit.c:331 #, c-format msgid "Enabled" msgstr "" -#: ../../utils/net_rpc_audit.c:341 +#: ../../utils/net_rpc_audit.c:334 #, c-format msgid "Disabled" msgstr "" -#: ../../utils/net_rpc_audit.c:344 +#: ../../utils/net_rpc_audit.c:337 #, c-format msgid "unknown (%d)" msgstr "" -#: ../../utils/net_rpc_audit.c:350 +#: ../../utils/net_rpc_audit.c:343 #, c-format msgid "Auditing categories:\t%d\n" msgstr "" -#: ../../utils/net_rpc_audit.c:351 +#: ../../utils/net_rpc_audit.c:344 #, c-format msgid "Auditing settings:\n" msgstr "" -#: ../../utils/net_rpc_audit.c:361 +#: ../../utils/net_rpc_audit.c:354 #, c-format msgid "failed to list auditing policies: %s\n" msgstr "" -#: ../../utils/net_rpc_audit.c:374 +#: ../../utils/net_rpc_audit.c:367 msgid "" "Usage:\n" "net rpc audit get\n" " View configured audit setting\n" msgstr "" -#: ../../utils/net_rpc_audit.c:390 +#: ../../utils/net_rpc_audit.c:383 msgid "" "Usage:\n" "net rpc audit set\n" " Set audit policies\n" msgstr "" -#: ../../utils/net_rpc_audit.c:406 +#: ../../utils/net_rpc_audit.c:399 msgid "" "Usage:\n" "net rpc audit enable\n" " Enable auditing\n" msgstr "" -#: ../../utils/net_rpc_audit.c:422 +#: ../../utils/net_rpc_audit.c:415 msgid "" "Usage:\n" "net rpc audit disable\n" " Disable auditing\n" msgstr "" -#: ../../utils/net_rpc_audit.c:438 +#: ../../utils/net_rpc_audit.c:431 msgid "" "Usage:\n" "net rpc audit list\n" " List auditing settings\n" msgstr "" -#: ../../utils/net_rpc_audit.c:458 +#: ../../utils/net_rpc_audit.c:451 msgid "View configured auditing settings" msgstr "" -#: ../../utils/net_rpc_audit.c:459 +#: ../../utils/net_rpc_audit.c:452 msgid "" "net rpc audit get\n" " View configured auditing settings" msgstr "" -#: ../../utils/net_rpc_audit.c:466 +#: ../../utils/net_rpc_audit.c:459 msgid "Set auditing policies" msgstr "" -#: ../../utils/net_rpc_audit.c:467 +#: ../../utils/net_rpc_audit.c:460 msgid "" "net rpc audit set\n" " Set auditing policies" msgstr "" -#: ../../utils/net_rpc_audit.c:474 +#: ../../utils/net_rpc_audit.c:467 msgid "Enable auditing" msgstr "" -#: ../../utils/net_rpc_audit.c:475 +#: ../../utils/net_rpc_audit.c:468 msgid "" "net rpc audit enable\n" " Enable auditing" msgstr "" -#: ../../utils/net_rpc_audit.c:482 +#: ../../utils/net_rpc_audit.c:475 msgid "Disable auditing" msgstr "" -#: ../../utils/net_rpc_audit.c:483 +#: ../../utils/net_rpc_audit.c:476 msgid "" "net rpc audit disable\n" " Disable auditing" msgstr "" -#: ../../utils/net_rpc_audit.c:490 +#: ../../utils/net_rpc_audit.c:483 msgid "List configured auditing settings" msgstr "" -#: ../../utils/net_rpc_audit.c:491 +#: ../../utils/net_rpc_audit.c:484 msgid "" "net rpc audit list\n" " List configured auditing settings" msgstr "" -#: ../../utils/net_rpc_join.c:290 +#: ../../utils/net_rpc_join.c:297 msgid "Creation of workstation account failed\n" msgstr "" -#: ../../utils/net_rpc_join.c:297 +#: ../../utils/net_rpc_join.c:304 msgid "User specified does not have administrator privileges\n" msgstr "" -#: ../../utils/net_rpc_join.c:403 ../../utils/net_rpc_join.c:431 +#: ../../utils/net_rpc_join.c:410 ../../utils/net_rpc_join.c:438 #, c-format msgid "" "Please make sure that no computer account\n" "named like this machine (%s) exists in the domain\n" msgstr "" -#: ../../utils/net_rpc_join.c:468 +#: ../../utils/net_rpc_join.c:475 #, c-format msgid "Unable to join domain %s.\n" msgstr "" -#: ../../utils/net_rpc_join.c:492 +#: ../../utils/net_rpc_join.c:499 msgid "" "Usage\n" "net rpc testjoin\n" " Test if a join is OK\n" msgstr "" -#: ../../utils/net_rpc_join.c:501 +#: ../../utils/net_rpc_join.c:508 #, c-format msgid "Join to domain '%s' is not valid: %s\n" msgstr "" -#: ../../utils/net_rpc_join.c:506 +#: ../../utils/net_rpc_join.c:513 #, c-format msgid "Join to '%s' is OK\n" msgstr "" -#: ../../utils/net_rpc_printer.c:54 +#: ../../utils/net_rpc_printer.c:55 #, c-format msgid "Printer Driver Info 3:\n" msgstr "" -#: ../../utils/net_rpc_printer.c:55 +#: ../../utils/net_rpc_printer.c:56 #, c-format msgid "\tVersion: [%x]\n" msgstr "" -#: ../../utils/net_rpc_printer.c:56 +#: ../../utils/net_rpc_printer.c:57 #, c-format msgid "\tDriver Name: [%s]\n" msgstr "" -#: ../../utils/net_rpc_printer.c:57 +#: ../../utils/net_rpc_printer.c:58 #, c-format msgid "\tArchitecture: [%s]\n" msgstr "" -#: ../../utils/net_rpc_printer.c:58 +#: ../../utils/net_rpc_printer.c:59 #, c-format msgid "\tDriver Path: [%s]\n" msgstr "" -#: ../../utils/net_rpc_printer.c:59 +#: ../../utils/net_rpc_printer.c:60 #, c-format msgid "\tDatafile: [%s]\n" msgstr "" -#: ../../utils/net_rpc_printer.c:60 +#: ../../utils/net_rpc_printer.c:61 #, c-format msgid "" "\tConfigfile: [%s]\n" "\n" msgstr "" -#: ../../utils/net_rpc_printer.c:61 +#: ../../utils/net_rpc_printer.c:62 #, c-format msgid "" "\tHelpfile: [%s]\n" "\n" msgstr "" -#: ../../utils/net_rpc_printer.c:64 +#: ../../utils/net_rpc_printer.c:65 #, c-format msgid "\tDependentfiles: [%s]\n" msgstr "" -#: ../../utils/net_rpc_printer.c:69 +#: ../../utils/net_rpc_printer.c:70 #, c-format msgid "\tMonitorname: [%s]\n" msgstr "" -#: ../../utils/net_rpc_printer.c:70 +#: ../../utils/net_rpc_printer.c:71 #, c-format msgid "" "\tDefaultdatatype: [%s]\n" "\n" msgstr "" -#: ../../utils/net_rpc_printer.c:79 +#: ../../utils/net_rpc_printer.c:81 #, c-format msgid "\t[%s:%s]: REG_DWORD: 0x%08x\n" msgstr "" -#: ../../utils/net_rpc_printer.c:92 +#: ../../utils/net_rpc_printer.c:91 #, c-format msgid "\t[%s:%s]: REG_SZ: %s\n" msgstr "" -#: ../../utils/net_rpc_printer.c:97 +#: ../../utils/net_rpc_printer.c:96 #, c-format msgid "\t[%s:%s]: REG_BINARY: unknown length value not displayed\n" msgstr "" -#: ../../utils/net_rpc_printer.c:109 -msgid "reg_pull_multi_sz failed\n" -msgstr "" - -#: ../../utils/net_rpc_printer.c:121 +#: ../../utils/net_rpc_printer.c:120 #, c-format msgid "\t%s: unknown type %d\n" msgstr "" -#: ../../utils/net_rpc_printer.c:255 +#: ../../utils/net_rpc_printer.c:254 #, c-format msgid "could not close %s on originating server: %s\n" msgstr "" -#: ../../utils/net_rpc_printer.c:263 +#: ../../utils/net_rpc_printer.c:262 #, c-format msgid "could not close %s on destination server: %s\n" msgstr "" -#: ../../utils/net_rpc_printer.c:356 +#: ../../utils/net_rpc_printer.c:355 #, c-format msgid "malloc fail for size %d\n" msgstr "" -#: ../../utils/net_rpc_printer.c:367 +#: ../../utils/net_rpc_printer.c:366 #, c-format msgid "copying [\\\\%s\\%s%s] => [\\\\%s\\%s%s] %s ACLs and %s DOS Attributes %s\n" msgstr "" -#: ../../utils/net_rpc_printer.c:371 ../../utils/net_rpc_printer.c:372 +#: ../../utils/net_rpc_printer.c:370 ../../utils/net_rpc_printer.c:371 msgid "with" msgstr "" -#: ../../utils/net_rpc_printer.c:391 +#: ../../utils/net_rpc_printer.c:390 #, c-format msgid "Error writing file: %s\n" msgstr "" -#: ../../utils/net_rpc_printer.c:415 +#: ../../utils/net_rpc_printer.c:414 #, c-format msgid "cannot check for directory %s: %s\n" msgstr "" -#: ../../utils/net_rpc_printer.c:425 +#: ../../utils/net_rpc_printer.c:424 #, c-format msgid "could not close file on originating server: %s\n" msgstr "" -#: ../../utils/net_rpc_printer.c:433 +#: ../../utils/net_rpc_printer.c:432 #, c-format msgid "could not close file on destination server: %s\n" msgstr "" -#: ../../utils/net_rpc_printer.c:566 +#: ../../utils/net_rpc_printer.c:565 #, c-format msgid "cannot check %s: %s\n" msgstr "" -#: ../../utils/net_rpc_printer.c:607 +#: ../../utils/net_rpc_printer.c:606 #, c-format msgid "copying driver: [%s], for architecture: [%s], version: [%d]\n" msgstr "" -#: ../../utils/net_rpc_printer.c:676 +#: ../../utils/net_rpc_printer.c:675 #, c-format msgid "cannot enum printers: %s\n" msgstr "" -#: ../../utils/net_rpc_printer.c:709 +#: ../../utils/net_rpc_printer.c:708 #, c-format msgid "no access to printer [%s] on [%s] for user [%s] granted\n" msgstr "" -#: ../../utils/net_rpc_printer.c:716 +#: ../../utils/net_rpc_printer.c:715 #, c-format msgid "cannot open printer %s on server %s: %s\n" msgstr "" -#: ../../utils/net_rpc_printer.c:742 +#: ../../utils/net_rpc_printer.c:741 #, c-format msgid "cannot get printer-info: %s\n" msgstr "" -#: ../../utils/net_rpc_printer.c:823 ../../utils/net_rpc_printer.c:1318 +#: ../../utils/net_rpc_printer.c:822 ../../utils/net_rpc_printer.c:1326 #, c-format msgid "cannot set printer-info: %s\n" msgstr "" -#: ../../utils/net_rpc_printer.c:851 +#: ../../utils/net_rpc_printer.c:850 #, c-format msgid "unable to set printerdata: %s\n" msgstr "" -#: ../../utils/net_rpc_printer.c:872 +#: ../../utils/net_rpc_printer.c:871 #, c-format msgid "enumprinterkey failed: %s\n" msgstr "" -#: ../../utils/net_rpc_printer.c:898 +#: ../../utils/net_rpc_printer.c:897 #, c-format msgid "enumprinterdataex failed: %s\n" msgstr "" -#: ../../utils/net_rpc_printer.c:926 +#: ../../utils/net_rpc_printer.c:934 #, c-format msgid "could not set printerdataex: %s\n" msgstr "" -#: ../../utils/net_rpc_printer.c:951 +#: ../../utils/net_rpc_printer.c:959 #, c-format msgid "could not enum forms: %s\n" msgstr "" -#: ../../utils/net_rpc_printer.c:975 +#: ../../utils/net_rpc_printer.c:983 #, c-format msgid "cannot enum drivers: %s\n" msgstr "" -#: ../../utils/net_rpc_printer.c:1008 +#: ../../utils/net_rpc_printer.c:1016 #, c-format msgid "cannot get driver: %s\n" msgstr "" -#: ../../utils/net_rpc_printer.c:1038 +#: ../../utils/net_rpc_printer.c:1046 #, c-format msgid "unsupported info level: %d\n" msgstr "" -#: ../../utils/net_rpc_printer.c:1049 +#: ../../utils/net_rpc_printer.c:1057 #, c-format msgid "You are not allowed to add drivers\n" msgstr "" -#: ../../utils/net_rpc_printer.c:1053 +#: ../../utils/net_rpc_printer.c:1061 #, c-format msgid "cannot add driver: %s\n" msgstr "" -#: ../../utils/net_rpc_printer.c:1153 +#: ../../utils/net_rpc_printer.c:1161 #, c-format msgid "printer %d: %s, shared as: %s\n" msgstr "" -#: ../../utils/net_rpc_printer.c:1193 +#: ../../utils/net_rpc_printer.c:1201 #, c-format msgid "listing printer-drivers\n" msgstr "" -#: ../../utils/net_rpc_printer.c:1208 +#: ../../utils/net_rpc_printer.c:1216 #, c-format msgid "no drivers found on server for architecture: [%s].\n" msgstr "" -#: ../../utils/net_rpc_printer.c:1214 +#: ../../utils/net_rpc_printer.c:1222 #, c-format msgid "got %d printer-drivers for architecture: [%s]\n" msgstr "" -#: ../../utils/net_rpc_printer.c:1287 +#: ../../utils/net_rpc_printer.c:1295 msgid "published" msgstr "" -#: ../../utils/net_rpc_printer.c:1290 +#: ../../utils/net_rpc_printer.c:1298 msgid "updated" msgstr "" -#: ../../utils/net_rpc_printer.c:1293 +#: ../../utils/net_rpc_printer.c:1301 msgid "unpublished" msgstr "" -#: ../../utils/net_rpc_printer.c:1296 +#: ../../utils/net_rpc_printer.c:1304 msgid "unknown action" msgstr "" -#: ../../utils/net_rpc_printer.c:1297 +#: ../../utils/net_rpc_printer.c:1305 #, c-format msgid "unkown action: %d\n" msgstr "" -#: ../../utils/net_rpc_printer.c:1323 +#: ../../utils/net_rpc_printer.c:1331 #, c-format msgid "successfully %s printer %s in Active Directory\n" msgstr "" -#: ../../utils/net_rpc_printer.c:1435 +#: ../../utils/net_rpc_printer.c:1443 #, c-format msgid "printer [%s] is published" msgstr "" -#: ../../utils/net_rpc_printer.c:1438 +#: ../../utils/net_rpc_printer.c:1446 #, c-format msgid ", guid: %s" msgstr "" -#: ../../utils/net_rpc_printer.c:1442 +#: ../../utils/net_rpc_printer.c:1450 #, c-format msgid "printer [%s] is unpublished\n" msgstr "" -#: ../../utils/net_rpc_printer.c:1446 +#: ../../utils/net_rpc_printer.c:1454 #, c-format msgid "printer [%s] is currently updating\n" msgstr "" -#: ../../utils/net_rpc_printer.c:1450 +#: ../../utils/net_rpc_printer.c:1458 #, c-format msgid "unkown state: %d\n" msgstr "" -#: ../../utils/net_rpc_printer.c:1520 ../../utils/net_rpc_printer.c:1667 ../../utils/net_rpc_printer.c:1850 ../../utils/net_rpc_printer.c:2039 ../../utils/net_rpc_printer.c:2206 +#: ../../utils/net_rpc_printer.c:1528 ../../utils/net_rpc_printer.c:1675 ../../utils/net_rpc_printer.c:1858 ../../utils/net_rpc_printer.c:2047 ../../utils/net_rpc_printer.c:2214 #, c-format msgid "no printers found on server.\n" msgstr "" -#: ../../utils/net_rpc_printer.c:1541 +#: ../../utils/net_rpc_printer.c:1549 #, c-format msgid "migrating printer ACLs for: [%s] / [%s]\n" msgstr "" -#: ../../utils/net_rpc_printer.c:1687 +#: ../../utils/net_rpc_printer.c:1695 #, c-format msgid "migrating printer forms for: [%s] / [%s]\n" msgstr "" -#: ../../utils/net_rpc_printer.c:1723 +#: ../../utils/net_rpc_printer.c:1731 #, c-format msgid "\tmigrating form # %d [%s] of type [%d]\n" msgstr "" -#: ../../utils/net_rpc_printer.c:1739 +#: ../../utils/net_rpc_printer.c:1747 #, c-format msgid "\tAddForm form %d: [%s] refused.\n" msgstr "" -#: ../../utils/net_rpc_printer.c:1872 +#: ../../utils/net_rpc_printer.c:1880 #, c-format msgid "migrating printer driver for: [%s] / [%s]\n" msgstr "" -#: ../../utils/net_rpc_printer.c:2059 +#: ../../utils/net_rpc_printer.c:2067 #, c-format msgid "migrating printer queue for: [%s] / [%s]\n" msgstr "" -#: ../../utils/net_rpc_printer.c:2071 +#: ../../utils/net_rpc_printer.c:2079 #, c-format msgid "could not get printer, creating printer.\n" msgstr "" #. copy each src printer to a dst printer 1:1, #. maybe some values have to be changed though -#: ../../utils/net_rpc_printer.c:2095 +#: ../../utils/net_rpc_printer.c:2103 #, c-format msgid "creating printer: %s\n" msgstr "" -#: ../../utils/net_rpc_printer.c:2106 +#: ../../utils/net_rpc_printer.c:2114 #, c-format msgid "printer [%s] successfully added.\n" msgstr "" -#: ../../utils/net_rpc_printer.c:2109 +#: ../../utils/net_rpc_printer.c:2117 #, c-format msgid "printer [%s] already exists.\n" msgstr "" -#: ../../utils/net_rpc_printer.c:2112 +#: ../../utils/net_rpc_printer.c:2120 #, c-format msgid "could not create printer [%s]\n" msgstr "" -#: ../../utils/net_rpc_printer.c:2240 +#: ../../utils/net_rpc_printer.c:2248 #, c-format msgid "migrating printer settings for: [%s] / [%s]\n" msgstr "" -#: ../../utils/net_rpc_printer.c:2393 +#: ../../utils/net_rpc_printer.c:2401 #, c-format msgid "got no key-data\n" msgstr "" -#: ../../utils/net_rpc_registry.c:389 ../../utils/net_rpc_registry.c:461 ../../utils/net_rpc_registry.c:522 ../../utils/net_rpc_registry.c:791 ../../utils/net_rpc_registry.c:862 ../../utils/net_rpc_registry.c:1171 +#: ../../utils/net_rpc_registry.c:430 ../../utils/net_rpc_registry.c:502 ../../utils/net_rpc_registry.c:563 ../../utils/net_rpc_registry.c:832 ../../utils/net_rpc_registry.c:903 ../../utils/net_rpc_registry.c:1210 #, c-format msgid "registry_openkey failed: %s\n" msgstr "" -#: ../../utils/net_rpc_registry.c:418 +#: ../../utils/net_rpc_registry.c:459 #, c-format msgid "registry_setvalue failed: %s\n" msgstr "" -#: ../../utils/net_rpc_registry.c:472 +#: ../../utils/net_rpc_registry.c:513 #, c-format msgid "registry_deletevalue failed: %s\n" msgstr "" -#: ../../utils/net_rpc_registry.c:543 ../../utils/net_rpc_registry.c:560 +#: ../../utils/net_rpc_registry.c:584 ../../utils/net_rpc_registry.c:601 #, c-format msgid "registry_queryvalue failed: %s\n" msgstr "" -#: ../../utils/net_rpc_registry.c:673 +#: ../../utils/net_rpc_registry.c:714 #, c-format msgid "createkey returned %s\n" msgstr "" -#: ../../utils/net_rpc_registry.c:702 +#: ../../utils/net_rpc_registry.c:743 msgid "usage: net rpc registry createkey <key>\n" msgstr "" -#: ../../utils/net_rpc_registry.c:741 +#: ../../utils/net_rpc_registry.c:782 #, c-format msgid "deletekey returned %s\n" msgstr "" -#: ../../utils/net_rpc_registry.c:752 +#: ../../utils/net_rpc_registry.c:793 msgid "usage: net rpc registry deletekey <key>\n" msgstr "" -#: ../../utils/net_rpc_registry.c:782 +#: ../../utils/net_rpc_registry.c:823 msgid "Usage: net rpc registry enumerate <path>\n" msgstr "" -#: ../../utils/net_rpc_registry.c:783 +#: ../../utils/net_rpc_registry.c:824 msgid "Example: net rpc registry enumerate 'HKLM\\Software\\Samba'\n" msgstr "" -#: ../../utils/net_rpc_registry.c:799 +#: ../../utils/net_rpc_registry.c:840 #, c-format msgid "enumerating keys failed: %s\n" msgstr "" -#: ../../utils/net_rpc_registry.c:811 +#: ../../utils/net_rpc_registry.c:852 #, c-format msgid "enumerating values failed: %s\n" msgstr "" -#: ../../utils/net_rpc_registry.c:854 +#: ../../utils/net_rpc_registry.c:895 msgid "Usage: net rpc registry backup <path> <file> \n" msgstr "" -#: ../../utils/net_rpc_registry.c:870 +#: ../../utils/net_rpc_registry.c:911 #, c-format msgid "Unable to save [%s] to %s:%s\n" msgstr "" -#: ../../utils/net_rpc_registry.c:937 +#: ../../utils/net_rpc_registry.c:976 msgid "unknown" msgstr "" -#: ../../utils/net_rpc_registry.c:1044 +#: ../../utils/net_rpc_registry.c:1083 msgid "Usage: net rpc registry dump <file> \n" msgstr "" -#: ../../utils/net_rpc_registry.c:1048 ../../utils/net_rpc_registry.c:1093 ../../utils/net_rpc_registry.c:1100 +#: ../../utils/net_rpc_registry.c:1087 ../../utils/net_rpc_registry.c:1132 ../../utils/net_rpc_registry.c:1139 #, c-format msgid "Opening %s...." msgstr "" -#: ../../utils/net_rpc_registry.c:1050 ../../utils/net_rpc_registry.c:1095 +#: ../../utils/net_rpc_registry.c:1089 ../../utils/net_rpc_registry.c:1134 #, c-format msgid "Failed to open %s for reading\n" msgstr "" -#: ../../utils/net_rpc_registry.c:1058 ../../utils/net_rpc_registry.c:1110 +#: ../../utils/net_rpc_registry.c:1097 ../../utils/net_rpc_registry.c:1149 msgid "Could not get rootkey\n" msgstr "" -#: ../../utils/net_rpc_registry.c:1071 +#: ../../utils/net_rpc_registry.c:1110 msgid "Closing registry..." msgstr "" -#: ../../utils/net_rpc_registry.c:1088 +#: ../../utils/net_rpc_registry.c:1127 msgid "Usage: net rpc registry copy <srcfile> <newfile>\n" msgstr "" -#: ../../utils/net_rpc_registry.c:1102 +#: ../../utils/net_rpc_registry.c:1141 #, c-format msgid "Failed to open %s for writing\n" msgstr "" -#: ../../utils/net_rpc_registry.c:1113 +#: ../../utils/net_rpc_registry.c:1152 #, c-format msgid "RootKey: [%s]\n" msgstr "" -#: ../../utils/net_rpc_registry.c:1121 ../../utils/net_rpc_registry.c:1127 +#: ../../utils/net_rpc_registry.c:1160 ../../utils/net_rpc_registry.c:1166 #, c-format msgid "Closing %s..." msgstr "" -#: ../../utils/net_rpc_registry.c:1160 +#: ../../utils/net_rpc_registry.c:1199 msgid "Usage: net rpc registry getsd <path> <secinfo>\n" msgstr "" -#: ../../utils/net_rpc_registry.c:1162 +#: ../../utils/net_rpc_registry.c:1201 msgid "Example: net rpc registry getsd 'HKLM\\Software\\Samba'\n" msgstr "" -#: ../../utils/net_rpc_registry.c:1192 +#: ../../utils/net_rpc_registry.c:1231 #, c-format msgid "getting sd failed: %s\n" msgstr "" -#: ../../utils/net_rpc_registry.c:1235 +#: ../../utils/net_rpc_registry.c:1274 msgid "" "net rpc registry enumerate\n" " Enumerate registry keys and values" msgstr "" -#: ../../utils/net_rpc_registry.c:1243 +#: ../../utils/net_rpc_registry.c:1282 msgid "" "net rpc registry createkey\n" " Create a new registry key" msgstr "" -#: ../../utils/net_rpc_registry.c:1251 +#: ../../utils/net_rpc_registry.c:1290 msgid "" "net rpc registry deletekey\n" " Delete a registry key" msgstr "" -#: ../../utils/net_rpc_registry.c:1259 +#: ../../utils/net_rpc_registry.c:1298 msgid "" "net rpc registry getvalue\n" " Print a registry value" msgstr "" -#: ../../utils/net_rpc_registry.c:1267 +#: ../../utils/net_rpc_registry.c:1306 msgid "" "net rpc registry getvalueraw\n" " Print a registry value (raw version)" msgstr "" -#: ../../utils/net_rpc_registry.c:1275 +#: ../../utils/net_rpc_registry.c:1314 msgid "" "net rpc registry setvalue\n" " Set a new registry value" msgstr "" -#: ../../utils/net_rpc_registry.c:1283 +#: ../../utils/net_rpc_registry.c:1322 msgid "" "net rpc registry deletevalue\n" " Delete a registry value" msgstr "" -#: ../../utils/net_rpc_registry.c:1290 +#: ../../utils/net_rpc_registry.c:1329 msgid "Save a registry file" msgstr "" -#: ../../utils/net_rpc_registry.c:1291 +#: ../../utils/net_rpc_registry.c:1330 msgid "" "net rpc registry save\n" " Save a registry file" msgstr "" -#: ../../utils/net_rpc_registry.c:1298 +#: ../../utils/net_rpc_registry.c:1337 msgid "Dump a registry file" msgstr "" -#: ../../utils/net_rpc_registry.c:1299 +#: ../../utils/net_rpc_registry.c:1338 msgid "" "net rpc registry dump\n" " Dump a registry file" msgstr "" -#: ../../utils/net_rpc_registry.c:1306 +#: ../../utils/net_rpc_registry.c:1345 msgid "Copy a registry file" msgstr "" -#: ../../utils/net_rpc_registry.c:1307 +#: ../../utils/net_rpc_registry.c:1346 msgid "" "net rpc registry copy\n" " Copy a registry file" msgstr "" -#: ../../utils/net_rpc_registry.c:1315 +#: ../../utils/net_rpc_registry.c:1354 msgid "" "net rpc registry getsd\n" " Get security descriptior" msgstr "" -#: ../../utils/net_rpc_rights.c:202 +#: ../../utils/net_rpc_rights.c:203 msgid "No privileges assigned\n" msgstr "" -#: ../../utils/net_rpc_rights.c:367 +#: ../../utils/net_rpc_rights.c:368 #, c-format msgid "No such privilege exists: %s.\n" msgstr "" -#: ../../utils/net_rpc_rights.c:370 +#: ../../utils/net_rpc_rights.c:371 #, c-format msgid "Error resolving privilege display name [%s].\n" msgstr "" -#: ../../utils/net_rpc_rights.c:379 +#: ../../utils/net_rpc_rights.c:380 #, c-format msgid "Error enumerating accounts for privilege %s [%s].\n" msgstr "" -#: ../../utils/net_rpc_rights.c:415 +#: ../../utils/net_rpc_rights.c:416 msgid "Usage: net rpc rights list [[accounts|privileges] [name|SID]]\n" msgstr "" -#: ../../utils/net_rpc_rights.c:453 +#: ../../utils/net_rpc_rights.c:454 msgid "Usage: net rpc rights grant <name|SID> <rights...>\n" msgstr "" -#: ../../utils/net_rpc_rights.c:491 +#: ../../utils/net_rpc_rights.c:492 msgid "Successfully granted rights.\n" msgstr "" -#: ../../utils/net_rpc_rights.c:495 +#: ../../utils/net_rpc_rights.c:496 #, c-format msgid "Failed to grant privileges for %s (%s)\n" msgstr "" -#: ../../utils/net_rpc_rights.c:523 +#: ../../utils/net_rpc_rights.c:524 msgid "Usage: net rpc rights revoke <name|SID> <rights...>\n" msgstr "" -#: ../../utils/net_rpc_rights.c:559 +#: ../../utils/net_rpc_rights.c:560 msgid "Successfully revoked rights.\n" msgstr "" -#: ../../utils/net_rpc_rights.c:563 +#: ../../utils/net_rpc_rights.c:564 #, c-format msgid "Failed to revoke privileges for %s (%s)\n" msgstr "" -#: ../../utils/net_rpc_rights.c:579 +#: ../../utils/net_rpc_rights.c:580 msgid "" "Usage:\n" "net rpc rights list [{accounts|privileges} [name|SID]]\n" " View available/assigned privileges\n" msgstr "" -#: ../../utils/net_rpc_rights.c:596 +#: ../../utils/net_rpc_rights.c:597 msgid "" "Usage:\n" "net rpc rights grant <name|SID> <right>\n" " Assign privilege[s]\n" msgstr "" -#: ../../utils/net_rpc_rights.c:599 +#: ../../utils/net_rpc_rights.c:600 msgid "" "For example:\n" " net rpc rights grant 'VALE\\biddle' SePrintOperatorPrivilege SeDiskOperatorPrivilege\n" " would grant the printer admin and disk manager rights to the user 'VALE\\biddle'\n" msgstr "" -#: ../../utils/net_rpc_rights.c:617 +#: ../../utils/net_rpc_rights.c:618 msgid "" "Usage:\n" "net rpc rights revoke <name|SID> <right>\n" " Revoke privilege[s]\n" msgstr "" -#: ../../utils/net_rpc_rights.c:620 +#: ../../utils/net_rpc_rights.c:621 msgid "" "For example:\n" " net rpc rights revoke 'VALE\\biddle' SePrintOperatorPrivilege SeDiskOperatorPrivilege\n" " would revoke the printer admin and disk manager rights from the user 'VALE\\biddle'\n" msgstr "" -#: ../../utils/net_rpc_rights.c:642 +#: ../../utils/net_rpc_rights.c:643 msgid "View available/assigned privileges" msgstr "" -#: ../../utils/net_rpc_rights.c:643 +#: ../../utils/net_rpc_rights.c:644 msgid "" "net rpc rights list\n" " View available/assigned privileges" msgstr "" -#: ../../utils/net_rpc_rights.c:650 ../../utils/net_rpc_rights.c:709 +#: ../../utils/net_rpc_rights.c:651 ../../utils/net_rpc_rights.c:710 msgid "Assign privilege[s]" msgstr "" -#: ../../utils/net_rpc_rights.c:651 +#: ../../utils/net_rpc_rights.c:652 msgid "" "net rpc rights grant\n" " Assign privilege[s]" msgstr "" -#: ../../utils/net_rpc_rights.c:658 ../../utils/net_rpc_rights.c:712 +#: ../../utils/net_rpc_rights.c:659 ../../utils/net_rpc_rights.c:713 msgid "Revoke privilege[s]" msgstr "" -#: ../../utils/net_rpc_rights.c:659 +#: ../../utils/net_rpc_rights.c:660 msgid "" "net rpc rights revoke\n" " Revoke privilege[s]" msgstr "" -#: ../../utils/net_rpc_rights.c:706 +#: ../../utils/net_rpc_rights.c:707 msgid "View available or assigned privileges" msgstr "" @@ -7295,152 +7387,150 @@ msgid "" " Creates a service" msgstr "" -#: ../../utils/net_rpc_sh_acct.c:78 +#: ../../utils/net_rpc_sh_acct.c:79 #, c-format msgid "query_domain_info level 1 failed: %s\n" msgstr "" -#: ../../utils/net_rpc_sh_acct.c:89 +#: ../../utils/net_rpc_sh_acct.c:90 #, c-format msgid "query_domain_info level 3 failed: %s\n" msgstr "" -#: ../../utils/net_rpc_sh_acct.c:100 +#: ../../utils/net_rpc_sh_acct.c:101 #, c-format msgid "query_domain_info level 12 failed: %s\n" msgstr "" -#: ../../utils/net_rpc_sh_acct.c:133 +#: ../../utils/net_rpc_sh_acct.c:134 #, c-format msgid "Got unexpected info level %d\n" msgstr "" -#: ../../utils/net_rpc_sh_acct.c:157 +#: ../../utils/net_rpc_sh_acct.c:158 #, c-format msgid "usage: %s\n" msgstr "" -#: ../../utils/net_rpc_sh_acct.c:161 +#: ../../utils/net_rpc_sh_acct.c:162 #, c-format msgid "Minimum password length: %d\n" msgstr "" -#: ../../utils/net_rpc_sh_acct.c:162 +#: ../../utils/net_rpc_sh_acct.c:163 #, c-format msgid "Password history length: %d\n" msgstr "" -#: ../../utils/net_rpc_sh_acct.c:165 +#: ../../utils/net_rpc_sh_acct.c:166 msgid "Minimum password age: " msgstr "" -#: ../../utils/net_rpc_sh_acct.c:168 ../../utils/net_rpc_sh_acct.c:176 ../../utils/net_rpc_sh_acct.c:188 ../../utils/net_rpc_sh_acct.c:196 +#: ../../utils/net_rpc_sh_acct.c:169 ../../utils/net_rpc_sh_acct.c:177 ../../utils/net_rpc_sh_acct.c:189 ../../utils/net_rpc_sh_acct.c:197 #, c-format msgid "%d seconds\n" msgstr "" -#: ../../utils/net_rpc_sh_acct.c:170 ../../utils/net_rpc_sh_acct.c:178 ../../utils/net_rpc_sh_acct.c:190 ../../utils/net_rpc_sh_acct.c:198 +#: ../../utils/net_rpc_sh_acct.c:171 ../../utils/net_rpc_sh_acct.c:179 ../../utils/net_rpc_sh_acct.c:191 ../../utils/net_rpc_sh_acct.c:199 msgid "not set\n" msgstr "" -#: ../../utils/net_rpc_sh_acct.c:173 +#: ../../utils/net_rpc_sh_acct.c:174 msgid "Maximum password age: " msgstr "" -#: ../../utils/net_rpc_sh_acct.c:181 +#: ../../utils/net_rpc_sh_acct.c:182 #, c-format msgid "Bad logon attempts: %d\n" msgstr "" -#: ../../utils/net_rpc_sh_acct.c:185 +#: ../../utils/net_rpc_sh_acct.c:186 msgid "Account lockout duration: " msgstr "" -#: ../../utils/net_rpc_sh_acct.c:193 +#: ../../utils/net_rpc_sh_acct.c:194 msgid "Bad password count reset after: " msgstr "" -#: ../../utils/net_rpc_sh_acct.c:202 +#: ../../utils/net_rpc_sh_acct.c:203 #, c-format msgid "Disconnect users when logon hours expire: %s\n" msgstr "" -#: ../../utils/net_rpc_sh_acct.c:205 +#: ../../utils/net_rpc_sh_acct.c:206 #, c-format msgid "User must logon to change password: %s\n" msgstr "Benutzer muss sich anmelden um Passwort zu ändern: %s\n" -#: ../../utils/net_rpc_sh_acct.c:228 ../../utils/net_rpc_sh_acct.c:258 ../../utils/net_rpc_sh_acct.c:288 ../../utils/net_rpc_sh_acct.c:318 ../../utils/net_rpc_sh_acct.c:348 ../../utils/net_rpc_sh_acct.c:378 ../../utils/net_rpc_sh_acct.c:408 +#: ../../utils/net_rpc_sh_acct.c:229 ../../utils/net_rpc_sh_acct.c:259 ../../utils/net_rpc_sh_acct.c:289 ../../utils/net_rpc_sh_acct.c:319 ../../utils/net_rpc_sh_acct.c:349 ../../utils/net_rpc_sh_acct.c:379 ../../utils/net_rpc_sh_acct.c:409 #, c-format msgid "usage: %s <count>\n" msgstr "" -#: ../../utils/net_rpc_sh_acct.c:233 +#: ../../utils/net_rpc_sh_acct.c:234 #, c-format msgid "Setting bad password count to %d\n" msgstr "" -#: ../../utils/net_rpc_sh_acct.c:263 +#: ../../utils/net_rpc_sh_acct.c:264 #, c-format msgid "Setting lockout duration to %d seconds\n" msgstr "" -#: ../../utils/net_rpc_sh_acct.c:293 +#: ../../utils/net_rpc_sh_acct.c:294 #, c-format msgid "Setting bad password reset duration to %d seconds\n" msgstr "" -#: ../../utils/net_rpc_sh_acct.c:323 +#: ../../utils/net_rpc_sh_acct.c:324 #, c-format msgid "Setting minimum password age to %d seconds\n" msgstr "" -#: ../../utils/net_rpc_sh_acct.c:353 +#: ../../utils/net_rpc_sh_acct.c:354 #, c-format msgid "Setting maximum password age to %d seconds\n" msgstr "" -#: ../../utils/net_rpc_sh_acct.c:383 +#: ../../utils/net_rpc_sh_acct.c:384 #, c-format msgid "Setting minimum password length to %d\n" msgstr "" -#: ../../utils/net_rpc_sh_acct.c:413 +#: ../../utils/net_rpc_sh_acct.c:414 #, c-format msgid "Setting password history length to %d\n" msgstr "" -#: ../../utils/net_rpc_sh_acct.c:434 +#: ../../utils/net_rpc_sh_acct.c:435 msgid "Show current account policy settings" msgstr "" -#: ../../utils/net_rpc_sh_acct.c:436 +#: ../../utils/net_rpc_sh_acct.c:437 msgid "Set bad password count before lockout" msgstr "" -#: ../../utils/net_rpc_sh_acct.c:438 +#: ../../utils/net_rpc_sh_acct.c:439 msgid "Set account lockout duration" msgstr "" -#: ../../utils/net_rpc_sh_acct.c:441 +#: ../../utils/net_rpc_sh_acct.c:442 msgid "Set bad password count reset duration" msgstr "" -#: ../../utils/net_rpc_sh_acct.c:443 -#, fuzzy +#: ../../utils/net_rpc_sh_acct.c:444 msgid "Set minimum password age" -msgstr "Bitte Maschinenpasswort eingeben: " +msgstr "" -#: ../../utils/net_rpc_sh_acct.c:445 -#, fuzzy +#: ../../utils/net_rpc_sh_acct.c:446 msgid "Set maximum password age" -msgstr "Bitte Maschinenpasswort eingeben: " +msgstr "" -#: ../../utils/net_rpc_sh_acct.c:447 +#: ../../utils/net_rpc_sh_acct.c:448 msgid "Set minimum password length" msgstr "" -#: ../../utils/net_rpc_sh_acct.c:449 +#: ../../utils/net_rpc_sh_acct.c:450 msgid "Set the password history length" msgstr "" @@ -7454,57 +7544,57 @@ msgid "Could not open pipe: %s\n" msgstr "" #. None found -#: ../../utils/net_rpc_shell.c:144 +#: ../../utils/net_rpc_shell.c:146 #, c-format msgid "%s: unknown cmd\n" msgstr "" -#: ../../utils/net_rpc_shell.c:150 ../../utils/net_rpc_shell.c:231 ../../utils/net_sam.c:1573 ../../utils/net_sam.c:1835 +#: ../../utils/net_rpc_shell.c:152 ../../utils/net_rpc_shell.c:233 ../../utils/net_sam.c:1573 ../../utils/net_sam.c:1835 msgid "talloc failed\n" msgstr "" -#: ../../utils/net_rpc_shell.c:182 +#: ../../utils/net_rpc_shell.c:184 #, c-format msgid "%s failed: %s\n" msgstr "" -#: ../../utils/net_rpc_shell.c:192 +#: ../../utils/net_rpc_shell.c:194 msgid "Print information about the domain connected to" msgstr "" -#: ../../utils/net_rpc_shell.c:195 +#: ../../utils/net_rpc_shell.c:197 msgid "List/Grant/Revoke user rights" msgstr "" -#: ../../utils/net_rpc_shell.c:198 +#: ../../utils/net_rpc_shell.c:200 msgid "List/Add/Remove etc shares" msgstr "" -#: ../../utils/net_rpc_shell.c:201 +#: ../../utils/net_rpc_shell.c:203 msgid "List/Add/Remove user info" msgstr "" -#: ../../utils/net_rpc_shell.c:204 +#: ../../utils/net_rpc_shell.c:206 msgid "Show/Change account policy settings" msgstr "" -#: ../../utils/net_rpc_shell.c:215 +#: ../../utils/net_rpc_shell.c:217 msgid "" "Usage:\n" "net rpc shell\n" msgstr "" -#: ../../utils/net_rpc_shell.c:237 +#: ../../utils/net_rpc_shell.c:239 #, c-format msgid "Could not open connection: %s\n" msgstr "" -#: ../../utils/net_rpc_shell.c:252 +#: ../../utils/net_rpc_shell.c:254 #, c-format msgid "Talking to domain %s (%s)\n" msgstr "" -#: ../../utils/net_rpc_shell.c:279 +#: ../../utils/net_rpc_shell.c:281 #, c-format msgid "cmdline invalid: %s\n" msgstr "Kommandozeile ungültig: %s\n" @@ -8191,7 +8281,7 @@ msgstr "" #: ../../utils/net_sam.c:1663 ../../utils/net_sam.c:1720 ../../utils/net_sam.c:1804 ../../utils/net_sam.c:1893 ../../utils/net_sam.c:1907 ../../utils/net_sam.c:1954 msgid "found!\n" -msgstr "" +msgstr "gefunden!\n" #: ../../utils/net_sam.c:1668 msgid "Checking for Domain Admins group.\n" @@ -8564,6 +8654,18 @@ msgid "" "\n" "\n" msgstr "" +"net time\n" +"\tZeigt die Zeit eines Servers an\n" +"\n" +"net time system\n" +"\tZeigt die Zeit eines Servers im /bin/date Format an\n" +"\n" +"net time set\n" +"\tFührt /bin/date mit der Serverzeit aus\n" +"\n" +"net time zone\n" +"\tZeigt die Zeitzone in Stunden zur GMT auf dem entfernten Computer\n" +"\n" #: ../../utils/net_time.c:123 #, c-format @@ -8703,7 +8805,7 @@ msgstr "" #: ../../utils/net_usershare.c:39 msgid "System error" -msgstr "" +msgstr "System Fehler" #: ../../utils/net_usershare.c:55 #, c-format @@ -9004,77 +9106,77 @@ msgstr "" msgid "Please ask your system administrator to enable user sharing.\n" msgstr "" -#: ../../utils/net_util.c:116 +#: ../../utils/net_util.c:118 #, c-format msgid "Could not connect to server %s\n" msgstr "" -#: ../../utils/net_util.c:124 +#: ../../utils/net_util.c:126 msgid "The username or password was not correct.\n" -msgstr "" +msgstr "Benutzername oder Passwort nicht korrekt.\n" -#: ../../utils/net_util.c:129 +#: ../../utils/net_util.c:131 msgid "The account was locked out.\n" msgstr "" -#: ../../utils/net_util.c:133 +#: ../../utils/net_util.c:135 msgid "The account was disabled.\n" msgstr "" -#: ../../utils/net_util.c:144 +#: ../../utils/net_util.c:146 msgid "Encryption required and server that doesn't support UNIX extensions - failing connect\n" msgstr "" -#: ../../utils/net_util.c:148 +#: ../../utils/net_util.c:150 msgid "Encryption required and can't get UNIX CIFS extensions version from server.\n" msgstr "" -#: ../../utils/net_util.c:152 +#: ../../utils/net_util.c:154 #, c-format msgid "Encryption required and share %s doesn't support encryption.\n" msgstr "" -#: ../../utils/net_util.c:156 +#: ../../utils/net_util.c:158 #, c-format msgid "Encryption required and setup failed with error %s.\n" msgstr "" -#: ../../utils/net_util.c:343 ../../utils/net_util.c:365 +#: ../../utils/net_util.c:345 ../../utils/net_util.c:367 msgid "ERROR: Unable to open secrets database\n" msgstr "" -#: ../../utils/net_util.c:499 +#: ../../utils/net_util.c:501 #, c-format msgid "Unable to find a suitable server for domain %s\n" msgstr "" -#: ../../utils/net_util.c:524 +#: ../../utils/net_util.c:526 #, c-format msgid "Connection failed: %s\n" -msgstr "" +msgstr "Verbindung fehlgeschlagen: %s\n" -#: ../../utils/net_util.c:558 +#: ../../utils/net_util.c:560 #, c-format msgid "Enter %s's password:" msgstr "Bitte Passwort für %s eingeben: " -#: ../../utils/net_util.c:581 +#: ../../utils/net_util.c:583 #, c-format msgid "Invalid command: %s %s\n" msgstr "Ungültiges Kommando: %s %s\n" -#: ../../utils/net_util.c:607 +#: ../../utils/net_util.c:609 msgid "Disk" -msgstr "" +msgstr "Festplatte" -#: ../../utils/net_util.c:608 +#: ../../utils/net_util.c:610 msgid "Print" -msgstr "" +msgstr "Drucker" -#: ../../utils/net_util.c:609 +#: ../../utils/net_util.c:611 msgid "Dev" -msgstr "" +msgstr "Gerät" -#: ../../utils/net_util.c:610 +#: ../../utils/net_util.c:612 msgid "IPC" -msgstr "" +msgstr "IPC" diff --git a/source3/modules/vfs_acl_common.c b/source3/modules/vfs_acl_common.c index 06bcfb856b..1eec448083 100644 --- a/source3/modules/vfs_acl_common.c +++ b/source3/modules/vfs_acl_common.c @@ -157,6 +157,85 @@ static NTSTATUS create_acl_blob(const struct security_descriptor *psd, } /******************************************************************* + Add in 3 inheritable components for a non-inheritable directory ACL. + CREATOR_OWNER/CREATOR_GROUP/WORLD. +*******************************************************************/ + +static void add_directory_inheritable_components(vfs_handle_struct *handle, + const char *name, + SMB_STRUCT_STAT *psbuf, + struct security_descriptor *psd) +{ + struct connection_struct *conn = handle->conn; + int num_aces = (psd->dacl ? psd->dacl->num_aces : 0); + struct smb_filename smb_fname; + enum security_ace_type acl_type; + uint32_t access_mask; + mode_t dir_mode; + mode_t file_mode; + mode_t mode; + struct security_ace *new_ace_list = TALLOC_ZERO_ARRAY(talloc_tos(), + struct security_ace, + num_aces + 3); + + if (new_ace_list == NULL) { + return; + } + + /* Fake a quick smb_filename. */ + ZERO_STRUCT(smb_fname); + smb_fname.st = *psbuf; + smb_fname.base_name = CONST_DISCARD(char *, name); + + dir_mode = unix_mode(conn, + FILE_ATTRIBUTE_DIRECTORY, &smb_fname, NULL); + file_mode = unix_mode(conn, + FILE_ATTRIBUTE_ARCHIVE, &smb_fname, NULL); + + mode = dir_mode | file_mode; + + DEBUG(10, ("add_directory_inheritable_components: directory %s, " + "mode = 0%o\n", + name, + (unsigned int)mode )); + + if (num_aces) { + memcpy(new_ace_list, psd->dacl->aces, + num_aces * sizeof(struct security_ace)); + } + access_mask = map_canon_ace_perms(SNUM(conn), &acl_type, + mode & 0700, false); + + init_sec_ace(&new_ace_list[num_aces], + &global_sid_Creator_Owner, + acl_type, + access_mask, + SEC_ACE_FLAG_CONTAINER_INHERIT| + SEC_ACE_FLAG_OBJECT_INHERIT| + SEC_ACE_FLAG_INHERIT_ONLY); + access_mask = map_canon_ace_perms(SNUM(conn), &acl_type, + (mode << 3) & 0700, false); + init_sec_ace(&new_ace_list[num_aces+1], + &global_sid_Creator_Group, + acl_type, + access_mask, + SEC_ACE_FLAG_CONTAINER_INHERIT| + SEC_ACE_FLAG_OBJECT_INHERIT| + SEC_ACE_FLAG_INHERIT_ONLY); + access_mask = map_canon_ace_perms(SNUM(conn), &acl_type, + (mode << 6) & 0700, false); + init_sec_ace(&new_ace_list[num_aces+2], + &global_sid_World, + acl_type, + access_mask, + SEC_ACE_FLAG_CONTAINER_INHERIT| + SEC_ACE_FLAG_OBJECT_INHERIT| + SEC_ACE_FLAG_INHERIT_ONLY); + psd->dacl->aces = new_ace_list; + psd->dacl->num_aces += 3; +} + +/******************************************************************* Pull a DATA_BLOB from an xattr given a pathname. If the hash doesn't match, or doesn't exist - return the underlying filesystem sd. @@ -261,6 +340,33 @@ static NTSTATUS get_nt_acl_internal(vfs_handle_struct *handle, /* We're returning the blob, throw * away the filesystem SD. */ TALLOC_FREE(pdesc_next); + } else { + SMB_STRUCT_STAT sbuf; + SMB_STRUCT_STAT *psbuf = &sbuf; + bool is_directory = false; + /* + * We're returning the underlying ACL from the + * filesystem. If it's a directory, and has no + * inheritable ACE entries we have to fake them. + */ + if (fsp) { + is_directory = fsp->is_directory; + psbuf = &fsp->fsp_name->st; + } else { + if (vfs_stat_smb_fname(handle->conn, + name, + &sbuf) == 0) { + is_directory = S_ISDIR(sbuf.st_ex_mode); + } + } + if (is_directory && + !sd_has_inheritable_components(psd, + true)) { + add_directory_inheritable_components(handle, + name, + psbuf, + psd); + } } if (!(security_info & OWNER_SECURITY_INFORMATION)) { diff --git a/source3/rpc_client/cli_pipe.c b/source3/rpc_client/cli_pipe.c index 23f002ceeb..2f84828689 100644 --- a/source3/rpc_client/cli_pipe.c +++ b/source3/rpc_client/cli_pipe.c @@ -3034,12 +3034,30 @@ NTSTATUS rpc_pipe_bind(struct rpc_pipe_client *cli, unsigned int rpccli_set_timeout(struct rpc_pipe_client *rpc_cli, unsigned int timeout) { - struct cli_state *cli = rpc_pipe_np_smb_conn(rpc_cli); + struct cli_state *cli; - if (cli == NULL) { - return 0; + if (rpc_cli->transport->transport == NCACN_NP) { + cli = rpc_pipe_np_smb_conn(rpc_cli); + if (cli == NULL) { + return 0; + } + return cli_set_timeout(cli, timeout); + } + + if (rpc_cli->transport->transport == NCACN_IP_TCP || + rpc_cli->transport->transport == NCALRPC) { + return rpccli_set_sock_timeout(rpc_cli, timeout); } - return cli_set_timeout(cli, timeout); + + if (rpc_cli->transport->transport == NCACN_INTERNAL) { + cli = rpc_pipe_smbd_smb_conn(rpc_cli); + if (!cli) { + return 0; + } + return cli_set_timeout(cli, timeout); + } + + return 0; } bool rpccli_get_pwd_hash(struct rpc_pipe_client *rpc_cli, uint8_t nt_hash[16]) diff --git a/source3/rpc_client/ndr.c b/source3/rpc_client/ndr.c index 6433a7d196..4e8634d3b9 100644 --- a/source3/rpc_client/ndr.c +++ b/source3/rpc_client/ndr.c @@ -182,6 +182,21 @@ NTSTATUS cli_do_rpc_ndr(struct rpc_pipe_client *cli, } status = cli_do_rpc_ndr_recv(req, mem_ctx); + + /* + * NT_STATUS_IO_TIMEOUT indicates network problem, + * tear the connection apart. + */ + if (NT_STATUS_EQUAL(status, NT_STATUS_IO_TIMEOUT)) { + if (cli->transport->transport == NCACN_IP_TCP || + cli->transport->transport == NCALRPC) { + rpccli_close_sock_fd(cli); + } + + if (cli->transport->transport == NCACN_NP) { + rpccli_close_np_fd(cli); + } + } fail: TALLOC_FREE(frame); return status; diff --git a/source3/rpc_client/rpc_transport_np.c b/source3/rpc_client/rpc_transport_np.c index c28664d007..fdcdfd3a25 100644 --- a/source3/rpc_client/rpc_transport_np.c +++ b/source3/rpc_client/rpc_transport_np.c @@ -402,3 +402,15 @@ struct cli_state *rpc_pipe_np_smb_conn(struct rpc_pipe_client *p) } return state->cli; } + +void rpccli_close_np_fd(struct rpc_pipe_client *p) +{ + struct cli_state *cli = rpc_pipe_np_smb_conn(p); + if (cli) { + if (cli->fd != -1) { + close(cli->fd); + cli->fd = -1; + } + } + return; +} diff --git a/source3/rpc_client/rpc_transport_smbd.c b/source3/rpc_client/rpc_transport_smbd.c index 171048ae29..929e553c84 100644 --- a/source3/rpc_client/rpc_transport_smbd.c +++ b/source3/rpc_client/rpc_transport_smbd.c @@ -682,3 +682,13 @@ NTSTATUS rpc_transport_smbd_init(TALLOC_CTX *mem_ctx, TALLOC_FREE(frame); return status; } + +struct cli_state *rpc_pipe_smbd_smb_conn(struct rpc_pipe_client *p) +{ + struct rpc_transport_smbd_state *state = talloc_get_type(p->transport->priv, + struct rpc_transport_smbd_state); + if (!state || !state->conn) { + return NULL; + } + return state->conn->cli; +} diff --git a/source3/rpc_client/rpc_transport_sock.c b/source3/rpc_client/rpc_transport_sock.c index 4ab6500900..df060e61e9 100644 --- a/source3/rpc_client/rpc_transport_sock.c +++ b/source3/rpc_client/rpc_transport_sock.c @@ -24,6 +24,7 @@ struct rpc_transport_sock_state { int fd; + int timeout; }; static int rpc_transport_sock_state_destructor(struct rpc_transport_sock_state *s) @@ -51,6 +52,7 @@ static struct tevent_req *rpc_sock_read_send(TALLOC_CTX *mem_ctx, priv, struct rpc_transport_sock_state); struct tevent_req *req, *subreq; struct rpc_sock_read_state *state; + struct timeval endtime; req = tevent_req_create(mem_ctx, &state, struct rpc_sock_read_state); if (req == NULL) { @@ -61,10 +63,16 @@ static struct tevent_req *rpc_sock_read_send(TALLOC_CTX *mem_ctx, return tevent_req_post(req, ev); } state->transp = sock_transp; + endtime = timeval_current_ofs(0, sock_transp->timeout * 1000); subreq = async_recv_send(state, ev, sock_transp->fd, data, size, 0); if (subreq == NULL) { goto fail; } + + if (!tevent_req_set_endtime(subreq, ev, endtime)) { + goto fail; + } + tevent_req_set_callback(subreq, rpc_sock_read_done, req); return req; fail: @@ -121,6 +129,7 @@ static struct tevent_req *rpc_sock_write_send(TALLOC_CTX *mem_ctx, priv, struct rpc_transport_sock_state); struct tevent_req *req, *subreq; struct rpc_sock_write_state *state; + struct timeval endtime; req = tevent_req_create(mem_ctx, &state, struct rpc_sock_write_state); if (req == NULL) { @@ -131,10 +140,16 @@ static struct tevent_req *rpc_sock_write_send(TALLOC_CTX *mem_ctx, return tevent_req_post(req, ev); } state->transp = sock_transp; + endtime = timeval_current_ofs(0, sock_transp->timeout * 1000); subreq = async_send_send(state, ev, sock_transp->fd, data, size, 0); if (subreq == NULL) { goto fail; } + + if (!tevent_req_set_endtime(subreq, ev, endtime)) { + goto fail; + } + tevent_req_set_callback(subreq, rpc_sock_write_done, req); return req; fail: @@ -193,6 +208,7 @@ NTSTATUS rpc_transport_sock_init(TALLOC_CTX *mem_ctx, int fd, result->priv = state; state->fd = fd; + state->timeout = 10000; /* 10 seconds. */ talloc_set_destructor(state, rpc_transport_sock_state_destructor); result->trans_send = NULL; @@ -205,3 +221,40 @@ NTSTATUS rpc_transport_sock_init(TALLOC_CTX *mem_ctx, int fd, *presult = result; return NT_STATUS_OK; } + +int rpccli_set_sock_timeout(struct rpc_pipe_client *cli, int timeout) +{ + struct rpc_transport_sock_state *state = talloc_get_type(cli->transport->priv, + struct rpc_transport_sock_state); + int orig_timeout; + if (!state) { + return 0; + } + orig_timeout = state->timeout; + state->timeout = timeout; + return orig_timeout; +} + +void rpccli_close_sock_fd(struct rpc_pipe_client *cli) +{ + struct rpc_transport_sock_state *state = talloc_get_type(cli->transport->priv, + struct rpc_transport_sock_state); + if (state) { + if (state->fd != -1) { + close(state->fd); + state->fd = -1; + } + } + return; +} + +bool rpc_pipe_tcp_connection_ok(struct rpc_pipe_client *cli) +{ + struct rpc_transport_sock_state *state = talloc_get_type(cli->transport->priv, + struct rpc_transport_sock_state); + if (state && state->fd != -1) { + return true; + } + + return false; +} diff --git a/source3/rpc_server/srv_pipe_hnd.c b/source3/rpc_server/srv_pipe_hnd.c index 5d5eb0eeb1..83f27fee8e 100644 --- a/source3/rpc_server/srv_pipe_hnd.c +++ b/source3/rpc_server/srv_pipe_hnd.c @@ -903,6 +903,13 @@ static ssize_t read_from_internal_pipe(struct pipes_struct *p, char *data, size_ out: (*is_data_outstanding) = prs_offset(&p->out_data.frag) > n; + if (p->out_data.current_pdu_sent == prs_offset(&p->out_data.frag)) { + /* We've returned everything in the out_data.frag + * so we're done with this pdu. Free it and reset + * current_pdu_sent. */ + p->out_data.current_pdu_sent = 0; + prs_mem_free(&p->out_data.frag); + } return data_returned; } diff --git a/source3/rpc_server/srv_samr_nt.c b/source3/rpc_server/srv_samr_nt.c index f3a48a8d8f..d50c6c3e0e 100644 --- a/source3/rpc_server/srv_samr_nt.c +++ b/source3/rpc_server/srv_samr_nt.c @@ -5360,6 +5360,14 @@ NTSTATUS _samr_GetAliasMembership(pipes_struct *p, r->out.rids->count = num_alias_rids; r->out.rids->ids = alias_rids; + if (r->out.rids->ids == NULL) { + /* Windows domain clients don't accept a NULL ptr here */ + r->out.rids->ids = talloc_zero(p->mem_ctx, uint32_t); + } + if (r->out.rids->ids == NULL) { + return NT_STATUS_NO_MEMORY; + } + return NT_STATUS_OK; } diff --git a/source3/rpcclient/cmd_spoolss.c b/source3/rpcclient/cmd_spoolss.c index 6101fc651d..deecbc5164 100644 --- a/source3/rpcclient/cmd_spoolss.c +++ b/source3/rpcclient/cmd_spoolss.c @@ -1676,8 +1676,8 @@ static WERROR cmd_spoolss_addprinterex(struct rpc_pipe_client *cli, info2.comment = "Created by rpcclient"; info2.printprocessor = "winprint"; info2.datatype = "RAW"; - info2.devmode = NULL; - info2.secdesc = NULL; + info2.devmode_ptr = 0; + info2.secdesc_ptr = 0; info2.attributes = PRINTER_ATTRIBUTE_SHARED; info2.priority = 0; info2.defaultpriority = 0; diff --git a/source3/smbd/dosmode.c b/source3/smbd/dosmode.c index 0f31973675..aaef09bc85 100644 --- a/source3/smbd/dosmode.c +++ b/source3/smbd/dosmode.c @@ -21,6 +21,18 @@ #include "includes.h" #include "librpc/gen_ndr/ndr_xattr.h" +static uint32_t filter_mode_by_protocol(uint32_t mode) +{ + if (get_Protocol() <= PROTOCOL_LANMAN2) { + DEBUG(10,("filter_mode_by_protocol: " + "filtering result 0x%x to 0x%x\n", + (unsigned int)mode, + (unsigned int)(mode & 0x3f) )); + mode &= 0x3f; + } + return mode; +} + static int set_sparse_flag(const SMB_STRUCT_STAT * const sbuf) { #if defined (HAVE_STAT_ST_BLOCKS) && defined(STAT_ST_BLOCKSIZE) @@ -459,12 +471,12 @@ uint32 dos_mode_msdfs(connection_struct *conn, result |= aHIDDEN; } - if (get_Protocol() <= PROTOCOL_LANMAN2) { - DEBUG(10,("dos_mode_msdfs : filtering result 0x%x\n", - (unsigned int)result )); - result &= 0xff; + if (result == 0) { + result = FILE_ATTRIBUTE_NORMAL; } + result = filter_mode_by_protocol(result); + DEBUG(8,("dos_mode_msdfs returning ")); if (result & aHIDDEN) DEBUG(8, ("h")); @@ -645,12 +657,12 @@ uint32 dos_mode(connection_struct *conn, struct smb_filename *smb_fname) result |= aHIDDEN; } - if (get_Protocol() <= PROTOCOL_LANMAN2) { - DEBUG(10,("dos_mode : filtering result 0x%x\n", - (unsigned int)result )); - result &= 0xff; + if (result == 0) { + result = FILE_ATTRIBUTE_NORMAL; } + result = filter_mode_by_protocol(result); + DEBUG(8,("dos_mode returning ")); if (result & aHIDDEN) DEBUG(8, ("h")); diff --git a/source3/smbd/error.c b/source3/smbd/error.c index 874efa2a0b..252eb77416 100644 --- a/source3/smbd/error.c +++ b/source3/smbd/error.c @@ -30,9 +30,29 @@ bool use_nt_status(void) /**************************************************************************** Create an error packet. Normally called using the ERROR() macro. - Setting eclass and ecode only and status to NT_STATUS_OK forces DOS errors. - Setting status only and eclass and ecode to zero forces NT errors. - If the override errors are set they take precedence over any passed in values. + + Setting eclass and ecode to zero and status to a valid NT error will + reply with an NT error if the client supports CAP_STATUS32, otherwise + it maps to and returns a DOS error if the client doesn't support CAP_STATUS32. + This is the normal mode of calling this function via reply_nterror(req, status). + + Setting eclass and ecode to non-zero and status to NT_STATUS_OK (0) will map + from a DOS error to an NT error and reply with an NT error if the client + supports CAP_STATUS32, otherwise it replies with the given DOS error. + This mode is currently not used in the server. + + Setting both eclass, ecode and status to non-zero values allows a non-default + mapping from NT error codes to DOS error codes, and will return one or the + other depending on the client supporting CAP_STATUS32 or not. This is the + path taken by calling reply_botherror(req, eclass, ecode, status); + + Setting status to NT_STATUS_DOS(eclass, ecode) forces DOS errors even if the + client supports CAP_STATUS32. This is the path taken to force a DOS error + reply by calling reply_force_doserror(req, eclass, ecode). + + Setting status only and eclass to -1 forces NT errors even if the client + doesn't support CAP_STATUS32. This mode is currently never used in the + server. ****************************************************************************/ void error_packet_set(char *outbuf, uint8 eclass, uint32 ecode, NTSTATUS ntstatus, int line, const char *file) @@ -95,21 +115,20 @@ void reply_nt_error(struct smb_request *req, NTSTATUS ntstatus, error_packet_set((char *)req->outbuf, 0, 0, ntstatus, line, file); } -void reply_force_nt_error(struct smb_request *req, NTSTATUS ntstatus, - int line, const char *file) -{ - TALLOC_FREE(req->outbuf); - reply_outbuf(req, 0, 0); - error_packet_set((char *)req->outbuf, -1, -1, ntstatus, line, file); -} +/**************************************************************************** + Forces a DOS error on the wire. +****************************************************************************/ -void reply_dos_error(struct smb_request *req, uint8 eclass, uint32 ecode, +void reply_force_dos_error(struct smb_request *req, uint8 eclass, uint32 ecode, int line, const char *file) { TALLOC_FREE(req->outbuf); reply_outbuf(req, 0, 0); - error_packet_set((char *)req->outbuf, eclass, ecode, NT_STATUS_OK, line, - file); + error_packet_set((char *)req->outbuf, + eclass, ecode, + NT_STATUS_DOS(eclass, ecode), + line, + file); } void reply_both_error(struct smb_request *req, uint8 eclass, uint32 ecode, @@ -132,6 +151,11 @@ void reply_openerror(struct smb_request *req, NTSTATUS status) */ reply_botherror(req, NT_STATUS_OBJECT_NAME_COLLISION, ERRDOS, ERRfilexists); + } else if (NT_STATUS_EQUAL(status, NT_STATUS_TOO_MANY_OPENED_FILES)) { + /* EMFILE always seems to be returned as a DOS error. + * See bug 6837. NOTE this forces a DOS error on the wire + * even though it's calling reply_nterror(). */ + reply_force_doserror(req, ERRDOS, ERRnofids); } else { reply_nterror(req, status); } diff --git a/source3/smbd/mangle_hash.c b/source3/smbd/mangle_hash.c index 94bb184b0f..8369af418a 100644 --- a/source3/smbd/mangle_hash.c +++ b/source3/smbd/mangle_hash.c @@ -429,6 +429,13 @@ static void cache_mangled_name( const char mangled_name[13], if( !s1[i] && !s2[i] ) { /* Truncate at the '.' */ *s1 = '\0'; + /* + * DANGER WILL ROBINSON - this + * is changing a const string via + * an aliased pointer ! Remember to + * put it back once we've used it. + * JRA + */ *s2 = '\0'; } } @@ -440,6 +447,8 @@ static void cache_mangled_name( const char mangled_name[13], } else { DEBUG(5,("cache_mangled_name: Stored entry %s -> %s\n", mangled_name_key, raw_name)); } + /* Restore the change we made to the const string. */ + *s2 = '.'; } /* ************************************************************************** ** @@ -612,7 +621,10 @@ static bool must_mangle(const char *name, } status = is_valid_name(name_ucs2, False, False); TALLOC_FREE(name_ucs2); - return NT_STATUS_IS_OK(status); + /* We return true if we *must* mangle, so if it's + * a valid name (status == OK) then we must return + * false. Bug #6939. */ + return !NT_STATUS_IS_OK(status); } /***************************************************************************** diff --git a/source3/smbd/message.c b/source3/smbd/message.c index e6d5f451cd..82b3dc30a2 100644 --- a/source3/smbd/message.c +++ b/source3/smbd/message.c @@ -145,7 +145,7 @@ void reply_sends(struct smb_request *req) START_PROFILE(SMBsends); if (!(*lp_msg_command())) { - reply_doserror(req, ERRSRV, ERRmsgoff); + reply_nterror(req, NT_STATUS_REQUEST_NOT_ACCEPTED); END_PROFILE(SMBsends); return; } @@ -193,7 +193,7 @@ void reply_sendstrt(struct smb_request *req) START_PROFILE(SMBsendstrt); if (!(*lp_msg_command())) { - reply_doserror(req, ERRSRV, ERRmsgoff); + reply_nterror(req, NT_STATUS_REQUEST_NOT_ACCEPTED); END_PROFILE(SMBsendstrt); return; } @@ -240,7 +240,7 @@ void reply_sendtxt(struct smb_request *req) START_PROFILE(SMBsendtxt); if (! (*lp_msg_command())) { - reply_doserror(req, ERRSRV, ERRmsgoff); + reply_nterror(req, NT_STATUS_REQUEST_NOT_ACCEPTED); END_PROFILE(SMBsendtxt); return; } @@ -288,7 +288,7 @@ void reply_sendend(struct smb_request *req) START_PROFILE(SMBsendend); if (! (*lp_msg_command())) { - reply_doserror(req, ERRSRV, ERRmsgoff); + reply_nterror(req, NT_STATUS_REQUEST_NOT_ACCEPTED); END_PROFILE(SMBsendend); return; } diff --git a/source3/smbd/nttrans.c b/source3/smbd/nttrans.c index 16f8bb592a..656375499f 100644 --- a/source3/smbd/nttrans.c +++ b/source3/smbd/nttrans.c @@ -512,7 +512,7 @@ void reply_ntcreate_and_X(struct smb_request *req) do_ntcreate_pipe_open(conn, req); goto out; } - reply_doserror(req, ERRDOS, ERRnoaccess); + reply_nterror(req, NT_STATUS_ACCESS_DENIED); goto out; } @@ -580,12 +580,7 @@ void reply_ntcreate_and_X(struct smb_request *req) /* We have re-scheduled this call, no error. */ goto out; } - if (NT_STATUS_EQUAL(status, NT_STATUS_OBJECT_NAME_COLLISION)) { - reply_botherror(req, status, ERRDOS, ERRfilexists); - } - else { - reply_nterror(req, status); - } + reply_openerror(req, status); goto out; } @@ -757,7 +752,7 @@ static void do_nt_transact_create_pipe(connection_struct *conn, if(parameter_count < 54) { DEBUG(0,("do_nt_transact_create_pipe - insufficient parameters (%u)\n", (unsigned int)parameter_count)); - reply_doserror(req, ERRDOS, ERRnoaccess); + reply_nterror(req, NT_STATUS_INVALID_PARAMETER); return; } @@ -787,7 +782,7 @@ static void do_nt_transact_create_pipe(connection_struct *conn, } params = nttrans_realloc(ppparams, param_len); if(params == NULL) { - reply_doserror(req, ERRDOS, ERRnomem); + reply_nterror(req, NT_STATUS_NO_MEMORY); return; } @@ -962,7 +957,7 @@ static void call_nt_transact_create(connection_struct *conn, ppdata, data_count); goto out; } - reply_doserror(req, ERRDOS, ERRnoaccess); + reply_nterror(req, NT_STATUS_ACCESS_DENIED); goto out; } @@ -1164,7 +1159,7 @@ static void call_nt_transact_create(connection_struct *conn, } params = nttrans_realloc(ppparams, param_len); if(params == NULL) { - reply_doserror(req, ERRDOS, ERRnomem); + reply_nterror(req, NT_STATUS_NO_MEMORY); goto out; } @@ -1600,7 +1595,7 @@ static void call_nt_transact_notify_change(connection_struct *conn, bool recursive; if(setup_count < 6) { - reply_doserror(req, ERRDOS, ERRbadfunc); + reply_nterror(req, NT_STATUS_INVALID_PARAMETER); return; } @@ -1611,7 +1606,7 @@ static void call_nt_transact_notify_change(connection_struct *conn, DEBUG(3,("call_nt_transact_notify_change\n")); if(!fsp) { - reply_doserror(req, ERRDOS, ERRbadfid); + reply_nterror(req, NT_STATUS_INVALID_HANDLE); return; } @@ -1705,7 +1700,7 @@ static void call_nt_transact_rename(connection_struct *conn, TALLOC_CTX *ctx = talloc_tos(); if(parameter_count < 5) { - reply_doserror(req, ERRDOS, ERRbadfunc); + reply_nterror(req, NT_STATUS_INVALID_PARAMETER); return; } @@ -1774,13 +1769,13 @@ static void call_nt_transact_query_security_desc(connection_struct *conn, DATA_BLOB blob; if(parameter_count < 8) { - reply_doserror(req, ERRDOS, ERRbadfunc); + reply_nterror(req, NT_STATUS_INVALID_PARAMETER); return; } fsp = file_fsp(req, SVAL(params,0)); if(!fsp) { - reply_doserror(req, ERRDOS, ERRbadfid); + reply_nterror(req, NT_STATUS_INVALID_HANDLE); return; } @@ -1792,7 +1787,7 @@ static void call_nt_transact_query_security_desc(connection_struct *conn, params = nttrans_realloc(ppparams, 4); if(params == NULL) { - reply_doserror(req, ERRDOS, ERRnomem); + reply_nterror(req, NT_STATUS_NO_MEMORY); return; } @@ -1844,7 +1839,7 @@ static void call_nt_transact_query_security_desc(connection_struct *conn, data = nttrans_realloc(ppdata, sd_size); if(data == NULL) { - reply_doserror(req, ERRDOS, ERRnomem); + reply_nterror(req, NT_STATUS_NO_MEMORY); return; } @@ -1885,12 +1880,12 @@ static void call_nt_transact_set_security_desc(connection_struct *conn, NTSTATUS status; if(parameter_count < 8) { - reply_doserror(req, ERRDOS, ERRbadfunc); + reply_nterror(req, NT_STATUS_INVALID_PARAMETER); return; } if((fsp = file_fsp(req, SVAL(params,0))) == NULL) { - reply_doserror(req, ERRDOS, ERRbadfid); + reply_nterror(req, NT_STATUS_INVALID_HANDLE); return; } @@ -1904,7 +1899,7 @@ static void call_nt_transact_set_security_desc(connection_struct *conn, fsp_str_dbg(fsp), (unsigned int)security_info_sent)); if (data_count == 0) { - reply_doserror(req, ERRDOS, ERRnoaccess); + reply_nterror(req, NT_STATUS_INVALID_PARAMETER); return; } @@ -2248,7 +2243,7 @@ static void call_nt_transact_get_user_quota(connection_struct *conn, DEBUG(1,("get_user_quota: access_denied service [%s] user " "[%s]\n", lp_servicename(SNUM(conn)), conn->server_info->unix_name)); - reply_doserror(req, ERRDOS, ERRnoaccess); + reply_nterror(req, NT_STATUS_ACCESS_DENIED); return; } @@ -2258,7 +2253,7 @@ static void call_nt_transact_get_user_quota(connection_struct *conn, if (parameter_count < 4) { DEBUG(0,("TRANSACT_GET_USER_QUOTA: requires %d >= 4 bytes parameters\n",parameter_count)); - reply_doserror(req, ERRDOS, ERRinvalidparam); + reply_nterror(req, NT_STATUS_INVALID_PARAMETER); return; } @@ -2293,7 +2288,7 @@ static void call_nt_transact_get_user_quota(connection_struct *conn, param_len = 4; params = nttrans_realloc(ppparams, param_len); if(params == NULL) { - reply_doserror(req, ERRDOS, ERRnomem); + reply_nterror(req, NT_STATUS_NO_MEMORY); return; } @@ -2313,7 +2308,7 @@ static void call_nt_transact_get_user_quota(connection_struct *conn, } if (start_enum && vfs_get_user_ntquota_list(fsp,&(qt_handle->quota_list))!=0) { - reply_doserror(req, ERRSRV, ERRerror); + reply_nterror(req, NT_STATUS_INTERNAL_ERROR); return; } @@ -2321,7 +2316,7 @@ static void call_nt_transact_get_user_quota(connection_struct *conn, param_len = 4; params = nttrans_realloc(ppparams, param_len); if(params == NULL) { - reply_doserror(req, ERRDOS, ERRnomem); + reply_nterror(req, NT_STATUS_NO_MEMORY); return; } @@ -2330,7 +2325,7 @@ static void call_nt_transact_get_user_quota(connection_struct *conn, pdata = nttrans_realloc(ppdata, max_data_count);/* should be max data count from client*/ if(pdata == NULL) { - reply_doserror(req, ERRDOS, ERRnomem); + reply_nterror(req, NT_STATUS_NO_MEMORY); return; } @@ -2393,20 +2388,20 @@ static void call_nt_transact_get_user_quota(connection_struct *conn, if (data_count < 8) { DEBUG(0,("TRANSACT_GET_USER_QUOTA_FOR_SID: requires %d >= %d bytes data\n",data_count,8)); - reply_doserror(req, ERRDOS, ERRunknownlevel); + reply_nterror(req, NT_STATUS_INVALID_LEVEL); return; } sid_len = IVAL(pdata,4); /* Ensure this is less than 1mb. */ if (sid_len > (1024*1024)) { - reply_doserror(req, ERRDOS, ERRnomem); + reply_nterror(req, NT_STATUS_NO_MEMORY); return; } if (data_count < 8+sid_len) { DEBUG(0,("TRANSACT_GET_USER_QUOTA_FOR_SID: requires %d >= %lu bytes data\n",data_count,(unsigned long)(8+sid_len))); - reply_doserror(req, ERRDOS, ERRunknownlevel); + reply_nterror(req, NT_STATUS_INVALID_LEVEL); return; } @@ -2437,13 +2432,13 @@ static void call_nt_transact_get_user_quota(connection_struct *conn, param_len = 4; params = nttrans_realloc(ppparams, param_len); if(params == NULL) { - reply_doserror(req, ERRDOS, ERRnomem); + reply_nterror(req, NT_STATUS_NO_MEMORY); return; } pdata = nttrans_realloc(ppdata, data_len); if(pdata == NULL) { - reply_doserror(req, ERRDOS, ERRnomem); + reply_nterror(req, NT_STATUS_NO_MEMORY); return; } @@ -2477,7 +2472,7 @@ static void call_nt_transact_get_user_quota(connection_struct *conn, default: DEBUG(0,("do_nt_transact_get_user_quota: fnum %d unknown level 0x%04hX\n",fsp->fnum,level)); - reply_doserror(req, ERRSRV, ERRerror); + reply_nterror(req, NT_STATUS_INVALID_LEVEL); return; break; } @@ -2515,7 +2510,7 @@ static void call_nt_transact_set_user_quota(connection_struct *conn, DEBUG(1,("set_user_quota: access_denied service [%s] user " "[%s]\n", lp_servicename(SNUM(conn)), conn->server_info->unix_name)); - reply_doserror(req, ERRDOS, ERRnoaccess); + reply_nterror(req, NT_STATUS_ACCESS_DENIED); return; } @@ -2525,7 +2520,7 @@ static void call_nt_transact_set_user_quota(connection_struct *conn, if (parameter_count < 2) { DEBUG(0,("TRANSACT_SET_USER_QUOTA: requires %d >= 2 bytes parameters\n",parameter_count)); - reply_doserror(req, ERRDOS, ERRinvalidparam); + reply_nterror(req, NT_STATUS_INVALID_PARAMETER); return; } @@ -2539,7 +2534,7 @@ static void call_nt_transact_set_user_quota(connection_struct *conn, if (data_count < 40) { DEBUG(0,("TRANSACT_SET_USER_QUOTA: requires %d >= %d bytes data\n",data_count,40)); - reply_doserror(req, ERRDOS, ERRunknownlevel); + reply_nterror(req, NT_STATUS_INVALID_LEVEL); return; } @@ -2553,7 +2548,7 @@ static void call_nt_transact_set_user_quota(connection_struct *conn, if (data_count < 40+sid_len) { DEBUG(0,("TRANSACT_SET_USER_QUOTA: requires %d >= %lu bytes data\n",data_count,(unsigned long)40+sid_len)); - reply_doserror(req, ERRDOS, ERRunknownlevel); + reply_nterror(req, NT_STATUS_INVALID_LEVEL); return; } @@ -2570,7 +2565,7 @@ static void call_nt_transact_set_user_quota(connection_struct *conn, ((qt.usedspace != 0xFFFFFFFF)|| (IVAL(pdata,20)!=0xFFFFFFFF))) { /* more than 32 bits? */ - reply_doserror(req, ERRDOS, ERRunknownlevel); + reply_nterror(req, NT_STATUS_INVALID_LEVEL); return; } #endif /* LARGE_SMB_OFF_T */ @@ -2584,7 +2579,7 @@ static void call_nt_transact_set_user_quota(connection_struct *conn, ((qt.softlim != 0xFFFFFFFF)|| (IVAL(pdata,28)!=0xFFFFFFFF))) { /* more than 32 bits? */ - reply_doserror(req, ERRDOS, ERRunknownlevel); + reply_nterror(req, NT_STATUS_INVALID_LEVEL); return; } #endif /* LARGE_SMB_OFF_T */ @@ -2598,7 +2593,7 @@ static void call_nt_transact_set_user_quota(connection_struct *conn, ((qt.hardlim != 0xFFFFFFFF)|| (IVAL(pdata,36)!=0xFFFFFFFF))) { /* more than 32 bits? */ - reply_doserror(req, ERRDOS, ERRunknownlevel); + reply_nterror(req, NT_STATUS_INVALID_LEVEL); return; } #endif /* LARGE_SMB_OFF_T */ @@ -2609,7 +2604,7 @@ static void call_nt_transact_set_user_quota(connection_struct *conn, /* 44 unknown bytes left... */ if (vfs_set_ntquota(fsp, SMB_USER_QUOTA_TYPE, &sid, &qt)!=0) { - reply_doserror(req, ERRSRV, ERRerror); + reply_nterror(req, NT_STATUS_INTERNAL_ERROR); return; } @@ -2743,7 +2738,7 @@ static void handle_nttrans(connection_struct *conn, /* Error in request */ DEBUG(0,("handle_nttrans: Unknown request %d in " "nttrans call\n", state->call)); - reply_doserror(req, ERRSRV, ERRerror); + reply_nterror(req, NT_STATUS_INVALID_LEVEL); return; } return; @@ -2779,7 +2774,7 @@ void reply_nttrans(struct smb_request *req) function_code = SVAL(req->vwv+18, 0); if (IS_IPC(conn) && (function_code != NT_TRANSACT_CREATE)) { - reply_doserror(req, ERRSRV, ERRaccess); + reply_nterror(req, NT_STATUS_ACCESS_DENIED); END_PROFILE(SMBnttrans); return; } @@ -2793,7 +2788,7 @@ void reply_nttrans(struct smb_request *req) } if ((state = TALLOC_P(conn, struct trans_state)) == NULL) { - reply_doserror(req, ERRSRV, ERRaccess); + reply_nterror(req, NT_STATUS_NO_MEMORY); END_PROFILE(SMBnttrans); return; } @@ -2839,7 +2834,7 @@ void reply_nttrans(struct smb_request *req) /* Don't allow more than 128mb for each value. */ if ((state->total_data > (1024*1024*128)) || (state->total_param > (1024*1024*128))) { - reply_doserror(req, ERRDOS, ERRnomem); + reply_nterror(req, NT_STATUS_NO_MEMORY); END_PROFILE(SMBnttrans); return; } @@ -2860,7 +2855,7 @@ void reply_nttrans(struct smb_request *req) DEBUG(0,("reply_nttrans: data malloc fail for %u " "bytes !\n", (unsigned int)state->total_data)); TALLOC_FREE(state); - reply_doserror(req, ERRDOS, ERRnomem); + reply_nterror(req, NT_STATUS_NO_MEMORY); END_PROFILE(SMBnttrans); return; } @@ -2882,7 +2877,7 @@ void reply_nttrans(struct smb_request *req) "bytes !\n", (unsigned int)state->total_param)); SAFE_FREE(state->data); TALLOC_FREE(state); - reply_doserror(req, ERRDOS, ERRnomem); + reply_nterror(req, NT_STATUS_NO_MEMORY); END_PROFILE(SMBnttrans); return; } @@ -2915,7 +2910,7 @@ void reply_nttrans(struct smb_request *req) SAFE_FREE(state->data); SAFE_FREE(state->param); TALLOC_FREE(state); - reply_doserror(req, ERRDOS, ERRnomem); + reply_nterror(req, NT_STATUS_NO_MEMORY); END_PROFILE(SMBnttrans); return; } diff --git a/source3/smbd/open.c b/source3/smbd/open.c index 9dc8320b68..120de0f21a 100644 --- a/source3/smbd/open.c +++ b/source3/smbd/open.c @@ -102,8 +102,6 @@ NTSTATUS smbd_check_open_rights(struct connection_struct *conn, access_mask, access_granted); - TALLOC_FREE(sd); - DEBUG(10,("smbd_check_open_rights: file %s requesting " "0x%x returning 0x%x (%s)\n", smb_fname_str_dbg(smb_fname), @@ -111,6 +109,16 @@ NTSTATUS smbd_check_open_rights(struct connection_struct *conn, (unsigned int)*access_granted, nt_errstr(status) )); + if (!NT_STATUS_IS_OK(status)) { + if (DEBUGLEVEL >= 10) { + DEBUG(10,("smbd_check_open_rights: acl for %s is:\n", + smb_fname_str_dbg(smb_fname) )); + NDR_PRINT_DEBUG(security_descriptor, sd); + } + } + + TALLOC_FREE(sd); + return status; } diff --git a/source3/smbd/pipes.c b/source3/smbd/pipes.c index 091db09987..9bc3fdfdf6 100644 --- a/source3/smbd/pipes.c +++ b/source3/smbd/pipes.c @@ -105,7 +105,7 @@ void reply_open_pipe_and_X(connection_struct *conn, struct smb_request *req) /* at a mailslot or something we really, really don't understand, */ /* not just something we really don't understand. */ if ( strncmp(pipe_name,PIPE,PIPELEN) != 0 ) { - reply_doserror(req, ERRSRV, ERRaccess); + reply_nterror(req, NT_STATUS_ACCESS_DENIED); return; } @@ -119,7 +119,7 @@ void reply_open_pipe_and_X(connection_struct *conn, struct smb_request *req) * Hack for NT printers... JRA. */ if(should_fail_next_srvsvc_open(fname)) { - reply_doserror(req, ERRSRV, ERRaccess); + reply_nterror(req, NT_STATUS_ACCESS_DENIED); return; } #endif @@ -171,7 +171,7 @@ void reply_pipe_write(struct smb_request *req) struct tevent_req *subreq; if (!fsp_is_np(fsp)) { - reply_doserror(req, ERRDOS, ERRbadfid); + reply_nterror(req, NT_STATUS_INVALID_HANDLE); return; } @@ -223,7 +223,7 @@ static void pipe_write_done(struct tevent_req *subreq) /* Looks bogus to me now. Needs to be removed ? JRA. */ if ((nwritten == 0 && state->numtowrite != 0)) { - reply_doserror(req, ERRDOS, ERRnoaccess); + reply_nterror(req, NT_STATUS_ACCESS_DENIED); goto send; } @@ -266,7 +266,7 @@ void reply_pipe_write_and_X(struct smb_request *req) struct tevent_req *subreq; if (!fsp_is_np(fsp)) { - reply_doserror(req, ERRDOS, ERRbadfid); + reply_nterror(req, NT_STATUS_INVALID_HANDLE); return; } @@ -340,7 +340,7 @@ static void pipe_write_andx_done(struct tevent_req *subreq) /* Looks bogus to me now. Is this error message correct ? JRA. */ if (nwritten != state->numtowrite) { - reply_doserror(req, ERRDOS,ERRnoaccess); + reply_nterror(req, NT_STATUS_ACCESS_DENIED); goto done; } @@ -353,6 +353,11 @@ static void pipe_write_andx_done(struct tevent_req *subreq) done: chain_reply(req); + /* + * We must free here as the ownership of req was + * moved to the connection struct in reply_pipe_write_and_X(). + */ + TALLOC_FREE(req); } /**************************************************************************** @@ -384,7 +389,7 @@ void reply_pipe_read_and_X(struct smb_request *req) #endif if (!fsp_is_np(fsp)) { - reply_doserror(req, ERRDOS, ERRbadfid); + reply_nterror(req, NT_STATUS_INVALID_HANDLE); return; } @@ -458,4 +463,9 @@ static void pipe_read_andx_done(struct tevent_req *subreq) done: chain_reply(req); + /* + * We must free here as the ownership of req was + * moved to the connection struct in reply_pipe_read_and_X(). + */ + TALLOC_FREE(req); } diff --git a/source3/smbd/posix_acls.c b/source3/smbd/posix_acls.c index 65d0929024..828053811b 100644 --- a/source3/smbd/posix_acls.c +++ b/source3/smbd/posix_acls.c @@ -1068,7 +1068,7 @@ bool nt4_compatible_acls(void) not get. Deny entries are implicit on get with ace->perms = 0. ****************************************************************************/ -static uint32_t map_canon_ace_perms(int snum, +uint32_t map_canon_ace_perms(int snum, enum security_ace_type *pacl_type, mode_t perms, bool directory_ace) @@ -1570,7 +1570,7 @@ static bool dup_owning_ace(canon_ace *dir_ace, canon_ace *ace) ****************************************************************************/ static bool create_canon_ace_lists(files_struct *fsp, - SMB_STRUCT_STAT *pst, + const SMB_STRUCT_STAT *pst, DOM_SID *pfile_owner_sid, DOM_SID *pfile_grp_sid, canon_ace **ppfile_ace, @@ -2305,7 +2305,7 @@ static mode_t create_default_mode(files_struct *fsp, bool interitable_mode) ****************************************************************************/ static bool unpack_canon_ace(files_struct *fsp, - SMB_STRUCT_STAT *pst, + const SMB_STRUCT_STAT *pst, DOM_SID *pfile_owner_sid, DOM_SID *pfile_grp_sid, canon_ace **ppfile_ace, @@ -2313,6 +2313,7 @@ static bool unpack_canon_ace(files_struct *fsp, uint32 security_info_sent, const SEC_DESC *psd) { + SMB_STRUCT_STAT st; canon_ace *file_ace = NULL; canon_ace *dir_ace = NULL; @@ -2376,14 +2377,17 @@ static bool unpack_canon_ace(files_struct *fsp, print_canon_ace_list( "file ace - before valid", file_ace); + st = *pst; + /* * A default 3 element mode entry for a file should be r-- --- ---. * A default 3 element mode entry for a directory should be rwx --- ---. */ - pst->st_ex_mode = create_default_mode(fsp, False); + st.st_ex_mode = create_default_mode(fsp, False); - if (!ensure_canon_entry_valid(&file_ace, fsp->conn->params, fsp->is_directory, pfile_owner_sid, pfile_grp_sid, pst, True)) { + if (!ensure_canon_entry_valid(&file_ace, fsp->conn->params, + fsp->is_directory, pfile_owner_sid, pfile_grp_sid, &st, True)) { free_canon_ace_list(file_ace); free_canon_ace_list(dir_ace); return False; @@ -2397,9 +2401,10 @@ static bool unpack_canon_ace(files_struct *fsp, * it's a directory. */ - pst->st_ex_mode = create_default_mode(fsp, True); + st.st_ex_mode = create_default_mode(fsp, True); - if (dir_ace && !ensure_canon_entry_valid(&dir_ace, fsp->conn->params, fsp->is_directory, pfile_owner_sid, pfile_grp_sid, pst, True)) { + if (dir_ace && !ensure_canon_entry_valid(&dir_ace, fsp->conn->params, + fsp->is_directory, pfile_owner_sid, pfile_grp_sid, &st, True)) { free_canon_ace_list(file_ace); free_canon_ace_list(dir_ace); return False; @@ -4086,6 +4091,9 @@ NTSTATUS set_nt_acl(files_struct *fsp, uint32 security_info_sent, const SEC_DESC free_canon_ace_list(file_ace_list); free_canon_ace_list(dir_ace_list); + /* Ensure the stat struct in the fsp is correct. */ + status = vfs_stat_fsp(fsp); + return NT_STATUS_OK; } diff --git a/source3/smbd/process.c b/source3/smbd/process.c index 15d89a5450..572f37dbbe 100644 --- a/source3/smbd/process.c +++ b/source3/smbd/process.c @@ -1335,7 +1335,7 @@ static connection_struct *switch_message(uint8 type, struct smb_request *req, in if (type == SMBntcreateX) { reply_nterror(req, NT_STATUS_INVALID_HANDLE); } else { - reply_doserror(req, ERRSRV, ERRinvnid); + reply_nterror(req, NT_STATUS_NETWORK_NAME_DELETED); } return NULL; } @@ -1343,7 +1343,7 @@ static connection_struct *switch_message(uint8 type, struct smb_request *req, in if (!change_to_user(conn,session_tag)) { DEBUG(0, ("Error: Could not change to user. Removing " "deferred open, mid=%d.\n", req->mid)); - reply_nterror(req, NT_STATUS_DOS(ERRSRV, ERRbaduid)); + reply_force_doserror(req, ERRSRV, ERRbaduid); return conn; } @@ -1357,7 +1357,7 @@ static connection_struct *switch_message(uint8 type, struct smb_request *req, in /* IPC services are limited */ if (IS_IPC(conn) && !(flags & CAN_IPC)) { - reply_doserror(req, ERRSRV,ERRaccess); + reply_nterror(req, NT_STATUS_ACCESS_DENIED); return conn; } } else { @@ -1382,7 +1382,7 @@ static connection_struct *switch_message(uint8 type, struct smb_request *req, in if (!set_current_service(conn,SVAL(req->inbuf,smb_flg), (flags & (AS_USER|DO_CHDIR) ?True:False))) { - reply_doserror(req, ERRSRV, ERRaccess); + reply_nterror(req, NT_STATUS_ACCESS_DENIED); return conn; } conn->num_smb_operations++; @@ -1393,7 +1393,7 @@ static connection_struct *switch_message(uint8 type, struct smb_request *req, in && (!change_to_guest() || !check_access(smbd_server_fd(), lp_hostsallow(-1), lp_hostsdeny(-1)))) { - reply_doserror(req, ERRSRV, ERRaccess); + reply_nterror(req, NT_STATUS_ACCESS_DENIED); return conn; } @@ -1608,6 +1608,180 @@ static void fixup_chain_error_packet(struct smb_request *req) SCVAL(req->outbuf, smb_vwv0, 0xff); } +/** + * @brief Find the smb_cmd offset of the last command pushed + * @param[in] buf The buffer we're building up + * @retval Where can we put our next andx cmd? + * + * While chaining requests, the "next" request we're looking at needs to put + * its SMB_Command before the data the previous request already built up added + * to the chain. Find the offset to the place where we have to put our cmd. + */ + +static bool find_andx_cmd_ofs(uint8_t *buf, size_t *pofs) +{ + uint8_t cmd; + size_t ofs; + + cmd = CVAL(buf, smb_com); + + SMB_ASSERT(is_andx_req(cmd)); + + ofs = smb_vwv0; + + while (CVAL(buf, ofs) != 0xff) { + + if (!is_andx_req(CVAL(buf, ofs))) { + return false; + } + + /* + * ofs is from start of smb header, so add the 4 length + * bytes. The next cmd is right after the wct field. + */ + ofs = SVAL(buf, ofs+2) + 4 + 1; + + SMB_ASSERT(ofs+4 < talloc_get_size(buf)); + } + + *pofs = ofs; + return true; +} + +/** + * @brief Do the smb chaining at a buffer level + * @param[in] poutbuf Pointer to the talloc'ed buffer to be modified + * @param[in] smb_command The command that we want to issue + * @param[in] wct How many words? + * @param[in] vwv The words, already in network order + * @param[in] bytes_alignment How shall we align "bytes"? + * @param[in] num_bytes How many bytes? + * @param[in] bytes The data the request ships + * + * smb_splice_chain() adds the vwv and bytes to the request already present in + * *poutbuf. + */ + +static bool smb_splice_chain(uint8_t **poutbuf, uint8_t smb_command, + uint8_t wct, const uint16_t *vwv, + size_t bytes_alignment, + uint32_t num_bytes, const uint8_t *bytes) +{ + uint8_t *outbuf; + size_t old_size, new_size; + size_t ofs; + size_t chain_padding = 0; + size_t bytes_padding = 0; + bool first_request; + + old_size = talloc_get_size(*poutbuf); + + /* + * old_size == smb_wct means we're pushing the first request in for + * libsmb/ + */ + + first_request = (old_size == smb_wct); + + if (!first_request && ((old_size % 4) != 0)) { + /* + * Align the wct field of subsequent requests to a 4-byte + * boundary + */ + chain_padding = 4 - (old_size % 4); + } + + /* + * After the old request comes the new wct field (1 byte), the vwv's + * and the num_bytes field. After at we might need to align the bytes + * given to us to "bytes_alignment", increasing the num_bytes value. + */ + + new_size = old_size + chain_padding + 1 + wct * sizeof(uint16_t) + 2; + + if ((bytes_alignment != 0) && ((new_size % bytes_alignment) != 0)) { + bytes_padding = bytes_alignment - (new_size % bytes_alignment); + } + + new_size += bytes_padding + num_bytes; + + if ((smb_command != SMBwriteX) && (new_size > 0xffff)) { + DEBUG(1, ("splice_chain: %u bytes won't fit\n", + (unsigned)new_size)); + return false; + } + + outbuf = TALLOC_REALLOC_ARRAY(NULL, *poutbuf, uint8_t, new_size); + if (outbuf == NULL) { + DEBUG(0, ("talloc failed\n")); + return false; + } + *poutbuf = outbuf; + + if (first_request) { + SCVAL(outbuf, smb_com, smb_command); + } else { + size_t andx_cmd_ofs; + + if (!find_andx_cmd_ofs(outbuf, &andx_cmd_ofs)) { + DEBUG(1, ("invalid command chain\n")); + *poutbuf = TALLOC_REALLOC_ARRAY( + NULL, *poutbuf, uint8_t, old_size); + return false; + } + + if (chain_padding != 0) { + memset(outbuf + old_size, 0, chain_padding); + old_size += chain_padding; + } + + SCVAL(outbuf, andx_cmd_ofs, smb_command); + SSVAL(outbuf, andx_cmd_ofs + 2, old_size - 4); + } + + ofs = old_size; + + /* + * Push the chained request: + * + * wct field + */ + + SCVAL(outbuf, ofs, wct); + ofs += 1; + + /* + * vwv array + */ + + memcpy(outbuf + ofs, vwv, sizeof(uint16_t) * wct); + ofs += sizeof(uint16_t) * wct; + + /* + * bcc (byte count) + */ + + SSVAL(outbuf, ofs, num_bytes + bytes_padding); + ofs += sizeof(uint16_t); + + /* + * padding + */ + + if (bytes_padding != 0) { + memset(outbuf + ofs, 0, bytes_padding); + ofs += bytes_padding; + } + + /* + * The bytes field + */ + + memcpy(outbuf + ofs, bytes, num_bytes); + + return true; +} + /**************************************************************************** Construct a chained reply and add it to the already made reply ****************************************************************************/ @@ -1809,7 +1983,7 @@ void chain_reply(struct smb_request *req) * We end up here if there's any error in the chain syntax. Report a * DOS error, just like Windows does. */ - reply_nterror(req, NT_STATUS_DOS(ERRSRV, ERRerror)); + reply_force_doserror(req, ERRSRV, ERRerror); fixup_chain_error_packet(req); done: diff --git a/source3/smbd/reply.c b/source3/smbd/reply.c index 185f6014d1..b2d98bfbc0 100644 --- a/source3/smbd/reply.c +++ b/source3/smbd/reply.c @@ -704,7 +704,7 @@ void reply_tcon_and_X(struct smb_request *req) } if ((passlen > MAX_PASS_LEN) || (passlen >= req->buflen)) { - reply_doserror(req, ERRDOS, ERRbuftoosmall); + reply_force_doserror(req, ERRDOS, ERRbuftoosmall); END_PROFILE(SMBtconX); return; } @@ -744,7 +744,7 @@ void reply_tcon_and_X(struct smb_request *req) q = strchr_m(path+2,'\\'); if (!q) { data_blob_clear_free(&password); - reply_doserror(req, ERRDOS, ERRnosuchshare); + reply_nterror(req, NT_STATUS_BAD_NETWORK_NAME); END_PROFILE(SMBtconX); return; } @@ -864,7 +864,7 @@ void reply_unknown_new(struct smb_request *req, uint8 type) { DEBUG(0, ("unknown command type (%s): type=%d (0x%X)\n", smb_fn_name(type), type, type)); - reply_doserror(req, ERRSRV, ERRunknownsmb); + reply_force_doserror(req, ERRSRV, ERRunknownsmb); return; } @@ -901,7 +901,7 @@ void reply_ioctl(struct smb_request *req) replysize = 32; break; default: - reply_doserror(req, ERRSRV, ERRnosupport); + reply_force_doserror(req, ERRSRV, ERRnosupport); END_PROFILE(SMBioctl); return; } @@ -920,7 +920,7 @@ void reply_ioctl(struct smb_request *req) files_struct *fsp = file_fsp( req, SVAL(req->vwv+0, 0)); if (!fsp) { - reply_doserror(req, ERRDOS, ERRbadfid); + reply_nterror(req, NT_STATUS_INVALID_HANDLE); END_PROFILE(SMBioctl); return; } @@ -1652,7 +1652,7 @@ void reply_fclose(struct smb_request *req) p += 2; if (status_len == 0) { - reply_doserror(req, ERRSRV, ERRsrverror); + reply_force_doserror(req, ERRSRV, ERRsrverror); END_PROFILE(SMBfclose); return; } @@ -1738,7 +1738,7 @@ void reply_open(struct smb_request *req) OPENX_FILE_EXISTS_OPEN, &access_mask, &share_mode, &create_disposition, &create_options)) { - reply_nterror(req, NT_STATUS_DOS(ERRDOS, ERRbadaccess)); + reply_force_doserror(req, ERRDOS, ERRbadaccess); goto out; } @@ -1789,7 +1789,8 @@ void reply_open(struct smb_request *req) DEBUG(3,("attempt to open a directory %s\n", fsp_str_dbg(fsp))); close_file(req, fsp, ERROR_CLOSE); - reply_doserror(req, ERRDOS,ERRnoaccess); + reply_botherror(req, NT_STATUS_ACCESS_DENIED, + ERRDOS, ERRnoaccess); goto out; } @@ -1875,7 +1876,7 @@ void reply_open_and_X(struct smb_request *req) if (lp_nt_pipe_support()) { reply_open_pipe_and_X(conn, req); } else { - reply_doserror(req, ERRSRV, ERRaccess); + reply_nterror(req, NT_STATUS_NETWORK_ACCESS_DENIED); } goto out; } @@ -1910,7 +1911,7 @@ void reply_open_and_X(struct smb_request *req) &access_mask, &share_mode, &create_disposition, &create_options)) { - reply_nterror(req, NT_STATUS_DOS(ERRDOS, ERRbadaccess)); + reply_force_doserror(req, ERRDOS, ERRbadaccess); goto out; } @@ -1963,7 +1964,7 @@ void reply_open_and_X(struct smb_request *req) mtime = convert_timespec_to_time_t(smb_fname->st.st_ex_mtime); if (fattr & aDIR) { close_file(req, fsp, ERROR_CLOSE); - reply_doserror(req, ERRDOS, ERRnoaccess); + reply_nterror(req, NT_STATUS_ACCESS_DENIED); goto out; } @@ -3198,7 +3199,7 @@ void reply_lockread(struct smb_request *req) } if (!CHECK_READ(fsp,req)) { - reply_doserror(req, ERRDOS, ERRbadaccess); + reply_nterror(req, NT_STATUS_ACCESS_DENIED); END_PROFILE(SMBlockread); return; } @@ -3308,7 +3309,7 @@ void reply_read(struct smb_request *req) } if (!CHECK_READ(fsp,req)) { - reply_doserror(req, ERRDOS, ERRbadaccess); + reply_nterror(req, NT_STATUS_ACCESS_DENIED); END_PROFILE(SMBread); return; } @@ -3338,7 +3339,7 @@ Returning short read of maximum allowed for compatibility with Windows 2000.\n", &lock); if (!SMB_VFS_STRICT_LOCK(conn, fsp, &lock)) { - reply_doserror(req, ERRDOS,ERRlock); + reply_nterror(req, NT_STATUS_FILE_LOCK_CONFLICT); END_PROFILE(SMBread); return; } @@ -3420,7 +3421,7 @@ static void send_file_readX(connection_struct *conn, struct smb_request *req, &lock); if (!SMB_VFS_STRICT_LOCK(conn, fsp, &lock)) { - reply_doserror(req, ERRDOS, ERRlock); + reply_nterror(req, NT_STATUS_FILE_LOCK_CONFLICT); return; } @@ -3618,7 +3619,7 @@ void reply_read_and_X(struct smb_request *req) } if (!CHECK_READ(fsp,req)) { - reply_doserror(req, ERRDOS,ERRbadaccess); + reply_nterror(req, NT_STATUS_ACCESS_DENIED); END_PROFILE(SMBreadX); return; } @@ -3669,7 +3670,7 @@ void reply_read_and_X(struct smb_request *req) "used and we don't support 64 bit offsets.\n", (unsigned int)IVAL(req->vwv+10, 0) )); END_PROFILE(SMBreadX); - reply_doserror(req, ERRDOS, ERRbadaccess); + reply_nterror(req, NT_STATUS_ACCESS_DENIED); return; } @@ -3752,7 +3753,7 @@ void reply_writebraw(struct smb_request *req) } if (!CHECK_WRITE(fsp)) { - reply_doserror(req, ERRDOS, ERRbadaccess); + reply_nterror(req, NT_STATUS_ACCESS_DENIED); error_to_writebrawerr(req); END_PROFILE(SMBwritebraw); return; @@ -3786,7 +3787,7 @@ void reply_writebraw(struct smb_request *req) &lock); if (!SMB_VFS_STRICT_LOCK(conn, fsp, &lock)) { - reply_doserror(req, ERRDOS, ERRlock); + reply_nterror(req, NT_STATUS_FILE_LOCK_CONFLICT); error_to_writebrawerr(req); END_PROFILE(SMBwritebraw); return; @@ -3802,7 +3803,7 @@ void reply_writebraw(struct smb_request *req) (int)nwritten, (int)write_through)); if (nwritten < (ssize_t)numtowrite) { - reply_doserror(req, ERRHRD, ERRdiskfull); + reply_nterror(req, NT_STATUS_DISK_FULL); error_to_writebrawerr(req); goto strict_unlock; } @@ -3812,7 +3813,7 @@ void reply_writebraw(struct smb_request *req) /* Allocate a buffer of 64k + length. */ buf = TALLOC_ARRAY(NULL, char, 65540); if (!buf) { - reply_doserror(req, ERRDOS, ERRnomem); + reply_nterror(req, NT_STATUS_NO_MEMORY); error_to_writebrawerr(req); goto strict_unlock; } @@ -3968,7 +3969,7 @@ void reply_writeunlock(struct smb_request *req) } if (!CHECK_WRITE(fsp)) { - reply_doserror(req, ERRDOS,ERRbadaccess); + reply_nterror(req, NT_STATUS_ACCESS_DENIED); END_PROFILE(SMBwriteunlock); return; } @@ -3983,7 +3984,7 @@ void reply_writeunlock(struct smb_request *req) &lock); if (!SMB_VFS_STRICT_LOCK(conn, fsp, &lock)) { - reply_doserror(req, ERRDOS, ERRlock); + reply_nterror(req, NT_STATUS_FILE_LOCK_CONFLICT); END_PROFILE(SMBwriteunlock); return; } @@ -4013,7 +4014,7 @@ void reply_writeunlock(struct smb_request *req) } if((nwritten < numtowrite) && (numtowrite != 0)) { - reply_doserror(req, ERRHRD, ERRdiskfull); + reply_nterror(req, NT_STATUS_DISK_FULL); goto strict_unlock; } @@ -4089,7 +4090,7 @@ void reply_write(struct smb_request *req) } if (!CHECK_WRITE(fsp)) { - reply_doserror(req, ERRDOS, ERRbadaccess); + reply_nterror(req, NT_STATUS_ACCESS_DENIED); END_PROFILE(SMBwrite); return; } @@ -4103,7 +4104,7 @@ void reply_write(struct smb_request *req) &lock); if (!SMB_VFS_STRICT_LOCK(conn, fsp, &lock)) { - reply_doserror(req, ERRDOS, ERRlock); + reply_nterror(req, NT_STATUS_FILE_LOCK_CONFLICT); END_PROFILE(SMBwrite); return; } @@ -4147,7 +4148,7 @@ void reply_write(struct smb_request *req) } if((nwritten == 0) && (numtowrite != 0)) { - reply_doserror(req, ERRHRD, ERRdiskfull); + reply_nterror(req, NT_STATUS_DISK_FULL); goto strict_unlock; } @@ -4299,14 +4300,14 @@ void reply_write_and_X(struct smb_request *req) return; } if (numtowrite != req->unread_bytes) { - reply_doserror(req, ERRDOS, ERRbadmem); + reply_nterror(req, NT_STATUS_INVALID_PARAMETER); END_PROFILE(SMBwriteX); return; } } else { if (smb_doff > smblen || smb_doff + numtowrite < numtowrite || smb_doff + numtowrite > smblen) { - reply_doserror(req, ERRDOS, ERRbadmem); + reply_nterror(req, NT_STATUS_INVALID_PARAMETER); END_PROFILE(SMBwriteX); return; } @@ -4315,7 +4316,7 @@ void reply_write_and_X(struct smb_request *req) /* If it's an IPC, pass off the pipe handler. */ if (IS_IPC(conn)) { if (req->unread_bytes) { - reply_doserror(req, ERRDOS, ERRbadmem); + reply_nterror(req, NT_STATUS_INVALID_PARAMETER); END_PROFILE(SMBwriteX); return; } @@ -4334,7 +4335,7 @@ void reply_write_and_X(struct smb_request *req) } if (!CHECK_WRITE(fsp)) { - reply_doserror(req, ERRDOS, ERRbadaccess); + reply_nterror(req, NT_STATUS_ACCESS_DENIED); END_PROFILE(SMBwriteX); return; } @@ -4358,7 +4359,7 @@ void reply_write_and_X(struct smb_request *req) DEBUG(0,("reply_write_and_X - large offset (%x << 32) " "used and we don't support 64 bit offsets.\n", (unsigned int)IVAL(req->vwv+12, 0) )); - reply_doserror(req, ERRDOS, ERRbadaccess); + reply_nterror(req, NT_STATUS_ACCESS_DENIED); END_PROFILE(SMBwriteX); return; } @@ -4371,7 +4372,7 @@ void reply_write_and_X(struct smb_request *req) &lock); if (!SMB_VFS_STRICT_LOCK(conn, fsp, &lock)) { - reply_doserror(req, ERRDOS, ERRlock); + reply_nterror(req, NT_STATUS_FILE_LOCK_CONFLICT); END_PROFILE(SMBwriteX); return; } @@ -4400,7 +4401,7 @@ void reply_write_and_X(struct smb_request *req) } if((nwritten == 0) && (numtowrite != 0)) { - reply_doserror(req, ERRHRD, ERRdiskfull); + reply_nterror(req, NT_STATUS_DISK_FULL); goto strict_unlock; } @@ -4611,7 +4612,7 @@ void reply_close(struct smb_request *req) */ if(!fsp || (fsp->conn != conn) || (fsp->vuid != req->vuid)) { - reply_doserror(req, ERRDOS, ERRbadfid); + reply_nterror(req, NT_STATUS_INVALID_HANDLE); END_PROFILE(SMBclose); return; } @@ -4690,7 +4691,7 @@ void reply_writeclose(struct smb_request *req) return; } if (!CHECK_WRITE(fsp)) { - reply_doserror(req, ERRDOS,ERRbadaccess); + reply_nterror(req, NT_STATUS_ACCESS_DENIED); END_PROFILE(SMBwriteclose); return; } @@ -4706,7 +4707,7 @@ void reply_writeclose(struct smb_request *req) &lock); if (!SMB_VFS_STRICT_LOCK(conn, fsp, &lock)) { - reply_doserror(req, ERRDOS,ERRlock); + reply_nterror(req, NT_STATUS_FILE_LOCK_CONFLICT); END_PROFILE(SMBwriteclose); return; } @@ -4732,7 +4733,7 @@ void reply_writeclose(struct smb_request *req) conn->num_files_open)); if(((nwritten == 0) && (numtowrite != 0))||(nwritten < 0)) { - reply_doserror(req, ERRHRD, ERRdiskfull); + reply_nterror(req, NT_STATUS_DISK_FULL); goto strict_unlock; } @@ -4882,7 +4883,7 @@ void reply_tdis(struct smb_request *req) if (!conn) { DEBUG(4,("Invalid connection in tdis\n")); - reply_doserror(req, ERRSRV, ERRinvnid); + reply_nterror(req, NT_STATUS_NETWORK_NAME_DELETED); END_PROFILE(SMBtdis); return; } @@ -4982,7 +4983,7 @@ void reply_printopen(struct smb_request *req) } if (!CAN_PRINT(conn)) { - reply_doserror(req, ERRDOS, ERRnoaccess); + reply_nterror(req, NT_STATUS_ACCESS_DENIED); END_PROFILE(SMBsplopen); return; } @@ -5040,7 +5041,7 @@ void reply_printclose(struct smb_request *req) } if (!CAN_PRINT(conn)) { - reply_nterror(req, NT_STATUS_DOS(ERRSRV, ERRerror)); + reply_force_doserror(req, ERRSRV, ERRerror); END_PROFILE(SMBsplclose); return; } @@ -5088,7 +5089,7 @@ void reply_printqueue(struct smb_request *req) one printer - I think we should now only accept it if they get it right (tridge) */ if (!CAN_PRINT(conn)) { - reply_doserror(req, ERRDOS, ERRnoaccess); + reply_nterror(req, NT_STATUS_ACCESS_DENIED); END_PROFILE(SMBsplretq); return; } @@ -5182,13 +5183,13 @@ void reply_printwrite(struct smb_request *req) } if (!CAN_PRINT(conn)) { - reply_doserror(req, ERRDOS, ERRnoaccess); + reply_nterror(req, NT_STATUS_ACCESS_DENIED); END_PROFILE(SMBsplwr); return; } if (!CHECK_WRITE(fsp)) { - reply_doserror(req, ERRDOS, ERRbadaccess); + reply_nterror(req, NT_STATUS_ACCESS_DENIED); END_PROFILE(SMBsplwr); return; } @@ -6548,7 +6549,7 @@ void reply_copy(struct smb_request *req) if (tid2 != conn->cnum) { /* can't currently handle inter share copies XXXX */ DEBUG(3,("Rejecting inter-share copy\n")); - reply_doserror(req, ERRSRV, ERRinvdevice); + reply_nterror(req, NT_STATUS_BAD_DEVICE_TYPE); goto out; } @@ -6587,19 +6588,19 @@ void reply_copy(struct smb_request *req) target_is_directory = VALID_STAT_OF_DIR(smb_fname_dst->st); if ((flags&1) && target_is_directory) { - reply_doserror(req, ERRDOS, ERRbadfile); + reply_nterror(req, NT_STATUS_NO_SUCH_FILE); goto out; } if ((flags&2) && !target_is_directory) { - reply_doserror(req, ERRDOS, ERRbadpath); + reply_nterror(req, NT_STATUS_OBJECT_PATH_NOT_FOUND); goto out; } if ((flags&(1<<5)) && VALID_STAT_OF_DIR(smb_fname_src->st)) { /* wants a tree copy! XXXX */ DEBUG(3,("Rejecting tree copy\n")); - reply_doserror(req, ERRSRV, ERRerror); + reply_nterror(req, NT_STATUS_INVALID_PARAMETER); goto out; } @@ -6810,7 +6811,7 @@ void reply_copy(struct smb_request *req) } if (count == 0) { - reply_doserror(req, ERRDOS, error); + reply_nterror(req, dos_to_ntstatus(ERRDOS, error)); goto out; } @@ -7239,7 +7240,7 @@ void reply_lockingX(struct smb_request *req) /* we don't support these - and CANCEL_LOCK makes w2k and XP reboot so I don't really want to be compatible! (tridge) */ - reply_nterror(req, NT_STATUS_DOS(ERRDOS, ERRnoatomiclocks)); + reply_force_doserror(req, ERRDOS, ERRnoatomiclocks); END_PROFILE(SMBlockingX); return; } @@ -7282,7 +7283,7 @@ void reply_lockingX(struct smb_request *req) return; } else { END_PROFILE(SMBlockingX); - reply_doserror(req, ERRDOS, ERRlock); + reply_nterror(req, NT_STATUS_FILE_LOCK_CONFLICT); return; } } @@ -7350,8 +7351,8 @@ void reply_lockingX(struct smb_request *req) * There is no error code marked "stupid client bug".... :-). */ if(err) { + reply_nterror(req, NT_STATUS_ACCESS_DENIED); END_PROFILE(SMBlockingX); - reply_doserror(req, ERRDOS, ERRnoaccess); return; } } @@ -7385,8 +7386,8 @@ void reply_lockingX(struct smb_request *req) * There is no error code marked "stupid client bug".... :-). */ if(err) { + reply_nterror(req, NT_STATUS_ACCESS_DENIED); END_PROFILE(SMBlockingX); - reply_doserror(req, ERRDOS, ERRnoaccess); return; } } @@ -7427,7 +7428,7 @@ void reply_lockingX(struct smb_request *req) void reply_readbmpx(struct smb_request *req) { START_PROFILE(SMBreadBmpx); - reply_doserror(req, ERRSRV, ERRuseSTD); + reply_force_doserror(req, ERRSRV, ERRuseSTD); END_PROFILE(SMBreadBmpx); return; } @@ -7441,7 +7442,7 @@ void reply_readbmpx(struct smb_request *req) void reply_readbs(struct smb_request *req) { START_PROFILE(SMBreadBs); - reply_doserror(req, ERRSRV, ERRuseSTD); + reply_force_doserror(req, ERRSRV, ERRuseSTD); END_PROFILE(SMBreadBs); return; } @@ -7468,7 +7469,7 @@ void reply_setattrE(struct smb_request *req) fsp = file_fsp(req, SVAL(req->vwv+0, 0)); if(!fsp || (fsp->conn != conn)) { - reply_doserror(req, ERRDOS, ERRbadfid); + reply_nterror(req, NT_STATUS_INVALID_HANDLE); goto out; } @@ -7499,7 +7500,7 @@ void reply_setattrE(struct smb_request *req) status = smb_set_file_time(conn, fsp, fsp->fsp_name, &ft, true); if (!NT_STATUS_IS_OK(status)) { - reply_doserror(req, ERRDOS, ERRnoaccess); + reply_nterror(req, status); goto out; } @@ -7527,7 +7528,7 @@ void reply_setattrE(struct smb_request *req) void reply_writebmpx(struct smb_request *req) { START_PROFILE(SMBwriteBmpx); - reply_doserror(req, ERRSRV, ERRuseSTD); + reply_force_doserror(req, ERRSRV, ERRuseSTD); END_PROFILE(SMBwriteBmpx); return; } @@ -7541,7 +7542,7 @@ void reply_writebmpx(struct smb_request *req) void reply_writebs(struct smb_request *req) { START_PROFILE(SMBwriteBs); - reply_doserror(req, ERRSRV, ERRuseSTD); + reply_force_doserror(req, ERRSRV, ERRuseSTD); END_PROFILE(SMBwriteBs); return; } @@ -7568,7 +7569,7 @@ void reply_getattrE(struct smb_request *req) fsp = file_fsp(req, SVAL(req->vwv+0, 0)); if(!fsp || (fsp->conn != conn)) { - reply_doserror(req, ERRDOS, ERRbadfid); + reply_nterror(req, NT_STATUS_INVALID_HANDLE); END_PROFILE(SMBgetattrE); return; } diff --git a/source3/smbd/trans2.c b/source3/smbd/trans2.c index ca2ff60162..f9c11d8903 100644 --- a/source3/smbd/trans2.c +++ b/source3/smbd/trans2.c @@ -1012,7 +1012,7 @@ static void call_trans2open(connection_struct *conn, pname = ¶ms[28]; if (IS_IPC(conn)) { - reply_doserror(req, ERRSRV, ERRaccess); + reply_nterror(req, NT_STATUS_NETWORK_ACCESS_DENIED); goto out; } @@ -1055,7 +1055,7 @@ static void call_trans2open(connection_struct *conn, &access_mask, &share_mode, &create_disposition, &create_options)) { - reply_doserror(req, ERRDOS, ERRbadaccess); + reply_nterror(req, NT_STATUS_ACCESS_DENIED); goto out; } @@ -1121,7 +1121,7 @@ static void call_trans2open(connection_struct *conn, inode = smb_fname->st.st_ex_ino; if (fattr & aDIR) { close_file(req, fsp, ERROR_CLOSE); - reply_doserror(req, ERRDOS,ERRnoaccess); + reply_nterror(req, NT_STATUS_ACCESS_DENIED); goto out; } @@ -1484,7 +1484,6 @@ static bool smbd_marshall_dir_entry(TALLOC_CTX *ctx, char *nameptr; char *last_entry_ptr; bool was_8_3; - uint32_t nt_extmode; /* Used for NT connections instead of mode */ off_t off; off_t pad = 0; @@ -1535,8 +1534,6 @@ static bool smbd_marshall_dir_entry(TALLOC_CTX *ctx, pad = 0; off = 0; - nt_extmode = mode ? mode : FILE_ATTRIBUTE_NORMAL; - switch (info_level) { case SMB_FIND_INFO_STANDARD: DEBUG(10,("smbd_marshall_dir_entry: SMB_FIND_INFO_STANDARD\n")); @@ -1684,7 +1681,7 @@ static bool smbd_marshall_dir_entry(TALLOC_CTX *ctx, put_long_date_timespec(conn->ts_res,p,cdate_ts); p += 8; SOFF_T(p,0,file_size); p += 8; SOFF_T(p,0,allocation_size); p += 8; - SIVAL(p,0,nt_extmode); p += 4; + SIVAL(p,0,mode); p += 4; q = p; p += 4; /* q is placeholder for name length. */ { unsigned int ea_size = estimate_ea_size(conn, NULL, @@ -1750,7 +1747,7 @@ static bool smbd_marshall_dir_entry(TALLOC_CTX *ctx, put_long_date_timespec(conn->ts_res,p,cdate_ts); p += 8; SOFF_T(p,0,file_size); p += 8; SOFF_T(p,0,allocation_size); p += 8; - SIVAL(p,0,nt_extmode); p += 4; + SIVAL(p,0,mode); p += 4; len = srvstr_push(base_data, flags2, p + 4, fname, PTR_DIFF(end_data, p+4), STR_TERMINATE_ASCII); @@ -1786,7 +1783,7 @@ static bool smbd_marshall_dir_entry(TALLOC_CTX *ctx, put_long_date_timespec(conn->ts_res,p,cdate_ts); p += 8; SOFF_T(p,0,file_size); p += 8; SOFF_T(p,0,allocation_size); p += 8; - SIVAL(p,0,nt_extmode); p += 4; + SIVAL(p,0,mode); p += 4; q = p; p += 4; /* q is placeholder for name length. */ { unsigned int ea_size = estimate_ea_size(conn, NULL, @@ -1861,7 +1858,7 @@ static bool smbd_marshall_dir_entry(TALLOC_CTX *ctx, put_long_date_timespec(conn->ts_res,p,cdate_ts); p += 8; SOFF_T(p,0,file_size); p += 8; SOFF_T(p,0,allocation_size); p += 8; - SIVAL(p,0,nt_extmode); p += 4; + SIVAL(p,0,mode); p += 4; q = p; p += 4; /* q is placeholder for name length. */ { unsigned int ea_size = estimate_ea_size(conn, NULL, @@ -1908,7 +1905,7 @@ static bool smbd_marshall_dir_entry(TALLOC_CTX *ctx, put_long_date_timespec(conn->ts_res,p,cdate_ts); p += 8; SOFF_T(p,0,file_size); p += 8; SOFF_T(p,0,allocation_size); p += 8; - SIVAL(p,0,nt_extmode); p += 4; + SIVAL(p,0,mode); p += 4; q = p; p += 4; /* q is placeholder for name length */ { unsigned int ea_size = estimate_ea_size(conn, NULL, @@ -2337,7 +2334,7 @@ total_data=%u (should be %u)\n", (unsigned int)total_data, (unsigned int)IVAL(pd } if (!lp_ea_support(SNUM(conn))) { - reply_doserror(req, ERRDOS, ERReasnotsupported); + reply_nterror(req, NT_STATUS_EAS_NOT_SUPPORTED); goto out; } @@ -2465,7 +2462,7 @@ total_data=%u (should be %u)\n", (unsigned int)total_data, (unsigned int)IVAL(pd if(numentries == 0) { dptr_close(sconn, &dptr_num); if (get_Protocol() < PROTOCOL_NT1) { - reply_doserror(req, ERRDOS, ERRnofiles); + reply_force_doserror(req, ERRDOS, ERRnofiles); goto out; } else { reply_botherror(req, NT_STATUS_NO_SUCH_FILE, @@ -2652,7 +2649,7 @@ total_data=%u (should be %u)\n", (unsigned int)total_data, (unsigned int)IVAL(pd } if (!lp_ea_support(SNUM(conn))) { - reply_doserror(req, ERRDOS, ERReasnotsupported); + reply_nterror(req, NT_STATUS_EAS_NOT_SUPPORTED); return; } @@ -2685,7 +2682,7 @@ total_data=%u (should be %u)\n", (unsigned int)total_data, (unsigned int)IVAL(pd /* Check that the dptr is valid */ if(!(dirptr = dptr_fetch_lanman2(sconn, dptr_num))) { - reply_doserror(req, ERRDOS, ERRnofiles); + reply_nterror(req, STATUS_NO_MORE_FILES); return; } @@ -2694,7 +2691,7 @@ total_data=%u (should be %u)\n", (unsigned int)total_data, (unsigned int)IVAL(pd /* Get the wildcard mask from the dptr */ if((p = dptr_wcard(sconn, dptr_num))== NULL) { DEBUG(2,("dptr_num %d has no wildcard\n", dptr_num)); - reply_doserror(req, ERRDOS, ERRnofiles); + reply_nterror(req, STATUS_NO_MORE_FILES); return; } @@ -4187,8 +4184,6 @@ NTSTATUS smbd_do_qfilepathinfo(connection_struct *conn, } else { mode = dos_mode(conn, smb_fname); } - if (!mode) - mode = FILE_ATTRIBUTE_NORMAL; nlink = psbuf->st_ex_nlink; @@ -5236,8 +5231,7 @@ total_data=%u (should be %u)\n", (unsigned int)total_data, (unsigned int)IVAL(pd } if (!lp_ea_support(SNUM(conn))) { - reply_doserror(req, ERRDOS, - ERReasnotsupported); + reply_nterror(req, NT_STATUS_EAS_NOT_SUPPORTED); return; } @@ -7669,7 +7663,8 @@ static void call_trans2setfilepathinfo(connection_struct *conn, max_data_bytes); return; } else { - reply_doserror(req, ERRDOS, ERRbadpath); + reply_nterror(req, + NT_STATUS_OBJECT_PATH_NOT_FOUND); return; } } else { @@ -7809,7 +7804,7 @@ static void call_trans2mkdir(connection_struct *conn, struct smb_request *req, TALLOC_CTX *ctx = talloc_tos(); if (!CAN_WRITE(conn)) { - reply_doserror(req, ERRSRV, ERRaccess); + reply_nterror(req, NT_STATUS_ACCESS_DENIED); return; } @@ -8028,7 +8023,7 @@ static void call_trans2getdfsreferral(connection_struct *conn, max_referral_level = SVAL(params,0); if(!lp_host_msdfs()) { - reply_doserror(req, ERRDOS, ERRbadfunc); + reply_nterror(req, NT_STATUS_NOT_IMPLEMENTED); return; } @@ -8070,7 +8065,7 @@ static void call_trans2ioctl(connection_struct *conn, /* check for an invalid fid before proceeding */ if (!fsp) { - reply_doserror(req, ERRDOS, ERRbadfid); + reply_nterror(req, NT_STATUS_INVALID_HANDLE); return; } @@ -8099,7 +8094,7 @@ static void call_trans2ioctl(connection_struct *conn, } DEBUG(2,("Unknown TRANS2_IOCTL\n")); - reply_doserror(req, ERRSRV, ERRerror); + reply_nterror(req, NT_STATUS_NOT_IMPLEMENTED); } /**************************************************************************** @@ -8325,7 +8320,7 @@ static void handle_trans2(connection_struct *conn, struct smb_request *req, default: /* Error in request */ DEBUG(2,("Unknown request %d in trans2 call\n", state->call)); - reply_doserror(req, ERRSRV,ERRerror); + reply_nterror(req, NT_STATUS_NOT_IMPLEMENTED); } } @@ -8377,7 +8372,7 @@ void reply_trans2(struct smb_request *req) case TRANSACT2_SETFSINFO: break; default: - reply_doserror(req, ERRSRV, ERRaccess); + reply_nterror(req, NT_STATUS_ACCESS_DENIED); END_PROFILE(SMBtrans2); return; } diff --git a/source3/utils/net_ads.c b/source3/utils/net_ads.c index f133eec0fc..8e644bb6b2 100644 --- a/source3/utils/net_ads.c +++ b/source3/utils/net_ads.c @@ -1007,6 +1007,8 @@ static NTSTATUS net_ads_join_ok(struct net_context *c) { ADS_STRUCT *ads = NULL; ADS_STATUS status; + fstring dc_name; + struct sockaddr_storage dcip; if (!secrets_init()) { DEBUG(1,("Failed to initialise secrets database\n")); @@ -1015,6 +1017,8 @@ static NTSTATUS net_ads_join_ok(struct net_context *c) net_use_krb_machine_account(c); + get_dc_name(lp_workgroup(), lp_realm(), dc_name, &dcip); + status = ads_startup(c, true, &ads); if (!ADS_ERR_OK(status)) { return ads_ntstatus(status); diff --git a/source3/utils/net_help.c b/source3/utils/net_help.c index 20fb66c2e0..4e326ba902 100644 --- a/source3/utils/net_help.c +++ b/source3/utils/net_help.c @@ -37,10 +37,10 @@ static int net_usage(struct net_context *c, int argc, const char **argv) for (i=0; table[i].funcname != NULL; i++) { if (c->display_usage) { d_printf(_("net %s usage:\n"), table[i].funcname); - d_printf("\n%s\n\n", table[i].usage); + d_printf("\n%s\n\n", _(table[i].usage)); } else { d_printf("%s %-15s %s\n", "net", table[i].funcname, - table[i].description); + _(table[i].description)); } } diff --git a/source3/utils/net_util.c b/source3/utils/net_util.c index 6bb5a3836c..2a42c87e2e 100644 --- a/source3/utils/net_util.c +++ b/source3/utils/net_util.c @@ -583,13 +583,13 @@ int net_run_function(struct net_context *c, int argc, const char **argv, d_fprintf(stderr, _("Invalid command: %s %s\n"), whoami, (argc > 0)?argv[0]:""); } - d_printf("Usage:\n"); + d_printf(_("Usage:\n")); for (i=0; table[i].funcname != NULL; i++) { if(c->display_usage == false) d_printf("%s %-15s %s\n", whoami, table[i].funcname, - table[i].description); + _(table[i].description)); else - d_printf("%s\n", table[i].usage); + d_printf("%s\n", _(table[i].usage)); } return c->display_usage?0:-1; @@ -599,7 +599,7 @@ void net_display_usage_from_functable(struct functable *table) { int i; for (i=0; table[i].funcname != NULL; i++) { - d_printf("%s\n", table[i].usage); + d_printf("%s\n", _(table[i].usage)); } } diff --git a/source3/utils/pdbedit.c b/source3/utils/pdbedit.c index 5d8a6fd749..06eedef920 100644 --- a/source3/utils/pdbedit.c +++ b/source3/utils/pdbedit.c @@ -50,9 +50,10 @@ #define BIT_BADPWRESET 0x08000000 #define BIT_LOGONHOURS 0x10000000 #define BIT_KICKOFFTIME 0x20000000 +#define BIT_DESCRIPTION 0x40000000 #define MASK_ALWAYS_GOOD 0x0000001F -#define MASK_USER_GOOD 0x20405FE0 +#define MASK_USER_GOOD 0x60405FE0 static int get_sid_from_cli_string(DOM_SID *sid, const char *str_sid) { @@ -1106,7 +1107,8 @@ int main (int argc, char **argv) (backend_out ? BIT_EXPORT : 0) + (badpw_reset ? BIT_BADPWRESET : 0) + (hours_reset ? BIT_LOGONHOURS : 0) + - (kickoff_time ? BIT_KICKOFFTIME : 0); + (kickoff_time ? BIT_KICKOFFTIME : 0) + + (acct_desc ? BIT_DESCRIPTION : 0); if (setparms & BIT_BACKEND) { /* HACK: set the global passdb backend by overwriting globals. diff --git a/source3/winbindd/wb_fill_pwent.c b/source3/winbindd/wb_fill_pwent.c index 4f4819ca23..8998bf991d 100644 --- a/source3/winbindd/wb_fill_pwent.c +++ b/source3/winbindd/wb_fill_pwent.c @@ -27,6 +27,14 @@ struct wb_fill_pwent_state { struct winbindd_pw *pw; }; +static bool fillup_pw_field(const char *lp_template, + const char *username, + const char *domname, + uid_t uid, + gid_t gid, + const char *in, + fstring out); + static void wb_fill_pwent_sid2uid_done(struct tevent_req *subreq); static void wb_fill_pwent_sid2gid_done(struct tevent_req *subreq); @@ -153,3 +161,42 @@ NTSTATUS wb_fill_pwent_recv(struct tevent_req *req) { return tevent_req_simple_recv_ntstatus(req); } + +static bool fillup_pw_field(const char *lp_template, + const char *username, + const char *domname, + uid_t uid, + gid_t gid, + const char *in, + fstring out) +{ + char *templ; + + if (out == NULL) + return False; + + /* The substitution of %U and %D in the 'template + homedir' is done by talloc_sub_specified() below. + If we have an in string (which means the value has already + been set in the nss_info backend), then use that. + Otherwise use the template value passed in. */ + + if ((in != NULL) && (in[0] != '\0') && (lp_security() == SEC_ADS)) { + templ = talloc_sub_specified(talloc_tos(), in, + username, domname, + uid, gid); + } else { + templ = talloc_sub_specified(talloc_tos(), lp_template, + username, domname, + uid, gid); + } + + if (!templ) + return False; + + safe_strcpy(out, templ, sizeof(fstring) - 1); + TALLOC_FREE(templ); + + return True; + +} diff --git a/source3/winbindd/wb_getgrsid.c b/source3/winbindd/wb_getgrsid.c index 03d71e45b9..bb93be2174 100644 --- a/source3/winbindd/wb_getgrsid.c +++ b/source3/winbindd/wb_getgrsid.c @@ -52,6 +52,17 @@ struct tevent_req *wb_getgrsid_send(TALLOC_CTX *mem_ctx, state->ev = ev; state->max_nesting = max_nesting; + if (lp_winbind_trusted_domains_only()) { + struct winbindd_domain *our_domain = find_our_domain(); + + if (sid_compare_domain(group_sid, &our_domain->sid) == 0) { + DEBUG(7, ("winbindd_getgrsid: My domain -- rejecting " + "getgrsid() for %s\n", sid_string_tos(group_sid))); + tevent_req_nterror(req, NT_STATUS_NO_SUCH_GROUP); + return tevent_req_post(req, ev); + } + } + subreq = wb_lookupsid_send(state, ev, &state->sid); if (tevent_req_nomem(subreq, req)) { return tevent_req_post(req, ev); diff --git a/source3/winbindd/wb_getpwsid.c b/source3/winbindd/wb_getpwsid.c index 1295d5bcbc..4ccc51ae18 100644 --- a/source3/winbindd/wb_getpwsid.c +++ b/source3/winbindd/wb_getpwsid.c @@ -31,8 +31,7 @@ struct wb_getpwsid_state { static void wb_getpwsid_queryuser_done(struct tevent_req *subreq); static void wb_getpwsid_lookupsid_done(struct tevent_req *subreq); -static void wb_getpwsid_sid2uid_done(struct tevent_req *subreq); -static void wb_getpwsid_sid2gid_done(struct tevent_req *subreq); +static void wb_getpwsid_done(struct tevent_req *subreq); struct tevent_req *wb_getpwsid_send(TALLOC_CTX *mem_ctx, struct tevent_context *ev, @@ -83,14 +82,14 @@ static void wb_getpwsid_queryuser_done(struct tevent_req *subreq) && (state->userinfo->acct_name[0] != '\0')) { /* * QueryUser got us a name, let's got directly to the - * sid2uid step + * fill_pwent step */ - subreq = wb_sid2uid_send(state, state->ev, - &state->userinfo->user_sid); + subreq = wb_fill_pwent_send(state, state->ev, state->userinfo, + state->pw); if (tevent_req_nomem(subreq, req)) { return; } - tevent_req_set_callback(subreq, wb_getpwsid_sid2uid_done, req); + tevent_req_set_callback(subreq, wb_getpwsid_done, req); return; } @@ -122,93 +121,25 @@ static void wb_getpwsid_lookupsid_done(struct tevent_req *subreq) tevent_req_nterror(req, status); return; } - subreq = wb_sid2uid_send(state, state->ev, &state->userinfo->user_sid); + subreq = wb_fill_pwent_send(state, state->ev, state->userinfo, + state->pw); if (tevent_req_nomem(subreq, req)) { return; } - tevent_req_set_callback(subreq, wb_getpwsid_sid2uid_done, req); + tevent_req_set_callback(subreq, wb_getpwsid_done, req); } -static void wb_getpwsid_sid2uid_done(struct tevent_req *subreq) +static void wb_getpwsid_done(struct tevent_req *subreq) { struct tevent_req *req = tevent_req_callback_data( subreq, struct tevent_req); - struct wb_getpwsid_state *state = tevent_req_data( - req, struct wb_getpwsid_state); - NTSTATUS status; - - status = wb_sid2uid_recv(subreq, &state->pw->pw_uid); - TALLOC_FREE(subreq); - if (!NT_STATUS_IS_OK(status)) { - tevent_req_nterror(req, status); - return; - } - subreq = wb_sid2gid_send(state, state->ev, - &state->userinfo->group_sid); - if (tevent_req_nomem(subreq, req)) { - return; - } - tevent_req_set_callback(subreq, wb_getpwsid_sid2gid_done, req); -} - -static void wb_getpwsid_sid2gid_done(struct tevent_req *subreq) -{ - struct tevent_req *req = tevent_req_callback_data( - subreq, struct tevent_req); - struct wb_getpwsid_state *state = tevent_req_data( - req, struct wb_getpwsid_state); NTSTATUS status; - char *username; - char *mapped_name; - status = wb_sid2gid_recv(subreq, &state->pw->pw_gid); - TALLOC_FREE(subreq); + status = wb_fill_pwent_recv(subreq); if (!NT_STATUS_IS_OK(status)) { tevent_req_nterror(req, status); return; } - - username = talloc_strdup_lower(state, state->userinfo->acct_name); - if (tevent_req_nomem(username, req)) { - return; - } - - status = normalize_name_map(state, state->user_domain, username, - &mapped_name); - - if (NT_STATUS_IS_OK(status) - || NT_STATUS_EQUAL(status, NT_STATUS_FILE_RENAMED)) { - /* - * normalize_name_map did something - */ - fstrcpy(state->pw->pw_name, mapped_name); - TALLOC_FREE(mapped_name); - } else { - fill_domain_username(state->pw->pw_name, - state->user_domain->name, - username, True); - } - fstrcpy(state->pw->pw_passwd, "*"); - fstrcpy(state->pw->pw_gecos, state->userinfo->full_name); - - if (!fillup_pw_field(lp_template_homedir(), username, - state->user_domain->name, state->pw->pw_uid, - state->pw->pw_gid, state->userinfo->homedir, - state->pw->pw_dir)) { - DEBUG(5, ("Could not compose homedir\n")); - tevent_req_nterror(req, NT_STATUS_NO_MEMORY); - return; - } - - if (!fillup_pw_field(lp_template_shell(), state->pw->pw_name, - state->user_domain->name, state->pw->pw_uid, - state->pw->pw_gid, state->userinfo->shell, - state->pw->pw_shell)) { - DEBUG(5, ("Could not compose shell\n")); - tevent_req_nterror(req, NT_STATUS_NO_MEMORY); - return; - } - tevent_req_done(req); } diff --git a/source3/winbindd/wb_gettoken.c b/source3/winbindd/wb_gettoken.c index 26189e5a97..ca407b2117 100644 --- a/source3/winbindd/wb_gettoken.c +++ b/source3/winbindd/wb_gettoken.c @@ -60,6 +60,13 @@ struct tevent_req *wb_gettoken_send(TALLOC_CTX *mem_ctx, return tevent_req_post(req, ev); } + if (lp_winbind_trusted_domains_only() && domain->primary) { + DEBUG(7, ("wb_gettoken: My domain -- rejecting getgroups() " + "for %s.\n", sid_string_tos(sid))); + tevent_req_nterror(req, NT_STATUS_NO_SUCH_USER); + return tevent_req_post(req, ev); + } + subreq = wb_lookupusergroups_send(state, ev, domain, &state->usersid); if (tevent_req_nomem(subreq, req)) { return tevent_req_post(req, ev); diff --git a/source3/winbindd/wb_sid2gid.c b/source3/winbindd/wb_sid2gid.c index a578746ea2..e15d563cd7 100644 --- a/source3/winbindd/wb_sid2gid.c +++ b/source3/winbindd/wb_sid2gid.c @@ -54,7 +54,7 @@ struct tevent_req *wb_sid2gid_send(TALLOC_CTX *mem_ctx, DEBUG(10, ("idmap_cache_find_sid2gid found %d%s\n", (int)state->gid, expired ? " (expired)": "")); - if (!expired || IS_DOMAIN_OFFLINE(find_our_domain())) { + if (!expired || is_domain_offline(find_our_domain())) { if (state->gid == -1) { tevent_req_nterror(req, NT_STATUS_NONE_MAPPED); } else { diff --git a/source3/winbindd/wb_sid2uid.c b/source3/winbindd/wb_sid2uid.c index abfe257bfa..9c22b8d10b 100644 --- a/source3/winbindd/wb_sid2uid.c +++ b/source3/winbindd/wb_sid2uid.c @@ -53,7 +53,7 @@ struct tevent_req *wb_sid2uid_send(TALLOC_CTX *mem_ctx, DEBUG(10, ("idmap_cache_find_sid2uid found %d%s\n", (int)state->uid, expired ? " (expired)": "")); - if (!expired || IS_DOMAIN_OFFLINE(find_our_domain())) { + if (!expired || is_domain_offline(find_our_domain())) { if (state->uid == -1) { tevent_req_nterror(req, NT_STATUS_NONE_MAPPED); } else { diff --git a/source3/winbindd/winbindd.c b/source3/winbindd/winbindd.c index e09374c5cb..f6f4a8fee7 100644 --- a/source3/winbindd/winbindd.c +++ b/source3/winbindd/winbindd.c @@ -532,6 +532,8 @@ static struct winbindd_async_dispatch_table async_nonpriv_table[] = { winbindd_list_groups_send, winbindd_list_groups_recv }, { WINBINDD_CHECK_MACHACC, "CHECK_MACHACC", winbindd_check_machine_acct_send, winbindd_check_machine_acct_recv }, + { WINBINDD_PING_DC, "PING_DC", + winbindd_ping_dc_send, winbindd_ping_dc_recv }, { 0, NULL, NULL, NULL } }; @@ -796,10 +798,15 @@ static void winbind_client_request_read(struct tevent_req *req) ret = wb_req_read_recv(req, state, &state->request, &err); TALLOC_FREE(req); if (ret == -1) { + if (err == EPIPE) { + DEBUG(6, ("closing socket %d, client exited\n", + state->sock)); + } else { + DEBUG(2, ("Could not read client request from fd %d: " + "%s\n", state->sock, strerror(err))); + } close(state->sock); state->sock = -1; - DEBUG(2, ("Could not read client request: %s\n", - strerror(err))); remove_client(state); return; } @@ -833,10 +840,6 @@ static void remove_client(struct winbindd_cli_state *state) state->sock = -1; } - /* Free any getent state */ - - free_getent_state(state->getgrent_state); - TALLOC_FREE(state->mem_ctx); /* Remove from list and free */ @@ -855,7 +858,7 @@ static bool remove_idle_client(void) for (state = winbindd_client_list(); state; state = state->next) { if (state->response == NULL && - !state->pwent_state && !state->getgrent_state) { + !state->pwent_state && !state->grent_state) { nidle++; if (!last_access || state->last_access < last_access) { last_access = state->last_access; diff --git a/source3/winbindd/winbindd.h b/source3/winbindd/winbindd.h index 2e7d09f442..ea791234fb 100644 --- a/source3/winbindd/winbindd.h +++ b/source3/winbindd/winbindd.h @@ -65,22 +65,11 @@ struct winbindd_cli_state { * initialized? */ bool getgrent_initialized; /* Has getgrent_state been * initialized? */ - struct getent_state *getgrent_state; /* State for getgrent() */ struct getpwent_state *pwent_state; /* State for getpwent() */ struct getgrent_state *grent_state; /* State for getgrent() */ }; -/* State between get{pw,gr}ent() calls */ - -struct getent_state { - struct getent_state *prev, *next; - void *sam_entries; - uint32 sam_entry_index, num_sam_entries; - bool got_sam_entries; - fstring domain_name; -}; - struct getpwent_state { struct winbindd_domain *domain; int next_user; @@ -121,8 +110,6 @@ struct winbindd_cm_conn { struct rpc_pipe_client *netlogon_pipe; }; -struct winbindd_async_request; - /* Async child */ struct winbindd_domain; @@ -326,10 +313,7 @@ struct winbindd_methods { /* enumerate trusted domains */ NTSTATUS (*trusted_domains)(struct winbindd_domain *domain, TALLOC_CTX *mem_ctx, - uint32 *num_domains, - char ***names, - char ***alt_names, - DOM_SID **dom_sids); + struct netr_DomainTrustList *trusts); }; /* Filled out by IDMAP backends */ @@ -400,9 +384,4 @@ struct WINBINDD_CCACHE_ENTRY { #define WINBINDD_PAM_AUTH_KRB5_RENEW_TIME 2592000 /* one month */ #define DOM_SEQUENCE_NONE ((uint32)-1) -#define IS_DOMAIN_OFFLINE(x) ( lp_winbind_offline_logon() && \ - ( get_global_winbindd_state_offline() \ - || !(x)->online ) ) -#define IS_DOMAIN_ONLINE(x) (!IS_DOMAIN_OFFLINE(x)) - #endif /* _WINBINDD_H */ diff --git a/source3/winbindd/winbindd_ads.c b/source3/winbindd/winbindd_ads.c index 92c0272088..b0ca9b8176 100644 --- a/source3/winbindd/winbindd_ads.c +++ b/source3/winbindd/winbindd_ads.c @@ -1257,13 +1257,9 @@ static NTSTATUS password_policy(struct winbindd_domain *domain, /* get a list of trusted domains */ static NTSTATUS trusted_domains(struct winbindd_domain *domain, TALLOC_CTX *mem_ctx, - uint32 *num_domains, - char ***names, - char ***alt_names, - DOM_SID **dom_sids) + struct netr_DomainTrustList *trusts) { NTSTATUS result = NT_STATUS_UNSUCCESSFUL; - struct netr_DomainTrustList trusts; int i; uint32 flags; struct rpc_pipe_client *cli; @@ -1272,10 +1268,7 @@ static NTSTATUS trusted_domains(struct winbindd_domain *domain, DEBUG(3,("ads: trusted_domains\n")); - *num_domains = 0; - *alt_names = NULL; - *names = NULL; - *dom_sids = NULL; + ZERO_STRUCTP(trusts); /* If this is our primary domain or a root in our forest, query for all trusts. If not, then just look for domain @@ -1303,142 +1296,121 @@ static NTSTATUS trusted_domains(struct winbindd_domain *domain, result = rpccli_netr_DsrEnumerateDomainTrusts(cli, mem_ctx, cli->desthost, flags, - &trusts, + trusts, NULL); - if ( NT_STATUS_IS_OK(result) && trusts.count) { - - /* Allocate memory for trusted domain names and sids */ - - if ( !(*names = TALLOC_ARRAY(mem_ctx, char *, trusts.count)) ) { - DEBUG(0, ("trusted_domains: out of memory\n")); - return NT_STATUS_NO_MEMORY; - } - - if ( !(*alt_names = TALLOC_ARRAY(mem_ctx, char *, trusts.count)) ) { - DEBUG(0, ("trusted_domains: out of memory\n")); - return NT_STATUS_NO_MEMORY; - } - - if ( !(*dom_sids = TALLOC_ARRAY(mem_ctx, DOM_SID, trusts.count)) ) { - DEBUG(0, ("trusted_domains: out of memory\n")); - return NT_STATUS_NO_MEMORY; - } - - /* Copy across names and sids */ - - - ret_count = 0; - for (i = 0; i < trusts.count; i++) { - struct winbindd_domain d; + if (!NT_STATUS_IS_OK(result)) { + return result; + } + if (trusts->count == 0) { + return NT_STATUS_OK; + } - ZERO_STRUCT(d); + /* Copy across names and sids */ - /* drop external trusts if this is not our primary - domain. This means that the returned number of - domains may be less that the ones actually trusted - by the DC. */ + ret_count = 0; + for (i = 0; i < trusts->count; i++) { + struct netr_DomainTrust *trust = &trusts->array[i]; + struct winbindd_domain d; - if ( (trusts.array[i].trust_attributes == NETR_TRUST_ATTRIBUTE_QUARANTINED_DOMAIN) && - !domain->primary ) - { - DEBUG(10,("trusted_domains: Skipping external trusted domain " - "%s because it is outside of our primary domain\n", - trusts.array[i].netbios_name)); - continue; - } + ZERO_STRUCT(d); - /* We must check that the SID of each trusted domain - * was returned to work around a bug in Windows: - * http://support.microsoft.com/kb/922832 */ + /* + * drop external trusts if this is not our primary + * domain. This means that the returned number of + * domains may be less that the ones actually trusted + * by the DC. + */ - (*names)[ret_count] = CONST_DISCARD(char *, trusts.array[i].netbios_name); - (*alt_names)[ret_count] = CONST_DISCARD(char *, trusts.array[i].dns_name); - if (trusts.array[i].sid) { - sid_copy(&(*dom_sids)[ret_count], trusts.array[i].sid); - } else { - sid_copy(&(*dom_sids)[ret_count], &global_sid_NULL); - } + if ((trust->trust_attributes + == NETR_TRUST_ATTRIBUTE_QUARANTINED_DOMAIN) && + !domain->primary ) + { + DEBUG(10,("trusted_domains: Skipping external trusted " + "domain %s because it is outside of our " + "primary domain\n", + trust->netbios_name)); + continue; + } - /* add to the trusted domain cache */ + /* add to the trusted domain cache */ - fstrcpy( d.name, trusts.array[i].netbios_name); - fstrcpy( d.alt_name, trusts.array[i].dns_name); - if (trusts.array[i].sid) { - sid_copy( &d.sid, trusts.array[i].sid); - } else { - sid_copy(&d.sid, &global_sid_NULL); - } + fstrcpy(d.name, trust->netbios_name); + fstrcpy(d.alt_name, trust->dns_name); + if (trust->sid) { + sid_copy(&d.sid, trust->sid); + } else { + sid_copy(&d.sid, &global_sid_NULL); + } - if ( domain->primary ) { + if ( domain->primary ) { + DEBUG(10,("trusted_domains(ads): Searching " + "trusted domain list of %s and storing " + "trust flags for domain %s\n", + domain->name, d.alt_name)); + + d.domain_flags = trust->trust_flags; + d.domain_type = trust->trust_type; + d.domain_trust_attribs = trust->trust_attributes; + + wcache_tdc_add_domain( &d ); + ret_count++; + } else if ( (domain->domain_flags&fr_flags) == fr_flags ) { + /* Check if we already have this record. If + * we are following our forest root that is not + * our primary domain, we want to keep trust + * flags from the perspective of our primary + * domain not our forest root. */ + struct winbindd_tdc_domain *exist = NULL; + + exist = wcache_tdc_fetch_domain( + talloc_tos(), trust->netbios_name); + if (!exist) { DEBUG(10,("trusted_domains(ads): Searching " - "trusted domain list of %s and storing " - "trust flags for domain %s\n", - domain->name, d.alt_name)); - - d.domain_flags = trusts.array[i].trust_flags; - d.domain_type = trusts.array[i].trust_type; - d.domain_trust_attribs = trusts.array[i].trust_attributes; + "trusted domain list of %s and " + "storing trust flags for domain " + "%s\n", domain->name, d.alt_name)); + d.domain_flags = trust->trust_flags; + d.domain_type = trust->trust_type; + d.domain_trust_attribs = + trust->trust_attributes; wcache_tdc_add_domain( &d ); ret_count++; - } else if ( (domain->domain_flags&fr_flags) == fr_flags ) { - /* Check if we already have this record. If - * we are following our forest root that is not - * our primary domain, we want to keep trust - * flags from the perspective of our primary - * domain not our forest root. */ - struct winbindd_tdc_domain *exist = NULL; - - exist = - wcache_tdc_fetch_domain(NULL, trusts.array[i].netbios_name); - if (!exist) { - DEBUG(10,("trusted_domains(ads): Searching " - "trusted domain list of %s and storing " - "trust flags for domain %s\n", - domain->name, d.alt_name)); - d.domain_flags = trusts.array[i].trust_flags; - d.domain_type = trusts.array[i].trust_type; - d.domain_trust_attribs = trusts.array[i].trust_attributes; - - wcache_tdc_add_domain( &d ); - ret_count++; - } - TALLOC_FREE(exist); + } + TALLOC_FREE(exist); + } else { + /* This gets a little tricky. If we are + following a transitive forest trust, then + innerit the flags, type, and attribs from + the domain we queried to make sure we don't + record the view of the trust from the wrong + side. Always view it from the side of our + primary domain. --jerry */ + struct winbindd_tdc_domain *parent = NULL; + + DEBUG(10,("trusted_domains(ads): Searching " + "trusted domain list of %s and inheriting " + "trust flags for domain %s\n", + domain->name, d.alt_name)); + + parent = wcache_tdc_fetch_domain(talloc_tos(), + domain->name); + if (parent) { + d.domain_flags = parent->trust_flags; + d.domain_type = parent->trust_type; + d.domain_trust_attribs = parent->trust_attribs; } else { - /* This gets a little tricky. If we are - following a transitive forest trust, then - innerit the flags, type, and attribs from - the domain we queried to make sure we don't - record the view of the trust from the wrong - side. Always view it from the side of our - primary domain. --jerry */ - struct winbindd_tdc_domain *parent = NULL; - - DEBUG(10,("trusted_domains(ads): Searching " - "trusted domain list of %s and inheriting " - "trust flags for domain %s\n", - domain->name, d.alt_name)); - - parent = wcache_tdc_fetch_domain(NULL, domain->name); - if (parent) { - d.domain_flags = parent->trust_flags; - d.domain_type = parent->trust_type; - d.domain_trust_attribs = parent->trust_attribs; - } else { - d.domain_flags = domain->domain_flags; - d.domain_type = domain->domain_type; - d.domain_trust_attribs = domain->domain_trust_attribs; - } - TALLOC_FREE(parent); - - wcache_tdc_add_domain( &d ); - ret_count++; + d.domain_flags = domain->domain_flags; + d.domain_type = domain->domain_type; + d.domain_trust_attribs = + domain->domain_trust_attribs; } - } + TALLOC_FREE(parent); - *num_domains = ret_count; + wcache_tdc_add_domain( &d ); + ret_count++; + } } - return result; } diff --git a/source3/winbindd/winbindd_async.c b/source3/winbindd/winbindd_async.c index 6c5d92e71b..5a350b99bc 100644 --- a/source3/winbindd/winbindd_async.c +++ b/source3/winbindd/winbindd_async.c @@ -6,17 +6,6 @@ Copyright (C) Volker Lendecke 2005 Copyright (C) Gerald Carter 2006 - The helpers always consist of three functions: - - * A request setup function that takes the necessary parameters together - with a continuation function that is to be called upon completion - - * A private continuation function that is internal only. This is to be - called by the lower-level functions in do_async(). Its only task is to - properly call the continuation function named above. - - * A worker function that is called inside the appropriate child process. - This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or @@ -37,423 +26,6 @@ #undef DBGC_CLASS #define DBGC_CLASS DBGC_WINBIND -struct do_async_state { - TALLOC_CTX *mem_ctx; - struct winbindd_request request; - struct winbindd_response response; - void (*cont)(TALLOC_CTX *mem_ctx, - bool success, - struct winbindd_response *response, - void *c, void *private_data); - void *c, *private_data; -}; - -static void do_async_recv(void *private_data, bool success) -{ - struct do_async_state *state = - talloc_get_type_abort(private_data, struct do_async_state); - - state->cont(state->mem_ctx, success, &state->response, - state->c, state->private_data); -} - -void do_async(TALLOC_CTX *mem_ctx, struct winbindd_child *child, - const struct winbindd_request *request, - void (*cont)(TALLOC_CTX *mem_ctx, bool success, - struct winbindd_response *response, - void *c, void *private_data), - void *c, void *private_data) -{ - struct do_async_state *state; - - state = TALLOC_ZERO_P(mem_ctx, struct do_async_state); - if (state == NULL) { - DEBUG(0, ("talloc failed\n")); - cont(mem_ctx, False, NULL, c, private_data); - return; - } - - state->mem_ctx = mem_ctx; - state->request = *request; - state->request.length = sizeof(state->request); - state->cont = cont; - state->c = c; - state->private_data = private_data; - - async_request(mem_ctx, child, &state->request, - &state->response, do_async_recv, state); -} - -static void do_async_domain(TALLOC_CTX *mem_ctx, struct winbindd_domain *domain, - const struct winbindd_request *request, - void (*cont)(TALLOC_CTX *mem_ctx, bool success, - struct winbindd_response *response, - void *c, void *private_data), - void *c, void *private_data) -{ - struct do_async_state *state; - - state = TALLOC_ZERO_P(mem_ctx, struct do_async_state); - if (state == NULL) { - DEBUG(0, ("talloc failed\n")); - cont(mem_ctx, False, NULL, c, private_data); - return; - } - - state->mem_ctx = mem_ctx; - state->request = *request; - state->request.length = sizeof(state->request); - state->cont = cont; - state->c = c; - state->private_data = private_data; - - async_domain_request(mem_ctx, domain, &state->request, - &state->response, do_async_recv, state); -} - -struct lookupsid_state { - DOM_SID sid; - void *caller_private_data; -}; - - -static void lookupsid_recv2(TALLOC_CTX *mem_ctx, bool success, - struct winbindd_response *response, - void *c, void *private_data) -{ - void (*cont)(void *priv, bool succ, const char *dom_name, - const char *name, enum lsa_SidType type) = - (void (*)(void *, bool, const char *, const char *, - enum lsa_SidType))c; - struct lookupsid_state *s = talloc_get_type_abort(private_data, - struct lookupsid_state); - - if (!success) { - DEBUG(5, ("Could not trigger lookupsid\n")); - cont(s->caller_private_data, False, NULL, NULL, SID_NAME_UNKNOWN); - return; - } - - if (response->result != WINBINDD_OK) { - DEBUG(5, ("lookupsid (forest root) returned an error\n")); - cont(s->caller_private_data, False, NULL, NULL, SID_NAME_UNKNOWN); - return; - } - - cont(s->caller_private_data, True, response->data.name.dom_name, - response->data.name.name, - (enum lsa_SidType)response->data.name.type); -} - -static void lookupsid_recv(TALLOC_CTX *mem_ctx, bool success, - struct winbindd_response *response, - void *c, void *private_data) -{ - void (*cont)(void *priv, bool succ, const char *dom_name, - const char *name, enum lsa_SidType type) = - (void (*)(void *, bool, const char *, const char *, - enum lsa_SidType))c; - struct lookupsid_state *s = talloc_get_type_abort(private_data, - struct lookupsid_state); - - if (!success) { - DEBUG(5, ("Could not trigger lookupsid\n")); - cont(s->caller_private_data, False, NULL, NULL, SID_NAME_UNKNOWN); - return; - } - - if (response->result != WINBINDD_OK) { - /* Try again using the forest root */ - struct winbindd_domain *root_domain = find_root_domain(); - struct winbindd_request request; - - if ( !root_domain ) { - DEBUG(5,("lookupsid_recv: unable to determine forest root\n")); - cont(s->caller_private_data, False, NULL, NULL, SID_NAME_UNKNOWN); - return; - } - - ZERO_STRUCT(request); - request.cmd = WINBINDD_LOOKUPSID; - sid_to_fstring(request.data.sid, &s->sid); - - do_async_domain(mem_ctx, root_domain, &request, lookupsid_recv2, - (void *)cont, s); - - return; - } - - cont(s->caller_private_data, True, response->data.name.dom_name, - response->data.name.name, - (enum lsa_SidType)response->data.name.type); -} - -void winbindd_lookupsid_async(TALLOC_CTX *mem_ctx, const DOM_SID *sid, - void (*cont)(void *private_data, bool success, - const char *dom_name, - const char *name, - enum lsa_SidType type), - void *private_data) -{ - struct winbindd_domain *domain; - struct winbindd_request request; - struct lookupsid_state *s; - - domain = find_lookup_domain_from_sid(sid); - if (domain == NULL) { - DEBUG(5, ("Could not find domain for sid %s\n", - sid_string_dbg(sid))); - cont(private_data, False, NULL, NULL, SID_NAME_UNKNOWN); - return; - } - - ZERO_STRUCT(request); - request.cmd = WINBINDD_LOOKUPSID; - sid_to_fstring(request.data.sid, sid); - - if ( (s = TALLOC_ZERO_P(mem_ctx, struct lookupsid_state)) == NULL ) { - DEBUG(0, ("winbindd_lookupsid_async: talloc failed\n")); - cont(private_data, False, NULL, NULL, SID_NAME_UNKNOWN); - return; - } - - sid_copy( &s->sid, sid ); - s->caller_private_data = private_data; - - do_async_domain(mem_ctx, domain, &request, lookupsid_recv, - (void *)cont, s); -} - -enum winbindd_result winbindd_dual_lookupsid(struct winbindd_domain *domain, - struct winbindd_cli_state *state) -{ - enum lsa_SidType type; - DOM_SID sid; - char *name; - char *dom_name; - - /* Ensure null termination */ - state->request->data.sid[sizeof(state->request->data.sid)-1]='\0'; - - DEBUG(3, ("[%5lu]: lookupsid %s\n", (unsigned long)state->pid, - state->request->data.sid)); - - /* Lookup sid from PDC using lsa_lookup_sids() */ - - if (!string_to_sid(&sid, state->request->data.sid)) { - DEBUG(5, ("%s not a SID\n", state->request->data.sid)); - return WINBINDD_ERROR; - } - - /* Lookup the sid */ - - if (!winbindd_lookup_name_by_sid(state->mem_ctx, domain, &sid, - &dom_name, &name, &type)) - { - TALLOC_FREE(dom_name); - TALLOC_FREE(name); - return WINBINDD_ERROR; - } - - fstrcpy(state->response->data.name.dom_name, dom_name); - fstrcpy(state->response->data.name.name, name); - state->response->data.name.type = type; - - TALLOC_FREE(dom_name); - TALLOC_FREE(name); - return WINBINDD_OK; -} - -/******************************************************************** - This is the second callback after contacting the forest root -********************************************************************/ - -struct lookupname_state { - char *dom_name; - char *name; - void *caller_private_data; -}; - - -static void lookupname_recv2(TALLOC_CTX *mem_ctx, bool success, - struct winbindd_response *response, - void *c, void *private_data) -{ - void (*cont)(void *priv, bool succ, const DOM_SID *sid, - enum lsa_SidType type) = - (void (*)(void *, bool, const DOM_SID *, enum lsa_SidType))c; - DOM_SID sid; - struct lookupname_state *s = talloc_get_type_abort( private_data, - struct lookupname_state ); - - if (!success) { - DEBUG(5, ("Could not trigger lookup_name\n")); - cont(s->caller_private_data, False, NULL, SID_NAME_UNKNOWN); - return; - } - - if (response->result != WINBINDD_OK) { - DEBUG(5, ("lookup_name returned an error\n")); - cont(s->caller_private_data, False, NULL, SID_NAME_UNKNOWN); - return; - } - - if (!string_to_sid(&sid, response->data.sid.sid)) { - DEBUG(0, ("Could not convert string %s to sid\n", - response->data.sid.sid)); - cont(s->caller_private_data, False, NULL, SID_NAME_UNKNOWN); - return; - } - - cont(s->caller_private_data, True, &sid, - (enum lsa_SidType)response->data.sid.type); -} - -/******************************************************************** - This is the first callback after contacting our own domain -********************************************************************/ - -static void lookupname_recv(TALLOC_CTX *mem_ctx, bool success, - struct winbindd_response *response, - void *c, void *private_data) -{ - void (*cont)(void *priv, bool succ, const DOM_SID *sid, - enum lsa_SidType type) = - (void (*)(void *, bool, const DOM_SID *, enum lsa_SidType))c; - DOM_SID sid; - struct lookupname_state *s = talloc_get_type_abort( private_data, - struct lookupname_state ); - - if (!success) { - DEBUG(5, ("lookupname_recv: lookup_name() failed!\n")); - cont(s->caller_private_data, False, NULL, SID_NAME_UNKNOWN); - return; - } - - if (response->result != WINBINDD_OK) { - /* Try again using the forest root */ - struct winbindd_domain *root_domain = find_root_domain(); - struct winbindd_request request; - - if ( !root_domain ) { - DEBUG(5,("lookupname_recv: unable to determine forest root\n")); - cont(s->caller_private_data, False, NULL, SID_NAME_UNKNOWN); - return; - } - - ZERO_STRUCT(request); - request.cmd = WINBINDD_LOOKUPNAME; - - fstrcpy( request.data.name.dom_name, s->dom_name ); - fstrcpy( request.data.name.name, s->name ); - - do_async_domain(mem_ctx, root_domain, &request, lookupname_recv2, - (void *)cont, s); - - return; - } - - if (!string_to_sid(&sid, response->data.sid.sid)) { - DEBUG(0, ("Could not convert string %s to sid\n", - response->data.sid.sid)); - cont(s->caller_private_data, False, NULL, SID_NAME_UNKNOWN); - return; - } - - cont(s->caller_private_data, True, &sid, - (enum lsa_SidType)response->data.sid.type); -} - -/******************************************************************** - The lookup name call first contacts a DC in its own domain - and fallbacks to contact a DC if the forest in our domain doesn't - know the name. -********************************************************************/ - -void winbindd_lookupname_async(TALLOC_CTX *mem_ctx, - const char *dom_name, const char *name, - void (*cont)(void *private_data, bool success, - const DOM_SID *sid, - enum lsa_SidType type), - enum winbindd_cmd orig_cmd, - void *private_data) -{ - struct winbindd_request request; - struct winbindd_domain *domain; - struct lookupname_state *s; - - domain = find_lookup_domain_from_name(dom_name); - if (domain == NULL) { - DEBUG(5, ("Could not find domain for name '%s'\n", dom_name)); - cont(private_data, False, NULL, SID_NAME_UNKNOWN); - return; - } - - ZERO_STRUCT(request); - request.cmd = WINBINDD_LOOKUPNAME; - request.original_cmd = orig_cmd; - fstrcpy(request.data.name.dom_name, dom_name); - fstrcpy(request.data.name.name, name); - - if ( (s = TALLOC_ZERO_P(mem_ctx, struct lookupname_state)) == NULL ) { - DEBUG(0, ("winbindd_lookupname_async: talloc failed\n")); - cont(private_data, False, NULL, SID_NAME_UNKNOWN); - return; - } - - s->dom_name = talloc_strdup( s, dom_name ); - s->name = talloc_strdup( s, name ); - if (!s->dom_name || !s->name) { - cont(private_data, False, NULL, SID_NAME_UNKNOWN); - return; - } - - s->caller_private_data = private_data; - - do_async_domain(mem_ctx, domain, &request, lookupname_recv, - (void *)cont, s); -} - -enum winbindd_result winbindd_dual_lookupname(struct winbindd_domain *domain, - struct winbindd_cli_state *state) -{ - enum lsa_SidType type; - char *name_domain, *name_user; - DOM_SID sid; - char *p; - - /* Ensure null termination */ - state->request->data.name.dom_name[sizeof(state->request->data.name.dom_name)-1]='\0'; - - /* Ensure null termination */ - state->request->data.name.name[sizeof(state->request->data.name.name)-1]='\0'; - - /* cope with the name being a fully qualified name */ - p = strstr(state->request->data.name.name, lp_winbind_separator()); - if (p) { - *p = 0; - name_domain = state->request->data.name.name; - name_user = p+1; - } else { - name_domain = state->request->data.name.dom_name; - name_user = state->request->data.name.name; - } - - DEBUG(3, ("[%5lu]: lookupname %s%s%s\n", (unsigned long)state->pid, - name_domain, lp_winbind_separator(), name_user)); - - /* Lookup name from DC using lsa_lookup_names() */ - if (!winbindd_lookup_sid_by_name(state->mem_ctx, state->request->original_cmd, domain, name_domain, - name_user, &sid, &type)) { - return WINBINDD_ERROR; - } - - sid_to_fstring(state->response->data.sid.sid, &sid); - state->response->data.sid.type = type; - - return WINBINDD_OK; -} - bool print_sidlist(TALLOC_CTX *mem_ctx, const DOM_SID *sids, size_t num_sids, char **result, ssize_t *len) { @@ -514,127 +86,6 @@ bool parse_sidlist(TALLOC_CTX *mem_ctx, const char *sidstr, return True; } -static void getsidaliases_recv(TALLOC_CTX *mem_ctx, bool success, - struct winbindd_response *response, - void *c, void *private_data) -{ - void (*cont)(void *priv, bool succ, - DOM_SID *aliases, size_t num_aliases) = - (void (*)(void *, bool, DOM_SID *, size_t))c; - char *aliases_str; - DOM_SID *sids = NULL; - size_t num_sids = 0; - - if (!success) { - DEBUG(5, ("Could not trigger getsidaliases\n")); - cont(private_data, success, NULL, 0); - return; - } - - if (response->result != WINBINDD_OK) { - DEBUG(5, ("getsidaliases returned an error\n")); - cont(private_data, False, NULL, 0); - return; - } - - aliases_str = (char *)response->extra_data.data; - - if (aliases_str == NULL) { - DEBUG(10, ("getsidaliases return 0 SIDs\n")); - cont(private_data, True, NULL, 0); - return; - } - - if (!parse_sidlist(mem_ctx, aliases_str, &sids, &num_sids)) { - DEBUG(0, ("Could not parse sids\n")); - cont(private_data, False, NULL, 0); - return; - } - - cont(private_data, True, sids, num_sids); -} - -void winbindd_getsidaliases_async(struct winbindd_domain *domain, - TALLOC_CTX *mem_ctx, - const DOM_SID *sids, size_t num_sids, - void (*cont)(void *private_data, - bool success, - const DOM_SID *aliases, - size_t num_aliases), - void *private_data) -{ - struct winbindd_request request; - char *sidstr = NULL; - ssize_t len; - - if (num_sids == 0) { - cont(private_data, True, NULL, 0); - return; - } - - if (!print_sidlist(mem_ctx, sids, num_sids, &sidstr, &len)) { - cont(private_data, False, NULL, 0); - return; - } - - ZERO_STRUCT(request); - request.cmd = WINBINDD_DUAL_GETSIDALIASES; - request.extra_len = len; - request.extra_data.data = sidstr; - - do_async_domain(mem_ctx, domain, &request, getsidaliases_recv, - (void *)cont, private_data); -} - -static void query_user_recv(TALLOC_CTX *mem_ctx, bool success, - struct winbindd_response *response, - void *c, void *private_data) -{ - void (*cont)(void *priv, bool succ, const char *acct_name, - const char *full_name, const char *homedir, - const char *shell, uint32 gid, uint32 group_rid) = - (void (*)(void *, bool, const char *, const char *, - const char *, const char *, uint32, uint32))c; - - if (!success) { - DEBUG(5, ("Could not trigger query_user\n")); - cont(private_data, False, NULL, NULL, NULL, NULL, -1, -1); - return; - } - - if (response->result != WINBINDD_OK) { - DEBUG(5, ("query_user returned an error\n")); - cont(private_data, False, NULL, NULL, NULL, NULL, -1, -1); - return; - } - - cont(private_data, True, response->data.user_info.acct_name, - response->data.user_info.full_name, - response->data.user_info.homedir, - response->data.user_info.shell, - response->data.user_info.primary_gid, - response->data.user_info.group_rid); -} - -void query_user_async(TALLOC_CTX *mem_ctx, struct winbindd_domain *domain, - const DOM_SID *sid, - void (*cont)(void *private_data, bool success, - const char *acct_name, - const char *full_name, - const char *homedir, - const char *shell, - gid_t gid, - uint32 group_rid), - void *private_data) -{ - struct winbindd_request request; - ZERO_STRUCT(request); - request.cmd = WINBINDD_DUAL_USERINFO; - sid_to_fstring(request.data.sid, sid); - do_async_domain(mem_ctx, domain, &request, query_user_recv, - (void *)cont, private_data); -} - enum winbindd_result winbindd_dual_ping(struct winbindd_domain *domain, struct winbindd_cli_state *state) { diff --git a/source3/winbindd/winbindd_cache.c b/source3/winbindd/winbindd_cache.c index c4bc936a5d..68972dd18d 100644 --- a/source3/winbindd/winbindd_cache.c +++ b/source3/winbindd/winbindd_cache.c @@ -514,7 +514,7 @@ static void refresh_sequence_number(struct winbindd_domain *domain, bool force) time_t t = time(NULL); unsigned cache_time = lp_winbind_cache_time(); - if ( IS_DOMAIN_OFFLINE(domain) ) { + if (is_domain_offline(domain)) { return; } @@ -1380,6 +1380,7 @@ static NTSTATUS query_user_list(struct winbindd_domain *domain, struct cache_entry *centry = NULL; NTSTATUS status; unsigned int i, retry; + bool old_status = domain->online; if (!cache->tdb) goto do_query; @@ -1388,6 +1389,7 @@ static NTSTATUS query_user_list(struct winbindd_domain *domain, if (!centry) goto do_query; +do_fetch_cache: *num_entries = centry_uint32(centry); if (*num_entries == 0) @@ -1448,12 +1450,44 @@ do_query: "connection cache\n")); invalidate_cm_connection(&domain->conn); } + if (NT_STATUS_EQUAL(status, NT_STATUS_IO_TIMEOUT) || + NT_STATUS_EQUAL(status, NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND)) { + if (!domain->internal && old_status) { + set_domain_offline(domain); + } + /* store partial response. */ + if (*num_entries > 0) { + /* + * humm, what about the status used for cache? + * Should it be NT_STATUS_OK? + */ + break; + } + /* + * domain is offline now, and there is no user entries, + * try to fetch from cache again. + */ + if (cache->tdb && !domain->online && !domain->internal && old_status) { + centry = wcache_fetch(cache, domain, "UL/%s", domain->name); + /* partial response... */ + if (!centry) { + goto skip_save; + } else { + goto do_fetch_cache; + } + } else { + goto skip_save; + } + } } while (NT_STATUS_V(status) == NT_STATUS_V(NT_STATUS_UNSUCCESSFUL) && (retry++ < 5)); /* and save it */ refresh_sequence_number(domain, false); + if (!NT_STATUS_IS_OK(status)) { + return status; + } centry = centry_start(domain, status); if (!centry) goto skip_save; @@ -1497,7 +1531,9 @@ static NTSTATUS enum_dom_groups(struct winbindd_domain *domain, struct cache_entry *centry = NULL; NTSTATUS status; unsigned int i; + bool old_status; + old_status = domain->online; if (!cache->tdb) goto do_query; @@ -1505,6 +1541,7 @@ static NTSTATUS enum_dom_groups(struct winbindd_domain *domain, if (!centry) goto do_query; +do_fetch_cache: *num_entries = centry_uint32(centry); if (*num_entries == 0) @@ -1543,8 +1580,26 @@ do_query: status = domain->backend->enum_dom_groups(domain, mem_ctx, num_entries, info); + if (NT_STATUS_EQUAL(status, NT_STATUS_IO_TIMEOUT) || + NT_STATUS_EQUAL(status, NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND)) { + if (!domain->internal && old_status) { + set_domain_offline(domain); + } + if (cache->tdb && + !domain->online && + !domain->internal && + old_status) { + centry = wcache_fetch(cache, domain, "GL/%s/domain", domain->name); + if (centry) { + goto do_fetch_cache; + } + } + } /* and save it */ refresh_sequence_number(domain, false); + if (!NT_STATUS_IS_OK(status)) { + return status; + } centry = centry_start(domain, status); if (!centry) goto skip_save; @@ -1571,7 +1626,9 @@ static NTSTATUS enum_local_groups(struct winbindd_domain *domain, struct cache_entry *centry = NULL; NTSTATUS status; unsigned int i; + bool old_status; + old_status = domain->online; if (!cache->tdb) goto do_query; @@ -1579,6 +1636,7 @@ static NTSTATUS enum_local_groups(struct winbindd_domain *domain, if (!centry) goto do_query; +do_fetch_cache: *num_entries = centry_uint32(centry); if (*num_entries == 0) @@ -1627,8 +1685,26 @@ do_query: status = domain->backend->enum_local_groups(domain, mem_ctx, num_entries, info); + if (NT_STATUS_EQUAL(status, NT_STATUS_IO_TIMEOUT) || + NT_STATUS_EQUAL(status, NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND)) { + if (!domain->internal && old_status) { + set_domain_offline(domain); + } + if (cache->tdb && + !domain->internal && + !domain->online && + old_status) { + centry = wcache_fetch(cache, domain, "GL/%s/local", domain->name); + if (centry) { + goto do_fetch_cache; + } + } + } /* and save it */ refresh_sequence_number(domain, false); + if (!NT_STATUS_IS_OK(status)) { + return status; + } centry = centry_start(domain, status); if (!centry) goto skip_save; @@ -1694,6 +1770,9 @@ static NTSTATUS name_to_sid(struct winbindd_domain *domain, enum lsa_SidType *type) { NTSTATUS status; + bool old_status; + + old_status = domain->online; status = wcache_name_to_sid(domain, domain_name, name, sid, type); if (!NT_STATUS_EQUAL(status, NT_STATUS_NOT_FOUND)) { @@ -1719,6 +1798,19 @@ static NTSTATUS name_to_sid(struct winbindd_domain *domain, status = domain->backend->name_to_sid(domain, mem_ctx, domain_name, name, flags, sid, type); + if (NT_STATUS_EQUAL(status, NT_STATUS_IO_TIMEOUT) || + NT_STATUS_EQUAL(status, NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND)) { + if (!domain->internal && old_status) { + set_domain_offline(domain); + } + if (!domain->internal && + !domain->online && + old_status) { + NTSTATUS cache_status; + cache_status = wcache_name_to_sid(domain, domain_name, name, sid, type); + return cache_status; + } + } /* and save it */ refresh_sequence_number(domain, false); @@ -1789,7 +1881,9 @@ static NTSTATUS sid_to_name(struct winbindd_domain *domain, enum lsa_SidType *type) { NTSTATUS status; + bool old_status; + old_status = domain->online; status = wcache_sid_to_name(domain, sid, mem_ctx, domain_name, name, type); if (!NT_STATUS_EQUAL(status, NT_STATUS_NOT_FOUND)) { @@ -1815,8 +1909,25 @@ static NTSTATUS sid_to_name(struct winbindd_domain *domain, status = domain->backend->sid_to_name(domain, mem_ctx, sid, domain_name, name, type); + if (NT_STATUS_EQUAL(status, NT_STATUS_IO_TIMEOUT) || + NT_STATUS_EQUAL(status, NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND)) { + if (!domain->internal && old_status) { + set_domain_offline(domain); + } + if (!domain->internal && + !domain->online && + old_status) { + NTSTATUS cache_status; + cache_status = wcache_sid_to_name(domain, sid, mem_ctx, + domain_name, name, type); + return cache_status; + } + } /* and save it */ refresh_sequence_number(domain, false); + if (!NT_STATUS_IS_OK(status)) { + return status; + } wcache_save_sid_to_name(domain, status, sid, *domain_name, *name, *type); /* We can't save the name to sid mapping here, as with sid history a @@ -1839,7 +1950,9 @@ static NTSTATUS rids_to_names(struct winbindd_domain *domain, NTSTATUS result = NT_STATUS_UNSUCCESSFUL; bool have_mapped; bool have_unmapped; + bool old_status; + old_status = domain->online; *domain_name = NULL; *names = NULL; *types = NULL; @@ -1924,6 +2037,73 @@ static NTSTATUS rids_to_names(struct winbindd_domain *domain, rids, num_rids, domain_name, names, types); + if (NT_STATUS_EQUAL(result, NT_STATUS_IO_TIMEOUT) || + NT_STATUS_EQUAL(result, NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND)) { + if (!domain->internal && old_status) { + set_domain_offline(domain); + } + if (cache->tdb && + !domain->internal && + !domain->online && + old_status) { + have_mapped = have_unmapped = false; + + for (i=0; i<num_rids; i++) { + DOM_SID sid; + struct cache_entry *centry; + fstring tmp; + + if (!sid_compose(&sid, domain_sid, rids[i])) { + result = NT_STATUS_INTERNAL_ERROR; + goto error; + } + + centry = wcache_fetch(cache, domain, "SN/%s", + sid_to_fstring(tmp, &sid)); + if (!centry) { + (*types)[i] = SID_NAME_UNKNOWN; + (*names)[i] = talloc_strdup(*names, ""); + continue; + } + + (*types)[i] = SID_NAME_UNKNOWN; + (*names)[i] = talloc_strdup(*names, ""); + + if (NT_STATUS_IS_OK(centry->status)) { + char *dom; + have_mapped = true; + (*types)[i] = (enum lsa_SidType)centry_uint32(centry); + + dom = centry_string(centry, mem_ctx); + if (*domain_name == NULL) { + *domain_name = dom; + } else { + talloc_free(dom); + } + + (*names)[i] = centry_string(centry, *names); + + } else if (NT_STATUS_EQUAL(centry->status, NT_STATUS_NONE_MAPPED)) { + have_unmapped = true; + + } else { + /* something's definitely wrong */ + result = centry->status; + goto error; + } + + centry_free(centry); + } + + if (!have_mapped) { + return NT_STATUS_NONE_MAPPED; + } + if (!have_unmapped) { + return NT_STATUS_OK; + } + return STATUS_SOME_UNMAPPED; + } + } /* None of the queried rids has been found so save all negative entries */ @@ -2046,7 +2226,9 @@ static NTSTATUS query_user(struct winbindd_domain *domain, struct wbint_userinfo *info) { NTSTATUS status; + bool old_status; + old_status = domain->online; status = wcache_query_user(domain, mem_ctx, user_sid, info); if (!NT_STATUS_EQUAL(status, NT_STATUS_NOT_FOUND)) { return status; @@ -2064,8 +2246,24 @@ static NTSTATUS query_user(struct winbindd_domain *domain, status = domain->backend->query_user(domain, mem_ctx, user_sid, info); + if (NT_STATUS_EQUAL(status, NT_STATUS_IO_TIMEOUT) || + NT_STATUS_EQUAL(status, NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND)) { + if (!domain->internal && old_status) { + set_domain_offline(domain); + } + if (!domain->internal && + !domain->online && + old_status) { + NTSTATUS cache_status; + cache_status = wcache_query_user(domain, mem_ctx, user_sid, info); + return cache_status; + } + } /* and save it */ refresh_sequence_number(domain, false); + if (!NT_STATUS_IS_OK(status)) { + return status; + } wcache_save_user(domain, status, info); return status; @@ -2140,7 +2338,9 @@ static NTSTATUS lookup_usergroups(struct winbindd_domain *domain, NTSTATUS status; unsigned int i; fstring sid_string; + bool old_status; + old_status = domain->online; status = wcache_lookup_usergroups(domain, mem_ctx, user_sid, num_groups, user_gids); if (!NT_STATUS_EQUAL(status, NT_STATUS_NOT_FOUND)) { @@ -2160,11 +2360,28 @@ static NTSTATUS lookup_usergroups(struct winbindd_domain *domain, status = domain->backend->lookup_usergroups(domain, mem_ctx, user_sid, num_groups, user_gids); + if (NT_STATUS_EQUAL(status, NT_STATUS_IO_TIMEOUT) || + NT_STATUS_EQUAL(status, NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND)) { + if (!domain->internal && old_status) { + set_domain_offline(domain); + } + if (!domain->internal && + !domain->online && + old_status) { + NTSTATUS cache_status; + cache_status = wcache_lookup_usergroups(domain, mem_ctx, user_sid, + num_groups, user_gids); + return cache_status; + } + } if ( NT_STATUS_EQUAL(status, NT_STATUS_SYNCHRONIZATION_REQUIRED) ) goto skip_save; /* and save it */ refresh_sequence_number(domain, false); + if (!NT_STATUS_IS_OK(status)) { + return status; + } centry = centry_start(domain, status); if (!centry) goto skip_save; @@ -2272,7 +2489,9 @@ static NTSTATUS lookup_useraliases(struct winbindd_domain *domain, NTSTATUS status; char *sidlist; int i; + bool old_status; + old_status = domain->online; status = wcache_lookup_useraliases(domain, mem_ctx, num_sids, sids, num_aliases, alias_rids); if (!NT_STATUS_EQUAL(status, NT_STATUS_NOT_FOUND)) { @@ -2297,8 +2516,25 @@ static NTSTATUS lookup_useraliases(struct winbindd_domain *domain, num_sids, sids, num_aliases, alias_rids); + if (NT_STATUS_EQUAL(status, NT_STATUS_IO_TIMEOUT) || + NT_STATUS_EQUAL(status, NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND)) { + if (!domain->internal && old_status) { + set_domain_offline(domain); + } + if (!domain->internal && + !domain->online && + old_status) { + NTSTATUS cache_status; + cache_status = wcache_lookup_useraliases(domain, mem_ctx, num_sids, + sids, num_aliases, alias_rids); + return cache_status; + } + } /* and save it */ refresh_sequence_number(domain, false); + if (!NT_STATUS_IS_OK(status)) { + return status; + } centry = centry_start(domain, status); if (!centry) goto skip_save; @@ -2389,7 +2625,9 @@ static NTSTATUS lookup_groupmem(struct winbindd_domain *domain, NTSTATUS status; unsigned int i; fstring sid_string; + bool old_status; + old_status = domain->online; status = wcache_lookup_groupmem(domain, mem_ctx, group_sid, num_names, sid_mem, names, name_types); if (!NT_STATUS_EQUAL(status, NT_STATUS_NOT_FOUND)) { @@ -2413,8 +2651,26 @@ static NTSTATUS lookup_groupmem(struct winbindd_domain *domain, type, num_names, sid_mem, names, name_types); + if (NT_STATUS_EQUAL(status, NT_STATUS_IO_TIMEOUT) || + NT_STATUS_EQUAL(status, NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND)) { + if (!domain->internal && old_status) { + set_domain_offline(domain); + } + if (!domain->internal && + !domain->online && + old_status) { + NTSTATUS cache_status; + cache_status = wcache_lookup_groupmem(domain, mem_ctx, group_sid, + num_names, sid_mem, names, + name_types); + return cache_status; + } + } /* and save it */ refresh_sequence_number(domain, false); + if (!NT_STATUS_IS_OK(status)) { + return status; + } centry = centry_start(domain, status); if (!centry) goto skip_save; @@ -2446,63 +2702,74 @@ static NTSTATUS sequence_number(struct winbindd_domain *domain, uint32 *seq) * Guenther */ static NTSTATUS trusted_domains(struct winbindd_domain *domain, TALLOC_CTX *mem_ctx, - uint32 *num_domains, - char ***names, - char ***alt_names, - DOM_SID **dom_sids) + struct netr_DomainTrustList *trusts) { - struct winbind_cache *cache = get_cache(domain); - struct cache_entry *centry = NULL; NTSTATUS status; + struct winbind_cache *cache; + struct winbindd_tdc_domain *dom_list = NULL; + size_t num_domains = 0; + bool retval = false; int i; + bool old_status; - if (!cache->tdb) + old_status = domain->online; + trusts->count = 0; + trusts->array = NULL; + if (domain->online) { goto do_query; - - centry = wcache_fetch(cache, domain, "TRUSTDOMS/%s", domain->name); - - if (!centry) { - goto do_query; } - *num_domains = centry_uint32(centry); + cache = get_cache(domain); + if (!cache || !cache->tdb) { + goto do_query; + } - if (*num_domains) { - (*names) = TALLOC_ARRAY(mem_ctx, char *, *num_domains); - (*alt_names) = TALLOC_ARRAY(mem_ctx, char *, *num_domains); - (*dom_sids) = TALLOC_ARRAY(mem_ctx, DOM_SID, *num_domains); + retval = wcache_tdc_fetch_list(&dom_list, &num_domains); + if (!retval || !num_domains || !dom_list) { + TALLOC_FREE(dom_list); + goto do_query; + } - if (! (*dom_sids) || ! (*names) || ! (*alt_names)) { - smb_panic_fn("trusted_domains out of memory"); - } - } else { - (*names) = NULL; - (*alt_names) = NULL; - (*dom_sids) = NULL; +do_fetch_cache: + trusts->array = TALLOC_ZERO_ARRAY(mem_ctx, struct netr_DomainTrust, num_domains); + if (!trusts->array) { + TALLOC_FREE(dom_list); + return NT_STATUS_NO_MEMORY; } - for (i=0; i<(*num_domains); i++) { - (*names)[i] = centry_string(centry, mem_ctx); - (*alt_names)[i] = centry_string(centry, mem_ctx); - if (!centry_sid(centry, &(*dom_sids)[i])) { - sid_copy(&(*dom_sids)[i], &global_sid_NULL); + for (i = 0; i < num_domains; i++) { + struct netr_DomainTrust *trust; + struct dom_sid *sid; + struct winbindd_domain *dom; + + dom = find_domain_from_name_noinit(dom_list[i].domain_name); + if (dom && dom->internal) { + continue; } - } - status = centry->status; + trust = &trusts->array[trusts->count]; + trust->netbios_name = talloc_strdup(trusts->array, dom_list[i].domain_name); + trust->dns_name = talloc_strdup(trusts->array, dom_list[i].dns_name); + sid = talloc(trusts->array, struct dom_sid); + if (!trust->netbios_name || !trust->dns_name || + !sid) { + TALLOC_FREE(dom_list); + TALLOC_FREE(trusts->array); + return NT_STATUS_NO_MEMORY; + } - DEBUG(10,("trusted_domains: [Cached] - cached info for domain %s (%d trusts) status: %s\n", - domain->name, *num_domains, nt_errstr(status) )); + trust->trust_flags = dom_list[i].trust_flags; + trust->trust_attributes = dom_list[i].trust_attribs; + trust->trust_type = dom_list[i].trust_type; + sid_copy(sid, &dom_list[i].sid); + trust->sid = sid; + trusts->count++; + } - centry_free(centry); - return status; + TALLOC_FREE(dom_list); + return NT_STATUS_OK; do_query: - (*num_domains) = 0; - (*dom_sids) = NULL; - (*names) = NULL; - (*alt_names) = NULL; - /* Return status value returned by seq number check */ if (!NT_STATUS_IS_OK(domain->last_status)) @@ -2511,9 +2778,24 @@ do_query: DEBUG(10,("trusted_domains: [Cached] - doing backend query for info for domain %s\n", domain->name )); - status = domain->backend->trusted_domains(domain, mem_ctx, num_domains, - names, alt_names, dom_sids); + status = domain->backend->trusted_domains(domain, mem_ctx, trusts); + if (NT_STATUS_EQUAL(status, NT_STATUS_IO_TIMEOUT) || + NT_STATUS_EQUAL(status, NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND)) { + if (!domain->internal && old_status) { + set_domain_offline(domain); + } + if (!domain->internal && + !domain->online && + old_status) { + retval = wcache_tdc_fetch_list(&dom_list, &num_domains); + if (retval && num_domains && dom_list) { + TALLOC_FREE(trusts->array); + trusts->count = 0; + goto do_fetch_cache; + } + } + } /* no trusts gives NT_STATUS_NO_MORE_ENTRIES resetting to NT_STATUS_OK * so that the generic centry handling still applies correctly - * Guenther*/ @@ -2521,33 +2803,6 @@ do_query: if (!NT_STATUS_IS_ERR(status)) { status = NT_STATUS_OK; } - - -#if 0 /* Disabled as we want the trust dom list to be managed by - the main parent and always to make the query. --jerry */ - - /* and save it */ - refresh_sequence_number(domain, false); - - centry = centry_start(domain, status); - if (!centry) - goto skip_save; - - centry_put_uint32(centry, *num_domains); - - for (i=0; i<(*num_domains); i++) { - centry_put_string(centry, (*names)[i]); - centry_put_string(centry, (*alt_names)[i]); - centry_put_sid(centry, &(*dom_sids)[i]); - } - - centry_end(centry, "TRUSTDOMS/%s", domain->name); - - centry_free(centry); - -skip_save: -#endif - return status; } @@ -2559,7 +2814,9 @@ static NTSTATUS lockout_policy(struct winbindd_domain *domain, struct winbind_cache *cache = get_cache(domain); struct cache_entry *centry = NULL; NTSTATUS status; + bool old_status; + old_status = domain->online; if (!cache->tdb) goto do_query; @@ -2568,6 +2825,7 @@ static NTSTATUS lockout_policy(struct winbindd_domain *domain, if (!centry) goto do_query; +do_fetch_cache: policy->lockout_duration = centry_nttime(centry); policy->lockout_window = centry_nttime(centry); policy->lockout_threshold = centry_uint16(centry); @@ -2593,8 +2851,26 @@ do_query: status = domain->backend->lockout_policy(domain, mem_ctx, policy); + if (NT_STATUS_EQUAL(status, NT_STATUS_IO_TIMEOUT) || + NT_STATUS_EQUAL(status, NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND)) { + if (!domain->internal && old_status) { + set_domain_offline(domain); + } + if (cache->tdb && + !domain->internal && + !domain->online && + old_status) { + centry = wcache_fetch(cache, domain, "LOC_POL/%s", domain->name); + if (centry) { + goto do_fetch_cache; + } + } + } /* and save it */ refresh_sequence_number(domain, false); + if (!NT_STATUS_IS_OK(status)) { + return status; + } wcache_save_lockout_policy(domain, status, policy); return status; @@ -2608,7 +2884,9 @@ static NTSTATUS password_policy(struct winbindd_domain *domain, struct winbind_cache *cache = get_cache(domain); struct cache_entry *centry = NULL; NTSTATUS status; + bool old_status; + old_status = domain->online; if (!cache->tdb) goto do_query; @@ -2617,6 +2895,7 @@ static NTSTATUS password_policy(struct winbindd_domain *domain, if (!centry) goto do_query; +do_fetch_cache: policy->min_password_length = centry_uint16(centry); policy->password_history_length = centry_uint16(centry); policy->password_properties = centry_uint32(centry); @@ -2644,11 +2923,27 @@ do_query: status = domain->backend->password_policy(domain, mem_ctx, policy); + if (NT_STATUS_EQUAL(status, NT_STATUS_IO_TIMEOUT) || + NT_STATUS_EQUAL(status, NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND)) { + if (!domain->internal && old_status) { + set_domain_offline(domain); + } + if (cache->tdb && + !domain->internal && + !domain->online && + old_status) { + centry = wcache_fetch(cache, domain, "PWD_POL/%s", domain->name); + if (centry) { + goto do_fetch_cache; + } + } + } /* and save it */ refresh_sequence_number(domain, false); - if (NT_STATUS_IS_OK(status)) { - wcache_save_password_policy(domain, status, policy); + if (!NT_STATUS_IS_OK(status)) { + return status; } + wcache_save_password_policy(domain, status, policy); return status; } @@ -3557,34 +3852,6 @@ static int validate_nss_na(TALLOC_CTX *mem_ctx, const char *keystr, return 0; } -static int validate_trustdoms(TALLOC_CTX *mem_ctx, const char *keystr, TDB_DATA dbuf, - struct tdb_validation_status *state) -{ - struct cache_entry *centry = create_centry_validate(keystr, dbuf, state); - int32 num_domains, i; - - if (!centry) { - return 1; - } - - num_domains = centry_uint32(centry); - - for (i=0; i< num_domains; i++) { - DOM_SID sid; - (void)centry_string(centry, mem_ctx); - (void)centry_string(centry, mem_ctx); - (void)centry_sid(centry, &sid); - } - - centry_free(centry); - - if (!(state->success)) { - return 1; - } - DEBUG(10,("validate_trustdoms: %s ok\n", keystr)); - return 0; -} - static int validate_trustdomcache(TALLOC_CTX *mem_ctx, const char *keystr, TDB_DATA dbuf, struct tdb_validation_status *state) @@ -3666,7 +3933,6 @@ struct key_val_struct { {"DR/", validate_dr}, {"DE/", validate_de}, {"NSS/PWINFO/", validate_pwinfo}, - {"TRUSTDOMS/", validate_trustdoms}, {"TRUSTDOMCACHE/", validate_trustdomcache}, {"NSS/NA/", validate_nss_na}, {"NSS/AN/", validate_nss_an}, @@ -4361,6 +4627,7 @@ static bool wcache_opnum_cacheable(uint32_t opnum) case NDR_WBINT_ALLOCATEGID: case NDR_WBINT_CHECKMACHINEACCOUNT: case NDR_WBINT_CHANGEMACHINEACCOUNT: + case NDR_WBINT_PINGDC: return false; } return true; @@ -4393,7 +4660,7 @@ bool wcache_fetch_ndr(TALLOC_CTX *mem_ctx, struct winbindd_domain *domain, goto fail; } - if (IS_DOMAIN_ONLINE(domain)) { + if (!is_domain_offline(domain)) { uint32_t entry_seqnum, dom_seqnum, last_check; if (!wcache_fetch_seqnum(domain->name, &dom_seqnum, diff --git a/source3/winbindd/winbindd_ccache_access.c b/source3/winbindd/winbindd_ccache_access.c index 86017e2215..f0c77b2a7b 100644 --- a/source3/winbindd/winbindd_ccache_access.c +++ b/source3/winbindd/winbindd_ccache_access.c @@ -6,17 +6,17 @@ Copyright (C) Robert O'Callahan 2006 Copyright (C) Jeremy Allison 2006 (minor fixes to fit into Samba and protect against integer wrap). - + This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. - + This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. - + You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/>. */ @@ -77,7 +77,7 @@ static NTSTATUS do_ntlm_auth_with_hashes(const char *username, } status = ntlmssp_set_hashes(ntlmssp_state, lm_hash, nt_hash); - + if (!NT_STATUS_IS_OK(status)) { DEBUG(1, ("Could not set hashes: %s\n", nt_errstr(status))); diff --git a/source3/winbindd/winbindd_check_machine_acct.c b/source3/winbindd/winbindd_check_machine_acct.c index 610e9edfaa..33b6d9fba4 100644 --- a/source3/winbindd/winbindd_check_machine_acct.c +++ b/source3/winbindd/winbindd_check_machine_acct.c @@ -42,7 +42,7 @@ struct tevent_req *winbindd_check_machine_acct_send(TALLOC_CTX *mem_ctx, return NULL; } - if (request->domain_name[0] == '0') { + if (request->domain_name[0] == '\0') { /* preserve old behavior, when no domain name is given */ domain = find_our_domain(); } else { diff --git a/source3/winbindd/winbindd_cm.c b/source3/winbindd/winbindd_cm.c index 36b769bf1b..479602a9b4 100644 --- a/source3/winbindd/winbindd_cm.c +++ b/source3/winbindd/winbindd_cm.c @@ -2214,7 +2214,8 @@ NTSTATUS cm_connect_lsa_tcp(struct winbindd_domain *domain, if (conn->lsa_pipe_tcp && conn->lsa_pipe_tcp->transport->transport == NCACN_IP_TCP && - conn->lsa_pipe_tcp->auth->auth_level == DCERPC_AUTH_LEVEL_PRIVACY) { + conn->lsa_pipe_tcp->auth->auth_level == DCERPC_AUTH_LEVEL_PRIVACY && + rpc_pipe_tcp_connection_ok(conn->lsa_pipe_tcp)) { goto done; } diff --git a/source3/winbindd/winbindd_domain.c b/source3/winbindd/winbindd_domain.c index ad3d6d7916..45da57e132 100644 --- a/source3/winbindd/winbindd_domain.c +++ b/source3/winbindd/winbindd_domain.c @@ -31,14 +31,6 @@ static const struct winbindd_child_dispatch_table domain_dispatch_table[] = { .struct_cmd = WINBINDD_PING, .struct_fn = winbindd_dual_ping, },{ - .name = "LOOKUPSID", - .struct_cmd = WINBINDD_LOOKUPSID, - .struct_fn = winbindd_dual_lookupsid, - },{ - .name = "LOOKUPNAME", - .struct_cmd = WINBINDD_LOOKUPNAME, - .struct_fn = winbindd_dual_lookupname, - },{ .name = "LIST_TRUSTDOM", .struct_cmd = WINBINDD_LIST_TRUSTDOM, .struct_fn = winbindd_dual_list_trusted_domains, @@ -47,10 +39,6 @@ static const struct winbindd_child_dispatch_table domain_dispatch_table[] = { .struct_cmd = WINBINDD_INIT_CONNECTION, .struct_fn = winbindd_dual_init_connection, },{ - .name = "GETDCNAME", - .struct_cmd = WINBINDD_GETDCNAME, - .struct_fn = winbindd_dual_getdcname, - },{ .name = "SHOW_SEQUENCE", .struct_cmd = WINBINDD_SHOW_SEQUENCE, .struct_fn = winbindd_dual_show_sequence, @@ -75,22 +63,6 @@ static const struct winbindd_child_dispatch_table domain_dispatch_table[] = { .struct_cmd = WINBINDD_PAM_CHAUTHTOK, .struct_fn = winbindd_dual_pam_chauthtok, },{ - .name = "DUAL_USERINFO", - .struct_cmd = WINBINDD_DUAL_USERINFO, - .struct_fn = winbindd_dual_userinfo, - },{ - .name = "GETUSERDOMGROUPS", - .struct_cmd = WINBINDD_GETUSERDOMGROUPS, - .struct_fn = winbindd_dual_getuserdomgroups, - },{ - .name = "GETSIDALIASES", - .struct_cmd = WINBINDD_DUAL_GETSIDALIASES, - .struct_fn = winbindd_dual_getsidaliases, - },{ - .name = "GETSIDALIASES", - .struct_cmd = WINBINDD_GETSIDALIASES, - .struct_fn = winbindd_dual_getsidaliases, - },{ .name = "CCACHE_NTLM_AUTH", .struct_cmd = WINBINDD_CCACHE_NTLMAUTH, .struct_fn = winbindd_dual_ccache_ntlm_auth, @@ -108,6 +80,4 @@ void setup_domain_child(struct winbindd_domain *domain, { setup_child(domain, child, domain_dispatch_table, "log.wb", domain->name); - - child->domain = domain; } diff --git a/source3/winbindd/winbindd_dual.c b/source3/winbindd/winbindd_dual.c index 376d7c7309..bccd63ffa4 100644 --- a/source3/winbindd/winbindd_dual.c +++ b/source3/winbindd/winbindd_dual.c @@ -367,85 +367,6 @@ int wb_domain_request_recv(struct tevent_req *req, TALLOC_CTX *mem_ctx, return 0; } -/* - * Machinery for async requests sent to children. You set up a - * winbindd_request, select a child to query, and issue a async_request - * call. When the request is completed, the callback function you specified is - * called back with the private pointer you gave to async_request. - */ - -struct winbindd_async_request { - struct winbindd_async_request *next, *prev; - TALLOC_CTX *mem_ctx; - struct winbindd_child *child; - struct winbindd_response *response; - void (*continuation)(void *private_data, bool success); - struct timed_event *reply_timeout_event; - pid_t child_pid; /* pid of the child we're waiting on. Used to detect - a restart of the child (child->pid != child_pid). */ - void *private_data; -}; - -static void async_request_done(struct tevent_req *req); - -void async_request(TALLOC_CTX *mem_ctx, struct winbindd_child *child, - struct winbindd_request *request, - struct winbindd_response *response, - void (*continuation)(void *private_data, bool success), - void *private_data) -{ - struct winbindd_async_request *state; - struct tevent_req *req; - - DEBUG(10, ("Sending request to child pid %d (domain=%s)\n", - (int)child->pid, - (child->domain != NULL) ? child->domain->name : "''")); - - state = talloc(mem_ctx, struct winbindd_async_request); - if (state == NULL) { - DEBUG(0, ("talloc failed\n")); - continuation(private_data, False); - return; - } - - state->mem_ctx = mem_ctx; - state->child = child; - state->reply_timeout_event = NULL; - state->response = response; - state->continuation = continuation; - state->private_data = private_data; - - request->pid = child->pid; - - req = wb_child_request_send(state, winbind_event_context(), - child, request); - if (req == NULL) { - DEBUG(0, ("wb_child_request_send failed\n")); - continuation(private_data, false); - return; - } - tevent_req_set_callback(req, async_request_done, state); -} - -static void async_request_done(struct tevent_req *req) -{ - struct winbindd_async_request *state = tevent_req_callback_data( - req, struct winbindd_async_request); - struct winbindd_response *response; - int ret, err; - - ret = wb_child_request_recv(req, state, &response, &err); - TALLOC_FREE(req); - if (ret == -1) { - DEBUG(2, ("wb_child_request_recv failed: %s\n", - strerror(err))); - state->continuation(state->private_data, false); - return; - } - *state->response = *response; - state->continuation(state->private_data, true); -} - struct domain_request_state { struct winbindd_domain *domain; struct winbindd_request *request; @@ -527,13 +448,6 @@ static void recvfrom_child(void *private_data_data, bool success) request_ok(state); } -void sendto_child(struct winbindd_cli_state *state, - struct winbindd_child *child) -{ - async_request(state->mem_ctx, child, state->request, - state->response, recvfrom_child, state); -} - void sendto_domain(struct winbindd_cli_state *state, struct winbindd_domain *domain) { @@ -588,7 +502,7 @@ void setup_child(struct winbindd_domain *domain, struct winbindd_child *child, "logname == NULL"); } - child->domain = NULL; + child->domain = domain; child->table = table; child->queue = tevent_queue_create(NULL, "winbind_child"); SMB_ASSERT(child->queue != NULL); @@ -830,7 +744,7 @@ void winbind_msg_onlinestatus(struct messaging_context *msg_ctx, TALLOC_CTX *mem_ctx; const char *message; struct server_id *sender; - + DEBUG(5,("winbind_msg_onlinestatus received.\n")); if (!data->data) { @@ -843,7 +757,7 @@ void winbind_msg_onlinestatus(struct messaging_context *msg_ctx, if (mem_ctx == NULL) { return; } - + message = collect_onlinestatus(mem_ctx); if (message == NULL) { talloc_destroy(mem_ctx); diff --git a/source3/winbindd/winbindd_dual_srv.c b/source3/winbindd/winbindd_dual_srv.c index cecbb61051..b247d5a233 100644 --- a/source3/winbindd/winbindd_dual_srv.c +++ b/source3/winbindd/winbindd_dual_srv.c @@ -510,6 +510,54 @@ again: return status; } +NTSTATUS _wbint_PingDc(pipes_struct *p, struct wbint_PingDc *r) +{ + NTSTATUS status; + struct winbindd_domain *domain; + struct rpc_pipe_client *netlogon_pipe; + union netr_CONTROL_QUERY_INFORMATION info; + WERROR werr; + fstring logon_server; + + domain = wb_child_domain(); + if (domain == NULL) { + return NT_STATUS_REQUEST_NOT_ACCEPTED; + } + + status = cm_connect_netlogon(domain, &netlogon_pipe); + if (!NT_STATUS_IS_OK(status)) { + DEBUG(3, ("could not open handle to NETLOGON pipe\n")); + return status; + } + + fstr_sprintf(logon_server, "\\\\%s", domain->dcname); + + /* + * This provokes a WERR_NOT_SUPPORTED error message. This is + * documented in the wspp docs. I could not get a successful + * call to work, but the main point here is testing that the + * netlogon pipe works. + */ + status = rpccli_netr_LogonControl(netlogon_pipe, p->mem_ctx, + logon_server, NETLOGON_CONTROL_QUERY, + 2, &info, &werr); + + if (NT_STATUS_EQUAL(status, NT_STATUS_IO_TIMEOUT)) { + DEBUG(2, ("rpccli_netr_LogonControl timed out\n")); + invalidate_cm_connection(&domain->conn); + return status; + } + + if (!NT_STATUS_EQUAL(status, NT_STATUS_CTL_FILE_NOT_SUPPORTED)) { + DEBUG(2, ("rpccli_netr_LogonControl returned %s, expected " + "NT_STATUS_CTL_FILE_NOT_SUPPORTED\n", + nt_errstr(status))); + return status; + } + + DEBUG(5, ("winbindd_dual_ping_dc succeeded\n")); + return NT_STATUS_OK; +} NTSTATUS _wbint_SetMapping(pipes_struct *p, struct wbint_SetMapping *r) { diff --git a/source3/winbindd/winbindd_getgrnam.c b/source3/winbindd/winbindd_getgrnam.c index d888393399..3ca1aa6111 100644 --- a/source3/winbindd/winbindd_getgrnam.c +++ b/source3/winbindd/winbindd_getgrnam.c @@ -40,7 +40,6 @@ struct tevent_req *winbindd_getgrnam_send(TALLOC_CTX *mem_ctx, { struct tevent_req *req, *subreq; struct winbindd_getgrnam_state *state; - struct winbindd_domain *domain; char *tmp; NTSTATUS nt_status; @@ -77,27 +76,7 @@ struct tevent_req *winbindd_getgrnam_send(TALLOC_CTX *mem_ctx, fstrcpy(state->name_domain, get_global_sam_name()); } - /* Get info for the domain */ - - domain = find_domain_from_name_noinit(state->name_domain); - if (domain == NULL) { - DEBUG(3, ("could not get domain sid for domain %s\n", - state->name_domain)); - tevent_req_nterror(req, NT_STATUS_NO_SUCH_GROUP); - return tevent_req_post(req, ev); - } - - /* should we deal with users for our domain? */ - - if ( lp_winbind_trusted_domains_only() && domain->primary) { - DEBUG(7,("winbindd_getgrnam: My domain -- rejecting " - "getgrnam() for %s\\%s.\n", state->name_domain, - state->name_group)); - tevent_req_nterror(req, NT_STATUS_NO_SUCH_GROUP); - return tevent_req_post(req, ev); - } - - subreq = wb_lookupname_send(state, ev, domain->name, state->name_group, + subreq = wb_lookupname_send(state, ev, state->name_domain, state->name_group, 0); if (tevent_req_nomem(subreq, req)) { return tevent_req_post(req, ev); diff --git a/source3/winbindd/winbindd_getgroups.c b/source3/winbindd/winbindd_getgroups.c index 3bdf762c45..736eba698a 100644 --- a/source3/winbindd/winbindd_getgroups.c +++ b/source3/winbindd/winbindd_getgroups.c @@ -45,7 +45,6 @@ struct tevent_req *winbindd_getgroups_send(TALLOC_CTX *mem_ctx, struct tevent_req *req, *subreq; struct winbindd_getgroups_state *state; char *domuser, *mapped_user; - struct winbindd_domain *domain; NTSTATUS status; req = tevent_req_create(mem_ctx, &state, @@ -76,29 +75,6 @@ struct tevent_req *winbindd_getgroups_send(TALLOC_CTX *mem_ctx, return tevent_req_post(req, ev); } - domain = find_domain_from_name_noinit(state->domname); - if (domain == NULL) { - /* Retry with DNS name */ - char *p = strchr(domuser, '@'); - if (p != NULL) { - domain = find_domain_from_name_noinit(p+1); - } - } - if (domain == NULL) { - DEBUG(7, ("could not find domain entry for domain %s\n", - state->domname)); - tevent_req_nterror(req, NT_STATUS_NO_SUCH_USER); - return tevent_req_post(req, ev); - } - - if (lp_winbind_trusted_domains_only() && domain->primary) { - DEBUG(7,("winbindd_getgroups: My domain -- " - "rejecting getgroups() for %s\\%s.\n", - state->domname, state->username)); - tevent_req_nterror(req, NT_STATUS_NO_SUCH_USER); - return tevent_req_post(req, ev); - } - subreq = wb_lookupname_send(state, ev, state->domname, state->username, LOOKUP_NAME_NO_NSS); if (tevent_req_nomem(subreq, req)) { diff --git a/source3/winbindd/winbindd_group.c b/source3/winbindd/winbindd_group.c index eab5c26df4..a985fa254f 100644 --- a/source3/winbindd/winbindd_group.c +++ b/source3/winbindd/winbindd_group.c @@ -66,290 +66,6 @@ bool fill_grent(TALLOC_CTX *mem_ctx, struct winbindd_gr *gr, return True; } -/* Get the list of domain groups and domain aliases for a domain. We fill in - the sam_entries and num_sam_entries fields with domain group information. - Return True if some groups were returned, False otherwise. */ - -bool get_sam_group_entries(struct getent_state *ent) -{ - NTSTATUS status; - uint32 num_entries; - struct acct_info *name_list = NULL; - TALLOC_CTX *mem_ctx; - bool result = False; - struct acct_info *sam_grp_entries = NULL; - struct winbindd_domain *domain; - - if (ent->got_sam_entries) - return False; - - if (!(mem_ctx = talloc_init("get_sam_group_entries(%s)", - ent->domain_name))) { - DEBUG(1, ("get_sam_group_entries: " - "could not create talloc context!\n")); - return False; - } - - /* Free any existing group info */ - - SAFE_FREE(ent->sam_entries); - ent->num_sam_entries = 0; - ent->got_sam_entries = True; - - /* Enumerate domain groups */ - - num_entries = 0; - - if (!(domain = find_domain_from_name(ent->domain_name))) { - DEBUG(3, ("no such domain %s in get_sam_group_entries\n", - ent->domain_name)); - goto done; - } - - /* always get the domain global groups */ - - status = domain->methods->enum_dom_groups(domain, mem_ctx, &num_entries, - &sam_grp_entries); - - if (!NT_STATUS_IS_OK(status)) { - DEBUG(3, ("get_sam_group_entries: " - "could not enumerate domain groups! Error: %s\n", - nt_errstr(status))); - result = False; - goto done; - } - - /* Copy entries into return buffer */ - - if (num_entries) { - name_list = SMB_MALLOC_ARRAY(struct acct_info, num_entries); - if (!name_list) { - DEBUG(0,("get_sam_group_entries: Failed to malloc " - "memory for %d domain groups!\n", - num_entries)); - result = False; - goto done; - } - memcpy(name_list, sam_grp_entries, - num_entries * sizeof(struct acct_info)); - } - - ent->num_sam_entries = num_entries; - - /* get the domain local groups if we are a member of a native win2k - * domain and are not using LDAP to get the groups */ - - if ( ( lp_security() != SEC_ADS && domain->native_mode - && domain->primary) || domain->internal ) - { - DEBUG(4,("get_sam_group_entries: %s domain; " - "enumerating local groups as well\n", - domain->native_mode ? "Native Mode 2k": - "BUILTIN or local")); - - status = domain->methods->enum_local_groups(domain, mem_ctx, - &num_entries, - &sam_grp_entries); - - if ( !NT_STATUS_IS_OK(status) ) { - DEBUG(3,("get_sam_group_entries: " - "Failed to enumerate " - "domain local groups with error %s!\n", - nt_errstr(status))); - num_entries = 0; - } - else - DEBUG(4,("get_sam_group_entries: " - "Returned %d local groups\n", - num_entries)); - - /* Copy entries into return buffer */ - - if ( num_entries ) { - name_list = SMB_REALLOC_ARRAY(name_list, - struct acct_info, - ent->num_sam_entries+ - num_entries); - if (!name_list) { - DEBUG(0,("get_sam_group_entries: " - "Failed to realloc more memory " - "for %d local groups!\n", - num_entries)); - result = False; - goto done; - } - - memcpy(&name_list[ent->num_sam_entries], - sam_grp_entries, - num_entries * sizeof(struct acct_info)); - } - - ent->num_sam_entries += num_entries; - } - - - /* Fill in remaining fields */ - - ent->sam_entries = name_list; - ent->sam_entry_index = 0; - - result = (ent->num_sam_entries > 0); - - done: - talloc_destroy(mem_ctx); - - return result; -} - -/* Get user supplementary groups. This is much quicker than trying to - invert the groups database. We merge the groups from the gids and - other_sids info3 fields as trusted domain, universal group - memberships, and nested groups (win2k native mode only) are not - returned by the getgroups RPC call but are present in the info3. */ - -struct getgroups_state { - struct winbindd_cli_state *state; - struct winbindd_domain *domain; - char *domname; - char *username; - DOM_SID user_sid; - - const DOM_SID *token_sids; - size_t i, num_token_sids; - - gid_t *token_gids; - size_t num_token_gids; -}; - -enum winbindd_result winbindd_dual_getuserdomgroups(struct winbindd_domain *domain, - struct winbindd_cli_state *state) -{ - DOM_SID user_sid; - NTSTATUS status; - - char *sidstring; - ssize_t len; - DOM_SID *groups; - uint32 num_groups; - - /* Ensure null termination */ - state->request->data.sid[sizeof(state->request->data.sid)-1]='\0'; - - if (!string_to_sid(&user_sid, state->request->data.sid)) { - DEBUG(1, ("Could not get convert sid %s from string\n", - state->request->data.sid)); - return WINBINDD_ERROR; - } - - status = domain->methods->lookup_usergroups(domain, state->mem_ctx, - &user_sid, &num_groups, - &groups); - if (!NT_STATUS_IS_OK(status)) - return WINBINDD_ERROR; - - if (num_groups == 0) { - state->response->data.num_entries = 0; - state->response->extra_data.data = NULL; - return WINBINDD_OK; - } - - if (!print_sidlist(state->mem_ctx, - groups, num_groups, - &sidstring, &len)) { - DEBUG(0, ("talloc failed\n")); - return WINBINDD_ERROR; - } - - state->response->extra_data.data = sidstring; - state->response->length += len+1; - state->response->data.num_entries = num_groups; - - return WINBINDD_OK; -} - -enum winbindd_result winbindd_dual_getsidaliases(struct winbindd_domain *domain, - struct winbindd_cli_state *state) -{ - DOM_SID *sids = NULL; - size_t num_sids = 0; - char *sidstr = NULL; - ssize_t len; - size_t i; - uint32 num_aliases; - uint32 *alias_rids; - NTSTATUS result; - - DEBUG(3, ("[%5lu]: getsidaliases\n", (unsigned long)state->pid)); - - sidstr = state->request->extra_data.data; - if (sidstr == NULL) { - sidstr = talloc_strdup(state->mem_ctx, "\n"); /* No SID */ - if (!sidstr) { - DEBUG(0, ("Out of memory\n")); - return WINBINDD_ERROR; - } - } - - DEBUG(10, ("Sidlist: %s\n", sidstr)); - - if (!parse_sidlist(state->mem_ctx, sidstr, &sids, &num_sids)) { - DEBUG(0, ("Could not parse SID list: %s\n", sidstr)); - return WINBINDD_ERROR; - } - - num_aliases = 0; - alias_rids = NULL; - - result = domain->methods->lookup_useraliases(domain, - state->mem_ctx, - num_sids, sids, - &num_aliases, - &alias_rids); - - if (!NT_STATUS_IS_OK(result)) { - DEBUG(3, ("Could not lookup_useraliases: %s\n", - nt_errstr(result))); - return WINBINDD_ERROR; - } - - num_sids = 0; - sids = NULL; - sidstr = NULL; - - DEBUG(10, ("Got %d aliases\n", num_aliases)); - - for (i=0; i<num_aliases; i++) { - DOM_SID sid; - DEBUGADD(10, (" rid %d\n", alias_rids[i])); - sid_copy(&sid, &domain->sid); - sid_append_rid(&sid, alias_rids[i]); - result = add_sid_to_array(state->mem_ctx, &sid, &sids, - &num_sids); - if (!NT_STATUS_IS_OK(result)) { - return WINBINDD_ERROR; - } - } - - - if (!print_sidlist(state->mem_ctx, sids, num_sids, &sidstr, &len)) { - DEBUG(0, ("Could not print_sidlist\n")); - state->response->extra_data.data = NULL; - return WINBINDD_ERROR; - } - - state->response->extra_data.data = NULL; - - if (sidstr) { - state->response->extra_data.data = sidstr; - DEBUG(10, ("aliases_list: %s\n", - (char *)state->response->extra_data.data)); - state->response->length += len+1; - state->response->data.num_entries = num_sids; - } - - return WINBINDD_OK; -} - struct getgr_countmem { int num; size_t len; diff --git a/source3/winbindd/winbindd_idmap.c b/source3/winbindd/winbindd_idmap.c index 1d275014ce..028026087d 100644 --- a/source3/winbindd/winbindd_idmap.c +++ b/source3/winbindd/winbindd_idmap.c @@ -7,17 +7,6 @@ Copyright (C) Gerald Carter 2006 Copyright (C) Simo Sorce 2007 - The helpers always consist of three functions: - - * A request setup function that takes the necessary parameters together - with a continuation function that is to be called upon completion - - * A private continuation function that is internal only. This is to be - called by the lower-level functions in do_async(). Its only task is to - properly call the continuation function named above. - - * A worker function that is called inside the appropriate child process. - This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or @@ -45,322 +34,12 @@ struct winbindd_child *idmap_child(void) return &static_idmap_child; } -static void winbindd_sid2uid_recv(TALLOC_CTX *mem_ctx, bool success, - struct winbindd_response *response, - void *c, void *private_data) -{ - void (*cont)(void *priv, bool succ, uid_t uid) = - (void (*)(void *, bool, uid_t))c; - - if (!success) { - DEBUG(5, ("Could not trigger sid2uid\n")); - cont(private_data, False, 0); - return; - } - - if (response->result != WINBINDD_OK) { - DEBUG(5, ("sid2uid returned an error\n")); - cont(private_data, False, 0); - return; - } - - cont(private_data, True, response->data.uid); -} - -void winbindd_sid2uid_async(TALLOC_CTX *mem_ctx, const DOM_SID *sid, - void (*cont)(void *private_data, bool success, uid_t uid), - void *private_data) -{ - struct winbindd_request request; - struct winbindd_domain *domain; - - ZERO_STRUCT(request); - request.cmd = WINBINDD_DUAL_SID2UID; - - domain = find_domain_from_sid(sid); - - if (domain != NULL) { - DEBUG(10, ("winbindd_sid2uid_async found domain %s, " - "have_idmap_config = %d\n", domain->name, - (int)domain->have_idmap_config)); - - } - else { - DEBUG(10, ("winbindd_sid2uid_async did not find a domain for " - "%s\n", sid_string_dbg(sid))); - } - - if ((domain != NULL) && (domain->have_idmap_config)) { - fstrcpy(request.domain_name, domain->name); - } - - sid_to_fstring(request.data.dual_sid2id.sid, sid); - do_async(mem_ctx, idmap_child(), &request, winbindd_sid2uid_recv, - (void *)cont, private_data); -} - -enum winbindd_result winbindd_dual_sid2uid(struct winbindd_domain *domain, - struct winbindd_cli_state *state) -{ - DOM_SID sid; - NTSTATUS result; - - DEBUG(3, ("[%5lu]: sid to uid %s\n", (unsigned long)state->pid, - state->request->data.dual_sid2id.sid)); - - if (!string_to_sid(&sid, state->request->data.dual_sid2id.sid)) { - DEBUG(1, ("Could not get convert sid %s from string\n", - state->request->data.dual_sid2id.sid)); - return WINBINDD_ERROR; - } - - result = idmap_sid_to_uid(state->request->domain_name, &sid, - &state->response->data.uid); - - DEBUG(10, ("winbindd_dual_sid2uid: 0x%08x - %s - %u\n", - NT_STATUS_V(result), sid_string_dbg(&sid), - (unsigned int)state->response->data.uid)); - - return NT_STATUS_IS_OK(result) ? WINBINDD_OK : WINBINDD_ERROR; -} - -static void winbindd_sid2gid_recv(TALLOC_CTX *mem_ctx, bool success, - struct winbindd_response *response, - void *c, void *private_data) -{ - void (*cont)(void *priv, bool succ, gid_t gid) = - (void (*)(void *, bool, gid_t))c; - - if (!success) { - DEBUG(5, ("Could not trigger sid2gid\n")); - cont(private_data, False, 0); - return; - } - - if (response->result != WINBINDD_OK) { - DEBUG(5, ("sid2gid returned an error\n")); - cont(private_data, False, 0); - return; - } - - cont(private_data, True, response->data.gid); -} - -void winbindd_sid2gid_async(TALLOC_CTX *mem_ctx, const DOM_SID *sid, - void (*cont)(void *private_data, bool success, gid_t gid), - void *private_data) -{ - struct winbindd_request request; - struct winbindd_domain *domain; - - ZERO_STRUCT(request); - request.cmd = WINBINDD_DUAL_SID2GID; - - domain = find_domain_from_sid(sid); - if ((domain != NULL) && (domain->have_idmap_config)) { - fstrcpy(request.domain_name, domain->name); - } - - sid_to_fstring(request.data.dual_sid2id.sid, sid); - - DEBUG(7,("winbindd_sid2gid_async: Resolving %s to a gid\n", - request.data.dual_sid2id.sid)); - - do_async(mem_ctx, idmap_child(), &request, winbindd_sid2gid_recv, - (void *)cont, private_data); -} - -enum winbindd_result winbindd_dual_sid2gid(struct winbindd_domain *domain, - struct winbindd_cli_state *state) -{ - DOM_SID sid; - NTSTATUS result; - - DEBUG(3, ("[%5lu]: sid to gid %s\n", (unsigned long)state->pid, - state->request->data.dual_sid2id.sid)); - - if (!string_to_sid(&sid, state->request->data.dual_sid2id.sid)) { - DEBUG(1, ("Could not get convert sid %s from string\n", - state->request->data.dual_sid2id.sid)); - return WINBINDD_ERROR; - } - - /* Find gid for this sid and return it, possibly ask the slow remote idmap */ - - result = idmap_sid_to_gid(state->request->domain_name, &sid, - &state->response->data.gid); - - DEBUG(10, ("winbindd_dual_sid2gid: 0x%08x - %s - %u\n", - NT_STATUS_V(result), sid_string_dbg(&sid), - (unsigned int)state->response->data.gid)); - - return NT_STATUS_IS_OK(result) ? WINBINDD_OK : WINBINDD_ERROR; -} - -/* The following uid2sid/gid2sid functions has been contributed by - * Keith Reynolds <Keith.Reynolds@centrify.com> */ - -static void winbindd_uid2sid_recv(TALLOC_CTX *mem_ctx, bool success, - struct winbindd_response *response, - void *c, void *private_data) -{ - void (*cont)(void *priv, bool succ, const char *sid) = - (void (*)(void *, bool, const char *))c; - - if (!success) { - DEBUG(5, ("Could not trigger uid2sid\n")); - cont(private_data, False, NULL); - return; - } - - if (response->result != WINBINDD_OK) { - DEBUG(5, ("uid2sid returned an error\n")); - cont(private_data, False, NULL); - return; - } - - cont(private_data, True, response->data.sid.sid); -} - -void winbindd_uid2sid_async(TALLOC_CTX *mem_ctx, uid_t uid, - void (*cont)(void *private_data, bool success, const char *sid), - void *private_data) -{ - struct winbindd_domain *domain; - struct winbindd_request request; - - ZERO_STRUCT(request); - request.cmd = WINBINDD_DUAL_UID2SID; - request.data.uid = uid; - - for (domain = domain_list(); domain != NULL; domain = domain->next) { - if (domain->have_idmap_config - && (uid >= domain->id_range_low) - && (uid <= domain->id_range_high)) { - fstrcpy(request.domain_name, domain->name); - } - } - - do_async(mem_ctx, idmap_child(), &request, winbindd_uid2sid_recv, - (void *)cont, private_data); -} - -enum winbindd_result winbindd_dual_uid2sid(struct winbindd_domain *domain, - struct winbindd_cli_state *state) -{ - DOM_SID sid; - NTSTATUS result; - - DEBUG(3,("[%5lu]: uid to sid %lu\n", - (unsigned long)state->pid, - (unsigned long) state->request->data.uid)); - - /* Find sid for this uid and return it, possibly ask the slow remote idmap */ - result = idmap_uid_to_sid(state->request->domain_name, &sid, - state->request->data.uid); - - if (NT_STATUS_IS_OK(result)) { - sid_to_fstring(state->response->data.sid.sid, &sid); - state->response->data.sid.type = SID_NAME_USER; - return WINBINDD_OK; - } - - return WINBINDD_ERROR; -} - -static void winbindd_gid2sid_recv(TALLOC_CTX *mem_ctx, bool success, - struct winbindd_response *response, - void *c, void *private_data) -{ - void (*cont)(void *priv, bool succ, const char *sid) = - (void (*)(void *, bool, const char *))c; - - if (!success) { - DEBUG(5, ("Could not trigger gid2sid\n")); - cont(private_data, False, NULL); - return; - } - - if (response->result != WINBINDD_OK) { - DEBUG(5, ("gid2sid returned an error\n")); - cont(private_data, False, NULL); - return; - } - - cont(private_data, True, response->data.sid.sid); -} - -void winbindd_gid2sid_async(TALLOC_CTX *mem_ctx, gid_t gid, - void (*cont)(void *private_data, bool success, const char *sid), - void *private_data) -{ - struct winbindd_domain *domain; - struct winbindd_request request; - - ZERO_STRUCT(request); - request.cmd = WINBINDD_DUAL_GID2SID; - request.data.gid = gid; - - for (domain = domain_list(); domain != NULL; domain = domain->next) { - if (domain->have_idmap_config - && (gid >= domain->id_range_low) - && (gid <= domain->id_range_high)) { - fstrcpy(request.domain_name, domain->name); - } - } - - do_async(mem_ctx, idmap_child(), &request, winbindd_gid2sid_recv, - (void *)cont, private_data); -} - -enum winbindd_result winbindd_dual_gid2sid(struct winbindd_domain *domain, - struct winbindd_cli_state *state) -{ - DOM_SID sid; - NTSTATUS result; - - DEBUG(3,("[%5lu]: gid %lu to sid\n", - (unsigned long)state->pid, - (unsigned long) state->request->data.gid)); - - /* Find sid for this gid and return it, possibly ask the slow remote idmap */ - result = idmap_gid_to_sid(state->request->domain_name, &sid, - state->request->data.gid); - - if (NT_STATUS_IS_OK(result)) { - sid_to_fstring(state->response->data.sid.sid, &sid); - DEBUG(10, ("[%5lu]: retrieved sid: %s\n", - (unsigned long)state->pid, - state->response->data.sid.sid)); - state->response->data.sid.type = SID_NAME_DOM_GRP; - return WINBINDD_OK; - } - - return WINBINDD_ERROR; -} - static const struct winbindd_child_dispatch_table idmap_dispatch_table[] = { { .name = "PING", .struct_cmd = WINBINDD_PING, .struct_fn = winbindd_dual_ping, },{ - .name = "DUAL_SID2UID", - .struct_cmd = WINBINDD_DUAL_SID2UID, - .struct_fn = winbindd_dual_sid2uid, - },{ - .name = "DUAL_SID2GID", - .struct_cmd = WINBINDD_DUAL_SID2GID, - .struct_fn = winbindd_dual_sid2gid, - },{ - .name = "DUAL_UID2SID", - .struct_cmd = WINBINDD_DUAL_UID2SID, - .struct_fn = winbindd_dual_uid2sid, - },{ - .name = "DUAL_GID2SID", - .struct_cmd = WINBINDD_DUAL_GID2SID, - .struct_fn = winbindd_dual_gid2sid, - },{ .name = "NDRCMD", .struct_cmd = WINBINDD_DUAL_NDRCMD, .struct_fn = winbindd_dual_ndrcmd, diff --git a/source3/winbindd/winbindd_misc.c b/source3/winbindd/winbindd_misc.c index 3ebd9ffdbd..ac8f1a7dfd 100644 --- a/source3/winbindd/winbindd_misc.c +++ b/source3/winbindd/winbindd_misc.c @@ -5,17 +5,17 @@ Copyright (C) Tim Potter 2000 Copyright (C) Andrew Bartlett 2002 - + This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. - + This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. - + You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/>. */ @@ -93,7 +93,7 @@ void winbindd_list_trusted_domains(struct winbindd_cli_state *state) int extra_data_len = 0; char *extra_data = NULL; int i = 0; - + DEBUG(3, ("[%5lu]: list trusted domains\n", (unsigned long)state->pid)); @@ -102,6 +102,12 @@ void winbindd_list_trusted_domains(struct winbindd_cli_state *state) goto done; } + extra_data = talloc_strdup(state->mem_ctx, ""); + if (extra_data == NULL) { + request_error(state); + goto done; + } + for ( i = 0; i < num_domains; i++ ) { struct winbindd_domain *domain; bool is_online = true; @@ -111,41 +117,27 @@ void winbindd_list_trusted_domains(struct winbindd_cli_state *state) if (domain) { is_online = domain->online; } - - if ( !extra_data ) { - extra_data = talloc_asprintf(state->mem_ctx, - "%s\\%s\\%s\\%s\\%s\\%s\\%s\\%s", - d->domain_name, - d->dns_name ? d->dns_name : d->domain_name, - sid_string_talloc(state->mem_ctx, &d->sid), - get_trust_type_string(d), - trust_is_transitive(d) ? "Yes" : "No", - trust_is_inbound(d) ? "Yes" : "No", - trust_is_outbound(d) ? "Yes" : "No", - is_online ? "Online" : "Offline" ); - } else { - extra_data = talloc_asprintf(state->mem_ctx, - "%s\n%s\\%s\\%s\\%s\\%s\\%s\\%s\\%s", - extra_data, - d->domain_name, - d->dns_name ? d->dns_name : d->domain_name, - sid_string_talloc(state->mem_ctx, &d->sid), - get_trust_type_string(d), - trust_is_transitive(d) ? "Yes" : "No", - trust_is_inbound(d) ? "Yes" : "No", - trust_is_outbound(d) ? "Yes" : "No", - is_online ? "Online" : "Offline" ); - } - } - - extra_data_len = 0; - if (extra_data != NULL) { - extra_data_len = strlen(extra_data); + extra_data = talloc_asprintf_append_buffer( + extra_data, + "%s\\%s\\%s\\%s\\%s\\%s\\%s\\%s\n", + d->domain_name, + d->dns_name ? d->dns_name : d->domain_name, + sid_string_talloc(state->mem_ctx, &d->sid), + get_trust_type_string(d), + trust_is_transitive(d) ? "Yes" : "No", + trust_is_inbound(d) ? "Yes" : "No", + trust_is_outbound(d) ? "Yes" : "No", + is_online ? "Online" : "Offline" ); } + extra_data_len = strlen(extra_data); if (extra_data_len > 0) { + + /* Strip the last \n */ + extra_data[extra_data_len-1] = '\0'; + state->response->extra_data.data = extra_data; - state->response->length += extra_data_len+1; + state->response->length += extra_data_len; } request_ok(state); @@ -156,20 +148,18 @@ done: enum winbindd_result winbindd_dual_list_trusted_domains(struct winbindd_domain *domain, struct winbindd_cli_state *state) { - uint32 i, num_domains; - char **names, **alt_names; - DOM_SID *sids; + int i; int extra_data_len = 0; char *extra_data; NTSTATUS result; bool have_own_domain = False; + struct netr_DomainTrustList trusts; DEBUG(3, ("[%5lu]: list trusted domains\n", (unsigned long)state->pid)); result = domain->methods->trusted_domains(domain, state->mem_ctx, - &num_domains, &names, - &alt_names, &sids); + &trusts); if (!NT_STATUS_IS_OK(result)) { DEBUG(3, ("winbindd_dual_list_trusted_domains: trusted_domains returned %s\n", @@ -179,45 +169,37 @@ enum winbindd_result winbindd_dual_list_trusted_domains(struct winbindd_domain * extra_data = talloc_strdup(state->mem_ctx, ""); - if (num_domains > 0) - extra_data = talloc_asprintf( - state->mem_ctx, "%s\\%s\\%s", - names[0], alt_names[0] ? alt_names[0] : names[0], - sid_string_talloc(state->mem_ctx, &sids[0])); - - for (i=1; i<num_domains; i++) - extra_data = talloc_asprintf( - state->mem_ctx, "%s\n%s\\%s\\%s", - extra_data, names[i], - alt_names[i] ? alt_names[i] : names[i], - sid_string_talloc(state->mem_ctx, &sids[i])); + for (i=0; i<trusts.count; i++) { + extra_data = talloc_asprintf_append_buffer( + extra_data, "%s\\%s\\%s\n", + trusts.array[i].netbios_name, + trusts.array[i].dns_name, + sid_string_talloc(state->mem_ctx, + trusts.array[i].sid)); + } /* add our primary domain */ - - for (i=0; i<num_domains; i++) { - if (strequal(names[i], domain->name)) { + + for (i=0; i<trusts.count; i++) { + if (strequal(trusts.array[i].netbios_name, domain->name)) { have_own_domain = True; break; } } if (state->request->data.list_all_domains && !have_own_domain) { - extra_data = talloc_asprintf( - state->mem_ctx, "%s\n%s\\%s\\%s", - extra_data, domain->name, + extra_data = talloc_asprintf_append_buffer( + extra_data, "%s\\%s\\%s\n", domain->name, domain->alt_name ? domain->alt_name : domain->name, sid_string_talloc(state->mem_ctx, &domain->sid)); } - /* This is a bit excessive, but the extra data sooner or later will be - talloc'ed */ + extra_data_len = strlen(extra_data); + if (extra_data_len > 0) { - extra_data_len = 0; - if (extra_data != NULL) { - extra_data_len = strlen(extra_data); - } + /* Strip the last \n */ + extra_data[extra_data_len-1] = '\0'; - if (extra_data_len > 0) { state->response->extra_data.data = extra_data; state->response->length += extra_data_len+1; } @@ -225,78 +207,6 @@ enum winbindd_result winbindd_dual_list_trusted_domains(struct winbindd_domain * return WINBINDD_OK; } -enum winbindd_result winbindd_dual_getdcname(struct winbindd_domain *domain, - struct winbindd_cli_state *state) -{ - const char *dcname_slash = NULL; - const char *p; - struct rpc_pipe_client *netlogon_pipe; - NTSTATUS result; - WERROR werr; - unsigned int orig_timeout; - struct winbindd_domain *req_domain; - - state->request->domain_name - [sizeof(state->request->domain_name)-1] = '\0'; - - DEBUG(3, ("[%5lu]: Get DC name for %s\n", (unsigned long)state->pid, - state->request->domain_name)); - - result = cm_connect_netlogon(domain, &netlogon_pipe); - - if (!NT_STATUS_IS_OK(result)) { - DEBUG(1, ("Can't contact the NETLOGON pipe\n")); - return WINBINDD_ERROR; - } - - /* This call can take a long time - allow the server to time out. - 35 seconds should do it. */ - - orig_timeout = rpccli_set_timeout(netlogon_pipe, 35000); - - req_domain = find_domain_from_name_noinit(state->request->domain_name); - if (req_domain == domain) { - result = rpccli_netr_GetDcName(netlogon_pipe, - state->mem_ctx, - domain->dcname, - state->request->domain_name, - &dcname_slash, - &werr); - } else { - result = rpccli_netr_GetAnyDCName(netlogon_pipe, - state->mem_ctx, - domain->dcname, - state->request->domain_name, - &dcname_slash, - &werr); - } - /* And restore our original timeout. */ - rpccli_set_timeout(netlogon_pipe, orig_timeout); - - if (!NT_STATUS_IS_OK(result)) { - DEBUG(5,("Error requesting DCname for domain %s: %s\n", - state->request->domain_name, nt_errstr(result))); - return WINBINDD_ERROR; - } - - if (!W_ERROR_IS_OK(werr)) { - DEBUG(5, ("Error requesting DCname for domain %s: %s\n", - state->request->domain_name, win_errstr(werr))); - return WINBINDD_ERROR; - } - - p = dcname_slash; - if (*p == '\\') { - p+=1; - } - if (*p == '\\') { - p+=1; - } - - fstrcpy(state->response->data.dc_name, p); - return WINBINDD_OK; -} - /* This is the child-only version of --sequence. It only allows for a single * domain (ie "our" one) to be displayed. */ @@ -440,7 +350,7 @@ void winbindd_interface_version(struct winbindd_cli_state *state) { DEBUG(3, ("[%5lu]: request interface version\n", (unsigned long)state->pid)); - + state->response->data.interface_version = WINBIND_INTERFACE_VERSION; request_ok(state); } @@ -450,7 +360,7 @@ void winbindd_interface_version(struct winbindd_cli_state *state) void winbindd_domain_name(struct winbindd_cli_state *state) { DEBUG(3, ("[%5lu]: request domain name\n", (unsigned long)state->pid)); - + fstrcpy(state->response->data.domain_name, lp_workgroup()); request_ok(state); } @@ -461,7 +371,7 @@ void winbindd_netbios_name(struct winbindd_cli_state *state) { DEBUG(3, ("[%5lu]: request netbios name\n", (unsigned long)state->pid)); - + fstrcpy(state->response->data.netbios_name, global_myname()); request_ok(state); } @@ -473,7 +383,7 @@ void winbindd_priv_pipe_dir(struct winbindd_cli_state *state) char *priv_dir; DEBUG(3, ("[%5lu]: request location of privileged pipe\n", (unsigned long)state->pid)); - + priv_dir = get_winbind_priv_pipe_dir(); state->response->extra_data.data = talloc_move(state->mem_ctx, &priv_dir); diff --git a/source3/winbindd/winbindd_passdb.c b/source3/winbindd/winbindd_passdb.c index c23f87dcd5..34b5990a3f 100644 --- a/source3/winbindd/winbindd_passdb.c +++ b/source3/winbindd/winbindd_passdb.c @@ -398,16 +398,10 @@ static NTSTATUS builtin_query_user(struct winbindd_domain *domain, /* get a list of trusted domains - builtin domain */ static NTSTATUS builtin_trusted_domains(struct winbindd_domain *domain, - TALLOC_CTX *mem_ctx, - uint32 *num_domains, - char ***names, - char ***alt_names, - DOM_SID **dom_sids) + TALLOC_CTX *mem_ctx, + struct netr_DomainTrustList *trusts) { - *num_domains = 0; - *names = NULL; - *alt_names = NULL; - *dom_sids = NULL; + ZERO_STRUCTP(trusts); return NT_STATUS_OK; } @@ -649,58 +643,44 @@ static NTSTATUS sam_lookup_groupmem(struct winbindd_domain *domain, /* get a list of trusted domains */ static NTSTATUS sam_trusted_domains(struct winbindd_domain *domain, - TALLOC_CTX *mem_ctx, - uint32 *num_domains, - char ***names, - char ***alt_names, - DOM_SID **dom_sids) + TALLOC_CTX *mem_ctx, + struct netr_DomainTrustList *trusts) { NTSTATUS nt_status; struct trustdom_info **domains; int i; - TALLOC_CTX *tmp_ctx; - - *num_domains = 0; - *names = NULL; - *alt_names = NULL; - *dom_sids = NULL; - - if (!(tmp_ctx = talloc_init("trusted_domains"))) { - return NT_STATUS_NO_MEMORY; - } - nt_status = pdb_enum_trusteddoms(tmp_ctx, num_domains, &domains); + nt_status = pdb_enum_trusteddoms(talloc_tos(), &trusts->count, + &domains); if (!NT_STATUS_IS_OK(nt_status)) { - TALLOC_FREE(tmp_ctx); return nt_status; } - if (*num_domains) { - *names = TALLOC_ARRAY(mem_ctx, char *, *num_domains); - *alt_names = TALLOC_ARRAY(mem_ctx, char *, *num_domains); - *dom_sids = TALLOC_ARRAY(mem_ctx, DOM_SID, *num_domains); + if (trusts->count == 0) { + trusts->array = NULL; + return NT_STATUS_OK; + } - if ((*alt_names == NULL) || (*names == NULL) || (*dom_sids == NULL)) { - TALLOC_FREE(tmp_ctx); - return NT_STATUS_NO_MEMORY; - } - } else { - *names = NULL; - *alt_names = NULL; - *dom_sids = NULL; + trusts->array = talloc_zero_array( + mem_ctx, struct netr_DomainTrust, trusts->count); + if (trusts->array == NULL) { + return NT_STATUS_NO_MEMORY; } - for (i=0; i<*num_domains; i++) { - (*alt_names)[i] = NULL; - if (!((*names)[i] = talloc_strdup((*names), - domains[i]->name))) { - TALLOC_FREE(tmp_ctx); + for (i=0; i<trusts->count; i++) { + struct dom_sid *sid; + + trusts->array[i].netbios_name = talloc_move( + trusts->array, &domains[i]->name); + trusts->array[i].dns_name = NULL; + + sid = talloc(trusts->array, struct dom_sid); + if (sid == NULL) { return NT_STATUS_NO_MEMORY; } - sid_copy(&(*dom_sids)[i], &domains[i]->sid); + sid_copy(sid, &domains[i]->sid); + trusts->array[i].sid = sid; } - - TALLOC_FREE(tmp_ctx); return NT_STATUS_OK; } diff --git a/source3/winbindd/winbindd_ping_dc.c b/source3/winbindd/winbindd_ping_dc.c new file mode 100644 index 0000000000..e06e5896c2 --- /dev/null +++ b/source3/winbindd/winbindd_ping_dc.c @@ -0,0 +1,96 @@ +/* + Unix SMB/CIFS implementation. + async implementation of WINBINDD_PING_DC + Copyright (C) Volker Lendecke 2009 + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see <http://www.gnu.org/licenses/>. +*/ + +#include "includes.h" +#include "winbindd.h" +#include "librpc/gen_ndr/cli_wbint.h" + +struct winbindd_ping_dc_state { + uint8_t dummy; +}; + +static void winbindd_ping_dc_done(struct tevent_req *subreq); + +struct tevent_req *winbindd_ping_dc_send(TALLOC_CTX *mem_ctx, + struct tevent_context *ev, + struct winbindd_cli_state *cli, + struct winbindd_request *request) +{ + struct tevent_req *req, *subreq; + struct winbindd_ping_dc_state *state; + struct winbindd_domain *domain; + + req = tevent_req_create(mem_ctx, &state, + struct winbindd_ping_dc_state); + if (req == NULL) { + return NULL; + } + + if (request->domain_name[0] == '\0') { + /* preserve old behavior, when no domain name is given */ + domain = find_our_domain(); + } else { + domain = find_domain_from_name(request->domain_name); + } + if (domain == NULL) { + tevent_req_nterror(req, NT_STATUS_NO_SUCH_DOMAIN); + return tevent_req_post(req, ev); + } + if (domain->internal) { + /* + * Internal domains are passdb based, we can always + * contact them. + */ + tevent_req_done(req); + return tevent_req_post(req, ev); + } + + subreq = rpccli_wbint_PingDc_send(state, ev, domain->child.rpccli); + if (tevent_req_nomem(subreq, req)) { + return tevent_req_post(req, ev); + } + tevent_req_set_callback(subreq, winbindd_ping_dc_done, req); + return req; +} + +static void winbindd_ping_dc_done(struct tevent_req *subreq) +{ + struct tevent_req *req = tevent_req_callback_data( + subreq, struct tevent_req); + struct winbindd_ping_dc_state *state = tevent_req_data( + req, struct winbindd_ping_dc_state); + NTSTATUS status, result; + + status = rpccli_wbint_PingDc_recv(subreq, state, &result); + if (!NT_STATUS_IS_OK(status)) { + tevent_req_nterror(req, status); + return; + } + if (!NT_STATUS_IS_OK(result)) { + tevent_req_nterror(req, result); + return; + } + tevent_req_done(req); +} + +NTSTATUS winbindd_ping_dc_recv(struct tevent_req *req, + struct winbindd_response *presp) +{ + return tevent_req_simple_recv_ntstatus(req); +} diff --git a/source3/winbindd/winbindd_proto.h b/source3/winbindd/winbindd_proto.h index 21feddf6d6..263e326917 100644 --- a/source3/winbindd/winbindd_proto.h +++ b/source3/winbindd/winbindd_proto.h @@ -82,62 +82,10 @@ NTSTATUS winbindd_lookup_names(TALLOC_CTX *mem_ctx, /* The following definitions come from winbindd/winbindd_async.c */ -void do_async(TALLOC_CTX *mem_ctx, struct winbindd_child *child, - const struct winbindd_request *request, - void (*cont)(TALLOC_CTX *mem_ctx, bool success, - struct winbindd_response *response, - void *c, void *private_data), - void *c, void *private_data); -void winbindd_lookupsid_async(TALLOC_CTX *mem_ctx, const DOM_SID *sid, - void (*cont)(void *private_data, bool success, - const char *dom_name, - const char *name, - enum lsa_SidType type), - void *private_data); -enum winbindd_result winbindd_dual_lookupsid(struct winbindd_domain *domain, - struct winbindd_cli_state *state); -void winbindd_lookupname_async(TALLOC_CTX *mem_ctx, - const char *dom_name, const char *name, - void (*cont)(void *private_data, bool success, - const DOM_SID *sid, - enum lsa_SidType type), - enum winbindd_cmd orig_cmd, - void *private_data); -enum winbindd_result winbindd_dual_lookupname(struct winbindd_domain *domain, - struct winbindd_cli_state *state); -void winbindd_listent_async(TALLOC_CTX *mem_ctx, - struct winbindd_domain *domain, - void (*cont)(void *private_data, bool success, - fstring dom_name, char* extra_data), - void *private_data, enum ent_type type); -enum winbindd_result winbindd_dual_list_users(struct winbindd_domain *domain, - struct winbindd_cli_state *state); -enum winbindd_result winbindd_dual_list_groups(struct winbindd_domain *domain, - struct winbindd_cli_state *state); bool print_sidlist(TALLOC_CTX *mem_ctx, const DOM_SID *sids, size_t num_sids, char **result, ssize_t *len); bool parse_sidlist(TALLOC_CTX *mem_ctx, const char *sidstr, DOM_SID **sids, size_t *num_sids); -void winbindd_getsidaliases_async(struct winbindd_domain *domain, - TALLOC_CTX *mem_ctx, - const DOM_SID *sids, size_t num_sids, - void (*cont)(void *private_data, - bool success, - const DOM_SID *aliases, - size_t num_aliases), - void *private_data); -enum winbindd_result winbindd_dual_getsidaliases(struct winbindd_domain *domain, - struct winbindd_cli_state *state); -void query_user_async(TALLOC_CTX *mem_ctx, struct winbindd_domain *domain, - const DOM_SID *sid, - void (*cont)(void *private_data, bool success, - const char *acct_name, - const char *full_name, - const char *homedir, - const char *shell, - gid_t gid, - uint32 group_rid), - void *private_data); /* The following definitions come from winbindd/winbindd_cache.c */ @@ -328,19 +276,12 @@ struct tevent_req *wb_domain_request_send(TALLOC_CTX *mem_ctx, int wb_domain_request_recv(struct tevent_req *req, TALLOC_CTX *mem_ctx, struct winbindd_response **presponse, int *err); -void async_request(TALLOC_CTX *mem_ctx, struct winbindd_child *child, - struct winbindd_request *request, - struct winbindd_response *response, - void (*continuation)(void *private_data, bool success), - void *private_data); void async_domain_request(TALLOC_CTX *mem_ctx, struct winbindd_domain *domain, struct winbindd_request *request, struct winbindd_response *response, void (*continuation)(void *private_data_data, bool success), void *private_data_data); -void sendto_child(struct winbindd_cli_state *state, - struct winbindd_child *child); void sendto_domain(struct winbindd_cli_state *state, struct winbindd_domain *domain); void setup_child(struct winbindd_domain *domain, struct winbindd_child *child, @@ -394,9 +335,6 @@ void winbindd_getgroups(struct winbindd_cli_state *state); void winbindd_getusersids(struct winbindd_cli_state *state); void winbindd_getuserdomgroups(struct winbindd_cli_state *state); void winbindd_getsidaliases(struct winbindd_cli_state *state); -enum winbindd_result winbindd_dual_getuserdomgroups(struct winbindd_domain *domain, - struct winbindd_cli_state *state); -bool get_sam_group_entries(struct getent_state *ent); bool fill_grent(TALLOC_CTX *mem_ctx, struct winbindd_gr *gr, const char *dom_name, const char *gr_name, gid_t unix_gid); NTSTATUS winbindd_print_groupmembers(struct talloc_dict *members, @@ -408,64 +346,17 @@ NTSTATUS winbindd_print_groupmembers(struct talloc_dict *members, void init_idmap_child(void); struct winbindd_child *idmap_child(void); -void winbindd_set_mapping_async(TALLOC_CTX *mem_ctx, const struct id_map *map, - void (*cont)(void *private_data, bool success), - void *private_data); -enum winbindd_result winbindd_dual_set_mapping(struct winbindd_domain *domain, - struct winbindd_cli_state *state); -void winbindd_remove_mapping_async(TALLOC_CTX *mem_ctx, const struct id_map *map, - void (*cont)(void *private_data, bool success), - void *private_data); -enum winbindd_result winbindd_dual_remove_mapping(struct winbindd_domain *domain, - struct winbindd_cli_state *state); -void winbindd_set_hwm_async(TALLOC_CTX *mem_ctx, const struct unixid *xid, - void (*cont)(void *private_data, bool success), - void *private_data); -enum winbindd_result winbindd_dual_set_hwm(struct winbindd_domain *domain, - struct winbindd_cli_state *state); -void winbindd_sids2xids_async(TALLOC_CTX *mem_ctx, void *sids, int size, - void (*cont)(void *private_data, bool success, void *data, int len), - void *private_data); -enum winbindd_result winbindd_dual_sids2xids(struct winbindd_domain *domain, - struct winbindd_cli_state *state); -void winbindd_sid2uid_async(TALLOC_CTX *mem_ctx, const DOM_SID *sid, - void (*cont)(void *private_data, bool success, uid_t uid), - void *private_data); -enum winbindd_result winbindd_dual_sid2uid(struct winbindd_domain *domain, - struct winbindd_cli_state *state); -void winbindd_sid2gid_async(TALLOC_CTX *mem_ctx, const DOM_SID *sid, - void (*cont)(void *private_data, bool success, gid_t gid), - void *private_data); -enum winbindd_result winbindd_dual_sid2gid(struct winbindd_domain *domain, - struct winbindd_cli_state *state); -void winbindd_uid2sid_async(TALLOC_CTX *mem_ctx, uid_t uid, - void (*cont)(void *private_data, bool success, const char *sid), - void *private_data); -enum winbindd_result winbindd_dual_uid2sid(struct winbindd_domain *domain, - struct winbindd_cli_state *state); -void winbindd_gid2sid_async(TALLOC_CTX *mem_ctx, gid_t gid, - void (*cont)(void *private_data, bool success, const char *sid), - void *private_data); -enum winbindd_result winbindd_dual_gid2sid(struct winbindd_domain *domain, - struct winbindd_cli_state *state); /* The following definitions come from winbindd/winbindd_locator.c */ void init_locator_child(void); struct winbindd_child *locator_child(void); -void winbindd_dsgetdcname(struct winbindd_cli_state *state); /* The following definitions come from winbindd/winbindd_misc.c */ -void winbindd_check_machine_acct(struct winbindd_cli_state *state); -enum winbindd_result winbindd_dual_check_machine_acct(struct winbindd_domain *domain, - struct winbindd_cli_state *state); -void winbindd_list_ent(struct winbindd_cli_state *state, enum ent_type type); void winbindd_list_trusted_domains(struct winbindd_cli_state *state); enum winbindd_result winbindd_dual_list_trusted_domains(struct winbindd_domain *domain, struct winbindd_cli_state *state); -enum winbindd_result winbindd_dual_getdcname(struct winbindd_domain *domain, - struct winbindd_cli_state *state); void winbindd_show_sequence(struct winbindd_cli_state *state); enum winbindd_result winbindd_dual_show_sequence(struct winbindd_domain *domain, struct winbindd_cli_state *state); @@ -518,51 +409,6 @@ enum winbindd_result winbindd_dual_pam_logoff(struct winbindd_domain *domain, void winbindd_pam_chng_pswd_auth_crap(struct winbindd_cli_state *state); enum winbindd_result winbindd_dual_pam_chng_pswd_auth_crap(struct winbindd_domain *domainSt, struct winbindd_cli_state *state); -/* The following definitions come from winbindd/winbindd_passdb.c */ - - -/* The following definitions come from winbindd/winbindd_reconnect.c */ - - -/* The following definitions come from winbindd/winbindd_sid.c */ - -void winbindd_lookupsid(struct winbindd_cli_state *state); -void winbindd_lookupname(struct winbindd_cli_state *state); -void winbindd_lookuprids(struct winbindd_cli_state *state); -void winbindd_sid_to_uid(struct winbindd_cli_state *state); -void winbindd_sid_to_gid(struct winbindd_cli_state *state); -void winbindd_set_mapping(struct winbindd_cli_state *state); -void winbindd_remove_mapping(struct winbindd_cli_state *state); -void winbindd_set_hwm(struct winbindd_cli_state *state); -void winbindd_uid_to_sid(struct winbindd_cli_state *state); -void winbindd_gid_to_sid(struct winbindd_cli_state *state); -void winbindd_allocate_uid(struct winbindd_cli_state *state); -enum winbindd_result winbindd_dual_allocate_uid(struct winbindd_domain *domain, - struct winbindd_cli_state *state); -void winbindd_allocate_gid(struct winbindd_cli_state *state); -enum winbindd_result winbindd_dual_allocate_gid(struct winbindd_domain *domain, - struct winbindd_cli_state *state); - -/* The following definitions come from winbindd/winbindd_user.c */ - -bool fillup_pw_field(const char *lp_template, - const char *username, - const char *domname, - uid_t uid, - gid_t gid, - const char *in, - fstring out); - -enum winbindd_result winbindd_dual_userinfo(struct winbindd_domain *domain, - struct winbindd_cli_state *state); -void winbindd_getpwnam(struct winbindd_cli_state *state); -void winbindd_getpwuid(struct winbindd_cli_state *state); -void winbindd_getpwsid(struct winbindd_cli_state *state); -void winbindd_setpwent(struct winbindd_cli_state *state); -void winbindd_endpwent(struct winbindd_cli_state *state); -void winbindd_getpwent(struct winbindd_cli_state *state); -void winbindd_list_users(struct winbindd_cli_state *state); - /* The following definitions come from winbindd/winbindd_util.c */ struct winbindd_domain *domain_list(void); @@ -582,19 +428,6 @@ struct winbindd_domain *find_root_domain(void); struct winbindd_domain *find_builtin_domain(void); struct winbindd_domain *find_lookup_domain_from_sid(const DOM_SID *sid); struct winbindd_domain *find_lookup_domain_from_name(const char *domain_name); -bool winbindd_lookup_sid_by_name(TALLOC_CTX *mem_ctx, - enum winbindd_cmd orig_cmd, - struct winbindd_domain *domain, - const char *domain_name, - const char *name, DOM_SID *sid, - enum lsa_SidType *type); -bool winbindd_lookup_name_by_sid(TALLOC_CTX *mem_ctx, - struct winbindd_domain *domain, - DOM_SID *sid, - char **dom_name, - char **name, - enum lsa_SidType *type); -void free_getent_state(struct getent_state *state); bool parse_domain_user(const char *domuser, fstring domain, fstring user); bool parse_domain_user_talloc(TALLOC_CTX *mem_ctx, const char *domuser, char **domain, char **user); @@ -641,6 +474,7 @@ void winbindd_unset_locator_kdc_env(const struct winbindd_domain *domain); void winbindd_set_locator_kdc_envs(const struct winbindd_domain *domain); void winbindd_unset_locator_kdc_env(const struct winbindd_domain *domain); void set_auth_errors(struct winbindd_response *resp, NTSTATUS result); +bool is_domain_offline(const struct winbindd_domain *domain); /* The following definitions come from winbindd/winbindd_wins.c */ @@ -995,6 +829,13 @@ struct tevent_req *winbindd_check_machine_acct_send(TALLOC_CTX *mem_ctx, NTSTATUS winbindd_check_machine_acct_recv(struct tevent_req *req, struct winbindd_response *presp); +struct tevent_req *winbindd_ping_dc_send(TALLOC_CTX *mem_ctx, + struct tevent_context *ev, + struct winbindd_cli_state *cli, + struct winbindd_request *request); +NTSTATUS winbindd_ping_dc_recv(struct tevent_req *req, + struct winbindd_response *presp); + struct tevent_req *winbindd_change_machine_acct_send(TALLOC_CTX *mem_ctx, struct tevent_context *ev, struct winbindd_cli_state *cli, diff --git a/source3/winbindd/winbindd_reconnect.c b/source3/winbindd/winbindd_reconnect.c index 3efd4a9428..bf6e577f29 100644 --- a/source3/winbindd/winbindd_reconnect.c +++ b/source3/winbindd/winbindd_reconnect.c @@ -279,21 +279,15 @@ static NTSTATUS password_policy(struct winbindd_domain *domain, /* get a list of trusted domains */ static NTSTATUS trusted_domains(struct winbindd_domain *domain, TALLOC_CTX *mem_ctx, - uint32 *num_domains, - char ***names, - char ***alt_names, - DOM_SID **dom_sids) + struct netr_DomainTrustList *trusts) { NTSTATUS result; - result = msrpc_methods.trusted_domains(domain, mem_ctx, - num_domains, names, - alt_names, dom_sids); + result = msrpc_methods.trusted_domains(domain, mem_ctx, trusts); if (NT_STATUS_EQUAL(result, NT_STATUS_UNSUCCESSFUL)) result = msrpc_methods.trusted_domains(domain, mem_ctx, - num_domains, names, - alt_names, dom_sids); + trusts); return result; } diff --git a/source3/winbindd/winbindd_rpc.c b/source3/winbindd/winbindd_rpc.c index b6cb56e02d..599c888aad 100644 --- a/source3/winbindd/winbindd_rpc.c +++ b/source3/winbindd/winbindd_rpc.c @@ -194,7 +194,7 @@ static NTSTATUS enum_dom_groups(struct winbindd_domain *domain, talloc_destroy(mem_ctx2); } while (NT_STATUS_EQUAL(status, STATUS_MORE_ENTRIES)); - return NT_STATUS_OK; + return status; } /* List all domain groups */ @@ -264,7 +264,7 @@ static NTSTATUS enum_local_groups(struct winbindd_domain *domain, } while (NT_STATUS_EQUAL(result, STATUS_MORE_ENTRIES)); - return NT_STATUS_OK; + return result; } /* convert a single name to a sid in a domain */ @@ -782,16 +782,16 @@ static NTSTATUS lookup_groupmem(struct winbindd_domain *domain, if (!NT_STATUS_IS_OK(result)) return result; - *num_names = rids->count; - rid_mem = rids->rids; - - if (!*num_names) { + if (!rids || !rids->count) { names = NULL; name_types = NULL; sid_mem = NULL; return NT_STATUS_OK; } + *num_names = rids->count; + rid_mem = rids->rids; + /* Step #2: Convert list of rids into list of usernames. Do this in bunches of ~1000 to avoid crashing NT4. It looks like there is a buffer overflow or something like that lurking around @@ -1027,10 +1027,7 @@ static NTSTATUS sequence_number(struct winbindd_domain *domain, uint32 *seq) /* get a list of trusted domains */ static NTSTATUS trusted_domains(struct winbindd_domain *domain, TALLOC_CTX *mem_ctx, - uint32 *num_domains, - char ***names, - char ***alt_names, - DOM_SID **dom_sids) + struct netr_DomainTrustList *trusts) { NTSTATUS result = NT_STATUS_UNSUCCESSFUL; uint32 enum_ctx = 0; @@ -1039,10 +1036,7 @@ static NTSTATUS trusted_domains(struct winbindd_domain *domain, DEBUG(3,("rpc: trusted_domains\n")); - *num_domains = 0; - *names = NULL; - *alt_names = NULL; - *dom_sids = NULL; + ZERO_STRUCTP(trusts); result = cm_connect_lsa(domain, mem_ctx, &cli, &lsa_policy); if (!NT_STATUS_IS_OK(result)) @@ -1065,22 +1059,33 @@ static NTSTATUS trusted_domains(struct winbindd_domain *domain, !NT_STATUS_EQUAL(result, STATUS_MORE_ENTRIES)) break; - start_idx = *num_domains; - *num_domains += dom_list.count; - *names = TALLOC_REALLOC_ARRAY(mem_ctx, *names, - char *, *num_domains); - *dom_sids = TALLOC_REALLOC_ARRAY(mem_ctx, *dom_sids, - DOM_SID, *num_domains); - *alt_names = TALLOC_REALLOC_ARRAY(mem_ctx, *alt_names, - char *, *num_domains); - if ((*names == NULL) || (*dom_sids == NULL) || - (*alt_names == NULL)) + start_idx = trusts->count; + trusts->count += dom_list.count; + + trusts->array = talloc_realloc( + mem_ctx, trusts->array, struct netr_DomainTrust, + trusts->count); + if (trusts->array == NULL) { return NT_STATUS_NO_MEMORY; + } for (i=0; i<dom_list.count; i++) { - (*names)[start_idx+i] = CONST_DISCARD(char *, dom_list.domains[i].name.string); - (*dom_sids)[start_idx+i] = *dom_list.domains[i].sid; - (*alt_names)[start_idx+i] = talloc_strdup(mem_ctx, ""); + struct netr_DomainTrust *trust = &trusts->array[i]; + struct dom_sid *sid; + + ZERO_STRUCTP(trust); + + trust->netbios_name = talloc_move( + trusts->array, + &dom_list.domains[i].name.string); + trust->dns_name = NULL; + + sid = talloc(trusts->array, struct dom_sid); + if (sid == NULL) { + return NT_STATUS_NO_MEMORY; + } + sid_copy(sid, dom_list.domains[i].sid); + trust->sid = sid; } } return result; @@ -1253,7 +1258,7 @@ NTSTATUS winbindd_lookup_names(TALLOC_CTX *mem_ctx, NTSTATUS status; struct rpc_pipe_client *cli = NULL; struct policy_handle lsa_policy; - unsigned int orig_timeout; + unsigned int orig_timeout = 0; lookup_names_fn_t lookup_names_fn = rpccli_lsa_lookup_names; if (domain->can_do_ncacn_ip_tcp) { @@ -1276,12 +1281,8 @@ NTSTATUS winbindd_lookup_names(TALLOC_CTX *mem_ctx, * This call can take a long time * allow the server to time out. * 35 seconds should do it. - * NB - * only do this when the undelying transport is named pipe. */ - if (cli->transport->transport == NCACN_NP) { - orig_timeout = rpccli_set_timeout(cli, 35000); - } + orig_timeout = rpccli_set_timeout(cli, 35000); status = lookup_names_fn(cli, mem_ctx, @@ -1294,9 +1295,7 @@ NTSTATUS winbindd_lookup_names(TALLOC_CTX *mem_ctx, types); /* And restore our original timeout. */ - if (cli->transport->transport == NCACN_NP) { - rpccli_set_timeout(cli, orig_timeout); - } + rpccli_set_timeout(cli, orig_timeout); if (!NT_STATUS_IS_OK(status)) { return status; diff --git a/source3/winbindd/winbindd_user.c b/source3/winbindd/winbindd_user.c deleted file mode 100644 index b23b7df608..0000000000 --- a/source3/winbindd/winbindd_user.c +++ /dev/null @@ -1,112 +0,0 @@ -/* - Unix SMB/CIFS implementation. - - Winbind daemon - user related functions - - Copyright (C) Tim Potter 2000 - Copyright (C) Jeremy Allison 2001. - Copyright (C) Gerald (Jerry) Carter 2003. - - This program is free software; you can redistribute it and/or modify - it under the terms of the GNU General Public License as published by - the Free Software Foundation; either version 3 of the License, or - (at your option) any later version. - - This program is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU General Public License for more details. - - You should have received a copy of the GNU General Public License - along with this program. If not, see <http://www.gnu.org/licenses/>. -*/ - -#include "includes.h" -#include "winbindd.h" - -#undef DBGC_CLASS -#define DBGC_CLASS DBGC_WINBIND - -bool fillup_pw_field(const char *lp_template, - const char *username, - const char *domname, - uid_t uid, - gid_t gid, - const char *in, - fstring out) -{ - char *templ; - - if (out == NULL) - return False; - - /* The substitution of %U and %D in the 'template - homedir' is done by talloc_sub_specified() below. - If we have an in string (which means the value has already - been set in the nss_info backend), then use that. - Otherwise use the template value passed in. */ - - if ( in && !strequal(in,"") && lp_security() == SEC_ADS ) { - templ = talloc_sub_specified(NULL, in, - username, domname, - uid, gid); - } else { - templ = talloc_sub_specified(NULL, lp_template, - username, domname, - uid, gid); - } - - if (!templ) - return False; - - safe_strcpy(out, templ, sizeof(fstring) - 1); - TALLOC_FREE(templ); - - return True; - -} - -/* Wrapper for domain->methods->query_user, only on the parent->child pipe */ - -enum winbindd_result winbindd_dual_userinfo(struct winbindd_domain *domain, - struct winbindd_cli_state *state) -{ - DOM_SID sid; - struct wbint_userinfo user_info; - NTSTATUS status; - - /* Ensure null termination */ - state->request->data.sid[sizeof(state->request->data.sid)-1]='\0'; - - DEBUG(3, ("[%5lu]: lookupsid %s\n", (unsigned long)state->pid, - state->request->data.sid)); - - if (!string_to_sid(&sid, state->request->data.sid)) { - DEBUG(5, ("%s not a SID\n", state->request->data.sid)); - return WINBINDD_ERROR; - } - - status = domain->methods->query_user(domain, state->mem_ctx, - &sid, &user_info); - if (!NT_STATUS_IS_OK(status)) { - DEBUG(1, ("error getting user info for sid %s\n", - sid_string_dbg(&sid))); - return WINBINDD_ERROR; - } - - fstrcpy(state->response->data.user_info.acct_name, - user_info.acct_name); - fstrcpy(state->response->data.user_info.full_name, - user_info.full_name); - fstrcpy(state->response->data.user_info.homedir, user_info.homedir); - fstrcpy(state->response->data.user_info.shell, user_info.shell); - state->response->data.user_info.primary_gid = user_info.primary_gid; - if (!sid_peek_check_rid(&domain->sid, &user_info.group_sid, - &state->response->data.user_info.group_rid)) { - DEBUG(1, ("Could not extract group rid out of %s\n", - sid_string_dbg(&sid))); - return WINBINDD_ERROR; - } - - return WINBINDD_OK; -} diff --git a/source3/winbindd/winbindd_util.c b/source3/winbindd/winbindd_util.c index ff8c101b37..17603820d4 100644 --- a/source3/winbindd/winbindd_util.c +++ b/source3/winbindd/winbindd_util.c @@ -868,95 +868,6 @@ struct winbindd_domain *find_lookup_domain_from_name(const char *domain_name) return find_our_domain(); } -/* Lookup a sid in a domain from a name */ - -bool winbindd_lookup_sid_by_name(TALLOC_CTX *mem_ctx, - enum winbindd_cmd orig_cmd, - struct winbindd_domain *domain, - const char *domain_name, - const char *name, DOM_SID *sid, - enum lsa_SidType *type) -{ - NTSTATUS result; - - /* - * For all but LOOKUPNAME we have to avoid nss calls to avoid - * recursion - */ - result = domain->methods->name_to_sid( - domain, mem_ctx, domain_name, name, - orig_cmd == WINBINDD_LOOKUPNAME ? 0 : LOOKUP_NAME_NO_NSS, - sid, type); - - /* Return sid and type if lookup successful */ - if (!NT_STATUS_IS_OK(result)) { - *type = SID_NAME_UNKNOWN; - } - - return NT_STATUS_IS_OK(result); -} - -/** - * @brief Lookup a name in a domain from a sid. - * - * @param sid Security ID you want to look up. - * @param name On success, set to the name corresponding to @p sid. - * @param dom_name On success, set to the 'domain name' corresponding to @p sid. - * @param type On success, contains the type of name: alias, group or - * user. - * @retval True if the name exists, in which case @p name and @p type - * are set, otherwise False. - **/ -bool winbindd_lookup_name_by_sid(TALLOC_CTX *mem_ctx, - struct winbindd_domain *domain, - DOM_SID *sid, - char **dom_name, - char **name, - enum lsa_SidType *type) -{ - NTSTATUS result; - - *dom_name = NULL; - *name = NULL; - - /* Lookup name */ - - result = domain->methods->sid_to_name(domain, mem_ctx, sid, dom_name, name, type); - - /* Return name and type if successful */ - - if (NT_STATUS_IS_OK(result)) { - return True; - } - - *type = SID_NAME_UNKNOWN; - - return False; -} - -/* Free state information held for {set,get,end}{pw,gr}ent() functions */ - -void free_getent_state(struct getent_state *state) -{ - struct getent_state *temp; - - /* Iterate over state list */ - - temp = state; - - while(temp != NULL) { - struct getent_state *next = temp->next; - - /* Free sam entries then list entry */ - - SAFE_FREE(state->sam_entries); - DLIST_REMOVE(state, state); - - SAFE_FREE(temp); - temp = next; - } -} - /* Is this a domain which we may assume no DOMAIN\ prefix? */ static bool assume_domain(const char *domain) @@ -1550,3 +1461,14 @@ void set_auth_errors(struct winbindd_response *resp, NTSTATUS result) get_friendly_nt_error_msg(result)); resp->data.auth.pam_error = nt_status_to_pam(result); } + +bool is_domain_offline(const struct winbindd_domain *domain) +{ + if (!lp_winbind_offline_logon()) { + return false; + } + if (get_global_winbindd_state_offline()) { + return true; + } + return !domain->online; +} diff --git a/source4/heimdal/lib/wind/rfc3454.txt b/source4/heimdal/lib/wind/rfc3454.txt deleted file mode 100644 index 26a1e6c74d..0000000000 --- a/source4/heimdal/lib/wind/rfc3454.txt +++ /dev/null @@ -1,5099 +0,0 @@ - - - - - - -Network Working Group P. Hoffman -Request for Comments: 3454 IMC & VPNC -Category: Standards Track M. Blanchet - Viagenie - December 2002 - - - Preparation of Internationalized Strings ("stringprep") - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2002). All Rights Reserved. - -Abstract - - This document describes a framework for preparing Unicode text - strings in order to increase the likelihood that string input and - string comparison work in ways that make sense for typical users - throughout the world. The stringprep protocol is useful for protocol - identifier values, company and personal names, internationalized - domain names, and other text strings. - - This document does not specify how protocols should prepare text - strings. Protocols must create profiles of stringprep in order to - fully specify the processing options. - -Table of Contents - - 1. Introduction....................................................3 - 1.1 Terminology..................................................4 - 1.2 Using stringprep in protocols................................4 - 2. Preparation Overview............................................6 - 3. Mapping.........................................................7 - 3.1 Commonly mapped to nothing...................................7 - 3.2 Case folding.................................................8 - 4. Normalization...................................................9 - 5. Prohibited Output..............................................10 - 5.1 Space characters............................................11 - 5.2 Control characters..........................................11 - 5.3 Private use.................................................12 - - - -Hoffman & Blanchet Standards Track [Page 1] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 5.4 Non-character code points...................................12 - 5.5 Surrogate codes.............................................13 - 5.6 Inappropriate for plain text................................13 - 5.7 Inappropriate for canonical representation..................13 - 5.8 Change display properties or deprecated.....................13 - 5.9 Tagging characters..........................................14 - 6. Bidirectional Characters.......................................14 - 7. Unassigned Code Points in Stringprep Profiles..................15 - 7.1 Categories of code points...................................16 - 7.2 Reasons for difference between stored strings and queries...17 - 7.3 Versions of applications and stored strings.................18 - 8. References.....................................................19 - 8.1 Normative references........................................19 - 8.2 Informative references......................................19 - 9. Security Considerations........................................19 - 9.1 Stringprep-specific security considerations.................19 - 9.2 Generic Unicode security considerations.....................20 - 10. IANA Considerations...........................................21 - 11. Acknowledgements..............................................22 - A. Unicode repertoires............................................23 - A.1 Unassigned code points in Unicode 3.2.......................23 - B. Mapping Tables.................................................31 - B.1 Commonly mapped to nothing..................................31 - B.2 Mapping for case-folding used with NFKC.....................32 - B.3 Mapping for case-folding used with no normalization.........61 - C. Prohibition tables.............................................78 - C.1 Space characters............................................78 - C.1.1 ASCII space characters..................................78 - C.1.2 Non-ASCII space characters..............................79 - C.2 Control characters..........................................79 - C.2.1 ASCII control characters................................79 - C.2.2 Non-ASCII control characters............................79 - C.3 Private use.................................................80 - C.4 Non-character code points...................................80 - C.5 Surrogate codes.............................................80 - C.6 Inappropriate for plain text................................80 - C.7 Inappropriate for canonical representation..................81 - C.8 Change display properties or are deprecated.................81 - C.9 Tagging characters..........................................81 - D. Bidirectional tables...........................................81 - D.1 Characters with bidirectional property "R" or "AL"..........81 - D.2 Characters with bidirectional property "L"..................82 - Authors' Addresses................................................90 - Full Copyright Statement..........................................91 - - - - - - - -Hoffman & Blanchet Standards Track [Page 2] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - -1. Introduction - - Application programs can display text in many different ways. - Similarly, a user can enter text into an application program in a - myriad of fashions. Internationalized text (that is, text that is - not restricted to the narrow set of US-ASCII characters) has many - input and display behaviors that make it difficult to compare text in - a consistent fashion. - - This document specifies a framework of processing rules for Unicode - text. Other protocols can create profiles of these rules; these - profiles will allow users to enter internationalized text strings in - applications and have the highest chance of getting the content of - the strings correct. In this case, "correct" means that if two - different people enter what they think is the same string into two - different input mechanisms, the strings should match on a character- - by-character basis. - - This framework does not describe how data is transcoded from other - character sets into Unicode. In systems that uses non-Unicode - character sets, the transcoding algorithm is a critical part of - enabling secure and "correct" operation of internationalized text - strings. - - In addition to helping string matching, profiles of stringprep can - also exclude characters that should not normally appear in text that - is used in the protocol. The profile can prevent such characters by - changing the characters to be excluded to other characters, by - removing those characters, or by causing an error if the characters - would appear in the output. For example, because the backspace - character can cause unpredictable display results, a profile can - specify that a string containing a backspace character would cause an - error. - - A profile of stringprep converts a single string of input characters - to a string of output characters, or returns an error if the output - string would contain a prohibited character. Stringprep profiles - cannot both emit a string and return an error. - - Stringprep profiles cannot account for all of the variations that - might occur or that a user might expect. In particular, a profile - will not be able to account for choice of spellings in all languages - for all scripts because the number of alternative spellings of words - and phrases is immense. Users would probably expect all spelling - equivalents to be made equivalent, or none of them to be. Examples - of spelling equivalents include "theater" vs. "theatre", and - "hemoglobin" vs. "h<U+00E6>moglobin" in American vs. British English. - Other examples are simplified Chinese spellings of names (for - - - -Hoffman & Blanchet Standards Track [Page 3] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - example,"<U+7EDF><U+4E00><U+7801>") vs. the equivalent traditional - Chinese spelling (for example, "<U+7D71><U+4E00><U+78BC>"). - Language-specific equivalences such as "Aepfel" vs. "<U+00C4>pfel", - which are sometimes considered equivalent in German, may not be - considered equivalent in other languages. - -1.1 Terminology - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in BCP 14, RFC 2119 - [RFC2119]. - - Note: A glossary of terms used in Unicode and ISO/IEC 10646 can be - found in [Glossary]. Information on the 10646/Unicode character - encoding model can be found in [CharModel]. - - Character names in this document use the notation for code points and - names from the Unicode Standard [Unicode3.2] and ISO/IEC 10646 - [ISO10646]. For example, the letter "a" may be represented as either - "U+0061" or "LATIN SMALL LETTER A". In the lists of mappings and the - prohibited characters, the "U+" is left off to make the lists easier - to read. The comments for character ranges are shown in square - brackets (such as "[CONTROL CHARACTERS]") and do not come from the - standards. - -1.2 Using stringprep in protocols - - The stringprep protocol does not stand on its own; it has to be used - by other protocols at precisely-defined places in those other - protocols. For example, a protocol that has strings that come from - the entire ISO/IEC 10646 [ISO10646] character repertoire might - specify that only strings that have been processed with a particular - profile of stringprep are legal. Another example would be a protocol - that does string comparison as a step in the protocol; that protocol - might specify that such comparison is done only after processing the - strings with a specific profile of stringprep. - - When two protocols that use different profiles of stringprep - interoperate, there may be conflict about what characters are and are - not allowed in the final string. Thus, protocol developers should - strongly consider re-using existing profiles of stringprep. - - When developers wish to allow users as wide of a range of characters - as possible in input text strings, they should, where possible, cause - stringprep to convert characters from the input string to a canonical - form instead of prohibiting them. - - - - -Hoffman & Blanchet Standards Track [Page 4] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - Although it would be easy to use the stringprep process to "correct" - perceived mis-features or bugs in the current character standards, - stringprep profiles SHOULD NOT do so. - - A profile of stringprep can create tables different from those in the - appendixes of this document, but it will be an exception when they - do. The intention of stringprep is to define the tables and have the - profiles of stringprep select among those defined tables. - - A profile of stringprep MUST include all of the following: - - - The intended applicability of the profile - - - The character repertoire that is the input and output to stringprep - (which is Unicode 3.2 for this version of stringprep) - - - The mapping tables from this document used (as described in section - 3) - - - Any additional mapping tables specific to the profile - - - The Unicode normalization used, if any (as described in section 4) - - - The tables from this document of characters that are prohibited as - output (as described in section 5) - - - The bidirectional string testing used, if any (as described in - section 6) - - - Any additional characters that are prohibited as output specific to - the profile - - Each profile MUST state the character repertoire on which the profile - will operate. Appendix A lists the Unicode repertoires that can be - selected. No repertoire is ever complete, and it is expected that - characters will be added to the Unicode repertoire for the - foreseeable future. Section 7 of this document describes how to - handle characters that are assigned in later versions of the Unicode - repertories. Subsections of appendix A also list unassigned code - points for each repertoire. - - This document is for Unicode version 3.2, and should not be - considered to automatically apply to later Unicode versions. The - IETF, through an explicit standards action, may update this document - as appropriate to handle later Unicode versions. - - - - - - -Hoffman & Blanchet Standards Track [Page 5] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - This document lists the unassigned code points in the range 0 to - 10FFFF for Unicode 3.2 in appendix A. The list in appendix A MUST be - used by implementations of this specification. If there are any - discrepancies between the list in appendix A and the Unicode 3.2 - specification, the list in appendix A always takes precedence. - - Each profile of stringprep MUST be registered with IANA. The - registration procedure is described in the IANA Considerations - appendix; basically, the IESG must review each profile of stringprep. - Protocol developers are strongly encouraged to look through the IANA - profile registry when creating new profiles for stringprep, and to - re-use logic from earlier profiles where possible in new profiles. - In some cases, an existing profile can be reused by a different - protocol. - -2. Preparation Overview - - The steps for preparing strings are: - - 1) Map -- For each character in the input, check if it has a mapping - and, if so, replace it with its mapping. This is described in - section 3. - - 2) Normalize -- Possibly normalize the result of step 1 using Unicode - normalization. This is described in section 4. - - 3) Prohibit -- Check for any characters that are not allowed in the - output. If any are found, return an error. This is described in - section 5. - - 4) Check bidi -- Possibly check for right-to-left characters, and if - any are found, make sure that the whole string satisfies the - requirements for bidirectional strings. If the string does not - satisfy the requirements for bidirectional strings, return an - error. This is described in section 6. - - The above steps MUST be performed in the order given to comply with - this specification. - - The mappings described in section 3, and the optional Unicode - normalization described in section 4, can be one-to-none, one-to-one, - one-to-many, many-to-one, or many-to-many. That is, some characters - might be eliminated or replaced by more than one character, and the - output of this step might be shorter or longer than the input. - Because of this, the system using stringprep MUST be prepared to - receive a longer or shorter string than the one input in the - stringprep algorithm. - - - - -Hoffman & Blanchet Standards Track [Page 6] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - -3. Mapping - - Each character in the input stream MUST be checked against a mapping - table. The mapping table SHOULD come from this document, although - the mapping table MAY be added to or altered by the profile. The - mapping tables are subsections of appendix B. - - The lists in appendix B MUST be used by implementations of this - specification. If there are any discrepancies between the lists in - appendix B and subsections below, the lists in appendix B always - takes precedence. - - For any individual character, the mapping table MAY specify that a - character be mapped to nothing, or mapped to one other character, or - mapped to a string of other characters. - - Mapped characters are not re-scanned during the mapping step. That - is, if character A at position X is mapped to character B, character - B which is now at position X is not checked against the mapping - table. - -3.1 Commonly mapped to nothing - - The following characters are simply deleted from the input (that is, - they are mapped to nothing) because their presence or absence in - protocol identifiers should not make two strings different. They are - listed in Table B.1. - - Some characters are only useful in line-based text, and are otherwise - invisible and ignored. - - 00AD; SOFT HYPHEN - 1806; MONGOLIAN TODO SOFT HYPHEN - 200B; ZERO WIDTH SPACE - 2060; WORD JOINER - FEFF; ZERO WIDTH NO-BREAK SPACE - - Some characters affect glyph choice and glyph placement, but do not - bear semantics. - - 034F; COMBINING GRAPHEME JOINER - 180B; MONGOLIAN FREE VARIATION SELECTOR ONE - 180C; MONGOLIAN FREE VARIATION SELECTOR TWO - 180D; MONGOLIAN FREE VARIATION SELECTOR THREE - 200C; ZERO WIDTH NON-JOINER - 200D; ZERO WIDTH JOINER - FE00; VARIATION SELECTOR-1 - FE01; VARIATION SELECTOR-2 - - - -Hoffman & Blanchet Standards Track [Page 7] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - FE02; VARIATION SELECTOR-3 - FE03; VARIATION SELECTOR-4 - FE04; VARIATION SELECTOR-5 - FE05; VARIATION SELECTOR-6 - FE06; VARIATION SELECTOR-7 - FE07; VARIATION SELECTOR-8 - FE08; VARIATION SELECTOR-9 - FE09; VARIATION SELECTOR-10 - FE0A; VARIATION SELECTOR-11 - FE0B; VARIATION SELECTOR-12 - FE0C; VARIATION SELECTOR-13 - FE0D; VARIATION SELECTOR-14 - FE0E; VARIATION SELECTOR-15 - FE0F; VARIATION SELECTOR-16 - -3.2 Case folding - - If a profile is going to map characters for case-insensitive - comparison, that profile SHOULD map using either appendix B.2 or - appendix B.3. appendix B.2 is for profiles that also use Unicode - normalization form KC, while appendix B.3 is for profiles that do - not use Unicode normalization. These tables map from uppercase to - lowercase characters. Note that this could have been "change all - lowercase characters into uppercase characters". However, the - upper-to-lower folding was chosen because there is a tradition of - using lowercase in current Internet applications and protocols. - - If a profile creates its own mapping tables for case folding, they - SHOULD be based on [UTR21], and SHOULD map from uppercase characters - to lowercase. The "CaseFolding.txt" file from the Unicode database - SHOULD be used to prepare the mapping table. The profile SHOULD do - full case mapping (that is, using statuses C, F, and I). - - If the profile is using Unicode normalization form KC (as described - in section 4 of this document), it is important to note that there - are some characters that do not have mappings in [UTR21] but still - need processing. These characters include a few Greek characters and - many symbols that contain Latin characters. The list of characters - to add to the mapping table can determined by the following - algorithm: - - b = NormalizeWithKC(Fold(a)); - c = NormalizeWithKC(Fold(b)); - if c is not the same as b, add a mapping for "a to c". - - Because NormalizeWithKC(Fold(c)) always equals c, the table is stable - from that point on. - - - - -Hoffman & Blanchet Standards Track [Page 8] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - Appendix B.3 is derived from the CaseFolding-3.txt file associated - with Unicode 3.2; appendix B.2 is based on appendix B.3 with the - additional characters added from the algorithm above. - - Authors of profiles of this document need to consider the effects of - changing the mapping of any currently-assigned character when - updating their profiles. Adding a new mapping for a currently- - assigned character, or changing an existing mapping, could cause a - variance between the behavior of systems that have been updated and - systems that have not been updated. - -4. Normalization - - The output of the mapping step is optionally normalized using one of - the Unicode normalization forms, as described in [UAX15]. A profile - can specify one of two options for Unicode normalization: - - - no normalization - - - Unicode normalization with form KC - - A profile MAY choose to do no normalization. However, such a profile - can easily yield results that will be surprising to typical users, - depending on the input mechanism they use. For example, some input - mechanisms enter compatibility characters that look exactly like the - underlying characters, but have different code points. Another - example of where Unicode normalization helps create predictable - results is with characters that have multiple combining diacritics: - normalization orders those diacritics in a predictable fashion. - - On the other hand, Unicode normalization requires fairly large tables - and somewhat complicated character reordering logic. The size and - complexity should not be considered daunting except in the most - restricted of environments, and needs to be weighed against the - problems of user surprise from comparing unnormalized strings. Note - that the tables used for normalization are not given in this - document, but instead must be derived from the Unicode database, as - described in [UAX15]. - - There is a third form of normalization, Unicode normalization with - form C. If a profile is going to use a Unicode normalization, it - MUST use Unicode normalization form KC. Form KC maps many - "compatibility characters" to their equivalents. Some user interface - systems make it possible to enter compatibility characters instead of - the base equivalents. Thus, using form KC instead of form C will - cause more strings that users would expect to match to actually - match. - - - - -Hoffman & Blanchet Standards Track [Page 9] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - A profile that specifies Unicode normalization MUST use the - normalization in [UAX15] that is associated with the version of the - Unicode character set specified for the profile. - - The composition process described in [UAX15] requires a fixed - composition version of Unicode to ensure that strings normalized - under one version of Unicode remain normalized under all future - versions of Unicode. - - The IETF is relying on Unicode not to change the normalization of - currently-assigned characters in future versions of normalization. - If a future version of the normalization tables changes the - normalized value of an existing character, authors of profiles of - this document have to look at the changes very carefully before they - update their normalization tables. Such a change could cause a - variance between the behavior of systems that have been updated and - systems that have not been updated. - -5. Prohibited Output - - Before the text can be emitted, it MUST be checked for prohibited - code points. There are a variety of prohibited code points, as - described in this section. A profile of this document MAY use all or - some of the tables in appendix C. - - The stringprep process never emits both an error and a string. If an - error is detected during the checking for prohibited code points, - only an error is returned. - - Note that the subsections below describe how the tables in appendix C - were formed. They are here for people who want to understand more, - but they should be ignored by implementors. Implementations that use - tables MUST map based on the tables themselves, not based on the - descriptions in this section of how the tables were created. - - The lists in appendix C MUST be used by implementations of this - specification. If there are any discrepancies between the lists in - appendix C and subsections below, the lists in appendix C always take - precedence. - - Some code points listed in one section may also appear in other - sections. - - It is important to note that a profile of this document MAY prohibit - additional characters. - - - - - - -Hoffman & Blanchet Standards Track [Page 10] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - Each subsection of this section has a matching subsection in appendix - C. For example, the characters listed in section 5.1 are listed in - appendix C.1. - -5.1 Space characters - - Space characters can make accurate visual transcription of strings - nearly impossible and could lead to user entry errors in many ways. - Note that the list below is split into two tables in appendix C: - Table C.1.1 contains the ASCII code points, while Table C.1.2 - contains the non-ASCII code points. Most profiles of this document - that want to prohibit space characters will want to include both - tables. - - 0020; SPACE - 00A0; NO-BREAK SPACE - 1680; OGHAM SPACE MARK - 2000; EN QUAD - 2001; EM QUAD - 2002; EN SPACE - 2003; EM SPACE - 2004; THREE-PER-EM SPACE - 2005; FOUR-PER-EM SPACE - 2006; SIX-PER-EM SPACE - 2007; FIGURE SPACE - 2008; PUNCTUATION SPACE - 2009; THIN SPACE - 200A; HAIR SPACE - 200B; ZERO WIDTH SPACE - 202F; NARROW NO-BREAK SPACE - 205F; MEDIUM MATHEMATICAL SPACE - 3000; IDEOGRAPHIC SPACE - -5.2 Control characters - - Control characters (or characters with control function) cannot be - seen and can cause unpredictable results when displayed. Note that - the list below is split into two tables in appendix C: Table C.2.1 - contains the ASCII code points, while Table C.2.2 contains the non- - ASCII code points. Most profiles of this document that want to - prohibit control characters will want to include both tables. - - 0000-001F; [CONTROL CHARACTERS] - 007F; DELETE - 0080-009F; [CONTROL CHARACTERS] - 06DD; ARABIC END OF AYAH - 070F; SYRIAC ABBREVIATION MARK - 180E; MONGOLIAN VOWEL SEPARATOR - - - -Hoffman & Blanchet Standards Track [Page 11] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 200C; ZERO WIDTH NON-JOINER - 200D; ZERO WIDTH JOINER - 2028; LINE SEPARATOR - 2029; PARAGRAPH SEPARATOR - 2060; WORD JOINER - 2061; FUNCTION APPLICATION - 2062; INVISIBLE TIMES - 2063; INVISIBLE SEPARATOR - 206A-206F; [CONTROL CHARACTERS] - FEFF; ZERO WIDTH NO-BREAK SPACE - FFF9-FFFC; [CONTROL CHARACTERS] - 1D173-1D17A; [MUSICAL CONTROL CHARACTERS] - -5.3 Private use - - Because private-use characters do not have defined meanings, they are - likely to be prohibited. The private-use characters are: - - E000-F8FF; [PRIVATE USE, PLANE 0] - F0000-FFFFD; [PRIVATE USE, PLANE 15] - 100000-10FFFD; [PRIVATE USE, PLANE 16] - -5.4 Non-character code points - - Non-character code points are code points that have been allocated in - ISO/IEC 10646 but are not characters. Because they are already - assigned, they are guaranteed not to later change into characters. - - FDD0-FDEF; [NONCHARACTER CODE POINTS] - FFFE-FFFF; [NONCHARACTER CODE POINTS] - 1FFFE-1FFFF; [NONCHARACTER CODE POINTS] - 2FFFE-2FFFF; [NONCHARACTER CODE POINTS] - 3FFFE-3FFFF; [NONCHARACTER CODE POINTS] - 4FFFE-4FFFF; [NONCHARACTER CODE POINTS] - 5FFFE-5FFFF; [NONCHARACTER CODE POINTS] - 6FFFE-6FFFF; [NONCHARACTER CODE POINTS] - 7FFFE-7FFFF; [NONCHARACTER CODE POINTS] - 8FFFE-8FFFF; [NONCHARACTER CODE POINTS] - 9FFFE-9FFFF; [NONCHARACTER CODE POINTS] - AFFFE-AFFFF; [NONCHARACTER CODE POINTS] - BFFFE-BFFFF; [NONCHARACTER CODE POINTS] - CFFFE-CFFFF; [NONCHARACTER CODE POINTS] - DFFFE-DFFFF; [NONCHARACTER CODE POINTS] - EFFFE-EFFFF; [NONCHARACTER CODE POINTS] - FFFFE-FFFFF; [NONCHARACTER CODE POINTS] - 10FFFE-10FFFF; [NONCHARACTER CODE POINTS] - - - - - -Hoffman & Blanchet Standards Track [Page 12] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - The non-character code points are listed in the PropList.txt file - from the Unicode database. - -5.5 Surrogate codes - - The following code points are permanently reserved for use as - surrogate code values in the UTF-16 encoding, will never be assigned - to characters in the Unicode repertoire, and are therefore - prohibited: - - D800-DFFF; [SURROGATE CODES] - -5.6 Inappropriate for plain text - - The following characters do not appear in regular text. - - FFF9; INTERLINEAR ANNOTATION ANCHOR - FFFA; INTERLINEAR ANNOTATION SEPARATOR - FFFB; INTERLINEAR ANNOTATION TERMINATOR - FFFC; OBJECT REPLACEMENT CHARACTER - - Although the replacement character (U+FFFD) might be used when a - string is displayed, it doesn't make sense for it to be part of the - string itself. It is often displayed by renderers to indicate "there - would be some character here, but it cannot be rendered". For - example, on a computer with no Asian fonts, a string with three - ideographs might be rendered with three replacement characters. - - FFFD; REPLACEMENT CHARACTER - -5.7 Inappropriate for canonical representation - - The ideographic description characters allow different sequences of - characters to be rendered the same way, which makes them - inappropriate for strings that have to have a single canonical - representation. - - 2FF0-2FFB; [IDEOGRAPHIC DESCRIPTION CHARACTERS] - -5.8 Change display properties or are deprecated - - The following characters can cause changes in display or the order in - which characters appear when rendered, or are deprecated in Unicode. - - 0340; COMBINING GRAVE TONE MARK - 0341; COMBINING ACUTE TONE MARK - 200E; LEFT-TO-RIGHT MARK - 200F; RIGHT-TO-LEFT MARK - - - -Hoffman & Blanchet Standards Track [Page 13] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 202A; LEFT-TO-RIGHT EMBEDDING - 202B; RIGHT-TO-LEFT EMBEDDING - 202C; POP DIRECTIONAL FORMATTING - 202D; LEFT-TO-RIGHT OVERRIDE - 202E; RIGHT-TO-LEFT OVERRIDE - 206A; INHIBIT SYMMETRIC SWAPPING - 206B; ACTIVATE SYMMETRIC SWAPPING - 206C; INHIBIT ARABIC FORM SHAPING - 206D; ACTIVATE ARABIC FORM SHAPING - 206E; NATIONAL DIGIT SHAPES - 206F; NOMINAL DIGIT SHAPES - -5.9 Tagging characters - - The following characters are used for tagging text and are invisible. - - E0001; LANGUAGE TAG - E0020-E007F; [TAGGING CHARACTERS] - -6. Bidirectional Characters - - Most characters are displayed from left to right, but some are - displayed from right to left. This feature of Unicode is called - "bidirectional text", or "bidi" for short. The Unicode standard has - an extensive discussion of how to reorder glyphs for display when - dealing with bidirectional text such as Arabic or Hebrew. See [UAX9] - for more information. In particular, all Unicode text is stored in - logical order. - - A profile MAY choose to ignore bidirectional text. However, ignoring - bidirectional text can cause display ambiguities. For example, it is - quite easy to create two different strings with the same characters - (but in different order) that are correctly displayed identically. - Therefore, in order to avoid most problems with ambiguous - bidirectional text display, profile creators should strongly consider - including the bidirectional character handling described in this - section in their profile. - - The stringprep process never emits both an error and a string. If an - error is detected during the checking of bidirectional strings, only - an error is returned. - - [Unicode3.2] defines several bidirectional categories; each character - has one bidirectional category assigned to it. For the purposes of - the requirements below, an "RandALCat character" is a character that - has Unicode bidirectional categories "R" or "AL"; an "LCat character" - is a character that has Unicode bidirectional category "L". Note - - - - -Hoffman & Blanchet Standards Track [Page 14] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - that there are many characters which fall in neither of the above - definitions; Latin digits (<U+0030> through <U+0039>) are examples of - this because they have bidirectional category "EN". - - In any profile that specifies bidirectional character handling, all - three of the following requirements MUST be met: - - 1) The characters in section 5.8 MUST be prohibited. - - 2) If a string contains any RandALCat character, the string MUST NOT - contain any LCat character. - - 3) If a string contains any RandALCat character, a RandALCat - character MUST be the first character of the string, and a - RandALCat character MUST be the last character of the string. - - Note that requirement 3 prohibits strings such as <U+0627><U+0031> - ("aleph 1") but allows strings such as <U+0627><U+0031><U+0628> - ("aleph 1 beh"). [UAX9] goes into great detail about the display - order of strings that contain particular categories of characters in - particular sequences. - - Table D.1 lists the characters that belong to Unicode bidirectional - categories "R" and "AL". Table D.2 lists all the characters that - belong to Unicode bidirectonal category "L". These tables are - derived from [Unicode3.2]. - -7. Unassigned Code Points in Stringprep Profiles - - This section describes two different types of strings in typical - protocols where internationalized strings are used: "stored strings" - and "queries". Of course, different Internet protocols use strings - very differently, so these terms cannot be used exactly in every - protocol that needs to use stringprep. In general, "stored strings" - are strings that are used in protocol identifiers and named entities, - such as names in digital certificates and DNS domain name parts. - "Queries" are strings that are used to match against strings that are - stored identifiers, such as user-entered names for digital - certificate authorities and DNS lookups. - - All code points not assigned in the character repertoire named in a - stringprep profile are called "unassigned code points". Stored - strings using the profile MUST NOT contain any unassigned code - points. Queries for matching strings MAY contain unassigned code - points. Note that this is the only part of this document where the - requirements for queries differs from the requirements for stored - strings. - - - - -Hoffman & Blanchet Standards Track [Page 15] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - Using two different policies for where unassigned code points can - appear removes the need for versioning in protocols that use - stringprep profiles. This is very useful since it makes the overall - processing simpler and does not impose a "protocol" to handle - versioning. It is expected that the ISO/IEC 10646 and Unicode - repertoires will be updated fairly frequently; at the time that this - document is being written, it has happened approximately once a year. - Each time a new version of a repertoire appears, a new version of a - profile MAY be created. Some end users will want to use the new code - points as soon as they are defined. - - The list of unassigned code points MUST be given in a profile, and - that list MUST be used by implementations of the profile. - - The goal of the requirements in this section is to prevent - comparisons between two strings that were both permitted to contain - unassigned code points. When two strings X and Y are compared and - string Y was prepared in a way that permits unassigned code points, a - negative result to the comparison is not definitive; it's possible - that the strings don't match even though they would match if a more - recent version of the profile were used for Y. However, if both X - and Y were prepared in a way that permits unassigned code points, - something worse can happen: even a positive result for the comparison - is not definitive. It is possible that the strings do match even - though they would not match if a more recent version of the profile - were used (one that prohibits a code point appearing in both X and - Y). - - Due to the way that versioning is handled in this section, stored - strings that are embedded in structures that cannot be changed (such - as the signed parts of digital certificates) MUST NOT contain any - unassigned code points. - -7.1 Categories of code points - - Each code point in a repertoire named by a profile of stringprep can - be categorized by how it acts in the process described in earlier - sections of this document: - - AO Code points that can be in the output - - MN Code points that cannot be in the output because they - never appear as output from mapping or normalization - - D Code points that cannot be in the output because they are - disallowed in the prohibition step - - U Unassigned code points - - - -Hoffman & Blanchet Standards Track [Page 16] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - A subsequent version of a profile that references a newer version of - a repertoire with new code points will inherently have some code - points move from category U to either D, MN, or AO. For backwards - compatibility, a subsequent version of a profile MUST NOT move code - points from any other category. That is, current AO, MN, or D code - points MUST NOT ever change to a different category. - - Stored strings MUST NOT contain any code points outside of AO for the - latest version of a profile. That is, they are forbidden to contain - code points from the MN, D, or U categories. - - Applications creating queries MUST treat U code points as if they - were AO when preparing the query to be entered in the process - described by a profile of stringprep. Those applications MAY - optionally have a preprocessor that provide stricter checks: treating - unassigned code points in the input as errors, or warning the user - about the fact that the code point is unassigned in the version of a - profile that the software is based on; such a choice is a local - matter for the software. - -7.2 Reasons for the difference between stored strings and queries - - Different software using different versions of a stringprep profile - need to interoperate with maximal compatibility. The scheme - described in this section (stored strings MUST NOT contain unassigned - code points, queries MAY include unassigned code points) allows that - compatibility without introducing any known security or - interoperability issues. - - The list below shows what happens if a query contains a code point - from category U that is allowed in a newer version of a profile. The - query either matches the string that was intended, or matches no - string at all. In this list, the query comes from an application - using version "oldVersion" of a profile, the stored string was - created using version "newVersion" of the same profile, and the code - point X was in category U in oldVersion, and has changed category to - AO, MN, or D. There are 3 possible scenarios: - - 1. X is assigned to AO -- In newVersion, X is in category AO. - Because the application passed X through, it gets back a positive - match with the stored string. There is one exceptional case, - where X is a combining mark. - - The order of combining marks is normalized, so if another - combining mark Y has a lower combining class than X then XY will - be put in the canonical order YX. (Unassigned code points are - never reordered, so this doesn't happen in oldVersion). If the - query contains YX, the query will get positive match with the - - - -Hoffman & Blanchet Standards Track [Page 17] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - stored string. However, no string can be stored with XY, so a - query with XY will get a negative answer to the test for matching. - - 2. X is assigned to MN -- In newVersion, X is normalized to code - point "nX" and therefore X is now put in category MN. This cannot - exist in any stored string, so any query containing X will get a - negative answer to the test for matching. Note, however, if the - query had contained the letter nX, it would have positively - matched. - - 3. X is assigned to D -- In newVersion, X is in category D. This - cannot exist in any stored string, so any query containing X will - get a negative answer to the test for matching. - - In none of the cases does the query get data for a stored string - other than the one it actually tried to match against. - - Profiles are stable between versions in the following sense: If a - string S has been prepared using newVersion, then it will not change - if it is subsequently prepared using oldVersion. - -7.3 Versions of applications and stored strings - - Another way to see that this versioning system works is to compare - what happens when an application uses a newer or older version of a - profile. - - Newer query application -- Suppose that a querying application is - using version newVersion and the stored string was created using - version oldVersion. This case is simple: there will be no characters - in the stored string that cannot be queried by the application - because the new profile uses a superset of the code points used for - making the stored string. - - Newer stored string -- Suppose that a querying application is using - oldVersion and the stored string was created using a profile that - uses newVersion. Because the querying application let unassigned - code points pass through, the user can query on stored strings that - use code points in newVersion. No stored strings can have code - points that are unassigned in newVersion, since that is illegal. In - order to get a match, the querying application has to enter the - unassigned code points in the proper order, and has to use unassigned - code points that would make it through both the mapping and the - normalization steps. - - - - - - - -Hoffman & Blanchet Standards Track [Page 18] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - -8. References - -8.1 Normative references - - [UAX15] Mark Davis and Martin Duerst. Unicode Standard Annex - #15: Unicode Normalization Forms, Version 3.2.0. - <http://www.unicode.org/unicode/reports/tr15/tr15- - 22.html>. - - [Unicode3.2] The Unicode Consortium. The Unicode Standard, Version - 3.2.0 is defined by The Unicode Standard, Version 3.0 - (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), - as amended by the Unicode Standard Annex #27: Unicode - 3.1 (http://www.unicode.org/reports/tr27/) and by the - Unicode Standard Annex #28: Unicode 3.2 - (http://www.unicode.org/reports/tr28/). - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - -8.2 Informative references - - [CharModel] Unicode Technical Report;17, Character Encoding Model. - <http://www.unicode.org/unicode/reports/tr17/>. - - [Glossary] Unicode Glossary, <http://www.unicode.org/glossary/>. - - [ISO10646] ISO/IEC, "Information Technology - Universal Multiple- - Octet Coded Character Set (UCS) - Part 1: Architecture - and Basic Multilingual Plane", ISO/IEC 10646-1:2000, - October 2000. - - [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for IANA - Considerations", BCP 26, RFC 2434, October 1998. - - [UAX9] The Unicode Consortium. Unicode Standard Annex #9, The - Bidirectional Algorithm, - <http://www.unicode.org/unicode/reports/tr9/>. - - [UTR21] Mark Davis. Case Mappings. Unicode Technical Report 21. - <http://www.unicode.org/unicode/reports/tr21/>. - -9. Security Considerations - - Stringprep is used with Unicode characters. There are security - considerations that are specific to stringprep, and others that are - generic to using Unicode. - - - - -Hoffman & Blanchet Standards Track [Page 19] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - -9.1 Stringprep-specific security considerations - - The Unicode and ISO/IEC 10646 repertoires have many characters that - look similar. In many cases, users of security protocols might do - visual matching, such as when comparing the names of trusted third - parties. Because it is impossible to map similar-looking characters - without a great deal of context such as knowing the fonts used, - stringprep does nothing to map similar-looking characters together - nor to prohibit some characters because they look like others. User - applications can help disambiguate some similar-looking characters by - showing the user when a string changes between scripts. - - Most profiles of stringprep can cause changes in strings that are - input to stringprep. Because of this, protocols that have sets of - non-allowed characters or sequences MUST check for the non-allowed - characters or sequences after the stringprep processing. - - This document does not mandate the checking of bidirectional - characters in section 6. If the requirements in section 6 are not - used in a profile of stringprep, it is easy to create many strings - whose characters are in different order but are displayed - identically. This can cause security-related user confusion similar - to look-alike characters, as described above. - - Stringprep does not do anything to assure that any algorithms - translating characters from non-Unicode into Unicode produce the same - output in all implementations. - - Some Unicode codepoints are invisible. Protocols that allow these - characters (that is, do not map them out or prohibit them in - stringprep) can cause users confusion when two identical-looking - strings do not match. - -9.2 Generic Unicode security considerations - - Using Unicode characters explicitly forces applications to use - multi-octet characters. Converting an application from one that uses - single-octet characters to one that uses multi-octet characters must - be done very carefully, particularly in an application that checks - for values of characters or sorts characters. - - Protocols that use stringprep usually also use encodings of Unicode, - such as UTF-8 or UTF-16. Some applications using those encodings - have been known to not check for illegal or ill-formed sequences in - the encodings, and thereby have not detected sequences of octets that - would have been detected if they used just ASCII. For example, in - - - - - -Hoffman & Blanchet Standards Track [Page 20] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - UTF-8 the octet sequence "0xC0 0xAB" is an illegal formation of - U+002B (plus sign). All programs should reject any string that is an - illegal or ill-formed octet sequence for the encoding being used. - - Both Unicode normalization and conversion between Unicode encodings - can cause strings to grow or shrink. Programs that used fixed-size - buffers, or that make assumptions that buffers will always be greater - than or less than particular sizes, are likely to fail in insecure - fashions when using Unicode normalization or encoding conversions. - - Covering an extensive list of security threats and considerations on - the use of current and future versions of Unicode is outside of the - scope of this document. - -10. IANA Considerations - - Stringprep profiles MUST have IETF consensus as described in - [RFC2434]. Each profile MUST be reviewed by the IESG before it is - registered. The IESG MAY change a profile before registration. - - IANA has set up a registry of stringprep profiles. This registry is - a single text file that lists the known profiles. Each entry in the - registry has three fields: - - - Profile name - - - RFC in which the profile is defined - - - Indicator whether or not this is the newest version of the profile - - Each version of a profile will remain listed in the registry forever. - That is, if a new version of a profile supersedes an earlier version, - both versions will continue to be listed in the registry, but the - current version indicator will be turned off for the earlier version - and turned on for the newer version. - - It is probably harmful if a large number of profiles of stringprep - proliferate. Therefore, the IESG may reject proposals for new - profiles and instead suggest that protocols reuse existing profiles. - - - - - - - - - - - - -Hoffman & Blanchet Standards Track [Page 21] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - -11. Acknowledgements - - Many people from the IETF IDN Working Group and the Unicode Technical - Committee contributed ideas that went into the first document of this - document. Mark Davis and Patrik Faltstrom were particularly helpful - in some of the ideas, such as the versioning description. - - The IDN nameprep design team made many useful changes to the first - document. That team and its advisors include: - - Asmus Freytag - Cathy Wissink - Francois Yergeau - James Seng - Marc Blanchet - Mark Davis - Martin Duerst - Patrik Faltstrom - Paul Hoffman - - Additional significant improvements were proposed by: - - Jonathan Rosenne - Kent Karlsson - Scott Hollenbeck - Dave Crocker - Erik Nordmark - Matitiahu Allouche - - - - - - - - - - - - - - - - - - - - - - - -Hoffman & Blanchet Standards Track [Page 22] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - -A. Unicode repertoires - - The following is the only repertoire covered in this document: - - Unicode 3.2, as defined in [Unicode3.2]. - -A.1 Unassigned code points in Unicode 3.2 - - ----- Start Table A.1 ----- - 0221 - 0234-024F - 02AE-02AF - 02EF-02FF - 0350-035F - 0370-0373 - 0376-0379 - 037B-037D - 037F-0383 - 038B - 038D - 03A2 - 03CF - 03F7-03FF - 0487 - 04CF - 04F6-04F7 - 04FA-04FF - 0510-0530 - 0557-0558 - 0560 - 0588 - 058B-0590 - 05A2 - 05BA - 05C5-05CF - 05EB-05EF - 05F5-060B - 060D-061A - 061C-061E - 0620 - 063B-063F - 0656-065F - 06EE-06EF - 06FF - 070E - 072D-072F - 074B-077F - 07B2-0900 - - - -Hoffman & Blanchet Standards Track [Page 23] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 0904 - 093A-093B - 094E-094F - 0955-0957 - 0971-0980 - 0984 - 098D-098E - 0991-0992 - 09A9 - 09B1 - 09B3-09B5 - 09BA-09BB - 09BD - 09C5-09C6 - 09C9-09CA - 09CE-09D6 - 09D8-09DB - 09DE - 09E4-09E5 - 09FB-0A01 - 0A03-0A04 - 0A0B-0A0E - 0A11-0A12 - 0A29 - 0A31 - 0A34 - 0A37 - 0A3A-0A3B - 0A3D - 0A43-0A46 - 0A49-0A4A - 0A4E-0A58 - 0A5D - 0A5F-0A65 - 0A75-0A80 - 0A84 - 0A8C - 0A8E - 0A92 - 0AA9 - 0AB1 - 0AB4 - 0ABA-0ABB - 0AC6 - 0ACA - 0ACE-0ACF - 0AD1-0ADF - 0AE1-0AE5 - - - -Hoffman & Blanchet Standards Track [Page 24] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 0AF0-0B00 - 0B04 - 0B0D-0B0E - 0B11-0B12 - 0B29 - 0B31 - 0B34-0B35 - 0B3A-0B3B - 0B44-0B46 - 0B49-0B4A - 0B4E-0B55 - 0B58-0B5B - 0B5E - 0B62-0B65 - 0B71-0B81 - 0B84 - 0B8B-0B8D - 0B91 - 0B96-0B98 - 0B9B - 0B9D - 0BA0-0BA2 - 0BA5-0BA7 - 0BAB-0BAD - 0BB6 - 0BBA-0BBD - 0BC3-0BC5 - 0BC9 - 0BCE-0BD6 - 0BD8-0BE6 - 0BF3-0C00 - 0C04 - 0C0D - 0C11 - 0C29 - 0C34 - 0C3A-0C3D - 0C45 - 0C49 - 0C4E-0C54 - 0C57-0C5F - 0C62-0C65 - 0C70-0C81 - 0C84 - 0C8D - 0C91 - 0CA9 - 0CB4 - - - -Hoffman & Blanchet Standards Track [Page 25] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 0CBA-0CBD - 0CC5 - 0CC9 - 0CCE-0CD4 - 0CD7-0CDD - 0CDF - 0CE2-0CE5 - 0CF0-0D01 - 0D04 - 0D0D - 0D11 - 0D29 - 0D3A-0D3D - 0D44-0D45 - 0D49 - 0D4E-0D56 - 0D58-0D5F - 0D62-0D65 - 0D70-0D81 - 0D84 - 0D97-0D99 - 0DB2 - 0DBC - 0DBE-0DBF - 0DC7-0DC9 - 0DCB-0DCE - 0DD5 - 0DD7 - 0DE0-0DF1 - 0DF5-0E00 - 0E3B-0E3E - 0E5C-0E80 - 0E83 - 0E85-0E86 - 0E89 - 0E8B-0E8C - 0E8E-0E93 - 0E98 - 0EA0 - 0EA4 - 0EA6 - 0EA8-0EA9 - 0EAC - 0EBA - 0EBE-0EBF - 0EC5 - 0EC7 - 0ECE-0ECF - - - -Hoffman & Blanchet Standards Track [Page 26] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 0EDA-0EDB - 0EDE-0EFF - 0F48 - 0F6B-0F70 - 0F8C-0F8F - 0F98 - 0FBD - 0FCD-0FCE - 0FD0-0FFF - 1022 - 1028 - 102B - 1033-1035 - 103A-103F - 105A-109F - 10C6-10CF - 10F9-10FA - 10FC-10FF - 115A-115E - 11A3-11A7 - 11FA-11FF - 1207 - 1247 - 1249 - 124E-124F - 1257 - 1259 - 125E-125F - 1287 - 1289 - 128E-128F - 12AF - 12B1 - 12B6-12B7 - 12BF - 12C1 - 12C6-12C7 - 12CF - 12D7 - 12EF - 130F - 1311 - 1316-1317 - 131F - 1347 - 135B-1360 - 137D-139F - 13F5-1400 - - - -Hoffman & Blanchet Standards Track [Page 27] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 1677-167F - 169D-169F - 16F1-16FF - 170D - 1715-171F - 1737-173F - 1754-175F - 176D - 1771 - 1774-177F - 17DD-17DF - 17EA-17FF - 180F - 181A-181F - 1878-187F - 18AA-1DFF - 1E9C-1E9F - 1EFA-1EFF - 1F16-1F17 - 1F1E-1F1F - 1F46-1F47 - 1F4E-1F4F - 1F58 - 1F5A - 1F5C - 1F5E - 1F7E-1F7F - 1FB5 - 1FC5 - 1FD4-1FD5 - 1FDC - 1FF0-1FF1 - 1FF5 - 1FFF - 2053-2056 - 2058-205E - 2064-2069 - 2072-2073 - 208F-209F - 20B2-20CF - 20EB-20FF - 213B-213C - 214C-2152 - 2184-218F - 23CF-23FF - 2427-243F - 244B-245F - 24FF - - - -Hoffman & Blanchet Standards Track [Page 28] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 2614-2615 - 2618 - 267E-267F - 268A-2700 - 2705 - 270A-270B - 2728 - 274C - 274E - 2753-2755 - 2757 - 275F-2760 - 2795-2797 - 27B0 - 27BF-27CF - 27EC-27EF - 2B00-2E7F - 2E9A - 2EF4-2EFF - 2FD6-2FEF - 2FFC-2FFF - 3040 - 3097-3098 - 3100-3104 - 312D-3130 - 318F - 31B8-31EF - 321D-321F - 3244-3250 - 327C-327E - 32CC-32CF - 32FF - 3377-337A - 33DE-33DF - 33FF - 4DB6-4DFF - 9FA6-9FFF - A48D-A48F - A4C7-ABFF - D7A4-D7FF - FA2E-FA2F - FA6B-FAFF - FB07-FB12 - FB18-FB1C - FB37 - FB3D - FB3F - FB42 - - - -Hoffman & Blanchet Standards Track [Page 29] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - FB45 - FBB2-FBD2 - FD40-FD4F - FD90-FD91 - FDC8-FDCF - FDFD-FDFF - FE10-FE1F - FE24-FE2F - FE47-FE48 - FE53 - FE67 - FE6C-FE6F - FE75 - FEFD-FEFE - FF00 - FFBF-FFC1 - FFC8-FFC9 - FFD0-FFD1 - FFD8-FFD9 - FFDD-FFDF - FFE7 - FFEF-FFF8 - 10000-102FF - 1031F - 10324-1032F - 1034B-103FF - 10426-10427 - 1044E-1CFFF - 1D0F6-1D0FF - 1D127-1D129 - 1D1DE-1D3FF - 1D455 - 1D49D - 1D4A0-1D4A1 - 1D4A3-1D4A4 - 1D4A7-1D4A8 - 1D4AD - 1D4BA - 1D4BC - 1D4C1 - 1D4C4 - 1D506 - 1D50B-1D50C - 1D515 - 1D51D - 1D53A - 1D53F - 1D545 - - - -Hoffman & Blanchet Standards Track [Page 30] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 1D547-1D549 - 1D551 - 1D6A4-1D6A7 - 1D7CA-1D7CD - 1D800-1FFFD - 2A6D7-2F7FF - 2FA1E-2FFFD - 30000-3FFFD - 40000-4FFFD - 50000-5FFFD - 60000-6FFFD - 70000-7FFFD - 80000-8FFFD - 90000-9FFFD - A0000-AFFFD - B0000-BFFFD - C0000-CFFFD - D0000-DFFFD - E0000 - E0002-E001F - E0080-EFFFD - ----- End Table A.1 ----- - -B. Mapping Tables - - The following is the mapping table from section 3. The table has - three columns: - - - the code point that is mapped from - - the zero or more code points that it is mapped to - - the reason for the mapping - - The columns are separated by semicolons. Note that the second column - may be empty, or it may have one code point, or it may have more than - one code point, with each code point separated by a space. - -B.1 Commonly mapped to nothing - - ----- Start Table B.1 ----- - 00AD; ; Map to nothing - 034F; ; Map to nothing - 1806; ; Map to nothing - 180B; ; Map to nothing - 180C; ; Map to nothing - 180D; ; Map to nothing - 200B; ; Map to nothing - 200C; ; Map to nothing - 200D; ; Map to nothing - - - -Hoffman & Blanchet Standards Track [Page 31] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 2060; ; Map to nothing - FE00; ; Map to nothing - FE01; ; Map to nothing - FE02; ; Map to nothing - FE03; ; Map to nothing - FE04; ; Map to nothing - FE05; ; Map to nothing - FE06; ; Map to nothing - FE07; ; Map to nothing - FE08; ; Map to nothing - FE09; ; Map to nothing - FE0A; ; Map to nothing - FE0B; ; Map to nothing - FE0C; ; Map to nothing - FE0D; ; Map to nothing - FE0E; ; Map to nothing - FE0F; ; Map to nothing - FEFF; ; Map to nothing - ----- End Table B.1 ----- - -B.2 Mapping for case-folding used with NFKC - - ----- Start Table B.2 ----- - 0041; 0061; Case map - 0042; 0062; Case map - 0043; 0063; Case map - 0044; 0064; Case map - 0045; 0065; Case map - 0046; 0066; Case map - 0047; 0067; Case map - 0048; 0068; Case map - 0049; 0069; Case map - 004A; 006A; Case map - 004B; 006B; Case map - 004C; 006C; Case map - 004D; 006D; Case map - 004E; 006E; Case map - 004F; 006F; Case map - 0050; 0070; Case map - 0051; 0071; Case map - 0052; 0072; Case map - 0053; 0073; Case map - 0054; 0074; Case map - 0055; 0075; Case map - 0056; 0076; Case map - 0057; 0077; Case map - 0058; 0078; Case map - 0059; 0079; Case map - - - -Hoffman & Blanchet Standards Track [Page 32] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 005A; 007A; Case map - 00B5; 03BC; Case map - 00C0; 00E0; Case map - 00C1; 00E1; Case map - 00C2; 00E2; Case map - 00C3; 00E3; Case map - 00C4; 00E4; Case map - 00C5; 00E5; Case map - 00C6; 00E6; Case map - 00C7; 00E7; Case map - 00C8; 00E8; Case map - 00C9; 00E9; Case map - 00CA; 00EA; Case map - 00CB; 00EB; Case map - 00CC; 00EC; Case map - 00CD; 00ED; Case map - 00CE; 00EE; Case map - 00CF; 00EF; Case map - 00D0; 00F0; Case map - 00D1; 00F1; Case map - 00D2; 00F2; Case map - 00D3; 00F3; Case map - 00D4; 00F4; Case map - 00D5; 00F5; Case map - 00D6; 00F6; Case map - 00D8; 00F8; Case map - 00D9; 00F9; Case map - 00DA; 00FA; Case map - 00DB; 00FB; Case map - 00DC; 00FC; Case map - 00DD; 00FD; Case map - 00DE; 00FE; Case map - 00DF; 0073 0073; Case map - 0100; 0101; Case map - 0102; 0103; Case map - 0104; 0105; Case map - 0106; 0107; Case map - 0108; 0109; Case map - 010A; 010B; Case map - 010C; 010D; Case map - 010E; 010F; Case map - 0110; 0111; Case map - 0112; 0113; Case map - 0114; 0115; Case map - 0116; 0117; Case map - 0118; 0119; Case map - 011A; 011B; Case map - 011C; 011D; Case map - - - -Hoffman & Blanchet Standards Track [Page 33] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 011E; 011F; Case map - 0120; 0121; Case map - 0122; 0123; Case map - 0124; 0125; Case map - 0126; 0127; Case map - 0128; 0129; Case map - 012A; 012B; Case map - 012C; 012D; Case map - 012E; 012F; Case map - 0130; 0069 0307; Case map - 0132; 0133; Case map - 0134; 0135; Case map - 0136; 0137; Case map - 0139; 013A; Case map - 013B; 013C; Case map - 013D; 013E; Case map - 013F; 0140; Case map - 0141; 0142; Case map - 0143; 0144; Case map - 0145; 0146; Case map - 0147; 0148; Case map - 0149; 02BC 006E; Case map - 014A; 014B; Case map - 014C; 014D; Case map - 014E; 014F; Case map - 0150; 0151; Case map - 0152; 0153; Case map - 0154; 0155; Case map - 0156; 0157; Case map - 0158; 0159; Case map - 015A; 015B; Case map - 015C; 015D; Case map - 015E; 015F; Case map - 0160; 0161; Case map - 0162; 0163; Case map - 0164; 0165; Case map - 0166; 0167; Case map - 0168; 0169; Case map - 016A; 016B; Case map - 016C; 016D; Case map - 016E; 016F; Case map - 0170; 0171; Case map - 0172; 0173; Case map - 0174; 0175; Case map - 0176; 0177; Case map - 0178; 00FF; Case map - 0179; 017A; Case map - 017B; 017C; Case map - - - -Hoffman & Blanchet Standards Track [Page 34] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 017D; 017E; Case map - 017F; 0073; Case map - 0181; 0253; Case map - 0182; 0183; Case map - 0184; 0185; Case map - 0186; 0254; Case map - 0187; 0188; Case map - 0189; 0256; Case map - 018A; 0257; Case map - 018B; 018C; Case map - 018E; 01DD; Case map - 018F; 0259; Case map - 0190; 025B; Case map - 0191; 0192; Case map - 0193; 0260; Case map - 0194; 0263; Case map - 0196; 0269; Case map - 0197; 0268; Case map - 0198; 0199; Case map - 019C; 026F; Case map - 019D; 0272; Case map - 019F; 0275; Case map - 01A0; 01A1; Case map - 01A2; 01A3; Case map - 01A4; 01A5; Case map - 01A6; 0280; Case map - 01A7; 01A8; Case map - 01A9; 0283; Case map - 01AC; 01AD; Case map - 01AE; 0288; Case map - 01AF; 01B0; Case map - 01B1; 028A; Case map - 01B2; 028B; Case map - 01B3; 01B4; Case map - 01B5; 01B6; Case map - 01B7; 0292; Case map - 01B8; 01B9; Case map - 01BC; 01BD; Case map - 01C4; 01C6; Case map - 01C5; 01C6; Case map - 01C7; 01C9; Case map - 01C8; 01C9; Case map - 01CA; 01CC; Case map - 01CB; 01CC; Case map - 01CD; 01CE; Case map - 01CF; 01D0; Case map - 01D1; 01D2; Case map - 01D3; 01D4; Case map - - - -Hoffman & Blanchet Standards Track [Page 35] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 01D5; 01D6; Case map - 01D7; 01D8; Case map - 01D9; 01DA; Case map - 01DB; 01DC; Case map - 01DE; 01DF; Case map - 01E0; 01E1; Case map - 01E2; 01E3; Case map - 01E4; 01E5; Case map - 01E6; 01E7; Case map - 01E8; 01E9; Case map - 01EA; 01EB; Case map - 01EC; 01ED; Case map - 01EE; 01EF; Case map - 01F0; 006A 030C; Case map - 01F1; 01F3; Case map - 01F2; 01F3; Case map - 01F4; 01F5; Case map - 01F6; 0195; Case map - 01F7; 01BF; Case map - 01F8; 01F9; Case map - 01FA; 01FB; Case map - 01FC; 01FD; Case map - 01FE; 01FF; Case map - 0200; 0201; Case map - 0202; 0203; Case map - 0204; 0205; Case map - 0206; 0207; Case map - 0208; 0209; Case map - 020A; 020B; Case map - 020C; 020D; Case map - 020E; 020F; Case map - 0210; 0211; Case map - 0212; 0213; Case map - 0214; 0215; Case map - 0216; 0217; Case map - 0218; 0219; Case map - 021A; 021B; Case map - 021C; 021D; Case map - 021E; 021F; Case map - 0220; 019E; Case map - 0222; 0223; Case map - 0224; 0225; Case map - 0226; 0227; Case map - 0228; 0229; Case map - 022A; 022B; Case map - 022C; 022D; Case map - 022E; 022F; Case map - 0230; 0231; Case map - - - -Hoffman & Blanchet Standards Track [Page 36] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 0232; 0233; Case map - 0345; 03B9; Case map - 037A; 0020 03B9; Additional folding - 0386; 03AC; Case map - 0388; 03AD; Case map - 0389; 03AE; Case map - 038A; 03AF; Case map - 038C; 03CC; Case map - 038E; 03CD; Case map - 038F; 03CE; Case map - 0390; 03B9 0308 0301; Case map - 0391; 03B1; Case map - 0392; 03B2; Case map - 0393; 03B3; Case map - 0394; 03B4; Case map - 0395; 03B5; Case map - 0396; 03B6; Case map - 0397; 03B7; Case map - 0398; 03B8; Case map - 0399; 03B9; Case map - 039A; 03BA; Case map - 039B; 03BB; Case map - 039C; 03BC; Case map - 039D; 03BD; Case map - 039E; 03BE; Case map - 039F; 03BF; Case map - 03A0; 03C0; Case map - 03A1; 03C1; Case map - 03A3; 03C3; Case map - 03A4; 03C4; Case map - 03A5; 03C5; Case map - 03A6; 03C6; Case map - 03A7; 03C7; Case map - 03A8; 03C8; Case map - 03A9; 03C9; Case map - 03AA; 03CA; Case map - 03AB; 03CB; Case map - 03B0; 03C5 0308 0301; Case map - 03C2; 03C3; Case map - 03D0; 03B2; Case map - 03D1; 03B8; Case map - 03D2; 03C5; Additional folding - 03D3; 03CD; Additional folding - 03D4; 03CB; Additional folding - 03D5; 03C6; Case map - 03D6; 03C0; Case map - 03D8; 03D9; Case map - 03DA; 03DB; Case map - - - -Hoffman & Blanchet Standards Track [Page 37] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 03DC; 03DD; Case map - 03DE; 03DF; Case map - 03E0; 03E1; Case map - 03E2; 03E3; Case map - 03E4; 03E5; Case map - 03E6; 03E7; Case map - 03E8; 03E9; Case map - 03EA; 03EB; Case map - 03EC; 03ED; Case map - 03EE; 03EF; Case map - 03F0; 03BA; Case map - 03F1; 03C1; Case map - 03F2; 03C3; Case map - 03F4; 03B8; Case map - 03F5; 03B5; Case map - 0400; 0450; Case map - 0401; 0451; Case map - 0402; 0452; Case map - 0403; 0453; Case map - 0404; 0454; Case map - 0405; 0455; Case map - 0406; 0456; Case map - 0407; 0457; Case map - 0408; 0458; Case map - 0409; 0459; Case map - 040A; 045A; Case map - 040B; 045B; Case map - 040C; 045C; Case map - 040D; 045D; Case map - 040E; 045E; Case map - 040F; 045F; Case map - 0410; 0430; Case map - 0411; 0431; Case map - 0412; 0432; Case map - 0413; 0433; Case map - 0414; 0434; Case map - 0415; 0435; Case map - 0416; 0436; Case map - 0417; 0437; Case map - 0418; 0438; Case map - 0419; 0439; Case map - 041A; 043A; Case map - 041B; 043B; Case map - 041C; 043C; Case map - 041D; 043D; Case map - 041E; 043E; Case map - 041F; 043F; Case map - 0420; 0440; Case map - - - -Hoffman & Blanchet Standards Track [Page 38] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 0421; 0441; Case map - 0422; 0442; Case map - 0423; 0443; Case map - 0424; 0444; Case map - 0425; 0445; Case map - 0426; 0446; Case map - 0427; 0447; Case map - 0428; 0448; Case map - 0429; 0449; Case map - 042A; 044A; Case map - 042B; 044B; Case map - 042C; 044C; Case map - 042D; 044D; Case map - 042E; 044E; Case map - 042F; 044F; Case map - 0460; 0461; Case map - 0462; 0463; Case map - 0464; 0465; Case map - 0466; 0467; Case map - 0468; 0469; Case map - 046A; 046B; Case map - 046C; 046D; Case map - 046E; 046F; Case map - 0470; 0471; Case map - 0472; 0473; Case map - 0474; 0475; Case map - 0476; 0477; Case map - 0478; 0479; Case map - 047A; 047B; Case map - 047C; 047D; Case map - 047E; 047F; Case map - 0480; 0481; Case map - 048A; 048B; Case map - 048C; 048D; Case map - 048E; 048F; Case map - 0490; 0491; Case map - 0492; 0493; Case map - 0494; 0495; Case map - 0496; 0497; Case map - 0498; 0499; Case map - 049A; 049B; Case map - 049C; 049D; Case map - 049E; 049F; Case map - 04A0; 04A1; Case map - 04A2; 04A3; Case map - 04A4; 04A5; Case map - 04A6; 04A7; Case map - 04A8; 04A9; Case map - - - -Hoffman & Blanchet Standards Track [Page 39] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 04AA; 04AB; Case map - 04AC; 04AD; Case map - 04AE; 04AF; Case map - 04B0; 04B1; Case map - 04B2; 04B3; Case map - 04B4; 04B5; Case map - 04B6; 04B7; Case map - 04B8; 04B9; Case map - 04BA; 04BB; Case map - 04BC; 04BD; Case map - 04BE; 04BF; Case map - 04C1; 04C2; Case map - 04C3; 04C4; Case map - 04C5; 04C6; Case map - 04C7; 04C8; Case map - 04C9; 04CA; Case map - 04CB; 04CC; Case map - 04CD; 04CE; Case map - 04D0; 04D1; Case map - 04D2; 04D3; Case map - 04D4; 04D5; Case map - 04D6; 04D7; Case map - 04D8; 04D9; Case map - 04DA; 04DB; Case map - 04DC; 04DD; Case map - 04DE; 04DF; Case map - 04E0; 04E1; Case map - 04E2; 04E3; Case map - 04E4; 04E5; Case map - 04E6; 04E7; Case map - 04E8; 04E9; Case map - 04EA; 04EB; Case map - 04EC; 04ED; Case map - 04EE; 04EF; Case map - 04F0; 04F1; Case map - 04F2; 04F3; Case map - 04F4; 04F5; Case map - 04F8; 04F9; Case map - 0500; 0501; Case map - 0502; 0503; Case map - 0504; 0505; Case map - 0506; 0507; Case map - 0508; 0509; Case map - 050A; 050B; Case map - 050C; 050D; Case map - 050E; 050F; Case map - 0531; 0561; Case map - 0532; 0562; Case map - - - -Hoffman & Blanchet Standards Track [Page 40] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 0533; 0563; Case map - 0534; 0564; Case map - 0535; 0565; Case map - 0536; 0566; Case map - 0537; 0567; Case map - 0538; 0568; Case map - 0539; 0569; Case map - 053A; 056A; Case map - 053B; 056B; Case map - 053C; 056C; Case map - 053D; 056D; Case map - 053E; 056E; Case map - 053F; 056F; Case map - 0540; 0570; Case map - 0541; 0571; Case map - 0542; 0572; Case map - 0543; 0573; Case map - 0544; 0574; Case map - 0545; 0575; Case map - 0546; 0576; Case map - 0547; 0577; Case map - 0548; 0578; Case map - 0549; 0579; Case map - 054A; 057A; Case map - 054B; 057B; Case map - 054C; 057C; Case map - 054D; 057D; Case map - 054E; 057E; Case map - 054F; 057F; Case map - 0550; 0580; Case map - 0551; 0581; Case map - 0552; 0582; Case map - 0553; 0583; Case map - 0554; 0584; Case map - 0555; 0585; Case map - 0556; 0586; Case map - 0587; 0565 0582; Case map - 1E00; 1E01; Case map - 1E02; 1E03; Case map - 1E04; 1E05; Case map - 1E06; 1E07; Case map - 1E08; 1E09; Case map - 1E0A; 1E0B; Case map - 1E0C; 1E0D; Case map - 1E0E; 1E0F; Case map - 1E10; 1E11; Case map - 1E12; 1E13; Case map - 1E14; 1E15; Case map - - - -Hoffman & Blanchet Standards Track [Page 41] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 1E16; 1E17; Case map - 1E18; 1E19; Case map - 1E1A; 1E1B; Case map - 1E1C; 1E1D; Case map - 1E1E; 1E1F; Case map - 1E20; 1E21; Case map - 1E22; 1E23; Case map - 1E24; 1E25; Case map - 1E26; 1E27; Case map - 1E28; 1E29; Case map - 1E2A; 1E2B; Case map - 1E2C; 1E2D; Case map - 1E2E; 1E2F; Case map - 1E30; 1E31; Case map - 1E32; 1E33; Case map - 1E34; 1E35; Case map - 1E36; 1E37; Case map - 1E38; 1E39; Case map - 1E3A; 1E3B; Case map - 1E3C; 1E3D; Case map - 1E3E; 1E3F; Case map - 1E40; 1E41; Case map - 1E42; 1E43; Case map - 1E44; 1E45; Case map - 1E46; 1E47; Case map - 1E48; 1E49; Case map - 1E4A; 1E4B; Case map - 1E4C; 1E4D; Case map - 1E4E; 1E4F; Case map - 1E50; 1E51; Case map - 1E52; 1E53; Case map - 1E54; 1E55; Case map - 1E56; 1E57; Case map - 1E58; 1E59; Case map - 1E5A; 1E5B; Case map - 1E5C; 1E5D; Case map - 1E5E; 1E5F; Case map - 1E60; 1E61; Case map - 1E62; 1E63; Case map - 1E64; 1E65; Case map - 1E66; 1E67; Case map - 1E68; 1E69; Case map - 1E6A; 1E6B; Case map - 1E6C; 1E6D; Case map - 1E6E; 1E6F; Case map - 1E70; 1E71; Case map - 1E72; 1E73; Case map - 1E74; 1E75; Case map - - - -Hoffman & Blanchet Standards Track [Page 42] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 1E76; 1E77; Case map - 1E78; 1E79; Case map - 1E7A; 1E7B; Case map - 1E7C; 1E7D; Case map - 1E7E; 1E7F; Case map - 1E80; 1E81; Case map - 1E82; 1E83; Case map - 1E84; 1E85; Case map - 1E86; 1E87; Case map - 1E88; 1E89; Case map - 1E8A; 1E8B; Case map - 1E8C; 1E8D; Case map - 1E8E; 1E8F; Case map - 1E90; 1E91; Case map - 1E92; 1E93; Case map - 1E94; 1E95; Case map - 1E96; 0068 0331; Case map - 1E97; 0074 0308; Case map - 1E98; 0077 030A; Case map - 1E99; 0079 030A; Case map - 1E9A; 0061 02BE; Case map - 1E9B; 1E61; Case map - 1EA0; 1EA1; Case map - 1EA2; 1EA3; Case map - 1EA4; 1EA5; Case map - 1EA6; 1EA7; Case map - 1EA8; 1EA9; Case map - 1EAA; 1EAB; Case map - 1EAC; 1EAD; Case map - 1EAE; 1EAF; Case map - 1EB0; 1EB1; Case map - 1EB2; 1EB3; Case map - 1EB4; 1EB5; Case map - 1EB6; 1EB7; Case map - 1EB8; 1EB9; Case map - 1EBA; 1EBB; Case map - 1EBC; 1EBD; Case map - 1EBE; 1EBF; Case map - 1EC0; 1EC1; Case map - 1EC2; 1EC3; Case map - 1EC4; 1EC5; Case map - 1EC6; 1EC7; Case map - 1EC8; 1EC9; Case map - 1ECA; 1ECB; Case map - 1ECC; 1ECD; Case map - 1ECE; 1ECF; Case map - 1ED0; 1ED1; Case map - 1ED2; 1ED3; Case map - - - -Hoffman & Blanchet Standards Track [Page 43] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 1ED4; 1ED5; Case map - 1ED6; 1ED7; Case map - 1ED8; 1ED9; Case map - 1EDA; 1EDB; Case map - 1EDC; 1EDD; Case map - 1EDE; 1EDF; Case map - 1EE0; 1EE1; Case map - 1EE2; 1EE3; Case map - 1EE4; 1EE5; Case map - 1EE6; 1EE7; Case map - 1EE8; 1EE9; Case map - 1EEA; 1EEB; Case map - 1EEC; 1EED; Case map - 1EEE; 1EEF; Case map - 1EF0; 1EF1; Case map - 1EF2; 1EF3; Case map - 1EF4; 1EF5; Case map - 1EF6; 1EF7; Case map - 1EF8; 1EF9; Case map - 1F08; 1F00; Case map - 1F09; 1F01; Case map - 1F0A; 1F02; Case map - 1F0B; 1F03; Case map - 1F0C; 1F04; Case map - 1F0D; 1F05; Case map - 1F0E; 1F06; Case map - 1F0F; 1F07; Case map - 1F18; 1F10; Case map - 1F19; 1F11; Case map - 1F1A; 1F12; Case map - 1F1B; 1F13; Case map - 1F1C; 1F14; Case map - 1F1D; 1F15; Case map - 1F28; 1F20; Case map - 1F29; 1F21; Case map - 1F2A; 1F22; Case map - 1F2B; 1F23; Case map - 1F2C; 1F24; Case map - 1F2D; 1F25; Case map - 1F2E; 1F26; Case map - 1F2F; 1F27; Case map - 1F38; 1F30; Case map - 1F39; 1F31; Case map - 1F3A; 1F32; Case map - 1F3B; 1F33; Case map - 1F3C; 1F34; Case map - 1F3D; 1F35; Case map - 1F3E; 1F36; Case map - - - -Hoffman & Blanchet Standards Track [Page 44] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 1F3F; 1F37; Case map - 1F48; 1F40; Case map - 1F49; 1F41; Case map - 1F4A; 1F42; Case map - 1F4B; 1F43; Case map - 1F4C; 1F44; Case map - 1F4D; 1F45; Case map - 1F50; 03C5 0313; Case map - 1F52; 03C5 0313 0300; Case map - 1F54; 03C5 0313 0301; Case map - 1F56; 03C5 0313 0342; Case map - 1F59; 1F51; Case map - 1F5B; 1F53; Case map - 1F5D; 1F55; Case map - 1F5F; 1F57; Case map - 1F68; 1F60; Case map - 1F69; 1F61; Case map - 1F6A; 1F62; Case map - 1F6B; 1F63; Case map - 1F6C; 1F64; Case map - 1F6D; 1F65; Case map - 1F6E; 1F66; Case map - 1F6F; 1F67; Case map - 1F80; 1F00 03B9; Case map - 1F81; 1F01 03B9; Case map - 1F82; 1F02 03B9; Case map - 1F83; 1F03 03B9; Case map - 1F84; 1F04 03B9; Case map - 1F85; 1F05 03B9; Case map - 1F86; 1F06 03B9; Case map - 1F87; 1F07 03B9; Case map - 1F88; 1F00 03B9; Case map - 1F89; 1F01 03B9; Case map - 1F8A; 1F02 03B9; Case map - 1F8B; 1F03 03B9; Case map - 1F8C; 1F04 03B9; Case map - 1F8D; 1F05 03B9; Case map - 1F8E; 1F06 03B9; Case map - 1F8F; 1F07 03B9; Case map - 1F90; 1F20 03B9; Case map - 1F91; 1F21 03B9; Case map - 1F92; 1F22 03B9; Case map - 1F93; 1F23 03B9; Case map - 1F94; 1F24 03B9; Case map - 1F95; 1F25 03B9; Case map - 1F96; 1F26 03B9; Case map - 1F97; 1F27 03B9; Case map - 1F98; 1F20 03B9; Case map - - - -Hoffman & Blanchet Standards Track [Page 45] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 1F99; 1F21 03B9; Case map - 1F9A; 1F22 03B9; Case map - 1F9B; 1F23 03B9; Case map - 1F9C; 1F24 03B9; Case map - 1F9D; 1F25 03B9; Case map - 1F9E; 1F26 03B9; Case map - 1F9F; 1F27 03B9; Case map - 1FA0; 1F60 03B9; Case map - 1FA1; 1F61 03B9; Case map - 1FA2; 1F62 03B9; Case map - 1FA3; 1F63 03B9; Case map - 1FA4; 1F64 03B9; Case map - 1FA5; 1F65 03B9; Case map - 1FA6; 1F66 03B9; Case map - 1FA7; 1F67 03B9; Case map - 1FA8; 1F60 03B9; Case map - 1FA9; 1F61 03B9; Case map - 1FAA; 1F62 03B9; Case map - 1FAB; 1F63 03B9; Case map - 1FAC; 1F64 03B9; Case map - 1FAD; 1F65 03B9; Case map - 1FAE; 1F66 03B9; Case map - 1FAF; 1F67 03B9; Case map - 1FB2; 1F70 03B9; Case map - 1FB3; 03B1 03B9; Case map - 1FB4; 03AC 03B9; Case map - 1FB6; 03B1 0342; Case map - 1FB7; 03B1 0342 03B9; Case map - 1FB8; 1FB0; Case map - 1FB9; 1FB1; Case map - 1FBA; 1F70; Case map - 1FBB; 1F71; Case map - 1FBC; 03B1 03B9; Case map - 1FBE; 03B9; Case map - 1FC2; 1F74 03B9; Case map - 1FC3; 03B7 03B9; Case map - 1FC4; 03AE 03B9; Case map - 1FC6; 03B7 0342; Case map - 1FC7; 03B7 0342 03B9; Case map - 1FC8; 1F72; Case map - 1FC9; 1F73; Case map - 1FCA; 1F74; Case map - 1FCB; 1F75; Case map - 1FCC; 03B7 03B9; Case map - 1FD2; 03B9 0308 0300; Case map - 1FD3; 03B9 0308 0301; Case map - 1FD6; 03B9 0342; Case map - 1FD7; 03B9 0308 0342; Case map - - - -Hoffman & Blanchet Standards Track [Page 46] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 1FD8; 1FD0; Case map - 1FD9; 1FD1; Case map - 1FDA; 1F76; Case map - 1FDB; 1F77; Case map - 1FE2; 03C5 0308 0300; Case map - 1FE3; 03C5 0308 0301; Case map - 1FE4; 03C1 0313; Case map - 1FE6; 03C5 0342; Case map - 1FE7; 03C5 0308 0342; Case map - 1FE8; 1FE0; Case map - 1FE9; 1FE1; Case map - 1FEA; 1F7A; Case map - 1FEB; 1F7B; Case map - 1FEC; 1FE5; Case map - 1FF2; 1F7C 03B9; Case map - 1FF3; 03C9 03B9; Case map - 1FF4; 03CE 03B9; Case map - 1FF6; 03C9 0342; Case map - 1FF7; 03C9 0342 03B9; Case map - 1FF8; 1F78; Case map - 1FF9; 1F79; Case map - 1FFA; 1F7C; Case map - 1FFB; 1F7D; Case map - 1FFC; 03C9 03B9; Case map - 20A8; 0072 0073; Additional folding - 2102; 0063; Additional folding - 2103; 00B0 0063; Additional folding - 2107; 025B; Additional folding - 2109; 00B0 0066; Additional folding - 210B; 0068; Additional folding - 210C; 0068; Additional folding - 210D; 0068; Additional folding - 2110; 0069; Additional folding - 2111; 0069; Additional folding - 2112; 006C; Additional folding - 2115; 006E; Additional folding - 2116; 006E 006F; Additional folding - 2119; 0070; Additional folding - 211A; 0071; Additional folding - 211B; 0072; Additional folding - 211C; 0072; Additional folding - 211D; 0072; Additional folding - 2120; 0073 006D; Additional folding - 2121; 0074 0065 006C; Additional folding - 2122; 0074 006D; Additional folding - 2124; 007A; Additional folding - 2126; 03C9; Case map - 2128; 007A; Additional folding - - - -Hoffman & Blanchet Standards Track [Page 47] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 212A; 006B; Case map - 212B; 00E5; Case map - 212C; 0062; Additional folding - 212D; 0063; Additional folding - 2130; 0065; Additional folding - 2131; 0066; Additional folding - 2133; 006D; Additional folding - 213E; 03B3; Additional folding - 213F; 03C0; Additional folding - 2145; 0064; Additional folding - 2160; 2170; Case map - 2161; 2171; Case map - 2162; 2172; Case map - 2163; 2173; Case map - 2164; 2174; Case map - 2165; 2175; Case map - 2166; 2176; Case map - 2167; 2177; Case map - 2168; 2178; Case map - 2169; 2179; Case map - 216A; 217A; Case map - 216B; 217B; Case map - 216C; 217C; Case map - 216D; 217D; Case map - 216E; 217E; Case map - 216F; 217F; Case map - 24B6; 24D0; Case map - 24B7; 24D1; Case map - 24B8; 24D2; Case map - 24B9; 24D3; Case map - 24BA; 24D4; Case map - 24BB; 24D5; Case map - 24BC; 24D6; Case map - 24BD; 24D7; Case map - 24BE; 24D8; Case map - 24BF; 24D9; Case map - 24C0; 24DA; Case map - 24C1; 24DB; Case map - 24C2; 24DC; Case map - 24C3; 24DD; Case map - 24C4; 24DE; Case map - 24C5; 24DF; Case map - 24C6; 24E0; Case map - 24C7; 24E1; Case map - 24C8; 24E2; Case map - 24C9; 24E3; Case map - 24CA; 24E4; Case map - 24CB; 24E5; Case map - - - -Hoffman & Blanchet Standards Track [Page 48] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 24CC; 24E6; Case map - 24CD; 24E7; Case map - 24CE; 24E8; Case map - 24CF; 24E9; Case map - 3371; 0068 0070 0061; Additional folding - 3373; 0061 0075; Additional folding - 3375; 006F 0076; Additional folding - 3380; 0070 0061; Additional folding - 3381; 006E 0061; Additional folding - 3382; 03BC 0061; Additional folding - 3383; 006D 0061; Additional folding - 3384; 006B 0061; Additional folding - 3385; 006B 0062; Additional folding - 3386; 006D 0062; Additional folding - 3387; 0067 0062; Additional folding - 338A; 0070 0066; Additional folding - 338B; 006E 0066; Additional folding - 338C; 03BC 0066; Additional folding - 3390; 0068 007A; Additional folding - 3391; 006B 0068 007A; Additional folding - 3392; 006D 0068 007A; Additional folding - 3393; 0067 0068 007A; Additional folding - 3394; 0074 0068 007A; Additional folding - 33A9; 0070 0061; Additional folding - 33AA; 006B 0070 0061; Additional folding - 33AB; 006D 0070 0061; Additional folding - 33AC; 0067 0070 0061; Additional folding - 33B4; 0070 0076; Additional folding - 33B5; 006E 0076; Additional folding - 33B6; 03BC 0076; Additional folding - 33B7; 006D 0076; Additional folding - 33B8; 006B 0076; Additional folding - 33B9; 006D 0076; Additional folding - 33BA; 0070 0077; Additional folding - 33BB; 006E 0077; Additional folding - 33BC; 03BC 0077; Additional folding - 33BD; 006D 0077; Additional folding - 33BE; 006B 0077; Additional folding - 33BF; 006D 0077; Additional folding - 33C0; 006B 03C9; Additional folding - 33C1; 006D 03C9; Additional folding - 33C3; 0062 0071; Additional folding - 33C6; 0063 2215 006B 0067; Additional folding - 33C7; 0063 006F 002E; Additional folding - 33C8; 0064 0062; Additional folding - 33C9; 0067 0079; Additional folding - 33CB; 0068 0070; Additional folding - 33CD; 006B 006B; Additional folding - - - -Hoffman & Blanchet Standards Track [Page 49] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 33CE; 006B 006D; Additional folding - 33D7; 0070 0068; Additional folding - 33D9; 0070 0070 006D; Additional folding - 33DA; 0070 0072; Additional folding - 33DC; 0073 0076; Additional folding - 33DD; 0077 0062; Additional folding - FB00; 0066 0066; Case map - FB01; 0066 0069; Case map - FB02; 0066 006C; Case map - FB03; 0066 0066 0069; Case map - FB04; 0066 0066 006C; Case map - FB05; 0073 0074; Case map - FB06; 0073 0074; Case map - FB13; 0574 0576; Case map - FB14; 0574 0565; Case map - FB15; 0574 056B; Case map - FB16; 057E 0576; Case map - FB17; 0574 056D; Case map - FF21; FF41; Case map - FF22; FF42; Case map - FF23; FF43; Case map - FF24; FF44; Case map - FF25; FF45; Case map - FF26; FF46; Case map - FF27; FF47; Case map - FF28; FF48; Case map - FF29; FF49; Case map - FF2A; FF4A; Case map - FF2B; FF4B; Case map - FF2C; FF4C; Case map - FF2D; FF4D; Case map - FF2E; FF4E; Case map - FF2F; FF4F; Case map - FF30; FF50; Case map - FF31; FF51; Case map - FF32; FF52; Case map - FF33; FF53; Case map - FF34; FF54; Case map - FF35; FF55; Case map - FF36; FF56; Case map - FF37; FF57; Case map - FF38; FF58; Case map - FF39; FF59; Case map - FF3A; FF5A; Case map - 10400; 10428; Case map - 10401; 10429; Case map - 10402; 1042A; Case map - 10403; 1042B; Case map - - - -Hoffman & Blanchet Standards Track [Page 50] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 10404; 1042C; Case map - 10405; 1042D; Case map - 10406; 1042E; Case map - 10407; 1042F; Case map - 10408; 10430; Case map - 10409; 10431; Case map - 1040A; 10432; Case map - 1040B; 10433; Case map - 1040C; 10434; Case map - 1040D; 10435; Case map - 1040E; 10436; Case map - 1040F; 10437; Case map - 10410; 10438; Case map - 10411; 10439; Case map - 10412; 1043A; Case map - 10413; 1043B; Case map - 10414; 1043C; Case map - 10415; 1043D; Case map - 10416; 1043E; Case map - 10417; 1043F; Case map - 10418; 10440; Case map - 10419; 10441; Case map - 1041A; 10442; Case map - 1041B; 10443; Case map - 1041C; 10444; Case map - 1041D; 10445; Case map - 1041E; 10446; Case map - 1041F; 10447; Case map - 10420; 10448; Case map - 10421; 10449; Case map - 10422; 1044A; Case map - 10423; 1044B; Case map - 10424; 1044C; Case map - 10425; 1044D; Case map - 1D400; 0061; Additional folding - 1D401; 0062; Additional folding - 1D402; 0063; Additional folding - 1D403; 0064; Additional folding - 1D404; 0065; Additional folding - 1D405; 0066; Additional folding - 1D406; 0067; Additional folding - 1D407; 0068; Additional folding - 1D408; 0069; Additional folding - 1D409; 006A; Additional folding - 1D40A; 006B; Additional folding - 1D40B; 006C; Additional folding - 1D40C; 006D; Additional folding - 1D40D; 006E; Additional folding - - - -Hoffman & Blanchet Standards Track [Page 51] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 1D40E; 006F; Additional folding - 1D40F; 0070; Additional folding - 1D410; 0071; Additional folding - 1D411; 0072; Additional folding - 1D412; 0073; Additional folding - 1D413; 0074; Additional folding - 1D414; 0075; Additional folding - 1D415; 0076; Additional folding - 1D416; 0077; Additional folding - 1D417; 0078; Additional folding - 1D418; 0079; Additional folding - 1D419; 007A; Additional folding - 1D434; 0061; Additional folding - 1D435; 0062; Additional folding - 1D436; 0063; Additional folding - 1D437; 0064; Additional folding - 1D438; 0065; Additional folding - 1D439; 0066; Additional folding - 1D43A; 0067; Additional folding - 1D43B; 0068; Additional folding - 1D43C; 0069; Additional folding - 1D43D; 006A; Additional folding - 1D43E; 006B; Additional folding - 1D43F; 006C; Additional folding - 1D440; 006D; Additional folding - 1D441; 006E; Additional folding - 1D442; 006F; Additional folding - 1D443; 0070; Additional folding - 1D444; 0071; Additional folding - 1D445; 0072; Additional folding - 1D446; 0073; Additional folding - 1D447; 0074; Additional folding - 1D448; 0075; Additional folding - 1D449; 0076; Additional folding - 1D44A; 0077; Additional folding - 1D44B; 0078; Additional folding - 1D44C; 0079; Additional folding - 1D44D; 007A; Additional folding - 1D468; 0061; Additional folding - 1D469; 0062; Additional folding - 1D46A; 0063; Additional folding - 1D46B; 0064; Additional folding - 1D46C; 0065; Additional folding - 1D46D; 0066; Additional folding - 1D46E; 0067; Additional folding - 1D46F; 0068; Additional folding - 1D470; 0069; Additional folding - 1D471; 006A; Additional folding - - - -Hoffman & Blanchet Standards Track [Page 52] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 1D472; 006B; Additional folding - 1D473; 006C; Additional folding - 1D474; 006D; Additional folding - 1D475; 006E; Additional folding - 1D476; 006F; Additional folding - 1D477; 0070; Additional folding - 1D478; 0071; Additional folding - 1D479; 0072; Additional folding - 1D47A; 0073; Additional folding - 1D47B; 0074; Additional folding - 1D47C; 0075; Additional folding - 1D47D; 0076; Additional folding - 1D47E; 0077; Additional folding - 1D47F; 0078; Additional folding - 1D480; 0079; Additional folding - 1D481; 007A; Additional folding - 1D49C; 0061; Additional folding - 1D49E; 0063; Additional folding - 1D49F; 0064; Additional folding - 1D4A2; 0067; Additional folding - 1D4A5; 006A; Additional folding - 1D4A6; 006B; Additional folding - 1D4A9; 006E; Additional folding - 1D4AA; 006F; Additional folding - 1D4AB; 0070; Additional folding - 1D4AC; 0071; Additional folding - 1D4AE; 0073; Additional folding - 1D4AF; 0074; Additional folding - 1D4B0; 0075; Additional folding - 1D4B1; 0076; Additional folding - 1D4B2; 0077; Additional folding - 1D4B3; 0078; Additional folding - 1D4B4; 0079; Additional folding - 1D4B5; 007A; Additional folding - 1D4D0; 0061; Additional folding - 1D4D1; 0062; Additional folding - 1D4D2; 0063; Additional folding - 1D4D3; 0064; Additional folding - 1D4D4; 0065; Additional folding - 1D4D5; 0066; Additional folding - 1D4D6; 0067; Additional folding - 1D4D7; 0068; Additional folding - 1D4D8; 0069; Additional folding - 1D4D9; 006A; Additional folding - 1D4DA; 006B; Additional folding - 1D4DB; 006C; Additional folding - 1D4DC; 006D; Additional folding - 1D4DD; 006E; Additional folding - - - -Hoffman & Blanchet Standards Track [Page 53] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 1D4DE; 006F; Additional folding - 1D4DF; 0070; Additional folding - 1D4E0; 0071; Additional folding - 1D4E1; 0072; Additional folding - 1D4E2; 0073; Additional folding - 1D4E3; 0074; Additional folding - 1D4E4; 0075; Additional folding - 1D4E5; 0076; Additional folding - 1D4E6; 0077; Additional folding - 1D4E7; 0078; Additional folding - 1D4E8; 0079; Additional folding - 1D4E9; 007A; Additional folding - 1D504; 0061; Additional folding - 1D505; 0062; Additional folding - 1D507; 0064; Additional folding - 1D508; 0065; Additional folding - 1D509; 0066; Additional folding - 1D50A; 0067; Additional folding - 1D50D; 006A; Additional folding - 1D50E; 006B; Additional folding - 1D50F; 006C; Additional folding - 1D510; 006D; Additional folding - 1D511; 006E; Additional folding - 1D512; 006F; Additional folding - 1D513; 0070; Additional folding - 1D514; 0071; Additional folding - 1D516; 0073; Additional folding - 1D517; 0074; Additional folding - 1D518; 0075; Additional folding - 1D519; 0076; Additional folding - 1D51A; 0077; Additional folding - 1D51B; 0078; Additional folding - 1D51C; 0079; Additional folding - 1D538; 0061; Additional folding - 1D539; 0062; Additional folding - 1D53B; 0064; Additional folding - 1D53C; 0065; Additional folding - 1D53D; 0066; Additional folding - 1D53E; 0067; Additional folding - 1D540; 0069; Additional folding - 1D541; 006A; Additional folding - 1D542; 006B; Additional folding - 1D543; 006C; Additional folding - 1D544; 006D; Additional folding - 1D546; 006F; Additional folding - 1D54A; 0073; Additional folding - 1D54B; 0074; Additional folding - 1D54C; 0075; Additional folding - - - -Hoffman & Blanchet Standards Track [Page 54] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 1D54D; 0076; Additional folding - 1D54E; 0077; Additional folding - 1D54F; 0078; Additional folding - 1D550; 0079; Additional folding - 1D56C; 0061; Additional folding - 1D56D; 0062; Additional folding - 1D56E; 0063; Additional folding - 1D56F; 0064; Additional folding - 1D570; 0065; Additional folding - 1D571; 0066; Additional folding - 1D572; 0067; Additional folding - 1D573; 0068; Additional folding - 1D574; 0069; Additional folding - 1D575; 006A; Additional folding - 1D576; 006B; Additional folding - 1D577; 006C; Additional folding - 1D578; 006D; Additional folding - 1D579; 006E; Additional folding - 1D57A; 006F; Additional folding - 1D57B; 0070; Additional folding - 1D57C; 0071; Additional folding - 1D57D; 0072; Additional folding - 1D57E; 0073; Additional folding - 1D57F; 0074; Additional folding - 1D580; 0075; Additional folding - 1D581; 0076; Additional folding - 1D582; 0077; Additional folding - 1D583; 0078; Additional folding - 1D584; 0079; Additional folding - 1D585; 007A; Additional folding - 1D5A0; 0061; Additional folding - 1D5A1; 0062; Additional folding - 1D5A2; 0063; Additional folding - 1D5A3; 0064; Additional folding - 1D5A4; 0065; Additional folding - 1D5A5; 0066; Additional folding - 1D5A6; 0067; Additional folding - 1D5A7; 0068; Additional folding - 1D5A8; 0069; Additional folding - 1D5A9; 006A; Additional folding - 1D5AA; 006B; Additional folding - 1D5AB; 006C; Additional folding - 1D5AC; 006D; Additional folding - 1D5AD; 006E; Additional folding - 1D5AE; 006F; Additional folding - 1D5AF; 0070; Additional folding - 1D5B0; 0071; Additional folding - 1D5B1; 0072; Additional folding - - - -Hoffman & Blanchet Standards Track [Page 55] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 1D5B2; 0073; Additional folding - 1D5B3; 0074; Additional folding - 1D5B4; 0075; Additional folding - 1D5B5; 0076; Additional folding - 1D5B6; 0077; Additional folding - 1D5B7; 0078; Additional folding - 1D5B8; 0079; Additional folding - 1D5B9; 007A; Additional folding - 1D5D4; 0061; Additional folding - 1D5D5; 0062; Additional folding - 1D5D6; 0063; Additional folding - 1D5D7; 0064; Additional folding - 1D5D8; 0065; Additional folding - 1D5D9; 0066; Additional folding - 1D5DA; 0067; Additional folding - 1D5DB; 0068; Additional folding - 1D5DC; 0069; Additional folding - 1D5DD; 006A; Additional folding - 1D5DE; 006B; Additional folding - 1D5DF; 006C; Additional folding - 1D5E0; 006D; Additional folding - 1D5E1; 006E; Additional folding - 1D5E2; 006F; Additional folding - 1D5E3; 0070; Additional folding - 1D5E4; 0071; Additional folding - 1D5E5; 0072; Additional folding - 1D5E6; 0073; Additional folding - 1D5E7; 0074; Additional folding - 1D5E8; 0075; Additional folding - 1D5E9; 0076; Additional folding - 1D5EA; 0077; Additional folding - 1D5EB; 0078; Additional folding - 1D5EC; 0079; Additional folding - 1D5ED; 007A; Additional folding - 1D608; 0061; Additional folding - 1D609; 0062; Additional folding - 1D60A; 0063; Additional folding - 1D60B; 0064; Additional folding - 1D60C; 0065; Additional folding - 1D60D; 0066; Additional folding - 1D60E; 0067; Additional folding - 1D60F; 0068; Additional folding - 1D610; 0069; Additional folding - 1D611; 006A; Additional folding - 1D612; 006B; Additional folding - 1D613; 006C; Additional folding - 1D614; 006D; Additional folding - 1D615; 006E; Additional folding - - - -Hoffman & Blanchet Standards Track [Page 56] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 1D616; 006F; Additional folding - 1D617; 0070; Additional folding - 1D618; 0071; Additional folding - 1D619; 0072; Additional folding - 1D61A; 0073; Additional folding - 1D61B; 0074; Additional folding - 1D61C; 0075; Additional folding - 1D61D; 0076; Additional folding - 1D61E; 0077; Additional folding - 1D61F; 0078; Additional folding - 1D620; 0079; Additional folding - 1D621; 007A; Additional folding - 1D63C; 0061; Additional folding - 1D63D; 0062; Additional folding - 1D63E; 0063; Additional folding - 1D63F; 0064; Additional folding - 1D640; 0065; Additional folding - 1D641; 0066; Additional folding - 1D642; 0067; Additional folding - 1D643; 0068; Additional folding - 1D644; 0069; Additional folding - 1D645; 006A; Additional folding - 1D646; 006B; Additional folding - 1D647; 006C; Additional folding - 1D648; 006D; Additional folding - 1D649; 006E; Additional folding - 1D64A; 006F; Additional folding - 1D64B; 0070; Additional folding - 1D64C; 0071; Additional folding - 1D64D; 0072; Additional folding - 1D64E; 0073; Additional folding - 1D64F; 0074; Additional folding - 1D650; 0075; Additional folding - 1D651; 0076; Additional folding - 1D652; 0077; Additional folding - 1D653; 0078; Additional folding - 1D654; 0079; Additional folding - 1D655; 007A; Additional folding - 1D670; 0061; Additional folding - 1D671; 0062; Additional folding - 1D672; 0063; Additional folding - 1D673; 0064; Additional folding - 1D674; 0065; Additional folding - 1D675; 0066; Additional folding - 1D676; 0067; Additional folding - 1D677; 0068; Additional folding - 1D678; 0069; Additional folding - 1D679; 006A; Additional folding - - - -Hoffman & Blanchet Standards Track [Page 57] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 1D67A; 006B; Additional folding - 1D67B; 006C; Additional folding - 1D67C; 006D; Additional folding - 1D67D; 006E; Additional folding - 1D67E; 006F; Additional folding - 1D67F; 0070; Additional folding - 1D680; 0071; Additional folding - 1D681; 0072; Additional folding - 1D682; 0073; Additional folding - 1D683; 0074; Additional folding - 1D684; 0075; Additional folding - 1D685; 0076; Additional folding - 1D686; 0077; Additional folding - 1D687; 0078; Additional folding - 1D688; 0079; Additional folding - 1D689; 007A; Additional folding - 1D6A8; 03B1; Additional folding - 1D6A9; 03B2; Additional folding - 1D6AA; 03B3; Additional folding - 1D6AB; 03B4; Additional folding - 1D6AC; 03B5; Additional folding - 1D6AD; 03B6; Additional folding - 1D6AE; 03B7; Additional folding - 1D6AF; 03B8; Additional folding - 1D6B0; 03B9; Additional folding - 1D6B1; 03BA; Additional folding - 1D6B2; 03BB; Additional folding - 1D6B3; 03BC; Additional folding - 1D6B4; 03BD; Additional folding - 1D6B5; 03BE; Additional folding - 1D6B6; 03BF; Additional folding - 1D6B7; 03C0; Additional folding - 1D6B8; 03C1; Additional folding - 1D6B9; 03B8; Additional folding - 1D6BA; 03C3; Additional folding - 1D6BB; 03C4; Additional folding - 1D6BC; 03C5; Additional folding - 1D6BD; 03C6; Additional folding - 1D6BE; 03C7; Additional folding - 1D6BF; 03C8; Additional folding - 1D6C0; 03C9; Additional folding - 1D6D3; 03C3; Additional folding - 1D6E2; 03B1; Additional folding - 1D6E3; 03B2; Additional folding - 1D6E4; 03B3; Additional folding - 1D6E5; 03B4; Additional folding - 1D6E6; 03B5; Additional folding - 1D6E7; 03B6; Additional folding - - - -Hoffman & Blanchet Standards Track [Page 58] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 1D6E8; 03B7; Additional folding - 1D6E9; 03B8; Additional folding - 1D6EA; 03B9; Additional folding - 1D6EB; 03BA; Additional folding - 1D6EC; 03BB; Additional folding - 1D6ED; 03BC; Additional folding - 1D6EE; 03BD; Additional folding - 1D6EF; 03BE; Additional folding - 1D6F0; 03BF; Additional folding - 1D6F1; 03C0; Additional folding - 1D6F2; 03C1; Additional folding - 1D6F3; 03B8; Additional folding - 1D6F4; 03C3; Additional folding - 1D6F5; 03C4; Additional folding - 1D6F6; 03C5; Additional folding - 1D6F7; 03C6; Additional folding - 1D6F8; 03C7; Additional folding - 1D6F9; 03C8; Additional folding - 1D6FA; 03C9; Additional folding - 1D70D; 03C3; Additional folding - 1D71C; 03B1; Additional folding - 1D71D; 03B2; Additional folding - 1D71E; 03B3; Additional folding - 1D71F; 03B4; Additional folding - 1D720; 03B5; Additional folding - 1D721; 03B6; Additional folding - 1D722; 03B7; Additional folding - 1D723; 03B8; Additional folding - 1D724; 03B9; Additional folding - 1D725; 03BA; Additional folding - 1D726; 03BB; Additional folding - 1D727; 03BC; Additional folding - 1D728; 03BD; Additional folding - 1D729; 03BE; Additional folding - 1D72A; 03BF; Additional folding - 1D72B; 03C0; Additional folding - 1D72C; 03C1; Additional folding - 1D72D; 03B8; Additional folding - 1D72E; 03C3; Additional folding - 1D72F; 03C4; Additional folding - 1D730; 03C5; Additional folding - 1D731; 03C6; Additional folding - 1D732; 03C7; Additional folding - 1D733; 03C8; Additional folding - 1D734; 03C9; Additional folding - 1D747; 03C3; Additional folding - 1D756; 03B1; Additional folding - 1D757; 03B2; Additional folding - - - -Hoffman & Blanchet Standards Track [Page 59] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 1D758; 03B3; Additional folding - 1D759; 03B4; Additional folding - 1D75A; 03B5; Additional folding - 1D75B; 03B6; Additional folding - 1D75C; 03B7; Additional folding - 1D75D; 03B8; Additional folding - 1D75E; 03B9; Additional folding - 1D75F; 03BA; Additional folding - 1D760; 03BB; Additional folding - 1D761; 03BC; Additional folding - 1D762; 03BD; Additional folding - 1D763; 03BE; Additional folding - 1D764; 03BF; Additional folding - 1D765; 03C0; Additional folding - 1D766; 03C1; Additional folding - 1D767; 03B8; Additional folding - 1D768; 03C3; Additional folding - 1D769; 03C4; Additional folding - 1D76A; 03C5; Additional folding - 1D76B; 03C6; Additional folding - 1D76C; 03C7; Additional folding - 1D76D; 03C8; Additional folding - 1D76E; 03C9; Additional folding - 1D781; 03C3; Additional folding - 1D790; 03B1; Additional folding - 1D791; 03B2; Additional folding - 1D792; 03B3; Additional folding - 1D793; 03B4; Additional folding - 1D794; 03B5; Additional folding - 1D795; 03B6; Additional folding - 1D796; 03B7; Additional folding - 1D797; 03B8; Additional folding - 1D798; 03B9; Additional folding - 1D799; 03BA; Additional folding - 1D79A; 03BB; Additional folding - 1D79B; 03BC; Additional folding - 1D79C; 03BD; Additional folding - 1D79D; 03BE; Additional folding - 1D79E; 03BF; Additional folding - 1D79F; 03C0; Additional folding - 1D7A0; 03C1; Additional folding - 1D7A1; 03B8; Additional folding - 1D7A2; 03C3; Additional folding - 1D7A3; 03C4; Additional folding - 1D7A4; 03C5; Additional folding - 1D7A5; 03C6; Additional folding - 1D7A6; 03C7; Additional folding - 1D7A7; 03C8; Additional folding - - - -Hoffman & Blanchet Standards Track [Page 60] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 1D7A8; 03C9; Additional folding - 1D7BB; 03C3; Additional folding - ----- End Table B.2 ----- - -B.3 Mapping for case-folding used with no normalization - - ----- Start Table B.3 ----- - 0041; 0061; Case map - 0042; 0062; Case map - 0043; 0063; Case map - 0044; 0064; Case map - 0045; 0065; Case map - 0046; 0066; Case map - 0047; 0067; Case map - 0048; 0068; Case map - 0049; 0069; Case map - 004A; 006A; Case map - 004B; 006B; Case map - 004C; 006C; Case map - 004D; 006D; Case map - 004E; 006E; Case map - 004F; 006F; Case map - 0050; 0070; Case map - 0051; 0071; Case map - 0052; 0072; Case map - 0053; 0073; Case map - 0054; 0074; Case map - 0055; 0075; Case map - 0056; 0076; Case map - 0057; 0077; Case map - 0058; 0078; Case map - 0059; 0079; Case map - 005A; 007A; Case map - 00B5; 03BC; Case map - 00C0; 00E0; Case map - 00C1; 00E1; Case map - 00C2; 00E2; Case map - 00C3; 00E3; Case map - 00C4; 00E4; Case map - 00C5; 00E5; Case map - 00C6; 00E6; Case map - 00C7; 00E7; Case map - 00C8; 00E8; Case map - 00C9; 00E9; Case map - 00CA; 00EA; Case map - 00CB; 00EB; Case map - 00CC; 00EC; Case map - 00CD; 00ED; Case map - - - -Hoffman & Blanchet Standards Track [Page 61] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 00CE; 00EE; Case map - 00CF; 00EF; Case map - 00D0; 00F0; Case map - 00D1; 00F1; Case map - 00D2; 00F2; Case map - 00D3; 00F3; Case map - 00D4; 00F4; Case map - 00D5; 00F5; Case map - 00D6; 00F6; Case map - 00D8; 00F8; Case map - 00D9; 00F9; Case map - 00DA; 00FA; Case map - 00DB; 00FB; Case map - 00DC; 00FC; Case map - 00DD; 00FD; Case map - 00DE; 00FE; Case map - 00DF; 0073 0073; Case map - 0100; 0101; Case map - 0102; 0103; Case map - 0104; 0105; Case map - 0106; 0107; Case map - 0108; 0109; Case map - 010A; 010B; Case map - 010C; 010D; Case map - 010E; 010F; Case map - 0110; 0111; Case map - 0112; 0113; Case map - 0114; 0115; Case map - 0116; 0117; Case map - 0118; 0119; Case map - 011A; 011B; Case map - 011C; 011D; Case map - 011E; 011F; Case map - 0120; 0121; Case map - 0122; 0123; Case map - 0124; 0125; Case map - 0126; 0127; Case map - 0128; 0129; Case map - 012A; 012B; Case map - 012C; 012D; Case map - 012E; 012F; Case map - 0130; 0069 0307; Case map - 0132; 0133; Case map - 0134; 0135; Case map - 0136; 0137; Case map - 0139; 013A; Case map - 013B; 013C; Case map - 013D; 013E; Case map - - - -Hoffman & Blanchet Standards Track [Page 62] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 013F; 0140; Case map - 0141; 0142; Case map - 0143; 0144; Case map - 0145; 0146; Case map - 0147; 0148; Case map - 0149; 02BC 006E; Case map - 014A; 014B; Case map - 014C; 014D; Case map - 014E; 014F; Case map - 0150; 0151; Case map - 0152; 0153; Case map - 0154; 0155; Case map - 0156; 0157; Case map - 0158; 0159; Case map - 015A; 015B; Case map - 015C; 015D; Case map - 015E; 015F; Case map - 0160; 0161; Case map - 0162; 0163; Case map - 0164; 0165; Case map - 0166; 0167; Case map - 0168; 0169; Case map - 016A; 016B; Case map - 016C; 016D; Case map - 016E; 016F; Case map - 0170; 0171; Case map - 0172; 0173; Case map - 0174; 0175; Case map - 0176; 0177; Case map - 0178; 00FF; Case map - 0179; 017A; Case map - 017B; 017C; Case map - 017D; 017E; Case map - 017F; 0073; Case map - 0181; 0253; Case map - 0182; 0183; Case map - 0184; 0185; Case map - 0186; 0254; Case map - 0187; 0188; Case map - 0189; 0256; Case map - 018A; 0257; Case map - 018B; 018C; Case map - 018E; 01DD; Case map - 018F; 0259; Case map - 0190; 025B; Case map - 0191; 0192; Case map - 0193; 0260; Case map - 0194; 0263; Case map - - - -Hoffman & Blanchet Standards Track [Page 63] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 0196; 0269; Case map - 0197; 0268; Case map - 0198; 0199; Case map - 019C; 026F; Case map - 019D; 0272; Case map - 019F; 0275; Case map - 01A0; 01A1; Case map - 01A2; 01A3; Case map - 01A4; 01A5; Case map - 01A6; 0280; Case map - 01A7; 01A8; Case map - 01A9; 0283; Case map - 01AC; 01AD; Case map - 01AE; 0288; Case map - 01AF; 01B0; Case map - 01B1; 028A; Case map - 01B2; 028B; Case map - 01B3; 01B4; Case map - 01B5; 01B6; Case map - 01B7; 0292; Case map - 01B8; 01B9; Case map - 01BC; 01BD; Case map - 01C4; 01C6; Case map - 01C5; 01C6; Case map - 01C7; 01C9; Case map - 01C8; 01C9; Case map - 01CA; 01CC; Case map - 01CB; 01CC; Case map - 01CD; 01CE; Case map - 01CF; 01D0; Case map - 01D1; 01D2; Case map - 01D3; 01D4; Case map - 01D5; 01D6; Case map - 01D7; 01D8; Case map - 01D9; 01DA; Case map - 01DB; 01DC; Case map - 01DE; 01DF; Case map - 01E0; 01E1; Case map - 01E2; 01E3; Case map - 01E4; 01E5; Case map - 01E6; 01E7; Case map - 01E8; 01E9; Case map - 01EA; 01EB; Case map - 01EC; 01ED; Case map - 01EE; 01EF; Case map - 01F0; 006A 030C; Case map - 01F1; 01F3; Case map - 01F2; 01F3; Case map - - - -Hoffman & Blanchet Standards Track [Page 64] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 01F4; 01F5; Case map - 01F6; 0195; Case map - 01F7; 01BF; Case map - 01F8; 01F9; Case map - 01FA; 01FB; Case map - 01FC; 01FD; Case map - 01FE; 01FF; Case map - 0200; 0201; Case map - 0202; 0203; Case map - 0204; 0205; Case map - 0206; 0207; Case map - 0208; 0209; Case map - 020A; 020B; Case map - 020C; 020D; Case map - 020E; 020F; Case map - 0210; 0211; Case map - 0212; 0213; Case map - 0214; 0215; Case map - 0216; 0217; Case map - 0218; 0219; Case map - 021A; 021B; Case map - 021C; 021D; Case map - 021E; 021F; Case map - 0220; 019E; Case map - 0222; 0223; Case map - 0224; 0225; Case map - 0226; 0227; Case map - 0228; 0229; Case map - 022A; 022B; Case map - 022C; 022D; Case map - 022E; 022F; Case map - 0230; 0231; Case map - 0232; 0233; Case map - 0345; 03B9; Case map - 0386; 03AC; Case map - 0388; 03AD; Case map - 0389; 03AE; Case map - 038A; 03AF; Case map - 038C; 03CC; Case map - 038E; 03CD; Case map - 038F; 03CE; Case map - 0390; 03B9 0308 0301; Case map - 0391; 03B1; Case map - 0392; 03B2; Case map - 0393; 03B3; Case map - 0394; 03B4; Case map - 0395; 03B5; Case map - 0396; 03B6; Case map - - - -Hoffman & Blanchet Standards Track [Page 65] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 0397; 03B7; Case map - 0398; 03B8; Case map - 0399; 03B9; Case map - 039A; 03BA; Case map - 039B; 03BB; Case map - 039C; 03BC; Case map - 039D; 03BD; Case map - 039E; 03BE; Case map - 039F; 03BF; Case map - 03A0; 03C0; Case map - 03A1; 03C1; Case map - 03A3; 03C3; Case map - 03A4; 03C4; Case map - 03A5; 03C5; Case map - 03A6; 03C6; Case map - 03A7; 03C7; Case map - 03A8; 03C8; Case map - 03A9; 03C9; Case map - 03AA; 03CA; Case map - 03AB; 03CB; Case map - 03B0; 03C5 0308 0301; Case map - 03C2; 03C3; Case map - 03D0; 03B2; Case map - 03D1; 03B8; Case map - 03D5; 03C6; Case map - 03D6; 03C0; Case map - 03D8; 03D9; Case map - 03DA; 03DB; Case map - 03DC; 03DD; Case map - 03DE; 03DF; Case map - 03E0; 03E1; Case map - 03E2; 03E3; Case map - 03E4; 03E5; Case map - 03E6; 03E7; Case map - 03E8; 03E9; Case map - 03EA; 03EB; Case map - 03EC; 03ED; Case map - 03EE; 03EF; Case map - 03F0; 03BA; Case map - 03F1; 03C1; Case map - 03F2; 03C3; Case map - 03F4; 03B8; Case map - 03F5; 03B5; Case map - 0400; 0450; Case map - 0401; 0451; Case map - 0402; 0452; Case map - 0403; 0453; Case map - 0404; 0454; Case map - - - -Hoffman & Blanchet Standards Track [Page 66] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 0405; 0455; Case map - 0406; 0456; Case map - 0407; 0457; Case map - 0408; 0458; Case map - 0409; 0459; Case map - 040A; 045A; Case map - 040B; 045B; Case map - 040C; 045C; Case map - 040D; 045D; Case map - 040E; 045E; Case map - 040F; 045F; Case map - 0410; 0430; Case map - 0411; 0431; Case map - 0412; 0432; Case map - 0413; 0433; Case map - 0414; 0434; Case map - 0415; 0435; Case map - 0416; 0436; Case map - 0417; 0437; Case map - 0418; 0438; Case map - 0419; 0439; Case map - 041A; 043A; Case map - 041B; 043B; Case map - 041C; 043C; Case map - 041D; 043D; Case map - 041E; 043E; Case map - 041F; 043F; Case map - 0420; 0440; Case map - 0421; 0441; Case map - 0422; 0442; Case map - 0423; 0443; Case map - 0424; 0444; Case map - 0425; 0445; Case map - 0426; 0446; Case map - 0427; 0447; Case map - 0428; 0448; Case map - 0429; 0449; Case map - 042A; 044A; Case map - 042B; 044B; Case map - 042C; 044C; Case map - 042D; 044D; Case map - 042E; 044E; Case map - 042F; 044F; Case map - 0460; 0461; Case map - 0462; 0463; Case map - 0464; 0465; Case map - 0466; 0467; Case map - 0468; 0469; Case map - - - -Hoffman & Blanchet Standards Track [Page 67] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 046A; 046B; Case map - 046C; 046D; Case map - 046E; 046F; Case map - 0470; 0471; Case map - 0472; 0473; Case map - 0474; 0475; Case map - 0476; 0477; Case map - 0478; 0479; Case map - 047A; 047B; Case map - 047C; 047D; Case map - 047E; 047F; Case map - 0480; 0481; Case map - 048A; 048B; Case map - 048C; 048D; Case map - 048E; 048F; Case map - 0490; 0491; Case map - 0492; 0493; Case map - 0494; 0495; Case map - 0496; 0497; Case map - 0498; 0499; Case map - 049A; 049B; Case map - 049C; 049D; Case map - 049E; 049F; Case map - 04A0; 04A1; Case map - 04A2; 04A3; Case map - 04A4; 04A5; Case map - 04A6; 04A7; Case map - 04A8; 04A9; Case map - 04AA; 04AB; Case map - 04AC; 04AD; Case map - 04AE; 04AF; Case map - 04B0; 04B1; Case map - 04B2; 04B3; Case map - 04B4; 04B5; Case map - 04B6; 04B7; Case map - 04B8; 04B9; Case map - 04BA; 04BB; Case map - 04BC; 04BD; Case map - 04BE; 04BF; Case map - 04C1; 04C2; Case map - 04C3; 04C4; Case map - 04C5; 04C6; Case map - 04C7; 04C8; Case map - 04C9; 04CA; Case map - 04CB; 04CC; Case map - 04CD; 04CE; Case map - 04D0; 04D1; Case map - 04D2; 04D3; Case map - - - -Hoffman & Blanchet Standards Track [Page 68] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 04D4; 04D5; Case map - 04D6; 04D7; Case map - 04D8; 04D9; Case map - 04DA; 04DB; Case map - 04DC; 04DD; Case map - 04DE; 04DF; Case map - 04E0; 04E1; Case map - 04E2; 04E3; Case map - 04E4; 04E5; Case map - 04E6; 04E7; Case map - 04E8; 04E9; Case map - 04EA; 04EB; Case map - 04EC; 04ED; Case map - 04EE; 04EF; Case map - 04F0; 04F1; Case map - 04F2; 04F3; Case map - 04F4; 04F5; Case map - 04F8; 04F9; Case map - 0500; 0501; Case map - 0502; 0503; Case map - 0504; 0505; Case map - 0506; 0507; Case map - 0508; 0509; Case map - 050A; 050B; Case map - 050C; 050D; Case map - 050E; 050F; Case map - 0531; 0561; Case map - 0532; 0562; Case map - 0533; 0563; Case map - 0534; 0564; Case map - 0535; 0565; Case map - 0536; 0566; Case map - 0537; 0567; Case map - 0538; 0568; Case map - 0539; 0569; Case map - 053A; 056A; Case map - 053B; 056B; Case map - 053C; 056C; Case map - 053D; 056D; Case map - 053E; 056E; Case map - 053F; 056F; Case map - 0540; 0570; Case map - 0541; 0571; Case map - 0542; 0572; Case map - 0543; 0573; Case map - 0544; 0574; Case map - 0545; 0575; Case map - 0546; 0576; Case map - - - -Hoffman & Blanchet Standards Track [Page 69] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 0547; 0577; Case map - 0548; 0578; Case map - 0549; 0579; Case map - 054A; 057A; Case map - 054B; 057B; Case map - 054C; 057C; Case map - 054D; 057D; Case map - 054E; 057E; Case map - 054F; 057F; Case map - 0550; 0580; Case map - 0551; 0581; Case map - 0552; 0582; Case map - 0553; 0583; Case map - 0554; 0584; Case map - 0555; 0585; Case map - 0556; 0586; Case map - 0587; 0565 0582; Case map - 1E00; 1E01; Case map - 1E02; 1E03; Case map - 1E04; 1E05; Case map - 1E06; 1E07; Case map - 1E08; 1E09; Case map - 1E0A; 1E0B; Case map - 1E0C; 1E0D; Case map - 1E0E; 1E0F; Case map - 1E10; 1E11; Case map - 1E12; 1E13; Case map - 1E14; 1E15; Case map - 1E16; 1E17; Case map - 1E18; 1E19; Case map - 1E1A; 1E1B; Case map - 1E1C; 1E1D; Case map - 1E1E; 1E1F; Case map - 1E20; 1E21; Case map - 1E22; 1E23; Case map - 1E24; 1E25; Case map - 1E26; 1E27; Case map - 1E28; 1E29; Case map - 1E2A; 1E2B; Case map - 1E2C; 1E2D; Case map - 1E2E; 1E2F; Case map - 1E30; 1E31; Case map - 1E32; 1E33; Case map - 1E34; 1E35; Case map - 1E36; 1E37; Case map - 1E38; 1E39; Case map - 1E3A; 1E3B; Case map - 1E3C; 1E3D; Case map - - - -Hoffman & Blanchet Standards Track [Page 70] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 1E3E; 1E3F; Case map - 1E40; 1E41; Case map - 1E42; 1E43; Case map - 1E44; 1E45; Case map - 1E46; 1E47; Case map - 1E48; 1E49; Case map - 1E4A; 1E4B; Case map - 1E4C; 1E4D; Case map - 1E4E; 1E4F; Case map - 1E50; 1E51; Case map - 1E52; 1E53; Case map - 1E54; 1E55; Case map - 1E56; 1E57; Case map - 1E58; 1E59; Case map - 1E5A; 1E5B; Case map - 1E5C; 1E5D; Case map - 1E5E; 1E5F; Case map - 1E60; 1E61; Case map - 1E62; 1E63; Case map - 1E64; 1E65; Case map - 1E66; 1E67; Case map - 1E68; 1E69; Case map - 1E6A; 1E6B; Case map - 1E6C; 1E6D; Case map - 1E6E; 1E6F; Case map - 1E70; 1E71; Case map - 1E72; 1E73; Case map - 1E74; 1E75; Case map - 1E76; 1E77; Case map - 1E78; 1E79; Case map - 1E7A; 1E7B; Case map - 1E7C; 1E7D; Case map - 1E7E; 1E7F; Case map - 1E80; 1E81; Case map - 1E82; 1E83; Case map - 1E84; 1E85; Case map - 1E86; 1E87; Case map - 1E88; 1E89; Case map - 1E8A; 1E8B; Case map - 1E8C; 1E8D; Case map - 1E8E; 1E8F; Case map - 1E90; 1E91; Case map - 1E92; 1E93; Case map - 1E94; 1E95; Case map - 1E96; 0068 0331; Case map - 1E97; 0074 0308; Case map - 1E98; 0077 030A; Case map - 1E99; 0079 030A; Case map - - - -Hoffman & Blanchet Standards Track [Page 71] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 1E9A; 0061 02BE; Case map - 1E9B; 1E61; Case map - 1EA0; 1EA1; Case map - 1EA2; 1EA3; Case map - 1EA4; 1EA5; Case map - 1EA6; 1EA7; Case map - 1EA8; 1EA9; Case map - 1EAA; 1EAB; Case map - 1EAC; 1EAD; Case map - 1EAE; 1EAF; Case map - 1EB0; 1EB1; Case map - 1EB2; 1EB3; Case map - 1EB4; 1EB5; Case map - 1EB6; 1EB7; Case map - 1EB8; 1EB9; Case map - 1EBA; 1EBB; Case map - 1EBC; 1EBD; Case map - 1EBE; 1EBF; Case map - 1EC0; 1EC1; Case map - 1EC2; 1EC3; Case map - 1EC4; 1EC5; Case map - 1EC6; 1EC7; Case map - 1EC8; 1EC9; Case map - 1ECA; 1ECB; Case map - 1ECC; 1ECD; Case map - 1ECE; 1ECF; Case map - 1ED0; 1ED1; Case map - 1ED2; 1ED3; Case map - 1ED4; 1ED5; Case map - 1ED6; 1ED7; Case map - 1ED8; 1ED9; Case map - 1EDA; 1EDB; Case map - 1EDC; 1EDD; Case map - 1EDE; 1EDF; Case map - 1EE0; 1EE1; Case map - 1EE2; 1EE3; Case map - 1EE4; 1EE5; Case map - 1EE6; 1EE7; Case map - 1EE8; 1EE9; Case map - 1EEA; 1EEB; Case map - 1EEC; 1EED; Case map - 1EEE; 1EEF; Case map - 1EF0; 1EF1; Case map - 1EF2; 1EF3; Case map - 1EF4; 1EF5; Case map - 1EF6; 1EF7; Case map - 1EF8; 1EF9; Case map - 1F08; 1F00; Case map - - - -Hoffman & Blanchet Standards Track [Page 72] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 1F09; 1F01; Case map - 1F0A; 1F02; Case map - 1F0B; 1F03; Case map - 1F0C; 1F04; Case map - 1F0D; 1F05; Case map - 1F0E; 1F06; Case map - 1F0F; 1F07; Case map - 1F18; 1F10; Case map - 1F19; 1F11; Case map - 1F1A; 1F12; Case map - 1F1B; 1F13; Case map - 1F1C; 1F14; Case map - 1F1D; 1F15; Case map - 1F28; 1F20; Case map - 1F29; 1F21; Case map - 1F2A; 1F22; Case map - 1F2B; 1F23; Case map - 1F2C; 1F24; Case map - 1F2D; 1F25; Case map - 1F2E; 1F26; Case map - 1F2F; 1F27; Case map - 1F38; 1F30; Case map - 1F39; 1F31; Case map - 1F3A; 1F32; Case map - 1F3B; 1F33; Case map - 1F3C; 1F34; Case map - 1F3D; 1F35; Case map - 1F3E; 1F36; Case map - 1F3F; 1F37; Case map - 1F48; 1F40; Case map - 1F49; 1F41; Case map - 1F4A; 1F42; Case map - 1F4B; 1F43; Case map - 1F4C; 1F44; Case map - 1F4D; 1F45; Case map - 1F50; 03C5 0313; Case map - 1F52; 03C5 0313 0300; Case map - 1F54; 03C5 0313 0301; Case map - 1F56; 03C5 0313 0342; Case map - 1F59; 1F51; Case map - 1F5B; 1F53; Case map - 1F5D; 1F55; Case map - 1F5F; 1F57; Case map - 1F68; 1F60; Case map - 1F69; 1F61; Case map - 1F6A; 1F62; Case map - 1F6B; 1F63; Case map - 1F6C; 1F64; Case map - - - -Hoffman & Blanchet Standards Track [Page 73] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 1F6D; 1F65; Case map - 1F6E; 1F66; Case map - 1F6F; 1F67; Case map - 1F80; 1F00 03B9; Case map - 1F81; 1F01 03B9; Case map - 1F82; 1F02 03B9; Case map - 1F83; 1F03 03B9; Case map - 1F84; 1F04 03B9; Case map - 1F85; 1F05 03B9; Case map - 1F86; 1F06 03B9; Case map - 1F87; 1F07 03B9; Case map - 1F88; 1F00 03B9; Case map - 1F89; 1F01 03B9; Case map - 1F8A; 1F02 03B9; Case map - 1F8B; 1F03 03B9; Case map - 1F8C; 1F04 03B9; Case map - 1F8D; 1F05 03B9; Case map - 1F8E; 1F06 03B9; Case map - 1F8F; 1F07 03B9; Case map - 1F90; 1F20 03B9; Case map - 1F91; 1F21 03B9; Case map - 1F92; 1F22 03B9; Case map - 1F93; 1F23 03B9; Case map - 1F94; 1F24 03B9; Case map - 1F95; 1F25 03B9; Case map - 1F96; 1F26 03B9; Case map - 1F97; 1F27 03B9; Case map - 1F98; 1F20 03B9; Case map - 1F99; 1F21 03B9; Case map - 1F9A; 1F22 03B9; Case map - 1F9B; 1F23 03B9; Case map - 1F9C; 1F24 03B9; Case map - 1F9D; 1F25 03B9; Case map - 1F9E; 1F26 03B9; Case map - 1F9F; 1F27 03B9; Case map - 1FA0; 1F60 03B9; Case map - 1FA1; 1F61 03B9; Case map - 1FA2; 1F62 03B9; Case map - 1FA3; 1F63 03B9; Case map - 1FA4; 1F64 03B9; Case map - 1FA5; 1F65 03B9; Case map - 1FA6; 1F66 03B9; Case map - 1FA7; 1F67 03B9; Case map - 1FA8; 1F60 03B9; Case map - 1FA9; 1F61 03B9; Case map - 1FAA; 1F62 03B9; Case map - 1FAB; 1F63 03B9; Case map - 1FAC; 1F64 03B9; Case map - - - -Hoffman & Blanchet Standards Track [Page 74] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 1FAD; 1F65 03B9; Case map - 1FAE; 1F66 03B9; Case map - 1FAF; 1F67 03B9; Case map - 1FB2; 1F70 03B9; Case map - 1FB3; 03B1 03B9; Case map - 1FB4; 03AC 03B9; Case map - 1FB6; 03B1 0342; Case map - 1FB7; 03B1 0342 03B9; Case map - 1FB8; 1FB0; Case map - 1FB9; 1FB1; Case map - 1FBA; 1F70; Case map - 1FBB; 1F71; Case map - 1FBC; 03B1 03B9; Case map - 1FBE; 03B9; Case map - 1FC2; 1F74 03B9; Case map - 1FC3; 03B7 03B9; Case map - 1FC4; 03AE 03B9; Case map - 1FC6; 03B7 0342; Case map - 1FC7; 03B7 0342 03B9; Case map - 1FC8; 1F72; Case map - 1FC9; 1F73; Case map - 1FCA; 1F74; Case map - 1FCB; 1F75; Case map - 1FCC; 03B7 03B9; Case map - 1FD2; 03B9 0308 0300; Case map - 1FD3; 03B9 0308 0301; Case map - 1FD6; 03B9 0342; Case map - 1FD7; 03B9 0308 0342; Case map - 1FD8; 1FD0; Case map - 1FD9; 1FD1; Case map - 1FDA; 1F76; Case map - 1FDB; 1F77; Case map - 1FE2; 03C5 0308 0300; Case map - 1FE3; 03C5 0308 0301; Case map - 1FE4; 03C1 0313; Case map - 1FE6; 03C5 0342; Case map - 1FE7; 03C5 0308 0342; Case map - 1FE8; 1FE0; Case map - 1FE9; 1FE1; Case map - 1FEA; 1F7A; Case map - 1FEB; 1F7B; Case map - 1FEC; 1FE5; Case map - 1FF2; 1F7C 03B9; Case map - 1FF3; 03C9 03B9; Case map - 1FF4; 03CE 03B9; Case map - 1FF6; 03C9 0342; Case map - 1FF7; 03C9 0342 03B9; Case map - 1FF8; 1F78; Case map - - - -Hoffman & Blanchet Standards Track [Page 75] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 1FF9; 1F79; Case map - 1FFA; 1F7C; Case map - 1FFB; 1F7D; Case map - 1FFC; 03C9 03B9; Case map - 2126; 03C9; Case map - 212A; 006B; Case map - 212B; 00E5; Case map - 2160; 2170; Case map - 2161; 2171; Case map - 2162; 2172; Case map - 2163; 2173; Case map - 2164; 2174; Case map - 2165; 2175; Case map - 2166; 2176; Case map - 2167; 2177; Case map - 2168; 2178; Case map - 2169; 2179; Case map - 216A; 217A; Case map - 216B; 217B; Case map - 216C; 217C; Case map - 216D; 217D; Case map - 216E; 217E; Case map - 216F; 217F; Case map - 24B6; 24D0; Case map - 24B7; 24D1; Case map - 24B8; 24D2; Case map - 24B9; 24D3; Case map - 24BA; 24D4; Case map - 24BB; 24D5; Case map - 24BC; 24D6; Case map - 24BD; 24D7; Case map - 24BE; 24D8; Case map - 24BF; 24D9; Case map - 24C0; 24DA; Case map - 24C1; 24DB; Case map - 24C2; 24DC; Case map - 24C3; 24DD; Case map - 24C4; 24DE; Case map - 24C5; 24DF; Case map - 24C6; 24E0; Case map - 24C7; 24E1; Case map - 24C8; 24E2; Case map - 24C9; 24E3; Case map - 24CA; 24E4; Case map - 24CB; 24E5; Case map - 24CC; 24E6; Case map - 24CD; 24E7; Case map - 24CE; 24E8; Case map - - - -Hoffman & Blanchet Standards Track [Page 76] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 24CF; 24E9; Case map - FB00; 0066 0066; Case map - FB01; 0066 0069; Case map - FB02; 0066 006C; Case map - FB03; 0066 0066 0069; Case map - FB04; 0066 0066 006C; Case map - FB05; 0073 0074; Case map - FB06; 0073 0074; Case map - FB13; 0574 0576; Case map - FB14; 0574 0565; Case map - FB15; 0574 056B; Case map - FB16; 057E 0576; Case map - FB17; 0574 056D; Case map - FF21; FF41; Case map - FF22; FF42; Case map - FF23; FF43; Case map - FF24; FF44; Case map - FF25; FF45; Case map - FF26; FF46; Case map - FF27; FF47; Case map - FF28; FF48; Case map - FF29; FF49; Case map - FF2A; FF4A; Case map - FF2B; FF4B; Case map - FF2C; FF4C; Case map - FF2D; FF4D; Case map - FF2E; FF4E; Case map - FF2F; FF4F; Case map - FF30; FF50; Case map - FF31; FF51; Case map - FF32; FF52; Case map - FF33; FF53; Case map - FF34; FF54; Case map - FF35; FF55; Case map - FF36; FF56; Case map - FF37; FF57; Case map - FF38; FF58; Case map - FF39; FF59; Case map - FF3A; FF5A; Case map - 10400; 10428; Case map - 10401; 10429; Case map - 10402; 1042A; Case map - 10403; 1042B; Case map - 10404; 1042C; Case map - 10405; 1042D; Case map - 10406; 1042E; Case map - 10407; 1042F; Case map - 10408; 10430; Case map - - - -Hoffman & Blanchet Standards Track [Page 77] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 10409; 10431; Case map - 1040A; 10432; Case map - 1040B; 10433; Case map - 1040C; 10434; Case map - 1040D; 10435; Case map - 1040E; 10436; Case map - 1040F; 10437; Case map - 10410; 10438; Case map - 10411; 10439; Case map - 10412; 1043A; Case map - 10413; 1043B; Case map - 10414; 1043C; Case map - 10415; 1043D; Case map - 10416; 1043E; Case map - 10417; 1043F; Case map - 10418; 10440; Case map - 10419; 10441; Case map - 1041A; 10442; Case map - 1041B; 10443; Case map - 1041C; 10444; Case map - 1041D; 10445; Case map - 1041E; 10446; Case map - 1041F; 10447; Case map - 10420; 10448; Case map - 10421; 10449; Case map - 10422; 1044A; Case map - 10423; 1044B; Case map - 10424; 1044C; Case map - 10425; 1044D; Case map - ----- End Table B.3 ----- - -C. Prohibition tables - - The tables in this appendix consist of lines with one prohibited code - point per line. The format of the lines are the value of the code - point, a semicolon, and a comment which is the name of the code - point. - -C.1 Space characters - -C.1.1 ASCII space characters - - ----- Start Table C.1.1 ----- - 0020; SPACE - ----- End Table C.1.1 ----- - - - - - - -Hoffman & Blanchet Standards Track [Page 78] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - -C.1.2 Non-ASCII space characters - ----- Start Table C.1.2 ----- - 00A0; NO-BREAK SPACE - 1680; OGHAM SPACE MARK - 2000; EN QUAD - 2001; EM QUAD - 2002; EN SPACE - 2003; EM SPACE - 2004; THREE-PER-EM SPACE - 2005; FOUR-PER-EM SPACE - 2006; SIX-PER-EM SPACE - 2007; FIGURE SPACE - 2008; PUNCTUATION SPACE - 2009; THIN SPACE - 200A; HAIR SPACE - 200B; ZERO WIDTH SPACE - 202F; NARROW NO-BREAK SPACE - 205F; MEDIUM MATHEMATICAL SPACE - 3000; IDEOGRAPHIC SPACE - ----- End Table C.1.2 ----- - -C.2 Control characters - -C.2.1 ASCII control characters - - ----- Start Table C.2.1 ----- - 0000-001F; [CONTROL CHARACTERS] - 007F; DELETE - ----- End Table C.2.1 ----- - -C.2.2 Non-ASCII control characters - - ----- Start Table C.2.2 ----- - 0080-009F; [CONTROL CHARACTERS] - 06DD; ARABIC END OF AYAH - 070F; SYRIAC ABBREVIATION MARK - 180E; MONGOLIAN VOWEL SEPARATOR - 200C; ZERO WIDTH NON-JOINER - 200D; ZERO WIDTH JOINER - 2028; LINE SEPARATOR - 2029; PARAGRAPH SEPARATOR - 2060; WORD JOINER - 2061; FUNCTION APPLICATION - 2062; INVISIBLE TIMES - 2063; INVISIBLE SEPARATOR - 206A-206F; [CONTROL CHARACTERS] - FEFF; ZERO WIDTH NO-BREAK SPACE - FFF9-FFFC; [CONTROL CHARACTERS] - - - -Hoffman & Blanchet Standards Track [Page 79] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 1D173-1D17A; [MUSICAL CONTROL CHARACTERS] - ----- End Table C.2.2 ----- - -C.3 Private use - - ----- Start Table C.3 ----- - E000-F8FF; [PRIVATE USE, PLANE 0] - F0000-FFFFD; [PRIVATE USE, PLANE 15] - 100000-10FFFD; [PRIVATE USE, PLANE 16] - ----- End Table C.3 ----- - -C.4 Non-character code points - - ----- Start Table C.4 ----- - FDD0-FDEF; [NONCHARACTER CODE POINTS] - FFFE-FFFF; [NONCHARACTER CODE POINTS] - 1FFFE-1FFFF; [NONCHARACTER CODE POINTS] - 2FFFE-2FFFF; [NONCHARACTER CODE POINTS] - 3FFFE-3FFFF; [NONCHARACTER CODE POINTS] - 4FFFE-4FFFF; [NONCHARACTER CODE POINTS] - 5FFFE-5FFFF; [NONCHARACTER CODE POINTS] - 6FFFE-6FFFF; [NONCHARACTER CODE POINTS] - 7FFFE-7FFFF; [NONCHARACTER CODE POINTS] - 8FFFE-8FFFF; [NONCHARACTER CODE POINTS] - 9FFFE-9FFFF; [NONCHARACTER CODE POINTS] - AFFFE-AFFFF; [NONCHARACTER CODE POINTS] - BFFFE-BFFFF; [NONCHARACTER CODE POINTS] - CFFFE-CFFFF; [NONCHARACTER CODE POINTS] - DFFFE-DFFFF; [NONCHARACTER CODE POINTS] - EFFFE-EFFFF; [NONCHARACTER CODE POINTS] - FFFFE-FFFFF; [NONCHARACTER CODE POINTS] - 10FFFE-10FFFF; [NONCHARACTER CODE POINTS] - ----- End Table C.4 ----- - -C.5 Surrogate codes - - ----- Start Table C.5 ----- - D800-DFFF; [SURROGATE CODES] - ----- End Table C.5 ----- - -C.6 Inappropriate for plain text - - ----- Start Table C.6 ----- - FFF9; INTERLINEAR ANNOTATION ANCHOR - FFFA; INTERLINEAR ANNOTATION SEPARATOR - FFFB; INTERLINEAR ANNOTATION TERMINATOR - FFFC; OBJECT REPLACEMENT CHARACTER - FFFD; REPLACEMENT CHARACTER - - - -Hoffman & Blanchet Standards Track [Page 80] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - ----- End Table C.6 ----- - -C.7 Inappropriate for canonical representation - - ----- Start Table C.7 ----- - 2FF0-2FFB; [IDEOGRAPHIC DESCRIPTION CHARACTERS] - ----- End Table C.7 ----- - -C.8 Change display properties or are deprecated - - ----- Start Table C.8 ----- - 0340; COMBINING GRAVE TONE MARK - 0341; COMBINING ACUTE TONE MARK - 200E; LEFT-TO-RIGHT MARK - 200F; RIGHT-TO-LEFT MARK - 202A; LEFT-TO-RIGHT EMBEDDING - 202B; RIGHT-TO-LEFT EMBEDDING - 202C; POP DIRECTIONAL FORMATTING - 202D; LEFT-TO-RIGHT OVERRIDE - 202E; RIGHT-TO-LEFT OVERRIDE - 206A; INHIBIT SYMMETRIC SWAPPING - 206B; ACTIVATE SYMMETRIC SWAPPING - 206C; INHIBIT ARABIC FORM SHAPING - 206D; ACTIVATE ARABIC FORM SHAPING - 206E; NATIONAL DIGIT SHAPES - 206F; NOMINAL DIGIT SHAPES - ----- End Table C.8 ----- - -C.9 Tagging characters - - ----- Start Table C.9 ----- - E0001; LANGUAGE TAG - E0020-E007F; [TAGGING CHARACTERS] - ----- End Table C.9 ----- - -D. Bidirectional tables - -D.1 Characters with bidirectional property "R" or "AL" - - ----- Start Table D.1 ----- - 05BE - 05C0 - 05C3 - 05D0-05EA - 05F0-05F4 - 061B - 061F - 0621-063A - - - -Hoffman & Blanchet Standards Track [Page 81] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 0640-064A - 066D-066F - 0671-06D5 - 06DD - 06E5-06E6 - 06FA-06FE - 0700-070D - 0710 - 0712-072C - 0780-07A5 - 07B1 - 200F - FB1D - FB1F-FB28 - FB2A-FB36 - FB38-FB3C - FB3E - FB40-FB41 - FB43-FB44 - FB46-FBB1 - FBD3-FD3D - FD50-FD8F - FD92-FDC7 - FDF0-FDFC - FE70-FE74 - FE76-FEFC - ----- End Table D.1 ----- - -D.2 Characters with bidirectional property "L" - - ----- Start Table D.2 ----- - 0041-005A - 0061-007A - 00AA - 00B5 - 00BA - 00C0-00D6 - 00D8-00F6 - 00F8-0220 - 0222-0233 - 0250-02AD - 02B0-02B8 - 02BB-02C1 - 02D0-02D1 - 02E0-02E4 - 02EE - 037A - 0386 - - - -Hoffman & Blanchet Standards Track [Page 82] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 0388-038A - 038C - 038E-03A1 - 03A3-03CE - 03D0-03F5 - 0400-0482 - 048A-04CE - 04D0-04F5 - 04F8-04F9 - 0500-050F - 0531-0556 - 0559-055F - 0561-0587 - 0589 - 0903 - 0905-0939 - 093D-0940 - 0949-094C - 0950 - 0958-0961 - 0964-0970 - 0982-0983 - 0985-098C - 098F-0990 - 0993-09A8 - 09AA-09B0 - 09B2 - 09B6-09B9 - 09BE-09C0 - 09C7-09C8 - 09CB-09CC - 09D7 - 09DC-09DD - 09DF-09E1 - 09E6-09F1 - 09F4-09FA - 0A05-0A0A - 0A0F-0A10 - 0A13-0A28 - 0A2A-0A30 - 0A32-0A33 - 0A35-0A36 - 0A38-0A39 - 0A3E-0A40 - 0A59-0A5C - 0A5E - 0A66-0A6F - 0A72-0A74 - - - -Hoffman & Blanchet Standards Track [Page 83] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 0A83 - 0A85-0A8B - 0A8D - 0A8F-0A91 - 0A93-0AA8 - 0AAA-0AB0 - 0AB2-0AB3 - 0AB5-0AB9 - 0ABD-0AC0 - 0AC9 - 0ACB-0ACC - 0AD0 - 0AE0 - 0AE6-0AEF - 0B02-0B03 - 0B05-0B0C - 0B0F-0B10 - 0B13-0B28 - 0B2A-0B30 - 0B32-0B33 - 0B36-0B39 - 0B3D-0B3E - 0B40 - 0B47-0B48 - 0B4B-0B4C - 0B57 - 0B5C-0B5D - 0B5F-0B61 - 0B66-0B70 - 0B83 - 0B85-0B8A - 0B8E-0B90 - 0B92-0B95 - 0B99-0B9A - 0B9C - 0B9E-0B9F - 0BA3-0BA4 - 0BA8-0BAA - 0BAE-0BB5 - 0BB7-0BB9 - 0BBE-0BBF - 0BC1-0BC2 - 0BC6-0BC8 - 0BCA-0BCC - 0BD7 - 0BE7-0BF2 - 0C01-0C03 - 0C05-0C0C - - - -Hoffman & Blanchet Standards Track [Page 84] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 0C0E-0C10 - 0C12-0C28 - 0C2A-0C33 - 0C35-0C39 - 0C41-0C44 - 0C60-0C61 - 0C66-0C6F - 0C82-0C83 - 0C85-0C8C - 0C8E-0C90 - 0C92-0CA8 - 0CAA-0CB3 - 0CB5-0CB9 - 0CBE - 0CC0-0CC4 - 0CC7-0CC8 - 0CCA-0CCB - 0CD5-0CD6 - 0CDE - 0CE0-0CE1 - 0CE6-0CEF - 0D02-0D03 - 0D05-0D0C - 0D0E-0D10 - 0D12-0D28 - 0D2A-0D39 - 0D3E-0D40 - 0D46-0D48 - 0D4A-0D4C - 0D57 - 0D60-0D61 - 0D66-0D6F - 0D82-0D83 - 0D85-0D96 - 0D9A-0DB1 - 0DB3-0DBB - 0DBD - 0DC0-0DC6 - 0DCF-0DD1 - 0DD8-0DDF - 0DF2-0DF4 - 0E01-0E30 - 0E32-0E33 - 0E40-0E46 - 0E4F-0E5B - 0E81-0E82 - 0E84 - 0E87-0E88 - - - -Hoffman & Blanchet Standards Track [Page 85] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 0E8A - 0E8D - 0E94-0E97 - 0E99-0E9F - 0EA1-0EA3 - 0EA5 - 0EA7 - 0EAA-0EAB - 0EAD-0EB0 - 0EB2-0EB3 - 0EBD - 0EC0-0EC4 - 0EC6 - 0ED0-0ED9 - 0EDC-0EDD - 0F00-0F17 - 0F1A-0F34 - 0F36 - 0F38 - 0F3E-0F47 - 0F49-0F6A - 0F7F - 0F85 - 0F88-0F8B - 0FBE-0FC5 - 0FC7-0FCC - 0FCF - 1000-1021 - 1023-1027 - 1029-102A - 102C - 1031 - 1038 - 1040-1057 - 10A0-10C5 - 10D0-10F8 - 10FB - 1100-1159 - 115F-11A2 - 11A8-11F9 - 1200-1206 - 1208-1246 - 1248 - 124A-124D - 1250-1256 - 1258 - 125A-125D - 1260-1286 - - - -Hoffman & Blanchet Standards Track [Page 86] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 1288 - 128A-128D - 1290-12AE - 12B0 - 12B2-12B5 - 12B8-12BE - 12C0 - 12C2-12C5 - 12C8-12CE - 12D0-12D6 - 12D8-12EE - 12F0-130E - 1310 - 1312-1315 - 1318-131E - 1320-1346 - 1348-135A - 1361-137C - 13A0-13F4 - 1401-1676 - 1681-169A - 16A0-16F0 - 1700-170C - 170E-1711 - 1720-1731 - 1735-1736 - 1740-1751 - 1760-176C - 176E-1770 - 1780-17B6 - 17BE-17C5 - 17C7-17C8 - 17D4-17DA - 17DC - 17E0-17E9 - 1810-1819 - 1820-1877 - 1880-18A8 - 1E00-1E9B - 1EA0-1EF9 - 1F00-1F15 - 1F18-1F1D - 1F20-1F45 - 1F48-1F4D - 1F50-1F57 - 1F59 - 1F5B - 1F5D - - - -Hoffman & Blanchet Standards Track [Page 87] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 1F5F-1F7D - 1F80-1FB4 - 1FB6-1FBC - 1FBE - 1FC2-1FC4 - 1FC6-1FCC - 1FD0-1FD3 - 1FD6-1FDB - 1FE0-1FEC - 1FF2-1FF4 - 1FF6-1FFC - 200E - 2071 - 207F - 2102 - 2107 - 210A-2113 - 2115 - 2119-211D - 2124 - 2126 - 2128 - 212A-212D - 212F-2131 - 2133-2139 - 213D-213F - 2145-2149 - 2160-2183 - 2336-237A - 2395 - 249C-24E9 - 3005-3007 - 3021-3029 - 3031-3035 - 3038-303C - 3041-3096 - 309D-309F - 30A1-30FA - 30FC-30FF - 3105-312C - 3131-318E - 3190-31B7 - 31F0-321C - 3220-3243 - 3260-327B - 327F-32B0 - 32C0-32CB - 32D0-32FE - - - -Hoffman & Blanchet Standards Track [Page 88] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 3300-3376 - 337B-33DD - 33E0-33FE - 3400-4DB5 - 4E00-9FA5 - A000-A48C - AC00-D7A3 - D800-FA2D - FA30-FA6A - FB00-FB06 - FB13-FB17 - FF21-FF3A - FF41-FF5A - FF66-FFBE - FFC2-FFC7 - FFCA-FFCF - FFD2-FFD7 - FFDA-FFDC - 10300-1031E - 10320-10323 - 10330-1034A - 10400-10425 - 10428-1044D - 1D000-1D0F5 - 1D100-1D126 - 1D12A-1D166 - 1D16A-1D172 - 1D183-1D184 - 1D18C-1D1A9 - 1D1AE-1D1DD - 1D400-1D454 - 1D456-1D49C - 1D49E-1D49F - 1D4A2 - 1D4A5-1D4A6 - 1D4A9-1D4AC - 1D4AE-1D4B9 - 1D4BB - 1D4BD-1D4C0 - 1D4C2-1D4C3 - 1D4C5-1D505 - 1D507-1D50A - 1D50D-1D514 - 1D516-1D51C - 1D51E-1D539 - 1D53B-1D53E - 1D540-1D544 - 1D546 - - - -Hoffman & Blanchet Standards Track [Page 89] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - - 1D54A-1D550 - 1D552-1D6A3 - 1D6A8-1D7C9 - 20000-2A6D6 - 2F800-2FA1D - F0000-FFFFD - 100000-10FFFD - ----- End Table D.2 ----- - -Authors' Addresses - - Paul Hoffman - Internet Mail Consortium and VPN Consortium - 127 Segre Place - Santa Cruz, CA 95060 USA - - EMail: paul.hoffman@imc.org and paul.hoffman@vpnc.org - - - Marc Blanchet - Viagenie inc. - 2875 boul. Laurier, bur. 300 - Ste-Foy, Quebec, Canada, G1V 2M2 - - EMail: Marc.Blanchet@viagenie.qc.ca - - - - - - - - - - - - - - - - - - - - - - - - - - -Hoffman & Blanchet Standards Track [Page 90] - -RFC 3454 Preparation of Internationalized Strings December 2002 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2002). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Hoffman & Blanchet Standards Track [Page 91] - diff --git a/source4/heimdal/lib/wind/rfc3490.txt b/source4/heimdal/lib/wind/rfc3490.txt deleted file mode 100644 index d2e0b3b75a..0000000000 --- a/source4/heimdal/lib/wind/rfc3490.txt +++ /dev/null @@ -1,1235 +0,0 @@ - - - - - - -Network Working Group P. Faltstrom -Request for Comments: 3490 Cisco -Category: Standards Track P. Hoffman - IMC & VPNC - A. Costello - UC Berkeley - March 2003 - - - Internationalizing Domain Names in Applications (IDNA) - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - Until now, there has been no standard method for domain names to use - characters outside the ASCII repertoire. This document defines - internationalized domain names (IDNs) and a mechanism called - Internationalizing Domain Names in Applications (IDNA) for handling - them in a standard fashion. IDNs use characters drawn from a large - repertoire (Unicode), but IDNA allows the non-ASCII characters to be - represented using only the ASCII characters already allowed in so- - called host names today. This backward-compatible representation is - required in existing protocols like DNS, so that IDNs can be - introduced with no changes to the existing infrastructure. IDNA is - only meant for processing domain names, not free text. - -Table of Contents - - 1. Introduction.................................................. 2 - 1.1 Problem Statement......................................... 3 - 1.2 Limitations of IDNA....................................... 3 - 1.3 Brief overview for application developers................. 4 - 2. Terminology................................................... 5 - 3. Requirements and applicability................................ 7 - 3.1 Requirements.............................................. 7 - 3.2 Applicability............................................. 8 - 3.2.1. DNS resource records................................ 8 - - - -Faltstrom, et al. Standards Track [Page 1] - -RFC 3490 IDNA March 2003 - - - 3.2.2. Non-domain-name data types stored in domain names... 9 - 4. Conversion operations......................................... 9 - 4.1 ToASCII................................................... 10 - 4.2 ToUnicode................................................. 11 - 5. ACE prefix.................................................... 12 - 6. Implications for typical applications using DNS............... 13 - 6.1 Entry and display in applications......................... 14 - 6.2 Applications and resolver libraries....................... 15 - 6.3 DNS servers............................................... 15 - 6.4 Avoiding exposing users to the raw ACE encoding........... 16 - 6.5 DNSSEC authentication of IDN domain names................ 16 - 7. Name server considerations.................................... 17 - 8. Root server considerations.................................... 17 - 9. References.................................................... 18 - 9.1 Normative References...................................... 18 - 9.2 Informative References.................................... 18 - 10. Security Considerations...................................... 19 - 11. IANA Considerations.......................................... 20 - 12. Authors' Addresses........................................... 21 - 13. Full Copyright Statement..................................... 22 - -1. Introduction - - IDNA works by allowing applications to use certain ASCII name labels - (beginning with a special prefix) to represent non-ASCII name labels. - Lower-layer protocols need not be aware of this; therefore IDNA does - not depend on changes to any infrastructure. In particular, IDNA - does not depend on any changes to DNS servers, resolvers, or protocol - elements, because the ASCII name service provided by the existing DNS - is entirely sufficient for IDNA. - - This document does not require any applications to conform to IDNA, - but applications can elect to use IDNA in order to support IDN while - maintaining interoperability with existing infrastructure. If an - application wants to use non-ASCII characters in domain names, IDNA - is the only currently-defined option. Adding IDNA support to an - existing application entails changes to the application only, and - leaves room for flexibility in the user interface. - - A great deal of the discussion of IDN solutions has focused on - transition issues and how IDN will work in a world where not all of - the components have been updated. Proposals that were not chosen by - the IDN Working Group would depend on user applications, resolvers, - and DNS servers being updated in order for a user to use an - internationalized domain name. Rather than rely on widespread - updating of all components, IDNA depends on updates to user - applications only; no changes are needed to the DNS protocol or any - DNS servers or the resolvers on user's computers. - - - -Faltstrom, et al. Standards Track [Page 2] - -RFC 3490 IDNA March 2003 - - -1.1 Problem Statement - - The IDNA specification solves the problem of extending the repertoire - of characters that can be used in domain names to include the Unicode - repertoire (with some restrictions). - - IDNA does not extend the service offered by DNS to the applications. - Instead, the applications (and, by implication, the users) continue - to see an exact-match lookup service. Either there is a single - exactly-matching name or there is no match. This model has served - the existing applications well, but it requires, with or without - internationalized domain names, that users know the exact spelling of - the domain names that the users type into applications such as web - browsers and mail user agents. The introduction of the larger - repertoire of characters potentially makes the set of misspellings - larger, especially given that in some cases the same appearance, for - example on a business card, might visually match several Unicode code - points or several sequences of code points. - - IDNA allows the graceful introduction of IDNs not only by avoiding - upgrades to existing infrastructure (such as DNS servers and mail - transport agents), but also by allowing some rudimentary use of IDNs - in applications by using the ASCII representation of the non-ASCII - name labels. While such names are very user-unfriendly to read and - type, and hence are not suitable for user input, they allow (for - instance) replying to email and clicking on URLs even though the - domain name displayed is incomprehensible to the user. In order to - allow user-friendly input and output of the IDNs, the applications - need to be modified to conform to this specification. - - IDNA uses the Unicode character repertoire, which avoids the - significant delays that would be inherent in waiting for a different - and specific character set be defined for IDN purposes by some other - standards developing organization. - -1.2 Limitations of IDNA - - The IDNA protocol does not solve all linguistic issues with users - inputting names in different scripts. Many important language-based - and script-based mappings are not covered in IDNA and need to be - handled outside the protocol. For example, names that are entered in - a mix of traditional and simplified Chinese characters will not be - mapped to a single canonical name. Another example is Scandinavian - names that are entered with U+00F6 (LATIN SMALL LETTER O WITH - DIAERESIS) will not be mapped to U+00F8 (LATIN SMALL LETTER O WITH - STROKE). - - - - - -Faltstrom, et al. Standards Track [Page 3] - -RFC 3490 IDNA March 2003 - - - An example of an important issue that is not considered in detail in - IDNA is how to provide a high probability that a user who is entering - a domain name based on visual information (such as from a business - card or billboard) or aural information (such as from a telephone or - radio) would correctly enter the IDN. Similar issues exist for ASCII - domain names, for example the possible visual confusion between the - letter 'O' and the digit zero, but the introduction of the larger - repertoire of characters creates more opportunities of similar - looking and similar sounding names. Note that this is a complex - issue relating to languages, input methods on computers, and so on. - Furthermore, the kind of matching and searching necessary for a high - probability of success would not fit the role of the DNS and its - exact matching function. - -1.3 Brief overview for application developers - - Applications can use IDNA to support internationalized domain names - anywhere that ASCII domain names are already supported, including DNS - master files and resolver interfaces. (Applications can also define - protocols and interfaces that support IDNs directly using non-ASCII - representations. IDNA does not prescribe any particular - representation for new protocols, but it still defines which names - are valid and how they are compared.) - - The IDNA protocol is contained completely within applications. It is - not a client-server or peer-to-peer protocol: everything is done - inside the application itself. When used with a DNS resolver - library, IDNA is inserted as a "shim" between the application and the - resolver library. When used for writing names into a DNS zone, IDNA - is used just before the name is committed to the zone. - - There are two operations described in section 4 of this document: - - - The ToASCII operation is used before sending an IDN to something - that expects ASCII names (such as a resolver) or writing an IDN - into a place that expects ASCII names (such as a DNS master file). - - - The ToUnicode operation is used when displaying names to users, - for example names obtained from a DNS zone. - - It is important to note that the ToASCII operation can fail. If it - fails when processing a domain name, that domain name cannot be used - as an internationalized domain name and the application has to have - some method of dealing with this failure. - - IDNA requires that implementations process input strings with - Nameprep [NAMEPREP], which is a profile of Stringprep [STRINGPREP], - and then with Punycode [PUNYCODE]. Implementations of IDNA MUST - - - -Faltstrom, et al. Standards Track [Page 4] - -RFC 3490 IDNA March 2003 - - - fully implement Nameprep and Punycode; neither Nameprep nor Punycode - are optional. - -2. Terminology - - The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", - and "MAY" in this document are to be interpreted as described in BCP - 14, RFC 2119 [RFC2119]. - - A code point is an integer value associated with a character in a - coded character set. - - Unicode [UNICODE] is a coded character set containing tens of - thousands of characters. A single Unicode code point is denoted by - "U+" followed by four to six hexadecimal digits, while a range of - Unicode code points is denoted by two hexadecimal numbers separated - by "..", with no prefixes. - - ASCII means US-ASCII [USASCII], a coded character set containing 128 - characters associated with code points in the range 0..7F. Unicode - is an extension of ASCII: it includes all the ASCII characters and - associates them with the same code points. - - The term "LDH code points" is defined in this document to mean the - code points associated with ASCII letters, digits, and the hyphen- - minus; that is, U+002D, 30..39, 41..5A, and 61..7A. "LDH" is an - abbreviation for "letters, digits, hyphen". - - [STD13] talks about "domain names" and "host names", but many people - use the terms interchangeably. Further, because [STD13] was not - terribly clear, many people who are sure they know the exact - definitions of each of these terms disagree on the definitions. In - this document the term "domain name" is used in general. This - document explicitly cites [STD3] whenever referring to the host name - syntax restrictions defined therein. - - A label is an individual part of a domain name. Labels are usually - shown separated by dots; for example, the domain name - "www.example.com" is composed of three labels: "www", "example", and - "com". (The zero-length root label described in [STD13], which can - be explicit as in "www.example.com." or implicit as in - "www.example.com", is not considered a label in this specification.) - IDNA extends the set of usable characters in labels that are text. - For the rest of this document, the term "label" is shorthand for - "text label", and "every label" means "every text label". - - - - - - -Faltstrom, et al. Standards Track [Page 5] - -RFC 3490 IDNA March 2003 - - - An "internationalized label" is a label to which the ToASCII - operation (see section 4) can be applied without failing (with the - UseSTD3ASCIIRules flag unset). This implies that every ASCII label - that satisfies the [STD13] length restriction is an internationalized - label. Therefore the term "internationalized label" is a - generalization, embracing both old ASCII labels and new non-ASCII - labels. Although most Unicode characters can appear in - internationalized labels, ToASCII will fail for some input strings, - and such strings are not valid internationalized labels. - - An "internationalized domain name" (IDN) is a domain name in which - every label is an internationalized label. This implies that every - ASCII domain name is an IDN (which implies that it is possible for a - name to be an IDN without it containing any non-ASCII characters). - This document does not attempt to define an "internationalized host - name". Just as has been the case with ASCII names, some DNS zone - administrators may impose restrictions, beyond those imposed by DNS - or IDNA, on the characters or strings that may be registered as - labels in their zones. Such restrictions have no impact on the - syntax or semantics of DNS protocol messages; a query for a name that - matches no records will yield the same response regardless of the - reason why it is not in the zone. Clients issuing queries or - interpreting responses cannot be assumed to have any knowledge of - zone-specific restrictions or conventions. - - In IDNA, equivalence of labels is defined in terms of the ToASCII - operation, which constructs an ASCII form for a given label, whether - or not the label was already an ASCII label. Labels are defined to - be equivalent if and only if their ASCII forms produced by ToASCII - match using a case-insensitive ASCII comparison. ASCII labels - already have a notion of equivalence: upper case and lower case are - considered equivalent. The IDNA notion of equivalence is an - extension of that older notion. Equivalent labels in IDNA are - treated as alternate forms of the same label, just as "foo" and "Foo" - are treated as alternate forms of the same label. - - To allow internationalized labels to be handled by existing - applications, IDNA uses an "ACE label" (ACE stands for ASCII - Compatible Encoding). An ACE label is an internationalized label - that can be rendered in ASCII and is equivalent to an - internationalized label that cannot be rendered in ASCII. Given any - internationalized label that cannot be rendered in ASCII, the ToASCII - operation will convert it to an equivalent ACE label (whereas an - ASCII label will be left unaltered by ToASCII). ACE labels are - unsuitable for display to users. The ToUnicode operation will - convert any label to an equivalent non-ACE label. In fact, an ACE - label is formally defined to be any label that the ToUnicode - operation would alter (whereas non-ACE labels are left unaltered by - - - -Faltstrom, et al. Standards Track [Page 6] - -RFC 3490 IDNA March 2003 - - - ToUnicode). Every ACE label begins with the ACE prefix specified in - section 5. The ToASCII and ToUnicode operations are specified in - section 4. - - The "ACE prefix" is defined in this document to be a string of ASCII - characters that appears at the beginning of every ACE label. It is - specified in section 5. - - A "domain name slot" is defined in this document to be a protocol - element or a function argument or a return value (and so on) - explicitly designated for carrying a domain name. Examples of domain - name slots include: the QNAME field of a DNS query; the name argument - of the gethostbyname() library function; the part of an email address - following the at-sign (@) in the From: field of an email message - header; and the host portion of the URI in the src attribute of an - HTML <IMG> tag. General text that just happens to contain a domain - name is not a domain name slot; for example, a domain name appearing - in the plain text body of an email message is not occupying a domain - name slot. - - An "IDN-aware domain name slot" is defined in this document to be a - domain name slot explicitly designated for carrying an - internationalized domain name as defined in this document. The - designation may be static (for example, in the specification of the - protocol or interface) or dynamic (for example, as a result of - negotiation in an interactive session). - - An "IDN-unaware domain name slot" is defined in this document to be - any domain name slot that is not an IDN-aware domain name slot. - Obviously, this includes any domain name slot whose specification - predates IDNA. - -3. Requirements and applicability - -3.1 Requirements - - IDNA conformance means adherence to the following four requirements: - - 1) Whenever dots are used as label separators, the following - characters MUST be recognized as dots: U+002E (full stop), U+3002 - (ideographic full stop), U+FF0E (fullwidth full stop), U+FF61 - (halfwidth ideographic full stop). - - 2) Whenever a domain name is put into an IDN-unaware domain name slot - (see section 2), it MUST contain only ASCII characters. Given an - internationalized domain name (IDN), an equivalent domain name - satisfying this requirement can be obtained by applying the - - - - -Faltstrom, et al. Standards Track [Page 7] - -RFC 3490 IDNA March 2003 - - - ToASCII operation (see section 4) to each label and, if dots are - used as label separators, changing all the label separators to - U+002E. - - 3) ACE labels obtained from domain name slots SHOULD be hidden from - users when it is known that the environment can handle the non-ACE - form, except when the ACE form is explicitly requested. When it - is not known whether or not the environment can handle the non-ACE - form, the application MAY use the non-ACE form (which might fail, - such as by not being displayed properly), or it MAY use the ACE - form (which will look unintelligle to the user). Given an - internationalized domain name, an equivalent domain name - containing no ACE labels can be obtained by applying the ToUnicode - operation (see section 4) to each label. When requirements 2 and - 3 both apply, requirement 2 takes precedence. - - 4) Whenever two labels are compared, they MUST be considered to match - if and only if they are equivalent, that is, their ASCII forms - (obtained by applying ToASCII) match using a case-insensitive - ASCII comparison. Whenever two names are compared, they MUST be - considered to match if and only if their corresponding labels - match, regardless of whether the names use the same forms of label - separators. - -3.2 Applicability - - IDNA is applicable to all domain names in all domain name slots - except where it is explicitly excluded. - - This implies that IDNA is applicable to many protocols that predate - IDNA. Note that IDNs occupying domain name slots in those protocols - MUST be in ASCII form (see section 3.1, requirement 2). - -3.2.1. DNS resource records - - IDNA does not apply to domain names in the NAME and RDATA fields of - DNS resource records whose CLASS is not IN. This exclusion applies - to every non-IN class, present and future, except where future - standards override this exclusion by explicitly inviting the use of - IDNA. - - There are currently no other exclusions on the applicability of IDNA - to DNS resource records; it depends entirely on the CLASS, and not on - the TYPE. This will remain true, even as new types are defined, - unless there is a compelling reason for a new type to complicate - matters by imposing type-specific rules. - - - - - -Faltstrom, et al. Standards Track [Page 8] - -RFC 3490 IDNA March 2003 - - -3.2.2. Non-domain-name data types stored in domain names - - Although IDNA enables the representation of non-ASCII characters in - domain names, that does not imply that IDNA enables the - representation of non-ASCII characters in other data types that are - stored in domain names. For example, an email address local part is - sometimes stored in a domain label (hostmaster@example.com would be - represented as hostmaster.example.com in the RDATA field of an SOA - record). IDNA does not update the existing email standards, which - allow only ASCII characters in local parts. Therefore, unless the - email standards are revised to invite the use of IDNA for local - parts, a domain label that holds the local part of an email address - SHOULD NOT begin with the ACE prefix, and even if it does, it is to - be interpreted literally as a local part that happens to begin with - the ACE prefix. - -4. Conversion operations - - An application converts a domain name put into an IDN-unaware slot or - displayed to a user. This section specifies the steps to perform in - the conversion, and the ToASCII and ToUnicode operations. - - The input to ToASCII or ToUnicode is a single label that is a - sequence of Unicode code points (remember that all ASCII code points - are also Unicode code points). If a domain name is represented using - a character set other than Unicode or US-ASCII, it will first need to - be transcoded to Unicode. - - Starting from a whole domain name, the steps that an application - takes to do the conversions are: - - 1) Decide whether the domain name is a "stored string" or a "query - string" as described in [STRINGPREP]. If this conversion follows - the "queries" rule from [STRINGPREP], set the flag called - "AllowUnassigned". - - 2) Split the domain name into individual labels as described in - section 3.1. The labels do not include the separator. - - 3) For each label, decide whether or not to enforce the restrictions - on ASCII characters in host names [STD3]. (Applications already - faced this choice before the introduction of IDNA, and can - continue to make the decision the same way they always have; IDNA - makes no new recommendations regarding this choice.) If the - restrictions are to be enforced, set the flag called - "UseSTD3ASCIIRules" for that label. - - - - - -Faltstrom, et al. Standards Track [Page 9] - -RFC 3490 IDNA March 2003 - - - 4) Process each label with either the ToASCII or the ToUnicode - operation as appropriate. Typically, you use the ToASCII - operation if you are about to put the name into an IDN-unaware - slot, and you use the ToUnicode operation if you are displaying - the name to a user; section 3.1 gives greater detail on the - applicable requirements. - - 5) If ToASCII was applied in step 4 and dots are used as label - separators, change all the label separators to U+002E (full stop). - - The following two subsections define the ToASCII and ToUnicode - operations that are used in step 4. - - This description of the protocol uses specific procedure names, names - of flags, and so on, in order to facilitate the specification of the - protocol. These names, as well as the actual steps of the - procedures, are not required of an implementation. In fact, any - implementation which has the same external behavior as specified in - this document conforms to this specification. - -4.1 ToASCII - - The ToASCII operation takes a sequence of Unicode code points that - make up one label and transforms it into a sequence of code points in - the ASCII range (0..7F). If ToASCII succeeds, the original sequence - and the resulting sequence are equivalent labels. - - It is important to note that the ToASCII operation can fail. ToASCII - fails if any step of it fails. If any step of the ToASCII operation - fails on any label in a domain name, that domain name MUST NOT be - used as an internationalized domain name. The method for dealing - with this failure is application-specific. - - The inputs to ToASCII are a sequence of code points, the - AllowUnassigned flag, and the UseSTD3ASCIIRules flag. The output of - ToASCII is either a sequence of ASCII code points or a failure - condition. - - ToASCII never alters a sequence of code points that are all in the - ASCII range to begin with (although it could fail). Applying the - ToASCII operation multiple times has exactly the same effect as - applying it just once. - - ToASCII consists of the following steps: - - 1. If the sequence contains any code points outside the ASCII range - (0..7F) then proceed to step 2, otherwise skip to step 3. - - - - -Faltstrom, et al. Standards Track [Page 10] - -RFC 3490 IDNA March 2003 - - - 2. Perform the steps specified in [NAMEPREP] and fail if there is an - error. The AllowUnassigned flag is used in [NAMEPREP]. - - 3. If the UseSTD3ASCIIRules flag is set, then perform these checks: - - (a) Verify the absence of non-LDH ASCII code points; that is, the - absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F. - - (b) Verify the absence of leading and trailing hyphen-minus; that - is, the absence of U+002D at the beginning and end of the - sequence. - - 4. If the sequence contains any code points outside the ASCII range - (0..7F) then proceed to step 5, otherwise skip to step 8. - - 5. Verify that the sequence does NOT begin with the ACE prefix. - - 6. Encode the sequence using the encoding algorithm in [PUNYCODE] and - fail if there is an error. - - 7. Prepend the ACE prefix. - - 8. Verify that the number of code points is in the range 1 to 63 - inclusive. - -4.2 ToUnicode - - The ToUnicode operation takes a sequence of Unicode code points that - make up one label and returns a sequence of Unicode code points. If - the input sequence is a label in ACE form, then the result is an - equivalent internationalized label that is not in ACE form, otherwise - the original sequence is returned unaltered. - - ToUnicode never fails. If any step fails, then the original input - sequence is returned immediately in that step. - - The ToUnicode output never contains more code points than its input. - Note that the number of octets needed to represent a sequence of code - points depends on the particular character encoding used. - - The inputs to ToUnicode are a sequence of code points, the - AllowUnassigned flag, and the UseSTD3ASCIIRules flag. The output of - ToUnicode is always a sequence of Unicode code points. - - 1. If all code points in the sequence are in the ASCII range (0..7F) - then skip to step 3. - - - - - -Faltstrom, et al. Standards Track [Page 11] - -RFC 3490 IDNA March 2003 - - - 2. Perform the steps specified in [NAMEPREP] and fail if there is an - error. (If step 3 of ToASCII is also performed here, it will not - affect the overall behavior of ToUnicode, but it is not - necessary.) The AllowUnassigned flag is used in [NAMEPREP]. - - 3. Verify that the sequence begins with the ACE prefix, and save a - copy of the sequence. - - 4. Remove the ACE prefix. - - 5. Decode the sequence using the decoding algorithm in [PUNYCODE] and - fail if there is an error. Save a copy of the result of this - step. - - 6. Apply ToASCII. - - 7. Verify that the result of step 6 matches the saved copy from step - 3, using a case-insensitive ASCII comparison. - - 8. Return the saved copy from step 5. - -5. ACE prefix - - The ACE prefix, used in the conversion operations (section 4), is two - alphanumeric ASCII characters followed by two hyphen-minuses. It - cannot be any of the prefixes already used in earlier documents, - which includes the following: "bl--", "bq--", "dq--", "lq--", "mq--", - "ra--", "wq--" and "zq--". The ToASCII and ToUnicode operations MUST - recognize the ACE prefix in a case-insensitive manner. - - The ACE prefix for IDNA is "xn--" or any capitalization thereof. - - This means that an ACE label might be "xn--de-jg4avhby1noc0d", where - "de-jg4avhby1noc0d" is the part of the ACE label that is generated by - the encoding steps in [PUNYCODE]. - - While all ACE labels begin with the ACE prefix, not all labels - beginning with the ACE prefix are necessarily ACE labels. Non-ACE - labels that begin with the ACE prefix will confuse users and SHOULD - NOT be allowed in DNS zones. - - - - - - - - - - - -Faltstrom, et al. Standards Track [Page 12] - -RFC 3490 IDNA March 2003 - - -6. Implications for typical applications using DNS - - In IDNA, applications perform the processing needed to input - internationalized domain names from users, display internationalized - domain names to users, and process the inputs and outputs from DNS - and other protocols that carry domain names. - - The components and interfaces between them can be represented - pictorially as: - - +------+ - | User | - +------+ - ^ - | Input and display: local interface methods - | (pen, keyboard, glowing phosphorus, ...) - +-------------------|-------------------------------+ - | v | - | +-----------------------------+ | - | | Application | | - | | (ToASCII and ToUnicode | | - | | operations may be | | - | | called here) | | - | +-----------------------------+ | - | ^ ^ | End system - | | | | - | Call to resolver: | | Application-specific | - | ACE | | protocol: | - | v | ACE unless the | - | +----------+ | protocol is updated | - | | Resolver | | to handle other | - | +----------+ | encodings | - | ^ | | - +-----------------|----------|----------------------+ - DNS protocol: | | - ACE | | - v v - +-------------+ +---------------------+ - | DNS servers | | Application servers | - +-------------+ +---------------------+ - - The box labeled "Application" is where the application splits a - domain name into labels, sets the appropriate flags, and performs the - ToASCII and ToUnicode operations. This is described in section 4. - - - - - - - -Faltstrom, et al. Standards Track [Page 13] - -RFC 3490 IDNA March 2003 - - -6.1 Entry and display in applications - - Applications can accept domain names using any character set or sets - desired by the application developer, and can display domain names in - any charset. That is, the IDNA protocol does not affect the - interface between users and applications. - - An IDNA-aware application can accept and display internationalized - domain names in two formats: the internationalized character set(s) - supported by the application, and as an ACE label. ACE labels that - are displayed or input MUST always include the ACE prefix. - Applications MAY allow input and display of ACE labels, but are not - encouraged to do so except as an interface for special purposes, - possibly for debugging, or to cope with display limitations as - described in section 6.4.. ACE encoding is opaque and ugly, and - should thus only be exposed to users who absolutely need it. Because - name labels encoded as ACE name labels can be rendered either as the - encoded ASCII characters or the proper decoded characters, the - application MAY have an option for the user to select the preferred - method of display; if it does, rendering the ACE SHOULD NOT be the - default. - - Domain names are often stored and transported in many places. For - example, they are part of documents such as mail messages and web - pages. They are transported in many parts of many protocols, such as - both the control commands and the RFC 2822 body parts of SMTP, and - the headers and the body content in HTTP. It is important to - remember that domain names appear both in domain name slots and in - the content that is passed over protocols. - - In protocols and document formats that define how to handle - specification or negotiation of charsets, labels can be encoded in - any charset allowed by the protocol or document format. If a - protocol or document format only allows one charset, the labels MUST - be given in that charset. - - In any place where a protocol or document format allows transmission - of the characters in internationalized labels, internationalized - labels SHOULD be transmitted using whatever character encoding and - escape mechanism that the protocol or document format uses at that - place. - - All protocols that use domain name slots already have the capacity - for handling domain names in the ASCII charset. Thus, ACE labels - (internationalized labels that have been processed with the ToASCII - operation) can inherently be handled by those protocols. - - - - - -Faltstrom, et al. Standards Track [Page 14] - -RFC 3490 IDNA March 2003 - - -6.2 Applications and resolver libraries - - Applications normally use functions in the operating system when they - resolve DNS queries. Those functions in the operating system are - often called "the resolver library", and the applications communicate - with the resolver libraries through a programming interface (API). - - Because these resolver libraries today expect only domain names in - ASCII, applications MUST prepare labels that are passed to the - resolver library using the ToASCII operation. Labels received from - the resolver library contain only ASCII characters; internationalized - labels that cannot be represented directly in ASCII use the ACE form. - ACE labels always include the ACE prefix. - - An operating system might have a set of libraries for performing the - ToASCII operation. The input to such a library might be in one or - more charsets that are used in applications (UTF-8 and UTF-16 are - likely candidates for almost any operating system, and script- - specific charsets are likely for localized operating systems). - - IDNA-aware applications MUST be able to work with both non- - internationalized labels (those that conform to [STD13] and [STD3]) - and internationalized labels. - - It is expected that new versions of the resolver libraries in the - future will be able to accept domain names in other charsets than - ASCII, and application developers might one day pass not only domain - names in Unicode, but also in local script to a new API for the - resolver libraries in the operating system. Thus the ToASCII and - ToUnicode operations might be performed inside these new versions of - the resolver libraries. - - Domain names passed to resolvers or put into the question section of - DNS requests follow the rules for "queries" from [STRINGPREP]. - -6.3 DNS servers - - Domain names stored in zones follow the rules for "stored strings" - from [STRINGPREP]. - - For internationalized labels that cannot be represented directly in - ASCII, DNS servers MUST use the ACE form produced by the ToASCII - operation. All IDNs served by DNS servers MUST contain only ASCII - characters. - - If a signaling system which makes negotiation possible between old - and new DNS clients and servers is standardized in the future, the - encoding of the query in the DNS protocol itself can be changed from - - - -Faltstrom, et al. Standards Track [Page 15] - -RFC 3490 IDNA March 2003 - - - ACE to something else, such as UTF-8. The question whether or not - this should be used is, however, a separate problem and is not - discussed in this memo. - -6.4 Avoiding exposing users to the raw ACE encoding - - Any application that might show the user a domain name obtained from - a domain name slot, such as from gethostbyaddr or part of a mail - header, will need to be updated if it is to prevent users from seeing - the ACE. - - If an application decodes an ACE name using ToUnicode but cannot show - all of the characters in the decoded name, such as if the name - contains characters that the output system cannot display, the - application SHOULD show the name in ACE format (which always includes - the ACE prefix) instead of displaying the name with the replacement - character (U+FFFD). This is to make it easier for the user to - transfer the name correctly to other programs. Programs that by - default show the ACE form when they cannot show all the characters in - a name label SHOULD also have a mechanism to show the name that is - produced by the ToUnicode operation with as many characters as - possible and replacement characters in the positions where characters - cannot be displayed. - - The ToUnicode operation does not alter labels that are not valid ACE - labels, even if they begin with the ACE prefix. After ToUnicode has - been applied, if a label still begins with the ACE prefix, then it is - not a valid ACE label, and is not equivalent to any of the - intermediate Unicode strings constructed by ToUnicode. - -6.5 DNSSEC authentication of IDN domain names - - DNS Security [RFC2535] is a method for supplying cryptographic - verification information along with DNS messages. Public Key - Cryptography is used in conjunction with digital signatures to - provide a means for a requester of domain information to authenticate - the source of the data. This ensures that it can be traced back to a - trusted source, either directly, or via a chain of trust linking the - source of the information to the top of the DNS hierarchy. - - IDNA specifies that all internationalized domain names served by DNS - servers that cannot be represented directly in ASCII must use the ACE - form produced by the ToASCII operation. This operation must be - performed prior to a zone being signed by the private key for that - zone. Because of this ordering, it is important to recognize that - DNSSEC authenticates the ASCII domain name, not the Unicode form or - - - - - -Faltstrom, et al. Standards Track [Page 16] - -RFC 3490 IDNA March 2003 - - - the mapping between the Unicode form and the ASCII form. In the - presence of DNSSEC, this is the name that MUST be signed in the zone - and MUST be validated against. - - One consequence of this for sites deploying IDNA in the presence of - DNSSEC is that any special purpose proxies or forwarders used to - transform user input into IDNs must be earlier in the resolution flow - than DNSSEC authenticating nameservers for DNSSEC to work. - -7. Name server considerations - - Existing DNS servers do not know the IDNA rules for handling non- - ASCII forms of IDNs, and therefore need to be shielded from them. - All existing channels through which names can enter a DNS server - database (for example, master files [STD13] and DNS update messages - [RFC2136]) are IDN-unaware because they predate IDNA, and therefore - requirement 2 of section 3.1 of this document provides the needed - shielding, by ensuring that internationalized domain names entering - DNS server databases through such channels have already been - converted to their equivalent ASCII forms. - - It is imperative that there be only one ASCII encoding for a - particular domain name. Because of the design of the ToASCII and - ToUnicode operations, there are no ACE labels that decode to ASCII - labels, and therefore name servers cannot contain multiple ASCII - encodings of the same domain name. - - [RFC2181] explicitly allows domain labels to contain octets beyond - the ASCII range (0..7F), and this document does not change that. - Note, however, that there is no defined interpretation of octets - 80..FF as characters. If labels containing these octets are returned - to applications, unpredictable behavior could result. The ASCII form - defined by ToASCII is the only standard representation for - internationalized labels in the current DNS protocol. - -8. Root server considerations - - IDNs are likely to be somewhat longer than current domain names, so - the bandwidth needed by the root servers is likely to go up by a - small amount. Also, queries and responses for IDNs will probably be - somewhat longer than typical queries today, so more queries and - responses may be forced to go to TCP instead of UDP. - - - - - - - - - -Faltstrom, et al. Standards Track [Page 17] - -RFC 3490 IDNA March 2003 - - -9. References - -9.1 Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of - Internationalized Strings ("stringprep")", RFC 3454, - December 2002. - - [NAMEPREP] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep - Profile for Internationalized Domain Names (IDN)", RFC - 3491, March 2003. - - [PUNYCODE] Costello, A., "Punycode: A Bootstring encoding of - Unicode for use with Internationalized Domain Names in - Applications (IDNA)", RFC 3492, March 2003. - - [STD3] Braden, R., "Requirements for Internet Hosts -- - Communication Layers", STD 3, RFC 1122, and - "Requirements for Internet Hosts -- Application and - Support", STD 3, RFC 1123, October 1989. - - [STD13] Mockapetris, P., "Domain names - concepts and - facilities", STD 13, RFC 1034 and "Domain names - - implementation and specification", STD 13, RFC 1035, - November 1987. - -9.2 Informative References - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [UAX9] Unicode Standard Annex #9, The Bidirectional Algorithm, - <http://www.unicode.org/unicode/reports/tr9/>. - - [UNICODE] The Unicode Consortium. The Unicode Standard, Version - 3.2.0 is defined by The Unicode Standard, Version 3.0 - (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), - as amended by the Unicode Standard Annex #27: Unicode - 3.1 (http://www.unicode.org/reports/tr27/) and by the - Unicode Standard Annex #28: Unicode 3.2 - (http://www.unicode.org/reports/tr28/). - - - - -Faltstrom, et al. Standards Track [Page 18] - -RFC 3490 IDNA March 2003 - - - [USASCII] Cerf, V., "ASCII format for Network Interchange", RFC - 20, October 1969. - -10. Security Considerations - - Security on the Internet partly relies on the DNS. Thus, any change - to the characteristics of the DNS can change the security of much of - the Internet. - - This memo describes an algorithm which encodes characters that are - not valid according to STD3 and STD13 into octet values that are - valid. No security issues such as string length increases or new - allowed values are introduced by the encoding process or the use of - these encoded values, apart from those introduced by the ACE encoding - itself. - - Domain names are used by users to identify and connect to Internet - servers. The security of the Internet is compromised if a user - entering a single internationalized name is connected to different - servers based on different interpretations of the internationalized - domain name. - - When systems use local character sets other than ASCII and Unicode, - this specification leaves the the problem of transcoding between the - local character set and Unicode up to the application. If different - applications (or different versions of one application) implement - different transcoding rules, they could interpret the same name - differently and contact different servers. This problem is not - solved by security protocols like TLS that do not take local - character sets into account. - - Because this document normatively refers to [NAMEPREP], [PUNYCODE], - and [STRINGPREP], it includes the security considerations from those - documents as well. - - If or when this specification is updated to use a more recent Unicode - normalization table, the new normalization table will need to be - compared with the old to spot backwards incompatible changes. If - there are such changes, they will need to be handled somehow, or - there will be security as well as operational implications. Methods - to handle the conflicts could include keeping the old normalization, - or taking care of the conflicting characters by operational means, or - some other method. - - Implementations MUST NOT use more recent normalization tables than - the one referenced from this document, even though more recent tables - may be provided by operating systems. If an application is unsure of - which version of the normalization tables are in the operating - - - -Faltstrom, et al. Standards Track [Page 19] - -RFC 3490 IDNA March 2003 - - - system, the application needs to include the normalization tables - itself. Using normalization tables other than the one referenced - from this specification could have security and operational - implications. - - To help prevent confusion between characters that are visually - similar, it is suggested that implementations provide visual - indications where a domain name contains multiple scripts. Such - mechanisms can also be used to show when a name contains a mixture of - simplified and traditional Chinese characters, or to distinguish zero - and one from O and l. DNS zone adminstrators may impose restrictions - (subject to the limitations in section 2) that try to minimize - homographs. - - Domain names (or portions of them) are sometimes compared against a - set of privileged or anti-privileged domains. In such situations it - is especially important that the comparisons be done properly, as - specified in section 3.1 requirement 4. For labels already in ASCII - form, the proper comparison reduces to the same case-insensitive - ASCII comparison that has always been used for ASCII labels. - - The introduction of IDNA means that any existing labels that start - with the ACE prefix and would be altered by ToUnicode will - automatically be ACE labels, and will be considered equivalent to - non-ASCII labels, whether or not that was the intent of the zone - adminstrator or registrant. - -11. IANA Considerations - - IANA has assigned the ACE prefix in consultation with the IESG. - - - - - - - - - - - - - - - - - - - - - -Faltstrom, et al. Standards Track [Page 20] - -RFC 3490 IDNA March 2003 - - -12. Authors' Addresses - - Patrik Faltstrom - Cisco Systems - Arstaangsvagen 31 J - S-117 43 Stockholm Sweden - - EMail: paf@cisco.com - - - Paul Hoffman - Internet Mail Consortium and VPN Consortium - 127 Segre Place - Santa Cruz, CA 95060 USA - - EMail: phoffman@imc.org - - - Adam M. Costello - University of California, Berkeley - - URL: http://www.nicemice.net/amc/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Faltstrom, et al. Standards Track [Page 21] - -RFC 3490 IDNA March 2003 - - -13. Full Copyright Statement - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Faltstrom, et al. Standards Track [Page 22] - diff --git a/source4/heimdal/lib/wind/rfc3491.txt b/source4/heimdal/lib/wind/rfc3491.txt deleted file mode 100644 index dbc86c7fe4..0000000000 --- a/source4/heimdal/lib/wind/rfc3491.txt +++ /dev/null @@ -1,395 +0,0 @@ - - - - - - -Network Working Group P. Hoffman -Request for Comments: 3491 IMC & VPNC -Category: Standards Track M. Blanchet - Viagenie - March 2003 - - - Nameprep: A Stringprep Profile for - Internationalized Domain Names (IDN) - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - This document describes how to prepare internationalized domain name - (IDN) labels in order to increase the likelihood that name input and - name comparison work in ways that make sense for typical users - throughout the world. This profile of the stringprep protocol is - used as part of a suite of on-the-wire protocols for - internationalizing the Domain Name System (DNS). - -1. Introduction - - This document specifies processing rules that will allow users to - enter internationalized domain names (IDNs) into applications and - have the highest chance of getting the content of the strings - correct. It is a profile of stringprep [STRINGPREP]. These - processing rules are only intended for internationalized domain - names, not for arbitrary text. - - This profile defines the following, as required by [STRINGPREP]. - - - The intended applicability of the profile: internationalized - domain names processed by IDNA. - - - The character repertoire that is the input and output to - stringprep: Unicode 3.2, specified in section 2. - - - - -Hoffman & Blanchet Standards Track [Page 1] - -RFC 3491 IDN Nameprep March 2003 - - - - The mappings used: specified in section 3. - - - The Unicode normalization used: specified in section 4. - - - The characters that are prohibited as output: specified in section - 5. - - - Bidirectional character handling: specified in section 6. - -1.1 Interaction of protocol parts - - Nameprep is used by the IDNA [IDNA] protocol for preparing domain - names; it is not designed for any other purpose. It is explicitly - not designed for processing arbitrary free text and SHOULD NOT be - used for that purpose. Nameprep is a profile of Stringprep - [STRINGPREP]. Implementations of Nameprep MUST fully implement - Stringprep. - - Nameprep is used to process domain name labels, not domain names. - IDNA calls nameprep for each label in a domain name, not for the - whole domain name. - -1.2 Terminology - - The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" - in this document are to be interpreted as described in BCP 14, RFC - 2119 [RFC2119]. - -2. Character Repertoire - - This profile uses Unicode 3.2, as defined in [STRINGPREP] Appendix A. - -3. Mapping - - This profile specifies mapping using the following tables from - [STRINGPREP]: - - Table B.1 - Table B.2 - -4. Normalization - - This profile specifies using Unicode normalization form KC, as - described in [STRINGPREP]. - - - - - - - -Hoffman & Blanchet Standards Track [Page 2] - -RFC 3491 IDN Nameprep March 2003 - - -5. Prohibited Output - - This profile specifies prohibiting using the following tables from - [STRINGPREP]: - - Table C.1.2 - Table C.2.2 - Table C.3 - Table C.4 - Table C.5 - Table C.6 - Table C.7 - Table C.8 - Table C.9 - - IMPORTANT NOTE: This profile MUST be used with the IDNA protocol. - The IDNA protocol has additional prohibitions that are checked - outside of this profile. - -6. Bidirectional characters - - This profile specifies checking bidirectional strings as described in - [STRINGPREP] section 6. - -7. Unassigned Code Points in Internationalized Domain Names - - If the processing in [IDNA] specifies that a list of unassigned code - points be used, the system uses table A.1 from [STRINGPREP] as its - list of unassigned code points. - -8. References - -8.1 Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of - Internationalized Strings ("stringprep")", RFC 3454, - December 2002. - - [IDNA] Faltstrom, P., Hoffman, P. and A. Costello, - "Internationalizing Domain Names in Applications - (IDNA)", RFC 3490, March 2003. - - - - - - - -Hoffman & Blanchet Standards Track [Page 3] - -RFC 3491 IDN Nameprep March 2003 - - -8.2 Informative references - - [STD13] Mockapetris, P., "Domain names - concepts and - facilities", STD 13, RFC 1034, and "Domain names - - implementation and specification", STD 13, RFC 1035, - November 1987. - -9. Security Considerations - - The Unicode and ISO/IEC 10646 repertoires have many characters that - look similar. In many cases, users of security protocols might do - visual matching, such as when comparing the names of trusted third - parties. Because it is impossible to map similar-looking characters - without a great deal of context such as knowing the fonts used, - stringprep does nothing to map similar-looking characters together - nor to prohibit some characters because they look like others. - - Security on the Internet partly relies on the DNS. Thus, any change - to the characteristics of the DNS can change the security of much of - the Internet. - - Domain names are used by users to connect to Internet servers. The - security of the Internet would be compromised if a user entering a - single internationalized name could be connected to different servers - based on different interpretations of the internationalized domain - name. - - Current applications might assume that the characters allowed in - domain names will always be the same as they are in [STD13]. This - document vastly increases the number of characters available in - domain names. Every program that uses "special" characters in - conjunction with domain names may be vulnerable to attack based on - the new characters allowed by this specification. - - - - - - - - - - - - - - - - - - -Hoffman & Blanchet Standards Track [Page 4] - -RFC 3491 IDN Nameprep March 2003 - - -10. IANA Considerations - - This is a profile of stringprep. It has been registered by the IANA - in the stringprep profile registry - (www.iana.org/assignments/stringprep-profiles). - - Name of this profile: - Nameprep - - RFC in which the profile is defined: - This document. - - Indicator whether or not this is the newest version of the - profile: - This is the first version of Nameprep. - -11. Acknowledgements - - Many people from the IETF IDN Working Group and the Unicode Technical - Committee contributed ideas that went into this document. - - The IDN Nameprep design team made many useful changes to the - document. That team and its advisors include: - - Asmus Freytag - Cathy Wissink - Francois Yergeau - James Seng - Marc Blanchet - Mark Davis - Martin Duerst - Patrik Faltstrom - Paul Hoffman - - Additional significant improvements were proposed by: - - Jonathan Rosenne - Kent Karlsson - Scott Hollenbeck - Dave Crocker - Erik Nordmark - Matitiahu Allouche - - - - - - - - - -Hoffman & Blanchet Standards Track [Page 5] - -RFC 3491 IDN Nameprep March 2003 - - -12. Authors' Addresses - - Paul Hoffman - Internet Mail Consortium and VPN Consortium - 127 Segre Place - Santa Cruz, CA 95060 USA - - EMail: paul.hoffman@imc.org and paul.hoffman@vpnc.org - - - Marc Blanchet - Viagenie inc. - 2875 boul. Laurier, bur. 300 - Ste-Foy, Quebec, Canada, G1V 2M2 - - EMail: Marc.Blanchet@viagenie.qc.ca - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hoffman & Blanchet Standards Track [Page 6] - -RFC 3491 IDN Nameprep March 2003 - - -13. Full Copyright Statement - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Hoffman & Blanchet Standards Track [Page 7] - diff --git a/source4/heimdal/lib/wind/rfc3492.txt b/source4/heimdal/lib/wind/rfc3492.txt deleted file mode 100644 index e72ad81a27..0000000000 --- a/source4/heimdal/lib/wind/rfc3492.txt +++ /dev/null @@ -1,1963 +0,0 @@ - - - - - - -Network Working Group A. Costello -Request for Comments: 3492 Univ. of California, Berkeley -Category: Standards Track March 2003 - - - Punycode: A Bootstring encoding of Unicode - for Internationalized Domain Names in Applications (IDNA) - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - Punycode is a simple and efficient transfer encoding syntax designed - for use with Internationalized Domain Names in Applications (IDNA). - It uniquely and reversibly transforms a Unicode string into an ASCII - string. ASCII characters in the Unicode string are represented - literally, and non-ASCII characters are represented by ASCII - characters that are allowed in host name labels (letters, digits, and - hyphens). This document defines a general algorithm called - Bootstring that allows a string of basic code points to uniquely - represent any string of code points drawn from a larger set. - Punycode is an instance of Bootstring that uses particular parameter - values specified by this document, appropriate for IDNA. - -Table of Contents - - 1. Introduction...............................................2 - 1.1 Features..............................................2 - 1.2 Interaction of protocol parts.........................3 - 2. Terminology................................................3 - 3. Bootstring description.....................................4 - 3.1 Basic code point segregation..........................4 - 3.2 Insertion unsort coding...............................4 - 3.3 Generalized variable-length integers..................5 - 3.4 Bias adaptation.......................................7 - 4. Bootstring parameters......................................8 - 5. Parameter values for Punycode..............................8 - 6. Bootstring algorithms......................................9 - - - -Costello Standards Track [Page 1] - -RFC 3492 IDNA Punycode March 2003 - - - 6.1 Bias adaptation function.............................10 - 6.2 Decoding procedure...................................11 - 6.3 Encoding procedure...................................12 - 6.4 Overflow handling....................................13 - 7. Punycode examples.........................................14 - 7.1 Sample strings.......................................14 - 7.2 Decoding traces......................................17 - 7.3 Encoding traces......................................19 - 8. Security Considerations...................................20 - 9. References................................................21 - 9.1 Normative References.................................21 - 9.2 Informative References...............................21 - A. Mixed-case annotation.....................................22 - B. Disclaimer and license....................................22 - C. Punycode sample implementation............................23 - Author's Address.............................................34 - Full Copyright Statement.....................................35 - -1. Introduction - - [IDNA] describes an architecture for supporting internationalized - domain names. Labels containing non-ASCII characters can be - represented by ACE labels, which begin with a special ACE prefix and - contain only ASCII characters. The remainder of the label after the - prefix is a Punycode encoding of a Unicode string satisfying certain - constraints. For the details of the prefix and constraints, see - [IDNA] and [NAMEPREP]. - - Punycode is an instance of a more general algorithm called - Bootstring, which allows strings composed from a small set of "basic" - code points to uniquely represent any string of code points drawn - from a larger set. Punycode is Bootstring with particular parameter - values appropriate for IDNA. - -1.1 Features - - Bootstring has been designed to have the following features: - - * Completeness: Every extended string (sequence of arbitrary code - points) can be represented by a basic string (sequence of basic - code points). Restrictions on what strings are allowed, and on - length, can be imposed by higher layers. - - * Uniqueness: There is at most one basic string that represents a - given extended string. - - * Reversibility: Any extended string mapped to a basic string can - be recovered from that basic string. - - - -Costello Standards Track [Page 2] - -RFC 3492 IDNA Punycode March 2003 - - - * Efficient encoding: The ratio of basic string length to extended - string length is small. This is important in the context of - domain names because RFC 1034 [RFC1034] restricts the length of a - domain label to 63 characters. - - * Simplicity: The encoding and decoding algorithms are reasonably - simple to implement. The goals of efficiency and simplicity are - at odds; Bootstring aims at a good balance between them. - - * Readability: Basic code points appearing in the extended string - are represented as themselves in the basic string (although the - main purpose is to improve efficiency, not readability). - - Punycode can also support an additional feature that is not used by - the ToASCII and ToUnicode operations of [IDNA]. When extended - strings are case-folded prior to encoding, the basic string can use - mixed case to tell how to convert the folded string into a mixed-case - string. See appendix A "Mixed-case annotation". - -1.2 Interaction of protocol parts - - Punycode is used by the IDNA protocol [IDNA] for converting domain - labels into ASCII; it is not designed for any other purpose. It is - explicitly not designed for processing arbitrary free text. - -2. Terminology - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in BCP 14, RFC 2119 - [RFC2119]. - - A code point is an integral value associated with a character in a - coded character set. - - As in the Unicode Standard [UNICODE], Unicode code points are denoted - by "U+" followed by four to six hexadecimal digits, while a range of - code points is denoted by two hexadecimal numbers separated by "..", - with no prefixes. - - The operators div and mod perform integer division; (x div y) is the - quotient of x divided by y, discarding the remainder, and (x mod y) - is the remainder, so (x div y) * y + (x mod y) == x. Bootstring uses - these operators only with nonnegative operands, so the quotient and - remainder are always nonnegative. - - The break statement jumps out of the innermost loop (as in C). - - - - -Costello Standards Track [Page 3] - -RFC 3492 IDNA Punycode March 2003 - - - An overflow is an attempt to compute a value that exceeds the maximum - value of an integer variable. - -3. Bootstring description - - Bootstring represents an arbitrary sequence of code points (the - "extended string") as a sequence of basic code points (the "basic - string"). This section describes the representation. Section 6 - "Bootstring algorithms" presents the algorithms as pseudocode. - Sections 7.1 "Decoding traces" and 7.2 "Encoding traces" trace the - algorithms for sample inputs. - - The following sections describe the four techniques used in - Bootstring. "Basic code point segregation" is a very simple and - efficient encoding for basic code points occurring in the extended - string: they are simply copied all at once. "Insertion unsort - coding" encodes the non-basic code points as deltas, and processes - the code points in numerical order rather than in order of - appearance, which typically results in smaller deltas. The deltas - are represented as "generalized variable-length integers", which use - basic code points to represent nonnegative integers. The parameters - of this integer representation are dynamically adjusted using "bias - adaptation", to improve efficiency when consecutive deltas have - similar magnitudes. - -3.1 Basic code point segregation - - All basic code points appearing in the extended string are - represented literally at the beginning of the basic string, in their - original order, followed by a delimiter if (and only if) the number - of basic code points is nonzero. The delimiter is a particular basic - code point, which never appears in the remainder of the basic string. - The decoder can therefore find the end of the literal portion (if - there is one) by scanning for the last delimiter. - -3.2 Insertion unsort coding - - The remainder of the basic string (after the last delimiter if there - is one) represents a sequence of nonnegative integral deltas as - generalized variable-length integers, described in section 3.3. The - meaning of the deltas is best understood in terms of the decoder. - - The decoder builds the extended string incrementally. Initially, the - extended string is a copy of the literal portion of the basic string - (excluding the last delimiter). The decoder inserts non-basic code - points, one for each delta, into the extended string, ultimately - arriving at the final decoded string. - - - - -Costello Standards Track [Page 4] - -RFC 3492 IDNA Punycode March 2003 - - - At the heart of this process is a state machine with two state - variables: an index i and a counter n. The index i refers to a - position in the extended string; it ranges from 0 (the first - position) to the current length of the extended string (which refers - to a potential position beyond the current end). If the current - state is <n,i>, the next state is <n,i+1> if i is less than the - length of the extended string, or <n+1,0> if i equals the length of - the extended string. In other words, each state change causes i to - increment, wrapping around to zero if necessary, and n counts the - number of wrap-arounds. - - Notice that the state always advances monotonically (there is no way - for the decoder to return to an earlier state). At each state, an - insertion is either performed or not performed. At most one - insertion is performed in a given state. An insertion inserts the - value of n at position i in the extended string. The deltas are a - run-length encoding of this sequence of events: they are the lengths - of the runs of non-insertion states preceeding the insertion states. - Hence, for each delta, the decoder performs delta state changes, then - an insertion, and then one more state change. (An implementation - need not perform each state change individually, but can instead use - division and remainder calculations to compute the next insertion - state directly.) It is an error if the inserted code point is a - basic code point (because basic code points were supposed to be - segregated as described in section 3.1). - - The encoder's main task is to derive the sequence of deltas that will - cause the decoder to construct the desired string. It can do this by - repeatedly scanning the extended string for the next code point that - the decoder would need to insert, and counting the number of state - changes the decoder would need to perform, mindful of the fact that - the decoder's extended string will include only those code points - that have already been inserted. Section 6.3 "Encoding procedure" - gives a precise algorithm. - -3.3 Generalized variable-length integers - - In a conventional integer representation the base is the number of - distinct symbols for digits, whose values are 0 through base-1. Let - digit_0 denote the least significant digit, digit_1 the next least - significant, and so on. The value represented is the sum over j of - digit_j * w(j), where w(j) = base^j is the weight (scale factor) for - position j. For example, in the base 8 integer 437, the digits are - 7, 3, and 4, and the weights are 1, 8, and 64, so the value is 7 + - 3*8 + 4*64 = 287. This representation has two disadvantages: First, - there are multiple encodings of each value (because there can be - extra zeros in the most significant positions), which is inconvenient - - - - -Costello Standards Track [Page 5] - -RFC 3492 IDNA Punycode March 2003 - - - when unique encodings are needed. Second, the integer is not self- - delimiting, so if multiple integers are concatenated the boundaries - between them are lost. - - The generalized variable-length representation solves these two - problems. The digit values are still 0 through base-1, but now the - integer is self-delimiting by means of thresholds t(j), each of which - is in the range 0 through base-1. Exactly one digit, the most - significant, satisfies digit_j < t(j). Therefore, if several - integers are concatenated, it is easy to separate them, starting with - the first if they are little-endian (least significant digit first), - or starting with the last if they are big-endian (most significant - digit first). As before, the value is the sum over j of digit_j * - w(j), but the weights are different: - - w(0) = 1 - w(j) = w(j-1) * (base - t(j-1)) for j > 0 - - For example, consider the little-endian sequence of base 8 digits - 734251... Suppose the thresholds are 2, 3, 5, 5, 5, 5... This - implies that the weights are 1, 1*(8-2) = 6, 6*(8-3) = 30, 30*(8-5) = - 90, 90*(8-5) = 270, and so on. 7 is not less than 2, and 3 is not - less than 3, but 4 is less than 5, so 4 is the last digit. The value - of 734 is 7*1 + 3*6 + 4*30 = 145. The next integer is 251, with - value 2*1 + 5*6 + 1*30 = 62. Decoding this representation is very - similar to decoding a conventional integer: Start with a current - value of N = 0 and a weight w = 1. Fetch the next digit d and - increase N by d * w. If d is less than the current threshold (t) - then stop, otherwise increase w by a factor of (base - t), update t - for the next position, and repeat. - - Encoding this representation is similar to encoding a conventional - integer: If N < t then output one digit for N and stop, otherwise - output the digit for t + ((N - t) mod (base - t)), then replace N - with (N - t) div (base - t), update t for the next position, and - repeat. - - For any particular set of values of t(j), there is exactly one - generalized variable-length representation of each nonnegative - integral value. - - Bootstring uses little-endian ordering so that the deltas can be - separated starting with the first. The t(j) values are defined in - terms of the constants base, tmin, and tmax, and a state variable - called bias: - - t(j) = base * (j + 1) - bias, - clamped to the range tmin through tmax - - - -Costello Standards Track [Page 6] - -RFC 3492 IDNA Punycode March 2003 - - - The clamping means that if the formula yields a value less than tmin - or greater than tmax, then t(j) = tmin or tmax, respectively. (In - the pseudocode in section 6 "Bootstring algorithms", the expression - base * (j + 1) is denoted by k for performance reasons.) These t(j) - values cause the representation to favor integers within a particular - range determined by the bias. - -3.4 Bias adaptation - - After each delta is encoded or decoded, bias is set for the next - delta as follows: - - 1. Delta is scaled in order to avoid overflow in the next step: - - let delta = delta div 2 - - But when this is the very first delta, the divisor is not 2, but - instead a constant called damp. This compensates for the fact - that the second delta is usually much smaller than the first. - - 2. Delta is increased to compensate for the fact that the next delta - will be inserting into a longer string: - - let delta = delta + (delta div numpoints) - - numpoints is the total number of code points encoded/decoded so - far (including the one corresponding to this delta itself, and - including the basic code points). - - 3. Delta is repeatedly divided until it falls within a threshold, to - predict the minimum number of digits needed to represent the next - delta: - - while delta > ((base - tmin) * tmax) div 2 - do let delta = delta div (base - tmin) - - 4. The bias is set: - - let bias = - (base * the number of divisions performed in step 3) + - (((base - tmin + 1) * delta) div (delta + skew)) - - The motivation for this procedure is that the current delta - provides a hint about the likely size of the next delta, and so - t(j) is set to tmax for the more significant digits starting with - the one expected to be last, tmin for the less significant digits - up through the one expected to be third-last, and somewhere - between tmin and tmax for the digit expected to be second-last - - - -Costello Standards Track [Page 7] - -RFC 3492 IDNA Punycode March 2003 - - - (balancing the hope of the expected-last digit being unnecessary - against the danger of it being insufficient). - -4. Bootstring parameters - - Given a set of basic code points, one needs to be designated as the - delimiter. The base cannot be greater than the number of - distinguishable basic code points remaining. The digit-values in the - range 0 through base-1 need to be associated with distinct non- - delimiter basic code points. In some cases multiple code points need - to have the same digit-value; for example, uppercase and lowercase - versions of the same letter need to be equivalent if basic strings - are case-insensitive. - - The initial value of n cannot be greater than the minimum non-basic - code point that could appear in extended strings. - - The remaining five parameters (tmin, tmax, skew, damp, and the - initial value of bias) need to satisfy the following constraints: - - 0 <= tmin <= tmax <= base-1 - skew >= 1 - damp >= 2 - initial_bias mod base <= base - tmin - - Provided the constraints are satisfied, these five parameters affect - efficiency but not correctness. They are best chosen empirically. - - If support for mixed-case annotation is desired (see appendix A), - make sure that the code points corresponding to 0 through tmax-1 all - have both uppercase and lowercase forms. - -5. Parameter values for Punycode - - Punycode uses the following Bootstring parameter values: - - base = 36 - tmin = 1 - tmax = 26 - skew = 38 - damp = 700 - initial_bias = 72 - initial_n = 128 = 0x80 - - Although the only restriction Punycode imposes on the input integers - is that they be nonnegative, these parameters are especially designed - to work well with Unicode [UNICODE] code points, which are integers - in the range 0..10FFFF (but not D800..DFFF, which are reserved for - - - -Costello Standards Track [Page 8] - -RFC 3492 IDNA Punycode March 2003 - - - use by the UTF-16 encoding of Unicode). The basic code points are - the ASCII [ASCII] code points (0..7F), of which U+002D (-) is the - delimiter, and some of the others have digit-values as follows: - - code points digit-values - ------------ ---------------------- - 41..5A (A-Z) = 0 to 25, respectively - 61..7A (a-z) = 0 to 25, respectively - 30..39 (0-9) = 26 to 35, respectively - - Using hyphen-minus as the delimiter implies that the encoded string - can end with a hyphen-minus only if the Unicode string consists - entirely of basic code points, but IDNA forbids such strings from - being encoded. The encoded string can begin with a hyphen-minus, but - IDNA prepends a prefix. Therefore IDNA using Punycode conforms to - the RFC 952 rule that host name labels neither begin nor end with a - hyphen-minus [RFC952]. - - A decoder MUST recognize the letters in both uppercase and lowercase - forms (including mixtures of both forms). An encoder SHOULD output - only uppercase forms or only lowercase forms, unless it uses mixed- - case annotation (see appendix A). - - Presumably most users will not manually write or type encoded strings - (as opposed to cutting and pasting them), but those who do will need - to be alert to the potential visual ambiguity between the following - sets of characters: - - G 6 - I l 1 - O 0 - S 5 - U V - Z 2 - - Such ambiguities are usually resolved by context, but in a Punycode - encoded string there is no context apparent to humans. - -6. Bootstring algorithms - - Some parts of the pseudocode can be omitted if the parameters satisfy - certain conditions (for which Punycode qualifies). These parts are - enclosed in {braces}, and notes immediately following the pseudocode - explain the conditions under which they can be omitted. - - - - - - - -Costello Standards Track [Page 9] - -RFC 3492 IDNA Punycode March 2003 - - - Formally, code points are integers, and hence the pseudocode assumes - that arithmetic operations can be performed directly on code points. - In some programming languages, explicit conversion between code - points and integers might be necessary. - -6.1 Bias adaptation function - - function adapt(delta,numpoints,firsttime): - if firsttime then let delta = delta div damp - else let delta = delta div 2 - let delta = delta + (delta div numpoints) - let k = 0 - while delta > ((base - tmin) * tmax) div 2 do begin - let delta = delta div (base - tmin) - let k = k + base - end - return k + (((base - tmin + 1) * delta) div (delta + skew)) - - It does not matter whether the modifications to delta and k inside - adapt() affect variables of the same name inside the - encoding/decoding procedures, because after calling adapt() the - caller does not read those variables before overwriting them. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Costello Standards Track [Page 10] - -RFC 3492 IDNA Punycode March 2003 - - -6.2 Decoding procedure - - let n = initial_n - let i = 0 - let bias = initial_bias - let output = an empty string indexed from 0 - consume all code points before the last delimiter (if there is one) - and copy them to output, fail on any non-basic code point - if more than zero code points were consumed then consume one more - (which will be the last delimiter) - while the input is not exhausted do begin - let oldi = i - let w = 1 - for k = base to infinity in steps of base do begin - consume a code point, or fail if there was none to consume - let digit = the code point's digit-value, fail if it has none - let i = i + digit * w, fail on overflow - let t = tmin if k <= bias {+ tmin}, or - tmax if k >= bias + tmax, or k - bias otherwise - if digit < t then break - let w = w * (base - t), fail on overflow - end - let bias = adapt(i - oldi, length(output) + 1, test oldi is 0?) - let n = n + i div (length(output) + 1), fail on overflow - let i = i mod (length(output) + 1) - {if n is a basic code point then fail} - insert n into output at position i - increment i - end - - The full statement enclosed in braces (checking whether n is a basic - code point) can be omitted if initial_n exceeds all basic code points - (which is true for Punycode), because n is never less than initial_n. - - In the assignment of t, where t is clamped to the range tmin through - tmax, "+ tmin" can always be omitted. This makes the clamping - calculation incorrect when bias < k < bias + tmin, but that cannot - happen because of the way bias is computed and because of the - constraints on the parameters. - - Because the decoder state can only advance monotonically, and there - is only one representation of any delta, there is therefore only one - encoded string that can represent a given sequence of integers. The - only error conditions are invalid code points, unexpected end-of- - input, overflow, and basic code points encoded using deltas instead - of appearing literally. If the decoder fails on these errors as - shown above, then it cannot produce the same output for two distinct - inputs. Without this property it would have been necessary to re- - - - -Costello Standards Track [Page 11] - -RFC 3492 IDNA Punycode March 2003 - - - encode the output and verify that it matches the input in order to - guarantee the uniqueness of the encoding. - -6.3 Encoding procedure - - let n = initial_n - let delta = 0 - let bias = initial_bias - let h = b = the number of basic code points in the input - copy them to the output in order, followed by a delimiter if b > 0 - {if the input contains a non-basic code point < n then fail} - while h < length(input) do begin - let m = the minimum {non-basic} code point >= n in the input - let delta = delta + (m - n) * (h + 1), fail on overflow - let n = m - for each code point c in the input (in order) do begin - if c < n {or c is basic} then increment delta, fail on overflow - if c == n then begin - let q = delta - for k = base to infinity in steps of base do begin - let t = tmin if k <= bias {+ tmin}, or - tmax if k >= bias + tmax, or k - bias otherwise - if q < t then break - output the code point for digit t + ((q - t) mod (base - t)) - let q = (q - t) div (base - t) - end - output the code point for digit q - let bias = adapt(delta, h + 1, test h equals b?) - let delta = 0 - increment h - end - end - increment delta and n - end - - The full statement enclosed in braces (checking whether the input - contains a non-basic code point less than n) can be omitted if all - code points less than initial_n are basic code points (which is true - for Punycode if code points are unsigned). - - The brace-enclosed conditions "non-basic" and "or c is basic" can be - omitted if initial_n exceeds all basic code points (which is true for - Punycode), because the code point being tested is never less than - initial_n. - - In the assignment of t, where t is clamped to the range tmin through - tmax, "+ tmin" can always be omitted. This makes the clamping - calculation incorrect when bias < k < bias + tmin, but that cannot - - - -Costello Standards Track [Page 12] - -RFC 3492 IDNA Punycode March 2003 - - - happen because of the way bias is computed and because of the - constraints on the parameters. - - The checks for overflow are necessary to avoid producing invalid - output when the input contains very large values or is very long. - - The increment of delta at the bottom of the outer loop cannot - overflow because delta < length(input) before the increment, and - length(input) is already assumed to be representable. The increment - of n could overflow, but only if h == length(input), in which case - the procedure is finished anyway. - -6.4 Overflow handling - - For IDNA, 26-bit unsigned integers are sufficient to handle all valid - IDNA labels without overflow, because any string that needed a 27-bit - delta would have to exceed either the code point limit (0..10FFFF) or - the label length limit (63 characters). However, overflow handling - is necessary because the inputs are not necessarily valid IDNA - labels. - - If the programming language does not provide overflow detection, the - following technique can be used. Suppose A, B, and C are - representable nonnegative integers and C is nonzero. Then A + B - overflows if and only if B > maxint - A, and A + (B * C) overflows if - and only if B > (maxint - A) div C, where maxint is the greatest - integer for which maxint + 1 cannot be represented. Refer to - appendix C "Punycode sample implementation" for demonstrations of - this technique in the C language. - - The decoding and encoding algorithms shown in sections 6.2 and 6.3 - handle overflow by detecting it whenever it happens. Another - approach is to enforce limits on the inputs that prevent overflow - from happening. For example, if the encoder were to verify that no - input code points exceed M and that the input length does not exceed - L, then no delta could ever exceed (M - initial_n) * (L + 1), and - hence no overflow could occur if integer variables were capable of - representing values that large. This prevention approach would - impose more restrictions on the input than the detection approach - does, but might be considered simpler in some programming languages. - - In theory, the decoder could use an analogous approach, limiting the - number of digits in a variable-length integer (that is, limiting the - number of iterations in the innermost loop). However, the number of - digits that suffice to represent a given delta can sometimes - represent much larger deltas (because of the adaptation), and hence - this approach would probably need integers wider than 32 bits. - - - - -Costello Standards Track [Page 13] - -RFC 3492 IDNA Punycode March 2003 - - - Yet another approach for the decoder is to allow overflow to occur, - but to check the final output string by re-encoding it and comparing - to the decoder input. If and only if they do not match (using a - case-insensitive ASCII comparison) overflow has occurred. This - delayed-detection approach would not impose any more restrictions on - the input than the immediate-detection approach does, and might be - considered simpler in some programming languages. - - In fact, if the decoder is used only inside the IDNA ToUnicode - operation [IDNA], then it need not check for overflow at all, because - ToUnicode performs a higher level re-encoding and comparison, and a - mismatch has the same consequence as if the Punycode decoder had - failed. - -7. Punycode examples - -7.1 Sample strings - - In the Punycode encodings below, the ACE prefix is not shown. - Backslashes show where line breaks have been inserted in strings too - long for one line. - - The first several examples are all translations of the sentence "Why - can't they just speak in <language>?" (courtesy of Michael Kaplan's - "provincial" page [PROVINCIAL]). Word breaks and punctuation have - been removed, as is often done in domain names. - - (A) Arabic (Egyptian): - u+0644 u+064A u+0647 u+0645 u+0627 u+0628 u+062A u+0643 u+0644 - u+0645 u+0648 u+0634 u+0639 u+0631 u+0628 u+064A u+061F - Punycode: egbpdaj6bu4bxfgehfvwxn - - (B) Chinese (simplified): - u+4ED6 u+4EEC u+4E3A u+4EC0 u+4E48 u+4E0D u+8BF4 u+4E2D u+6587 - Punycode: ihqwcrb4cv8a8dqg056pqjye - - (C) Chinese (traditional): - u+4ED6 u+5011 u+7232 u+4EC0 u+9EBD u+4E0D u+8AAA u+4E2D u+6587 - Punycode: ihqwctvzc91f659drss3x8bo0yb - - (D) Czech: Pro<ccaron>prost<ecaron>nemluv<iacute><ccaron>esky - U+0050 u+0072 u+006F u+010D u+0070 u+0072 u+006F u+0073 u+0074 - u+011B u+006E u+0065 u+006D u+006C u+0075 u+0076 u+00ED u+010D - u+0065 u+0073 u+006B u+0079 - Punycode: Proprostnemluvesky-uyb24dma41a - - - - - - -Costello Standards Track [Page 14] - -RFC 3492 IDNA Punycode March 2003 - - - (E) Hebrew: - u+05DC u+05DE u+05D4 u+05D4 u+05DD u+05E4 u+05E9 u+05D5 u+05D8 - u+05DC u+05D0 u+05DE u+05D3 u+05D1 u+05E8 u+05D9 u+05DD u+05E2 - u+05D1 u+05E8 u+05D9 u+05EA - Punycode: 4dbcagdahymbxekheh6e0a7fei0b - - (F) Hindi (Devanagari): - u+092F u+0939 u+0932 u+094B u+0917 u+0939 u+093F u+0928 u+094D - u+0926 u+0940 u+0915 u+094D u+092F u+094B u+0902 u+0928 u+0939 - u+0940 u+0902 u+092C u+094B u+0932 u+0938 u+0915 u+0924 u+0947 - u+0939 u+0948 u+0902 - Punycode: i1baa7eci9glrd9b2ae1bj0hfcgg6iyaf8o0a1dig0cd - - (G) Japanese (kanji and hiragana): - u+306A u+305C u+307F u+3093 u+306A u+65E5 u+672C u+8A9E u+3092 - u+8A71 u+3057 u+3066 u+304F u+308C u+306A u+3044 u+306E u+304B - Punycode: n8jok5ay5dzabd5bym9f0cm5685rrjetr6pdxa - - (H) Korean (Hangul syllables): - u+C138 u+ACC4 u+C758 u+BAA8 u+B4E0 u+C0AC u+B78C u+B4E4 u+C774 - u+D55C u+AD6D u+C5B4 u+B97C u+C774 u+D574 u+D55C u+B2E4 u+BA74 - u+C5BC u+B9C8 u+B098 u+C88B u+C744 u+AE4C - Punycode: 989aomsvi5e83db1d2a355cv1e0vak1dwrv93d5xbh15a0dt30a5j\ - psd879ccm6fea98c - - (I) Russian (Cyrillic): - U+043F u+043E u+0447 u+0435 u+043C u+0443 u+0436 u+0435 u+043E - u+043D u+0438 u+043D u+0435 u+0433 u+043E u+0432 u+043E u+0440 - u+044F u+0442 u+043F u+043E u+0440 u+0443 u+0441 u+0441 u+043A - u+0438 - Punycode: b1abfaaepdrnnbgefbaDotcwatmq2g4l - - (J) Spanish: Porqu<eacute>nopuedensimplementehablarenEspa<ntilde>ol - U+0050 u+006F u+0072 u+0071 u+0075 u+00E9 u+006E u+006F u+0070 - u+0075 u+0065 u+0064 u+0065 u+006E u+0073 u+0069 u+006D u+0070 - u+006C u+0065 u+006D u+0065 u+006E u+0074 u+0065 u+0068 u+0061 - u+0062 u+006C u+0061 u+0072 u+0065 u+006E U+0045 u+0073 u+0070 - u+0061 u+00F1 u+006F u+006C - Punycode: PorqunopuedensimplementehablarenEspaol-fmd56a - - (K) Vietnamese: - T<adotbelow>isaoh<odotbelow>kh<ocirc>ngth<ecirchookabove>ch\ - <ihookabove>n<oacute>iti<ecircacute>ngVi<ecircdotbelow>t - U+0054 u+1EA1 u+0069 u+0073 u+0061 u+006F u+0068 u+1ECD u+006B - u+0068 u+00F4 u+006E u+0067 u+0074 u+0068 u+1EC3 u+0063 u+0068 - u+1EC9 u+006E u+00F3 u+0069 u+0074 u+0069 u+1EBF u+006E u+0067 - U+0056 u+0069 u+1EC7 u+0074 - Punycode: TisaohkhngthchnitingVit-kjcr8268qyxafd2f1b9g - - - -Costello Standards Track [Page 15] - -RFC 3492 IDNA Punycode March 2003 - - - The next several examples are all names of Japanese music artists, - song titles, and TV programs, just because the author happens to have - them handy (but Japanese is useful for providing examples of single- - row text, two-row text, ideographic text, and various mixtures - thereof). - - (L) 3<nen>B<gumi><kinpachi><sensei> - u+0033 u+5E74 U+0042 u+7D44 u+91D1 u+516B u+5148 u+751F - Punycode: 3B-ww4c5e180e575a65lsy2b - - (M) <amuro><namie>-with-SUPER-MONKEYS - u+5B89 u+5BA4 u+5948 u+7F8E u+6075 u+002D u+0077 u+0069 u+0074 - u+0068 u+002D U+0053 U+0055 U+0050 U+0045 U+0052 u+002D U+004D - U+004F U+004E U+004B U+0045 U+0059 U+0053 - Punycode: -with-SUPER-MONKEYS-pc58ag80a8qai00g7n9n - - (N) Hello-Another-Way-<sorezore><no><basho> - U+0048 u+0065 u+006C u+006C u+006F u+002D U+0041 u+006E u+006F - u+0074 u+0068 u+0065 u+0072 u+002D U+0057 u+0061 u+0079 u+002D - u+305D u+308C u+305E u+308C u+306E u+5834 u+6240 - Punycode: Hello-Another-Way--fc4qua05auwb3674vfr0b - - (O) <hitotsu><yane><no><shita>2 - u+3072 u+3068 u+3064 u+5C4B u+6839 u+306E u+4E0B u+0032 - Punycode: 2-u9tlzr9756bt3uc0v - - (P) Maji<de>Koi<suru>5<byou><mae> - U+004D u+0061 u+006A u+0069 u+3067 U+004B u+006F u+0069 u+3059 - u+308B u+0035 u+79D2 u+524D - Punycode: MajiKoi5-783gue6qz075azm5e - - (Q) <pafii>de<runba> - u+30D1 u+30D5 u+30A3 u+30FC u+0064 u+0065 u+30EB u+30F3 u+30D0 - Punycode: de-jg4avhby1noc0d - - (R) <sono><supiido><de> - u+305D u+306E u+30B9 u+30D4 u+30FC u+30C9 u+3067 - Punycode: d9juau41awczczp - - The last example is an ASCII string that breaks the existing rules - for host name labels. (It is not a realistic example for IDNA, - because IDNA never encodes pure ASCII labels.) - - (S) -> $1.00 <- - u+002D u+003E u+0020 u+0024 u+0031 u+002E u+0030 u+0030 u+0020 - u+003C u+002D - Punycode: -> $1.00 <-- - - - - -Costello Standards Track [Page 16] - -RFC 3492 IDNA Punycode March 2003 - - -7.2 Decoding traces - - In the following traces, the evolving state of the decoder is shown - as a sequence of hexadecimal values, representing the code points in - the extended string. An asterisk appears just after the most - recently inserted code point, indicating both n (the value preceeding - the asterisk) and i (the position of the value just after the - asterisk). Other numerical values are decimal. - - Decoding trace of example B from section 7.1: - - n is 128, i is 0, bias is 72 - input is "ihqwcrb4cv8a8dqg056pqjye" - there is no delimiter, so extended string starts empty - delta "ihq" decodes to 19853 - bias becomes 21 - 4E0D * - delta "wc" decodes to 64 - bias becomes 20 - 4E0D 4E2D * - delta "rb" decodes to 37 - bias becomes 13 - 4E3A * 4E0D 4E2D - delta "4c" decodes to 56 - bias becomes 17 - 4E3A 4E48 * 4E0D 4E2D - delta "v8a" decodes to 599 - bias becomes 32 - 4E3A 4EC0 * 4E48 4E0D 4E2D - delta "8d" decodes to 130 - bias becomes 23 - 4ED6 * 4E3A 4EC0 4E48 4E0D 4E2D - delta "qg" decodes to 154 - bias becomes 25 - 4ED6 4EEC * 4E3A 4EC0 4E48 4E0D 4E2D - delta "056p" decodes to 46301 - bias becomes 84 - 4ED6 4EEC 4E3A 4EC0 4E48 4E0D 4E2D 6587 * - delta "qjye" decodes to 88531 - bias becomes 90 - 4ED6 4EEC 4E3A 4EC0 4E48 4E0D 8BF4 * 4E2D 6587 - - - - - - - - - - -Costello Standards Track [Page 17] - -RFC 3492 IDNA Punycode March 2003 - - - Decoding trace of example L from section 7.1: - - n is 128, i is 0, bias is 72 - input is "3B-ww4c5e180e575a65lsy2b" - literal portion is "3B-", so extended string starts as: - 0033 0042 - delta "ww4c" decodes to 62042 - bias becomes 27 - 0033 0042 5148 * - delta "5e" decodes to 139 - bias becomes 24 - 0033 0042 516B * 5148 - delta "180e" decodes to 16683 - bias becomes 67 - 0033 5E74 * 0042 516B 5148 - delta "575a" decodes to 34821 - bias becomes 82 - 0033 5E74 0042 516B 5148 751F * - delta "65l" decodes to 14592 - bias becomes 67 - 0033 5E74 0042 7D44 * 516B 5148 751F - delta "sy2b" decodes to 42088 - bias becomes 84 - 0033 5E74 0042 7D44 91D1 * 516B 5148 751F - - - - - - - - - - - - - - - - - - - - - - - - - - - -Costello Standards Track [Page 18] - -RFC 3492 IDNA Punycode March 2003 - - -7.3 Encoding traces - - In the following traces, code point values are hexadecimal, while - other numerical values are decimal. - - Encoding trace of example B from section 7.1: - - bias is 72 - input is: - 4ED6 4EEC 4E3A 4EC0 4E48 4E0D 8BF4 4E2D 6587 - there are no basic code points, so no literal portion - next code point to insert is 4E0D - needed delta is 19853, encodes as "ihq" - bias becomes 21 - next code point to insert is 4E2D - needed delta is 64, encodes as "wc" - bias becomes 20 - next code point to insert is 4E3A - needed delta is 37, encodes as "rb" - bias becomes 13 - next code point to insert is 4E48 - needed delta is 56, encodes as "4c" - bias becomes 17 - next code point to insert is 4EC0 - needed delta is 599, encodes as "v8a" - bias becomes 32 - next code point to insert is 4ED6 - needed delta is 130, encodes as "8d" - bias becomes 23 - next code point to insert is 4EEC - needed delta is 154, encodes as "qg" - bias becomes 25 - next code point to insert is 6587 - needed delta is 46301, encodes as "056p" - bias becomes 84 - next code point to insert is 8BF4 - needed delta is 88531, encodes as "qjye" - bias becomes 90 - output is "ihqwcrb4cv8a8dqg056pqjye" - - - - - - - - - - - - -Costello Standards Track [Page 19] - -RFC 3492 IDNA Punycode March 2003 - - - Encoding trace of example L from section 7.1: - - bias is 72 - input is: - 0033 5E74 0042 7D44 91D1 516B 5148 751F - basic code points (0033, 0042) are copied to literal portion: "3B-" - next code point to insert is 5148 - needed delta is 62042, encodes as "ww4c" - bias becomes 27 - next code point to insert is 516B - needed delta is 139, encodes as "5e" - bias becomes 24 - next code point to insert is 5E74 - needed delta is 16683, encodes as "180e" - bias becomes 67 - next code point to insert is 751F - needed delta is 34821, encodes as "575a" - bias becomes 82 - next code point to insert is 7D44 - needed delta is 14592, encodes as "65l" - bias becomes 67 - next code point to insert is 91D1 - needed delta is 42088, encodes as "sy2b" - bias becomes 84 - output is "3B-ww4c5e180e575a65lsy2b" - -8. Security Considerations - - Users expect each domain name in DNS to be controlled by a single - authority. If a Unicode string intended for use as a domain label - could map to multiple ACE labels, then an internationalized domain - name could map to multiple ASCII domain names, each controlled by a - different authority, some of which could be spoofs that hijack - service requests intended for another. Therefore Punycode is - designed so that each Unicode string has a unique encoding. - - However, there can still be multiple Unicode representations of the - "same" text, for various definitions of "same". This problem is - addressed to some extent by the Unicode standard under the topic of - canonicalization, and this work is leveraged for domain names by - Nameprep [NAMEPREP]. - - - - - - - - - - -Costello Standards Track [Page 20] - -RFC 3492 IDNA Punycode March 2003 - - -9. References - -9.1 Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - -9.2 Informative References - - [RFC952] Harrenstien, K., Stahl, M. and E. Feinler, "DOD Internet - Host Table Specification", RFC 952, October 1985. - - [RFC1034] Mockapetris, P., "Domain Names - Concepts and - Facilities", STD 13, RFC 1034, November 1987. - - [IDNA] Faltstrom, P., Hoffman, P. and A. Costello, - "Internationalizing Domain Names in Applications - (IDNA)", RFC 3490, March 2003. - - [NAMEPREP] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep - Profile for Internationalized Domain Names (IDN)", RFC - 3491, March 2003. - - [ASCII] Cerf, V., "ASCII format for Network Interchange", RFC - 20, October 1969. - - [PROVINCIAL] Kaplan, M., "The 'anyone can be provincial!' page", - http://www.trigeminal.com/samples/provincial.html. - - [UNICODE] The Unicode Consortium, "The Unicode Standard", - http://www.unicode.org/unicode/standard/standard.html. - - - - - - - - - - - - - - - - - - - - -Costello Standards Track [Page 21] - -RFC 3492 IDNA Punycode March 2003 - - -A. Mixed-case annotation - - In order to use Punycode to represent case-insensitive strings, - higher layers need to case-fold the strings prior to Punycode - encoding. The encoded string can use mixed case as an annotation - telling how to convert the folded string into a mixed-case string for - display purposes. Note, however, that mixed-case annotation is not - used by the ToASCII and ToUnicode operations specified in [IDNA], and - therefore implementors of IDNA can disregard this appendix. - - Basic code points can use mixed case directly, because the decoder - copies them verbatim, leaving lowercase code points lowercase, and - leaving uppercase code points uppercase. Each non-basic code point - is represented by a delta, which is represented by a sequence of - basic code points, the last of which provides the annotation. If it - is uppercase, it is a suggestion to map the non-basic code point to - uppercase (if possible); if it is lowercase, it is a suggestion to - map the non-basic code point to lowercase (if possible). - - These annotations do not alter the code points returned by decoders; - the annotations are returned separately, for the caller to use or - ignore. Encoders can accept annotations in addition to code points, - but the annotations do not alter the output, except to influence the - uppercase/lowercase form of ASCII letters. - - Punycode encoders and decoders need not support these annotations, - and higher layers need not use them. - -B. Disclaimer and license - - Regarding this entire document or any portion of it (including the - pseudocode and C code), the author makes no guarantees and is not - responsible for any damage resulting from its use. The author grants - irrevocable permission to anyone to use, modify, and distribute it in - any way that does not diminish the rights of anyone else to use, - modify, and distribute it, provided that redistributed derivative - works do not contain misleading author or version information. - Derivative works need not be licensed under similar terms. - - - - - - - - - - - - - -Costello Standards Track [Page 22] - -RFC 3492 IDNA Punycode March 2003 - - -C. Punycode sample implementation - -/* -punycode.c from RFC 3492 -http://www.nicemice.net/idn/ -Adam M. Costello -http://www.nicemice.net/amc/ - -This is ANSI C code (C89) implementing Punycode (RFC 3492). - -*/ - - -/************************************************************/ -/* Public interface (would normally go in its own .h file): */ - -#include <limits.h> - -enum punycode_status { - punycode_success, - punycode_bad_input, /* Input is invalid. */ - punycode_big_output, /* Output would exceed the space provided. */ - punycode_overflow /* Input needs wider integers to process. */ -}; - -#if UINT_MAX >= (1 << 26) - 1 -typedef unsigned int punycode_uint; -#else -typedef unsigned long punycode_uint; -#endif - -enum punycode_status punycode_encode( - punycode_uint input_length, - const punycode_uint input[], - const unsigned char case_flags[], - punycode_uint *output_length, - char output[] ); - - /* punycode_encode() converts Unicode to Punycode. The input */ - /* is represented as an array of Unicode code points (not code */ - /* units; surrogate pairs are not allowed), and the output */ - /* will be represented as an array of ASCII code points. The */ - /* output string is *not* null-terminated; it will contain */ - /* zeros if and only if the input contains zeros. (Of course */ - /* the caller can leave room for a terminator and add one if */ - /* needed.) The input_length is the number of code points in */ - /* the input. The output_length is an in/out argument: the */ - /* caller passes in the maximum number of code points that it */ - - - -Costello Standards Track [Page 23] - -RFC 3492 IDNA Punycode March 2003 - - - /* can receive, and on successful return it will contain the */ - /* number of code points actually output. The case_flags array */ - /* holds input_length boolean values, where nonzero suggests that */ - /* the corresponding Unicode character be forced to uppercase */ - /* after being decoded (if possible), and zero suggests that */ - /* it be forced to lowercase (if possible). ASCII code points */ - /* are encoded literally, except that ASCII letters are forced */ - /* to uppercase or lowercase according to the corresponding */ - /* uppercase flags. If case_flags is a null pointer then ASCII */ - /* letters are left as they are, and other code points are */ - /* treated as if their uppercase flags were zero. The return */ - /* value can be any of the punycode_status values defined above */ - /* except punycode_bad_input; if not punycode_success, then */ - /* output_size and output might contain garbage. */ - -enum punycode_status punycode_decode( - punycode_uint input_length, - const char input[], - punycode_uint *output_length, - punycode_uint output[], - unsigned char case_flags[] ); - - /* punycode_decode() converts Punycode to Unicode. The input is */ - /* represented as an array of ASCII code points, and the output */ - /* will be represented as an array of Unicode code points. The */ - /* input_length is the number of code points in the input. The */ - /* output_length is an in/out argument: the caller passes in */ - /* the maximum number of code points that it can receive, and */ - /* on successful return it will contain the actual number of */ - /* code points output. The case_flags array needs room for at */ - /* least output_length values, or it can be a null pointer if the */ - /* case information is not needed. A nonzero flag suggests that */ - /* the corresponding Unicode character be forced to uppercase */ - /* by the caller (if possible), while zero suggests that it be */ - /* forced to lowercase (if possible). ASCII code points are */ - /* output already in the proper case, but their flags will be set */ - /* appropriately so that applying the flags would be harmless. */ - /* The return value can be any of the punycode_status values */ - /* defined above; if not punycode_success, then output_length, */ - /* output, and case_flags might contain garbage. On success, the */ - /* decoder will never need to write an output_length greater than */ - /* input_length, because of how the encoding is defined. */ - -/**********************************************************/ -/* Implementation (would normally go in its own .c file): */ - -#include <string.h> - - - - -Costello Standards Track [Page 24] - -RFC 3492 IDNA Punycode March 2003 - - -/*** Bootstring parameters for Punycode ***/ - -enum { base = 36, tmin = 1, tmax = 26, skew = 38, damp = 700, - initial_bias = 72, initial_n = 0x80, delimiter = 0x2D }; - -/* basic(cp) tests whether cp is a basic code point: */ -#define basic(cp) ((punycode_uint)(cp) < 0x80) - -/* delim(cp) tests whether cp is a delimiter: */ -#define delim(cp) ((cp) == delimiter) - -/* decode_digit(cp) returns the numeric value of a basic code */ -/* point (for use in representing integers) in the range 0 to */ -/* base-1, or base if cp is does not represent a value. */ - -static punycode_uint decode_digit(punycode_uint cp) -{ - return cp - 48 < 10 ? cp - 22 : cp - 65 < 26 ? cp - 65 : - cp - 97 < 26 ? cp - 97 : base; -} - -/* encode_digit(d,flag) returns the basic code point whose value */ -/* (when used for representing integers) is d, which needs to be in */ -/* the range 0 to base-1. The lowercase form is used unless flag is */ -/* nonzero, in which case the uppercase form is used. The behavior */ -/* is undefined if flag is nonzero and digit d has no uppercase form. */ - -static char encode_digit(punycode_uint d, int flag) -{ - return d + 22 + 75 * (d < 26) - ((flag != 0) << 5); - /* 0..25 map to ASCII a..z or A..Z */ - /* 26..35 map to ASCII 0..9 */ -} - -/* flagged(bcp) tests whether a basic code point is flagged */ -/* (uppercase). The behavior is undefined if bcp is not a */ -/* basic code point. */ - -#define flagged(bcp) ((punycode_uint)(bcp) - 65 < 26) - -/* encode_basic(bcp,flag) forces a basic code point to lowercase */ -/* if flag is zero, uppercase if flag is nonzero, and returns */ -/* the resulting code point. The code point is unchanged if it */ -/* is caseless. The behavior is undefined if bcp is not a basic */ -/* code point. */ - -static char encode_basic(punycode_uint bcp, int flag) -{ - - - -Costello Standards Track [Page 25] - -RFC 3492 IDNA Punycode March 2003 - - - bcp -= (bcp - 97 < 26) << 5; - return bcp + ((!flag && (bcp - 65 < 26)) << 5); -} - -/*** Platform-specific constants ***/ - -/* maxint is the maximum value of a punycode_uint variable: */ -static const punycode_uint maxint = -1; -/* Because maxint is unsigned, -1 becomes the maximum value. */ - -/*** Bias adaptation function ***/ - -static punycode_uint adapt( - punycode_uint delta, punycode_uint numpoints, int firsttime ) -{ - punycode_uint k; - - delta = firsttime ? delta / damp : delta >> 1; - /* delta >> 1 is a faster way of doing delta / 2 */ - delta += delta / numpoints; - - for (k = 0; delta > ((base - tmin) * tmax) / 2; k += base) { - delta /= base - tmin; - } - - return k + (base - tmin + 1) * delta / (delta + skew); -} - -/*** Main encode function ***/ - -enum punycode_status punycode_encode( - punycode_uint input_length, - const punycode_uint input[], - const unsigned char case_flags[], - punycode_uint *output_length, - char output[] ) -{ - punycode_uint n, delta, h, b, out, max_out, bias, j, m, q, k, t; - - /* Initialize the state: */ - - n = initial_n; - delta = out = 0; - max_out = *output_length; - bias = initial_bias; - - /* Handle the basic code points: */ - - - - -Costello Standards Track [Page 26] - -RFC 3492 IDNA Punycode March 2003 - - - for (j = 0; j < input_length; ++j) { - if (basic(input[j])) { - if (max_out - out < 2) return punycode_big_output; - output[out++] = - case_flags ? encode_basic(input[j], case_flags[j]) : input[j]; - } - /* else if (input[j] < n) return punycode_bad_input; */ - /* (not needed for Punycode with unsigned code points) */ - } - - h = b = out; - - /* h is the number of code points that have been handled, b is the */ - /* number of basic code points, and out is the number of characters */ - /* that have been output. */ - - if (b > 0) output[out++] = delimiter; - - /* Main encoding loop: */ - - while (h < input_length) { - /* All non-basic code points < n have been */ - /* handled already. Find the next larger one: */ - - for (m = maxint, j = 0; j < input_length; ++j) { - /* if (basic(input[j])) continue; */ - /* (not needed for Punycode) */ - if (input[j] >= n && input[j] < m) m = input[j]; - } - - /* Increase delta enough to advance the decoder's */ - /* <n,i> state to <m,0>, but guard against overflow: */ - - if (m - n > (maxint - delta) / (h + 1)) return punycode_overflow; - delta += (m - n) * (h + 1); - n = m; - - for (j = 0; j < input_length; ++j) { - /* Punycode does not need to check whether input[j] is basic: */ - if (input[j] < n /* || basic(input[j]) */ ) { - if (++delta == 0) return punycode_overflow; - } - - if (input[j] == n) { - /* Represent delta as a generalized variable-length integer: */ - - for (q = delta, k = base; ; k += base) { - if (out >= max_out) return punycode_big_output; - - - -Costello Standards Track [Page 27] - -RFC 3492 IDNA Punycode March 2003 - - - t = k <= bias /* + tmin */ ? tmin : /* +tmin not needed */ - k >= bias + tmax ? tmax : k - bias; - if (q < t) break; - output[out++] = encode_digit(t + (q - t) % (base - t), 0); - q = (q - t) / (base - t); - } - - output[out++] = encode_digit(q, case_flags && case_flags[j]); - bias = adapt(delta, h + 1, h == b); - delta = 0; - ++h; - } - } - - ++delta, ++n; - } - - *output_length = out; - return punycode_success; -} - -/*** Main decode function ***/ - -enum punycode_status punycode_decode( - punycode_uint input_length, - const char input[], - punycode_uint *output_length, - punycode_uint output[], - unsigned char case_flags[] ) -{ - punycode_uint n, out, i, max_out, bias, - b, j, in, oldi, w, k, digit, t; - - /* Initialize the state: */ - - n = initial_n; - out = i = 0; - max_out = *output_length; - bias = initial_bias; - - /* Handle the basic code points: Let b be the number of input code */ - /* points before the last delimiter, or 0 if there is none, then */ - /* copy the first b code points to the output. */ - - for (b = j = 0; j < input_length; ++j) if (delim(input[j])) b = j; - if (b > max_out) return punycode_big_output; - - for (j = 0; j < b; ++j) { - - - -Costello Standards Track [Page 28] - -RFC 3492 IDNA Punycode March 2003 - - - if (case_flags) case_flags[out] = flagged(input[j]); - if (!basic(input[j])) return punycode_bad_input; - output[out++] = input[j]; - } - - /* Main decoding loop: Start just after the last delimiter if any */ - /* basic code points were copied; start at the beginning otherwise. */ - - for (in = b > 0 ? b + 1 : 0; in < input_length; ++out) { - - /* in is the index of the next character to be consumed, and */ - /* out is the number of code points in the output array. */ - - /* Decode a generalized variable-length integer into delta, */ - /* which gets added to i. The overflow checking is easier */ - /* if we increase i as we go, then subtract off its starting */ - /* value at the end to obtain delta. */ - - for (oldi = i, w = 1, k = base; ; k += base) { - if (in >= input_length) return punycode_bad_input; - digit = decode_digit(input[in++]); - if (digit >= base) return punycode_bad_input; - if (digit > (maxint - i) / w) return punycode_overflow; - i += digit * w; - t = k <= bias /* + tmin */ ? tmin : /* +tmin not needed */ - k >= bias + tmax ? tmax : k - bias; - if (digit < t) break; - if (w > maxint / (base - t)) return punycode_overflow; - w *= (base - t); - } - - bias = adapt(i - oldi, out + 1, oldi == 0); - - /* i was supposed to wrap around from out+1 to 0, */ - /* incrementing n each time, so we'll fix that now: */ - - if (i / (out + 1) > maxint - n) return punycode_overflow; - n += i / (out + 1); - i %= (out + 1); - - /* Insert n at position i of the output: */ - - /* not needed for Punycode: */ - /* if (decode_digit(n) <= base) return punycode_invalid_input; */ - if (out >= max_out) return punycode_big_output; - - if (case_flags) { - memmove(case_flags + i + 1, case_flags + i, out - i); - - - -Costello Standards Track [Page 29] - -RFC 3492 IDNA Punycode March 2003 - - - /* Case of last character determines uppercase flag: */ - case_flags[i] = flagged(input[in - 1]); - } - - memmove(output + i + 1, output + i, (out - i) * sizeof *output); - output[i++] = n; - } - - *output_length = out; - return punycode_success; -} - -/******************************************************************/ -/* Wrapper for testing (would normally go in a separate .c file): */ - -#include <assert.h> -#include <stdio.h> -#include <stdlib.h> -#include <string.h> - -/* For testing, we'll just set some compile-time limits rather than */ -/* use malloc(), and set a compile-time option rather than using a */ -/* command-line option. */ - -enum { - unicode_max_length = 256, - ace_max_length = 256 -}; - -static void usage(char **argv) -{ - fprintf(stderr, - "\n" - "%s -e reads code points and writes a Punycode string.\n" - "%s -d reads a Punycode string and writes code points.\n" - "\n" - "Input and output are plain text in the native character set.\n" - "Code points are in the form u+hex separated by whitespace.\n" - "Although the specification allows Punycode strings to contain\n" - "any characters from the ASCII repertoire, this test code\n" - "supports only the printable characters, and needs the Punycode\n" - "string to be followed by a newline.\n" - "The case of the u in u+hex is the force-to-uppercase flag.\n" - , argv[0], argv[0]); - exit(EXIT_FAILURE); -} - -static void fail(const char *msg) - - - -Costello Standards Track [Page 30] - -RFC 3492 IDNA Punycode March 2003 - - -{ - fputs(msg,stderr); - exit(EXIT_FAILURE); -} - -static const char too_big[] = - "input or output is too large, recompile with larger limits\n"; -static const char invalid_input[] = "invalid input\n"; -static const char overflow[] = "arithmetic overflow\n"; -static const char io_error[] = "I/O error\n"; - -/* The following string is used to convert printable */ -/* characters between ASCII and the native charset: */ - -static const char print_ascii[] = - "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n" - "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n" - " !\"#$%&'()*+,-./" - "0123456789:;<=>?" - "@ABCDEFGHIJKLMNO" - "PQRSTUVWXYZ[\\]^_" - "`abcdefghijklmno" - "pqrstuvwxyz{|}~\n"; - -int main(int argc, char **argv) -{ - enum punycode_status status; - int r; - unsigned int input_length, output_length, j; - unsigned char case_flags[unicode_max_length]; - - if (argc != 2) usage(argv); - if (argv[1][0] != '-') usage(argv); - if (argv[1][2] != 0) usage(argv); - - if (argv[1][1] == 'e') { - punycode_uint input[unicode_max_length]; - unsigned long codept; - char output[ace_max_length+1], uplus[3]; - int c; - - /* Read the input code points: */ - - input_length = 0; - - for (;;) { - r = scanf("%2s%lx", uplus, &codept); - if (ferror(stdin)) fail(io_error); - - - -Costello Standards Track [Page 31] - -RFC 3492 IDNA Punycode March 2003 - - - if (r == EOF || r == 0) break; - - if (r != 2 || uplus[1] != '+' || codept > (punycode_uint)-1) { - fail(invalid_input); - } - - if (input_length == unicode_max_length) fail(too_big); - - if (uplus[0] == 'u') case_flags[input_length] = 0; - else if (uplus[0] == 'U') case_flags[input_length] = 1; - else fail(invalid_input); - - input[input_length++] = codept; - } - - /* Encode: */ - - output_length = ace_max_length; - status = punycode_encode(input_length, input, case_flags, - &output_length, output); - if (status == punycode_bad_input) fail(invalid_input); - if (status == punycode_big_output) fail(too_big); - if (status == punycode_overflow) fail(overflow); - assert(status == punycode_success); - - /* Convert to native charset and output: */ - - for (j = 0; j < output_length; ++j) { - c = output[j]; - assert(c >= 0 && c <= 127); - if (print_ascii[c] == 0) fail(invalid_input); - output[j] = print_ascii[c]; - } - - output[j] = 0; - r = puts(output); - if (r == EOF) fail(io_error); - return EXIT_SUCCESS; - } - - if (argv[1][1] == 'd') { - char input[ace_max_length+2], *p, *pp; - punycode_uint output[unicode_max_length]; - - /* Read the Punycode input string and convert to ASCII: */ - - fgets(input, ace_max_length+2, stdin); - if (ferror(stdin)) fail(io_error); - - - -Costello Standards Track [Page 32] - -RFC 3492 IDNA Punycode March 2003 - - - if (feof(stdin)) fail(invalid_input); - input_length = strlen(input) - 1; - if (input[input_length] != '\n') fail(too_big); - input[input_length] = 0; - - for (p = input; *p != 0; ++p) { - pp = strchr(print_ascii, *p); - if (pp == 0) fail(invalid_input); - *p = pp - print_ascii; - } - - /* Decode: */ - - output_length = unicode_max_length; - status = punycode_decode(input_length, input, &output_length, - output, case_flags); - if (status == punycode_bad_input) fail(invalid_input); - if (status == punycode_big_output) fail(too_big); - if (status == punycode_overflow) fail(overflow); - assert(status == punycode_success); - - /* Output the result: */ - - for (j = 0; j < output_length; ++j) { - r = printf("%s+%04lX\n", - case_flags[j] ? "U" : "u", - (unsigned long) output[j] ); - if (r < 0) fail(io_error); - } - - return EXIT_SUCCESS; - } - - usage(argv); - return EXIT_SUCCESS; /* not reached, but quiets compiler warning */ -} - - - - - - - - - - - - - - - -Costello Standards Track [Page 33] - -RFC 3492 IDNA Punycode March 2003 - - -Author's Address - - Adam M. Costello - University of California, Berkeley - http://www.nicemice.net/amc/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Costello Standards Track [Page 34] - -RFC 3492 IDNA Punycode March 2003 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Costello Standards Track [Page 35] - diff --git a/source4/heimdal/lib/wind/rfc4013.txt b/source4/heimdal/lib/wind/rfc4013.txt deleted file mode 100644 index 54a1d31581..0000000000 --- a/source4/heimdal/lib/wind/rfc4013.txt +++ /dev/null @@ -1,339 +0,0 @@ - - - - - - -Network Working Group K. Zeilenga -Request for Comments: 4013 OpenLDAP Foundation -Category: Standards Track February 2005 - - - SASLprep: Stringprep Profile for User Names and Passwords - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - This document describes how to prepare Unicode strings representing - user names and passwords for comparison. The document defines the - "SASLprep" profile of the "stringprep" algorithm to be used for both - user names and passwords. This profile is intended to be used by - Simple Authentication and Security Layer (SASL) mechanisms (such as - PLAIN, CRAM-MD5, and DIGEST-MD5), as well as other protocols - exchanging simple user names and/or passwords. - -1. Introduction - - The use of simple user names and passwords in authentication and - authorization is pervasive on the Internet. To increase the - likelihood that user name and password input and comparison work in - ways that make sense for typical users throughout the world, this - document defines rules for preparing internationalized user names and - passwords for comparison. For simplicity and implementation ease, a - single algorithm is defined for both user names and passwords. - - The algorithm assumes all strings are comprised of characters from - the Unicode [Unicode] character set. - - This document defines the "SASLprep" profile of the "stringprep" - algorithm [StringPrep]. - - The profile is designed for use in Simple Authentication and Security - Layer ([SASL]) mechanisms, such as [PLAIN], [CRAM-MD5], and - [DIGEST-MD5]. It may be applicable where simple user names and - - - -Zeilenga Standards Track [Page 1] - -RFC 4013 SASLprep February 2005 - - - passwords are used. This profile is not intended for use in - preparing identity strings that are not simple user names (e.g., - email addresses, domain names, distinguished names), or where - identity or password strings that are not character data, or require - different handling (e.g., case folding). - - This document does not alter the technical specification of any - existing protocols. Any specification that wishes to use the - algorithm described in this document needs to explicitly incorporate - this document and provide precise details as to where and how this - algorithm is used by implementations of that specification. - -2. The SASLprep Profile - - This section defines the "SASLprep" profile of the "stringprep" - algorithm [StringPrep]. This profile is intended for use in - preparing strings representing simple user names and passwords. - - This profile uses Unicode 3.2 [Unicode]. - - Character names in this document use the notation for code points and - names from the Unicode Standard [Unicode]. For example, the letter - "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>. - In the lists of mappings and the prohibited characters, the "U+" is - left off to make the lists easier to read. The comments for - character ranges are shown in square brackets (such as "[CONTROL - CHARACTERS]") and do not come from the standard. - - Note: A glossary of terms used in Unicode can be found in [Glossary]. - Information on the Unicode character encoding model can be found in - [CharModel]. - -2.1. Mapping - - This profile specifies: - - - non-ASCII space characters [StringPrep, C.1.2] that can be - mapped to SPACE (U+0020), and - - - the "commonly mapped to nothing" characters [StringPrep, B.1] - that can be mapped to nothing. - -2.2. Normalization - - This profile specifies using Unicode normalization form KC, as - described in Section 4 of [StringPrep]. - - - - - -Zeilenga Standards Track [Page 2] - -RFC 4013 SASLprep February 2005 - - -2.3. Prohibited Output - - This profile specifies the following characters as prohibited input: - - - Non-ASCII space characters [StringPrep, C.1.2] - - ASCII control characters [StringPrep, C.2.1] - - Non-ASCII control characters [StringPrep, C.2.2] - - Private Use characters [StringPrep, C.3] - - Non-character code points [StringPrep, C.4] - - Surrogate code points [StringPrep, C.5] - - Inappropriate for plain text characters [StringPrep, C.6] - - Inappropriate for canonical representation characters - [StringPrep, C.7] - - Change display properties or deprecated characters - [StringPrep, C.8] - - Tagging characters [StringPrep, C.9] - -2.4. Bidirectional Characters - - This profile specifies checking bidirectional strings as described in - [StringPrep, Section 6]. - -2.5. Unassigned Code Points - - This profile specifies the [StringPrep, A.1] table as its list of - unassigned code points. - -3. Examples - - The following table provides examples of how various character data - is transformed by the SASLprep string preparation algorithm - - # Input Output Comments - - ----- ------ -------- - 1 I<U+00AD>X IX SOFT HYPHEN mapped to nothing - 2 user user no transformation - 3 USER USER case preserved, will not match #2 - 4 <U+00AA> a output is NFKC, input in ISO 8859-1 - 5 <U+2168> IX output is NFKC, will match #1 - 6 <U+0007> Error - prohibited character - 7 <U+0627><U+0031> Error - bidirectional check - -4. Security Considerations - - This profile is intended to prepare simple user name and password - strings for comparison or use in cryptographic functions (e.g., - message digests). The preparation algorithm was specifically - designed such that its output is canonical, and it is well-formed. - - - -Zeilenga Standards Track [Page 3] - -RFC 4013 SASLprep February 2005 - - - However, due to an anomaly [PR29] in the specification of Unicode - normalization, canonical equivalence is not guaranteed for a select - few character sequences. These sequences, however, do not appear in - well-formed text. This specification was published despite this - known technical problem. It is expected that this specification will - be revised before further progression on the Standards Track (after - [Unicode] and/or [StringPrep] specifications have been updated to - address this problem). - - It is not intended for preparing identity strings that are not simple - user names (e.g., distinguished names, domain names), nor is the - profile intended for use of simple user names that require different - handling (such as case folding). Protocols (or applications of those - protocols) that have application-specific identity forms and/or - comparison algorithms should use mechanisms specifically designed for - these forms and algorithms. - - Application of string preparation may have an impact upon the - feasibility of brute force and dictionary attacks. While the number - of possible prepared strings is less than the number of possible - Unicode strings, the number of usable names and passwords is greater - than as if only ASCII was used. Though SASLprep eliminates some - Unicode code point sequences as possible prepared strings, that - elimination generally makes the (canonical) output forms practicable - and prohibits nonsensical inputs. - - User names and passwords should be protected from eavesdropping. - - General "stringprep" and Unicode security considerations apply. Both - are discussed in [StringPrep]. - -5. IANA Considerations - - This document details the "SASLprep" profile of the [StringPrep] - protocol. This profile has been registered in the stringprep profile - registry. - - Name of this profile: SASLprep - RFC in which the profile is defined: RFC 4013 - Indicator whether or not this is the newest version of the - profile: This is the first version of the SASPprep profile. - -6. Acknowledgement - - This document borrows text from "Preparation of Internationalized - Strings ('stringprep')" and "Nameprep: A Stringprep Profile for - Internationalized Domain Names", both by Paul Hoffman and Marc - Blanchet. This document is a product of the IETF SASL WG. - - - -Zeilenga Standards Track [Page 4] - -RFC 4013 SASLprep February 2005 - - -7. Normative References - - [StringPrep] Hoffman, P. and M. Blanchet, "Preparation of - Internationalized Strings ("stringprep")", RFC 3454, - December 2002. - - [Unicode] The Unicode Consortium, "The Unicode Standard, Version - 3.2.0" is defined by "The Unicode Standard, Version - 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201- - 61633-5), as amended by the "Unicode Standard Annex - #27: Unicode 3.1" - (http://www.unicode.org/reports/tr27/) and by the - "Unicode Standard Annex #28: Unicode 3.2" - (http://www.unicode.org/reports/tr28/). - -8. Informative References - - [Glossary] The Unicode Consortium, "Unicode Glossary", - <http://www.unicode.org/glossary/>. - - [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report - #17, Character Encoding Model", UTR17, - <http://www.unicode.org/unicode/reports/tr17/>, August - 2000. - - [SASL] Melnikov, A., Ed., "Simple Authentication and Security - Layer (SASL)", Work in Progress. - - [CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism", Work in - Progress. - - [DIGEST-MD5] Leach, P., Newman, C., and A. Melnikov, "Using Digest - Authentication as a SASL Mechanism", Work in Progress. - - [PLAIN] Zeilenga, K., Ed., "The Plain SASL Mechanism", Work in - Progress. - - [PR29] "Public Review Issue #29: Normalization Issue", - <http://www.unicode.org/review/pr-29.html>, February - 2004. - -Author's Address - - Kurt D. Zeilenga - OpenLDAP Foundation - - EMail: Kurt@OpenLDAP.org - - - - -Zeilenga Standards Track [Page 5] - -RFC 4013 SASLprep February 2005 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2005). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the IETF's procedures with respect to rights in IETF Documents can - be found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. - - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - -Zeilenga Standards Track [Page 6] - diff --git a/source4/heimdal/lib/wind/rfc4518.txt b/source4/heimdal/lib/wind/rfc4518.txt deleted file mode 100644 index f886bdfb5d..0000000000 --- a/source4/heimdal/lib/wind/rfc4518.txt +++ /dev/null @@ -1,787 +0,0 @@ - - - - - - -Network Working Group K. Zeilenga -Request for Comments: 4518 OpenLDAP Foundation -Category: Standards Track June 2006 - - - Lightweight Directory Access Protocol (LDAP): - Internationalized String Preparation - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - The previous Lightweight Directory Access Protocol (LDAP) technical - specifications did not precisely define how character string matching - is to be performed. This led to a number of usability and - interoperability problems. This document defines string preparation - algorithms for character-based matching rules defined for use in - LDAP. - -1. Introduction - -1.1. Background - - A Lightweight Directory Access Protocol (LDAP) [RFC4510] matching - rule [RFC4517] defines an algorithm for determining whether a - presented value matches an attribute value in accordance with the - criteria defined for the rule. The proposition may be evaluated to - True, False, or Undefined. - - True - the attribute contains a matching value, - - False - the attribute contains no matching value, - - Undefined - it cannot be determined whether the attribute contains - a matching value. - - - - - - -Zeilenga Standards Track [Page 1] - -RFC 4518 LDAP: Internationalized String Preparation June 2006 - - - For instance, the caseIgnoreMatch matching rule may be used to - compare whether the commonName attribute contains a particular value - without regard for case and insignificant spaces. - -1.2. X.500 String Matching Rules - - "X.520: Selected attribute types" [X.520] provides (among other - things) value syntaxes and matching rules for comparing values - commonly used in the directory [X.500]. These specifications are - inadequate for strings composed of Unicode [Unicode] characters. - - The caseIgnoreMatch matching rule [X.520], for example, is simply - defined as being a case-insensitive comparison where insignificant - spaces are ignored. For printableString, there is only one space - character and case mapping is bijective, hence this definition is - sufficient. However, for Unicode string types such as - universalString, this is not sufficient. For example, a case- - insensitive matching implementation that folded lowercase characters - to uppercase would yield different results than an implementation - that used uppercase to lowercase folding. Or one implementation may - view space as referring to only SPACE (U+0020), a second - implementation may view any character with the space separator (Zs) - property as a space, and another implementation may view any - character with the whitespace (WS) category as a space. - - The lack of precise specification for character string matching has - led to significant interoperability problems. When used in - certificate chain validation, security vulnerabilities can arise. To - address these problems, this document defines precise algorithms for - preparing character strings for matching. - -1.3. Relationship to "stringprep" - - The character string preparation algorithms described in this - document are based upon the "stringprep" approach [RFC3454]. In - "stringprep", presented and stored values are first prepared for - comparison so that a character-by-character comparison yields the - "correct" result. - - The approach used here is a refinement of the "stringprep" [RFC3454] - approach. Each algorithm involves two additional preparation steps. - - a) Prior to applying the Unicode string preparation steps outlined in - "stringprep", the string is transcoded to Unicode. - - b) After applying the Unicode string preparation steps outlined in - "stringprep", the string is modified to appropriately handle - characters insignificant to the matching rule. - - - -Zeilenga Standards Track [Page 2] - -RFC 4518 LDAP: Internationalized String Preparation June 2006 - - - Hence, preparation of character strings for X.500 [X.500] matching - [X.501] involves the following steps: - - 1) Transcode - 2) Map - 3) Normalize - 4) Prohibit - 5) Check Bidi (Bidirectional) - 6) Insignificant Character Handling - - These steps are described in Section 2. - - It is noted that while various tables of Unicode characters included - or referenced by this specification are derived from Unicode - [Unicode] data, these tables are to be considered definitive for the - purpose of implementing this specification. - -1.4. Relationship to the LDAP Technical Specification - - This document is an integral part of the LDAP technical specification - [RFC4510], which obsoletes the previously defined LDAP technical - specification [RFC3377] in its entirety. - - This document details new LDAP internationalized character string - preparation algorithms used by [RFC4517] and possible other technical - specifications defining LDAP syntaxes and/or matching rules. - -1.5. Relationship to X.500 - - LDAP is defined [RFC4510] in X.500 terms as an X.500 access - mechanism. As such, there is a strong desire for alignment between - LDAP and X.500 syntax and semantics. The character string - preparation algorithms described in this document are based upon - "Internationalized String Matching Rules for X.500" [XMATCH] proposal - to ITU/ISO Joint Study Group 2. - -1.6. Conventions and Terms - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in BCP 14 [RFC2119]. - - Character names in this document use the notation for code points and - names from the Unicode Standard [Unicode]. For example, the letter - "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>. - In the lists of mappings and the prohibited characters, the "U+" is - - - - - -Zeilenga Standards Track [Page 3] - -RFC 4518 LDAP: Internationalized String Preparation June 2006 - - - left off to make the lists easier to read. The comments for - character ranges are shown in square brackets (such as "[CONTROL - CHARACTERS]") and do not come from the standard. - - Note: a glossary of terms used in Unicode can be found in [Glossary]. - Information on the Unicode character encoding model can be found in - [CharModel]. - - The term "combining mark", as used in this specification, refers to - any Unicode [Unicode] code point that has a mark property (Mn, Mc, - Me). Appendix A provides a definitive list of combining marks. - -2. String Preparation - - The following six-step process SHALL be applied to each presented and - attribute value in preparation for character string matching rule - evaluation. - - 1) Transcode - 2) Map - 3) Normalize - 4) Prohibit - 5) Check bidi - 6) Insignificant Character Handling - - Failure in any step causes the assertion to evaluate to Undefined. - - The character repertoire of this process is Unicode 3.2 [Unicode]. - - Note that this six-step process specification is intended to describe - expected matching behavior. Implementations are free to use - alternative processes so long as the matching rule evaluation - behavior provided is consistent with the behavior described by this - specification. - -2.1. Transcode - - Each non-Unicode string value is transcoded to Unicode. - - PrintableString [X.680] values are transcoded directly to Unicode. - - UniversalString, UTF8String, and bmpString [X.680] values need not be - transcoded as they are Unicode-based strings (in the case of - bmpString, a subset of Unicode). - - TeletexString [X.680] values are transcoded to Unicode. As there is - no standard for mapping TeletexString values to Unicode, the mapping - is left a local matter. - - - -Zeilenga Standards Track [Page 4] - -RFC 4518 LDAP: Internationalized String Preparation June 2006 - - - For these and other reasons, use of TeletexString is NOT RECOMMENDED. - - The output is the transcoded string. - -2.2. Map - - SOFT HYPHEN (U+00AD) and MONGOLIAN TODO SOFT HYPHEN (U+1806) code - points are mapped to nothing. COMBINING GRAPHEME JOINER (U+034F) and - VARIATION SELECTORs (U+180B-180D, FF00-FE0F) code points are also - mapped to nothing. The OBJECT REPLACEMENT CHARACTER (U+FFFC) is - mapped to nothing. - - CHARACTER TABULATION (U+0009), LINE FEED (LF) (U+000A), LINE - TABULATION (U+000B), FORM FEED (FF) (U+000C), CARRIAGE RETURN (CR) - (U+000D), and NEXT LINE (NEL) (U+0085) are mapped to SPACE (U+0020). - - All other control code (e.g., Cc) points or code points with a - control function (e.g., Cf) are mapped to nothing. The following is - a complete list of these code points: U+0000-0008, 000E-001F, 007F- - 0084, 0086-009F, 06DD, 070F, 180E, 200C-200F, 202A-202E, 2060-2063, - 206A-206F, FEFF, FFF9-FFFB, 1D173-1D17A, E0001, E0020-E007F. - - ZERO WIDTH SPACE (U+200B) is mapped to nothing. All other code - points with Separator (space, line, or paragraph) property (e.g., Zs, - Zl, or Zp) are mapped to SPACE (U+0020). The following is a complete - list of these code points: U+0020, 00A0, 1680, 2000-200A, 2028-2029, - 202F, 205F, 3000. - - For case ignore, numeric, and stored prefix string matching rules, - characters are case folded per B.2 of [RFC3454]. - - The output is the mapped string. - -2.3. Normalize - - The input string is to be normalized to Unicode Form KC - (compatibility composed) as described in [UAX15]. The output is the - normalized string. - -2.4. Prohibit - - All Unassigned code points are prohibited. Unassigned code points - are listed in Table A.1 of [RFC3454]. - - Characters that, per Section 5.8 of [RFC3454], change display - properties or are deprecated are prohibited. These characters are - listed in Table C.8 of [RFC3454]. - - - - -Zeilenga Standards Track [Page 5] - -RFC 4518 LDAP: Internationalized String Preparation June 2006 - - - Private Use code points are prohibited. These characters are listed - in Table C.3 of [RFC3454]. - - All non-character code points are prohibited. These code points are - listed in Table C.4 of [RFC3454]. - - Surrogate codes are prohibited. These characters are listed in Table - C.5 of [RFC3454]. - - The REPLACEMENT CHARACTER (U+FFFD) code point is prohibited. - - The step fails if the input string contains any prohibited code - point. Otherwise, the output is the input string. - -2.5. Check bidi - - Bidirectional characters are ignored. - -2.6. Insignificant Character Handling - - In this step, the string is modified to ensure proper handling of - characters insignificant to the matching rule. This modification - differs from matching rule to matching rule. - - Section 2.6.1 applies to case ignore and exact string matching. - Section 2.6.2 applies to numericString matching. - Section 2.6.3 applies to telephoneNumber matching. - -2.6.1. Insignificant Space Handling - - For the purposes of this section, a space is defined to be the SPACE - (U+0020) code point followed by no combining marks. - - NOTE - The previous steps ensure that the string cannot contain - any code points in the separator class, other than SPACE - (U+0020). - - For input strings that are attribute values or non-substring - assertion values: If the input string contains no non-space - character, then the output is exactly two SPACEs. Otherwise (the - input string contains at least one non-space character), the string - is modified such that the string starts with exactly one space - character, ends with exactly one SPACE character, and any inner - (non-empty) sequence of space characters is replaced with exactly two - SPACE characters. For instance, the input strings - "foo<SPACE>bar<SPACE><SPACE>", result in the output - "<SPACE>foo<SPACE><SPACE>bar<SPACE>". - - - - -Zeilenga Standards Track [Page 6] - -RFC 4518 LDAP: Internationalized String Preparation June 2006 - - - For input strings that are substring assertion values: If the string - being prepared contains no non-space characters, then the output - string is exactly one SPACE. Otherwise, the following steps are - taken: - - - If the input string is an initial substring, it is modified to - start with exactly one SPACE character; - - - If the input string is an initial or an any substring that ends in - one or more space characters, it is modified to end with exactly - one SPACE character; - - - If the input string is an any or a final substring that starts in - one or more space characters, it is modified to start with exactly - one SPACE character; and - - - If the input string is a final substring, it is modified to end - with exactly one SPACE character. - - For instance, for the input string "foo<SPACE>bar<SPACE><SPACE>" as - an initial substring, the output would be - "<SPACE>foo<SPACE><SPACE>bar<SPACE>". As an any or final substring, - the same input would result in "foo<SPACE>bar<SPACE>". - - Appendix B discusses the rationale for the behavior. - -2.6.2. numericString Insignificant Character Handling - - For the purposes of this section, a space is defined to be the SPACE - (U+0020) code point followed by no combining marks. - - All spaces are regarded as insignificant and are to be removed. - - For example, removal of spaces from the Form KC string: - "<SPACE><SPACE>123<SPACE><SPACE>456<SPACE><SPACE>" - would result in the output string: - "123456" - and the Form KC string: - "<SPACE><SPACE><SPACE>" - would result in the output string: - "" (an empty string). - -2.6.3. telephoneNumber Insignificant Character Handling - - For the purposes of this section, a hyphen is defined to be a - HYPHEN-MINUS (U+002D), ARMENIAN HYPHEN (U+058A), HYPHEN (U+2010), - NON-BREAKING HYPHEN (U+2011), MINUS SIGN (U+2212), SMALL HYPHEN-MINUS - (U+FE63), or FULLWIDTH HYPHEN-MINUS (U+FF0D) code point followed by - - - -Zeilenga Standards Track [Page 7] - -RFC 4518 LDAP: Internationalized String Preparation June 2006 - - - no combining marks and a space is defined to be the SPACE (U+0020) - code point followed by no combining marks. - - All hyphens and spaces are considered insignificant and are to be - removed. - - For example, removal of hyphens and spaces from the Form KC string: - "<SPACE><HYPHEN>123<SPACE><SPACE>456<SPACE><HYPHEN>" - would result in the output string: - "123456" - and the Form KC string: - "<HYPHEN><HYPHEN><HYPHEN>" - would result in the (empty) output string: - "". - -3. Security Considerations - - "Preparation of Internationalized Strings ("stringprep")" [RFC3454] - security considerations generally apply to the algorithms described - here. - -4. Acknowledgements - - The approach used in this document is based upon design principles - and algorithms described in "Preparation of Internationalized Strings - ('stringprep')" [RFC3454] by Paul Hoffman and Marc Blanchet. Some - additional guidance was drawn from Unicode Technical Standards, - Technical Reports, and Notes. - - This document is a product of the IETF LDAP Revision (LDAPBIS) - Working Group. - -5. References - -5.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of - Internationalized Strings ("stringprep")", RFC 3454, - December 2002. - - [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP): Technical Specification Road Map", RFC 4510, - June 2006. - - - - - -Zeilenga Standards Track [Page 8] - -RFC 4518 LDAP: Internationalized String Preparation June 2006 - - - [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol - (LDAP): Syntaxes and Matching Rules", RFC 4517, June - 2006. - - [Unicode] The Unicode Consortium, "The Unicode Standard, Version - 3.2.0" is defined by "The Unicode Standard, Version - 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201- - 61633-5), as amended by the "Unicode Standard Annex - #27: Unicode 3.1" - (http://www.unicode.org/reports/tr27/) and by the - "Unicode Standard Annex #28: Unicode 3.2" - (http://www.unicode.org/reports/tr28/). - - [UAX15] Davis, M. and M. Duerst, "Unicode Standard Annex #15: - Unicode Normalization Forms, Version 3.2.0". - <http://www.unicode.org/unicode/reports/tr15/tr15- - 22.html>, March 2002. - - [X.680] International Telecommunication Union - - Telecommunication Standardization Sector, "Abstract - Syntax Notation One (ASN.1) - Specification of Basic - Notation", X.680(2002) (also ISO/IEC 8824-1:2002). - -5.2. Informative References - - [X.500] International Telecommunication Union - - Telecommunication Standardization Sector, "The - Directory -- Overview of concepts, models and - services," X.500(1993) (also ISO/IEC 9594-1:1994). - - [X.501] International Telecommunication Union - - Telecommunication Standardization Sector, "The - Directory -- Models," X.501(1993) (also ISO/IEC 9594- - 2:1994). - - [X.520] International Telecommunication Union - - Telecommunication Standardization Sector, "The - Directory: Selected Attribute Types", X.520(1993) (also - ISO/IEC 9594-6:1994). - - [Glossary] The Unicode Consortium, "Unicode Glossary", - <http://www.unicode.org/glossary/>. - - [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report - #17, Character Encoding Model", UTR17, - <http://www.unicode.org/unicode/reports/tr17/>, August - 2000. - - - - -Zeilenga Standards Track [Page 9] - -RFC 4518 LDAP: Internationalized String Preparation June 2006 - - - [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access - Protocol (v3): Technical Specification", RFC 3377, - September 2002. - - [RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory - Access Protocol (LDAP): String Representation of Search - Filters", RFC 4515, June 2006. - - [XMATCH] Zeilenga, K., "Internationalized String Matching Rules - for X.500", Work in Progress. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Zeilenga Standards Track [Page 10] - -RFC 4518 LDAP: Internationalized String Preparation June 2006 - - -Appendix A. Combining Marks - - This appendix is normative. - - This table was derived from Unicode [Unicode] data files; it lists - all code points with the Mn, Mc, or Me properties. This table is to - be considered definitive for the purposes of implementation of this - specification. - - 0300-034F 0360-036F 0483-0486 0488-0489 0591-05A1 - 05A3-05B9 05BB-05BC 05BF 05C1-05C2 05C4 064B-0655 0670 - 06D6-06DC 06DE-06E4 06E7-06E8 06EA-06ED 0711 0730-074A - 07A6-07B0 0901-0903 093C 093E-094F 0951-0954 0962-0963 - 0981-0983 09BC 09BE-09C4 09C7-09C8 09CB-09CD 09D7 - 09E2-09E3 0A02 0A3C 0A3E-0A42 0A47-0A48 0A4B-0A4D - 0A70-0A71 0A81-0A83 0ABC 0ABE-0AC5 0AC7-0AC9 0ACB-0ACD - 0B01-0B03 0B3C 0B3E-0B43 0B47-0B48 0B4B-0B4D 0B56-0B57 - 0B82 0BBE-0BC2 0BC6-0BC8 0BCA-0BCD 0BD7 0C01-0C03 - 0C3E-0C44 0C46-0C48 0C4A-0C4D 0C55-0C56 0C82-0C83 - 0CBE-0CC4 0CC6-0CC8 0CCA-0CCD 0CD5-0CD6 0D02-0D03 - 0D3E-0D43 0D46-0D48 0D4A-0D4D 0D57 0D82-0D83 0DCA - 0DCF-0DD4 0DD6 0DD8-0DDF 0DF2-0DF3 0E31 0E34-0E3A - 0E47-0E4E 0EB1 0EB4-0EB9 0EBB-0EBC 0EC8-0ECD 0F18-0F19 - 0F35 0F37 0F39 0F3E-0F3F 0F71-0F84 0F86-0F87 0F90-0F97 - 0F99-0FBC 0FC6 102C-1032 1036-1039 1056-1059 1712-1714 - 1732-1734 1752-1753 1772-1773 17B4-17D3 180B-180D 18A9 - 20D0-20EA 302A-302F 3099-309A FB1E FE00-FE0F FE20-FE23 - 1D165-1D169 1D16D-1D172 1D17B-1D182 1D185-1D18B - 1D1AA-1D1AD - -Appendix B. Substrings Matching - - This appendix is non-normative. - - In the absence of substrings matching, the insignificant space - handling for case ignore/exact matching could be simplified. - Specifically, the handling could be to require that all sequences of - one or more spaces be replaced with one space and, if the string - contains non-space characters, removal of all leading spaces and - trailing spaces. - - In the presence of substrings matching, this simplified space - handling would lead to unexpected and undesirable matching behavior. - For instance: - - 1) (CN=foo\20*\20bar) would match the CN value "foobar"; - - - - - -Zeilenga Standards Track [Page 11] - -RFC 4518 LDAP: Internationalized String Preparation June 2006 - - - 2) (CN=*\20foobar\20*) would match "foobar", but - (CN=*\20*foobar*\20*) would not. - - Note to readers not familiar with LDAP substrings matching: the LDAP - filter [RFC4515] assertion (CN=A*B*C) says to "match any value (of - the attribute CN) that begins with A, contains B after A, ends with C - where C is also after B." - - The first case illustrates that this simplified space handling would - cause leading and trailing spaces in substrings of the string to be - regarded as insignificant. However, only leading and trailing (as - well as multiple consecutive spaces) of the string (as a whole) are - insignificant. - - The second case illustrates that this simplified space handling would - cause sub-partitioning failures. That is, if a prepared any - substring matches a partition of the attribute value, then an - assertion constructed by subdividing that substring into multiple - substrings should also match. - - In designing an appropriate approach for space handling for - substrings matching, one must study key aspects of X.500 case - exact/ignore matching. X.520 [X.520] says: - - The [substrings] rule returns TRUE if there is a partitioning of - the attribute value (into portions) such that: - - - the specified substrings (initial, any, final) match - different portions of the value in the order of the strings - sequence; - - - initial, if present, matches the first portion of the value; - - - final, if present, matches the last portion of the value; - - - any, if present, matches some arbitrary portion of the - value. - - That is, the substrings assertion (CN=foo\20*\20bar) matches the - attribute value "foo<SPACE><SPACE>bar" as the value can be - partitioned into the portions "foo<SPACE>" and "<SPACE>bar" meeting - the above requirements. - - - - - - - - - -Zeilenga Standards Track [Page 12] - -RFC 4518 LDAP: Internationalized String Preparation June 2006 - - - X.520 also says: - - [T]he following spaces are regarded as not significant: - - - leading spaces (i.e., those preceding the first character - that is not a space); - - - trailing spaces (i.e., those following the last character - that is not a space); - - - multiple consecutive spaces (these are taken as equivalent - to a single space character). - - This statement applies to the assertion values and attribute values - as whole strings, and not individually to substrings of an assertion - value. In particular, the statements should be taken to mean that if - an assertion value and attribute value match without any - consideration to insignificant characters, then that assertion value - should also match any attribute value that differs only by inclusion - nor removal of insignificant characters. - - Hence the assertion (CN=foo\20*\20bar) matches - "foo<SPACE><SPACE><SPACE>bar" and "foo<SPACE>bar" as these values - only differ from "foo<SPACE><SPACE>bar" by the inclusion or removal - of insignificant spaces. - - Astute readers of this text will also note that there are special - cases where the specified space handling does not ignore spaces that - could be considered insignificant. For instance, the assertion - (CN=\20*\20*\20) does not match "<SPACE><SPACE><SPACE>" - (insignificant spaces present in value) or " " (insignificant spaces - not present in value). However, as these cases have no practical - application that cannot be met by simple assertions, e.g., (cn=\20), - and this minor anomaly can only be fully addressed by a preparation - algorithm to be used in conjunction with character-by-character - partitioning and matching, the anomaly is considered acceptable. - -Author's Address - - Kurt D. Zeilenga - OpenLDAP Foundation - - EMail: Kurt@OpenLDAP.org - - - - - - - - -Zeilenga Standards Track [Page 13] - -RFC 4518 LDAP: Internationalized String Preparation June 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Zeilenga Standards Track [Page 14] - diff --git a/source4/ldap_server/devdocs/rfc2307.txt b/source4/ldap_server/devdocs/rfc2307.txt deleted file mode 100644 index f46519f127..0000000000 --- a/source4/ldap_server/devdocs/rfc2307.txt +++ /dev/null @@ -1,1179 +0,0 @@ - - - - - - -Network Working Group L. Howard -Request for Comments: 2307 Independent Consultant -Category: Experimental March 1998 - - - An Approach for Using LDAP as a Network Information Service - -Status of this Memo - - This memo defines an Experimental Protocol for the Internet - community. It does not specify an Internet standard of any kind. - Discussion and suggestions for improvement are requested. - Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1998). All Rights Reserved. - -Abstract - - This document describes an experimental mechanism for mapping - entities related to TCP/IP and the UNIX system into X.500 [X500] - entries so that they may be resolved with the Lightweight Directory - Access Protocol [RFC2251]. A set of attribute types and object - classes are proposed, along with specific guidelines for interpreting - them. - - The intention is to assist the deployment of LDAP as an - organizational nameservice. No proposed solutions are intended as - standards for the Internet. Rather, it is hoped that a general - consensus will emerge as to the appropriate solution to such - problems, leading eventually to the adoption of standards. The - proposed mechanism has already been implemented with some success. - -1. Background and Motivation - - The UNIX (R) operating system, and its derivatives (specifically, - those which support TCP/IP and conform to the X/Open Single UNIX - specification [XOPEN]) require a means of looking up entities, by - matching them against search criteria or by enumeration. (Other - operating systems that support TCP/IP may provide some means of - resolving some of these entities. This schema is applicable to those - environments also.) - - These entities include users, groups, IP services (which map names to - IP ports and protocols, and vice versa), IP protocols (which map - names to IP protocol numbers and vice versa), RPCs (which map names - to ONC Remote Procedure Call [RFC1057] numbers and vice versa), NIS - - - -Howard Experimental [Page 1] - -RFC 2307 Using LDAP as a Network Information Service March 1998 - - - netgroups, booting information (boot parameters and MAC address - mappings), filesystem mounts, IP hosts and networks, and RFC822 mail - aliases. - - Resolution requests are made through a set of C functions, provided - in the UNIX system's C library. For example, the UNIX system utility - "ls", which enumerates the contents of a filesystem directory, uses - the C library function getpwuid() in order to map user IDs to login - names. Once the request is made, it is resolved using a "nameservice" - which is supported by the client library. The nameservice may be, at - its simplest, a collection of files in the local filesystem which are - opened and searched by the C library. Other common nameservices - include the Network Information Service (NIS) and the Domain Name - System (DNS). (The latter is typically used for resolving hosts, - services and networks.) Both these nameservices have the advantage of - being distributed and thus permitting a common set of entities to be - shared amongst many clients. - - LDAP is a distributed, hierarchical directory service access protocol - which is used to access repositories of users and other network- - related entities. Because LDAP is often not tightly integrated with - the host operating system, information such as users may need to be - kept both in LDAP and in an operating system supported nameservice - such as NIS. By using LDAP as the the primary means of resolving - these entities, these redundancy issues are minimized and the - scalability of LDAP can be exploited. (By comparison, NIS services - based on flat files do not have the scalability or extensibility of - LDAP or X.500.) - - The object classes and attributes defined below are suitable for - representing the aforementioned entities in a form compatible with - LDAP and X.500 directory services. - -2. General Issues - -2.1. Terminology - - The key words "MUST", "SHOULD", and "MAY" used in this document are - to be interpreted as described in [RFC2119]. - - For the purposes of this document, the term "nameservice" refers to a - service, such as NIS or flat files, that is used by the operating - system to resolve entities within a single, local naming context. - Contrast this with a "directory service" such as LDAP, which supports - extensible schema and multiple naming contexts. - - - - - - -Howard Experimental [Page 2] - -RFC 2307 Using LDAP as a Network Information Service March 1998 - - - The term "NIS-related entities" broadly refers to entities which are - typically resolved using the Network Information Service. (NIS was - previously known as YP.) Deploying LDAP for resolving these entities - does not imply that NIS be used, as a gateway or otherwise. In - particular, the host and network classes are generically applicable, - and may be implemented on any system that wishes to use LDAP or X.500 - for host and network resolution. - - The "DUA" (directory user agent) refers to the LDAP client querying - these entities, such as an LDAP to NIS gateway or the C library. The - "client" refers to the application which ultimately makes use of the - information returned by the resolution. It is irrelevant whether the - DUA and the client reside within the same address space. The act of - the DUA making this information to the client is termed - "republishing". - - To avoid confusion, the term "login name" refers to the user's login - name (being the value of the uid attribute) and the term "user ID" - refers to he user's integer identification number (being the value of - the uidNumber attribute). - - The phrases "resolving an entity" and "resolution of entities" refer - respectively to enumerating NIS-related entities of a given type, and - matching them against a given search criterion. One or more entities - are returned as a result of successful "resolutions" (a "match" - operation will only return one entity). - - The use of the term UNIX does not confer upon this schema the - endorsement of owners of the UNIX trademark. Where necessary, the - term "TCP/IP entity" is used to refer to protocols, services, hosts, - and networks, and the term "UNIX entity" to its complement. (The - former category does not mandate the host operating system supporting - the interfaces required for resolving UNIX entities.) - - The OIDs defined below are derived from iso(1) org(3) dod(6) - internet(1) directory(1) nisSchema(1). - -2.2. Attributes - - The attributes and classes defined in this document are summarized - below. - - The following attributes are defined in this document: - - uidNumber - gidNumber - gecos - homeDirectory - - - -Howard Experimental [Page 3] - -RFC 2307 Using LDAP as a Network Information Service March 1998 - - - loginShell - shadowLastChange - shadowMin - shadowMax - shadowWarning - shadowInactive - shadowExpire - shadowFlag - memberUid - memberNisNetgroup - nisNetgroupTriple - ipServicePort - ipServiceProtocol - ipProtocolNumber - oncRpcNumber - ipHostNumber - ipNetworkNumber - ipNetmaskNumber - macAddress - bootParameter - bootFile - nisMapName - nisMapEntry - - Additionally, some of the attributes defined in [RFC2256] are - required. - -2.3. Object classes - - The following object classes are defined in this document: - - posixAccount - shadowAccount - posixGroup - ipService - ipProtocol - oncRpc - ipHost - ipNetwork - nisNetgroup - nisMap - nisObject - ieee802Device - bootableDevice - - Additionally, some of the classes defined in [RFC2256] are required. - - - - - -Howard Experimental [Page 4] - -RFC 2307 Using LDAP as a Network Information Service March 1998 - - -2.4. Syntax definitions - - The following syntax definitions [RFC2252] are used by this schema. - The nisNetgroupTripleSyntax represents NIS netgroup triples: - - ( nisSchema.0.0 NAME 'nisNetgroupTripleSyntax' - DESC 'NIS netgroup triple' ) - - Values in this syntax are represented by the following: - - nisnetgrouptriple = "(" hostname "," username "," domainname ")" - hostname = "" / "-" / keystring - username = "" / "-" / keystring - domainname = "" / "-" / keystring - - X.500 servers may use the following representation of the above - syntax: - - nisNetgroupTripleSyntax ::= SEQUENCE { - hostname [0] IA5String OPTIONAL, - username [1] IA5String OPTIONAL, - domainname [2] IA5String OPTIONAL - } - - The bootParameterSyntax syntax represents boot parameters: - - ( nisSchema.0.1 NAME 'bootParameterSyntax' - DESC 'Boot parameter' ) - - where: - - bootparameter = key "=" server ":" path - key = keystring - server = keystring - path = keystring - - X.500 servers may use the following representation of the above - syntax: - - bootParameterSyntax ::= SEQUENCE { - key IA5String, - server IA5String, - path IA5String - } - - Values adhering to these syntaxes are encoded as strings by LDAP - servers. - - - - -Howard Experimental [Page 5] - -RFC 2307 Using LDAP as a Network Information Service March 1998 - - -3. Attribute definitions - - This section contains attribute definitions to be implemented by DUAs - supporting this schema. - - ( nisSchema.1.0 NAME 'uidNumber' - DESC 'An integer uniquely identifying a user in an - administrative domain' - EQUALITY integerMatch SYNTAX 'INTEGER' SINGLE-VALUE ) - - ( nisSchema.1.1 NAME 'gidNumber' - DESC 'An integer uniquely identifying a group in an - administrative domain' - EQUALITY integerMatch SYNTAX 'INTEGER' SINGLE-VALUE ) - - ( nisSchema.1.2 NAME 'gecos' - DESC 'The GECOS field; the common name' - EQUALITY caseIgnoreIA5Match - SUBSTRINGS caseIgnoreIA5SubstringsMatch - SYNTAX 'IA5String' SINGLE-VALUE ) - - ( nisSchema.1.3 NAME 'homeDirectory' - DESC 'The absolute path to the home directory' - EQUALITY caseExactIA5Match - SYNTAX 'IA5String' SINGLE-VALUE ) - - ( nisSchema.1.4 NAME 'loginShell' - DESC 'The path to the login shell' - EQUALITY caseExactIA5Match - SYNTAX 'IA5String' SINGLE-VALUE ) - - ( nisSchema.1.5 NAME 'shadowLastChange' - EQUALITY integerMatch - SYNTAX 'INTEGER' SINGLE-VALUE ) - - ( nisSchema.1.6 NAME 'shadowMin' - EQUALITY integerMatch - SYNTAX 'INTEGER' SINGLE-VALUE ) - - ( nisSchema.1.7 NAME 'shadowMax' - EQUALITY integerMatch - SYNTAX 'INTEGER' SINGLE-VALUE ) - - ( nisSchema.1.8 NAME 'shadowWarning' - EQUALITY integerMatch - SYNTAX 'INTEGER' SINGLE-VALUE ) - - ( nisSchema.1.9 NAME 'shadowInactive' - - - -Howard Experimental [Page 6] - -RFC 2307 Using LDAP as a Network Information Service March 1998 - - - EQUALITY integerMatch - SYNTAX 'INTEGER' SINGLE-VALUE ) - - ( nisSchema.1.10 NAME 'shadowExpire' - EQUALITY integerMatch - SYNTAX 'INTEGER' SINGLE-VALUE ) - - ( nisSchema.1.11 NAME 'shadowFlag' - EQUALITY integerMatch - SYNTAX 'INTEGER' SINGLE-VALUE ) - - ( nisSchema.1.12 NAME 'memberUid' - EQUALITY caseExactIA5Match - SUBSTRINGS caseExactIA5SubstringsMatch - SYNTAX 'IA5String' ) - - ( nisSchema.1.13 NAME 'memberNisNetgroup' - EQUALITY caseExactIA5Match - SUBSTRINGS caseExactIA5SubstringsMatch - SYNTAX 'IA5String' ) - - ( nisSchema.1.14 NAME 'nisNetgroupTriple' - DESC 'Netgroup triple' - SYNTAX 'nisNetgroupTripleSyntax' ) - - ( nisSchema.1.15 NAME 'ipServicePort' - EQUALITY integerMatch - SYNTAX 'INTEGER' SINGLE-VALUE ) - - ( nisSchema.1.16 NAME 'ipServiceProtocol' - SUP name ) - - ( nisSchema.1.17 NAME 'ipProtocolNumber' - EQUALITY integerMatch - SYNTAX 'INTEGER' SINGLE-VALUE ) - - ( nisSchema.1.18 NAME 'oncRpcNumber' - EQUALITY integerMatch - SYNTAX 'INTEGER' SINGLE-VALUE ) - - ( nisSchema.1.19 NAME 'ipHostNumber' - DESC 'IP address as a dotted decimal, eg. 192.168.1.1, - omitting leading zeros' - EQUALITY caseIgnoreIA5Match - SYNTAX 'IA5String{128}' ) - - ( nisSchema.1.20 NAME 'ipNetworkNumber' - DESC 'IP network as a dotted decimal, eg. 192.168, - - - -Howard Experimental [Page 7] - -RFC 2307 Using LDAP as a Network Information Service March 1998 - - - omitting leading zeros' - EQUALITY caseIgnoreIA5Match - SYNTAX 'IA5String{128}' SINGLE-VALUE ) - - ( nisSchema.1.21 NAME 'ipNetmaskNumber' - DESC 'IP netmask as a dotted decimal, eg. 255.255.255.0, - omitting leading zeros' - EQUALITY caseIgnoreIA5Match - SYNTAX 'IA5String{128}' SINGLE-VALUE ) - - ( nisSchema.1.22 NAME 'macAddress' - DESC 'MAC address in maximal, colon separated hex - notation, eg. 00:00:92:90:ee:e2' - EQUALITY caseIgnoreIA5Match - SYNTAX 'IA5String{128}' ) - - ( nisSchema.1.23 NAME 'bootParameter' - DESC 'rpc.bootparamd parameter' - SYNTAX 'bootParameterSyntax' ) - - ( nisSchema.1.24 NAME 'bootFile' - DESC 'Boot image name' - EQUALITY caseExactIA5Match - SYNTAX 'IA5String' ) - - ( nisSchema.1.26 NAME 'nisMapName' - SUP name ) - - ( nisSchema.1.27 NAME 'nisMapEntry' - EQUALITY caseExactIA5Match - SUBSTRINGS caseExactIA5SubstringsMatch - SYNTAX 'IA5String{1024}' SINGLE-VALUE ) - -4. Class definitions - - This section contains class definitions to be implemented by DUAs - supporting the schema. - - The rfc822MailGroup object class MAY be used to represent a mail - group for the purpose of alias expansion. Several alternative schemes - for mail routing and delivery using LDAP directories, which are - outside the scope of this document. - - ( nisSchema.2.0 NAME 'posixAccount' SUP top AUXILIARY - DESC 'Abstraction of an account with POSIX attributes' - MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory ) - MAY ( userPassword $ loginShell $ gecos $ description ) ) - - - - -Howard Experimental [Page 8] - -RFC 2307 Using LDAP as a Network Information Service March 1998 - - - ( nisSchema.2.1 NAME 'shadowAccount' SUP top AUXILIARY - DESC 'Additional attributes for shadow passwords' - MUST uid - MAY ( userPassword $ shadowLastChange $ shadowMin - shadowMax $ shadowWarning $ shadowInactive $ - shadowExpire $ shadowFlag $ description ) ) - - ( nisSchema.2.2 NAME 'posixGroup' SUP top STRUCTURAL - DESC 'Abstraction of a group of accounts' - MUST ( cn $ gidNumber ) - MAY ( userPassword $ memberUid $ description ) ) - - ( nisSchema.2.3 NAME 'ipService' SUP top STRUCTURAL - DESC 'Abstraction an Internet Protocol service. - Maps an IP port and protocol (such as tcp or udp) - to one or more names; the distinguished value of - the cn attribute denotes the service's canonical - name' - MUST ( cn $ ipServicePort $ ipServiceProtocol ) - MAY ( description ) ) - - ( nisSchema.2.4 NAME 'ipProtocol' SUP top STRUCTURAL - DESC 'Abstraction of an IP protocol. Maps a protocol number - to one or more names. The distinguished value of the cn - attribute denotes the protocol's canonical name' - MUST ( cn $ ipProtocolNumber $ description ) - MAY description ) - - ( nisSchema.2.5 NAME 'oncRpc' SUP top STRUCTURAL - DESC 'Abstraction of an Open Network Computing (ONC) - [RFC1057] Remote Procedure Call (RPC) binding. - This class maps an ONC RPC number to a name. - The distinguished value of the cn attribute denotes - the RPC service's canonical name' - MUST ( cn $ oncRpcNumber $ description ) - MAY description ) - - ( nisSchema.2.6 NAME 'ipHost' SUP top AUXILIARY - - DESC 'Abstraction of a host, an IP device. The distinguished - value of the cn attribute denotes the host's canonical - name. Device SHOULD be used as a structural class' - MUST ( cn $ ipHostNumber ) - MAY ( l $ description $ manager ) ) - - ( nisSchema.2.7 NAME 'ipNetwork' SUP top STRUCTURAL - DESC 'Abstraction of a network. The distinguished value of - the cn attribute denotes the network's canonical name' - - - -Howard Experimental [Page 9] - -RFC 2307 Using LDAP as a Network Information Service March 1998 - - - MUST ( cn $ ipNetworkNumber ) - MAY ( ipNetmaskNumber $ l $ description $ manager ) ) - - ( nisSchema.2.8 NAME 'nisNetgroup' SUP top STRUCTURAL - DESC 'Abstraction of a netgroup. May refer to other netgroups' - MUST cn - MAY ( nisNetgroupTriple $ memberNisNetgroup $ description ) ) - - ( nisSchema.2.09 NAME 'nisMap' SUP top STRUCTURAL - DESC 'A generic abstraction of a NIS map' - MUST nisMapName - MAY description ) - - ( nisSchema.2.10 NAME 'nisObject' SUP top STRUCTURAL - DESC 'An entry in a NIS map' - MUST ( cn $ nisMapEntry $ nisMapName ) - MAY description ) - - ( nisSchema.2.11 NAME 'ieee802Device' SUP top AUXILIARY - DESC 'A device with a MAC address; device SHOULD be - used as a structural class' - MAY macAddress ) - - ( nisSchema.2.12 NAME 'bootableDevice' SUP top AUXILIARY - DESC 'A device with boot parameters; device SHOULD be - used as a structural class' - MAY ( bootFile $ bootParameter ) ) - -5. Implementation details - -5.1. Suggested resolution methods - - The preferred means of directing a client application (one using the - shared services of the C library) to use LDAP as its information - source for the functions listed in 5.2 is to modify the source code - to directly query LDAP. As the source to commercial C libraries and - applications is rarely available to the end-user, one could emulate a - supported nameservice (such as NIS). (This is also an appropriate - opportunity to perform caching of entries across process address - spaces.) In the case of NIS, reference implementations are widely - available and the RPC interface is well known. - - The means by which the operating system is directed to use LDAP is - implementation dependent. For example, some operating systems and C - libraries support end-user extensible resolvers using dynamically - loadable libraries and a nameservice "switch". The means in which the - DUA locates LDAP servers is also implementation dependent. - - - - -Howard Experimental [Page 10] - -RFC 2307 Using LDAP as a Network Information Service March 1998 - - -5.2. Affected library functions - - The following functions are typically found in the C libraries of - most UNIX and POSIX compliant systems. An LDAP search filter - [RFC2254] which may be used to satisfy the function call is included - alongside each function name. Parameters are denoted by %s and %d for - string and integer arguments, respectively. Long lines are broken. - - getpwnam() (&(objectClass=posixAccount)(uid=%s)) - getpwuid() (&(objectClass=posixAccount) - (uidNumber=%d)) - getpwent() (objectClass=posixAccount) - - getspnam() (&(objectClass=shadowAccount)(uid=%s)) - getspent() (objectClass=shadowAccount) - - getgrnam() (&(objectClass=posixGroup)(cn=%s)) - getgrgid() (&(objectClass=posixGroup) - (gidNumber=%d)) - getgrent() (objectClass=posixGroup) - - getservbyname() (&(objectClass=ipService) - (cn=%s)(ipServiceProtocol=%s)) - getservbyport() (&(objectClass=ipService) - (ipServicePort=%d) - (ipServiceProtocol=%s)) - getservent() (objectClass=ipService) - - getrpcbyname() (&(objectClass=oncRpc)(cn=%s)) - getrpcbynumber() (&(objectClass=oncRpc)(oncRpcNumber=%d)) - getrpcent() (objectClass=oncRpc) - - getprotobyname() (&(objectClass=ipProtocol)(cn=%s)) - getprotobynumber() (&(objectClass=ipProtocol) - (ipProtocolNumber=%d)) - getprotoent() (objectClass=ipProtocol) - - gethostbyname() (&(objectClass=ipHost)(cn=%s)) - gethostbyaddr() (&(objectClass=ipHost)(ipHostNumber=%s)) - gethostent() (objectClass=ipHost) - - getnetbyname() (&(objectClass=ipNetwork)(cn=%s)) - getnetbyaddr() (&(objectClass=ipNetwork) - (ipNetworkNumber=%s)) - getnetent() (objectClass=ipNetwork) - - setnetgrent() (&(objectClass=nisNetgroup)(cn=%s)) - - - - -Howard Experimental [Page 11] - -RFC 2307 Using LDAP as a Network Information Service March 1998 - - -5.3. Interpreting user and group entries - - User and group resolution is initiated by the functions prefixed by - getpw and getgr respectively. The uid attribute contains the user's - login name. The cn attribute, in posixGroup entries, contains the - group's name. - - The account object class provides a convenient structural class for - posixAccount, and SHOULD be used where additional attributes are not - required. - - It is suggested that uid and cn are used as the RDN attribute type - for posixAccount and posixGroup entries, respectively. - - An account's GECOS field is preferably determined by a value of the - gecos attribute. If no gecos attribute exists, the value of the cn - attribute MUST be used. (The existence of the gecos attribute allows - information embedded in the GECOS field, such as a user's telephone - number, to be returned to the client without overloading the cn - attribute. It also accommodates directories where the common name - does not contain the user's full name.) - - An entry of class posixAccount, posixGroup, or shadowAccount without - a userPassword attribute MUST NOT be used for authentication. The - client should be returned a non-matchable password such as "x". - - userPassword values MUST be represented by following syntax: - - passwordvalue = schemeprefix encryptedpassword - schemeprefix = "{" scheme "}" - scheme = "crypt" / "md5" / "sha" / altscheme - altscheme = "x-" keystring - encryptedpassword = encrypted password - - The encrypted password contains of a plaintext key hashed using the - algorithm scheme. - - userPassword values which do not adhere to this syntax MUST NOT be - used for authentication. The DUA MUST iterate through the values of - the attribute until a value matching the above syntax is found. Only - if encryptedpassword is an empty string does the user have no - password. DUAs are not required to consider encryption schemes which - the client will not recognize; in most cases, it may be sufficient to - consider only "crypt". - - Below is an example of a userPassword attribute: - - userPassword: {crypt}X5/DBrWPOQQaI - - - -Howard Experimental [Page 12] - -RFC 2307 Using LDAP as a Network Information Service March 1998 - - - A future standard may specify LDAP v3 attribute descriptions to - represent hashed userPasswords, as noted below. This schema MUST NOT - be used with LDAP v2 DUAs and DSAs. - - attributetype = attributename sep attributeoption - attributename = "userPassword" - sep = ";" - attributeoption = schemeclass "-" scheme - schemeclass = "hash" / altschemeclass - scheme = "crypt" / "md5" / "sha" / altscheme - altschemeclass = "x-" keystring - altscheme = keystring - - - Below is an example of a userPassword attribute, represented with an - LDAP v3 attribute description: - - userPassword;hash-crypt: X5/DBrWPOQQaI - - - A DUA MAY utilise the attributes in the shadowAccount class to - provide shadow password service (getspnam() and getspent()). In such - cases, the DUA MUST NOT make use of the userPassword attribute for - getpwnam() et al, and MUST return a non-matchable password (such as - "x") to the client instead. - -5.4. Interpreting hosts and networks - - The ipHostNumber and ipNetworkNumber attributes are defined in - preference to dNSRecord (defined in [RFC1279]), in order to simplify - the DUA's role in interpreting entries in the directory. A dNSRecord - expresses a complete resource record, including time to live and - class data, which is extraneous to this schema. - - Additionally, the ipHost and ipNetwork classes permit a host or - network (respectively) and all its aliases to be represented by a - single entry in the directory. This is not necessarily possible if a - DNS resource record is mapped directly to an LDAP entry. - Implementations that wish to use LDAP to master DNS zone information - are not precluded from doing so, and may simply avoid the ipHost and - ipNetwork classes. - - This document redefines, although not exclusively, the ipNetwork - class defined in [RFC1279], in order to achieve consistent naming - with ipHost. The ipNetworkNumber attribute is also used in the - siteContact object class [ROSE]. - - - - - -Howard Experimental [Page 13] - -RFC 2307 Using LDAP as a Network Information Service March 1998 - - - The trailing zeros in a network address MUST be omitted. CIDR-style - network addresses (eg. 192.168.1/24) MAY be used. - - Hosts with IPv6 addresses MUST be written in their "preferred" form - as defined in section 2.2.1 of [RFC1884], such that all components of - the address are indicated and leading zeros are omitted. This - provides a consistent means of resolving ipHosts by address. - -5.5. Interpreting other entities - - In general, a one-to-one mapping between entities and LDAP entries is - proposed, in that each entity has exactly one representation in the - DIT. In some cases this is not feasible; for example, a service which - is represented in more than one protocol domain. Consider the - following entry: - - dn: cn=domain, dc=aja, dc=com - cn: domain - cn: nameserver - objectClass: top - objectClass: ipService - ipServicePort: 53 - ipServiceProtocol: tcp - ipServiceProtocol: udp - - This entry MUST map to the following two (2) services entities: - - domain 53/tcp nameserver - domain 53/udp nameserver - - While the above two entities may be represented as separate LDAP - entities, with different distinguished names (such as - cn=domain+ipServiceProtocol=tcp, ... and - cn=domain+ipServiceProtocol=udp, ...) it is convenient to represent - them as a single entry. (If a service is represented in multiple - protocol domains with different ports, then multiple entries are - required; multivalued RDNs may be used to distinguish them.) - - With the exception of userPassword values, which are parsed according - to the syntax considered in section 5.2, any empty values (consisting - of a zero length string) are returned by the DUA to the client. The - DUA MUST reject any entries which do not conform to the schema - (missing mandatory attributes). Non-conforming entries SHOULD be - ignored while enumerating entries. - - The nisObject object class MAY be used as a generic means of - representing NIS entities. Its use is not encouraged; where support - for entities not described in this schema is desired, an appropriate - - - -Howard Experimental [Page 14] - -RFC 2307 Using LDAP as a Network Information Service March 1998 - - - schema should be devised. Implementors are strongly advised to - support end-user extensible mappings between NIS entities and object - classes. (Where the nisObject class is used, the nisMapName attribute - may be used as a RDN.) - -5.6. Canonicalizing entries with multi-valued naming attributes - - For entities such as hosts, services, networks, protocols, and RPCs, - where there may be one or more aliases, the respective entry's - relative distinguished name SHOULD be used to determine the canonical - name. Any other values for the same attribute are used as aliases. - For example, the service described in section 5.5 has the canonical - name "domain" and exactly one alias, "nameserver". - - The schema in this document generally only defines one attribute per - class which is suitable for distinguishing an entity (excluding any - attributes with integer syntax; it is assumed that entries will be - distinguished on name). Usually, this is the common name (cn) - attribute. This aids the DUA in determining the canonical name of an - entity, as it can examine the value of the relative distinguished - name. Aliases are thus any values of the distinguishing attribute - (such as cn) which do not match the canonical name of the entity. - - In the event that a different attribute is used to distinguish the - entry, as may be the case where these object classes are used as - auxiliary classes, the entry's canonical name may not be present in - the RDN. In this case, the DUA MUST choose one of the non- - distinguished values to represent the entity's canonical name. As the - directory server guarantees no ordering of attribute values, it may - not be possible to distinguish an entry deterministically. This - ambiguity SHOULD NOT be resolved by mapping one directory entry into - multiple entities. - -6. Implementation focus - - A NIS server which uses LDAP instead of local files has been - developed which supports the schema defined in this document. - - A reference implementation of the C library resolution code has been - written for the Free Software Foundation. It may support other C - libraries which support the Name Service Switch (NSS) or the - Information Retrieval Service (IRS). - - The author has made available a freely distributable set of scripts - which parses local databases such as /etc/passwd and /etc/hosts into - a form suitable for loading into an LDAP server. - - - - - -Howard Experimental [Page 15] - -RFC 2307 Using LDAP as a Network Information Service March 1998 - - -7. Security Considerations - - The entirety of related security considerations are outside the scope - of this document. It is noted that making passwords encrypted with a - widely understood hash function (such as crypt()) available to non- - privileged users is dangerous because it exposes them to dictionary - and brute-force attacks. This is proposed only for compatibility - with existing UNIX system implementations. Sites where security is - critical SHOULD consider using a strong authentication service for - user authentication. - - Alternatively, the encrypted password could be made available only to - a subset of privileged DUAs, which would provide "shadow" password - service to client applications. This may be difficult to enforce. - - Because the schema represents operating system-level entities, access - to these entities SHOULD be granted on a discretionary basis. (There - is little point in restricting access to data which will be - republished without restriction, however.) It is particularly - important that only administrators can modify entries defined in this - schema, with the exception of allowing a principal to change their - password (which may be done on behalf of the user by a client bound - as a superior principal, such that password restrictions may be - enforced). For example, if a user were allowed to change the value of - their uidNumber attribute, they could subvert security by - equivalencing their account with the superuser account. - - A subtree of the DIT which is to be republished by a DUA (such as a - NIS gateway) SHOULD be within the same administrative domain that the - republishing DUA represents. (For example, principals outside an - organization, while conceivably part of the DIT, should not be - considered with the same degree of authority as those within the - organization.) - - Finally, care should be exercised with integer attributes of a - sensitive nature (particularly the uidNumber and gidNumber - attributes) which contain zero-length values. DUAs MAY treat such - values as corresponding to the "nobody" or "nogroup" user and group, - respectively. - -8. Acknowledgements - - Thanks to Leif Hedstrom of Netscape Communications Corporation, - Michael Grant and Rosanna Lee of Sun Microsystems Inc., Ed Reed of - Novell Inc., and Mark Wahl of Critical Angle Inc. for their valuable - contributions to the development of this schema. Thanks to Andrew - Josey of The Open Group for clarifying the use of the UNIX trademark, - and to Tim Howes and Peter J. Cherny for their support. - - - -Howard Experimental [Page 16] - -RFC 2307 Using LDAP as a Network Information Service March 1998 - - - UNIX is a registered trademark of The Open Group. - -9. References - - [RFC1057] - Sun Microsystems, Inc., "RPC: Remote Procedure Call: Protocol - Specification Version 2", RFC 1057, June 1988. - - [RFC1279] - Kille, S., "X.500 and Domains", RFC 1279, November 1991. - - [RFC1884] - Hinden, R., and S. Deering, "IP Version 6 Addressing - Architecture", RFC 1884, December 1995. - - [RFC2119] - Bradner, S., "Key Words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [RFC2251] - Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access - Protocol (v3)", RFC 2251, December 1997. - - [RFC2252] - Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight - Directory Access Protocol (v3): Attribute Syntax Definitions", - RFC 2252, December 1997. - - [RFC2254] - Howes, T., "The String Representation of LDAP Search Filters", - RFC 2254, December 1997. - - [RFC2256] - Wahl, M., "A Summary of the X.500(96) User Schema for use with - LDAPv3", RFC 2256, December 1997. - - [ROSE] - M. T. Rose, "The Little Black Book: Mail Bonding with OSI - Directory Services", ISBN 0-13-683210-5, Prentice-Hall, Inc., - 1992. - - [X500] - "Information Processing Systems - Open Systems Interconnection - - The Directory: Overview of Concepts, Models and Service", - ISO/IEC JTC 1/SC21, International Standard 9594-1, 1988. - - - - - - -Howard Experimental [Page 17] - -RFC 2307 Using LDAP as a Network Information Service March 1998 - - - [XOPEN] - ISO/IEC 9945-1:1990, Information Technology - Portable Operating - Systems Interface (POSIX) - Part 1: Systems Application - Programming Interface (API) [C Language] - -10. Author's Address - - Luke Howard - PO Box 59 - Central Park Vic 3145 - Australia - - EMail: lukeh@xedoc.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Howard Experimental [Page 18] - -RFC 2307 Using LDAP as a Network Information Service March 1998 - - -A. Example entries - - The examples described in this section are provided to illustrate the - schema described in this memo. They are not meant to be exhaustive. - - The following entry is an example of the posixAccount class: - - dn: uid=lester, dc=aja, dc=com - objectClass: top - objectClass: account - objectClass: posixAccount - uid: lester - cn: Lester the Nightfly - userPassword: {crypt}X5/DBrWPOQQaI - gecos: Lester - loginShell: /bin/csh - uidNumber: 10 - gidNumber: 10 - homeDirectory: /home/lester - - - This corresponds the UNIX system password file entry: - - lester:X5/DBrWPOQQaI:10:10:Lester:/home/lester:/bin/sh - - The following entry is an example of the ipHost class: - - dn: cn=peg.aja.com, dc=aja, dc=com - objectClass: top - objectClass: device - objectClass: ipHost - objectClass: bootableDevice - objectClass: ieee802Device - cn: peg.aja.com - cn: www.aja.com - ipHostNumber: 10.0.0.1 - macAddress: 00:00:92:90:ee:e2 - bootFile: mach - bootParameter: root=fs:/nfsroot/peg - bootParameter: swap=fs:/nfsswap/peg - bootParameter: dump=fs:/nfsdump/peg - - This entry represents the host canonically peg.aja.com, also known as - www.aja.com. The Ethernet address and four boot parameters are also - specified. - - - - - - -Howard Experimental [Page 19] - -RFC 2307 Using LDAP as a Network Information Service March 1998 - - - An example of the nisNetgroup class: - - dn: cn=nightfly, dc=aja, dc=com - objectClass: top - objectClass: nisNetgroup - cn: nightfly - nisNetgroupTriple: (charlemagne,peg,dunes.aja.com) - nisNetgroupTriple: (lester,-,) - memberNisNetgroup: kamakiriad - - This entry represents the netgroup nightfly, which contains two - triples (the user charlemagne, the host peg, and the domain - dunes.aja.com; and, the user lester, no host, and any domain) and one - netgroup (kamakiriad). - - Finally, an example of the nisObject class: - - dn: nisMapName=tracks, dc=dunes, dc=aja, dc=com - objectClass: top - objectClass: nisMap - nisMapName: tracks - - dn: cn=Maxine, nisMapName=tracks, dc=dunes, dc=aja, dc=com - objectClass: top - objectClass: nisObject - cn: Maxine - nisMapName: tracks - nisMapEntry: Nightfly$4 - - This entry represents the NIS map tracks, and a single map entry. - - - - - - - - - - - - - - - - - - - - - -Howard Experimental [Page 20] - -RFC 2307 Using LDAP as a Network Information Service March 1998 - - -Full Copyright Statement - - Copyright (C) The Internet Society (1998). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Howard Experimental [Page 21] - diff --git a/source4/ldap_server/devdocs/rfc2696.txt b/source4/ldap_server/devdocs/rfc2696.txt deleted file mode 100644 index 4ccc4c169a..0000000000 --- a/source4/ldap_server/devdocs/rfc2696.txt +++ /dev/null @@ -1,395 +0,0 @@ - - - - - - -Network Working Group C. Weider -Request for Comments: 2696 A. Herron -Category: Informational A. Anantha - Microsoft - T. Howes - Netscape - September 1999 - - - LDAP Control Extension for Simple Paged Results Manipulation - -Status of this Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard of any kind. Distribution of this - memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1999). All Rights Reserved. - -1. Abstract - - This document describes an LDAPv3 control extension for simple paging - of search results. This control extension allows a client to control - the rate at which an LDAP server returns the results of an LDAP - search operation. This control may be useful when the LDAP client has - limited resources and may not be able to process the entire result - set from a given LDAP query, or when the LDAP client is connected - over a low-bandwidth connection. Other operations on the result set - are not defined in this extension. This extension is not designed to - provide more sophisticated result set management. - - The key words "MUST", "SHOULD", and "MAY" used in this document are - to be interpreted as described in [bradner97]. - -2. The Control - - This control is included in the searchRequest and searchResultDone - messages as part of the controls field of the LDAPMessage, as defined - in Section 4.1.12 of [LDAPv3]. The structure of this control is as - follows: - - - - - - - - - -Weider, et al. Informational [Page 1] - -RFC 2696 LDAP Control Ext. for Simple Paged Results September 1999 - - -pagedResultsControl ::= SEQUENCE { - controlType 1.2.840.113556.1.4.319, - criticality BOOLEAN DEFAULT FALSE, - controlValue searchControlValue -} - -The searchControlValue is an OCTET STRING wrapping the BER-encoded -version of the following SEQUENCE: - -realSearchControlValue ::= SEQUENCE { - size INTEGER (0..maxInt), - -- requested page size from client - -- result set size estimate from server - cookie OCTET STRING -} - -3. Client-Server Interaction - - An LDAP client application that needs to control the rate at which - results are returned MAY specify on the searchRequest a - pagedResultsControl with size set to the desired page size and cookie - set to the zero-length string. The page size specified MAY be greater - than zero and less than the sizeLimit value specified in the - searchRequest. - - If the page size is greater than or equal to the sizeLimit value, the - server should ignore the control as the request can be satisfied in a - single page. If the server does not support this control, the server - MUST return an error of unsupportedCriticalExtension if the client - requested it as critical, otherwise the server SHOULD ignore the - control. The remainder of this section assumes the server does not - ignore the client's pagedResultsControl. - - Each time the server returns a set of results to the client when - processing a search request containing the pagedResultsControl, the - server includes the pagedResultsControl control in the - searchResultDone message. In the control returned to the client, the - size MAY be set to the server's estimate of the total number of - entries in the entire result set. Servers that cannot provide such an - estimate MAY set this size to zero (0). The cookie MUST be set to an - empty value if there are no more entries to return (i.e., the page of - search results returned was the last), or, if there are more entries - to return, to an octet string of the server's choosing,used to resume - the search. - - The client MUST consider the cookie to be an opaque structure and - make no assumptions about its internal organization or value. When - the client wants to retrieve more entries for the result set, it MUST - - - -Weider, et al. Informational [Page 2] - -RFC 2696 LDAP Control Ext. for Simple Paged Results September 1999 - - - send to the server a searchRequest with all values identical to the - initial request with the exception of the messageID, the cookie, and - optionally a modified pageSize. The cookie MUST be the octet string - on the last searchResultDone response returned by the server. - Returning cookies from previous searchResultDone responses besides - the last one is undefined, as the server implementation may restrict - cookies from being reused. - - The server will then return the next set of results from the whole - result set. This interaction will continue until the client has - retrieved all the results, in which case the cookie in the - searchResultDone field will be empty, or until the client abandons - the search sequence as described below. Once the paged search - sequence has been completed, the cookie is no longer valid and MUST - NOT be used. - - A sequence of paged search requests is abandoned by the client - sending a search request containing a pagedResultsControl with the - size set to zero (0) and the cookie set to the last cookie returned - by the server. A client MAY use the LDAP Abandon operation to - abandon one paged search request in progress, but this is discouraged - as it MAY invalidate the client's cookie. - - If, for any reason, the server cannot resume a paged search operation - for a client, then it SHOULD return the appropriate error in a - searchResultDone entry. If this occurs, both client and server should - assume the paged result set is closed and no longer resumable. - - A client may have any number of outstanding search requests pending, - any of which may have used the pagedResultsControl. A server - implementation which requires a limit on the number of outstanding - paged search requests from a given client MAY either return - unwillingToPerform when the client attempts to create a new paged - search request, or age out an older result set. If the server - implementation ages out an older paged search request, it SHOULD - return "unwilling to perform" if the client attempts to resume the - paged search that was aged out. - - A client may safely assume that all entries that satisfy a given - search query are returned once and only once during the set of paged - search requests/responses necessary to enumerate the entire result - set, unless the result set for that query has changed since the - searchRequest starting the request/response sequence was processed. - In that case, the client may receive a given entry multiple times - and/or may not receive all entries matching the given search - criteria. - - - - - -Weider, et al. Informational [Page 3] - -RFC 2696 LDAP Control Ext. for Simple Paged Results September 1999 - - -4. Example - - The following example illustrates the client-server interaction - between a client doing a search requesting a page size limit of 3. - The entire result set returned by the server contains 5 entries. - - Lines beginning with "C:" indicate requests sent from client to - server. Lines beginning with "S:" indicate responses sent from server - to client. Lines beginning with "--" are comments to help explain the - example. - - -- Client sends a search request asking for paged results - -- with a page size of 3. - C: SearchRequest + pagedResultsControl(3,"") - -- Server responds with three entries plus an indication - -- of 5 total entries in the search result and an opaque - -- cooking to be used by the client when retrieving subsequent - -- pages. - S: SearchResultEntry - S: SearchResultEntry - S: SearchResultEntry - S: SearchResultDone + pagedResultsControl(5, "opaque") - -- Client sends an identical search request (except for - -- message id), returning the opaque cooking, asking for - -- the next page. - C: SearchRequest + PagedResultsControl(3, "opaque") - -- Server responds with two entries plus an indication - -- that there are no more entries (null cookie). - S: SearchResultEntry - S: SearchResultEntry - S: SearchResultDone + pagedResultsControl(5,"") - -5. Relationship to X.500 - - For LDAP servers providing a front end to X.500 (93) directories, the - paged results control defined in this document may be mapped directly - onto the X.500 (93) PagedResultsRequest defined in X.511 [x500]. The - size parameter may be mapped onto pageSize. The cookie parameter may - be mapped onto queryReference. The sortKeys and reverse fields in - the X.500 PagedResultsRequest are excluded. - - - - - - - - - - - -Weider, et al. Informational [Page 4] - -RFC 2696 LDAP Control Ext. for Simple Paged Results September 1999 - - -6. Security Considerations - - Server implementors should consider the resources used when clients - send searches with the simple paged control, to ensure that a - client's misuse of this control does not lock out other legitimate - operations. - - Servers implementations may enforce an overriding sizelimit, to - prevent the retrieval of large portions of a publically-accessible - directory. - - Clients can, using this control, determine how many entries match a - particular filter, before the entries are returned to the client. - This may require special processing in servers which perform access - control checks on entries to determine whether the existence of the - entry can be disclosed to the client. - -7. References - - [LDAPv3] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory - Access Protocol (v3)", RFC 2251, December 1997. - - [Bradner97] Bradner, S., "Key Words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Weider, et al. Informational [Page 5] - -RFC 2696 LDAP Control Ext. for Simple Paged Results September 1999 - - -8. Authors' Addresses - - Chris Weider - Microsoft Corp. - 1 Microsoft Way - Redmond, WA 98052 - USA - - Phone: +1 425 882-8080 - EMail: cweider@microsoft.com - - - Andy Herron - Microsoft Corp. - 1 Microsoft Way - Redmond, WA 98052 - USA - - Phone: +1 425 882-8080 - EMail: andyhe@microsoft.com - - - Anoop Anantha - Microsoft Corp. - 1 Microsoft Way - Redmond, WA 98052 - USA - - Phone: +1 425 882-8080 - EMail: anoopa@microsoft.com - - - Tim Howes - Netscape Communications Corp. - 501 E. Middlefield Road - Mountain View, CA 94043 - USA - - Phone: +1 415 937-2600 - EMail: howes@netscape.com - - - - - - - - - - - -Weider, et al. Informational [Page 6] - -RFC 2696 LDAP Control Ext. for Simple Paged Results September 1999 - - -9. Full Copyright Statement - - Copyright (C) The Internet Society (1999). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Weider, et al. Informational [Page 7] - diff --git a/source4/ldap_server/devdocs/rfc2849.txt b/source4/ldap_server/devdocs/rfc2849.txt deleted file mode 100644 index 2bf645500a..0000000000 --- a/source4/ldap_server/devdocs/rfc2849.txt +++ /dev/null @@ -1,787 +0,0 @@ - - - - - - -Network Working Group G. Good -Request for Comments: 2849 iPlanet e-commerce Solutions -Category: Standards Track June 2000 - - - The LDAP Data Interchange Format (LDIF) - Technical Specification - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2000). All Rights Reserved. - -Abstract - - This document describes a file format suitable for describing - directory information or modifications made to directory information. - The file format, known as LDIF, for LDAP Data Interchange Format, is - typically used to import and export directory information between - LDAP-based directory servers, or to describe a set of changes which - are to be applied to a directory. - -Background and Intended Usage - - There are a number of situations where a common interchange format is - desirable. For example, one might wish to export a copy of the - contents of a directory server to a file, move that file to a - different machine, and import the contents into a second directory - server. - - Additionally, by using a well-defined interchange format, development - of data import tools from legacy systems is facilitated. A fairly - simple set of tools written in awk or perl can, for example, convert - a database of personnel information into an LDIF file. This file can - then be imported into a directory server, regardless of the internal - database representation the target directory server uses. - - The LDIF format was originally developed and used in the University - of Michigan LDAP implementation. The first use of LDIF was in - describing directory entries. Later, the format was expanded to - allow representation of changes to directory entries. - - - - -Good Standards Track [Page 1] - -RFC 2849 LDAP Data Interchange Format June 2000 - - - Relationship to the application/directory MIME content-type: - - The application/directory MIME content-type [1] is a general - framework and format for conveying directory information, and is - independent of any particular directory service. The LDIF format is - a simpler format which is perhaps easier to create, and may also be - used, as noted, to describe a set of changes to be applied to a - directory. - - The key words "MUST", "MUST NOT", "MAY", "SHOULD", and "SHOULD NOT" - used in this document are to be interpreted as described in [7]. - -Definition of the LDAP Data Interchange Format - - The LDIF format is used to convey directory information, or a - description of a set of changes made to directory entries. An LDIF - file consists of a series of records separated by line separators. A - record consists of a sequence of lines describing a directory entry, - or a sequence of lines describing a set of changes to a directory - entry. An LDIF file specifies a set of directory entries, or a set - of changes to be applied to directory entries, but not both. - - There is a one-to-one correlation between LDAP operations that modify - the directory (add, delete, modify, and modrdn), and the types of - changerecords described below ("add", "delete", "modify", and - "modrdn" or "moddn"). This correspondence is intentional, and - permits a straightforward translation from LDIF changerecords to - protocol operations. - -Formal Syntax Definition of LDIF - - The following definition uses the augmented Backus-Naur Form - specified in RFC 2234 [2]. - -ldif-file = ldif-content / ldif-changes - -ldif-content = version-spec 1*(1*SEP ldif-attrval-record) - -ldif-changes = version-spec 1*(1*SEP ldif-change-record) - -ldif-attrval-record = dn-spec SEP 1*attrval-spec - -ldif-change-record = dn-spec SEP *control changerecord - -version-spec = "version:" FILL version-number - - - - - - -Good Standards Track [Page 2] - -RFC 2849 LDAP Data Interchange Format June 2000 - - -version-number = 1*DIGIT - ; version-number MUST be "1" for the - ; LDIF format described in this document. - -dn-spec = "dn:" (FILL distinguishedName / - ":" FILL base64-distinguishedName) - -distinguishedName = SAFE-STRING - ; a distinguished name, as defined in [3] - -base64-distinguishedName = BASE64-UTF8-STRING - ; a distinguishedName which has been base64 - ; encoded (see note 10, below) - -rdn = SAFE-STRING - ; a relative distinguished name, defined as - ; <name-component> in [3] - -base64-rdn = BASE64-UTF8-STRING - ; an rdn which has been base64 encoded (see - ; note 10, below) - -control = "control:" FILL ldap-oid ; controlType - 0*1(1*SPACE ("true" / "false")) ; criticality - 0*1(value-spec) ; controlValue - SEP - ; (See note 9, below) - -ldap-oid = 1*DIGIT 0*1("." 1*DIGIT) - ; An LDAPOID, as defined in [4] - -attrval-spec = AttributeDescription value-spec SEP - -value-spec = ":" ( FILL 0*1(SAFE-STRING) / - ":" FILL (BASE64-STRING) / - "<" FILL url) - ; See notes 7 and 8, below - -url = <a Uniform Resource Locator, - as defined in [6]> - ; (See Note 6, below) - -AttributeDescription = AttributeType [";" options] - ; Definition taken from [4] - -AttributeType = ldap-oid / (ALPHA *(attr-type-chars)) - -options = option / (option ";" options) - - - -Good Standards Track [Page 3] - -RFC 2849 LDAP Data Interchange Format June 2000 - - -option = 1*opt-char - -attr-type-chars = ALPHA / DIGIT / "-" - -opt-char = attr-type-chars - -changerecord = "changetype:" FILL - (change-add / change-delete / - change-modify / change-moddn) - -change-add = "add" SEP 1*attrval-spec - -change-delete = "delete" SEP - -change-moddn = ("modrdn" / "moddn") SEP - "newrdn:" ( FILL rdn / - ":" FILL base64-rdn) SEP - "deleteoldrdn:" FILL ("0" / "1") SEP - 0*1("newsuperior:" - ( FILL distinguishedName / - ":" FILL base64-distinguishedName) SEP) - -change-modify = "modify" SEP *mod-spec - -mod-spec = ("add:" / "delete:" / "replace:") - FILL AttributeDescription SEP - *attrval-spec - "-" SEP - -SPACE = %x20 - ; ASCII SP, space - -FILL = *SPACE - -SEP = (CR LF / LF) - -CR = %x0D - ; ASCII CR, carriage return - -LF = %x0A - ; ASCII LF, line feed - -ALPHA = %x41-5A / %x61-7A - ; A-Z / a-z - -DIGIT = %x30-39 - ; 0-9 - - - - -Good Standards Track [Page 4] - -RFC 2849 LDAP Data Interchange Format June 2000 - - -UTF8-1 = %x80-BF - -UTF8-2 = %xC0-DF UTF8-1 - -UTF8-3 = %xE0-EF 2UTF8-1 - -UTF8-4 = %xF0-F7 3UTF8-1 - -UTF8-5 = %xF8-FB 4UTF8-1 - -UTF8-6 = %xFC-FD 5UTF8-1 - -SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-7F - ; any value <= 127 decimal except NUL, LF, - ; and CR - -SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F / - %x21-39 / %x3B / %x3D-7F - ; any value <= 127 except NUL, LF, CR, - ; SPACE, colon (":", ASCII 58 decimal) - ; and less-than ("<" , ASCII 60 decimal) - -SAFE-STRING = [SAFE-INIT-CHAR *SAFE-CHAR] - -UTF8-CHAR = SAFE-CHAR / UTF8-2 / UTF8-3 / - UTF8-4 / UTF8-5 / UTF8-6 - -UTF8-STRING = *UTF8-CHAR - -BASE64-UTF8-STRING = BASE64-STRING - ; MUST be the base64 encoding of a - ; UTF8-STRING - -BASE64-CHAR = %x2B / %x2F / %x30-39 / %x3D / %x41-5A / - %x61-7A - ; +, /, 0-9, =, A-Z, and a-z - ; as specified in [5] - -BASE64-STRING = [*(BASE64-CHAR)] - - - Notes on LDIF Syntax - - 1) For the LDIF format described in this document, the version - number MUST be "1". If the version number is absent, - implementations MAY choose to interpret the contents as an - older LDIF file format, supported by the University of - Michigan ldap-3.3 implementation [8]. - - - -Good Standards Track [Page 5] - -RFC 2849 LDAP Data Interchange Format June 2000 - - - 2) Any non-empty line, including comment lines, in an LDIF file - MAY be folded by inserting a line separator (SEP) and a SPACE. - Folding MUST NOT occur before the first character of the line. - In other words, folding a line into two lines, the first of - which is empty, is not permitted. Any line that begins with a - single space MUST be treated as a continuation of the previous - (non-empty) line. When joining folded lines, exactly one space - character at the beginning of each continued line must be - discarded. Implementations SHOULD NOT fold lines in the middle - of a multi-byte UTF-8 character. - - 3) Any line that begins with a pound-sign ("#", ASCII 35) is a - comment line, and MUST be ignored when parsing an LDIF file. - - 4) Any dn or rdn that contains characters other than those - defined as "SAFE-UTF8-CHAR", or begins with a character other - than those defined as "SAFE-INIT-UTF8-CHAR", above, MUST be - base-64 encoded. Other values MAY be base-64 encoded. Any - value that contains characters other than those defined as - "SAFE-CHAR", or begins with a character other than those - defined as "SAFE-INIT-CHAR", above, MUST be base-64 encoded. - Other values MAY be base-64 encoded. - - 5) When a zero-length attribute value is to be included directly - in an LDIF file, it MUST be represented as - AttributeDescription ":" FILL SEP. For example, "seeAlso:" - followed by a newline represents a zero-length "seeAlso" - attribute value. It is also permissible for the value - referred to by a URL to be of zero length. - - 6) When a URL is specified in an attrval-spec, the following - conventions apply: - - a) Implementations SHOULD support the file:// URL format. The - contents of the referenced file are to be included verbatim - in the interpreted output of the LDIF file. - b) Implementations MAY support other URL formats. The - semantics associated with each supported URL will be - documented in an associated Applicability Statement. - - 7) Distinguished names, relative distinguished names, and - attribute values of DirectoryString syntax MUST be valid UTF-8 - strings. Implementations that read LDIF MAY interpret files - in which these entities are stored in some other character set - encoding, but implementations MUST NOT generate LDIF content - which does not contain valid UTF-8 data. - - - - - -Good Standards Track [Page 6] - -RFC 2849 LDAP Data Interchange Format June 2000 - - - 8) Values or distinguished names that end with SPACE SHOULD be - base-64 encoded. - - 9) When controls are included in an LDIF file, implementations - MAY choose to ignore some or all of them. This may be - necessary if the changes described in the LDIF file are being - sent on an LDAPv2 connection (LDAPv2 does not support - controls), or the particular controls are not supported by the - remote server. If the criticality of a control is "true", then - the implementation MUST either include the control, or MUST - NOT send the operation to a remote server. - - 10) When an attrval-spec, distinguishedName, or rdn is base64- - encoded, the encoding rules specified in [5] are used with the - following exceptions: a) The requirement that base64 output - streams must be represented as lines of no more than 76 - characters is removed. Lines in LDIF files may only be folded - according to the folding rules described in note 2, above. b) - Base64 strings in [5] may contain characters other than those - defined in BASE64-CHAR, and are ignored. LDIF does not permit - any extraneous characters, other than those used for line - folding. - -Examples of LDAP Data Interchange Format - -Example 1: An simple LDAP file with two entries - -version: 1 -dn: cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com -objectclass: top -objectclass: person -objectclass: organizationalPerson -cn: Barbara Jensen -cn: Barbara J Jensen -cn: Babs Jensen -sn: Jensen -uid: bjensen -telephonenumber: +1 408 555 1212 -description: A big sailing fan. - -dn: cn=Bjorn Jensen, ou=Accounting, dc=airius, dc=com -objectclass: top -objectclass: person -objectclass: organizationalPerson -cn: Bjorn Jensen -sn: Jensen -telephonenumber: +1 408 555 1212 - - - - -Good Standards Track [Page 7] - -RFC 2849 LDAP Data Interchange Format June 2000 - - -Example 2: A file containing an entry with a folded attribute value - -version: 1 -dn:cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com -objectclass:top -objectclass:person -objectclass:organizationalPerson -cn:Barbara Jensen -cn:Barbara J Jensen -cn:Babs Jensen -sn:Jensen -uid:bjensen -telephonenumber:+1 408 555 1212 -description:Babs is a big sailing fan, and travels extensively in sea - rch of perfect sailing conditions. -title:Product Manager, Rod and Reel Division - -Example 3: A file containing a base-64-encoded value - -version: 1 -dn: cn=Gern Jensen, ou=Product Testing, dc=airius, dc=com -objectclass: top -objectclass: person -objectclass: organizationalPerson -cn: Gern Jensen -cn: Gern O Jensen -sn: Jensen -uid: gernj -telephonenumber: +1 408 555 1212 -description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVl -IGlzIGJhc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdG -VyIGluIGl0IChhIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQg -b3V0IG1vcmUu - -Example 4: A file containing an entries with UTF-8-encoded attribute -values, including language tags. Comments indicate the contents -of UTF-8-encoded attributes and distinguished names. - -version: 1 -dn:: b3U95Za25qWt6YOoLG89QWlyaXVz -# dn:: ou=<JapaneseOU>,o=Airius -objectclass: top -objectclass: organizationalUnit -ou:: 5Za25qWt6YOo -# ou:: <JapaneseOU> -ou;lang-ja:: 5Za25qWt6YOo -# ou;lang-ja:: <JapaneseOU> -ou;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2 - - - -Good Standards Track [Page 8] - -RFC 2849 LDAP Data Interchange Format June 2000 - - -# ou;lang-ja:: <JapaneseOU_in_phonetic_representation> -ou;lang-en: Sales -description: Japanese office - -dn:: dWlkPXJvZ2FzYXdhcmEsb3U95Za25qWt6YOoLG89QWlyaXVz -# dn:: uid=<uid>,ou=<JapaneseOU>,o=Airius -userpassword: {SHA}O3HSv1MusyL4kTjP+HKI5uxuNoM= -objectclass: top -objectclass: person -objectclass: organizationalPerson -objectclass: inetOrgPerson -uid: rogasawara -mail: rogasawara@airius.co.jp -givenname;lang-ja:: 44Ot44OJ44OL44O8 -# givenname;lang-ja:: <JapaneseGivenname> -sn;lang-ja:: 5bCP56yg5Y6f -# sn;lang-ja:: <JapaneseSn> -cn;lang-ja:: 5bCP56yg5Y6fIOODreODieODi+ODvA== -# cn;lang-ja:: <JapaneseCn> -title;lang-ja:: 5Za25qWt6YOoIOmDqOmVtw== -# title;lang-ja:: <JapaneseTitle> -preferredlanguage: ja -givenname:: 44Ot44OJ44OL44O8 -# givenname:: <JapaneseGivenname> -sn:: 5bCP56yg5Y6f -# sn:: <JapaneseSn> -cn:: 5bCP56yg5Y6fIOODreODieODi+ODvA== -# cn:: <JapaneseCn> -title:: 5Za25qWt6YOoIOmDqOmVtw== -# title:: <JapaneseTitle> -givenname;lang-ja;phonetic:: 44KN44Gp44Gr44O8 -# givenname;lang-ja;phonetic:: -<JapaneseGivenname_in_phonetic_representation_kana> -sn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJ -# sn;lang-ja;phonetic:: <JapaneseSn_in_phonetic_representation_kana> -cn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJIOOCjeOBqeOBq+ODvA== -# cn;lang-ja;phonetic:: <JapaneseCn_in_phonetic_representation_kana> -title;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2IOOBtuOBoeOCh+OBhg== -# title;lang-ja;phonetic:: -# <JapaneseTitle_in_phonetic_representation_kana> -givenname;lang-en: Rodney -sn;lang-en: Ogasawara -cn;lang-en: Rodney Ogasawara -title;lang-en: Sales, Director - - - - - - - -Good Standards Track [Page 9] - -RFC 2849 LDAP Data Interchange Format June 2000 - - -Example 5: A file containing a reference to an external file - -version: 1 -dn: cn=Horatio Jensen, ou=Product Testing, dc=airius, dc=com -objectclass: top -objectclass: person -objectclass: organizationalPerson -cn: Horatio Jensen - -cn: Horatio N Jensen -sn: Jensen -uid: hjensen -telephonenumber: +1 408 555 1212 -jpegphoto:< file:///usr/local/directory/photos/hjensen.jpg - -Example 6: A file containing a series of change records and comments - -version: 1 -# Add a new entry -dn: cn=Fiona Jensen, ou=Marketing, dc=airius, dc=com -changetype: add -objectclass: top -objectclass: person -objectclass: organizationalPerson -cn: Fiona Jensen -sn: Jensen -uid: fiona -telephonenumber: +1 408 555 1212 -jpegphoto:< file:///usr/local/directory/photos/fiona.jpg - -# Delete an existing entry -dn: cn=Robert Jensen, ou=Marketing, dc=airius, dc=com -changetype: delete - -# Modify an entry's relative distinguished name -dn: cn=Paul Jensen, ou=Product Development, dc=airius, dc=com -changetype: modrdn -newrdn: cn=Paula Jensen -deleteoldrdn: 1 - -# Rename an entry and move all of its children to a new location in -# the directory tree (only implemented by LDAPv3 servers). -dn: ou=PD Accountants, ou=Product Development, dc=airius, dc=com -changetype: modrdn -newrdn: ou=Product Development Accountants -deleteoldrdn: 0 -newsuperior: ou=Accounting, dc=airius, dc=com - - - - -Good Standards Track [Page 10] - -RFC 2849 LDAP Data Interchange Format June 2000 - - -# Modify an entry: add an additional value to the postaladdress -# attribute, completely delete the description attribute, replace -# the telephonenumber attribute with two values, and delete a specific -# value from the facsimiletelephonenumber attribute -dn: cn=Paula Jensen, ou=Product Development, dc=airius, dc=com -changetype: modify -add: postaladdress -postaladdress: 123 Anystreet $ Sunnyvale, CA $ 94086 -- - -delete: description -- -replace: telephonenumber -telephonenumber: +1 408 555 1234 -telephonenumber: +1 408 555 5678 -- -delete: facsimiletelephonenumber -facsimiletelephonenumber: +1 408 555 9876 -- - -# Modify an entry: replace the postaladdress attribute with an empty -# set of values (which will cause the attribute to be removed), and -# delete the entire description attribute. Note that the first will -# always succeed, while the second will only succeed if at least -# one value for the description attribute is present. -dn: cn=Ingrid Jensen, ou=Product Support, dc=airius, dc=com -changetype: modify -replace: postaladdress -- -delete: description -- - -Example 7: An LDIF file containing a change record with a control -version: 1 -# Delete an entry. The operation will attach the LDAPv3 -# Tree Delete Control defined in [9]. The criticality -# field is "true" and the controlValue field is -# absent, as required by [9]. -dn: ou=Product Development, dc=airius, dc=com -control: 1.2.840.113556.1.4.805 true -changetype: delete - - - - - - - - - - -Good Standards Track [Page 11] - -RFC 2849 LDAP Data Interchange Format June 2000 - - -Security Considerations - - Given typical directory applications, an LDIF file is likely to - contain sensitive personal data. Appropriate measures should be - taken to protect the privacy of those persons whose data is contained - in an LDIF file. - - Since ":<" directives can cause external content to be included when - processing an LDIF file, one should be cautious of accepting LDIF - files from external sources. A "trojan" LDIF file could name a file - with sensitive contents and cause it to be included in a directory - entry, which a hostile entity could read via LDAP. - - LDIF does not provide any method for carrying authentication - information with an LDIF file. Users of LDIF files must take care to - verify the integrity of an LDIF file received from an external - source. - -Acknowledgments - - The LDAP Interchange Format was developed as part of the University - of Michigan LDAP reference implementation, and was developed by Tim - Howes, Mark Smith, and Gordon Good. It is based in part upon work - supported by the National Science Foundation under Grant No. NCR- - 9416667. - - Members of the IETF LDAP Extensions Working group provided many - helpful suggestions. In particular, Hallvard B. Furuseth of the - University of Oslo made many significant contributions to this - document, including a thorough review and rewrite of the BNF. - -References - - [1] Howes, T. and M. Smith, "A MIME Content-Type for Directory - Information", RFC 2425, September 1998. - - [2] Crocker, D., and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 2234, November 1997. - - [3] Wahl, M., Kille, S. and T. Howes, "A String Representation of - Distinguished Names", RFC 2253, December 1997. - - [4] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access - Protocol (v3)", RFC 2251, July 1997. - - [5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail - Extensions (MIME) Part One: Format of Internet Message Bodies", - RFC 2045, November 1996. - - - -Good Standards Track [Page 12] - -RFC 2849 LDAP Data Interchange Format June 2000 - - - [6] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform - Resource Locators (URL)", RFC 1738, December 1994. - - [7] Bradner, S., "Key Words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [8] The SLAPD and SLURPD Administrators Guide. University of - Michigan, April 1996. <URL: - http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/toc.html> - - [9] M. P. Armijo, "Tree Delete Control", Work in Progress. - -Author's Address - - Gordon Good - iPlanet e-commerce Solutions - 150 Network Circle - Mailstop USCA17-201 - Santa Clara, CA 95054, USA - - Phone: +1 408 276 4351 - EMail: ggood@netscape.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Good Standards Track [Page 13] - -RFC 2849 LDAP Data Interchange Format June 2000 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2000). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Good Standards Track [Page 14] - diff --git a/source4/ldap_server/devdocs/rfc2891.txt b/source4/ldap_server/devdocs/rfc2891.txt deleted file mode 100644 index 1d91e07783..0000000000 --- a/source4/ldap_server/devdocs/rfc2891.txt +++ /dev/null @@ -1,451 +0,0 @@ - - - - - - -Network Working Group T. Howes -Request for Comments: 2891 Loudcloud -Category: Standards Track M. Wahl - Sun Microsystems - A. Anantha - Microsoft - August 2000 - - - LDAP Control Extension for Server Side Sorting of Search Results - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2000). All Rights Reserved. - -Abstract - - This document describes two LDAPv3 control extensions for server side - sorting of search results. These controls allows a client to specify - the attribute types and matching rules a server should use when - returning the results to an LDAP search request. The controls may be - useful when the LDAP client has limited functionality or for some - other reason cannot sort the results but still needs them sorted. - Other permissible controls on search operations are not defined in - this extension. - - The sort controls allow a server to return a result code for the - sorting of the results that is independent of the result code - returned for the search operation. - - The key words "MUST", "SHOULD", and "MAY" used in this document are - to be interpreted as described in [bradner97]. - - - - - - - - - - - -Howes, et al. Standards Track [Page 1] - -RFC 2891 LDAP Control Extension for Server Side Sorting August 2000 - - -1. The Controls - -1.1 Request Control - - This control is included in the searchRequest message as part of the - controls field of the LDAPMessage, as defined in Section 4.1.12 of - [LDAPv3]. - - The controlType is set to "1.2.840.113556.1.4.473". The criticality - MAY be either TRUE or FALSE (where absent is also equivalent to - FALSE) at the client's option. The controlValue is an OCTET STRING, - whose value is the BER encoding of a value of the following SEQUENCE: - - SortKeyList ::= SEQUENCE OF SEQUENCE { - attributeType AttributeDescription, - orderingRule [0] MatchingRuleId OPTIONAL, - reverseOrder [1] BOOLEAN DEFAULT FALSE } - - The SortKeyList sequence is in order of highest to lowest sort key - precedence. - - The MatchingRuleId, as defined in section 4.1.9 of [LDAPv3], SHOULD - be one that is valid for the attribute type it applies to. If it is - not, the server will return inappropriateMatching. - - Each attributeType should only occur in the SortKeyList once. If an - attributeType is included in the sort key list multiple times, the - server should return an error in the sortResult of - unwillingToPerform. - - If the orderingRule is omitted, the ordering MatchingRule defined for - use with this attribute MUST be used. - - Any conformant implementation of this control MUST allow a sort key - list with at least one key. - -1.2 Response Control - - This control is included in the searchResultDone message as part of - the controls field of the LDAPMessage, as defined in Section 4.1.12 - of [LDAPv3]. - - The controlType is set to "1.2.840.113556.1.4.474". The criticality - is FALSE (MAY be absent). The controlValue is an OCTET STRING, whose - value is the BER encoding of a value of the following SEQUENCE: - - - - - - -Howes, et al. Standards Track [Page 2] - -RFC 2891 LDAP Control Extension for Server Side Sorting August 2000 - - - SortResult ::= SEQUENCE { - sortResult ENUMERATED { - success (0), -- results are sorted - operationsError (1), -- server internal failure - timeLimitExceeded (3), -- timelimit reached before - -- sorting was completed - strongAuthRequired (8), -- refused to return sorted - -- results via insecure - -- protocol - adminLimitExceeded (11), -- too many matching entries - -- for the server to sort - noSuchAttribute (16), -- unrecognized attribute - -- type in sort key - inappropriateMatching (18), -- unrecognized or - -- inappropriate matching - -- rule in sort key - insufficientAccessRights (50), -- refused to return sorted - -- results to this client - busy (51), -- too busy to process - unwillingToPerform (53), -- unable to sort - other (80) - }, - attributeType [0] AttributeDescription OPTIONAL } - -2. Client-Server Interaction - - The sortKeyRequestControl specifies one or more attribute types and - matching rules for the results returned by a search request. The - server SHOULD return all results for the search request in the order - specified by the sort keys. If the reverseOrder field is set to TRUE, - then the entries will be presented in reverse sorted order for the - specified key. - - There are six possible scenarios that may occur as a result of the - sort control being included on the search request: - - 1 - If the server does not support this sorting control and the - client specified TRUE for the control's criticality field, then - the server MUST return unavailableCriticalExtension as a return - code in the searchResultDone message and not send back any other - results. This behavior is specified in section 4.1.12 of - [LDAPv3]. - - 2 - If the server does not support this sorting control and the - client specified FALSE for the control's criticality field, then - the server MUST ignore the sort control and process the search - request as if it were not present. This behavior is specified in - section 4.1.12 of [LDAPv3]. - - - -Howes, et al. Standards Track [Page 3] - -RFC 2891 LDAP Control Extension for Server Side Sorting August 2000 - - - 3 - If the server supports this sorting control but for some reason - cannot sort the search results using the specified sort keys and - the client specified TRUE for the control's criticality field, - then the server SHOULD do the following: return - unavailableCriticalExtension as a return code in the - searchResultDone message; include the sortKeyResponseControl in - the searchResultDone message, and not send back any search result - entries. - - 4 - If the server supports this sorting control but for some reason - cannot sort the search results using the specified sort keys and - the client specified FALSE for the control's criticality field, - then the server should return all search results unsorted and - include the sortKeyResponseControl in the searchResultDone - message. - - 5 - If the server supports this sorting control and can sort the - search results using the specified sort keys, then it should - include the sortKeyResponseControl in the searchResultDone - message with a sortResult of success. - - 6 - If the search request failed for any reason and/or there are no - searchResultEntry messages returned for the search response, then - the server SHOULD omit the sortKeyResponseControl from the - searchResultDone message. - - The client application is assured that the results are sorted in the - specified key order if and only if the result code in the - sortKeyResponseControl is success. If the server omits the - sortKeyResponseControl from the searchResultDone message, the client - SHOULD assume that the sort control was ignored by the server. - - The sortKeyResponseControl, if included by the server in the - searchResultDone message, should have the sortResult set to either - success if the results were sorted in accordance with the keys - specified in the sortKeyRequestControl or set to the appropriate - error code as to why it could not sort the data (such as - noSuchAttribute or inappropriateMatching). Optionally, the server MAY - set the attributeType to the first attribute type specified in the - SortKeyList that was in error. The client SHOULD ignore the - attributeType field if the sortResult is success. - - The server may not be able to sort the results using the specified - sort keys because it may not recognize one of the attribute types, - the matching rule associated with an attribute type is not - applicable, or none of the attributes in the search response are of - these types. Servers may also restrict the number of keys allowed in - the control, such as only supporting a single key. - - - -Howes, et al. Standards Track [Page 4] - -RFC 2891 LDAP Control Extension for Server Side Sorting August 2000 - - - Servers that chain requests to other LDAP servers should ensure that - the server satisfying the client's request sort the entire result set - prior to sending back the results. - -2.1 Behavior in a chained environment - - If a server receives a sort request, the client expects to receive a - set of sorted results. If a client submits a sort request to a server - which chains the request and gets entries from multiple servers, and - the client has set the criticality of the sort extension to TRUE, the - server MUST merge sort the results before returning them to the - client or MUST return unwillingToPerform. - -2.2 Other sort issues - - An entry that meets the search criteria may be missing one or more of - the sort keys. In that case, the entry is considered to have a value - of NULL for that key. This standard considers NULL to be a larger - value than all other valid values for that key. For example, if only - one key is specified, entries which meet the search criteria but do - not have that key collate after all the entries which do have that - key. If the reverseOrder flag is set, and only one key is specified, - entries which meet the search criteria but do not have that key - collate BEFORE all the entries which do have that key. - - If a sort key is a multi-valued attribute, and an entry happens to - have multiple values for that attribute and no other controls are - present that affect the sorting order, then the server SHOULD use the - least value (according to the ORDERING rule for that attribute). - -3. Interaction with other search controls - - When the sortKeyRequestControl control is included with the - pagedResultsControl control as specified in [LdapPaged], then the - server should send the searchResultEntry messages sorted according to - the sort keys applied to the entire result set. The server should not - simply sort each page, as this will give erroneous results to the - client. - - The sortKeyList must be present on each searchRequest message for the - paged result. It also must not change between searchRequests for the - same result set. If the server has sorted the data, then it SHOULD - send back a sortKeyResponseControl control on every searchResultDone - message for each page. This will allow clients to quickly determine - if the result set is sorted, rather than waiting to receive the - entire result set. - - - - - -Howes, et al. Standards Track [Page 5] - -RFC 2891 LDAP Control Extension for Server Side Sorting August 2000 - - -4. Security Considerations - - Implementors and administrators should be aware that allowing sorting - of results could enable the retrieval of a large number of records - from a given directory service, regardless of administrative limits - set on the maximum number of records to return. - - A client that desired to pull all records out of a directory service - could use a combination of sorting and updating of search filters to - retrieve all records in a database in small result sets, thus - circumventing administrative limits. - - This behavior can be overcome by the judicious use of permissions on - the directory entries by the administrator and by intelligent - implementations of administrative limits on the number of records - retrieved by a client. - -5. References - - [LDAPv3] Wahl, M, Kille, S. and T. Howes, "Lightweight Directory - Access Protocol (v3)", RFC 2251, December 1997. - - [Bradner97] Bradner, S., "Key Words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [LdapPaged] Weider, C., Herron, A., Anantha, A. and T. Howes, "LDAP - Control Extension for Simple Paged Results Manipulation", - RFC 2696, September 1999. - - - - - - - - - - - - - - - - - - - - - - - -Howes, et al. Standards Track [Page 6] - -RFC 2891 LDAP Control Extension for Server Side Sorting August 2000 - - -6. Authors' Addresses - - Anoop Anantha - Microsoft Corp. - 1 Microsoft Way - Redmond, WA 98052 - USA - - Phone: +1 425 882-8080 - EMail: anoopa@microsoft.com - - - Tim Howes - Loudcloud, Inc. - 615 Tasman Dr. - Sunnyvale, CA 94089 - USA - - EMail: howes@loudcloud.com - - - Mark Wahl - Sun Microsystems, Inc. - 8911 Capital of Texas Hwy Suite 4140 - Austin, TX 78759 - USA - - EMail: Mark.Wahl@sun.com - - - - - - - - - - - - - - - - - - - - - - - -Howes, et al. Standards Track [Page 7] - -RFC 2891 LDAP Control Extension for Server Side Sorting August 2000 - - -7. Full Copyright Statement - - Copyright (C) The Internet Society (2000). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Howes, et al. Standards Track [Page 8] - diff --git a/source4/ldap_server/devdocs/rfc3296.txt b/source4/ldap_server/devdocs/rfc3296.txt deleted file mode 100644 index 32cf91cca7..0000000000 --- a/source4/ldap_server/devdocs/rfc3296.txt +++ /dev/null @@ -1,787 +0,0 @@ - - - - - - -Network Working Group K. Zeilenga -Request for Comments: 3296 OpenLDAP Foundation -Category: Standards Track July 2002 - - - Named Subordinate References in - Lightweight Directory Access Protocol (LDAP) Directories - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2002). All Rights Reserved. - -Abstract - - This document details schema and protocol elements for representing - and managing named subordinate references in Lightweight Directory - Access Protocol (LDAP) Directories. - -Conventions - - Schema definitions are provided using LDAPv3 description formats - [RFC2252]. Definitions provided here are formatted (line wrapped) - for readability. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" used in - this document are to be interpreted as described in BCP 14 [RFC2119]. - -1. Background and Intended Usage - - The broadening of interest in LDAP (Lightweight Directory Access - Protocol) [RFC2251] directories beyond their use as front ends to - X.500 [X.500] directories has created a need to represent knowledge - information in a more general way. Knowledge information is - information about one or more servers maintained in another server, - used to link servers and services together. - - This document details schema and protocol elements for representing - and manipulating named subordinate references in LDAP directories. A - referral object is used to hold subordinate reference information in - - - -Zeilenga Standards Track [Page 1] - -RFC 3296 Named Subordinate References in LDAP Directories July 2002 - - - the directory. These referral objects hold one or more URIs - [RFC2396] contained in values of the ref attribute type and are used - to generate protocol referrals and continuations. - - A control, ManageDsaIT, is defined to allow manipulation of referral - and other special objects as normal objects. As the name of control - implies, it is intended to be analogous to the ManageDsaIT service - option described in X.511(97) [X.511]. - - Other forms of knowledge information are not detailed by this - document. These forms may be described in subsequent documents. - - This document details subordinate referral processing requirements - for servers. This document does not describe protocol syntax and - semantics. This is detailed in RFC 2251 [RFC2251]. - - This document does not detail use of subordinate knowledge references - to support replicated environments nor distributed operations (e.g., - chaining of operations from one server to other servers). - -2. Schema - -2.1. The referral Object Class - - A referral object is a directory entry whose structural object class - is (or is derived from) the referral object class. - - ( 2.16.840.1.113730.3.2.6 - NAME 'referral' - DESC 'named subordinate reference object' - STRUCTURAL - MUST ref ) - - The referral object class is a structural object class used to - represent a subordinate reference in the directory. The referral - object class SHOULD be used in conjunction with the extensibleObject - object class to support the naming attributes used in the entry's - Distinguished Name (DN) [RFC2253]. - - Referral objects are normally instantiated at DSEs immediately - subordinate to object entries within a naming context held by the - DSA. Referral objects are analogous to X.500 subordinate knowledge - (subr) DSEs [X.501]. - - - - - - - - -Zeilenga Standards Track [Page 2] - -RFC 3296 Named Subordinate References in LDAP Directories July 2002 - - - In the presence of a ManageDsaIT control, referral objects are - treated as normal entries as described in section 3. Note that the - ref attribute is operational and will only be returned in a search - entry response when requested. - - In the absence of a ManageDsaIT control, the content of referral - objects are used to construct referrals and search references as - described in Section 4 and, as such, the referral entries are not - themselves visible to clients. - -2.2 The ref Attribute Type - - ( 2.16.840.1.113730.3.1.34 - NAME 'ref' - DESC 'named reference - a labeledURI' - EQUALITY caseExactMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 - USAGE distributedOperation ) - - The ref attribute type has directoryString syntax and is case - sensitive. The ref attribute is multi-valued. Values placed in the - attribute MUST conform to the specification given for the labeledURI - attribute [RFC2079]. The labeledURI specification defines a format - that is a URI, optionally followed by whitespace and a label. This - document does not make use of the label portion of the syntax. - Future documents MAY enable new functionality by imposing additional - structure on the label portion of the syntax as it appears in the ref - attribute. - - If the URI contained in a ref attribute value refers to a LDAP - [RFC2251] server, it MUST be in the form of a LDAP URL [RFC2255]. - The LDAP URL SHOULD NOT contain an explicit scope specifier, filter, - attribute description list, or any extensions. The LDAP URL SHOULD - contain a non-empty DN. The handling of LDAP URLs with absent or - empty DN parts or with explicit scope specifier is not defined by - this specification. - - Other URI schemes MAY be used so long as all operations returning - referrals based upon the value could be performed. This document - does not detail use of non-LDAP URIs. This is left to future - specifications. - - The referential integrity of the URI SHOULD NOT be validated by the - server holding or returning the URI (whether as a value of the - attribute or as part of a referral result or search reference - response). - - - - - -Zeilenga Standards Track [Page 3] - -RFC 3296 Named Subordinate References in LDAP Directories July 2002 - - - When returning a referral result or search continuation, the server - MUST NOT return the separator or label portions of the attribute - values as part of the reference. When the attribute contains - multiple values, the URI part of each value is used to construct the - referral result or search continuation. - - The ref attribute values SHOULD NOT be used as a relative name- - component of an entry's DN [RFC2253]. - - This document uses the ref attribute in conjunction with the referral - object class to represent subordinate references. The ref attribute - may be used for other purposes as defined by other documents. - -3. The ManageDsaIT Control - - The client may provide the ManageDsaIT control with an operation to - indicate that the operation is intended to manage objects within the - DSA (server) Information Tree. The control causes Directory-specific - entries (DSEs), regardless of type, to be treated as normal entries - allowing clients to interrogate and update these entries using LDAP - operations. - - A client MAY specify the following control when issuing an add, - compare, delete, modify, modifyDN, search request or an extended - operation for which the control is defined. - - The control type is 2.16.840.1.113730.3.4.2. The control criticality - may be TRUE or, if FALSE, absent. The control value is absent. - - When the control is present in the request, the server SHALL NOT - generate a referral or continuation reference based upon information - held in referral objects and instead SHALL treat the referral object - as a normal entry. The server, however, is still free to return - referrals for other reasons. When not present, referral objects - SHALL be handled as described above. - - The control MAY cause other objects to be treated as normal entries - as defined by subsequent documents. - -4. Named Subordinate References - - A named subordinate reference is constructed by instantiating a - referral object in the referencing server with ref attribute values - which point to the corresponding subtree maintained in the referenced - server. In general, the name of the referral object is the same as - the referenced object and this referenced object is a context prefix - [X.501]. - - - - -Zeilenga Standards Track [Page 4] - -RFC 3296 Named Subordinate References in LDAP Directories July 2002 - - - That is, if server A holds "DC=example,DC=net" and server B holds - "DC=sub,DC=example,DC=net", server A may contain a referral object - named "DC=sub,DC=example,DC=net" which contains a ref attribute with - value of "ldap://B/DC=sub,DC=example,DC=net". - - dn: DC=sub,DC=example,DC=net - dc: sub - ref: ldap://B/DC=sub,DC=example,DC=net - objectClass: referral - objectClass: extensibleObject - - Typically the DN of the referral object and the DN of the object in - the referenced server are the same. - - If the ref attribute has multiple values, all the DNs contained - within the LDAP URLs SHOULD be equivalent. Administrators SHOULD - avoid configuring naming loops using referrals. - - Named references MUST be treated as normal entries if the request - includes the ManageDsaIT control as described in section 3. - -5. Scenarios - - The following sections contain specifications of how referral objects - should be used in different scenarios followed by examples that - illustrate that usage. The scenarios described here consist of - referral object handling when finding target of a non-search - operation, when finding the base of a search operation, and when - generating search references. Lastly, other operation processing - considerations are presented. - - It is to be noted that, in this document, a search operation is - conceptually divided into two distinct, sequential phases: (1) - finding the base object where the search is to begin, and (2) - performing the search itself. The first phase is similar to, but not - the same as, finding the target of a non-search operation. - - It should also be noted that the ref attribute may have multiple - values and, where these sections refer to a single ref attribute - value, multiple ref attribute values may be substituted and SHOULD be - processed and returned (in any order) as a group in a referral or - search reference in the same way as described for a single ref - attribute value. - - Search references returned for a given request may be returned in any - order. - - - - - -Zeilenga Standards Track [Page 5] - -RFC 3296 Named Subordinate References in LDAP Directories July 2002 - - -5.1. Example Configuration - - For example, suppose the contacted server (hosta) holds the entry - "O=MNN,C=WW" and the entry "CN=Manager,O=MNN,C=WW" and the following - referral objects: - - dn: OU=People,O=MNN,C=WW - ou: People - ref: ldap://hostb/OU=People,O=MNN,C=US - ref: ldap://hostc/OU=People,O=MNN,C=US - objectClass: referral - objectClass: extensibleObject - - dn: OU=Roles,O=MNN,C=WW - ou: Roles - ref: ldap://hostd/OU=Roles,O=MNN,C=WW - objectClass: referral - objectClass: extensibleObject - - The first referral object provides the server with the knowledge that - subtree "OU=People,O=MNN,C=WW" is held by hostb and hostc (e.g., one - is the master and the other a shadow). The second referral object - provides the server with the knowledge that the subtree - "OU=Roles,O=MNN,C=WW" is held by hostd. - - Also, in the context of this document, the "nearest naming context" - means the deepest context which the object is within. That is, if - the object is within multiple naming contexts, the nearest naming - context is the one which is subordinate to all other naming contexts - the object is within. - -5.2. Target Object Considerations - - This section details referral handling for add, compare, delete, - modify, and modify DN operations. If the client requests any of - these operations, there are four cases that the server must handle - with respect to the target object. - - The DN part MUST be modified such that it refers to the appropriate - target in the referenced server (as detailed below). Even where the - DN to be returned is the same as the target DN, the DN part SHOULD - NOT be trimmed. - - In cases where the URI to be returned is a LDAP URL, the server - SHOULD trim any present scope, filter, or attribute list from the URI - before returning it. Critical extensions MUST NOT be trimmed or - modified. - - - - -Zeilenga Standards Track [Page 6] - -RFC 3296 Named Subordinate References in LDAP Directories July 2002 - - - Case 1: The target object is not held by the server and is not within - or subordinate to any naming context nor subordinate to any - referral object held by the server. - - The server SHOULD process the request normally as appropriate for - a non-existent base which is not within any naming context of the - server (generally return noSuchObject or a referral based upon - superior knowledge reference information). This document does not - detail management or processing of superior knowledge reference - information. - - Case 2: The target object is held by the server and is a referral - object. - - The server SHOULD return the URI value contained in the ref - attribute of the referral object appropriately modified as - described above. - - Example: If the client issues a modify request for the target object - of "OU=People,O=MNN,c=WW", the server will return: - - ModifyResponse (referral) { - ldap://hostb/OU=People,O=MNN,C=WW - ldap://hostc/OU=People,O=MNN,C=WW - } - - Case 3: The target object is not held by the server, but the nearest - naming context contains no referral object which the target object - is subordinate to. - - If the nearest naming context contains no referral object which - the target is subordinate to, the server SHOULD process the - request as appropriate for a nonexistent target (generally return - noSuchObject). - - Case 4: The target object is not held by the server, but the nearest - naming context contains a referral object which the target object - is subordinate to. - - If a client requests an operation for which the target object is - not held by the server and the nearest naming context contains a - referral object which the target object is subordinate to, the - server SHOULD return a referral response constructed from the URI - portion of the ref value of the referral object. - - - - - - - -Zeilenga Standards Track [Page 7] - -RFC 3296 Named Subordinate References in LDAP Directories July 2002 - - - Example: If the client issues an add request where the target object - has a DN of "CN=Manager,OU=Roles,O=MNN,C=WW", the server will - return: - - AddResponse (referral) { - ldap://hostd/CN=Manager,OU=Roles,O=MNN,C=WW" - } - - Note that the DN part of the LDAP URL is modified such that it - refers to the appropriate entry in the referenced server. - -5.3. Base Object Considerations - - This section details referral handling for base object processing - within search operations. Like target object considerations for - non-search operations, there are the four cases. - - In cases where the URI to be returned is a LDAP URL, the server MUST - provide an explicit scope specifier from the LDAP URL prior to - returning it. In addition, the DN part MUST be modified such that it - refers to the appropriate target in the referenced server (as - detailed below). - - If aliasing dereferencing was necessary in finding the referral - object, the DN part of the URI MUST be replaced with the base DN as - modified by the alias dereferencing such that the return URL refers - to the new target object per [RFC2251, 4.1.11]. - - Critical extensions MUST NOT be trimmed nor modified. - - Case 1: The base object is not held by the server and is not within - nor subordinate to any naming context held by the server. - - The server SHOULD process the request normally as appropriate for - a non-existent base which not within any naming context of the - server (generally return a superior referral or noSuchObject). - This document does not detail management or processing of superior - knowledge references. - - Case 2: The base object is held by the server and is a referral - object. - - The server SHOULD return the URI value contained in the ref - attribute of the referral object appropriately modified as - described above. - - - - - - -Zeilenga Standards Track [Page 8] - -RFC 3296 Named Subordinate References in LDAP Directories July 2002 - - - Example: If the client issues a subtree search in which the base - object is "OU=Roles,O=MNN,C=WW", the server will return - - SearchResultDone (referral) { - ldap://hostd/OU=Roles,O=MNN,C=WW??sub - } - - If the client were to issue a base or oneLevel search instead of - subtree, the returned LDAP URL would explicitly specify "base" or - "one", respectively, instead of "sub". - - Case 3: The base object is not held by the server, but the nearest - naming context contains no referral object which the base object - is subordinate to. - - If the nearest naming context contains no referral object which - the base is subordinate to, the request SHOULD be processed - normally as appropriate for a nonexistent base (generally return - noSuchObject). - - Case 4: The base object is not held by the server, but the nearest - naming context contains a referral object which the base object is - subordinate to. - - If a client requests an operation for which the target object is - not held by the server and the nearest naming context contains a - referral object which the target object is subordinate to, the - server SHOULD return a referral response which is constructed from - the URI portion of the ref value of the referral object. - - Example: If the client issues a base search request for - "CN=Manager,OU=Roles,O=MNN,C=WW", the server will return - - SearchResultDone (referral) { - ldap://hostd/CN=Manager,OU=Roles,O=MNN,C=WW??base" - } - - If the client were to issue a subtree or oneLevel search instead - of subtree, the returned LDAP URL would explicitly specify "sub" - or "one", respectively, instead of "base". - - Note that the DN part of the LDAP URL is modified such that it - refers to the appropriate entry in the referenced server. - - - - - - - - -Zeilenga Standards Track [Page 9] - -RFC 3296 Named Subordinate References in LDAP Directories July 2002 - - -5.4. Search Continuation Considerations - - For search operations, once the base object has been found and - determined not to be a referral object, the search may progress. Any - entry matching the filter and scope of the search which is not a - referral object is returned to the client normally as described in - [RFC2251]. - - For each referral object within the requested scope, regardless of - the search filter, the server SHOULD return a SearchResultReference - which is constructed from the URI component of values of the ref - attribute. If the URI component is not a LDAP URL, it should be - returned as is. If the LDAP URL's DN part is absent or empty, the DN - part must be modified to contain the DN of the referral object. If - the URI component is a LDAP URL, the URI SHOULD be modified to add an - explicit scope specifier. - - Subtree Example: - - If a client requests a subtree search of "O=MNN,C=WW", then in - addition to any entries within scope which match the filter, hosta - will also return two search references as the two referral objects - are within scope. One possible response might be: - - SearchEntry for O=MNN,C=WW - SearchResultReference { - ldap://hostb/OU=People,O=MNN,C=WW??sub - ldap://hostc/OU=People,O=MNN,C=WW??sub - } - SearchEntry for CN=Manager,O=MNN,C=WW - SearchResultReference { - ldap://hostd/OU=Roles,O=MNN,C=WW??sub - } - SearchResultDone (success) - - One Level Example: - - If a client requests a one level search of "O=MNN,C=WW" then, in - addition to any entries one level below the "O=MNN,C=WW" entry - matching the filter, the server will also return two search - references as the two referral objects are within scope. One - possible sequence is shown: - - - - - - - - - -Zeilenga Standards Track [Page 10] - -RFC 3296 Named Subordinate References in LDAP Directories July 2002 - - - SearchResultReference { - ldap://hostb/OU=People,O=MNN,C=WW??base - ldap://hostc/OU=People,O=MNN,C=WW??base - } - SearchEntry for CN=Manager,O=MNN,C=WW - SearchResultReference { - ldap://hostd/OU=Roles,O=MNN,C=WW??base - } - SearchResultDone (success) - - Note: Unlike the examples in Section 4.5.3.1 of RFC 2251, the LDAP - URLs returned with the SearchResultReference messages contain, as - required by this specification, an explicit scope specifier. - -5.6. Other Considerations - - This section details processing considerations for other operations. - -5.6.1 Bind - - Servers SHOULD NOT return referral result code if the bind name (or - authentication identity or authorization identity) is (or is - subordinate to) a referral object but MAY use the knowledge - information to process the bind request (such as in support a future - distributed operation specification). Where the server makes no use - of the knowledge information, the server processes the request - normally as appropriate for a non-existent authentication or - authorization identity (e.g., return invalidCredentials). - -5.6.2 Modify DN - - If the newSuperior is a referral object or is subordinate to a - referral object, the server SHOULD return affectsMultipleDSAs. If - the newRDN already exists but is a referral object, the server SHOULD - return affectsMultipleDSAs instead of entryAlreadyExists. - -6. Security Considerations - - This document defines mechanisms that can be used to tie LDAP (and - other) servers together. The information used to tie services - together should be protected from unauthorized modification. If the - server topology information is not public information, it should be - protected from unauthorized disclosure as well. - - - - - - - - -Zeilenga Standards Track [Page 11] - -RFC 3296 Named Subordinate References in LDAP Directories July 2002 - - -7. Acknowledgments - - This document borrows heavily from previous work by IETF LDAPext - Working Group. In particular, this document is based upon "Named - Referral in LDAP Directories" (an expired Internet Draft) by - Christopher Lukas, Tim Howes, Michael Roszkowski, Mark C. Smith, and - Mark Wahl. - -8. Normative References - - [RFC2079] Smith, M., "Definition of an X.500 Attribute Type and an - Object Class to Hold Uniform Resource Identifiers (URIs)", - RFC 2079, January 1997. - - [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory - Access Protocol (v3)", RFC 2251, December 1997. - - [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, - "Lightweight Directory Access Protocol (v3): Attribute - Syntax Definitions", RFC 2252, December 1997. - - [RFC2253] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory - Access Protocol (v3): UTF-8 String Representation of - Distinguished Names", RFC 2253, December 1997. - - [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, - December, 1997. - - [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform - Resource Identifiers (URI): Generic Syntax", RFC 2396, - August 1998. - - [X.501] ITU-T, "The Directory: Models", X.501, 1993. - -9. Informative References - - [X.500] ITU-T, "The Directory: Overview of Concepts, Models, and - Services", X.500, 1993. - - [X.511] ITU-T, "The Directory: Abstract Service Definition", X.500, - 1997. - - - - - - - -Zeilenga Standards Track [Page 12] - -RFC 3296 Named Subordinate References in LDAP Directories July 2002 - - -10. Author's Address - - Kurt D. Zeilenga - OpenLDAP Foundation - - EMail: Kurt@OpenLDAP.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Zeilenga Standards Track [Page 13] - -RFC 3296 Named Subordinate References in LDAP Directories July 2002 - - -11. Full Copyright Statement - - Copyright (C) The Internet Society (2002). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Zeilenga Standards Track [Page 14] - diff --git a/source4/ldap_server/devdocs/rfc4510.txt b/source4/ldap_server/devdocs/rfc4510.txt deleted file mode 100644 index 8ba41d1d93..0000000000 --- a/source4/ldap_server/devdocs/rfc4510.txt +++ /dev/null @@ -1,395 +0,0 @@ - - - - - - -Network Working Group K. Zeilenga, Ed. -Request for Comments: 4510 OpenLDAP Foundation -Obsoletes: 2251, 2252, 2253, 2254, 2255, June 2006 - 2256, 2829, 2830, 3377, 3771 -Category: Standards Track - - - Lightweight Directory Access Protocol (LDAP): - Technical Specification Road Map - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - The Lightweight Directory Access Protocol (LDAP) is an Internet - protocol for accessing distributed directory services that act in - accordance with X.500 data and service models. This document - provides a road map of the LDAP Technical Specification. - -1. The LDAP Technical Specification - - The technical specification detailing version 3 of the Lightweight - Directory Access Protocol (LDAP), an Internet Protocol, consists of - this document and the following documents: - - LDAP: The Protocol [RFC4511] - LDAP: Directory Information Models [RFC4512] - LDAP: Authentication Methods and Security Mechanisms [RFC4513] - LDAP: String Representation of Distinguished Names [RFC4514] - LDAP: String Representation of Search Filters [RFC4515] - LDAP: Uniform Resource Locator [RFC4516] - LDAP: Syntaxes and Matching Rules [RFC4517] - LDAP: Internationalized String Preparation [RFC4518] - LDAP: Schema for User Applications [RFC4519] - - - - - - - -Zeilenga Standards Track [Page 1] - -RFC 4510 LDAP: TS Road Map June 2006 - - - The terms "LDAP" and "LDAPv3" are commonly used to refer informally - to the protocol specified by this technical specification. The LDAP - suite, as defined here, should be formally identified in other - documents by a normative reference to this document. - - LDAP is an extensible protocol. Extensions to LDAP may be specified - in other documents. Nomenclature denoting such combinations of - LDAP-plus-extensions is not defined by this document but may be - defined in some future document(s). Extensions are expected to be - truly optional. Considerations for the LDAP extensions described in - BCP 118, RFC 4521 [RFC4521] fully apply to this revision of the LDAP - Technical Specification. - - IANA (Internet Assigned Numbers Authority) considerations for LDAP - described in BCP 64, RFC 4520 [RFC4520] apply fully to this revision - of the LDAP technical specification. - -1.1. Conventions - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in BCP 14 [RFC2119]. - -2. Relationship to X.500 - - This technical specification defines LDAP in terms of [X.500] as an - X.500 access mechanism. An LDAP server MUST act in accordance with - the X.500 (1993) series of International Telecommunication Union - - Telecommunication Standardization (ITU-T) Recommendations when - providing the service. However, it is not required that an LDAP - server make use of any X.500 protocols in providing this service. - For example, LDAP can be mapped onto any other directory system so - long as the X.500 data and service models [X.501][X.511], as used in - LDAP, are not violated in the LDAP interface. - - This technical specification explicitly incorporates portions of - X.500(93). Later revisions of X.500 do not automatically apply to - this technical specification. - -3. Relationship to Obsolete Specifications - - This technical specification, as defined in Section 1, obsoletes - entirely the previously defined LDAP technical specification defined - in RFC 3377 (and consisting of RFCs 2251-2256, 2829, 2830, 3771, and - 3377 itself). The technical specification was significantly - reorganized. - - - - - -Zeilenga Standards Track [Page 2] - -RFC 4510 LDAP: TS Road Map June 2006 - - - This document replaces RFC 3377 as well as Section 3.3 of RFC 2251. - [RFC4512] replaces portions of RFC 2251, RFC 2252, and RFC 2256. - [RFC4511] replaces the majority RFC 2251, portions of RFC 2252, and - all of RFC 3771. [RFC4513] replaces RFC 2829, RFC 2830, and portions - of RFC 2251. [RFC4517] replaces the majority of RFC 2252 and - portions of RFC 2256. [RFC4519] replaces the majority of RFC 2256. - [RFC4514] replaces RFC 2253. [RFC4515] replaces RFC 2254. [RFC4516] - replaces RFC 2255. - - [RFC4518] is new to this revision of the LDAP technical - specification. - - Each document of this specification contains appendices summarizing - changes to all sections of the specifications they replace. Appendix - A.1 of this document details changes made to RFC 3377. Appendix A.2 - of this document details changes made to Section 3.3 of RFC 2251. - - Additionally, portions of this technical specification update and/or - replace a number of other documents not listed above. These - relationships are discussed in the documents detailing these portions - of this technical specification. - -4. Security Considerations - - LDAP security considerations are discussed in each document - comprising the technical specification. - -5. Acknowledgements - - This document is based largely on RFC 3377 by J. Hodges and R. - Morgan, a product of the LDAPBIS and LDAPEXT Working Groups. The - document also borrows from RFC 2251 by M. Wahl, T. Howes, and S. - Kille, a product of the ASID Working Group. - - This document is a product of the IETF LDAPBIS Working Group. - - - - - - - - - - - - - - - - -Zeilenga Standards Track [Page 3] - -RFC 4510 LDAP: TS Road Map June 2006 - - -6. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access - Protocol (LDAP): The Protocol", RFC 4511, June 2006. - - [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP): Directory Information Models", RFC 4512, June - 2006. - - [RFC4513] Harrison, R., Ed., "Lightweight Directory Access - Protocol (LDAP): Authentication Methods and Security - Mechanisms", RFC 4513, June 2006. - - [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access - Protocol (LDAP): String Representation of Distinguished - Names", RFC 4514, June 2006. - - [RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory - Access Protocol (LDAP): String Representation of Search - Filters", RFC 4515, June 2006. - - [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory - Access Protocol (LDAP): Uniform Resource Locator", RFC - 4516, June 2006. - - [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol - (LDAP): Syntaxes and Matching Rules", RFC 4517, June - 2006. - - [RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP): Internationalized String Preparation", RFC - 4518, June 2006. - - [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access - Protocol (LDAP): Schema for User Applications", RFC - 4519, June 2006. - - [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority - (IANA) Considerations for the Lightweight Directory - Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. - - [RFC4521] Zeilenga, K., "Considerations for LDAP Extensions", BCP - 118, RFC 4521, June 2006. - - - - - -Zeilenga Standards Track [Page 4] - -RFC 4510 LDAP: TS Road Map June 2006 - - - [X.500] International Telecommunication Union - - Telecommunication Standardization Sector, "The - Directory -- Overview of concepts, models and - services", X.500(1993) (also ISO/IEC 9594-1:1994). - - [X.501] International Telecommunication Union - - Telecommunication Standardization Sector, "The - Directory -- Models", X.501(1993) (also ISO/IEC 9594- - 2:1994). - - [X.511] International Telecommunication Union - - Telecommunication Standardization Sector, "The - Directory: Abstract Service Definition", X.511(1993) - (also ISO/IEC 9594-3:1993). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Zeilenga Standards Track [Page 5] - -RFC 4510 LDAP: TS Road Map June 2006 - - -Appendix A. Changes to Previous Documents - - This appendix outlines changes this document makes relative to the - documents it replaces (in whole or in part). - -A.1. Changes to RFC 3377 - - This document is nearly a complete rewrite of RFC 3377 as much of the - material of RFC 3377 is no longer applicable. The changes include - redefining the terms "LDAP" and "LDAPv3" to refer to this revision of - the technical specification. - -A.2. Changes to Section 3.3 of RFC 2251 - - The section was modified slightly (the word "document" was replaced - with "technical specification") to clarify that it applies to the - entire LDAP technical specification. - -Author's Address - - Kurt D. Zeilenga - OpenLDAP Foundation - - EMail: Kurt@OpenLDAP.org - - - - - - - - - - - - - - - - - - - - - - - - - - - -Zeilenga Standards Track [Page 6] - -RFC 4510 LDAP: TS Road Map June 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Zeilenga Standards Track [Page 7] - diff --git a/source4/ldap_server/devdocs/rfc4511.txt b/source4/ldap_server/devdocs/rfc4511.txt deleted file mode 100644 index 8041f30544..0000000000 --- a/source4/ldap_server/devdocs/rfc4511.txt +++ /dev/null @@ -1,3811 +0,0 @@ - - - - - - -Network Working Group J. Sermersheim, Ed. -Request for Comments: 4511 Novell, Inc. -Obsoletes: 2251, 2830, 3771 June 2006 -Category: Standards Track - - - Lightweight Directory Access Protocol (LDAP): The Protocol - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document describes the protocol elements, along with their - semantics and encodings, of the Lightweight Directory Access Protocol - (LDAP). LDAP provides access to distributed directory services that - act in accordance with X.500 data and service models. These protocol - elements are based on those described in the X.500 Directory Access - Protocol (DAP). - -Table of Contents - - 1. Introduction ....................................................3 - 1.1. Relationship to Other LDAP Specifications ..................3 - 2. Conventions .....................................................3 - 3. Protocol Model ..................................................4 - 3.1. Operation and LDAP Message Layer Relationship ..............5 - 4. Elements of Protocol ............................................5 - 4.1. Common Elements ............................................5 - 4.1.1. Message Envelope ....................................6 - 4.1.2. String Types ........................................7 - 4.1.3. Distinguished Name and Relative Distinguished Name ..8 - 4.1.4. Attribute Descriptions ..............................8 - 4.1.5. Attribute Value .....................................8 - 4.1.6. Attribute Value Assertion ...........................9 - 4.1.7. Attribute and PartialAttribute ......................9 - 4.1.8. Matching Rule Identifier ...........................10 - 4.1.9. Result Message .....................................10 - 4.1.10. Referral ..........................................12 - - - -Sermersheim Standards Track [Page 1] - -RFC 4511 LDAPv3 June 2006 - - - 4.1.11. Controls ..........................................14 - 4.2. Bind Operation ............................................16 - 4.2.1. Processing of the Bind Request .....................17 - 4.2.2. Bind Response ......................................18 - 4.3. Unbind Operation ..........................................18 - 4.4. Unsolicited Notification ..................................19 - 4.4.1. Notice of Disconnection ............................19 - 4.5. Search Operation ..........................................20 - 4.5.1. Search Request .....................................20 - 4.5.2. Search Result ......................................27 - 4.5.3. Continuation References in the Search Result .......28 - 4.6. Modify Operation ..........................................31 - 4.7. Add Operation .............................................33 - 4.8. Delete Operation ..........................................34 - 4.9. Modify DN Operation .......................................34 - 4.10. Compare Operation ........................................36 - 4.11. Abandon Operation ........................................36 - 4.12. Extended Operation .......................................37 - 4.13. IntermediateResponse Message .............................39 - 4.13.1. Usage with LDAP ExtendedRequest and - ExtendedResponse ..................................40 - 4.13.2. Usage with LDAP Request Controls ..................40 - 4.14. StartTLS Operation .......................................40 - 4.14.1. StartTLS Request ..................................40 - 4.14.2. StartTLS Response .................................41 - 4.14.3. Removal of the TLS Layer ..........................41 - 5. Protocol Encoding, Connection, and Transfer ....................42 - 5.1. Protocol Encoding .........................................42 - 5.2. Transmission Control Protocol (TCP) .......................43 - 5.3. Termination of the LDAP session ...........................43 - 6. Security Considerations ........................................43 - 7. Acknowledgements ...............................................45 - 8. Normative References ...........................................46 - 9. Informative References .........................................48 - 10. IANA Considerations ...........................................48 - Appendix A. LDAP Result Codes .....................................49 - A.1. Non-Error Result Codes ....................................49 - A.2. Result Codes ..............................................49 - Appendix B. Complete ASN.1 Definition .............................54 - Appendix C. Changes ...............................................60 - C.1. Changes Made to RFC 2251 ..................................60 - C.2. Changes Made to RFC 2830 ..................................66 - C.3. Changes Made to RFC 3771 ..................................66 - - - - - - - - -Sermersheim Standards Track [Page 2] - -RFC 4511 LDAPv3 June 2006 - - -1. Introduction - - The Directory is "a collection of open systems cooperating to provide - directory services" [X.500]. A directory user, which may be a human - or other entity, accesses the Directory through a client (or - Directory User Agent (DUA)). The client, on behalf of the directory - user, interacts with one or more servers (or Directory System Agents - (DSA)). Clients interact with servers using a directory access - protocol. - - This document details the protocol elements of the Lightweight - Directory Access Protocol (LDAP), along with their semantics. - Following the description of protocol elements, it describes the way - in which the protocol elements are encoded and transferred. - -1.1. Relationship to Other LDAP Specifications - - This document is an integral part of the LDAP Technical Specification - [RFC4510], which obsoletes the previously defined LDAP technical - specification, RFC 3377, in its entirety. - - This document, together with [RFC4510], [RFC4513], and [RFC4512], - obsoletes RFC 2251 in its entirety. Section 3.3 is obsoleted by - [RFC4510]. Sections 4.2.1 (portions) and 4.2.2 are obsoleted by - [RFC4513]. Sections 3.2, 3.4, 4.1.3 (last paragraph), 4.1.4, 4.1.5, - 4.1.5.1, 4.1.9 (last paragraph), 5.1, 6.1, and 6.2 (last paragraph) - are obsoleted by [RFC4512]. The remainder of RFC 2251 is obsoleted - by this document. Appendix C.1 summarizes substantive changes in the - remainder. - - This document obsoletes RFC 2830, Sections 2 and 4. The remainder of - RFC 2830 is obsoleted by [RFC4513]. Appendix C.2 summarizes - substantive changes to the remaining sections. - - This document also obsoletes RFC 3771 in entirety. - -2. Conventions - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are - to be interpreted as described in [RFC2119]. - - Character names in this document use the notation for code points and - names from the Unicode Standard [Unicode]. For example, the letter - "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>. - - - - - - -Sermersheim Standards Track [Page 3] - -RFC 4511 LDAPv3 June 2006 - - - Note: a glossary of terms used in Unicode can be found in [Glossary]. - Information on the Unicode character encoding model can be found in - [CharModel]. - - The term "transport connection" refers to the underlying transport - services used to carry the protocol exchange, as well as associations - established by these services. - - The term "TLS layer" refers to Transport Layer Security (TLS) - services used in providing security services, as well as associations - established by these services. - - The term "SASL layer" refers to Simply Authentication and Security - Layer (SASL) services used in providing security services, as well as - associations established by these services. - - The term "LDAP message layer" refers to the LDAP Message Protocol - Data Unit (PDU) services used in providing directory services, as - well as associations established by these services. - - The term "LDAP session" refers to combined services (transport - connection, TLS layer, SASL layer, LDAP message layer) and their - associations. - - See the table in Section 5 for an illustration of these four terms. - -3. Protocol Model - - The general model adopted by this protocol is one of clients - performing protocol operations against servers. In this model, a - client transmits a protocol request describing the operation to be - performed to a server. The server is then responsible for performing - the necessary operation(s) in the Directory. Upon completion of an - operation, the server typically returns a response containing - appropriate data to the requesting client. - - Protocol operations are generally independent of one another. Each - operation is processed as an atomic action, leaving the directory in - a consistent state. - - Although servers are required to return responses whenever such - responses are defined in the protocol, there is no requirement for - synchronous behavior on the part of either clients or servers. - Requests and responses for multiple operations generally may be - exchanged between a client and server in any order. If required, - synchronous behavior may be controlled by client applications. - - - - - -Sermersheim Standards Track [Page 4] - -RFC 4511 LDAPv3 June 2006 - - - The core protocol operations defined in this document can be mapped - to a subset of the X.500 (1993) Directory Abstract Service [X.511]. - However, there is not a one-to-one mapping between LDAP operations - and X.500 Directory Access Protocol (DAP) operations. Server - implementations acting as a gateway to X.500 directories may need to - make multiple DAP requests to service a single LDAP request. - -3.1. Operation and LDAP Message Layer Relationship - - Protocol operations are exchanged at the LDAP message layer. When - the transport connection is closed, any uncompleted operations at the - LDAP message layer are abandoned (when possible) or are completed - without transmission of the response (when abandoning them is not - possible). Also, when the transport connection is closed, the client - MUST NOT assume that any uncompleted update operations have succeeded - or failed. - -4. Elements of Protocol - - The protocol is described using Abstract Syntax Notation One - ([ASN.1]) and is transferred using a subset of ASN.1 Basic Encoding - Rules ([BER]). Section 5 specifies how the protocol elements are - encoded and transferred. - - In order to support future extensions to this protocol, extensibility - is implied where it is allowed per ASN.1 (i.e., sequence, set, - choice, and enumerated types are extensible). In addition, ellipses - (...) have been supplied in ASN.1 types that are explicitly - extensible as discussed in [RFC4520]. Because of the implied - extensibility, clients and servers MUST (unless otherwise specified) - ignore trailing SEQUENCE components whose tags they do not recognize. - - Changes to the protocol other than through the extension mechanisms - described here require a different version number. A client - indicates the version it is using as part of the BindRequest, - described in Section 4.2. If a client has not sent a Bind, the - server MUST assume the client is using version 3 or later. - - Clients may attempt to determine the protocol versions a server - supports by reading the 'supportedLDAPVersion' attribute from the - root DSE (DSA-Specific Entry) [RFC4512]. - -4.1. Common Elements - - This section describes the LDAPMessage envelope Protocol Data Unit - (PDU) format, as well as data type definitions, which are used in the - protocol operations. - - - - -Sermersheim Standards Track [Page 5] - -RFC 4511 LDAPv3 June 2006 - - -4.1.1. Message Envelope - - For the purposes of protocol exchanges, all protocol operations are - encapsulated in a common envelope, the LDAPMessage, which is defined - as follows: - - LDAPMessage ::= SEQUENCE { - messageID MessageID, - protocolOp CHOICE { - bindRequest BindRequest, - bindResponse BindResponse, - unbindRequest UnbindRequest, - searchRequest SearchRequest, - searchResEntry SearchResultEntry, - searchResDone SearchResultDone, - searchResRef SearchResultReference, - modifyRequest ModifyRequest, - modifyResponse ModifyResponse, - addRequest AddRequest, - addResponse AddResponse, - delRequest DelRequest, - delResponse DelResponse, - modDNRequest ModifyDNRequest, - modDNResponse ModifyDNResponse, - compareRequest CompareRequest, - compareResponse CompareResponse, - abandonRequest AbandonRequest, - extendedReq ExtendedRequest, - extendedResp ExtendedResponse, - ..., - intermediateResponse IntermediateResponse }, - controls [0] Controls OPTIONAL } - - MessageID ::= INTEGER (0 .. maxInt) - - maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- - - The ASN.1 type Controls is defined in Section 4.1.11. - - The function of the LDAPMessage is to provide an envelope containing - common fields required in all protocol exchanges. At this time, the - only common fields are the messageID and the controls. - - If the server receives an LDAPMessage from the client in which the - LDAPMessage SEQUENCE tag cannot be recognized, the messageID cannot - be parsed, the tag of the protocolOp is not recognized as a request, - or the encoding structures or lengths of data fields are found to be - incorrect, then the server SHOULD return the Notice of Disconnection - - - -Sermersheim Standards Track [Page 6] - -RFC 4511 LDAPv3 June 2006 - - - described in Section 4.4.1, with the resultCode set to protocolError, - and MUST immediately terminate the LDAP session as described in - Section 5.3. - - In other cases where the client or server cannot parse an LDAP PDU, - it SHOULD abruptly terminate the LDAP session (Section 5.3) where - further communication (including providing notice) would be - pernicious. Otherwise, server implementations MUST return an - appropriate response to the request, with the resultCode set to - protocolError. - -4.1.1.1. MessageID - - All LDAPMessage envelopes encapsulating responses contain the - messageID value of the corresponding request LDAPMessage. - - The messageID of a request MUST have a non-zero value different from - the messageID of any other request in progress in the same LDAP - session. The zero value is reserved for the unsolicited notification - message. - - Typical clients increment a counter for each request. - - A client MUST NOT send a request with the same messageID as an - earlier request in the same LDAP session unless it can be determined - that the server is no longer servicing the earlier request (e.g., - after the final response is received, or a subsequent Bind - completes). Otherwise, the behavior is undefined. For this purpose, - note that Abandon and successfully abandoned operations do not send - responses. - -4.1.2. String Types - - The LDAPString is a notational convenience to indicate that, although - strings of LDAPString type encode as ASN.1 OCTET STRING types, the - [ISO10646] character set (a superset of [Unicode]) is used, encoded - following the UTF-8 [RFC3629] algorithm. Note that Unicode - characters U+0000 through U+007F are the same as ASCII 0 through 127, - respectively, and have the same single octet UTF-8 encoding. Other - Unicode characters have a multiple octet UTF-8 encoding. - - LDAPString ::= OCTET STRING -- UTF-8 encoded, - -- [ISO10646] characters - - The LDAPOID is a notational convenience to indicate that the - permitted value of this string is a (UTF-8 encoded) dotted-decimal - representation of an OBJECT IDENTIFIER. Although an LDAPOID is - - - - -Sermersheim Standards Track [Page 7] - -RFC 4511 LDAPv3 June 2006 - - - encoded as an OCTET STRING, values are limited to the definition of - <numericoid> given in Section 1.4 of [RFC4512]. - - LDAPOID ::= OCTET STRING -- Constrained to <numericoid> - -- [RFC4512] - - For example, - - 1.3.6.1.4.1.1466.1.2.3 - -4.1.3. Distinguished Name and Relative Distinguished Name - - An LDAPDN is defined to be the representation of a Distinguished Name - (DN) after encoding according to the specification in [RFC4514]. - - LDAPDN ::= LDAPString - -- Constrained to <distinguishedName> [RFC4514] - - A RelativeLDAPDN is defined to be the representation of a Relative - Distinguished Name (RDN) after encoding according to the - specification in [RFC4514]. - - RelativeLDAPDN ::= LDAPString - -- Constrained to <name-component> [RFC4514] - -4.1.4. Attribute Descriptions - - The definition and encoding rules for attribute descriptions are - defined in Section 2.5 of [RFC4512]. Briefly, an attribute - description is an attribute type and zero or more options. - - AttributeDescription ::= LDAPString - -- Constrained to <attributedescription> - -- [RFC4512] - -4.1.5. Attribute Value - - A field of type AttributeValue is an OCTET STRING containing an - encoded attribute value. The attribute value is encoded according to - the LDAP-specific encoding definition of its corresponding syntax. - The LDAP-specific encoding definitions for different syntaxes and - attribute types may be found in other documents and in particular - [RFC4517]. - - AttributeValue ::= OCTET STRING - - - - - - -Sermersheim Standards Track [Page 8] - -RFC 4511 LDAPv3 June 2006 - - - Note that there is no defined limit on the size of this encoding; - thus, protocol values may include multi-megabyte attribute values - (e.g., photographs). - - Attribute values may be defined that have arbitrary and non-printable - syntax. Implementations MUST NOT display or attempt to decode an - attribute value if its syntax is not known. The implementation may - attempt to discover the subschema of the source entry and to retrieve - the descriptions of 'attributeTypes' from it [RFC4512]. - - Clients MUST only send attribute values in a request that are valid - according to the syntax defined for the attributes. - -4.1.6. Attribute Value Assertion - - The AttributeValueAssertion (AVA) type definition is similar to the - one in the X.500 Directory standards. It contains an attribute - description and a matching rule ([RFC4512], Section 4.1.3) assertion - value suitable for that type. Elements of this type are typically - used to assert that the value in assertionValue matches a value of an - attribute. - - AttributeValueAssertion ::= SEQUENCE { - attributeDesc AttributeDescription, - assertionValue AssertionValue } - - AssertionValue ::= OCTET STRING - - The syntax of the AssertionValue depends on the context of the LDAP - operation being performed. For example, the syntax of the EQUALITY - matching rule for an attribute is used when performing a Compare - operation. Often this is the same syntax used for values of the - attribute type, but in some cases the assertion syntax differs from - the value syntax. See objectIdentiferFirstComponentMatch in - [RFC4517] for an example. - -4.1.7. Attribute and PartialAttribute - - Attributes and partial attributes consist of an attribute description - and attribute values. A PartialAttribute allows zero values, while - Attribute requires at least one value. - - PartialAttribute ::= SEQUENCE { - type AttributeDescription, - vals SET OF value AttributeValue } - - - - - - -Sermersheim Standards Track [Page 9] - -RFC 4511 LDAPv3 June 2006 - - - Attribute ::= PartialAttribute(WITH COMPONENTS { - ..., - vals (SIZE(1..MAX))}) - - No two of the attribute values may be equivalent as described by - Section 2.2 of [RFC4512]. The set of attribute values is unordered. - Implementations MUST NOT rely upon the ordering being repeatable. - -4.1.8. Matching Rule Identifier - - Matching rules are defined in Section 4.1.3 of [RFC4512]. A matching - rule is identified in the protocol by the printable representation of - either its <numericoid> or one of its short name descriptors - [RFC4512], e.g., 'caseIgnoreMatch' or '2.5.13.2'. - - MatchingRuleId ::= LDAPString - -4.1.9. Result Message - - The LDAPResult is the construct used in this protocol to return - success or failure indications from servers to clients. To various - requests, servers will return responses containing the elements found - in LDAPResult to indicate the final status of the protocol operation - request. - - LDAPResult ::= SEQUENCE { - resultCode ENUMERATED { - success (0), - operationsError (1), - protocolError (2), - timeLimitExceeded (3), - sizeLimitExceeded (4), - compareFalse (5), - compareTrue (6), - authMethodNotSupported (7), - strongerAuthRequired (8), - -- 9 reserved -- - referral (10), - adminLimitExceeded (11), - unavailableCriticalExtension (12), - confidentialityRequired (13), - saslBindInProgress (14), - noSuchAttribute (16), - undefinedAttributeType (17), - inappropriateMatching (18), - constraintViolation (19), - attributeOrValueExists (20), - invalidAttributeSyntax (21), - - - -Sermersheim Standards Track [Page 10] - -RFC 4511 LDAPv3 June 2006 - - - -- 22-31 unused -- - noSuchObject (32), - aliasProblem (33), - invalidDNSyntax (34), - -- 35 reserved for undefined isLeaf -- - aliasDereferencingProblem (36), - -- 37-47 unused -- - inappropriateAuthentication (48), - invalidCredentials (49), - insufficientAccessRights (50), - busy (51), - unavailable (52), - unwillingToPerform (53), - loopDetect (54), - -- 55-63 unused -- - namingViolation (64), - objectClassViolation (65), - notAllowedOnNonLeaf (66), - notAllowedOnRDN (67), - entryAlreadyExists (68), - objectClassModsProhibited (69), - -- 70 reserved for CLDAP -- - affectsMultipleDSAs (71), - -- 72-79 unused -- - other (80), - ... }, - matchedDN LDAPDN, - diagnosticMessage LDAPString, - referral [3] Referral OPTIONAL } - - The resultCode enumeration is extensible as defined in Section 3.8 of - [RFC4520]. The meanings of the listed result codes are given in - Appendix A. If a server detects multiple errors for an operation, - only one result code is returned. The server should return the - result code that best indicates the nature of the error encountered. - Servers may return substituted result codes to prevent unauthorized - disclosures. - - The diagnosticMessage field of this construct may, at the server's - option, be used to return a string containing a textual, human- - readable diagnostic message (terminal control and page formatting - characters should be avoided). As this diagnostic message is not - standardized, implementations MUST NOT rely on the values returned. - Diagnostic messages typically supplement the resultCode with - additional information. If the server chooses not to return a - textual diagnostic, the diagnosticMessage field MUST be empty. - - - - - -Sermersheim Standards Track [Page 11] - -RFC 4511 LDAPv3 June 2006 - - - For certain result codes (typically, but not restricted to - noSuchObject, aliasProblem, invalidDNSyntax, and - aliasDereferencingProblem), the matchedDN field is set (subject to - access controls) to the name of the last entry (object or alias) used - in finding the target (or base) object. This will be a truncated - form of the provided name or, if an alias was dereferenced while - attempting to locate the entry, of the resulting name. Otherwise, - the matchedDN field is empty. - -4.1.10. Referral - - The referral result code indicates that the contacted server cannot - or will not perform the operation and that one or more other servers - may be able to. Reasons for this include: - - - The target entry of the request is not held locally, but the server - has knowledge of its possible existence elsewhere. - - - The operation is restricted on this server -- perhaps due to a - read-only copy of an entry to be modified. - - The referral field is present in an LDAPResult if the resultCode is - set to referral, and it is absent with all other result codes. It - contains one or more references to one or more servers or services - that may be accessed via LDAP or other protocols. Referrals can be - returned in response to any operation request (except Unbind and - Abandon, which do not have responses). At least one URI MUST be - present in the Referral. - - During a Search operation, after the baseObject is located, and - entries are being evaluated, the referral is not returned. Instead, - continuation references, described in Section 4.5.3, are returned - when other servers would need to be contacted to complete the - operation. - - Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI - - URI ::= LDAPString -- limited to characters permitted in - -- URIs - - If the client wishes to progress the operation, it contacts one of - the supported services found in the referral. If multiple URIs are - present, the client assumes that any supported URI may be used to - progress the operation. - - Clients that follow referrals MUST ensure that they do not loop - between servers. They MUST NOT repeatedly contact the same server - for the same request with the same parameters. Some clients use a - - - -Sermersheim Standards Track [Page 12] - -RFC 4511 LDAPv3 June 2006 - - - counter that is incremented each time referral handling occurs for an - operation, and these kinds of clients MUST be able to handle at least - ten nested referrals while progressing the operation. - - A URI for a server implementing LDAP and accessible via TCP/IP (v4 or - v6) [RFC793][RFC791] is written as an LDAP URL according to - [RFC4516]. - - Referral values that are LDAP URLs follow these rules: - - - If an alias was dereferenced, the <dn> part of the LDAP URL MUST be - present, with the new target object name. - - - It is RECOMMENDED that the <dn> part be present to avoid ambiguity. - - - If the <dn> part is present, the client uses this name in its next - request to progress the operation, and if it is not present the - client uses the same name as in the original request. - - - Some servers (e.g., participating in distributed indexing) may - provide a different filter in a URL of a referral for a Search - operation. - - - If the <filter> part of the LDAP URL is present, the client uses - this filter in its next request to progress this Search, and if it - is not present the client uses the same filter as it used for that - Search. - - - For Search, it is RECOMMENDED that the <scope> part be present to - avoid ambiguity. - - - If the <scope> part is missing, the scope of the original Search is - used by the client to progress the operation. - - - Other aspects of the new request may be the same as or different - from the request that generated the referral. - - Other kinds of URIs may be returned. The syntax and semantics of - such URIs is left to future specifications. Clients may ignore URIs - that they do not support. - - UTF-8 encoded characters appearing in the string representation of a - DN, search filter, or other fields of the referral value may not be - legal for URIs (e.g., spaces) and MUST be escaped using the % method - in [RFC3986]. - - - - - - -Sermersheim Standards Track [Page 13] - -RFC 4511 LDAPv3 June 2006 - - -4.1.11. Controls - - Controls provide a mechanism whereby the semantics and arguments of - existing LDAP operations may be extended. One or more controls may - be attached to a single LDAP message. A control only affects the - semantics of the message it is attached to. - - Controls sent by clients are termed 'request controls', and those - sent by servers are termed 'response controls'. - - Controls ::= SEQUENCE OF control Control - - Control ::= SEQUENCE { - controlType LDAPOID, - criticality BOOLEAN DEFAULT FALSE, - controlValue OCTET STRING OPTIONAL } - - The controlType field is the dotted-decimal representation of an - OBJECT IDENTIFIER that uniquely identifies the control. This - provides unambiguous naming of controls. Often, response control(s) - solicited by a request control share controlType values with the - request control. - - The criticality field only has meaning in controls attached to - request messages (except UnbindRequest). For controls attached to - response messages and the UnbindRequest, the criticality field SHOULD - be FALSE, and MUST be ignored by the receiving protocol peer. A - value of TRUE indicates that it is unacceptable to perform the - operation without applying the semantics of the control. - Specifically, the criticality field is applied as follows: - - - If the server does not recognize the control type, determines that - it is not appropriate for the operation, or is otherwise unwilling - to perform the operation with the control, and if the criticality - field is TRUE, the server MUST NOT perform the operation, and for - operations that have a response message, it MUST return with the - resultCode set to unavailableCriticalExtension. - - - If the server does not recognize the control type, determines that - it is not appropriate for the operation, or is otherwise unwilling - to perform the operation with the control, and if the criticality - field is FALSE, the server MUST ignore the control. - - - Regardless of criticality, if a control is applied to an - operation, it is applied consistently and impartially to the - entire operation. - - - - - -Sermersheim Standards Track [Page 14] - -RFC 4511 LDAPv3 June 2006 - - - The controlValue may contain information associated with the - controlType. Its format is defined by the specification of the - control. Implementations MUST be prepared to handle arbitrary - contents of the controlValue octet string, including zero bytes. It - is absent only if there is no value information that is associated - with a control of its type. When a controlValue is defined in terms - of ASN.1, and BER-encoded according to Section 5.1, it also follows - the extensibility rules in Section 4. - - Servers list the controlType of request controls they recognize in - the 'supportedControl' attribute in the root DSE (Section 5.1 of - [RFC4512]). - - Controls SHOULD NOT be combined unless the semantics of the - combination has been specified. The semantics of control - combinations, if specified, are generally found in the control - specification most recently published. When a combination of - controls is encountered whose semantics are invalid, not specified - (or not known), the message is considered not well-formed; thus, the - operation fails with protocolError. Controls with a criticality of - FALSE may be ignored in order to arrive at a valid combination. - Additionally, unless order-dependent semantics are given in a - specification, the order of a combination of controls in the SEQUENCE - is ignored. Where the order is to be ignored but cannot be ignored - by the server, the message is considered not well-formed, and the - operation fails with protocolError. Again, controls with a - criticality of FALSE may be ignored in order to arrive at a valid - combination. - - This document does not specify any controls. Controls may be - specified in other documents. Documents detailing control extensions - are to provide for each control: - - - the OBJECT IDENTIFIER assigned to the control, - - - direction as to what value the sender should provide for the - criticality field (note: the semantics of the criticality field are - defined above should not be altered by the control's - specification), - - - whether the controlValue field is present, and if so, the format of - its contents, - - - the semantics of the control, and - - - optionally, semantics regarding the combination of the control with - other controls. - - - - -Sermersheim Standards Track [Page 15] - -RFC 4511 LDAPv3 June 2006 - - -4.2. Bind Operation - - The function of the Bind operation is to allow authentication - information to be exchanged between the client and server. The Bind - operation should be thought of as the "authenticate" operation. - Operational, authentication, and security-related semantics of this - operation are given in [RFC4513]. - - The Bind request is defined as follows: - - BindRequest ::= [APPLICATION 0] SEQUENCE { - version INTEGER (1 .. 127), - name LDAPDN, - authentication AuthenticationChoice } - - AuthenticationChoice ::= CHOICE { - simple [0] OCTET STRING, - -- 1 and 2 reserved - sasl [3] SaslCredentials, - ... } - - SaslCredentials ::= SEQUENCE { - mechanism LDAPString, - credentials OCTET STRING OPTIONAL } - - Fields of the BindRequest are: - - - version: A version number indicating the version of the protocol to - be used at the LDAP message layer. This document describes version - 3 of the protocol. There is no version negotiation. The client - sets this field to the version it desires. If the server does not - support the specified version, it MUST respond with a BindResponse - where the resultCode is set to protocolError. - - - name: If not empty, the name of the Directory object that the - client wishes to bind as. This field may take on a null value (a - zero-length string) for the purposes of anonymous binds ([RFC4513], - Section 5.1) or when using SASL [RFC4422] authentication - ([RFC4513], Section 5.2). Where the server attempts to locate the - named object, it SHALL NOT perform alias dereferencing. - - - authentication: Information used in authentication. This type is - extensible as defined in Section 3.7 of [RFC4520]. Servers that do - not support a choice supplied by a client return a BindResponse - with the resultCode set to authMethodNotSupported. - - - - - - -Sermersheim Standards Track [Page 16] - -RFC 4511 LDAPv3 June 2006 - - - Textual passwords (consisting of a character sequence with a known - character set and encoding) transferred to the server using the - simple AuthenticationChoice SHALL be transferred as UTF-8 [RFC3629] - encoded [Unicode]. Prior to transfer, clients SHOULD prepare text - passwords as "query" strings by applying the SASLprep [RFC4013] - profile of the stringprep [RFC3454] algorithm. Passwords - consisting of other data (such as random octets) MUST NOT be - altered. The determination of whether a password is textual is a - local client matter. - -4.2.1. Processing of the Bind Request - - Before processing a BindRequest, all uncompleted operations MUST - either complete or be abandoned. The server may either wait for the - uncompleted operations to complete, or abandon them. The server then - proceeds to authenticate the client in either a single-step or - multi-step Bind process. Each step requires the server to return a - BindResponse to indicate the status of authentication. - - After sending a BindRequest, clients MUST NOT send further LDAP PDUs - until receiving the BindResponse. Similarly, servers SHOULD NOT - process or respond to requests received while processing a - BindRequest. - - If the client did not bind before sending a request and receives an - operationsError to that request, it may then send a BindRequest. If - this also fails or the client chooses not to bind on the existing - LDAP session, it may terminate the LDAP session, re-establish it, and - begin again by first sending a BindRequest. This will aid in - interoperating with servers implementing other versions of LDAP. - - Clients may send multiple Bind requests to change the authentication - and/or security associations or to complete a multi-stage Bind - process. Authentication from earlier binds is subsequently ignored. - - For some SASL authentication mechanisms, it may be necessary for the - client to invoke the BindRequest multiple times ([RFC4513], Section - 5.2). Clients MUST NOT invoke operations between two Bind requests - made as part of a multi-stage Bind. - - A client may abort a SASL bind negotiation by sending a BindRequest - with a different value in the mechanism field of SaslCredentials, or - an AuthenticationChoice other than sasl. - - - - - - - - -Sermersheim Standards Track [Page 17] - -RFC 4511 LDAPv3 June 2006 - - - If the client sends a BindRequest with the sasl mechanism field as an - empty string, the server MUST return a BindResponse with the - resultCode set to authMethodNotSupported. This will allow the client - to abort a negotiation if it wishes to try again with the same SASL - mechanism. - -4.2.2. Bind Response - - The Bind response is defined as follows. - - BindResponse ::= [APPLICATION 1] SEQUENCE { - COMPONENTS OF LDAPResult, - serverSaslCreds [7] OCTET STRING OPTIONAL } - - BindResponse consists simply of an indication from the server of the - status of the client's request for authentication. - - A successful Bind operation is indicated by a BindResponse with a - resultCode set to success. Otherwise, an appropriate result code is - set in the BindResponse. For BindResponse, the protocolError result - code may be used to indicate that the version number supplied by the - client is unsupported. - - If the client receives a BindResponse where the resultCode is set to - protocolError, it is to assume that the server does not support this - version of LDAP. While the client may be able proceed with another - version of this protocol (which may or may not require closing and - re-establishing the transport connection), how to proceed with - another version of this protocol is beyond the scope of this - document. Clients that are unable or unwilling to proceed SHOULD - terminate the LDAP session. - - The serverSaslCreds field is used as part of a SASL-defined bind - mechanism to allow the client to authenticate the server to which it - is communicating, or to perform "challenge-response" authentication. - If the client bound with the simple choice, or the SASL mechanism - does not require the server to return information to the client, then - this field SHALL NOT be included in the BindResponse. - -4.3. Unbind Operation - - The function of the Unbind operation is to terminate an LDAP session. - The Unbind operation is not the antithesis of the Bind operation as - the name implies. The naming of these operations are historical. - The Unbind operation should be thought of as the "quit" operation. - - - - - - -Sermersheim Standards Track [Page 18] - -RFC 4511 LDAPv3 June 2006 - - - The Unbind operation is defined as follows: - - UnbindRequest ::= [APPLICATION 2] NULL - - The client, upon transmission of the UnbindRequest, and the server, - upon receipt of the UnbindRequest, are to gracefully terminate the - LDAP session as described in Section 5.3. Uncompleted operations are - handled as specified in Section 3.1. - -4.4. Unsolicited Notification - - An unsolicited notification is an LDAPMessage sent from the server to - the client that is not in response to any LDAPMessage received by the - server. It is used to signal an extraordinary condition in the - server or in the LDAP session between the client and the server. The - notification is of an advisory nature, and the server will not expect - any response to be returned from the client. - - The unsolicited notification is structured as an LDAPMessage in which - the messageID is zero and protocolOp is set to the extendedResp - choice using the ExtendedResponse type (See Section 4.12). The - responseName field of the ExtendedResponse always contains an LDAPOID - that is unique for this notification. - - One unsolicited notification (Notice of Disconnection) is defined in - this document. The specification of an unsolicited notification - consists of: - - - the OBJECT IDENTIFIER assigned to the notification (to be specified - in the responseName, - - - the format of the contents of the responseValue (if any), - - - the circumstances which will cause the notification to be sent, and - - - the semantics of the message. - -4.4.1. Notice of Disconnection - - This notification may be used by the server to advise the client that - the server is about to terminate the LDAP session on its own - initiative. This notification is intended to assist clients in - distinguishing between an exceptional server condition and a - transient network failure. Note that this notification is not a - response to an Unbind requested by the client. Uncompleted - operations are handled as specified in Section 3.1. - - - - - -Sermersheim Standards Track [Page 19] - -RFC 4511 LDAPv3 June 2006 - - - The responseName is 1.3.6.1.4.1.1466.20036, the responseValue field - is absent, and the resultCode is used to indicate the reason for the - disconnection. When the strongerAuthRequired resultCode is returned - with this message, it indicates that the server has detected that an - established security association between the client and server has - unexpectedly failed or been compromised. - - Upon transmission of the Notice of Disconnection, the server - gracefully terminates the LDAP session as described in Section 5.3. - -4.5. Search Operation - - The Search operation is used to request a server to return, subject - to access controls and other restrictions, a set of entries matching - a complex search criterion. This can be used to read attributes from - a single entry, from entries immediately subordinate to a particular - entry, or from a whole subtree of entries. - -4.5.1. Search Request - - The Search request is defined as follows: - - SearchRequest ::= [APPLICATION 3] SEQUENCE { - baseObject LDAPDN, - scope ENUMERATED { - baseObject (0), - singleLevel (1), - wholeSubtree (2), - ... }, - derefAliases ENUMERATED { - neverDerefAliases (0), - derefInSearching (1), - derefFindingBaseObj (2), - derefAlways (3) }, - sizeLimit INTEGER (0 .. maxInt), - timeLimit INTEGER (0 .. maxInt), - typesOnly BOOLEAN, - filter Filter, - attributes AttributeSelection } - - AttributeSelection ::= SEQUENCE OF selector LDAPString - -- The LDAPString is constrained to - -- <attributeSelector> in Section 4.5.1.8 - - Filter ::= CHOICE { - and [0] SET SIZE (1..MAX) OF filter Filter, - or [1] SET SIZE (1..MAX) OF filter Filter, - not [2] Filter, - - - -Sermersheim Standards Track [Page 20] - -RFC 4511 LDAPv3 June 2006 - - - equalityMatch [3] AttributeValueAssertion, - substrings [4] SubstringFilter, - greaterOrEqual [5] AttributeValueAssertion, - lessOrEqual [6] AttributeValueAssertion, - present [7] AttributeDescription, - approxMatch [8] AttributeValueAssertion, - extensibleMatch [9] MatchingRuleAssertion, - ... } - - SubstringFilter ::= SEQUENCE { - type AttributeDescription, - substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE { - initial [0] AssertionValue, -- can occur at most once - any [1] AssertionValue, - final [2] AssertionValue } -- can occur at most once - } - - MatchingRuleAssertion ::= SEQUENCE { - matchingRule [1] MatchingRuleId OPTIONAL, - type [2] AttributeDescription OPTIONAL, - matchValue [3] AssertionValue, - dnAttributes [4] BOOLEAN DEFAULT FALSE } - - Note that an X.500 "list"-like operation can be emulated by the - client requesting a singleLevel Search operation with a filter - checking for the presence of the 'objectClass' attribute, and that an - X.500 "read"-like operation can be emulated by a baseObject Search - operation with the same filter. A server that provides a gateway to - X.500 is not required to use the Read or List operations, although it - may choose to do so, and if it does, it must provide the same - semantics as the X.500 Search operation. - -4.5.1.1. SearchRequest.baseObject - - The name of the base object entry (or possibly the root) relative to - which the Search is to be performed. - -4.5.1.2. SearchRequest.scope - - Specifies the scope of the Search to be performed. The semantics (as - described in [X.511]) of the defined values of this field are: - - baseObject: The scope is constrained to the entry named by - baseObject. - - singleLevel: The scope is constrained to the immediate - subordinates of the entry named by baseObject. - - - - -Sermersheim Standards Track [Page 21] - -RFC 4511 LDAPv3 June 2006 - - - wholeSubtree: The scope is constrained to the entry named by - baseObject and to all its subordinates. - -4.5.1.3. SearchRequest.derefAliases - - An indicator as to whether or not alias entries (as defined in - [RFC4512]) are to be dereferenced during stages of the Search - operation. - - The act of dereferencing an alias includes recursively dereferencing - aliases that refer to aliases. - - Servers MUST detect looping while dereferencing aliases in order to - prevent denial-of-service attacks of this nature. - - The semantics of the defined values of this field are: - - neverDerefAliases: Do not dereference aliases in searching or in - locating the base object of the Search. - - derefInSearching: While searching subordinates of the base object, - dereference any alias within the search scope. Dereferenced - objects become the vertices of further search scopes where the - Search operation is also applied. If the search scope is - wholeSubtree, the Search continues in the subtree(s) of any - dereferenced object. If the search scope is singleLevel, the - search is applied to any dereferenced objects and is not applied - to their subordinates. Servers SHOULD eliminate duplicate entries - that arise due to alias dereferencing while searching. - - derefFindingBaseObj: Dereference aliases in locating the base - object of the Search, but not when searching subordinates of the - base object. - - derefAlways: Dereference aliases both in searching and in locating - the base object of the Search. - -4.5.1.4. SearchRequest.sizeLimit - - A size limit that restricts the maximum number of entries to be - returned as a result of the Search. A value of zero in this field - indicates that no client-requested size limit restrictions are in - effect for the Search. Servers may also enforce a maximum number of - entries to return. - - - - - - - -Sermersheim Standards Track [Page 22] - -RFC 4511 LDAPv3 June 2006 - - -4.5.1.5. SearchRequest.timeLimit - - A time limit that restricts the maximum time (in seconds) allowed for - a Search. A value of zero in this field indicates that no client- - requested time limit restrictions are in effect for the Search. - Servers may also enforce a maximum time limit for the Search. - -4.5.1.6. SearchRequest.typesOnly - - An indicator as to whether Search results are to contain both - attribute descriptions and values, or just attribute descriptions. - Setting this field to TRUE causes only attribute descriptions (and - not values) to be returned. Setting this field to FALSE causes both - attribute descriptions and values to be returned. - -4.5.1.7. SearchRequest.filter - - A filter that defines the conditions that must be fulfilled in order - for the Search to match a given entry. - - The 'and', 'or', and 'not' choices can be used to form combinations - of filters. At least one filter element MUST be present in an 'and' - or 'or' choice. The others match against individual attribute values - of entries in the scope of the Search. (Implementor's note: the - 'not' filter is an example of a tagged choice in an implicitly-tagged - module. In BER this is treated as if the tag were explicit.) - - A server MUST evaluate filters according to the three-valued logic of - [X.511] (1993), Clause 7.8.1. In summary, a filter is evaluated to - "TRUE", "FALSE", or "Undefined". If the filter evaluates to TRUE for - a particular entry, then the attributes of that entry are returned as - part of the Search result (subject to any applicable access control - restrictions). If the filter evaluates to FALSE or Undefined, then - the entry is ignored for the Search. - - A filter of the "and" choice is TRUE if all the filters in the SET OF - evaluate to TRUE, FALSE if at least one filter is FALSE, and - Undefined otherwise. A filter of the "or" choice is FALSE if all the - filters in the SET OF evaluate to FALSE, TRUE if at least one filter - is TRUE, and Undefined otherwise. A filter of the 'not' choice is - TRUE if the filter being negated is FALSE, FALSE if it is TRUE, and - Undefined if it is Undefined. - - A filter item evaluates to Undefined when the server would not be - able to determine whether the assertion value matches an entry. - Examples include: - - - - - -Sermersheim Standards Track [Page 23] - -RFC 4511 LDAPv3 June 2006 - - - - An attribute description in an equalityMatch, substrings, - greaterOrEqual, lessOrEqual, approxMatch, or extensibleMatch filter - is not recognized by the server. - - - The attribute type does not define the appropriate matching rule. - - - A MatchingRuleId in the extensibleMatch is not recognized by the - server or is not valid for the attribute type. - - - The type of filtering requested is not implemented. - - - The assertion value is invalid. - - For example, if a server did not recognize the attribute type - shoeSize, the filters (shoeSize=*), (shoeSize=12), (shoeSize>=12), - and (shoeSize<=12) would each evaluate to Undefined. - - Servers MUST NOT return errors if attribute descriptions or matching - rule ids are not recognized, assertion values are invalid, or the - assertion syntax is not supported. More details of filter processing - are given in Clause 7.8 of [X.511]. - -4.5.1.7.1. SearchRequest.filter.equalityMatch - - The matching rule for an equalityMatch filter is defined by the - EQUALITY matching rule for the attribute type or subtype. The filter - is TRUE when the EQUALITY rule returns TRUE as applied to the - attribute or subtype and the asserted value. - -4.5.1.7.2. SearchRequest.filter.substrings - - There SHALL be at most one 'initial' and at most one 'final' in the - 'substrings' of a SubstringFilter. If 'initial' is present, it SHALL - be the first element of 'substrings'. If 'final' is present, it - SHALL be the last element of 'substrings'. - - The matching rule for an AssertionValue in a substrings filter item - is defined by the SUBSTR matching rule for the attribute type or - subtype. The filter is TRUE when the SUBSTR rule returns TRUE as - applied to the attribute or subtype and the asserted value. - - Note that the AssertionValue in a substrings filter item conforms to - the assertion syntax of the EQUALITY matching rule for the attribute - type rather than to the assertion syntax of the SUBSTR matching rule - for the attribute type. Conceptually, the entire SubstringFilter is - converted into an assertion value of the substrings matching rule - prior to applying the rule. - - - - -Sermersheim Standards Track [Page 24] - -RFC 4511 LDAPv3 June 2006 - - -4.5.1.7.3. SearchRequest.filter.greaterOrEqual - - The matching rule for a greaterOrEqual filter is defined by the - ORDERING matching rule for the attribute type or subtype. The filter - is TRUE when the ORDERING rule returns FALSE as applied to the - attribute or subtype and the asserted value. - -4.5.1.7.4. SearchRequest.filter.lessOrEqual - - The matching rules for a lessOrEqual filter are defined by the - ORDERING and EQUALITY matching rules for the attribute type or - subtype. The filter is TRUE when either the ORDERING or EQUALITY - rule returns TRUE as applied to the attribute or subtype and the - asserted value. - -4.5.1.7.5. SearchRequest.filter.present - - A present filter is TRUE when there is an attribute or subtype of the - specified attribute description present in an entry, FALSE when no - attribute or subtype of the specified attribute description is - present in an entry, and Undefined otherwise. - -4.5.1.7.6. SearchRequest.filter.approxMatch - - An approxMatch filter is TRUE when there is a value of the attribute - type or subtype for which some locally-defined approximate matching - algorithm (e.g., spelling variations, phonetic match, etc.) returns - TRUE. If a value matches for equality, it also satisfies an - approximate match. If approximate matching is not supported for the - attribute, this filter item should be treated as an equalityMatch. - -4.5.1.7.7. SearchRequest.filter.extensibleMatch - - The fields of the extensibleMatch filter item are evaluated as - follows: - - - If the matchingRule field is absent, the type field MUST be - present, and an equality match is performed for that type. - - - If the type field is absent and the matchingRule is present, the - matchValue is compared against all attributes in an entry that - support that matchingRule. - - - If the type field is present and the matchingRule is present, the - matchValue is compared against the specified attribute type and its - subtypes. - - - - - -Sermersheim Standards Track [Page 25] - -RFC 4511 LDAPv3 June 2006 - - - - If the dnAttributes field is set to TRUE, the match is additionally - applied against all the AttributeValueAssertions in an entry's - distinguished name, and it evaluates to TRUE if there is at least - one attribute or subtype in the distinguished name for which the - filter item evaluates to TRUE. The dnAttributes field is present - to alleviate the need for multiple versions of generic matching - rules (such as word matching), where one applies to entries and - another applies to entries and DN attributes as well. - - The matchingRule used for evaluation determines the syntax for the - assertion value. Once the matchingRule and attribute(s) have been - determined, the filter item evaluates to TRUE if it matches at least - one attribute type or subtype in the entry, FALSE if it does not - match any attribute type or subtype in the entry, and Undefined if - the matchingRule is not recognized, the matchingRule is unsuitable - for use with the specified type, or the assertionValue is invalid. - -4.5.1.8. SearchRequest.attributes - - A selection list of the attributes to be returned from each entry - that matches the search filter. Attributes that are subtypes of - listed attributes are implicitly included. LDAPString values of this - field are constrained to the following Augmented Backus-Naur Form - (ABNF) [RFC4234]: - - attributeSelector = attributedescription / selectorspecial - - selectorspecial = noattrs / alluserattrs - - noattrs = %x31.2E.31 ; "1.1" - - alluserattrs = %x2A ; asterisk ("*") - - The <attributedescription> production is defined in Section 2.5 of - [RFC4512]. - - There are three special cases that may appear in the attributes - selection list: - - 1. An empty list with no attributes requests the return of all - user attributes. - - 2. A list containing "*" (with zero or more attribute - descriptions) requests the return of all user attributes in - addition to other listed (operational) attributes. - - - - - - -Sermersheim Standards Track [Page 26] - -RFC 4511 LDAPv3 June 2006 - - - 3. A list containing only the OID "1.1" indicates that no - attributes are to be returned. If "1.1" is provided with other - attributeSelector values, the "1.1" attributeSelector is - ignored. This OID was chosen because it does not (and can not) - correspond to any attribute in use. - - Client implementors should note that even if all user attributes are - requested, some attributes and/or attribute values of the entry may - not be included in Search results due to access controls or other - restrictions. Furthermore, servers will not return operational - attributes, such as objectClasses or attributeTypes, unless they are - listed by name. Operational attributes are described in [RFC4512]. - - Attributes are returned at most once in an entry. If an attribute - description is named more than once in the list, the subsequent names - are ignored. If an attribute description in the list is not - recognized, it is ignored by the server. - -4.5.2. Search Result - - The results of the Search operation are returned as zero or more - SearchResultEntry and/or SearchResultReference messages, followed by - a single SearchResultDone message. - - SearchResultEntry ::= [APPLICATION 4] SEQUENCE { - objectName LDAPDN, - attributes PartialAttributeList } - - PartialAttributeList ::= SEQUENCE OF - partialAttribute PartialAttribute - - SearchResultReference ::= [APPLICATION 19] SEQUENCE - SIZE (1..MAX) OF uri URI - - SearchResultDone ::= [APPLICATION 5] LDAPResult - - Each SearchResultEntry represents an entry found during the Search. - Each SearchResultReference represents an area not yet explored during - the Search. The SearchResultEntry and SearchResultReference messages - may come in any order. Following all the SearchResultReference and - SearchResultEntry responses, the server returns a SearchResultDone - response, which contains an indication of success or details any - errors that have occurred. - - Each entry returned in a SearchResultEntry will contain all - appropriate attributes as specified in the attributes field of the - Search Request, subject to access control and other administrative - policy. Note that the PartialAttributeList may hold zero elements. - - - -Sermersheim Standards Track [Page 27] - -RFC 4511 LDAPv3 June 2006 - - - This may happen when none of the attributes of an entry were - requested or could be returned. Note also that the partialAttribute - vals set may hold zero elements. This may happen when typesOnly is - requested, access controls prevent the return of values, or other - reasons. - - Some attributes may be constructed by the server and appear in a - SearchResultEntry attribute list, although they are not stored - attributes of an entry. Clients SHOULD NOT assume that all - attributes can be modified, even if this is permitted by access - control. - - If the server's schema defines short names [RFC4512] for an attribute - type, then the server SHOULD use one of those names in attribute - descriptions for that attribute type (in preference to using the - <numericoid> [RFC4512] format of the attribute type's object - identifier). The server SHOULD NOT use the short name if that name - is known by the server to be ambiguous, or if it is otherwise likely - to cause interoperability problems. - -4.5.3. Continuation References in the Search Result - - If the server was able to locate the entry referred to by the - baseObject but was unable or unwilling to search one or more non- - local entries, the server may return one or more - SearchResultReference messages, each containing a reference to - another set of servers for continuing the operation. A server MUST - NOT return any SearchResultReference messages if it has not located - the baseObject and thus has not searched any entries. In this case, - it would return a SearchResultDone containing either a referral or - noSuchObject result code (depending on the server's knowledge of the - entry named in the baseObject). - - If a server holds a copy or partial copy of the subordinate naming - context (Section 5 of [RFC4512]), it may use the search filter to - determine whether or not to return a SearchResultReference response. - Otherwise, SearchResultReference responses are always returned when - in scope. - - The SearchResultReference is of the same data type as the Referral. - - If the client wishes to progress the Search, it issues a new Search - operation for each SearchResultReference that is returned. If - multiple URIs are present, the client assumes that any supported URI - may be used to progress the operation. - - - - - - -Sermersheim Standards Track [Page 28] - -RFC 4511 LDAPv3 June 2006 - - - Clients that follow search continuation references MUST ensure that - they do not loop between servers. They MUST NOT repeatedly contact - the same server for the same request with the same parameters. Some - clients use a counter that is incremented each time search result - reference handling occurs for an operation, and these kinds of - clients MUST be able to handle at least ten nested referrals while - progressing the operation. - - Note that the Abandon operation described in Section 4.11 applies - only to a particular operation sent at the LDAP message layer between - a client and server. The client must individually abandon subsequent - Search operations it wishes to. - - A URI for a server implementing LDAP and accessible via TCP/IP (v4 or - v6) [RFC793][RFC791] is written as an LDAP URL according to - [RFC4516]. - - SearchResultReference values that are LDAP URLs follow these rules: - - - The <dn> part of the LDAP URL MUST be present, with the new target - object name. The client uses this name when following the - reference. - - - Some servers (e.g., participating in distributed indexing) may - provide a different filter in the LDAP URL. - - - If the <filter> part of the LDAP URL is present, the client uses - this filter in its next request to progress this Search, and if it - is not present the client uses the same filter as it used for that - Search. - - - If the originating search scope was singleLevel, the <scope> part - of the LDAP URL will be "base". - - - It is RECOMMENDED that the <scope> part be present to avoid - ambiguity. In the absence of a <scope> part, the scope of the - original Search request is assumed. - - - Other aspects of the new Search request may be the same as or - different from the Search request that generated the - SearchResultReference. - - - The name of an unexplored subtree in a SearchResultReference need - not be subordinate to the base object. - - Other kinds of URIs may be returned. The syntax and semantics of - such URIs is left to future specifications. Clients may ignore URIs - that they do not support. - - - -Sermersheim Standards Track [Page 29] - -RFC 4511 LDAPv3 June 2006 - - - UTF-8-encoded characters appearing in the string representation of a - DN, search filter, or other fields of the referral value may not be - legal for URIs (e.g., spaces) and MUST be escaped using the % method - in [RFC3986]. - -4.5.3.1. Examples - - For example, suppose the contacted server (hosta) holds the entry - <DC=Example,DC=NET> and the entry <CN=Manager,DC=Example,DC=NET>. It - knows that both LDAP servers (hostb) and (hostc) hold - <OU=People,DC=Example,DC=NET> (one is the master and the other server - a shadow), and that LDAP-capable server (hostd) holds the subtree - <OU=Roles,DC=Example,DC=NET>. If a wholeSubtree Search of - <DC=Example,DC=NET> is requested to the contacted server, it may - return the following: - - SearchResultEntry for DC=Example,DC=NET - SearchResultEntry for CN=Manager,DC=Example,DC=NET - SearchResultReference { - ldap://hostb/OU=People,DC=Example,DC=NET??sub - ldap://hostc/OU=People,DC=Example,DC=NET??sub } - SearchResultReference { - ldap://hostd/OU=Roles,DC=Example,DC=NET??sub } - SearchResultDone (success) - - Client implementors should note that when following a - SearchResultReference, additional SearchResultReference may be - generated. Continuing the example, if the client contacted the - server (hostb) and issued the Search request for the subtree - <OU=People,DC=Example,DC=NET>, the server might respond as follows: - - SearchResultEntry for OU=People,DC=Example,DC=NET - SearchResultReference { - ldap://hoste/OU=Managers,OU=People,DC=Example,DC=NET??sub } - SearchResultReference { - ldap://hostf/OU=Consultants,OU=People,DC=Example,DC=NET??sub } - SearchResultDone (success) - - Similarly, if a singleLevel Search of <DC=Example,DC=NET> is - requested to the contacted server, it may return the following: - - SearchResultEntry for CN=Manager,DC=Example,DC=NET - SearchResultReference { - ldap://hostb/OU=People,DC=Example,DC=NET??base - ldap://hostc/OU=People,DC=Example,DC=NET??base } - SearchResultReference { - ldap://hostd/OU=Roles,DC=Example,DC=NET??base } - SearchResultDone (success) - - - -Sermersheim Standards Track [Page 30] - -RFC 4511 LDAPv3 June 2006 - - - If the contacted server does not hold the base object for the Search, - but has knowledge of its possible location, then it may return a - referral to the client. In this case, if the client requests a - subtree Search of <DC=Example,DC=ORG> to hosta, the server returns a - SearchResultDone containing a referral. - - SearchResultDone (referral) { - ldap://hostg/DC=Example,DC=ORG??sub } - -4.6. Modify Operation - - The Modify operation allows a client to request that a modification - of an entry be performed on its behalf by a server. The Modify - Request is defined as follows: - - ModifyRequest ::= [APPLICATION 6] SEQUENCE { - object LDAPDN, - changes SEQUENCE OF change SEQUENCE { - operation ENUMERATED { - add (0), - delete (1), - replace (2), - ... }, - modification PartialAttribute } } - - Fields of the Modify Request are: - - - object: The value of this field contains the name of the entry to - be modified. The server SHALL NOT perform any alias dereferencing - in determining the object to be modified. - - - changes: A list of modifications to be performed on the entry. The - entire list of modifications MUST be performed in the order they - are listed as a single atomic operation. While individual - modifications may violate certain aspects of the directory schema - (such as the object class definition and Directory Information Tree - (DIT) content rule), the resulting entry after the entire list of - modifications is performed MUST conform to the requirements of the - directory model and controlling schema [RFC4512]. - - - operation: Used to specify the type of modification being - performed. Each operation type acts on the following - modification. The values of this field have the following - semantics, respectively: - - add: add values listed to the modification attribute, - creating the attribute if necessary. - - - - -Sermersheim Standards Track [Page 31] - -RFC 4511 LDAPv3 June 2006 - - - delete: delete values listed from the modification attribute. - If no values are listed, or if all current values of the - attribute are listed, the entire attribute is removed. - - replace: replace all existing values of the modification - attribute with the new values listed, creating the attribute - if it did not already exist. A replace with no value will - delete the entire attribute if it exists, and it is ignored - if the attribute does not exist. - - - modification: A PartialAttribute (which may have an empty SET - of vals) used to hold the attribute type or attribute type and - values being modified. - - Upon receipt of a Modify Request, the server attempts to perform the - necessary modifications to the DIT and returns the result in a Modify - Response, defined as follows: - - ModifyResponse ::= [APPLICATION 7] LDAPResult - - The server will return to the client a single Modify Response - indicating either the successful completion of the DIT modification, - or the reason that the modification failed. Due to the requirement - for atomicity in applying the list of modifications in the Modify - Request, the client may expect that no modifications of the DIT have - been performed if the Modify Response received indicates any sort of - error, and that all requested modifications have been performed if - the Modify Response indicates successful completion of the Modify - operation. Whether or not the modification was applied cannot be - determined by the client if the Modify Response was not received - (e.g., the LDAP session was terminated or the Modify operation was - abandoned). - - Servers MUST ensure that entries conform to user and system schema - rules or other data model constraints. The Modify operation cannot - be used to remove from an entry any of its distinguished values, - i.e., those values which form the entry's relative distinguished - name. An attempt to do so will result in the server returning the - notAllowedOnRDN result code. The Modify DN operation described in - Section 4.9 is used to rename an entry. - - For attribute types that specify no equality matching, the rules in - Section 2.5.1 of [RFC4512] are followed. - - Note that due to the simplifications made in LDAP, there is not a - direct mapping of the changes in an LDAP ModifyRequest onto the - changes of a DAP ModifyEntry operation, and different implementations - - - - -Sermersheim Standards Track [Page 32] - -RFC 4511 LDAPv3 June 2006 - - - of LDAP-DAP gateways may use different means of representing the - change. If successful, the final effect of the operations on the - entry MUST be identical. - -4.7. Add Operation - - The Add operation allows a client to request the addition of an entry - into the Directory. The Add Request is defined as follows: - - AddRequest ::= [APPLICATION 8] SEQUENCE { - entry LDAPDN, - attributes AttributeList } - - AttributeList ::= SEQUENCE OF attribute Attribute - - Fields of the Add Request are: - - - entry: the name of the entry to be added. The server SHALL NOT - dereference any aliases in locating the entry to be added. - - - attributes: the list of attributes that, along with those from the - RDN, make up the content of the entry being added. Clients MAY or - MAY NOT include the RDN attribute(s) in this list. Clients MUST - NOT supply NO-USER-MODIFICATION attributes such as the - createTimestamp or creatorsName attributes, since the server - maintains these automatically. - - Servers MUST ensure that entries conform to user and system schema - rules or other data model constraints. For attribute types that - specify no equality matching, the rules in Section 2.5.1 of [RFC4512] - are followed (this applies to the naming attribute in addition to any - multi-valued attributes being added). - - The entry named in the entry field of the AddRequest MUST NOT exist - for the AddRequest to succeed. The immediate superior (parent) of an - object or alias entry to be added MUST exist. For example, if the - client attempted to add <CN=JS,DC=Example,DC=NET>, the - <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did - exist, then the server would return the noSuchObject result code with - the matchedDN field containing <DC=NET>. - - Upon receipt of an Add Request, a server will attempt to add the - requested entry. The result of the Add attempt will be returned to - the client in the Add Response, defined as follows: - - AddResponse ::= [APPLICATION 9] LDAPResult - - - - - -Sermersheim Standards Track [Page 33] - -RFC 4511 LDAPv3 June 2006 - - - A response of success indicates that the new entry has been added to - the Directory. - -4.8. Delete Operation - - The Delete operation allows a client to request the removal of an - entry from the Directory. The Delete Request is defined as follows: - - DelRequest ::= [APPLICATION 10] LDAPDN - - The Delete Request consists of the name of the entry to be deleted. - The server SHALL NOT dereference aliases while resolving the name of - the target entry to be removed. - - Only leaf entries (those with no subordinate entries) can be deleted - with this operation. - - Upon receipt of a Delete Request, a server will attempt to perform - the entry removal requested and return the result in the Delete - Response defined as follows: - - DelResponse ::= [APPLICATION 11] LDAPResult - -4.9. Modify DN Operation - - The Modify DN operation allows a client to change the Relative - Distinguished Name (RDN) of an entry in the Directory and/or to move - a subtree of entries to a new location in the Directory. The Modify - DN Request is defined as follows: - - ModifyDNRequest ::= [APPLICATION 12] SEQUENCE { - entry LDAPDN, - newrdn RelativeLDAPDN, - deleteoldrdn BOOLEAN, - newSuperior [0] LDAPDN OPTIONAL } - - Fields of the Modify DN Request are: - - - entry: the name of the entry to be changed. This entry may or may - not have subordinate entries. - - - newrdn: the new RDN of the entry. The value of the old RDN is - supplied when moving the entry to a new superior without changing - its RDN. Attribute values of the new RDN not matching any - attribute value of the entry are added to the entry, and an - appropriate error is returned if this fails. - - - - - -Sermersheim Standards Track [Page 34] - -RFC 4511 LDAPv3 June 2006 - - - - deleteoldrdn: a boolean field that controls whether the old RDN - attribute values are to be retained as attributes of the entry or - deleted from the entry. - - - newSuperior: if present, this is the name of an existing object - entry that becomes the immediate superior (parent) of the - existing entry. - - The server SHALL NOT dereference any aliases in locating the objects - named in entry or newSuperior. - - Upon receipt of a ModifyDNRequest, a server will attempt to perform - the name change and return the result in the Modify DN Response, - defined as follows: - - ModifyDNResponse ::= [APPLICATION 13] LDAPResult - - For example, if the entry named in the entry field was <cn=John - Smith,c=US>, the newrdn field was <cn=John Cougar Smith>, and the - newSuperior field was absent, then this operation would attempt to - rename the entry as <cn=John Cougar Smith,c=US>. If there was - already an entry with that name, the operation would fail with the - entryAlreadyExists result code. - - Servers MUST ensure that entries conform to user and system schema - rules or other data model constraints. For attribute types that - specify no equality matching, the rules in Section 2.5.1 of [RFC4512] - are followed (this pertains to newrdn and deleteoldrdn). - - The object named in newSuperior MUST exist. For example, if the - client attempted to add <CN=JS,DC=Example,DC=NET>, the - <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did - exist, then the server would return the noSuchObject result code with - the matchedDN field containing <DC=NET>. - - If the deleteoldrdn field is TRUE, the attribute values forming the - old RDN (but not the new RDN) are deleted from the entry. If the - deleteoldrdn field is FALSE, the attribute values forming the old RDN - will be retained as non-distinguished attribute values of the entry. - - Note that X.500 restricts the ModifyDN operation to affect only - entries that are contained within a single server. If the LDAP - server is mapped onto DAP, then this restriction will apply, and the - affectsMultipleDSAs result code will be returned if this error - occurred. In general, clients MUST NOT expect to be able to perform - arbitrary movements of entries and subtrees between servers or - between naming contexts. - - - - -Sermersheim Standards Track [Page 35] - -RFC 4511 LDAPv3 June 2006 - - -4.10. Compare Operation - - The Compare operation allows a client to compare an assertion value - with the values of a particular attribute in a particular entry in - the Directory. The Compare Request is defined as follows: - - CompareRequest ::= [APPLICATION 14] SEQUENCE { - entry LDAPDN, - ava AttributeValueAssertion } - - Fields of the Compare Request are: - - - entry: the name of the entry to be compared. The server SHALL NOT - dereference any aliases in locating the entry to be compared. - - - ava: holds the attribute value assertion to be compared. - - Upon receipt of a Compare Request, a server will attempt to perform - the requested comparison and return the result in the Compare - Response, defined as follows: - - CompareResponse ::= [APPLICATION 15] LDAPResult - - The resultCode is set to compareTrue, compareFalse, or an appropriate - error. compareTrue indicates that the assertion value in the ava - field matches a value of the attribute or subtype according to the - attribute's EQUALITY matching rule. compareFalse indicates that the - assertion value in the ava field and the values of the attribute or - subtype did not match. Other result codes indicate either that the - result of the comparison was Undefined (Section 4.5.1.7), or that - some error occurred. - - Note that some directory systems may establish access controls that - permit the values of certain attributes (such as userPassword) to be - compared but not interrogated by other means. - -4.11. Abandon Operation - - The function of the Abandon operation is to allow a client to request - that the server abandon an uncompleted operation. The Abandon - Request is defined as follows: - - AbandonRequest ::= [APPLICATION 16] MessageID - - The MessageID is that of an operation that was requested earlier at - this LDAP message layer. The Abandon request itself has its own - MessageID. This is distinct from the MessageID of the earlier - operation being abandoned. - - - -Sermersheim Standards Track [Page 36] - -RFC 4511 LDAPv3 June 2006 - - - There is no response defined in the Abandon operation. Upon receipt - of an AbandonRequest, the server MAY abandon the operation identified - by the MessageID. Since the client cannot tell the difference - between a successfully abandoned operation and an uncompleted - operation, the application of the Abandon operation is limited to - uses where the client does not require an indication of its outcome. - - Abandon, Bind, Unbind, and StartTLS operations cannot be abandoned. - - In the event that a server receives an Abandon Request on a Search - operation in the midst of transmitting responses to the Search, that - server MUST cease transmitting entry responses to the abandoned - request immediately, and it MUST NOT send the SearchResultDone. Of - course, the server MUST ensure that only properly encoded LDAPMessage - PDUs are transmitted. - - The ability to abandon other (particularly update) operations is at - the discretion of the server. - - Clients should not send Abandon requests for the same operation - multiple times, and they MUST also be prepared to receive results - from operations they have abandoned (since these might have been in - transit when the Abandon was requested or might not be able to be - abandoned). - - Servers MUST discard Abandon requests for messageIDs they do not - recognize, for operations that cannot be abandoned, and for - operations that have already been abandoned. - -4.12. Extended Operation - - The Extended operation allows additional operations to be defined for - services not already available in the protocol; for example, to Add - operations to install transport layer security (see Section 4.14). - - The Extended operation allows clients to make requests and receive - responses with predefined syntaxes and semantics. These may be - defined in RFCs or be private to particular implementations. - - Each Extended operation consists of an Extended request and an - Extended response. - - ExtendedRequest ::= [APPLICATION 23] SEQUENCE { - requestName [0] LDAPOID, - requestValue [1] OCTET STRING OPTIONAL } - - - - - - -Sermersheim Standards Track [Page 37] - -RFC 4511 LDAPv3 June 2006 - - - The requestName is a dotted-decimal representation of the unique - OBJECT IDENTIFIER corresponding to the request. The requestValue is - information in a form defined by that request, encapsulated inside an - OCTET STRING. - - The server will respond to this with an LDAPMessage containing an - ExtendedResponse. - - ExtendedResponse ::= [APPLICATION 24] SEQUENCE { - COMPONENTS OF LDAPResult, - responseName [10] LDAPOID OPTIONAL, - responseValue [11] OCTET STRING OPTIONAL } - - The responseName field, when present, contains an LDAPOID that is - unique for this extended operation or response. This field is - optional (even when the extension specification defines an LDAPOID - for use in this field). The field will be absent whenever the server - is unable or unwilling to determine the appropriate LDAPOID to - return, for instance, when the requestName cannot be parsed or its - value is not recognized. - - Where the requestName is not recognized, the server returns - protocolError. (The server may return protocolError in other cases.) - - The requestValue and responseValue fields contain information - associated with the operation. The format of these fields is defined - by the specification of the Extended operation. Implementations MUST - be prepared to handle arbitrary contents of these fields, including - zero bytes. Values that are defined in terms of ASN.1 and BER- - encoded according to Section 5.1 also follow the extensibility rules - in Section 4. - - Servers list the requestName of Extended Requests they recognize in - the 'supportedExtension' attribute in the root DSE (Section 5.1 of - [RFC4512]). - - Extended operations may be specified in other documents. The - specification of an Extended operation consists of: - - - the OBJECT IDENTIFIER assigned to the requestName, - - - the OBJECT IDENTIFIER (if any) assigned to the responseName (note - that the same OBJECT IDENTIFIER may be used for both the - requestName and responseName), - - - - - - - -Sermersheim Standards Track [Page 38] - -RFC 4511 LDAPv3 June 2006 - - - - the format of the contents of the requestValue and responseValue - (if any), and - - - the semantics of the operation. - -4.13. IntermediateResponse Message - - While the Search operation provides a mechanism to return multiple - response messages for a single Search request, other operations, by - nature, do not provide for multiple response messages. - - The IntermediateResponse message provides a general mechanism for - defining single-request/multiple-response operations in LDAP. This - message is intended to be used in conjunction with the Extended - operation to define new single-request/multiple-response operations - or in conjunction with a control when extending existing LDAP - operations in a way that requires them to return Intermediate - response information. - - It is intended that the definitions and descriptions of Extended - operations and controls that make use of the IntermediateResponse - message will define the circumstances when an IntermediateResponse - message can be sent by a server and the associated meaning of an - IntermediateResponse message sent in a particular circumstance. - - IntermediateResponse ::= [APPLICATION 25] SEQUENCE { - responseName [0] LDAPOID OPTIONAL, - responseValue [1] OCTET STRING OPTIONAL } - - IntermediateResponse messages SHALL NOT be returned to the client - unless the client issues a request that specifically solicits their - return. This document defines two forms of solicitation: Extended - operation and request control. IntermediateResponse messages are - specified in documents describing the manner in which they are - solicited (i.e., in the Extended operation or request control - specification that uses them). These specifications include: - - - the OBJECT IDENTIFIER (if any) assigned to the responseName, - - - the format of the contents of the responseValue (if any), and - - - the semantics associated with the IntermediateResponse message. - - Extensions that allow the return of multiple types of - IntermediateResponse messages SHALL identify those types using unique - responseName values (note that one of these may specify no value). - - - - - -Sermersheim Standards Track [Page 39] - -RFC 4511 LDAPv3 June 2006 - - - Sections 4.13.1 and 4.13.2 describe additional requirements on the - inclusion of responseName and responseValue in IntermediateResponse - messages. - -4.13.1. Usage with LDAP ExtendedRequest and ExtendedResponse - - A single-request/multiple-response operation may be defined using a - single ExtendedRequest message to solicit zero or more - IntermediateResponse messages of one or more kinds, followed by an - ExtendedResponse message. - -4.13.2. Usage with LDAP Request Controls - - A control's semantics may include the return of zero or more - IntermediateResponse messages prior to returning the final result - code for the operation. One or more kinds of IntermediateResponse - messages may be sent in response to a request control. - - All IntermediateResponse messages associated with request controls - SHALL include a responseName. This requirement ensures that the - client can correctly identify the source of IntermediateResponse - messages when: - - - two or more controls using IntermediateResponse messages are - included in a request for any LDAP operation or - - - one or more controls using IntermediateResponse messages are - included in a request with an LDAP Extended operation that uses - IntermediateResponse messages. - -4.14. StartTLS Operation - - The Start Transport Layer Security (StartTLS) operation's purpose is - to initiate installation of a TLS layer. The StartTLS operation is - defined using the Extended operation mechanism described in Section - 4.12. - -4.14.1. StartTLS Request - - A client requests TLS establishment by transmitting a StartTLS - request message to the server. The StartTLS request is defined in - terms of an ExtendedRequest. The requestName is - "1.3.6.1.4.1.1466.20037", and the requestValue field is always - absent. - - - - - - - -Sermersheim Standards Track [Page 40] - -RFC 4511 LDAPv3 June 2006 - - - The client MUST NOT send any LDAP PDUs at this LDAP message layer - following this request until it receives a StartTLS Extended response - and, in the case of a successful response, completes TLS - negotiations. - - Detected sequencing problems (particularly those detailed in Section - 3.1.1 of [RFC4513]) result in the resultCode being set to - operationsError. - - If the server does not support TLS (whether by design or by current - configuration), it returns with the resultCode set to protocolError - as described in Section 4.12. - -4.14.2. StartTLS Response - - When a StartTLS request is received, servers supporting the operation - MUST return a StartTLS response message to the requestor. The - responseName is "1.3.6.1.4.1.1466.20037" when provided (see Section - 4.12). The responseValue is always absent. - - If the server is willing and able to negotiate TLS, it returns the - StartTLS response with the resultCode set to success. Upon client - receipt of a successful StartTLS response, protocol peers may - commence with TLS negotiation as discussed in Section 3 of [RFC4513]. - - If the server is otherwise unwilling or unable to perform this - operation, the server is to return an appropriate result code - indicating the nature of the problem. For example, if the TLS - subsystem is not presently available, the server may indicate this by - returning with the resultCode set to unavailable. In cases where a - non-success result code is returned, the LDAP session is left without - a TLS layer. - -4.14.3. Removal of the TLS Layer - - Either the client or server MAY remove the TLS layer and leave the - LDAP message layer intact by sending and receiving a TLS closure - alert. - - The initiating protocol peer sends the TLS closure alert and MUST - wait until it receives a TLS closure alert from the other peer before - sending further LDAP PDUs. - - When a protocol peer receives the initial TLS closure alert, it may - choose to allow the LDAP message layer to remain intact. In this - case, it MUST immediately transmit a TLS closure alert. Following - this, it MAY send and receive LDAP PDUs. - - - - -Sermersheim Standards Track [Page 41] - -RFC 4511 LDAPv3 June 2006 - - - Protocol peers MAY terminate the LDAP session after sending or - receiving a TLS closure alert. - -5. Protocol Encoding, Connection, and Transfer - - This protocol is designed to run over connection-oriented, reliable - transports, where the data stream is divided into octets (8-bit - units), with each octet and each bit being significant. - - One underlying service, LDAP over TCP, is defined in Section 5.2. - This service is generally applicable to applications providing or - consuming X.500-based directory services on the Internet. This - specification was generally written with the TCP mapping in mind. - Specifications detailing other mappings may encounter various - obstacles. - - Implementations of LDAP over TCP MUST implement the mapping as - described in Section 5.2. - - This table illustrates the relationship among the different layers - involved in an exchange between two protocol peers: - - +----------------------+ - | LDAP message layer | - +----------------------+ > LDAP PDUs - +----------------------+ < data - | SASL layer | - +----------------------+ > SASL-protected data - +----------------------+ < data - | TLS layer | - Application +----------------------+ > TLS-protected data - ------------+----------------------+ < data - Transport | transport connection | - +----------------------+ - -5.1. Protocol Encoding - - The protocol elements of LDAP SHALL be encoded for exchange using the - Basic Encoding Rules [BER] of [ASN.1] with the following - restrictions: - - - Only the definite form of length encoding is used. - - - OCTET STRING values are encoded in the primitive form only. - - - If the value of a BOOLEAN type is true, the encoding of the value - octet is set to hex "FF". - - - - -Sermersheim Standards Track [Page 42] - -RFC 4511 LDAPv3 June 2006 - - - - If a value of a type is its default value, it is absent. Only some - BOOLEAN and INTEGER types have default values in this protocol - definition. - - These restrictions are meant to ease the overhead of encoding and - decoding certain elements in BER. - - These restrictions do not apply to ASN.1 types encapsulated inside of - OCTET STRING values, such as attribute values, unless otherwise - stated. - -5.2. Transmission Control Protocol (TCP) - - The encoded LDAPMessage PDUs are mapped directly onto the TCP - [RFC793] bytestream using the BER-based encoding described in Section - 5.1. It is recommended that server implementations running over the - TCP provide a protocol listener on the Internet Assigned Numbers - Authority (IANA)-assigned LDAP port, 389 [PortReg]. Servers may - instead provide a listener on a different port number. Clients MUST - support contacting servers on any valid TCP port. - -5.3. Termination of the LDAP session - - Termination of the LDAP session is typically initiated by the client - sending an UnbindRequest (Section 4.3), or by the server sending a - Notice of Disconnection (Section 4.4.1). In these cases, each - protocol peer gracefully terminates the LDAP session by ceasing - exchanges at the LDAP message layer, tearing down any SASL layer, - tearing down any TLS layer, and closing the transport connection. - - A protocol peer may determine that the continuation of any - communication would be pernicious, and in this case, it may abruptly - terminate the session by ceasing communication and closing the - transport connection. - - In either case, when the LDAP session is terminated, uncompleted - operations are handled as specified in Section 3.1. - -6. Security Considerations - - This version of the protocol provides facilities for simple - authentication using a cleartext password, as well as any SASL - [RFC4422] mechanism. Installing SASL and/or TLS layers can provide - integrity and other data security services. - - It is also permitted that the server can return its credentials to - the client, if it chooses to do so. - - - - -Sermersheim Standards Track [Page 43] - -RFC 4511 LDAPv3 June 2006 - - - Use of cleartext password is strongly discouraged where the - underlying transport service cannot guarantee confidentiality and may - result in disclosure of the password to unauthorized parties. - - Servers are encouraged to prevent directory modifications by clients - that have authenticated anonymously [RFC4513]. - - Security considerations for authentication methods, SASL mechanisms, - and TLS are described in [RFC4513]. - - Note that SASL authentication exchanges do not provide data - confidentiality or integrity protection for the version or name - fields of the BindRequest or the resultCode, diagnosticMessage, or - referral fields of the BindResponse, nor for any information - contained in controls attached to Bind requests or responses. Thus, - information contained in these fields SHOULD NOT be relied on unless - it is otherwise protected (such as by establishing protections at the - transport layer). - - Implementors should note that various security factors (including - authentication and authorization information and data security - services) may change during the course of the LDAP session or even - during the performance of a particular operation. For instance, - credentials could expire, authorization identities or access controls - could change, or the underlying security layer(s) could be replaced - or terminated. Implementations should be robust in the handling of - changing security factors. - - In some cases, it may be appropriate to continue the operation even - in light of security factor changes. For instance, it may be - appropriate to continue an Abandon operation regardless of the - change, or to continue an operation when the change upgraded (or - maintained) the security factor. In other cases, it may be - appropriate to fail or alter the processing of the operation. For - instance, if confidential protections were removed, it would be - appropriate either to fail a request to return sensitive data or, - minimally, to exclude the return of sensitive data. - - Implementations that cache attributes and entries obtained via LDAP - MUST ensure that access controls are maintained if that information - is to be provided to multiple clients, since servers may have access - control policies that prevent the return of entries or attributes in - Search results except to particular authenticated clients. For - example, caches could serve result information only to the client - whose request caused it to be in the cache. - - - - - - -Sermersheim Standards Track [Page 44] - -RFC 4511 LDAPv3 June 2006 - - - Servers may return referrals or Search result references that - redirect clients to peer servers. It is possible for a rogue - application to inject such referrals into the data stream in an - attempt to redirect a client to a rogue server. Clients are advised - to be aware of this and possibly reject referrals when - confidentiality measures are not in place. Clients are advised to - reject referrals from the StartTLS operation. - - The matchedDN and diagnosticMessage fields, as well as some - resultCode values (e.g., attributeOrValueExists and - entryAlreadyExists), could disclose the presence or absence of - specific data in the directory that is subject to access and other - administrative controls. Server implementations should restrict - access to protected information equally under both normal and error - conditions. - - Protocol peers MUST be prepared to handle invalid and arbitrary- - length protocol encodings. Invalid protocol encodings include: BER - encoding exceptions, format string and UTF-8 encoding exceptions, - overflow exceptions, integer value exceptions, and binary mode on/off - flag exceptions. The LDAPv3 PROTOS [PROTOS-LDAP] test suite provides - excellent examples of these exceptions and test cases used to - discover flaws. - - In the event that a protocol peer senses an attack that in its nature - could cause damage due to further communication at any layer in the - LDAP session, the protocol peer should abruptly terminate the LDAP - session as described in Section 5.3. - -7. Acknowledgements - - This document is based on RFC 2251 by Mark Wahl, Tim Howes, and Steve - Kille. RFC 2251 was a product of the IETF ASID Working Group. - - It is also based on RFC 2830 by Jeff Hodges, RL "Bob" Morgan, and - Mark Wahl. RFC 2830 was a product of the IETF LDAPEXT Working Group. - - It is also based on RFC 3771 by Roger Harrison and Kurt Zeilenga. - RFC 3771 was an individual submission to the IETF. - - This document is a product of the IETF LDAPBIS Working Group. - Significant contributors of technical review and content include Kurt - Zeilenga, Steven Legg, and Hallvard Furuseth. - - - - - - - - -Sermersheim Standards Track [Page 45] - -RFC 4511 LDAPv3 June 2006 - - -8. Normative References - - [ASN.1] ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824- - 1:2002 "Information Technology - Abstract Syntax - Notation One (ASN.1): Specification of basic notation". - - [BER] ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002, - "Information technology - ASN.1 encoding rules: - Specification of Basic Encoding Rules (BER), Canonical - Encoding Rules (CER) and Distinguished Encoding Rules - (DER)", 2002. - - [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) - - Architecture and Basic Multilingual Plane, ISO/IEC - 10646-1 : 1993. - - [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, - September 1981. - - [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC - 793, September 1981. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC3454] Hoffman P. and M. Blanchet, "Preparation of - Internationalized Strings ('stringprep')", RFC 3454, - December 2002. - - [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO - 10646", STD 63, RFC 3629, November 2003. - - [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, - "Uniform Resource Identifier (URI): Generic Syntax", - STD 66, RFC 3986, January 2005. - - [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User - Names and Passwords", RFC 4013, February 2005. - - [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 4234, October 2005. - - [RFC4346] Dierks, T. and E. Rescorla, "The TLS Protocol Version - 1.1", RFC 4346, March 2006. - - [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple - Authentication and Security Layer (SASL)", RFC 4422, - June 2006. - - - -Sermersheim Standards Track [Page 46] - -RFC 4511 LDAPv3 June 2006 - - - [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access - Protocol (LDAP): Technical Specification Road Map", RFC - 4510, June 2006. - - [RFC4512] Zeilenga, K., Lightweight Directory Access Protocol - (LDAP): Directory Information Models", RFC 4512, June - 2006. - - [RFC4513] Harrison, R., Ed., "Lightweight Directory Access - Protocol (LDAP): Authentication Methods and Security - Mechanisms", RFC 4513, June 2006. - - [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access - Protocol (LDAP): String Representation of Distinguished - Names", RFC 4514, June 2006. - - [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory - Access Protocol (LDAP): Uniform Resource Locator", RFC - 4516, June 2006. - - [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol - (LDAP): Syntaxes and Matching Rules", RFC 4517, June - 2006. - - [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority - (IANA) Considerations for the Lightweight Directory - Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. - - [Unicode] The Unicode Consortium, "The Unicode Standard, Version - 3.2.0" is defined by "The Unicode Standard, Version - 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201- - 61633-5), as amended by the "Unicode Standard Annex - #27: Unicode 3.1" - (http://www.unicode.org/reports/tr27/) and by the - "Unicode Standard Annex #28: Unicode 3.2" - (http://www.unicode.org/reports/tr28/). - - [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts, - Models and Service", 1993. - - [X.511] ITU-T Rec. X.511, "The Directory: Abstract Service - Definition", 1993. - - - - - - - - - -Sermersheim Standards Track [Page 47] - -RFC 4511 LDAPv3 June 2006 - - -9. Informative References - - [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report - #17, Character Encoding Model", UTR17, - <http://www.unicode.org/unicode/reports/tr17/>, August - 2000. - - [Glossary] The Unicode Consortium, "Unicode Glossary", - <http://www.unicode.org/glossary/>. - - [PortReg] IANA, "Port Numbers", - <http://www.iana.org/assignments/port-numbers>. - - [PROTOS-LDAP] University of Oulu, "PROTOS Test-Suite: c06-ldapv3" - <http://www.ee.oulu.fi/research/ouspg/protos/testing/ - c06/ldapv3/>. - -10. IANA Considerations - - The Internet Assigned Numbers Authority (IANA) has updated the LDAP - result code registry to indicate that this document provides the - definitive technical specification for result codes 0-36, 48-54, 64- - 70, 80-90. It is also noted that one resultCode value - (strongAuthRequired) has been renamed (to strongerAuthRequired). - - The IANA has also updated the LDAP Protocol Mechanism registry to - indicate that this document and [RFC4513] provides the definitive - technical specification for the StartTLS (1.3.6.1.4.1.1466.20037) - Extended operation. - - IANA has assigned LDAP Object Identifier 18 [RFC4520] to identify the - ASN.1 module defined in this document. - - Subject: Request for LDAP Object Identifier Registration - Person & email address to contact for further information: - Jim Sermersheim <jimse@novell.com> - Specification: RFC 4511 - Author/Change Controller: IESG - Comments: - Identifies the LDAP ASN.1 module - - - - - - - - - - - -Sermersheim Standards Track [Page 48] - -RFC 4511 LDAPv3 June 2006 - - -Appendix A. LDAP Result Codes - - This normative appendix details additional considerations regarding - LDAP result codes and provides a brief, general description of each - LDAP result code enumerated in Section 4.1.9. - - Additional result codes MAY be defined for use with extensions - [RFC4520]. Client implementations SHALL treat any result code that - they do not recognize as an unknown error condition. - - The descriptions provided here do not fully account for result code - substitutions used to prevent unauthorized disclosures (such as - substitution of noSuchObject for insufficientAccessRights, or - invalidCredentials for insufficientAccessRights). - -A.1. Non-Error Result Codes - - These result codes (called "non-error" result codes) do not indicate - an error condition: - - success (0), - compareFalse (5), - compareTrue (6), - referral (10), and - saslBindInProgress (14). - - The success, compareTrue, and compareFalse result codes indicate - successful completion (and, hence, are referred to as "successful" - result codes). - - The referral and saslBindInProgress result codes indicate the client - needs to take additional action to complete the operation. - -A.2. Result Codes - - Existing LDAP result codes are described as follows: - - success (0) - Indicates the successful completion of an operation. Note: - this code is not used with the Compare operation. See - compareFalse (5) and compareTrue (6). - - - - - - - - - - -Sermersheim Standards Track [Page 49] - -RFC 4511 LDAPv3 June 2006 - - - operationsError (1) - Indicates that the operation is not properly sequenced with - relation to other operations (of same or different type). - - For example, this code is returned if the client attempts to - StartTLS [RFC4346] while there are other uncompleted operations - or if a TLS layer was already installed. - - protocolError (2) - Indicates the server received data that is not well-formed. - - For Bind operation only, this code is also used to indicate - that the server does not support the requested protocol - version. - - For Extended operations only, this code is also used to - indicate that the server does not support (by design or - configuration) the Extended operation associated with the - requestName. - - For request operations specifying multiple controls, this may - be used to indicate that the server cannot ignore the order - of the controls as specified, or that the combination of the - specified controls is invalid or unspecified. - - timeLimitExceeded (3) - Indicates that the time limit specified by the client was - exceeded before the operation could be completed. - - sizeLimitExceeded (4) - Indicates that the size limit specified by the client was - exceeded before the operation could be completed. - - compareFalse (5) - Indicates that the Compare operation has successfully - completed and the assertion has evaluated to FALSE or - Undefined. - - compareTrue (6) - Indicates that the Compare operation has successfully - completed and the assertion has evaluated to TRUE. - - authMethodNotSupported (7) - Indicates that the authentication method or mechanism is not - supported. - - - - - - -Sermersheim Standards Track [Page 50] - -RFC 4511 LDAPv3 June 2006 - - - strongerAuthRequired (8) - Indicates the server requires strong(er) authentication in - order to complete the operation. - - When used with the Notice of Disconnection operation, this - code indicates that the server has detected that an - established security association between the client and - server has unexpectedly failed or been compromised. - - referral (10) - Indicates that a referral needs to be chased to complete the - operation (see Section 4.1.10). - - adminLimitExceeded (11) - Indicates that an administrative limit has been exceeded. - - unavailableCriticalExtension (12) - Indicates a critical control is unrecognized (see Section - 4.1.11). - - confidentialityRequired (13) - Indicates that data confidentiality protections are required. - - saslBindInProgress (14) - Indicates the server requires the client to send a new bind - request, with the same SASL mechanism, to continue the - authentication process (see Section 4.2). - - noSuchAttribute (16) - Indicates that the named entry does not contain the specified - attribute or attribute value. - - undefinedAttributeType (17) - Indicates that a request field contains an unrecognized - attribute description. - - inappropriateMatching (18) - Indicates that an attempt was made (e.g., in an assertion) to - use a matching rule not defined for the attribute type - concerned. - - constraintViolation (19) - Indicates that the client supplied an attribute value that - does not conform to the constraints placed upon it by the - data model. - - For example, this code is returned when multiple values are - supplied to an attribute that has a SINGLE-VALUE constraint. - - - -Sermersheim Standards Track [Page 51] - -RFC 4511 LDAPv3 June 2006 - - - attributeOrValueExists (20) - Indicates that the client supplied an attribute or value to - be added to an entry, but the attribute or value already - exists. - - invalidAttributeSyntax (21) - Indicates that a purported attribute value does not conform - to the syntax of the attribute. - - noSuchObject (32) - Indicates that the object does not exist in the DIT. - - aliasProblem (33) - Indicates that an alias problem has occurred. For example, - the code may used to indicate an alias has been dereferenced - that names no object. - - invalidDNSyntax (34) - Indicates that an LDAPDN or RelativeLDAPDN field (e.g., search - base, target entry, ModifyDN newrdn, etc.) of a request does - not conform to the required syntax or contains attribute - values that do not conform to the syntax of the attribute's - type. - - aliasDereferencingProblem (36) - Indicates that a problem occurred while dereferencing an - alias. Typically, an alias was encountered in a situation - where it was not allowed or where access was denied. - - inappropriateAuthentication (48) - Indicates the server requires the client that had attempted - to bind anonymously or without supplying credentials to - provide some form of credentials. - - invalidCredentials (49) - Indicates that the provided credentials (e.g., the user's name - and password) are invalid. - - insufficientAccessRights (50) - Indicates that the client does not have sufficient access - rights to perform the operation. - - busy (51) - Indicates that the server is too busy to service the - operation. - - - - - - -Sermersheim Standards Track [Page 52] - -RFC 4511 LDAPv3 June 2006 - - - unavailable (52) - Indicates that the server is shutting down or a subsystem - necessary to complete the operation is offline. - - unwillingToPerform (53) - Indicates that the server is unwilling to perform the - operation. - - loopDetect (54) - Indicates that the server has detected an internal loop (e.g., - while dereferencing aliases or chaining an operation). - - namingViolation (64) - Indicates that the entry's name violates naming restrictions. - - objectClassViolation (65) - Indicates that the entry violates object class restrictions. - - notAllowedOnNonLeaf (66) - Indicates that the operation is inappropriately acting upon a - non-leaf entry. - - notAllowedOnRDN (67) - Indicates that the operation is inappropriately attempting to - remove a value that forms the entry's relative distinguished - name. - - entryAlreadyExists (68) - Indicates that the request cannot be fulfilled (added, moved, - or renamed) as the target entry already exists. - - objectClassModsProhibited (69) - Indicates that an attempt to modify the object class(es) of - an entry's 'objectClass' attribute is prohibited. - - For example, this code is returned when a client attempts to - modify the structural object class of an entry. - - affectsMultipleDSAs (71) - Indicates that the operation cannot be performed as it would - affect multiple servers (DSAs). - - other (80) - Indicates the server has encountered an internal error. - - - - - - - -Sermersheim Standards Track [Page 53] - -RFC 4511 LDAPv3 June 2006 - - -Appendix B. Complete ASN.1 Definition - - This appendix is normative. - - Lightweight-Directory-Access-Protocol-V3 {1 3 6 1 1 18} - -- Copyright (C) The Internet Society (2006). This version of - -- this ASN.1 module is part of RFC 4511; see the RFC itself - -- for full legal notices. - DEFINITIONS - IMPLICIT TAGS - EXTENSIBILITY IMPLIED ::= - - BEGIN - - LDAPMessage ::= SEQUENCE { - messageID MessageID, - protocolOp CHOICE { - bindRequest BindRequest, - bindResponse BindResponse, - unbindRequest UnbindRequest, - searchRequest SearchRequest, - searchResEntry SearchResultEntry, - searchResDone SearchResultDone, - searchResRef SearchResultReference, - modifyRequest ModifyRequest, - modifyResponse ModifyResponse, - addRequest AddRequest, - addResponse AddResponse, - delRequest DelRequest, - delResponse DelResponse, - modDNRequest ModifyDNRequest, - modDNResponse ModifyDNResponse, - compareRequest CompareRequest, - compareResponse CompareResponse, - abandonRequest AbandonRequest, - extendedReq ExtendedRequest, - extendedResp ExtendedResponse, - ..., - intermediateResponse IntermediateResponse }, - controls [0] Controls OPTIONAL } - - MessageID ::= INTEGER (0 .. maxInt) - - maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- - - LDAPString ::= OCTET STRING -- UTF-8 encoded, - -- [ISO10646] characters - - - - -Sermersheim Standards Track [Page 54] - -RFC 4511 LDAPv3 June 2006 - - - LDAPOID ::= OCTET STRING -- Constrained to <numericoid> - -- [RFC4512] - - LDAPDN ::= LDAPString -- Constrained to <distinguishedName> - -- [RFC4514] - - RelativeLDAPDN ::= LDAPString -- Constrained to <name-component> - -- [RFC4514] - - AttributeDescription ::= LDAPString - -- Constrained to <attributedescription> - -- [RFC4512] - - AttributeValue ::= OCTET STRING - - AttributeValueAssertion ::= SEQUENCE { - attributeDesc AttributeDescription, - assertionValue AssertionValue } - - AssertionValue ::= OCTET STRING - - PartialAttribute ::= SEQUENCE { - type AttributeDescription, - vals SET OF value AttributeValue } - - Attribute ::= PartialAttribute(WITH COMPONENTS { - ..., - vals (SIZE(1..MAX))}) - - MatchingRuleId ::= LDAPString - - LDAPResult ::= SEQUENCE { - resultCode ENUMERATED { - success (0), - operationsError (1), - protocolError (2), - timeLimitExceeded (3), - sizeLimitExceeded (4), - compareFalse (5), - compareTrue (6), - authMethodNotSupported (7), - strongerAuthRequired (8), - -- 9 reserved -- - referral (10), - adminLimitExceeded (11), - unavailableCriticalExtension (12), - confidentialityRequired (13), - saslBindInProgress (14), - - - -Sermersheim Standards Track [Page 55] - -RFC 4511 LDAPv3 June 2006 - - - noSuchAttribute (16), - undefinedAttributeType (17), - inappropriateMatching (18), - constraintViolation (19), - attributeOrValueExists (20), - invalidAttributeSyntax (21), - -- 22-31 unused -- - noSuchObject (32), - aliasProblem (33), - invalidDNSyntax (34), - -- 35 reserved for undefined isLeaf -- - aliasDereferencingProblem (36), - -- 37-47 unused -- - inappropriateAuthentication (48), - invalidCredentials (49), - insufficientAccessRights (50), - busy (51), - unavailable (52), - unwillingToPerform (53), - loopDetect (54), - -- 55-63 unused -- - namingViolation (64), - objectClassViolation (65), - notAllowedOnNonLeaf (66), - notAllowedOnRDN (67), - entryAlreadyExists (68), - objectClassModsProhibited (69), - -- 70 reserved for CLDAP -- - affectsMultipleDSAs (71), - -- 72-79 unused -- - other (80), - ... }, - matchedDN LDAPDN, - diagnosticMessage LDAPString, - referral [3] Referral OPTIONAL } - - Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI - - URI ::= LDAPString -- limited to characters permitted in - -- URIs - - Controls ::= SEQUENCE OF control Control - - Control ::= SEQUENCE { - controlType LDAPOID, - criticality BOOLEAN DEFAULT FALSE, - controlValue OCTET STRING OPTIONAL } - - - - -Sermersheim Standards Track [Page 56] - -RFC 4511 LDAPv3 June 2006 - - - BindRequest ::= [APPLICATION 0] SEQUENCE { - version INTEGER (1 .. 127), - name LDAPDN, - authentication AuthenticationChoice } - - AuthenticationChoice ::= CHOICE { - simple [0] OCTET STRING, - -- 1 and 2 reserved - sasl [3] SaslCredentials, - ... } - - SaslCredentials ::= SEQUENCE { - mechanism LDAPString, - credentials OCTET STRING OPTIONAL } - - BindResponse ::= [APPLICATION 1] SEQUENCE { - COMPONENTS OF LDAPResult, - serverSaslCreds [7] OCTET STRING OPTIONAL } - - UnbindRequest ::= [APPLICATION 2] NULL - - SearchRequest ::= [APPLICATION 3] SEQUENCE { - baseObject LDAPDN, - scope ENUMERATED { - baseObject (0), - singleLevel (1), - wholeSubtree (2), - ... }, - derefAliases ENUMERATED { - neverDerefAliases (0), - derefInSearching (1), - derefFindingBaseObj (2), - derefAlways (3) }, - sizeLimit INTEGER (0 .. maxInt), - timeLimit INTEGER (0 .. maxInt), - typesOnly BOOLEAN, - filter Filter, - attributes AttributeSelection } - - AttributeSelection ::= SEQUENCE OF selector LDAPString - -- The LDAPString is constrained to - -- <attributeSelector> in Section 4.5.1.8 - - Filter ::= CHOICE { - and [0] SET SIZE (1..MAX) OF filter Filter, - or [1] SET SIZE (1..MAX) OF filter Filter, - not [2] Filter, - equalityMatch [3] AttributeValueAssertion, - - - -Sermersheim Standards Track [Page 57] - -RFC 4511 LDAPv3 June 2006 - - - substrings [4] SubstringFilter, - greaterOrEqual [5] AttributeValueAssertion, - lessOrEqual [6] AttributeValueAssertion, - present [7] AttributeDescription, - approxMatch [8] AttributeValueAssertion, - extensibleMatch [9] MatchingRuleAssertion, - ... } - - SubstringFilter ::= SEQUENCE { - type AttributeDescription, - substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE { - initial [0] AssertionValue, -- can occur at most once - any [1] AssertionValue, - final [2] AssertionValue } -- can occur at most once - } - - MatchingRuleAssertion ::= SEQUENCE { - matchingRule [1] MatchingRuleId OPTIONAL, - type [2] AttributeDescription OPTIONAL, - matchValue [3] AssertionValue, - dnAttributes [4] BOOLEAN DEFAULT FALSE } - - SearchResultEntry ::= [APPLICATION 4] SEQUENCE { - objectName LDAPDN, - attributes PartialAttributeList } - - PartialAttributeList ::= SEQUENCE OF - partialAttribute PartialAttribute - - SearchResultReference ::= [APPLICATION 19] SEQUENCE - SIZE (1..MAX) OF uri URI - - SearchResultDone ::= [APPLICATION 5] LDAPResult - - ModifyRequest ::= [APPLICATION 6] SEQUENCE { - object LDAPDN, - changes SEQUENCE OF change SEQUENCE { - operation ENUMERATED { - add (0), - delete (1), - replace (2), - ... }, - modification PartialAttribute } } - - ModifyResponse ::= [APPLICATION 7] LDAPResult - - - - - - -Sermersheim Standards Track [Page 58] - -RFC 4511 LDAPv3 June 2006 - - - AddRequest ::= [APPLICATION 8] SEQUENCE { - entry LDAPDN, - attributes AttributeList } - - AttributeList ::= SEQUENCE OF attribute Attribute - - AddResponse ::= [APPLICATION 9] LDAPResult - - DelRequest ::= [APPLICATION 10] LDAPDN - - DelResponse ::= [APPLICATION 11] LDAPResult - - ModifyDNRequest ::= [APPLICATION 12] SEQUENCE { - entry LDAPDN, - newrdn RelativeLDAPDN, - deleteoldrdn BOOLEAN, - newSuperior [0] LDAPDN OPTIONAL } - - ModifyDNResponse ::= [APPLICATION 13] LDAPResult - - CompareRequest ::= [APPLICATION 14] SEQUENCE { - entry LDAPDN, - ava AttributeValueAssertion } - - CompareResponse ::= [APPLICATION 15] LDAPResult - - AbandonRequest ::= [APPLICATION 16] MessageID - - ExtendedRequest ::= [APPLICATION 23] SEQUENCE { - requestName [0] LDAPOID, - requestValue [1] OCTET STRING OPTIONAL } - - ExtendedResponse ::= [APPLICATION 24] SEQUENCE { - COMPONENTS OF LDAPResult, - responseName [10] LDAPOID OPTIONAL, - responseValue [11] OCTET STRING OPTIONAL } - - IntermediateResponse ::= [APPLICATION 25] SEQUENCE { - responseName [0] LDAPOID OPTIONAL, - responseValue [1] OCTET STRING OPTIONAL } - - END - - - - - - - - - -Sermersheim Standards Track [Page 59] - -RFC 4511 LDAPv3 June 2006 - - -Appendix C. Changes - - This appendix is non-normative. - - This appendix summarizes substantive changes made to RFC 2251, RFC - 2830, and RFC 3771. - -C.1. Changes Made to RFC 2251 - - This section summarizes the substantive changes made to Sections 1, - 2, 3.1, and 4, and the remainder of RFC 2251. Readers should - consult [RFC4512] and [RFC4513] for summaries of changes to other - sections. - -C.1.1. Section 1 (Status of this Memo) - - - Removed IESG note. Post publication of RFC 2251, mandatory LDAP - authentication mechanisms have been standardized which are - sufficient to remove this note. See [RFC4513] for authentication - mechanisms. - -C.1.2. Section 3.1 (Protocol Model) and others - - - Removed notes giving history between LDAP v1, v2, and v3. Instead, - added sufficient language so that this document can stand on its - own. - -C.1.3. Section 4 (Elements of Protocol) - - - Clarified where the extensibility features of ASN.1 apply to the - protocol. This change affected various ASN.1 types by the - inclusion of ellipses (...) to certain elements. - - Removed the requirement that servers that implement version 3 or - later MUST provide the 'supportedLDAPVersion' attribute. This - statement provided no interoperability advantages. - -C.1.4. Section 4.1.1 (Message Envelope) - - - There was a mandatory requirement for the server to return a - Notice of Disconnection and drop the transport connection when a - PDU is malformed in a certain way. This has been updated such that - the server SHOULD return the Notice of Disconnection, and it MUST - terminate the LDAP Session. - -C.1.5. Section 4.1.1.1 (Message ID) - - - Required that the messageID of requests MUST be non-zero as the - zero is reserved for Notice of Disconnection. - - - -Sermersheim Standards Track [Page 60] - -RFC 4511 LDAPv3 June 2006 - - - - Specified when it is and isn't appropriate to return an already - used messageID. RFC 2251 accidentally imposed synchronous server - behavior in its wording of this. - -C.1.6. Section 4.1.2 (String Types) - - - Stated that LDAPOID is constrained to <numericoid> from [RFC4512]. - -C.1.7. Section 4.1.5.1 (Binary Option) and others - - - Removed the Binary Option from the specification. There are - numerous interoperability problems associated with this method of - alternate attribute type encoding. Work to specify a suitable - replacement is ongoing. - -C.1.8. Section 4.1.8 (Attribute) - - - Combined the definitions of PartialAttribute and Attribute here, - and defined Attribute in terms of PartialAttribute. - -C.1.9. Section 4.1.10 (Result Message) - - - Renamed "errorMessage" to "diagnosticMessage" as it is allowed to - be sent for non-error results. - - Moved some language into Appendix A, and referred the reader there. - - Allowed matchedDN to be present for other result codes than those - listed in RFC 2251. - - Renamed the code "strongAuthRequired" to "strongerAuthRequired" to - clarify that this code may often be returned to indicate that a - stronger authentication is needed to perform a given operation. - -C.1.10. Section 4.1.11 (Referral) - - - Defined referrals in terms of URIs rather than URLs. - - Removed the requirement that all referral URIs MUST be equally - capable of progressing the operation. The statement was ambiguous - and provided no instructions on how to carry it out. - - Added the requirement that clients MUST NOT loop between servers. - - Clarified the instructions for using LDAPURLs in referrals, and in - doing so added a recommendation that the scope part be present. - - Removed imperatives which required clients to use URLs in specific - ways to progress an operation. These did nothing for - interoperability. - - - - - - - - -Sermersheim Standards Track [Page 61] - -RFC 4511 LDAPv3 June 2006 - - -C.1.11. Section 4.1.12 (Controls) - - - Specified how control values defined in terms of ASN.1 are to be - encoded. - - Noted that the criticality field is only applied to request - messages (except UnbindRequest), and must be ignored when present - on response messages and UnbindRequest. - - Specified that non-critical controls may be ignored at the - server's discretion. There was confusion in the original wording - which led some to believe that recognized controls may not be - ignored as long as they were associated with a proper request. - - Added language regarding combinations of controls and the ordering - of controls on a message. - - Specified that when the semantics of the combination of controls - is undefined or unknown, it results in a protocolError. - - Changed "The server MUST be prepared" to "Implementations MUST be - prepared" in paragraph 8 to reflect that both client and server - implementations must be able to handle this (as both parse - controls). - -C.1.12. Section 4.2 (Bind Operation) - - - Mandated that servers return protocolError when the version is not - supported. - - Disambiguated behavior when the simple authentication is used, the - name is empty, and the password is non-empty. - - Required servers to not dereference aliases for Bind. This was - added for consistency with other operations and to help ensure - data consistency. - - Required that textual passwords be transferred as UTF-8 encoded - Unicode, and added recommendations on string preparation. This was - to help ensure interoperability of passwords being sent from - different clients. - -C.1.13. Section 4.2.1 (Sequencing of the Bind Request) - - - This section was largely reorganized for readability, and language - was added to clarify the authentication state of failed and - abandoned Bind operations. - - Removed: "If a SASL transfer encryption or integrity mechanism has - been negotiated, that mechanism does not support the changing of - credentials from one identity to another, then the client MUST - instead establish a new connection." - If there are dependencies between multiple negotiations of a - particular SASL mechanism, the technical specification for that - SASL mechanism details how applications are to deal with them. - LDAP should not require any special handling. - - Dropped MUST imperative in paragraph 3 to align with [RFC2119]. - - - -Sermersheim Standards Track [Page 62] - -RFC 4511 LDAPv3 June 2006 - - - - Mandated that clients not send non-Bind operations while a Bind is - in progress, and suggested that servers not process them if they - are received. This is needed to ensure proper sequencing of the - Bind in relationship to other operations. - -C.1.14. Section 4.2.3 (Bind Response) - - - Moved most error-related text to Appendix A, and added text - regarding certain errors used in conjunction with the Bind - operation. - - Prohibited the server from specifying serverSaslCreds when not - appropriate. - -C.1.15. Section 4.3 (Unbind Operation) - - - Specified that both peers are to cease transmission and terminate - the LDAP session for the Unbind operation. - -C.1.16. Section 4.4 (Unsolicited Notification) - - - Added instructions for future specifications of Unsolicited - Notifications. - -C.1.17. Section 4.5.1 (Search Request) - - - SearchRequest attributes is now defined as an AttributeSelection - type rather than AttributeDescriptionList, and an ABNF is - provided. - - SearchRequest attributes may contain duplicate attribute - descriptions. This was previously prohibited. Now servers are - instructed to ignore subsequent names when they are duplicated. - This was relaxed in order to allow different short names and also - OIDs to be requested for an attribute. - - The present search filter now evaluates to Undefined when the - specified attribute is not known to the server. It used to - evaluate to FALSE, which caused behavior inconsistent with what - most would expect, especially when the 'not' operator was used. - - The Filter choice SubstringFilter substrings type is now defined - with a lower bound of 1. - - The SubstringFilter substrings 'initial, 'any', and 'final' types - are now AssertionValue rather than LDAPString. Also, added - imperatives stating that 'initial' (if present) must be listed - first, and 'final' (if present) must be listed last. - - Disambiguated the semantics of the derefAliases choices. There was - question as to whether derefInSearching applied to the base object - in a wholeSubtree Search. - - Added instructions for equalityMatch, substrings, greaterOrEqual, - lessOrEqual, and approxMatch. - - - -Sermersheim Standards Track [Page 63] - -RFC 4511 LDAPv3 June 2006 - - - -C.1.18. Section 4.5.2 (Search Result) - - - Recommended that servers not use attribute short names when it - knows they are ambiguous or may cause interoperability problems. - - Removed all mention of ExtendedResponse due to lack of - implementation. - -C.1.19. Section 4.5.3 (Continuation References in the Search Result) - - - Made changes similar to those made to Section 4.1.11. - -C.1.20. Section 4.5.3.1 (Example) - - - Fixed examples to adhere to changes made to Section 4.5.3. - -C.1.21. Section 4.6 (Modify Operation) - - - Replaced AttributeTypeAndValues with Attribute as they are - equivalent. - - Specified the types of modification changes that might - temporarily violate schema. Some readers were under the impression - that any temporary schema violation was allowed. - -C.1.22. Section 4.7 (Add Operation) - - - Aligned Add operation with X.511 in that the attributes of the RDN - are used in conjunction with the listed attributes to create the - entry. Previously, Add required that the distinguished values be - present in the listed attributes. - - Removed requirement that the objectClass attribute MUST be - specified as some DSE types do not require this attribute. - Instead, generic wording was added, requiring the added entry to - adhere to the data model. - - Removed recommendation regarding placement of objects. This is - covered in the data model document. - -C.1.23. Section 4.9 (Modify DN Operation) - - - Required servers to not dereference aliases for Modify DN. This - was added for consistency with other operations and to help ensure - data consistency. - - Allow Modify DN to fail when moving between naming contexts. - - Specified what happens when the attributes of the newrdn are not - present on the entry. - - - - - - -Sermersheim Standards Track [Page 64] - -RFC 4511 LDAPv3 June 2006 - - -C.1.24. Section 4.10 (Compare Operation) - - - Specified that compareFalse means that the Compare took place and - the result is false. There was confusion that led people to - believe that an Undefined match resulted in compareFalse. - - Required servers to not dereference aliases for Compare. This was - added for consistency with other operations and to help ensure - data consistency. - -C.1.25. Section 4.11 (Abandon Operation) - - - Explained that since Abandon returns no response, clients should - not use it if they need to know the outcome. - - Specified that Abandon and Unbind cannot be abandoned. - -C.1.26. Section 4.12 (Extended Operation) - - - Specified how values of Extended operations defined in terms of - ASN.1 are to be encoded. - - Added instructions on what Extended operation specifications - consist of. - - Added a recommendation that servers advertise supported Extended - operations. - -C.1.27. Section 5.2 (Transfer Protocols) - - - Moved referral-specific instructions into referral-related - sections. - -C.1.28. Section 7 (Security Considerations) - - - Reworded notes regarding SASL not protecting certain aspects of - the LDAP Bind messages. - - Noted that Servers are encouraged to prevent directory - modifications by clients that have authenticated anonymously - [RFC4513]. - - Added a note regarding the possibility of changes to security - factors (authentication, authorization, and data confidentiality). - - Warned against following referrals that may have been injected in - the data stream. - - Noted that servers should protect information equally, whether in - an error condition or not, and mentioned matchedDN, - diagnosticMessage, and resultCodes specifically. - - Added a note regarding malformed and long encodings. - - - - - - - -Sermersheim Standards Track [Page 65] - -RFC 4511 LDAPv3 June 2006 - - -C.1.29. Appendix A (Complete ASN.1 Definition) - - - Added "EXTENSIBILITY IMPLIED" to ASN.1 definition. - - Removed AttributeType. It is not used. - -C.2. Changes Made to RFC 2830 - - This section summarizes the substantive changes made to Sections of - RFC 2830. Readers should consult [RFC4513] for summaries of changes - to other sections. - -C.2.1. Section 2.3 (Response other than "success") - - - Removed wording indicating that referrals can be returned from - StartTLS. - - Removed requirement that only a narrow set of result codes can be - returned. Some result codes are required in certain scenarios, but - any other may be returned if appropriate. - - Removed requirement that the ExtendedResponse.responseName MUST be - present. There are circumstances where this is impossible, and - requiring this is at odds with language in Section 4.12. - -C.2.1. Section 4 (Closing a TLS Connection) - - - Reworded most of this section to align with definitions of the - LDAP protocol layers. - - Removed instructions on abrupt closure as this is covered in other - areas of the document (specifically, Section 5.3) - -C.3. Changes Made to RFC 3771 - - - Rewrote to fit into this document. In general, semantics were - preserved. Supporting and background language seen as redundant - due to its presence in this document was omitted. - - - Specified that Intermediate responses to a request may be of - different types, and one of the response types may be specified to - have no response value. - - - - - - - - - - - - - -Sermersheim Standards Track [Page 66] - -RFC 4511 LDAPv3 June 2006 - - -Editor's Address - - Jim Sermersheim - Novell, Inc. - 1800 South Novell Place - Provo, Utah 84606, USA - - Phone: +1 801 861-3088 - EMail: jimse@novell.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Sermersheim Standards Track [Page 67] - -RFC 4511 LDAPv3 June 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Sermersheim Standards Track [Page 68] - diff --git a/source4/ldap_server/devdocs/rfc4512.txt b/source4/ldap_server/devdocs/rfc4512.txt deleted file mode 100644 index f45a3f3e73..0000000000 --- a/source4/ldap_server/devdocs/rfc4512.txt +++ /dev/null @@ -1,2915 +0,0 @@ - - - - - - -Network Working Group K. Zeilenga -Request for Comments: 4512 OpenLDAP Foundation -Obsoletes: 2251, 2252, 2256, 3674 June 2006 -Category: Standards Track - - - Lightweight Directory Access Protocol (LDAP): - Directory Information Models - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - The Lightweight Directory Access Protocol (LDAP) is an Internet - protocol for accessing distributed directory services that act in - accordance with X.500 data and service models. This document - describes the X.500 Directory Information Models, as used in LDAP. - - - - - - - - - - - - - - - - - - - - - - - - -Zeilenga Standards Track [Page 1] - -RFC 4512 LDAP Models June 2006 - - -Table of Contents - - 1. Introduction ....................................................3 - 1.1. Relationship to Other LDAP Specifications ..................3 - 1.2. Relationship to X.501 ......................................4 - 1.3. Conventions ................................................4 - 1.4. Common ABNF Productions ....................................4 - 2. Model of Directory User Information .............................6 - 2.1. The Directory Information Tree .............................7 - 2.2. Structure of an Entry ......................................7 - 2.3. Naming of Entries ..........................................8 - 2.4. Object Classes .............................................9 - 2.5. Attribute Descriptions ....................................12 - 2.6. Alias Entries .............................................16 - 3. Directory Administrative and Operational Information ...........17 - 3.1. Subtrees ..................................................17 - 3.2. Subentries ................................................18 - 3.3. The 'objectClass' attribute ...............................18 - 3.4. Operational Attributes ....................................19 - 4. Directory Schema ...............................................22 - 4.1. Schema Definitions ........................................23 - 4.2. Subschema Subentries ......................................32 - 4.3. 'extensibleObject' object class ...........................35 - 4.4. Subschema Discovery .......................................35 - 5. DSA (Server) Informational Model ...............................36 - 5.1. Server-Specific Data Requirements .........................36 - 6. Other Considerations ...........................................40 - 6.1. Preservation of User Information ..........................40 - 6.2. Short Names ...............................................41 - 6.3. Cache and Shadowing .......................................41 - 7. Implementation Guidelines ......................................42 - 7.1. Server Guidelines .........................................42 - 7.2. Client Guidelines .........................................42 - 8. Security Considerations ........................................43 - 9. IANA Considerations ............................................43 - 10. Acknowledgements ..............................................44 - 11. Normative References ..........................................45 - Appendix A. Changes ...............................................47 - A.1. Changes to RFC 2251 .......................................47 - A.2. Changes to RFC 2252 .......................................49 - A.3. Changes to RFC 2256 .......................................50 - A.4. Changes to RFC 3674 .......................................51 - - - - - - - - - -Zeilenga Standards Track [Page 2] - -RFC 4512 LDAP Models June 2006 - - -1. Introduction - - This document discusses the X.500 Directory Information Models - [X.501], as used by the Lightweight Directory Access Protocol (LDAP) - [RFC4510]. - - The Directory is "a collection of open systems cooperating to provide - directory services" [X.500]. The information held in the Directory - is collectively known as the Directory Information Base (DIB). A - Directory user, which may be a human or other entity, accesses the - Directory through a client (or Directory User Agent (DUA)). The - client, on behalf of the directory user, interacts with one or more - servers (or Directory System Agents (DSA)). A server holds a - fragment of the DIB. - - The DIB contains two classes of information: - - 1) user information (e.g., information provided and administrated - by users). Section 2 describes the Model of User Information. - - 2) administrative and operational information (e.g., information - used to administer and/or operate the directory). Section 3 - describes the model of Directory Administrative and Operational - Information. - - These two models, referred to as the generic Directory Information - Models, describe how information is represented in the Directory. - These generic models provide a framework for other information - models. Section 4 discusses the subschema information model and - subschema discovery. Section 5 discusses the DSA (Server) - Informational Model. - - Other X.500 information models (such as access control distribution - knowledge and replication knowledge information models) may be - adapted for use in LDAP. Specification of how these models apply to - LDAP is left to future documents. - -1.1. Relationship to Other LDAP Specifications - - This document is a integral part of the LDAP technical specification - [RFC4510], which obsoletes the previously defined LDAP technical - specification, RFC 3377, in its entirety. - - This document obsoletes RFC 2251, Sections 3.2 and 3.4, as well as - portions of Sections 4 and 6. Appendix A.1 summarizes changes to - these sections. The remainder of RFC 2251 is obsoleted by the - [RFC4511], [RFC4513], and [RFC4510] documents. - - - - -Zeilenga Standards Track [Page 3] - -RFC 4512 LDAP Models June 2006 - - - This document obsoletes RFC 2252, Sections 4, 5, and 7. Appendix A.2 - summarizes changes to these sections. The remainder of RFC 2252 is - obsoleted by [RFC4517]. - - This document obsoletes RFC 2256, Sections 5.1, 5.2, 7.1, and 7.2. - Appendix A.3 summarizes changes to these sections. The remainder of - RFC 2256 is obsoleted by [RFC4519] and [RFC4517]. - - This document obsoletes RFC 3674 in its entirety. Appendix A.4 - summarizes changes since RFC 3674. - -1.2. Relationship to X.501 - - This document includes material, with and without adaptation, from - [X.501] as necessary to describe this protocol. These adaptations - (and any other differences herein) apply to this protocol, and only - this protocol. - -1.3. Conventions - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in BCP 14 [RFC2119]. - - Schema definitions are provided using LDAP description formats (as - defined in Section 4.1). Definitions provided here are formatted - (line wrapped) for readability. Matching rules and LDAP syntaxes - referenced in these definitions are specified in [RFC4517]. - -1.4. Common ABNF Productions - - A number of syntaxes in this document are described using Augmented - Backus-Naur Form (ABNF) [RFC4234]. These syntaxes (as well as a - number of syntaxes defined in other documents) rely on the following - common productions: - - keystring = leadkeychar *keychar - leadkeychar = ALPHA - keychar = ALPHA / DIGIT / HYPHEN - number = DIGIT / ( LDIGIT 1*DIGIT ) - - ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z" - DIGIT = %x30 / LDIGIT ; "0"-"9" - LDIGIT = %x31-39 ; "1"-"9" - HEX = DIGIT / %x41-46 / %x61-66 ; "0"-"9" / "A"-"F" / "a"-"f" - - SP = 1*SPACE ; one or more " " - WSP = 0*SPACE ; zero or more " " - - - -Zeilenga Standards Track [Page 4] - -RFC 4512 LDAP Models June 2006 - - - NULL = %x00 ; null (0) - SPACE = %x20 ; space (" ") - DQUOTE = %x22 ; quote (""") - SHARP = %x23 ; octothorpe (or sharp sign) ("#") - DOLLAR = %x24 ; dollar sign ("$") - SQUOTE = %x27 ; single quote ("'") - LPAREN = %x28 ; left paren ("(") - RPAREN = %x29 ; right paren (")") - PLUS = %x2B ; plus sign ("+") - COMMA = %x2C ; comma (",") - HYPHEN = %x2D ; hyphen ("-") - DOT = %x2E ; period (".") - SEMI = %x3B ; semicolon (";") - LANGLE = %x3C ; left angle bracket ("<") - EQUALS = %x3D ; equals sign ("=") - RANGLE = %x3E ; right angle bracket (">") - ESC = %x5C ; backslash ("\") - USCORE = %x5F ; underscore ("_") - LCURLY = %x7B ; left curly brace "{" - RCURLY = %x7D ; right curly brace "}" - - ; Any UTF-8 [RFC3629] encoded Unicode [Unicode] character - UTF8 = UTF1 / UTFMB - UTFMB = UTF2 / UTF3 / UTF4 - UTF0 = %x80-BF - UTF1 = %x00-7F - UTF2 = %xC2-DF UTF0 - UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / - %xED %x80-9F UTF0 / %xEE-EF 2(UTF0) - UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) / - %xF4 %x80-8F 2(UTF0) - - OCTET = %x00-FF ; Any octet (8-bit data unit) - - Object identifiers (OIDs) [X.680] are represented in LDAP using a - dot-decimal format conforming to the ABNF: - - numericoid = number 1*( DOT number ) - - Short names, also known as descriptors, are used as more readable - aliases for object identifiers. Short names are case insensitive and - conform to the ABNF: - - descr = keystring - - - - - - - -Zeilenga Standards Track [Page 5] - -RFC 4512 LDAP Models June 2006 - - - Where either an object identifier or a short name may be specified, - the following production is used: - - oid = descr / numericoid - - While the <descr> form is generally preferred when the usage is - restricted to short names referring to object identifiers that - identify like kinds of objects (e.g., attribute type descriptions, - matching rule descriptions, object class descriptions), the - <numericoid> form should be used when the object identifiers may - identify multiple kinds of objects or when an unambiguous short name - (descriptor) is not available. - - Implementations SHOULD treat short names (descriptors) used in an - ambiguous manner (as discussed above) as unrecognized. - - Short Names (descriptors) are discussed further in Section 6.2. - -2. Model of Directory User Information - - As [X.501] states: - - The purpose of the Directory is to hold, and provide access to, - information about objects of interest (objects) in some 'world'. - An object can be anything which is identifiable (can be named). - - An object class is an identified family of objects, or conceivable - objects, which share certain characteristics. Every object - belongs to at least one class. An object class may be a subclass - of other object classes, in which case the members of the former - class, the subclass, are also considered to be members of the - latter classes, the superclasses. There may be subclasses of - subclasses, etc., to an arbitrary depth. - - A directory entry, a named collection of information, is the basic - unit of information held in the Directory. There are multiple kinds - of directory entries. - - An object entry represents a particular object. An alias entry - provides alternative naming. A subentry holds administrative and/or - operational information. - - The set of entries representing the DIB are organized hierarchically - in a tree structure known as the Directory Information Tree (DIT). - - Section 2.1 describes the Directory Information Tree. - Section 2.2 discusses the structure of entries. - Section 2.3 discusses naming of entries. - - - -Zeilenga Standards Track [Page 6] - -RFC 4512 LDAP Models June 2006 - - - Section 2.4 discusses object classes. - Section 2.5 discusses attribute descriptions. - Section 2.6 discusses alias entries. - -2.1. The Directory Information Tree - - As noted above, the DIB is composed of a set of entries organized - hierarchically in a tree structure known as the Directory Information - Tree (DIT); specifically, a tree where vertices are the entries. - - The arcs between vertices define relations between entries. If an - arc exists from X to Y, then the entry at X is the immediate superior - of Y, and Y is the immediate subordinate of X. An entry's superiors - are the entry's immediate superior and its superiors. An entry's - subordinates are all of its immediate subordinates and their - subordinates. - - Similarly, the superior/subordinate relationship between object - entries can be used to derive a relation between the objects they - represent. DIT structure rules can be used to govern relationships - between objects. - - Note: An entry's immediate superior is also known as the entry's - parent, and an entry's immediate subordinate is also known as - the entry's child. Entries that have the same parent are known - as siblings. - -2.2. Structure of an Entry - - An entry consists of a set of attributes that hold information about - the object that the entry represents. Some attributes represent user - information and are called user attributes. Other attributes - represent operational and/or administrative information and are - called operational attributes. - - An attribute is an attribute description (a type and zero or more - options) with one or more associated values. An attribute is often - referred to by its attribute description. For example, the - 'givenName' attribute is the attribute that consists of the attribute - description 'givenName' (the 'givenName' attribute type [RFC4519] and - zero options) and one or more associated values. - - The attribute type governs whether the attribute can have multiple - values, the syntax and matching rules used to construct and compare - values of that attribute, and other functions. Options indicate - subtypes and other functions. - - Attribute values conform to the defined syntax of the attribute type. - - - -Zeilenga Standards Track [Page 7] - -RFC 4512 LDAP Models June 2006 - - - No two values of an attribute may be equivalent. Two values are - considered equivalent if and only if they would match according to - the equality matching rule of the attribute type. Or, if the - attribute type is defined with no equality matching rule, two values - are equivalent if and only if they are identical. (See 2.5.1 for - other restrictions.) - - For example, a 'givenName' attribute can have more than one value, - they must be Directory Strings, and they are case insensitive. A - 'givenName' attribute cannot hold both "John" and "JOHN", as these - are equivalent values per the equality matching rule of the attribute - type. - - Additionally, no attribute is to have a value that is not equivalent - to itself. For example, the 'givenName' attribute cannot have as a - value a directory string that includes the REPLACEMENT CHARACTER - (U+FFFD) code point, as matching involving that directory string is - Undefined per this attribute's equality matching rule. - - When an attribute is used for naming of the entry, one and only one - value of the attribute is used in forming the Relative Distinguished - Name. This value is known as a distinguished value. - -2.3. Naming of Entries - -2.3.1. Relative Distinguished Names - - Each entry is named relative to its immediate superior. This - relative name, known as its Relative Distinguished Name (RDN) - [X.501], is composed of an unordered set of one or more attribute - value assertions (AVA) consisting of an attribute description with - zero options and an attribute value. These AVAs are chosen to match - attribute values (each a distinguished value) of the entry. - - An entry's relative distinguished name must be unique among all - immediate subordinates of the entry's immediate superior (i.e., all - siblings). - - The following are examples of string representations of RDNs - [RFC4514]: - - UID=12345 - OU=Engineering - CN=Kurt Zeilenga+L=Redwood Shores - - The last is an example of a multi-valued RDN; that is, an RDN - composed of multiple AVAs. - - - - -Zeilenga Standards Track [Page 8] - -RFC 4512 LDAP Models June 2006 - - -2.3.2. Distinguished Names - - An entry's fully qualified name, known as its Distinguished Name (DN) - [X.501], is the concatenation of its RDN and its immediate superior's - DN. A Distinguished Name unambiguously refers to an entry in the - tree. The following are examples of string representations of DNs - [RFC4514]: - - UID=nobody@example.com,DC=example,DC=com - CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US - -2.3.3. Alias Names - - An alias, or alias name, is "an name for an object, provided by the - use of alias entries" [X.501]. Alias entries are described in - Section 2.6. - -2.4. Object Classes - - An object class is "an identified family of objects (or conceivable - objects) that share certain characteristics" [X.501]. - - As defined in [X.501]: - - Object classes are used in the Directory for a number of purposes: - - - describing and categorizing objects and the entries that - correspond to these objects; - - - where appropriate, controlling the operation of the Directory; - - - regulating, in conjunction with DIT structure rule - specifications, the position of entries in the DIT; - - - regulating, in conjunction with DIT content rule - specifications, the attributes that are contained in entries; - - - identifying classes of entry that are to be associated with a - particular policy by the appropriate administrative authority. - - An object class (a subclass) may be derived from an object class - (its direct superclass) which is itself derived from an even more - generic object class. For structural object classes, this process - stops at the most generic object class, 'top' (defined in Section - 2.4.1). An ordered set of superclasses up to the most superior - object class of an object class is its superclass chain. - - - - - -Zeilenga Standards Track [Page 9] - -RFC 4512 LDAP Models June 2006 - - - An object class may be derived from two or more direct - superclasses (superclasses not part of the same superclass chain). - This feature of subclassing is termed multiple inheritance. - - Each object class identifies the set of attributes required to be - present in entries belonging to the class and the set of attributes - allowed to be present in entries belonging to the class. As an entry - of a class must meet the requirements of each class it belongs to, it - can be said that an object class inherits the sets of allowed and - required attributes from its superclasses. A subclass can identify - an attribute allowed by its superclass as being required. If an - attribute is a member of both sets, it is required to be present. - - Each object class is defined to be one of three kinds of object - classes: Abstract, Structural, or Auxiliary. - - Each object class is identified by an object identifier (OID) and, - optionally, one or more short names (descriptors). - -2.4.1. Abstract Object Classes - - An abstract object class, as the name implies, provides a base of - characteristics from which other object classes can be defined to - inherit from. An entry cannot belong to an abstract object class - unless it belongs to a structural or auxiliary class that inherits - from that abstract class. - - Abstract object classes cannot derive from structural or auxiliary - object classes. - - All structural object classes derive (directly or indirectly) from - the 'top' abstract object class. Auxiliary object classes do not - necessarily derive from 'top'. - - The following is the object class definition (see Section 4.1.1) for - the 'top' object class: - - ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass ) - - All entries belong to the 'top' abstract object class. - - - - - - - - - - - -Zeilenga Standards Track [Page 10] - -RFC 4512 LDAP Models June 2006 - - -2.4.2. Structural Object Classes - - As stated in [X.501]: - - An object class defined for use in the structural specification of - the DIT is termed a structural object class. Structural object - classes are used in the definition of the structure of the names - of the objects for compliant entries. - - An object or alias entry is characterized by precisely one - structural object class superclass chain which has a single - structural object class as the most subordinate object class. - This structural object class is referred to as the structural - object class of the entry. - - Structural object classes are related to associated entries: - - - an entry conforming to a structural object class shall - represent the real-world object constrained by the object - class; - - - DIT structure rules only refer to structural object classes; - the structural object class of an entry is used to specify the - position of the entry in the DIT; - - - the structural object class of an entry is used, along with an - associated DIT content rule, to control the content of an - entry. - - The structural object class of an entry shall not be changed. - - Each structural object class is a (direct or indirect) subclass of - the 'top' abstract object class. - - Structural object classes cannot subclass auxiliary object classes. - - Each entry is said to belong to its structural object class as well - as all classes in its structural object class's superclass chain. - -2.4.3. Auxiliary Object Classes - - Auxiliary object classes are used to augment the characteristics of - entries. They are commonly used to augment the sets of attributes - required and allowed to be present in an entry. They can be used to - describe entries or classes of entries. - - Auxiliary object classes cannot subclass structural object classes. - - - - -Zeilenga Standards Track [Page 11] - -RFC 4512 LDAP Models June 2006 - - - An entry can belong to any subset of the set of auxiliary object - classes allowed by the DIT content rule associated with the - structural object class of the entry. If no DIT content rule is - associated with the structural object class of the entry, the entry - cannot belong to any auxiliary object class. - - The set of auxiliary object classes that an entry belongs to can - change over time. - -2.5. Attribute Descriptions - - An attribute description is composed of an attribute type (see - Section 2.5.1) and a set of zero or more attribute options (see - Section 2.5.2). - - An attribute description is represented by the ABNF: - - attributedescription = attributetype options - attributetype = oid - options = *( SEMI option ) - option = 1*keychar - - where <attributetype> identifies the attribute type and each <option> - identifies an attribute option. Both <attributetype> and <option> - productions are case insensitive. The order in which <option>s - appear is irrelevant. That is, any two <attributedescription>s that - consist of the same <attributetype> and same set of <option>s are - equivalent. - - Examples of valid attribute descriptions: - - 2.5.4.0 - cn;lang-de;lang-en - owner - - An attribute description with an unrecognized attribute type is to be - treated as unrecognized. Servers SHALL treat an attribute - description with an unrecognized attribute option as unrecognized. - Clients MAY treat an unrecognized attribute option as a tagging - option (see Section 2.5.2.1). - - All attributes of an entry must have distinct attribute descriptions. - -2.5.1. Attribute Types - - An attribute type governs whether the attribute can have multiple - values, the syntax and matching rules used to construct and compare - values of that attribute, and other functions. - - - -Zeilenga Standards Track [Page 12] - -RFC 4512 LDAP Models June 2006 - - - If no equality matching is specified for the attribute type: - - - the attribute (of the type) cannot be used for naming; - - when adding the attribute (or replacing all values), no two - values may be equivalent (see 2.2); - - individual values of a multi-valued attribute are not to be - independently added or deleted; - - attribute value assertions (such as matching in search filters - and comparisons) using values of such a type cannot be - performed. - - Otherwise, the specified equality matching rule is to be used to - evaluate attribute value assertions concerning the attribute type. - The specified equality rule is to be transitive and commutative. - - The attribute type indicates whether the attribute is a user - attribute or an operational attribute. If operational, the attribute - type indicates the operational usage and whether or not the attribute - is modifiable by users. Operational attributes are discussed in - Section 3.4. - - An attribute type (a subtype) may derive from a more generic - attribute type (a direct supertype). The following restrictions - apply to subtyping: - - - a subtype must have the same usage as its direct supertype, - - a subtype's syntax must be the same, or a refinement of, its - supertype's syntax, and - - a subtype must be collective [RFC3671] if its supertype is - collective. - - An attribute description consisting of a subtype and no options is - said to be the direct description subtype of the attribute - description consisting of the subtype's direct supertype and no - options. - - Each attribute type is identified by an object identifier (OID) and, - optionally, one or more short names (descriptors). - -2.5.2. Attribute Options - - There are multiple kinds of attribute description options. The LDAP - technical specification details one kind: tagging options. - - Not all options can be associated with attributes held in the - directory. Tagging options can be. - - - - - -Zeilenga Standards Track [Page 13] - -RFC 4512 LDAP Models June 2006 - - - Not all options can be used in conjunction with all attribute types. - In such cases, the attribute description is to be treated as - unrecognized. - - An attribute description that contains mutually exclusive options - shall be treated as unrecognized. That is, "cn;x-bar;x-foo", where - "x-foo" and "x-bar" are mutually exclusive, is to be treated as - unrecognized. - - Other kinds of options may be specified in future documents. These - documents must detail how new kinds of options they define relate to - tagging options. In particular, these documents must detail whether - or not new kinds of options can be associated with attributes held in - the directory, how new kinds of options affect transfer of attribute - values, and how new kinds of options are treated in attribute - description hierarchies. - - Options are represented as short, case-insensitive textual strings - conforming to the <option> production defined in Section 2.5 of this - document. - - Procedures for registering options are detailed in BCP 64, RFC 4520 - [RFC4520]. - -2.5.2.1. Tagging Options - - Attributes held in the directory can have attribute descriptions with - any number of tagging options. Tagging options are never mutually - exclusive. - - An attribute description with N tagging options is a direct - (description) subtype of all attribute descriptions of the same - attribute type and all but one of the N options. If the attribute - type has a supertype, then the attribute description is also a direct - (description) subtype of the attribute description of the supertype - and the N tagging options. That is, 'cn;lang-de;lang-en' is a direct - (description) subtype of 'cn;lang-de', 'cn;lang-en', and - 'name;lang-de;lang-en' ('cn' is a subtype of 'name'; both are defined - in [RFC4519]). - -2.5.3. Attribute Description Hierarchies - - An attribute description can be the direct subtype of zero or more - other attribute descriptions as indicated by attribute type subtyping - (as described in Section 2.5.1) or attribute tagging option subtyping - (as described in Section 2.5.2.1). These subtyping relationships are - used to form hierarchies of attribute descriptions and attributes. - - - - -Zeilenga Standards Track [Page 14] - -RFC 4512 LDAP Models June 2006 - - - As adapted from [X.501]: - - Attribute hierarchies allow access to the DIB with varying degrees - of granularity. This is achieved by allowing the value components - of attributes to be accessed by using either their specific - attribute description (a direct reference to the attribute) or a - more generic attribute description (an indirect reference). - - Semantically related attributes may be placed in a hierarchical - relationship, the more specialized being placed subordinate to the - more generalized. Searching for or retrieving attributes and - their values is made easier by quoting the more generalized - attribute description; a filter item so specified is evaluated for - the more specialized descriptions as well as for the quoted - description. - - Where subordinate specialized descriptions are selected to be - returned as part of a search result these descriptions shall be - returned if available. Where the more general descriptions are - selected to be returned as part of a search result both the - general and the specialized descriptions shall be returned, if - available. An attribute value shall always be returned as a value - of its own attribute description. - - All of the attribute descriptions in an attribute hierarchy are - treated as distinct and unrelated descriptions for user - modification of entry content. - - An attribute value stored in an object or alias entry is of - precisely one attribute description. The description is indicated - when the value is originally added to the entry. - - For the purpose of subschema administration of the entry, a - specification that an attribute is required is fulfilled if the entry - contains a value of an attribute description belonging to an - attribute hierarchy where the attribute type of that description is - the same as the required attribute's type. That is, a "MUST name" - specification is fulfilled by 'name' or 'name;x-tag-option', but is - not fulfilled by 'CN' or 'CN;x-tag-option' (even though 'CN' is a - subtype of 'name'). Likewise, an entry may contain a value of an - attribute description belonging to an attribute hierarchy where the - attribute type of that description is either explicitly included in - the definition of an object class to which the entry belongs or - allowed by the DIT content rule applicable to that entry. That is, - 'name' and 'name;x-tag-option' are allowed by "MAY name" (or by "MUST - name"), but 'CN' and 'CN;x-tag-option' are not allowed by "MAY name" - (or by "MUST name"). - - - - -Zeilenga Standards Track [Page 15] - -RFC 4512 LDAP Models June 2006 - - - For the purposes of other policy administration, unless stated - otherwise in the specification of the particular administrative - model, all of the attribute descriptions in an attribute hierarchy - are treated as distinct and unrelated descriptions. - -2.6. Alias Entries - - As adapted from [X.501]: - - An alias, or an alias name, for an object is an alternative name - for an object or object entry which is provided by the use of - alias entries. - - Each alias entry contains, within the 'aliasedObjectName' - attribute (known as the 'aliasedEntryName' attribute in X.500), a - name of some object. The distinguished name of the alias entry is - thus also a name for this object. - - NOTE - The name within the 'aliasedObjectName' is said to be - pointed to by the alias. It does not have to be the - distinguished name of any entry. - - The conversion of an alias name to an object name is termed - (alias) dereferencing and comprises the systematic replacement of - alias names, where found within a purported name, by the value of - the corresponding 'aliasedObjectName' attribute. The process may - require the examination of more than one alias entry. - - Any particular entry in the DIT may have zero or more alias names. - It therefore follows that several alias entries may point to the - same entry. An alias entry may point to an entry that is not a - leaf entry and may point to another alias entry. - - An alias entry shall have no subordinates, so that an alias entry - is always a leaf entry. - - Every alias entry shall belong to the 'alias' object class. - - An entry with the 'alias' object class must also belong to an object - class (or classes), or be governed by a DIT content rule, which - allows suitable naming attributes to be present. - - Example: - - dn: cn=bar,dc=example,dc=com - objectClass: top - objectClass: alias - objectClass: extensibleObject - - - -Zeilenga Standards Track [Page 16] - -RFC 4512 LDAP Models June 2006 - - - cn: bar - aliasedObjectName: cn=foo,dc=example,dc=com - -2.6.1. 'alias' Object Class - - Alias entries belong to the 'alias' object class. - - ( 2.5.6.1 NAME 'alias' - SUP top STRUCTURAL - MUST aliasedObjectName ) - -2.6.2. 'aliasedObjectName' Attribute Type - - The 'aliasedObjectName' attribute holds the name of the entry an - alias points to. The 'aliasedObjectName' attribute is known as the - 'aliasedEntryName' attribute in X.500. - - ( 2.5.4.1 NAME 'aliasedObjectName' - EQUALITY distinguishedNameMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 - SINGLE-VALUE ) - - The 'distinguishedNameMatch' matching rule and the DistinguishedName - (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517]. - -3. Directory Administrative and Operational Information - - This section discusses select aspects of the X.500 Directory - Administrative and Operational Information model [X.501]. LDAP - implementations MAY support other aspects of this model. - -3.1. Subtrees - - As defined in [X.501]: - - A subtree is a collection of object and alias entries situated at - the vertices of a tree. Subtrees do not contain subentries. The - prefix sub, in subtree, emphasizes that the base (or root) vertex - of this tree is usually subordinate to the root of the DIT. - - A subtree begins at some vertex and extends to some identifiable - lower boundary, possibly extending to leaves. A subtree is always - defined within a context which implicitly bounds the subtree. For - example, the vertex and lower boundaries of a subtree defining a - replicated area are bounded by a naming context. - - - - - - -Zeilenga Standards Track [Page 17] - -RFC 4512 LDAP Models June 2006 - - -3.2. Subentries - - A subentry is a "special sort of entry, known by the Directory, used - to hold information associated with a subtree or subtree refinement" - [X.501]. Subentries are used in Directory to hold for administrative - and operational purposes as defined in [X.501]. Their use in LDAP is - detailed in [RFC3672]. - - The term "(sub)entry" in this specification indicates that servers - implementing X.500(93) models are, in accordance with X.500(93) as - described in [RFC3672], to use a subentry and that other servers are - to use an object entry belonging to the appropriate auxiliary class - normally used with the subentry (e.g., 'subschema' for subschema - subentries) to mimic the subentry. This object entry's RDN SHALL be - formed from a value of the 'cn' (commonName) attribute [RFC4519] (as - all subentries are named with 'cn'). - -3.3. The 'objectClass' attribute - - Each entry in the DIT has an 'objectClass' attribute. - - ( 2.5.4.0 NAME 'objectClass' - EQUALITY objectIdentifierMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) - - The 'objectIdentifierMatch' matching rule and the OBJECT IDENTIFIER - (1.3.6.1.4.1.1466.115.121.1.38) syntax are defined in [RFC4517]. - - The 'objectClass' attribute specifies the object classes of an entry, - which (among other things) are used in conjunction with the - controlling schema to determine the permitted attributes of an entry. - Values of this attribute can be modified by clients, but the - 'objectClass' attribute cannot be removed. - - Servers that follow X.500(93) models SHALL restrict modifications of - this attribute to prevent the basic structural class of the entry - from being changed. That is, one cannot change a 'person' into a - 'country'. - - When creating an entry or adding an 'objectClass' value to an entry, - all superclasses of the named classes SHALL be implicitly added as - well if not already present. That is, if the auxiliary class 'x-a' - is a subclass of the class 'x-b', adding 'x-a' to 'objectClass' - causes 'x-b' to be implicitly added (if is not already present). - - Servers SHALL restrict modifications of this attribute to prevent - superclasses of remaining 'objectClass' values from being deleted. - That is, if the auxiliary class 'x-a' is a subclass of the auxiliary - - - -Zeilenga Standards Track [Page 18] - -RFC 4512 LDAP Models June 2006 - - - class 'x-b' and the 'objectClass' attribute contains 'x-a' and 'x-b', - an attempt to delete only 'x-b' from the 'objectClass' attribute is - an error. - -3.4. Operational Attributes - - Some attributes, termed operational attributes, are used or - maintained by servers for administrative and operational purposes. - As stated in [X.501]: "There are three varieties of operational - attributes: Directory operational attributes, DSA-shared operational - attributes, and DSA-specific operational attributes". - - A directory operational attribute is used to represent operational - and/or administrative information in the Directory Information Model. - This includes operational attributes maintained by the server (e.g., - 'createTimestamp') as well as operational attributes that hold values - administrated by the user (e.g., 'ditContentRules'). - - A DSA-shared operational attribute is used to represent information - of the DSA Information Model that is shared between DSAs. - - A DSA-specific operational attribute is used to represent information - of the DSA Information Model that is specific to the DSA (though, in - some cases, may be derived from information shared between DSAs; - e.g., 'namingContexts'). - - The DSA Information Model operational attributes are detailed in - [X.501]. - - Operational attributes are not normally visible. They are not - returned in search results unless explicitly requested by name. - - Not all operational attributes are user modifiable. - - Entries may contain, among others, the following operational - attributes: - - - creatorsName: the Distinguished Name of the user who added this - entry to the directory, - - - createTimestamp: the time this entry was added to the directory, - - - modifiersName: the Distinguished Name of the user who last - modified this entry, and - - - modifyTimestamp: the time this entry was last modified. - - - - - -Zeilenga Standards Track [Page 19] - -RFC 4512 LDAP Models June 2006 - - - Servers SHOULD maintain the 'creatorsName', 'createTimestamp', - 'modifiersName', and 'modifyTimestamp' attributes for all entries of - the DIT. - -3.4.1. 'creatorsName' - - This attribute appears in entries that were added using the protocol - (e.g., using the Add operation). The value is the distinguished name - of the creator. - - ( 2.5.18.3 NAME 'creatorsName' - EQUALITY distinguishedNameMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 - SINGLE-VALUE NO-USER-MODIFICATION - USAGE directoryOperation ) - - The 'distinguishedNameMatch' matching rule and the DistinguishedName - (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517]. - -3.4.2. 'createTimestamp' - - This attribute appears in entries that were added using the protocol - (e.g., using the Add operation). The value is the time the entry was - added. - - ( 2.5.18.1 NAME 'createTimestamp' - EQUALITY generalizedTimeMatch - ORDERING generalizedTimeOrderingMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 - SINGLE-VALUE NO-USER-MODIFICATION - USAGE directoryOperation ) - - The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' - matching rules and the GeneralizedTime - (1.3.6.1.4.1.1466.115.121.1.24) syntax are defined in [RFC4517]. - -3.4.3. 'modifiersName' - - This attribute appears in entries that have been modified using the - protocol (e.g., using the Modify operation). The value is the - distinguished name of the last modifier. - - ( 2.5.18.4 NAME 'modifiersName' - EQUALITY distinguishedNameMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 - SINGLE-VALUE NO-USER-MODIFICATION - USAGE directoryOperation ) - - - - -Zeilenga Standards Track [Page 20] - -RFC 4512 LDAP Models June 2006 - - - The 'distinguishedNameMatch' matching rule and the DistinguishedName - (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517]. - -3.4.4. 'modifyTimestamp' - - This attribute appears in entries that have been modified using the - protocol (e.g., using the Modify operation). The value is the time - the entry was last modified. - - ( 2.5.18.2 NAME 'modifyTimestamp' - EQUALITY generalizedTimeMatch - ORDERING generalizedTimeOrderingMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 - SINGLE-VALUE NO-USER-MODIFICATION - USAGE directoryOperation ) - - The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' - matching rules and the GeneralizedTime - (1.3.6.1.4.1.1466.115.121.1.24) syntax are defined in [RFC4517]. - -3.4.5. 'structuralObjectClass' - - This attribute indicates the structural object class of the entry. - - ( 2.5.21.9 NAME 'structuralObjectClass' - EQUALITY objectIdentifierMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 - SINGLE-VALUE NO-USER-MODIFICATION - USAGE directoryOperation ) - - The 'objectIdentifierMatch' matching rule and OBJECT IDENTIFIER - (1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [RFC4517]. - -3.4.6. 'governingStructureRule' - - This attribute indicates the structure rule governing the entry. - - ( 2.5.21.10 NAME 'governingStructureRule' - EQUALITY integerMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 - SINGLE-VALUE NO-USER-MODIFICATION - USAGE directoryOperation ) - - The 'integerMatch' matching rule and INTEGER - (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in [RFC4517]. - - - - - - -Zeilenga Standards Track [Page 21] - -RFC 4512 LDAP Models June 2006 - - -4. Directory Schema - - As defined in [X.501]: - - The Directory Schema is a set of definitions and constraints - concerning the structure of the DIT, the possible ways entries are - named, the information that can be held in an entry, the - attributes used to represent that information and their - organization into hierarchies to facilitate search and retrieval - of the information and the ways in which values of attributes may - be matched in attribute value and matching rule assertions. - - NOTE 1 - The schema enables the Directory system to, for example: - - - prevent the creation of subordinate entries of the wrong - object-class (e.g., a country as a subordinate of a person); - - - prevent the addition of attribute-types to an entry - inappropriate to the object-class (e.g., a serial number to a - person's entry); - - - prevent the addition of an attribute value of a syntax not - matching that defined for the attribute-type (e.g., a printable - string to a bit string). - - Formally, the Directory Schema comprises a set of: - - a) Name Form definitions that define primitive naming relations - for structural object classes; - - b) DIT Structure Rule definitions that define the names that - entries may have and the ways in which the entries may be - related to one another in the DIT; - - c) DIT Content Rule definitions that extend the specification of - allowable attributes for entries beyond those indicated by the - structural object classes of the entries; - - d) Object Class definitions that define the basic set of mandatory - and optional attributes that shall be present, and may be - present, respectively, in an entry of a given class, and which - indicate the kind of object class that is being defined; - - - - - - - - - -Zeilenga Standards Track [Page 22] - -RFC 4512 LDAP Models June 2006 - - - e) Attribute Type definitions that identify the object identifier - by which an attribute is known, its syntax, associated matching - rules, whether it is an operational attribute and if so its - type, whether it is a collective attribute, whether it is - permitted to have multiple values and whether or not it is - derived from another attribute type; - - f) Matching Rule definitions that define matching rules. - - And in LDAP: - - g) LDAP Syntax definitions that define encodings used in LDAP. - -4.1. Schema Definitions - - Schema definitions in this section are described using ABNF and rely - on the common productions specified in Section 1.2 as well as these: - - noidlen = numericoid [ LCURLY len RCURLY ] - len = number - - oids = oid / ( LPAREN WSP oidlist WSP RPAREN ) - oidlist = oid *( WSP DOLLAR WSP oid ) - - extensions = *( SP xstring SP qdstrings ) - xstring = "X" HYPHEN 1*( ALPHA / HYPHEN / USCORE ) - - qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN ) - qdescrlist = [ qdescr *( SP qdescr ) ] - qdescr = SQUOTE descr SQUOTE - - qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN ) - qdstringlist = [ qdstring *( SP qdstring ) ] - qdstring = SQUOTE dstring SQUOTE - dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF-8 string - - QQ = ESC %x32 %x37 ; "\27" - QS = ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5c" - - ; Any UTF-8 encoded Unicode character - ; except %x27 ("\'") and %x5C ("\") - QUTF8 = QUTF1 / UTFMB - - ; Any ASCII character except %x27 ("\'") and %x5C ("\") - QUTF1 = %x00-26 / %x28-5B / %x5D-7F - - Schema definitions in this section also share a number of common - terms. - - - -Zeilenga Standards Track [Page 23] - -RFC 4512 LDAP Models June 2006 - - - The NAME field provides a set of short names (descriptors) that are - to be used as aliases for the OID. - - The DESC field optionally allows a descriptive string to be provided - by the directory administrator and/or implementor. While - specifications may suggest a descriptive string, there is no - requirement that the suggested (or any) descriptive string be used. - - The OBSOLETE field, if present, indicates the element is not active. - - Implementors should note that future versions of this document may - expand these definitions to include additional terms. Terms whose - identifier begins with "X-" are reserved for private experiments and - are followed by <SP> and <qdstrings> tokens. - -4.1.1. Object Class Definitions - - Object Class definitions are written according to the ABNF: - - ObjectClassDescription = LPAREN WSP - numericoid ; object identifier - [ SP "NAME" SP qdescrs ] ; short names (descriptors) - [ SP "DESC" SP qdstring ] ; description - [ SP "OBSOLETE" ] ; not active - [ SP "SUP" SP oids ] ; superior object classes - [ SP kind ] ; kind of class - [ SP "MUST" SP oids ] ; attribute types - [ SP "MAY" SP oids ] ; attribute types - extensions WSP RPAREN - - kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" - - where: - <numericoid> is object identifier assigned to this object class; - NAME <qdescrs> are short names (descriptors) identifying this - object class; - DESC <qdstring> is a short descriptive string; - OBSOLETE indicates this object class is not active; - SUP <oids> specifies the direct superclasses of this object class; - the kind of object class is indicated by one of ABSTRACT, - STRUCTURAL, or AUXILIARY (the default is STRUCTURAL); - MUST and MAY specify the sets of required and allowed attribute - types, respectively; and - <extensions> describe extensions. - - - - - - - -Zeilenga Standards Track [Page 24] - -RFC 4512 LDAP Models June 2006 - - -4.1.2. Attribute Types - - Attribute Type definitions are written according to the ABNF: - - AttributeTypeDescription = LPAREN WSP - numericoid ; object identifier - [ SP "NAME" SP qdescrs ] ; short names (descriptors) - [ SP "DESC" SP qdstring ] ; description - [ SP "OBSOLETE" ] ; not active - [ SP "SUP" SP oid ] ; supertype - [ SP "EQUALITY" SP oid ] ; equality matching rule - [ SP "ORDERING" SP oid ] ; ordering matching rule - [ SP "SUBSTR" SP oid ] ; substrings matching rule - [ SP "SYNTAX" SP noidlen ] ; value syntax - [ SP "SINGLE-VALUE" ] ; single-value - [ SP "COLLECTIVE" ] ; collective - [ SP "NO-USER-MODIFICATION" ] ; not user modifiable - [ SP "USAGE" SP usage ] ; usage - extensions WSP RPAREN ; extensions - - usage = "userApplications" / ; user - "directoryOperation" / ; directory operational - "distributedOperation" / ; DSA-shared operational - "dSAOperation" ; DSA-specific operational - - where: - <numericoid> is object identifier assigned to this attribute type; - NAME <qdescrs> are short names (descriptors) identifying this - attribute type; - DESC <qdstring> is a short descriptive string; - OBSOLETE indicates this attribute type is not active; - SUP oid specifies the direct supertype of this type; - EQUALITY, ORDERING, and SUBSTR provide the oid of the equality, - ordering, and substrings matching rules, respectively; - SYNTAX identifies value syntax by object identifier and may suggest - a minimum upper bound; - SINGLE-VALUE indicates attributes of this type are restricted to a - single value; - COLLECTIVE indicates this attribute type is collective - [X.501][RFC3671]; - NO-USER-MODIFICATION indicates this attribute type is not user - modifiable; - USAGE indicates the application of this attribute type; and - <extensions> describe extensions. - - Each attribute type description must contain at least one of the SUP - or SYNTAX fields. If no SYNTAX field is provided, the attribute type - description takes its value from the supertype. - - - -Zeilenga Standards Track [Page 25] - -RFC 4512 LDAP Models June 2006 - - - If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING - fields, if not specified, take their value from the supertype. - - Usage of userApplications, the default, indicates that attributes of - this type represent user information. That is, they are user - attributes. - - A usage of directoryOperation, distributedOperation, or dSAOperation - indicates that attributes of this type represent operational and/or - administrative information. That is, they are operational - attributes. - - directoryOperation usage indicates that the attribute of this type is - a directory operational attribute. distributedOperation usage - indicates that the attribute of this type is a DSA-shared usage - operational attribute. dSAOperation usage indicates that the - attribute of this type is a DSA-specific operational attribute. - - COLLECTIVE requires usage userApplications. Use of collective - attribute types in LDAP is discussed in [RFC3671]. - - NO-USER-MODIFICATION requires an operational usage. - - Note that the <AttributeTypeDescription> does not list the matching - rules that can be used with that attribute type in an extensibleMatch - search filter [RFC4511]. This is done using the 'matchingRuleUse' - attribute described in Section 4.1.4. - - This document refines the schema description of X.501 by requiring - that the SYNTAX field in an <AttributeTypeDescription> be a string - representation of an object identifier for the LDAP string syntax - definition, with an optional indication of the suggested minimum - bound of a value of this attribute. - - A suggested minimum upper bound on the number of characters in a - value with a string-based syntax, or the number of bytes in a value - for all other syntaxes, may be indicated by appending this bound - count inside of curly braces following the syntax's OBJECT IDENTIFIER - in an Attribute Type Description. This bound is not part of the - syntax name itself. For instance, "1.3.6.4.1.1466.0{64}" suggests - that server implementations should allow a string to be 64 characters - long, although they may allow longer strings. Note that a single - character of the Directory String syntax may be encoded in more than - one octet since UTF-8 [RFC3629] is a variable-length encoding. - - - - - - - -Zeilenga Standards Track [Page 26] - -RFC 4512 LDAP Models June 2006 - - -4.1.3. Matching Rules - - Matching rules are used in performance of attribute value assertions, - such as in performance of a Compare operation. They are also used in - evaluating search filters, determining which individual values are to - be added or deleted during performance of a Modify operation, and in - comparing distinguished names. - - Each matching rule is identified by an object identifier (OID) and, - optionally, one or more short names (descriptors). - - Matching rule definitions are written according to the ABNF: - - MatchingRuleDescription = LPAREN WSP - numericoid ; object identifier - [ SP "NAME" SP qdescrs ] ; short names (descriptors) - [ SP "DESC" SP qdstring ] ; description - [ SP "OBSOLETE" ] ; not active - SP "SYNTAX" SP numericoid ; assertion syntax - extensions WSP RPAREN ; extensions - - where: - <numericoid> is object identifier assigned to this matching rule; - NAME <qdescrs> are short names (descriptors) identifying this - matching rule; - DESC <qdstring> is a short descriptive string; - OBSOLETE indicates this matching rule is not active; - SYNTAX identifies the assertion syntax (the syntax of the assertion - value) by object identifier; and - <extensions> describe extensions. - -4.1.4. Matching Rule Uses - - A matching rule use lists the attribute types that are suitable for - use with an extensibleMatch search filter. - - Matching rule use descriptions are written according to the following - ABNF: - - MatchingRuleUseDescription = LPAREN WSP - numericoid ; object identifier - [ SP "NAME" SP qdescrs ] ; short names (descriptors) - [ SP "DESC" SP qdstring ] ; description - [ SP "OBSOLETE" ] ; not active - SP "APPLIES" SP oids ; attribute types - extensions WSP RPAREN ; extensions - - - - - -Zeilenga Standards Track [Page 27] - -RFC 4512 LDAP Models June 2006 - - - where: - <numericoid> is the object identifier of the matching rule - associated with this matching rule use description; - NAME <qdescrs> are short names (descriptors) identifying this - matching rule use; - DESC <qdstring> is a short descriptive string; - OBSOLETE indicates this matching rule use is not active; - APPLIES provides a list of attribute types the matching rule - applies to; and - <extensions> describe extensions. - -4.1.5. LDAP Syntaxes - - LDAP Syntaxes of (attribute and assertion) values are described in - terms of ASN.1 [X.680] and, optionally, have an octet string encoding - known as the LDAP-specific encoding. Commonly, the LDAP-specific - encoding is constrained to a string of Unicode [Unicode] characters - in UTF-8 [RFC3629] form. - - Each LDAP syntax is identified by an object identifier (OID). - - LDAP syntax definitions are written according to the ABNF: - - SyntaxDescription = LPAREN WSP - numericoid ; object identifier - [ SP "DESC" SP qdstring ] ; description - extensions WSP RPAREN ; extensions - - where: - <numericoid> is the object identifier assigned to this LDAP syntax; - DESC <qdstring> is a short descriptive string; and - <extensions> describe extensions. - -4.1.6. DIT Content Rules - - A DIT content rule is a "rule governing the content of entries of a - particular structural object class" [X.501]. - - For DIT entries of a particular structural object class, a DIT - content rule specifies which auxiliary object classes the entries are - allowed to belong to and which additional attributes (by type) are - required, allowed, or not allowed to appear in the entries. - - The list of precluded attributes cannot include any attribute listed - as mandatory in the rule, the structural object class, or any of the - allowed auxiliary object classes. - - - - - -Zeilenga Standards Track [Page 28] - -RFC 4512 LDAP Models June 2006 - - - Each content rule is identified by the object identifier, as well as - any short names (descriptors), of the structural object class it - applies to. - - An entry may only belong to auxiliary object classes listed in the - governing content rule. - - An entry must contain all attributes required by the object classes - the entry belongs to as well as all attributes required by the - governing content rule. - - An entry may contain any non-precluded attributes allowed by the - object classes the entry belongs to as well as all attributes allowed - by the governing content rule. - - An entry cannot include any attribute precluded by the governing - content rule. - - An entry is governed by (if present and active in the subschema) the - DIT content rule that applies to the structural object class of the - entry (see Section 2.4.2). If no active rule is present for the - entry's structural object class, the entry's content is governed by - the structural object class (and possibly other aspects of user and - system schema). DIT content rules for superclasses of the structural - object class of an entry are not applicable to that entry. - - DIT content rule descriptions are written according to the ABNF: - - DITContentRuleDescription = LPAREN WSP - numericoid ; object identifier - [ SP "NAME" SP qdescrs ] ; short names (descriptors) - [ SP "DESC" SP qdstring ] ; description - [ SP "OBSOLETE" ] ; not active - [ SP "AUX" SP oids ] ; auxiliary object classes - [ SP "MUST" SP oids ] ; attribute types - [ SP "MAY" SP oids ] ; attribute types - [ SP "NOT" SP oids ] ; attribute types - extensions WSP RPAREN ; extensions - - where: - <numericoid> is the object identifier of the structural object - class associated with this DIT content rule; - NAME <qdescrs> are short names (descriptors) identifying this DIT - content rule; - DESC <qdstring> is a short descriptive string; - OBSOLETE indicates this DIT content rule use is not active; - AUX specifies a list of auxiliary object classes that entries - subject to this DIT content rule may belong to; - - - -Zeilenga Standards Track [Page 29] - -RFC 4512 LDAP Models June 2006 - - - MUST, MAY, and NOT specify lists of attribute types that are - required, allowed, or precluded, respectively, from appearing - in entries subject to this DIT content rule; and - <extensions> describe extensions. - -4.1.7. DIT Structure Rules and Name Forms - - It is sometimes desirable to regulate where object and alias entries - can be placed in the DIT and how they can be named based upon their - structural object class. - -4.1.7.1. DIT Structure Rules - - A DIT structure rule is a "rule governing the structure of the DIT by - specifying a permitted superior to subordinate entry relationship. A - structure rule relates a name form, and therefore a structural object - class, to superior structure rules. This permits entries of the - structural object class identified by the name form to exist in the - DIT as subordinates to entries governed by the indicated superior - structure rules" [X.501]. - - DIT structure rule descriptions are written according to the ABNF: - - DITStructureRuleDescription = LPAREN WSP - ruleid ; rule identifier - [ SP "NAME" SP qdescrs ] ; short names (descriptors) - [ SP "DESC" SP qdstring ] ; description - [ SP "OBSOLETE" ] ; not active - SP "FORM" SP oid ; NameForm - [ SP "SUP" ruleids ] ; superior rules - extensions WSP RPAREN ; extensions - - ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN ) - ruleidlist = ruleid *( SP ruleid ) - ruleid = number - - where: - <ruleid> is the rule identifier of this DIT structure rule; - NAME <qdescrs> are short names (descriptors) identifying this DIT - structure rule; - DESC <qdstring> is a short descriptive string; - OBSOLETE indicates this DIT structure rule use is not active; - FORM is specifies the name form associated with this DIT structure - rule; - SUP identifies superior rules (by rule id); and - <extensions> describe extensions. - - - - - -Zeilenga Standards Track [Page 30] - -RFC 4512 LDAP Models June 2006 - - - If no superior rules are identified, the DIT structure rule applies - to an autonomous administrative point (e.g., the root vertex of the - subtree controlled by the subschema) [X.501]. - -4.1.7.2. Name Forms - - A name form "specifies a permissible RDN for entries of a particular - structural object class. A name form identifies a named object class - and one or more attribute types to be used for naming (i.e., for the - RDN). Name forms are primitive pieces of specification used in the - definition of DIT structure rules" [X.501]. - - Each name form indicates the structural object class to be named, a - set of required attribute types, and a set of allowed attribute - types. A particular attribute type cannot be in both sets. - - Entries governed by the form must be named using a value from each - required attribute type and zero or more values from the allowed - attribute types. - - Each name form is identified by an object identifier (OID) and, - optionally, one or more short names (descriptors). - - Name form descriptions are written according to the ABNF: - - NameFormDescription = LPAREN WSP - numericoid ; object identifier - [ SP "NAME" SP qdescrs ] ; short names (descriptors) - [ SP "DESC" SP qdstring ] ; description - [ SP "OBSOLETE" ] ; not active - SP "OC" SP oid ; structural object class - SP "MUST" SP oids ; attribute types - [ SP "MAY" SP oids ] ; attribute types - extensions WSP RPAREN ; extensions - - where: - <numericoid> is object identifier that identifies this name form; - NAME <qdescrs> are short names (descriptors) identifying this name - form; - DESC <qdstring> is a short descriptive string; - OBSOLETE indicates this name form is not active; - OC identifies the structural object class this rule applies to, - MUST and MAY specify the sets of required and allowed, - respectively, naming attributes for this name form; and - <extensions> describe extensions. - - All attribute types in the required ("MUST") and allowed ("MAY") - lists shall be different. - - - -Zeilenga Standards Track [Page 31] - -RFC 4512 LDAP Models June 2006 - - -4.2. Subschema Subentries - - Subschema (sub)entries are used for administering information about - the directory schema. A single subschema (sub)entry contains all - schema definitions (see Section 4.1) used by entries in a particular - part of the directory tree. - - Servers that follow X.500(93) models SHOULD implement subschema using - the X.500 subschema mechanisms (as detailed in Section 12 of - [X.501]), so these are not ordinary object entries but subentries - (see Section 3.2). LDAP clients SHOULD NOT assume that servers - implement any of the other aspects of X.500 subschema. - - Servers MAY allow subschema modification. Procedures for subschema - modification are discussed in Section 14.5 of [X.501]. - - A server that masters entries and permits clients to modify these - entries SHALL implement and provide access to these subschema - (sub)entries including providing a 'subschemaSubentry' attribute in - each modifiable entry. This is so clients may discover the - attributes and object classes that are permitted to be present. It - is strongly RECOMMENDED that all other servers implement this as - well. - - The value of the 'subschemaSubentry' attribute is the name of the - subschema (sub)entry holding the subschema controlling the entry. - - ( 2.5.18.10 NAME 'subschemaSubentry' - EQUALITY distinguishedNameMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 - SINGLE-VALUE NO-USER-MODIFICATION - USAGE directoryOperation ) - - The 'distinguishedNameMatch' matching rule and the DistinguishedName - (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517]. - - Subschema is held in (sub)entries belonging to the subschema - auxiliary object class. - - ( 2.5.20.1 NAME 'subschema' AUXILIARY - MAY ( dITStructureRules $ nameForms $ ditContentRules $ - objectClasses $ attributeTypes $ matchingRules $ - matchingRuleUse ) ) - - The 'ldapSyntaxes' operational attribute may also be present in - subschema entries. - - - - - -Zeilenga Standards Track [Page 32] - -RFC 4512 LDAP Models June 2006 - - - Servers MAY provide additional attributes (described in other - documents) in subschema (sub)entries. - - Servers SHOULD provide the attributes 'createTimestamp' and - 'modifyTimestamp' in subschema (sub)entries, in order to allow - clients to maintain their caches of schema information. - - The following subsections provide attribute type definitions for each - of schema definition attribute types. - -4.2.1. 'objectClasses' - - This attribute holds definitions of object classes. - - ( 2.5.21.6 NAME 'objectClasses' - EQUALITY objectIdentifierFirstComponentMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.37 - USAGE directoryOperation ) - - The 'objectIdentifierFirstComponentMatch' matching rule and the - ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) syntax are - defined in [RFC4517]. - -4.2.2. 'attributeTypes' - - This attribute holds definitions of attribute types. - - ( 2.5.21.5 NAME 'attributeTypes' - EQUALITY objectIdentifierFirstComponentMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.3 - USAGE directoryOperation ) - - The 'objectIdentifierFirstComponentMatch' matching rule and the - AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) syntax are - defined in [RFC4517]. - -4.2.3. 'matchingRules' - - This attribute holds definitions of matching rules. - - ( 2.5.21.4 NAME 'matchingRules' - EQUALITY objectIdentifierFirstComponentMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.30 - USAGE directoryOperation ) - - The 'objectIdentifierFirstComponentMatch' matching rule and the - MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) syntax are - defined in [RFC4517]. - - - -Zeilenga Standards Track [Page 33] - -RFC 4512 LDAP Models June 2006 - - -4.2.4 'matchingRuleUse' - - This attribute holds definitions of matching rule uses. - - ( 2.5.21.8 NAME 'matchingRuleUse' - EQUALITY objectIdentifierFirstComponentMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.31 - USAGE directoryOperation ) - - The 'objectIdentifierFirstComponentMatch' matching rule and the - MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) syntax are - defined in [RFC4517]. - -4.2.5. 'ldapSyntaxes' - - This attribute holds definitions of LDAP syntaxes. - - ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes' - EQUALITY objectIdentifierFirstComponentMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.54 - USAGE directoryOperation ) - - The 'objectIdentifierFirstComponentMatch' matching rule and the - SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) syntax are defined - in [RFC4517]. - -4.2.6. 'dITContentRules' - - This attribute lists DIT Content Rules that are present in the - subschema. - - ( 2.5.21.2 NAME 'dITContentRules' - EQUALITY objectIdentifierFirstComponentMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.16 - USAGE directoryOperation ) - - The 'objectIdentifierFirstComponentMatch' matching rule and the - DITContentRuleDescription (1.3.6.1.4.1.1466.115.121.1.16) syntax are - defined in [RFC4517]. - - - - - - - - - - - - -Zeilenga Standards Track [Page 34] - -RFC 4512 LDAP Models June 2006 - - -4.2.7. 'dITStructureRules' - - This attribute lists DIT Structure Rules that are present in the - subschema. - - ( 2.5.21.1 NAME 'dITStructureRules' - EQUALITY integerFirstComponentMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.17 - USAGE directoryOperation ) - - The 'integerFirstComponentMatch' matching rule and the - DITStructureRuleDescription (1.3.6.1.4.1.1466.115.121.1.17) syntax - are defined in [RFC4517]. - -4.2.8 'nameForms' - - This attribute lists Name Forms that are in force. - - ( 2.5.21.7 NAME 'nameForms' - EQUALITY objectIdentifierFirstComponentMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.35 - USAGE directoryOperation ) - - The 'objectIdentifierFirstComponentMatch' matching rule and the - NameFormDescription (1.3.6.1.4.1.1466.115.121.1.35) syntax are - defined in [RFC4517]. - -4.3. 'extensibleObject' object class - - The 'extensibleObject' auxiliary object class allows entries that - belong to it to hold any user attribute. The set of allowed - attribute types of this object class is implicitly the set of all - attribute types of userApplications usage. - - ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject' - SUP top AUXILIARY ) - - The mandatory attributes of the other object classes of this entry - are still required to be present, and any precluded attributes are - still not allowed to be present. - -4.4. Subschema Discovery - - To discover the DN of the subschema (sub)entry holding the subschema - controlling a particular entry, a client reads that entry's - 'subschemaSubentry' operational attribute. To read schema attributes - from the subschema (sub)entry, clients MUST issue a Search operation - [RFC4511] where baseObject is the DN of the subschema (sub)entry, - - - -Zeilenga Standards Track [Page 35] - -RFC 4512 LDAP Models June 2006 - - - scope is baseObject, filter is "(objectClass=subschema)" [RFC4515], - and the attributes field lists the names of the desired schema - attributes (as they are operational). Note: the - "(objectClass=subschema)" filter allows LDAP servers that gateway to - X.500 to detect that subentry information is being requested. - - Clients SHOULD NOT assume that a published subschema is complete, - that the server supports all of the schema elements it publishes, or - that the server does not support an unpublished element. - -5. DSA (Server) Informational Model - - The LDAP protocol assumes there are one or more servers that jointly - provide access to a Directory Information Tree (DIT). The server - holding the original information is called the "master" (for that - information). Servers that hold copies of the original information - are referred to as "shadowing" or "caching" servers. - - - As defined in [X.501]: - - context prefix: The sequence of RDNs leading from the Root of the - DIT to the initial vertex of a naming context; corresponds to - the distinguished name of that vertex. - - naming context: A subtree of entries held in a single master DSA. - - That is, a naming context is the largest collection of entries, - starting at an entry that is mastered by a particular server, and - including all its subordinates and their subordinates, down to the - entries that are mastered by different servers. The context prefix - is the name of the initial entry. - - The root of the DIT is a DSA-specific Entry (DSE) and not part of any - naming context (or any subtree); each server has different attribute - values in the root DSE. - -5.1. Server-Specific Data Requirements - - An LDAP server SHALL provide information about itself and other - information that is specific to each server. This is represented as - a group of attributes located in the root DSE, which is named with - the DN with zero RDNs (whose [RFC4514] representation is as the - zero-length string). - - These attributes are retrievable, subject to access control and other - restrictions, if a client performs a Search operation [RFC4511] with - an empty baseObject, scope of baseObject, the filter - - - -Zeilenga Standards Track [Page 36] - -RFC 4512 LDAP Models June 2006 - - - "(objectClass=*)" [RFC4515], and the attributes field listing the - names of the desired attributes. It is noted that root DSE - attributes are operational and, like other operational attributes, - are not returned in search requests unless requested by name. - - The root DSE SHALL NOT be included if the client performs a subtree - search starting from the root. - - Servers may allow clients to modify attributes of the root DSE, where - appropriate. - - The following attributes of the root DSE are defined below. - Additional attributes may be defined in other documents. - - - altServer: alternative servers; - - - namingContexts: naming contexts; - - - supportedControl: recognized LDAP controls; - - - supportedExtension: recognized LDAP extended operations; - - - supportedFeatures: recognized LDAP features; - - - supportedLDAPVersion: LDAP versions supported; and - - - supportedSASLMechanisms: recognized Simple Authentication and - Security Layers (SASL) [RFC4422] mechanisms. - - The values provided for these attributes may depend on session- - specific and other factors. For example, a server supporting the - SASL EXTERNAL mechanism might only list "EXTERNAL" when the client's - identity has been established by a lower level. See [RFC4513]. - - The root DSE may also include a 'subschemaSubentry' attribute. If it - does, the attribute refers to the subschema (sub)entry holding the - schema controlling the root DSE. Clients SHOULD NOT assume that this - subschema (sub)entry controls other entries held by the server. - General subschema discovery procedures are provided in Section 4.4. - - - - - - - - - - - - -Zeilenga Standards Track [Page 37] - -RFC 4512 LDAP Models June 2006 - - -5.1.1. 'altServer' - - The 'altServer' attribute lists URIs referring to alternative servers - that may be contacted when this server becomes unavailable. URIs for - servers implementing the LDAP are written according to [RFC4516]. - Other kinds of URIs may be provided. If the server does not know of - any other servers that could be used, this attribute will be absent. - Clients may cache this information in case their preferred server - later becomes unavailable. - - ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 - USAGE dSAOperation ) - - The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax is defined in - [RFC4517]. - -5.1.2. 'namingContexts' - - The 'namingContexts' attribute lists the context prefixes of the - naming contexts the server masters or shadows (in part or in whole). - If the server is a first-level DSA [X.501], it should list (in - addition) an empty string (indicating the root of the DIT). If the - server does not master or shadow any information (e.g., it is an LDAP - gateway to a public X.500 directory) this attribute will be absent. - If the server believes it masters or shadows the entire directory, - the attribute will have a single value, and that value will be the - empty string (indicating the root of the DIT). - - This attribute may be used, for example, to select a suitable entry - name for subsequent operations with this server. - - ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 - USAGE dSAOperation ) - - The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is - defined in [RFC4517]. - -5.1.3. 'supportedControl' - - The 'supportedControl' attribute lists object identifiers identifying - the request controls [RFC4511] the server supports. If the server - does not support any request controls, this attribute will be absent. - Object identifiers identifying response controls need not be listed. - - Procedures for registering object identifiers used to discovery of - protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520]. - - - -Zeilenga Standards Track [Page 38] - -RFC 4512 LDAP Models June 2006 - - - ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 - USAGE dSAOperation ) - - The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is - defined in [RFC4517]. - -5.1.4. 'supportedExtension' - - The 'supportedExtension' attribute lists object identifiers - identifying the extended operations [RFC4511] that the server - supports. If the server does not support any extended operations, - this attribute will be absent. - - An extended operation generally consists of an extended request and - an extended response but may also include other protocol data units - (such as intermediate responses). The object identifier assigned to - the extended request is used to identify the extended operation. - Other object identifiers used in the extended operation need not be - listed as values of this attribute. - - Procedures for registering object identifiers used to discovery of - protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520]. - - ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 - USAGE dSAOperation ) - - The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is - defined in [RFC4517]. - -5.1.5. 'supportedFeatures' - - The 'supportedFeatures' attribute lists object identifiers - identifying elective features that the server supports. If the - server does not support any discoverable elective features, this - attribute will be absent. - - ( 1.3.6.1.4.1.4203.1.3.5 NAME 'supportedFeatures' - EQUALITY objectIdentifierMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 - USAGE dSAOperation ) - - Procedures for registering object identifiers used to discovery of - protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520]. - - The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax and - objectIdentifierMatch matching rule are defined in [RFC4517]. - - - -Zeilenga Standards Track [Page 39] - -RFC 4512 LDAP Models June 2006 - - -5.1.6. 'supportedLDAPVersion' - - The 'supportedLDAPVersion' attribute lists the versions of LDAP that - the server supports. - - ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 - USAGE dSAOperation ) - - The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in - [RFC4517]. - -5.1.7. 'supportedSASLMechanisms' - - The 'supportedSASLMechanisms' attribute lists the SASL mechanisms - [RFC4422] that the server recognizes and/or supports [RFC4513]. The - contents of this attribute may depend on the current session state. - If the server does not support any SASL mechanisms, this attribute - will not be present. - - ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 - USAGE dSAOperation ) - - The Directory String (1.3.6.1.4.1.1466.115.121.1.15) syntax is - defined in [RFC4517]. - -6. Other Considerations - -6.1. Preservation of User Information - - Syntaxes may be defined that have specific value and/or value form - (representation) preservation requirements. For example, a syntax - containing digitally signed data can mandate that the server preserve - both the value and form of value presented to ensure that the - signature is not invalidated. - - Where such requirements have not been explicitly stated, servers - SHOULD preserve the value of user information but MAY return the - value in a different form. And where a server is unable (or - unwilling) to preserve the value of user information, the server - SHALL ensure that an equivalent value (per Section 2.3) is returned. - - - - - - - - - -Zeilenga Standards Track [Page 40] - -RFC 4512 LDAP Models June 2006 - - -6.2. Short Names - - Short names, also known as descriptors, are used as more readable - aliases for object identifiers and are used to identify various - schema elements. However, it is not expected that LDAP - implementations with human user interface would display these short - names (or the object identifiers they refer to) to the user. - Instead, they would most likely be performing translations (such as - expressing the short name in one of the local national languages). - For example, the short name "st" (stateOrProvinceName) might be - displayed to a German-speaking user as "Land". - - The same short name might have different meaning in different - subschemas, and, within a particular subschema, the same short name - might refer to different object identifiers each identifying a - different kind of schema element. - - Implementations MUST be prepared that the same short name might be - used in a subschema to refer to the different kinds of schema - elements. That is, there might be an object class 'x-fubar' and an - attribute type 'x-fubar' in a subschema. - - Implementations MUST be prepared that the same short name might be - used in the different subschemas to refer to the different schema - elements. That is, there might be two matching rules 'x-fubar', each - in different subschemas. - - Procedures for registering short names (descriptors) are detailed in - BCP 64, RFC 4520 [RFC4520]. - -6.3. Cache and Shadowing - - Some servers may hold cache or shadow copies of entries, which can be - used to answer search and comparison queries, but will return - referrals or contact other servers if modification operations are - requested. Servers that perform shadowing or caching MUST ensure - that they do not violate any access control constraints placed on the - data by the originating server. - - - - - - - - - - - - - -Zeilenga Standards Track [Page 41] - -RFC 4512 LDAP Models June 2006 - - -7. Implementation Guidelines - -7.1. Server Guidelines - - Servers MUST recognize all names of attribute types and object - classes defined in this document but, unless stated otherwise, need - not support the associated functionality. Servers SHOULD recognize - all the names of attribute types and object classes defined in - Section 3 and 4, respectively, of [RFC4519]. - - Servers MUST ensure that entries conform to user and system schema - rules or other data model constraints. - - Servers MAY support DIT Content Rules. Servers MAY support DIT - Structure Rules and Name Forms. - - Servers MAY support alias entries. - - Servers MAY support the 'extensibleObject' object class. - - Servers MAY support subentries. If so, they MUST do so in accordance - with [RFC3672]. Servers that do not support subentries SHOULD use - object entries to mimic subentries as detailed in Section 3.2. - - Servers MAY implement additional schema elements. Servers SHOULD - provide definitions of all schema elements they support in subschema - (sub)entries. - -7.2. Client Guidelines - - In the absence of prior agreements with servers, clients SHOULD NOT - assume that servers support any particular schema elements beyond - those referenced in Section 7.1. The client can retrieve subschema - information as described in Section 4.4. - - Clients MUST NOT display or attempt to decode a value as ASN.1 if the - value's syntax is not known. Clients MUST NOT assume the LDAP- - specific string encoding is restricted to a UTF-8 encoded string of - Unicode characters or any particular subset of Unicode (such as a - printable subset) unless such restriction is explicitly stated. - Clients SHOULD NOT send attribute values in a request that are not - valid according to the syntax defined for the attributes. - - - - - - - - - -Zeilenga Standards Track [Page 42] - -RFC 4512 LDAP Models June 2006 - - -8. Security Considerations - - Attributes of directory entries are used to provide descriptive - information about the real-world objects they represent, which can be - people, organizations, or devices. Most countries have privacy laws - regarding the publication of information about people. - - General security considerations for accessing directory information - with LDAP are discussed in [RFC4511] and [RFC4513]. - -9. IANA Considerations - - The Internet Assigned Numbers Authority (IANA) has updated the LDAP - descriptors registry as indicated in the following template: - - Subject: Request for LDAP Descriptor Registration Update - Descriptor (short name): see comment - Object Identifier: see comment - Person & email address to contact for further information: - Kurt Zeilenga <kurt@OpenLDAP.org> - Usage: see comment - Specification: RFC 4512 - Author/Change Controller: IESG - Comments: - - The following descriptors (short names) has been added to - the registry. - - NAME Type OID - ------------------------ ---- ----------------- - governingStructureRule A 2.5.21.10 - structuralObjectClass A 2.5.21.9 - - The following descriptors (short names) have been updated to - refer to this RFC. - - NAME Type OID - ------------------------ ---- ----------------- - alias O 2.5.6.1 - aliasedObjectName A 2.5.4.1 - altServer A 1.3.6.1.4.1.1466.101.120.6 - attributeTypes A 2.5.21.5 - createTimestamp A 2.5.18.1 - creatorsName A 2.5.18.3 - dITContentRules A 2.5.21.2 - dITStructureRules A 2.5.21.1 - extensibleObject O 1.3.6.1.4.1.1466.101.120.111 - ldapSyntaxes A 1.3.6.1.4.1.1466.101.120.16 - - - -Zeilenga Standards Track [Page 43] - -RFC 4512 LDAP Models June 2006 - - - matchingRuleUse A 2.5.21.8 - matchingRules A 2.5.21.4 - modifiersName A 2.5.18.4 - modifyTimestamp A 2.5.18.2 - nameForms A 2.5.21.7 - namingContexts A 1.3.6.1.4.1.1466.101.120.5 - objectClass A 2.5.4.0 - objectClasses A 2.5.21.6 - subschema O 2.5.20.1 - subschemaSubentry A 2.5.18.10 - supportedControl A 1.3.6.1.4.1.1466.101.120.13 - supportedExtension A 1.3.6.1.4.1.1466.101.120.7 - supportedFeatures A 1.3.6.1.4.1.4203.1.3.5 - supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15 - supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14 - top O 2.5.6.0 - -10. Acknowledgements - - This document is based in part on RFC 2251 by M. Wahl, T. Howes, and - S. Kille; RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, S. Kille; and - RFC 2556 by M. Wahl, all products of the IETF Access, Searching and - Indexing of Directories (ASID) Working Group. This document is also - based in part on "The Directory: Models" [X.501], a product of the - International Telephone Union (ITU). Additional text was borrowed - from RFC 2253 by M. Wahl, T. Howes, and S. Kille. - - This document is a product of the IETF LDAP Revision (LDAPBIS) - Working Group. - - - - - - - - - - - - - - - - - - - - - - -Zeilenga Standards Track [Page 44] - -RFC 4512 LDAP Models June 2006 - - -11. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO - 10646", STD 63, RFC 3629, November 2003. - - [RFC3671] Zeilenga, K., "Collective Attributes in the Lightweight - Directory Access Protocol (LDAP)", RFC 3671, December - 2003. - - [RFC3672] Zeilenga, K., "Subentries in the Lightweight Directory - Access Protocol (LDAP)", RFC 3672, December 2003. - - [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 4234, October 2005. - - [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple - Authentication and Security Layer (SASL)", RFC 4422, - June 2006. - - [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access - Protocol (LDAP): Technical Specification Road Map", RFC - 4510, June 2006. - - [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access - Protocol (LDAP): The Protocol", RFC 4511, June 2006. - - [RFC4513] Harrison, R., Ed., "Lightweight Directory Access - Protocol (LDAP): Authentication Methods and Security - Mechanisms", RFC 4513, June 2006. - - [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access - Protocol (LDAP): String Representation of Distinguished - Names", RFC 4514, June 2006. - - [RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory - Access Protocol (LDAP): String Representation of Search - Filters", RFC 4515, June 2006. - - [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory - Access Protocol (LDAP): Uniform Resource Locator", RFC - 4516, June 2006. - - [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol - (LDAP): Syntaxes and Matching Rules", RFC 4517, June - 2006. - - - -Zeilenga Standards Track [Page 45] - -RFC 4512 LDAP Models June 2006 - - - [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access - Protocol (LDAP): Schema for User Applications", RFC - 4519, June 2006. - - [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority - (IANA) Considerations for the Lightweight Directory - Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. - - [Unicode] The Unicode Consortium, "The Unicode Standard, Version - 3.2.0" is defined by "The Unicode Standard, Version - 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201- - 61633-5), as amended by the "Unicode Standard Annex - #27: Unicode 3.1" - (http://www.unicode.org/reports/tr27/) and by the - "Unicode Standard Annex #28: Unicode 3.2" - (http://www.unicode.org/reports/tr28/). - - [X.500] International Telecommunication Union - - Telecommunication Standardization Sector, "The - Directory -- Overview of concepts, models and - services," X.500(1993) (also ISO/IEC 9594-1:1994). - - [X.501] International Telecommunication Union - - Telecommunication Standardization Sector, "The - Directory -- Models," X.501(1993) (also ISO/IEC 9594- - 2:1994). - - [X.680] International Telecommunication Union - - Telecommunication Standardization Sector, "Abstract - Syntax Notation One (ASN.1) - Specification of Basic - Notation", X.680(2002) (also ISO/IEC 8824-1:2002). - - - - - - - - - - - - - - - - - - - - -Zeilenga Standards Track [Page 46] - -RFC 4512 LDAP Models June 2006 - - -Appendix A. Changes - - This appendix is non-normative. - - This document amounts to nearly a complete rewrite of portions of RFC - 2251, RFC 2252, and RFC 2256. This rewrite was undertaken to improve - overall clarity of technical specification. This appendix provides a - summary of substantive changes made to the portions of these - documents incorporated into this document. Readers should consult - [RFC4510], [RFC4511], [RFC4517], and [RFC4519] for summaries of - remaining portions of these documents. - -A.1. Changes to RFC 2251 - - This document incorporates from RFC 2251, Sections 3.2 and 3.4, and - portions of Sections 4 and 6 as summarized below. - -A.1.1. Section 3.2 of RFC 2251 - - Section 3.2 of RFC 2251 provided a brief introduction to the X.500 - data model, as used by LDAP. The previous specification relied on - [X.501] but lacked clarity in how X.500 models are adapted for use by - LDAP. This document describes the X.500 data models, as used by - LDAP, in greater detail, especially in areas where adaptation is - needed. - - Section 3.2.1 of RFC 2251 described an attribute as "a type with one - or more associated values". In LDAP, an attribute is better - described as an attribute description, a type with zero or more - options, and one or more associated values. - - Section 3.2.2 of RFC 2251 mandated that subschema subentries contain - objectClasses and attributeTypes attributes, yet X.500(93) treats - these attributes as optional. While generally all implementations - that support X.500(93) subschema mechanisms will provide both of - these attributes, it is not absolutely required for interoperability - that all servers do. The mandate was removed for consistency with - X.500(93). The subschema discovery mechanism was also clarified to - indicate that subschema controlling an entry is obtained by reading - the (sub)entry referred to by that entry's 'subschemaSubentry' - attribute. - - - - - - - - - - -Zeilenga Standards Track [Page 47] - -RFC 4512 LDAP Models June 2006 - - -A.1.2. Section 3.4 of RFC 2251 - - Section 3.4 of RFC 2251 provided "Server-specific Data Requirements". - This material, with changes, was incorporated in Section 5.1 of this - document. - - Changes: - - - Clarify that attributes of the root DSE are subject to "other - restrictions" in addition to access controls. - - - Clarify that only recognized extended requests need to be - enumerated 'supportedExtension'. - - - Clarify that only recognized request controls need to be enumerated - 'supportedControl'. - - - Clarify that root DSE attributes are operational and, like other - operational attributes, will not be returned in search requests - unless requested by name. - - - Clarify that not all root DSE attributes are user modifiable. - - - Remove inconsistent text regarding handling of the - 'subschemaSubentry' attribute within the root DSE. The previous - specification stated that the 'subschemaSubentry' attribute held in - the root DSE referred to "subschema entries (or subentries) known - by this server". This is inconsistent with the attribute's - intended use as well as its formal definition as a single valued - attribute [X.501]. It is also noted that a simple (possibly - incomplete) list of subschema (sub)entries is not terribly useful. - This document (in Section 5.1) specifies that the - 'subschemaSubentry' attribute of the root DSE refers to the - subschema controlling the root DSE. It is noted that the general - subschema discovery mechanism remains available (see Section 4.4 of - this document). - -A.1.3. Section 4 of RFC 2251 - - Portions of Section 4 of RFC 2251 detailing aspects of the - information model used by LDAP were incorporated in this document, - including: - - - Restriction of distinguished values to attributes whose - descriptions have no options (from Section 4.1.3); - - - - - - -Zeilenga Standards Track [Page 48] - -RFC 4512 LDAP Models June 2006 - - - - Data model aspects of Attribute Types (from Section 4.1.4), - Attribute Descriptions (from 4.1.5), Attribute (from 4.1.8), - Matching Rule Identifier (from 4.1.9); and - - - User schema requirements (from Sections 4.1.6, 4.5.1, and 4.7). - - Clarifications to these portions include: - - - Subtyping and AttributeDescriptions with options. - -A.1.4. Section 6 of RFC 2251 - - The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251 - where incorporated into this document. - -A.2. Changes to RFC 2252 - - This document incorporates Sections 4, 5, and 7 from RFC 2252. - -A.2.1. Section 4 of RFC 2252 - - The specification was updated to use Augmented BNF [RFC4234]. The - string representation of an OBJECT IDENTIFIER was tightened to - disallow leading zeros as described in RFC 2252. - - The <descr> syntax was changed to disallow semicolon (U+003B) - characters in order to appear to be consistent its natural language - specification "descr is the syntactic representation of an object - descriptor, which consists of letters and digits, starting with a - letter". In a related change, the statement "an AttributeDescription - can be used as the value in a NAME part of an - AttributeTypeDescription" was deleted. RFC 2252 provided no - specification of the semantics of attribute options appearing in NAME - fields. - - RFC 2252 stated that the <descr> form of <oid> SHOULD be preferred - over the <numericoid> form. However, <descr> form can be ambiguous. - To address this issue, the imperative was replaced with a statement - (in Section 1.4) that while the <descr> form is generally preferred, - <numericoid> should be used where an unambiguous <descr> is not - available. Additionally, an expanded discussion of descriptor issues - is in Section 6.2 ("Short Names"). - - The ABNF for a quoted string (qdstring) was updated to reflect - support for the escaping mechanism described in Section 4.3 of RFC - 2252. - - - - - -Zeilenga Standards Track [Page 49] - -RFC 4512 LDAP Models June 2006 - - -A.2.2. Section 5 of RFC 2252 - - Definitions of operational attributes provided in Section 5 of RFC - 2252 where incorporated into this document. - - The 'namingContexts' description was clarified. A first-level DSA - should publish, in addition to other values, "" indicating the root - of the DIT. - - The 'altServer' description was clarified. It may hold any URI. - - The 'supportedExtension' description was clarified. A server need - only list the OBJECT IDENTIFIERs associated with the extended - requests of the extended operations it recognizes. - - The 'supportedControl' description was clarified. A server need only - list the OBJECT IDENTIFIERs associated with the request controls it - recognizes. - - Descriptions for the 'structuralObjectClass' and - 'governingStructureRule' operational attribute types were added. - - The attribute definition of 'subschemaSubentry' was corrected to list - the terms SINGLE-VALUE and NO-USER-MODIFICATION in proper order. - -A.2.3. Section 7 of RFC 2252 - - Section 7 of RFC 2252 provides definitions of the 'subschema' and - 'extensibleObject' object classes. These definitions where - integrated into Section 4.2 and Section 4.3 of this document, - respectively. Section 7 of RFC 2252 also contained the object class - implementation requirement. This was incorporated into Section 7 of - this document. - - The specification of 'extensibleObject' was clarified regarding how - it interacts with precluded attributes. - -A.3. Changes to RFC 2256 - - This document incorporates Sections 5.1, 5.2, 7.1, and 7.2 of RFC - 2256. - - Section 5.1 of RFC 2256 provided the definition of the 'objectClass' - attribute type. This was integrated into Section 2.4.1 of this - document. The statement "One of the values is either 'top' or - 'alias'" was replaced with statement that one of the values is 'top' - as entries belonging to 'alias' also belong to 'top'. - - - - -Zeilenga Standards Track [Page 50] - -RFC 4512 LDAP Models June 2006 - - - Section 5.2 of RFC 2256 provided the definition of the - 'aliasedObjectName' attribute type. This was integrated into Section - 2.6.2 of this document. - - Section 7.1 of RFC 2256 provided the definition of the 'top' object - class. This was integrated into Section 2.4.1 of this document. - - Section 7.2 of RFC 2256 provided the definition of the 'alias' object - class. This was integrated into Section 2.6.1 of this document. - -A.4. Changes to RFC 3674 - - This document made no substantive change to the 'supportedFeatures' - technical specification provided in RFC 3674. - -Editor's Address - - Kurt D. Zeilenga - OpenLDAP Foundation - - EMail: Kurt@OpenLDAP.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Zeilenga Standards Track [Page 51] - -RFC 4512 LDAP Models June 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Zeilenga Standards Track [Page 52] - diff --git a/source4/ldap_server/devdocs/rfc4513.txt b/source4/ldap_server/devdocs/rfc4513.txt deleted file mode 100644 index 7e6e7eb4bd..0000000000 --- a/source4/ldap_server/devdocs/rfc4513.txt +++ /dev/null @@ -1,1907 +0,0 @@ - - - - - - -Network Working Group R. Harrison, Ed. -Request for Comments: 4513 Novell, Inc. -Obsoletes: 2251, 2829, 2830 June 2006 -Category: Standards Track - - - Lightweight Directory Access Protocol (LDAP): - Authentication Methods and Security Mechanisms - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document describes authentication methods and security - mechanisms of the Lightweight Directory Access Protocol (LDAP). This - document details establishment of Transport Layer Security (TLS) - using the StartTLS operation. - - This document details the simple Bind authentication method including - anonymous, unauthenticated, and name/password mechanisms and the - Simple Authentication and Security Layer (SASL) Bind authentication - method including the EXTERNAL mechanism. - - This document discusses various authentication and authorization - states through which a session to an LDAP server may pass and the - actions that trigger these state changes. - - This document, together with other documents in the LDAP Technical - Specification (see Section 1 of the specification's road map), - obsoletes RFC 2251, RFC 2829, and RFC 2830. - - - - - - - - - - - -Harrison Standards Track [Page 1] - -RFC 4513 LDAP Authentication Methods June 2006 - - -Table of Contents - - 1. Introduction ....................................................4 - 1.1. Relationship to Other Documents ............................6 - 1.2. Conventions ................................................6 - 2. Implementation Requirements .....................................7 - 3. StartTLS Operation ..............................................8 - 3.1. TLS Establishment Procedures ..............................8 - 3.1.1. StartTLS Request Sequencing .........................8 - 3.1.2. Client Certificate ..................................9 - 3.1.3. Server Identity Check ...............................9 - 3.1.3.1. Comparison of DNS Names ...................10 - 3.1.3.2. Comparison of IP Addresses ................11 - 3.1.3.3. Comparison of Other subjectName Types .....11 - 3.1.4. Discovery of Resultant Security Level ..............11 - 3.1.5. Refresh of Server Capabilities Information .........11 - 3.2. Effect of TLS on Authorization State .....................12 - 3.3. TLS Ciphersuites ..........................................12 - 4. Authorization State ............................................13 - 5. Bind Operation .................................................14 - 5.1. Simple Authentication Method ..............................14 - 5.1.1. Anonymous Authentication Mechanism of Simple Bind ..14 - 5.1.2. Unauthenticated Authentication Mechanism of - Simple Bind ........................................14 - 5.1.3. Name/Password Authentication Mechanism of - Simple Bind ........................................15 - 5.2. SASL Authentication Method ................................16 - 5.2.1. SASL Protocol Profile ..............................16 - 5.2.1.1. SASL Service Name for LDAP ................16 - 5.2.1.2. SASL Authentication Initiation and - Protocol Exchange .........................16 - 5.2.1.3. Optional Fields ...........................17 - 5.2.1.4. Octet Where Negotiated Security - Layers Take Effect ........................18 - 5.2.1.5. Determination of Supported SASL - Mechanisms ................................18 - 5.2.1.6. Rules for Using SASL Layers ...............19 - 5.2.1.7. Support for Multiple Authentications ......19 - 5.2.1.8. SASL Authorization Identities .............19 - 5.2.2. SASL Semantics within LDAP .........................20 - 5.2.3. SASL EXTERNAL Authentication Mechanism .............20 - 5.2.3.1. Implicit Assertion ........................21 - 5.2.3.2. Explicit Assertion ........................21 - 6. Security Considerations ........................................21 - 6.1. General LDAP Security Considerations ......................21 - 6.2. StartTLS Security Considerations ..........................22 - 6.3. Bind Operation Security Considerations ....................23 - 6.3.1. Unauthenticated Mechanism Security Considerations ..23 - - - -Harrison Standards Track [Page 2] - -RFC 4513 LDAP Authentication Methods June 2006 - - - 6.3.2. Name/Password Mechanism Security Considerations ....23 - 6.3.3. Password-Related Security Considerations ...........23 - 6.3.4. Hashed Password Security Considerations ............24 - 6.4. SASL Security Considerations ..............................24 - 6.5. Related Security Considerations ...........................25 - 7. IANA Considerations ............................................25 - 8. Acknowledgements ...............................................25 - 9. Normative References ...........................................26 - 10. Informative References ........................................27 - Appendix A. Authentication and Authorization Concepts .............28 - A.1. Access Control Policy .....................................28 - A.2. Access Control Factors ....................................28 - A.3. Authentication, Credentials, Identity .....................28 - A.4. Authorization Identity ....................................29 - Appendix B. Summary of Changes ....................................29 - B.1. Changes Made to RFC 2251 ..................................30 - B.1.1. Section 4.2.1 ("Sequencing of the Bind Request") ...30 - B.1.2. Section 4.2.2 ("Authentication and Other Security - Services") .........................................30 - B.2. Changes Made to RFC 2829 ..................................30 - B.2.1. Section 4 ("Required security mechanisms") .........30 - B.2.2. Section 5.1 ("Anonymous authentication - procedure") ........................................31 - B.2.3. Section 6 ("Password-based authentication") ........31 - B.2.4. Section 6.1 ("Digest authentication") ..............31 - B.2.5. Section 6.2 ("'simple' authentication choice under - TLS encryption") ...................................31 - B.2.6. Section 6.3 ("Other authentication choices with - TLS") ..............................................31 - B.2.7. Section 7.1 ("Certificate-based authentication - with TLS") .........................................31 - B.2.8. Section 8 ("Other mechanisms") .....................32 - B.2.9. Section 9 ("Authorization Identity") ...............32 - B.2.10. Section 10 ("TLS Ciphersuites") ...................32 - B.3. Changes Made to RFC 2830 ..................................32 - B.3.1. Section 3.6 ("Server Identity Check") ..............32 - B.3.2. Section 3.7 ("Refresh of Server Capabilities - Information") ......................................33 - B.3.3. Section 5 ("Effects of TLS on a Client's - Authorization Identity") ...........................33 - B.3.4. Section 5.2 ("TLS Connection Closure Effects") .....33 - - - - - - - - - - -Harrison Standards Track [Page 3] - -RFC 4513 LDAP Authentication Methods June 2006 - - -1. Introduction - - The Lightweight Directory Access Protocol (LDAP) [RFC4510] is a - powerful protocol for accessing directories. It offers means of - searching, retrieving, and manipulating directory content and ways to - access a rich set of security functions. - - It is vital that these security functions be interoperable among all - LDAP clients and servers on the Internet; therefore there has to be a - minimum subset of security functions that is common to all - implementations that claim LDAP conformance. - - Basic threats to an LDAP directory service include (but are not - limited to): - - (1) Unauthorized access to directory data via data-retrieval - operations. - - (2) Unauthorized access to directory data by monitoring access of - others. - - (3) Unauthorized access to reusable client authentication information - by monitoring access of others. - - (4) Unauthorized modification of directory data. - - (5) Unauthorized modification of configuration information. - - (6) Denial of Service: Use of resources (commonly in excess) in a - manner intended to deny service to others. - - (7) Spoofing: Tricking a user or client into believing that - information came from the directory when in fact it did not, - either by modifying data in transit or misdirecting the client's - transport connection. Tricking a user or client into sending - privileged information to a hostile entity that appears to be the - directory server but is not. Tricking a directory server into - believing that information came from a particular client when in - fact it came from a hostile entity. - - (8) Hijacking: An attacker seizes control of an established protocol - session. - - Threats (1), (4), (5), (6), (7), and (8) are active attacks. Threats - (2) and (3) are passive attacks. - - - - - - -Harrison Standards Track [Page 4] - -RFC 4513 LDAP Authentication Methods June 2006 - - - Threats (1), (4), (5), and (6) are due to hostile clients. Threats - (2), (3), (7), and (8) are due to hostile agents on the path between - client and server or hostile agents posing as a server, e.g., IP - spoofing. - - LDAP offers the following security mechanisms: - - (1) Authentication by means of the Bind operation. The Bind - operation provides a simple method that supports anonymous, - unauthenticated, and name/password mechanisms, and the Simple - Authentication and Security Layer (SASL) method, which supports a - wide variety of authentication mechanisms. - - (2) Mechanisms to support vendor-specific access control facilities - (LDAP does not offer a standard access control facility). - - (3) Data integrity service by means of security layers in Transport - Layer Security (TLS) or SASL mechanisms. - - (4) Data confidentiality service by means of security layers in TLS - or SASL mechanisms. - - (5) Server resource usage limitation by means of administrative - limits configured on the server. - - (6) Server authentication by means of the TLS protocol or SASL - mechanisms. - - LDAP may also be protected by means outside the LDAP protocol, e.g., - with IP layer security [RFC4301]. - - Experience has shown that simply allowing implementations to pick and - choose the security mechanisms that will be implemented is not a - strategy that leads to interoperability. In the absence of mandates, - clients will continue to be written that do not support any security - function supported by the server, or worse, they will only support - mechanisms that provide inadequate security for most circumstances. - - It is desirable to allow clients to authenticate using a variety of - mechanisms including mechanisms where identities are represented as - distinguished names [X.501][RFC4512], in string form [RFC4514], or as - used in different systems (e.g., simple user names [RFC4013]). - Because some authentication mechanisms transmit credentials in plain - text form, and/or do not provide data security services and/or are - subject to passive attacks, it is necessary to ensure secure - interoperability by identifying a mandatory-to-implement mechanism - for establishing transport-layer security services. - - - - -Harrison Standards Track [Page 5] - -RFC 4513 LDAP Authentication Methods June 2006 - - - The set of security mechanisms provided in LDAP and described in this - document is intended to meet the security needs for a wide range of - deployment scenarios and still provide a high degree of - interoperability among various LDAP implementations and deployments. - -1.1. Relationship to Other Documents - - This document is an integral part of the LDAP Technical Specification - [RFC4510]. - - This document, together with [RFC4510], [RFC4511], and [RFC4512], - obsoletes RFC 2251 in its entirety. Sections 4.2.1 (portions) and - 4.2.2 of RFC 2251 are obsoleted by this document. Appendix B.1 - summarizes the substantive changes made to RFC 2251 by this document. - - This document obsoletes RFC 2829 in its entirety. Appendix B.2 - summarizes the substantive changes made to RFC 2829 by this document. - - Sections 2 and 4 of RFC 2830 are obsoleted by [RFC4511]. The - remainder of RFC 2830 is obsoleted by this document. Appendix B.3 - summarizes the substantive changes made to RFC 2830 by this document. - -1.2. Conventions - - The key words "MUST", "MUST NOT", "SHALL", "SHOULD", "SHOULD NOT", - "MAY", and "OPTIONAL" in this document are to be interpreted as - described in RFC 2119 [RFC2119]. - - The term "user" represents any human or application entity that is - accessing the directory using a directory client. A directory client - (or client) is also known as a directory user agent (DUA). - - The term "transport connection" refers to the underlying transport - services used to carry the protocol exchange, as well as associations - established by these services. - - The term "TLS layer" refers to TLS services used in providing - security services, as well as associations established by these - services. - - The term "SASL layer" refers to SASL services used in providing - security services, as well as associations established by these - services. - - The term "LDAP message layer" refers to the LDAP Message (PDU) - services used in providing directory services, as well as - associations established by these services. - - - - -Harrison Standards Track [Page 6] - -RFC 4513 LDAP Authentication Methods June 2006 - - - The term "LDAP session" refers to combined services (transport - connection, TLS layer, SASL layer, LDAP message layer) and their - associations. - - In general, security terms in this document are used consistently - with the definitions provided in [RFC2828]. In addition, several - terms and concepts relating to security, authentication, and - authorization are presented in Appendix A of this document. While - the formal definition of these terms and concepts is outside the - scope of this document, an understanding of them is prerequisite to - understanding much of the material in this document. Readers who are - unfamiliar with security-related concepts are encouraged to review - Appendix A before reading the remainder of this document. - -2. Implementation Requirements - - LDAP server implementations MUST support the anonymous authentication - mechanism of the simple Bind method (Section 5.1.1). - - LDAP implementations that support any authentication mechanism other - than the anonymous authentication mechanism of the simple Bind method - MUST support the name/password authentication mechanism of the simple - Bind method (Section 5.1.3) and MUST be capable of protecting this - name/password authentication using TLS as established by the StartTLS - operation (Section 3). - - Implementations SHOULD disallow the use of the name/password - authentication mechanism by default when suitable data security - services are not in place, and they MAY provide other suitable data - security services for use with this authentication mechanism. - - Implementations MAY support additional authentication mechanisms. - Some of these mechanisms are discussed below. - - LDAP server implementations SHOULD support client assertion of - authorization identity via the SASL EXTERNAL mechanism (Section - 5.2.3). - - LDAP server implementations that support no authentication mechanism - other than the anonymous mechanism of the simple bind method SHOULD - support use of TLS as established by the StartTLS operation (Section - 3). (Other servers MUST support TLS per the second paragraph of this - section.) - - - - - - - - -Harrison Standards Track [Page 7] - -RFC 4513 LDAP Authentication Methods June 2006 - - - Implementations supporting TLS MUST support the - TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite and SHOULD support the - TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite. Support for the - latter ciphersuite is recommended to encourage interoperability with - implementations conforming to earlier LDAP StartTLS specifications. - -3. StartTLS Operation - - The Start Transport Layer Security (StartTLS) operation defined in - Section 4.14 of [RFC4511] provides the ability to establish TLS - [RFC4346] in an LDAP session. - - The goals of using the TLS protocol with LDAP are to ensure data - confidentiality and integrity, and to optionally provide for - authentication. TLS expressly provides these capabilities, although - the authentication services of TLS are available to LDAP only in - combination with the SASL EXTERNAL authentication method (see Section - 5.2.3), and then only if the SASL EXTERNAL implementation chooses to - make use of the TLS credentials. - -3.1. TLS Establishment Procedures - - This section describes the overall procedures clients and servers - must follow for TLS establishment. These procedures take into - consideration various aspects of the TLS layer including discovery of - resultant security level and assertion of the client's authorization - identity. - -3.1.1. StartTLS Request Sequencing - - A client may send the StartTLS extended request at any time after - establishing an LDAP session, except: - - - when TLS is currently established on the session, - - when a multi-stage SASL negotiation is in progress on the - session, or - - when there are outstanding responses for operation requests - previously issued on the session. - - As described in [RFC4511], Section 4.14.1, a (detected) violation of - any of these requirements results in a return of the operationsError - resultCode. - - Client implementers should ensure that they strictly follow these - operation sequencing requirements to prevent interoperability issues. - Operational experience has shown that violating these requirements - - - - - -Harrison Standards Track [Page 8] - -RFC 4513 LDAP Authentication Methods June 2006 - - - causes interoperability issues because there are race conditions that - prevent servers from detecting some violations of these requirements - due to factors such as server hardware speed and network latencies. - - There is no general requirement that the client have or have not - already performed a Bind operation (Section 5) before sending a - StartTLS operation request; however, where a client intends to - perform both a Bind operation and a StartTLS operation, it SHOULD - first perform the StartTLS operation so that the Bind request and - response messages are protected by the data security services - established by the StartTLS operation. - -3.1.2. Client Certificate - - If an LDAP server requests or demands that a client provide a user - certificate during TLS negotiation and the client does not present a - suitable user certificate (e.g., one that can be validated), the - server may use a local security policy to determine whether to - successfully complete TLS negotiation. - - If a client that has provided a suitable certificate subsequently - performs a Bind operation using the SASL EXTERNAL authentication - mechanism (Section 5.2.3), information in the certificate may be used - by the server to identify and authenticate the client. - -3.1.3. Server Identity Check - - In order to prevent man-in-the-middle attacks, the client MUST verify - the server's identity (as presented in the server's Certificate - message). In this section, the client's understanding of the - server's identity (typically the identity used to establish the - transport connection) is called the "reference identity". - - The client determines the type (e.g., DNS name or IP address) of the - reference identity and performs a comparison between the reference - identity and each subjectAltName value of the corresponding type - until a match is produced. Once a match is produced, the server's - identity has been verified, and the server identity check is - complete. Different subjectAltName types are matched in different - ways. Sections 3.1.3.1 - 3.1.3.3 explain how to compare values of - various subjectAltName types. - - The client may map the reference identity to a different type prior - to performing a comparison. Mappings may be performed for all - available subjectAltName types to which the reference identity can be - mapped; however, the reference identity should only be mapped to - types for which the mapping is either inherently secure (e.g., - extracting the DNS name from a URI to compare with a subjectAltName - - - -Harrison Standards Track [Page 9] - -RFC 4513 LDAP Authentication Methods June 2006 - - - of type dNSName) or for which the mapping is performed in a secure - manner (e.g., using DNSSEC, or using user- or admin-configured host- - to-address/address-to-host lookup tables). - - The server's identity may also be verified by comparing the reference - identity to the Common Name (CN) [RFC4519] value in the leaf Relative - Distinguished Name (RDN) of the subjectName field of the server's - certificate. This comparison is performed using the rules for - comparison of DNS names in Section 3.1.3.1, below, with the exception - that no wildcard matching is allowed. Although the use of the Common - Name value is existing practice, it is deprecated, and Certification - Authorities are encouraged to provide subjectAltName values instead. - Note that the TLS implementation may represent DNs in certificates - according to X.500 or other conventions. For example, some X.500 - implementations order the RDNs in a DN using a left-to-right (most - significant to least significant) convention instead of LDAP's - right-to-left convention. - - If the server identity check fails, user-oriented clients SHOULD - either notify the user (clients may give the user the opportunity to - continue with the LDAP session in this case) or close the transport - connection and indicate that the server's identity is suspect. - Automated clients SHOULD close the transport connection and then - return or log an error indicating that the server's identity is - suspect or both. - - Beyond the server identity check described in this section, clients - should be prepared to do further checking to ensure that the server - is authorized to provide the service it is requested to provide. The - client may need to make use of local policy information in making - this determination. - -3.1.3.1. Comparison of DNS Names - - If the reference identity is an internationalized domain name, - conforming implementations MUST convert it to the ASCII Compatible - Encoding (ACE) format as specified in Section 4 of RFC 3490 [RFC3490] - before comparison with subjectAltName values of type dNSName. - Specifically, conforming implementations MUST perform the conversion - operation specified in Section 4 of RFC 3490 as follows: - - * in step 1, the domain name SHALL be considered a "stored - string"; - * in step 3, set the flag called "UseSTD3ASCIIRules"; - * in step 4, process each label with the "ToASCII" operation; and - * in step 5, change all label separators to U+002E (full stop). - - - - - -Harrison Standards Track [Page 10] - -RFC 4513 LDAP Authentication Methods June 2006 - - - After performing the "to-ASCII" conversion, the DNS labels and names - MUST be compared for equality according to the rules specified in - Section 3 of RFC3490. - - The '*' (ASCII 42) wildcard character is allowed in subjectAltName - values of type dNSName, and then only as the left-most (least - significant) DNS label in that value. This wildcard matches any - left-most DNS label in the server name. That is, the subject - *.example.com matches the server names a.example.com and - b.example.com, but does not match example.com or a.b.example.com. - -3.1.3.2. Comparison of IP Addresses - - When the reference identity is an IP address, the identity MUST be - converted to the "network byte order" octet string representation - [RFC791][RFC2460]. For IP Version 4, as specified in RFC 791, the - octet string will contain exactly four octets. For IP Version 6, as - specified in RFC 2460, the octet string will contain exactly sixteen - octets. This octet string is then compared against subjectAltName - values of type iPAddress. A match occurs if the reference identity - octet string and value octet strings are identical. - -3.1.3.3. Comparison of Other subjectName Types - - Client implementations MAY support matching against subjectAltName - values of other types as described in other documents. - -3.1.4. Discovery of Resultant Security Level - - After a TLS layer is established in an LDAP session, both parties are - to each independently decide whether or not to continue based on - local policy and the security level achieved. If either party - decides that the security level is inadequate for it to continue, it - SHOULD remove the TLS layer immediately after the TLS (re)negotiation - has completed (see [RFC4511], Section 4.14.3, and Section 3.2 below). - Implementations may reevaluate the security level at any time and, - upon finding it inadequate, should remove the TLS layer. - -3.1.5. Refresh of Server Capabilities Information - - After a TLS layer is established in an LDAP session, the client - SHOULD discard or refresh all information about the server that it - obtained prior to the initiation of the TLS negotiation and that it - did not obtain through secure mechanisms. This protects against - man-in-the-middle attacks that may have altered any server - capabilities information retrieved prior to TLS layer installation. - - - - - -Harrison Standards Track [Page 11] - -RFC 4513 LDAP Authentication Methods June 2006 - - - The server may advertise different capabilities after installing a - TLS layer. In particular, the value of 'supportedSASLMechanisms' may - be different after a TLS layer has been installed (specifically, the - EXTERNAL and PLAIN [PLAIN] mechanisms are likely to be listed only - after a TLS layer has been installed). - -3.2. Effect of TLS on Authorization State - - The establishment, change, and/or closure of TLS may cause the - authorization state to move to a new state. This is discussed - further in Section 4. - -3.3. TLS Ciphersuites - - Several issues should be considered when selecting TLS ciphersuites - that are appropriate for use in a given circumstance. These issues - include the following: - - - The ciphersuite's ability to provide adequate confidentiality - protection for passwords and other data sent over the transport - connection. Client and server implementers should recognize - that some TLS ciphersuites provide no confidentiality - protection, while other ciphersuites that do provide - confidentiality protection may be vulnerable to being cracked - using brute force methods, especially in light of ever- - increasing CPU speeds that reduce the time needed to - successfully mount such attacks. - - - Client and server implementers should carefully consider the - value of the password or data being protected versus the level - of confidentiality protection provided by the ciphersuite to - ensure that the level of protection afforded by the ciphersuite - is appropriate. - - - The ciphersuite's vulnerability (or lack thereof) to man-in-the- - middle attacks. Ciphersuites vulnerable to man-in-the-middle - attacks SHOULD NOT be used to protect passwords or sensitive - data, unless the network configuration is such that the danger - of a man-in-the-middle attack is negligible. - - - After a TLS negotiation (either initial or subsequent) is - completed, both protocol peers should independently verify that - the security services provided by the negotiated ciphersuite are - adequate for the intended use of the LDAP session. If they are - not, the TLS layer should be closed. - - - - - - -Harrison Standards Track [Page 12] - -RFC 4513 LDAP Authentication Methods June 2006 - - -4. Authorization State - - Every LDAP session has an associated authorization state. This state - is comprised of numerous factors such as what (if any) authentication - state has been established, how it was established, and what security - services are in place. Some factors may be determined and/or - affected by protocol events (e.g., Bind, StartTLS, or TLS closure), - and some factors may be determined by external events (e.g., time of - day or server load). - - While it is often convenient to view authorization state in - simplistic terms (as we often do in this technical specification) - such as "an anonymous state", it is noted that authorization systems - in LDAP implementations commonly involve many factors that - interrelate in complex manners. - - Authorization in LDAP is a local matter. One of the key factors in - making authorization decisions is authorization identity. The Bind - operation (defined in Section 4.2 of [RFC4511] and discussed further - in Section 5 below) allows information to be exchanged between the - client and server to establish an authorization identity for the LDAP - session. The Bind operation may also be used to move the LDAP - session to an anonymous authorization state (see Section 5.1.1). - - Upon initial establishment of the LDAP session, the session has an - anonymous authorization identity. Among other things this implies - that the client need not send a BindRequest in the first PDU of the - LDAP message layer. The client may send any operation request prior - to performing a Bind operation, and the server MUST treat it as if it - had been performed after an anonymous Bind operation (Section 5.1.1). - - Upon receipt of a Bind request, the server immediately moves the - session to an anonymous authorization state. If the Bind request is - successful, the session is moved to the requested authentication - state with its associated authorization state. Otherwise, the - session remains in an anonymous state. - - It is noted that other events both internal and external to LDAP may - result in the authentication and authorization states being moved to - an anonymous one. For instance, the establishment, change, or - closure of data security services may result in a move to an - anonymous state, or the user's credential information (e.g., - certificate) may have expired. The former is an example of an event - internal to LDAP, whereas the latter is an example of an event - external to LDAP. - - - - - - -Harrison Standards Track [Page 13] - -RFC 4513 LDAP Authentication Methods June 2006 - - -5. Bind Operation - - The Bind operation ([RFC4511], Section 4.2) allows authentication - information to be exchanged between the client and server to - establish a new authorization state. - - The Bind request typically specifies the desired authentication - identity. Some Bind mechanisms also allow the client to specify the - authorization identity. If the authorization identity is not - specified, the server derives it from the authentication identity in - an implementation-specific manner. - - If the authorization identity is specified, the server MUST verify - that the client's authentication identity is permitted to assume - (e.g., proxy for) the asserted authorization identity. The server - MUST reject the Bind operation with an invalidCredentials resultCode - in the Bind response if the client is not so authorized. - -5.1. Simple Authentication Method - - The simple authentication method of the Bind Operation provides three - authentication mechanisms: - - - An anonymous authentication mechanism (Section 5.1.1). - - - An unauthenticated authentication mechanism (Section 5.1.2). - - - A name/password authentication mechanism using credentials - consisting of a name (in the form of an LDAP distinguished name - [RFC4514]) and a password (Section 5.1.3). - -5.1.1. Anonymous Authentication Mechanism of Simple Bind - - An LDAP client may use the anonymous authentication mechanism of the - simple Bind method to explicitly establish an anonymous authorization - state by sending a Bind request with a name value of zero length and - specifying the simple authentication choice containing a password - value of zero length. - -5.1.2. Unauthenticated Authentication Mechanism of Simple Bind - - An LDAP client may use the unauthenticated authentication mechanism - of the simple Bind method to establish an anonymous authorization - state by sending a Bind request with a name value (a distinguished - name in LDAP string form [RFC4514] of non-zero length) and specifying - the simple authentication choice containing a password value of zero - length. - - - - -Harrison Standards Track [Page 14] - -RFC 4513 LDAP Authentication Methods June 2006 - - - The distinguished name value provided by the client is intended to be - used for trace (e.g., logging) purposes only. The value is not to be - authenticated or otherwise validated (including verification that the - DN refers to an existing directory object). The value is not to be - used (directly or indirectly) for authorization purposes. - - Unauthenticated Bind operations can have significant security issues - (see Section 6.3.1). In particular, users intending to perform - Name/Password Authentication may inadvertently provide an empty - password and thus cause poorly implemented clients to request - Unauthenticated access. Clients SHOULD be implemented to require - user selection of the Unauthenticated Authentication Mechanism by - means other than user input of an empty password. Clients SHOULD - disallow an empty password input to a Name/Password Authentication - user interface. Additionally, Servers SHOULD by default fail - Unauthenticated Bind requests with a resultCode of - unwillingToPerform. - -5.1.3. Name/Password Authentication Mechanism of Simple Bind - - An LDAP client may use the name/password authentication mechanism of - the simple Bind method to establish an authenticated authorization - state by sending a Bind request with a name value (a distinguished - name in LDAP string form [RFC4514] of non-zero length) and specifying - the simple authentication choice containing an OCTET STRING password - value of non-zero length. - - Servers that map the DN sent in the Bind request to a directory entry - with an associated set of one or more passwords used with this - mechanism will compare the presented password to that set of - passwords. The presented password is considered valid if it matches - any member of this set. - - A resultCode of invalidDNSyntax indicates that the DN sent in the - name value is syntactically invalid. A resultCode of - invalidCredentials indicates that the DN is syntactically correct but - not valid for purposes of authentication, that the password is not - valid for the DN, or that the server otherwise considers the - credentials invalid. A resultCode of success indicates that the - credentials are valid and that the server is willing to provide - service to the entity these credentials identify. - - Server behavior is undefined for Bind requests specifying the - name/password authentication mechanism with a zero-length name value - and a password value of non-zero length. - - - - - - -Harrison Standards Track [Page 15] - -RFC 4513 LDAP Authentication Methods June 2006 - - - The name/password authentication mechanism of the simple Bind method - is not suitable for authentication in environments without - confidentiality protection. - -5.2. SASL Authentication Method - - The sasl authentication method of the Bind Operation provides - facilities for using any SASL mechanism including authentication - mechanisms and other services (e.g., data security services). - -5.2.1. SASL Protocol Profile - - LDAP allows authentication via any SASL mechanism [RFC4422]. As LDAP - includes native anonymous and name/password (plain text) - authentication methods, the ANONYMOUS [RFC4505] and PLAIN [PLAIN] - SASL mechanisms are typically not used with LDAP. - - Each protocol that utilizes SASL services is required to supply - certain information profiling the way they are exposed through the - protocol ([RFC4422], Section 4). This section explains how each of - these profiling requirements is met by LDAP. - -5.2.1.1. SASL Service Name for LDAP - - The SASL service name for LDAP is "ldap", which has been registered - with the IANA as a SASL service name. - -5.2.1.2. SASL Authentication Initiation and Protocol Exchange - - SASL authentication is initiated via a BindRequest message - ([RFC4511], Section 4.2) with the following parameters: - - - The version is 3. - - The AuthenticationChoice is sasl. - - The mechanism element of the SaslCredentials sequence contains - the value of the desired SASL mechanism. - - The optional credentials field of the SaslCredentials sequence - MAY be used to provide an initial client response for mechanisms - that are defined to have the client send data first (see - [RFC4422], Sections 3 and 5). - - In general, a SASL authentication protocol exchange consists of a - series of server challenges and client responses, the contents of - which are specific to and defined by the SASL mechanism. Thus, for - some SASL authentication mechanisms, it may be necessary for the - client to respond to one or more server challenges by sending - BindRequest messages multiple times. A challenge is indicated by the - server sending a BindResponse message with the resultCode set to - - - -Harrison Standards Track [Page 16] - -RFC 4513 LDAP Authentication Methods June 2006 - - - saslBindInProgress. This indicates that the server requires the - client to send a new BindRequest message with the same SASL mechanism - to continue the authentication process. - - To the LDAP message layer, these challenges and responses are opaque - binary tokens of arbitrary length. LDAP servers use the - serverSaslCreds field (an OCTET STRING) in a BindResponse message to - transmit each challenge. LDAP clients use the credentials field (an - OCTET STRING) in the SaslCredentials sequence of a BindRequest - message to transmit each response. Note that unlike some Internet - protocols where SASL is used, LDAP is not text based and does not - Base64-transform these challenge and response values. - - Clients sending a BindRequest message with the sasl choice selected - SHOULD send a zero-length value in the name field. Servers receiving - a BindRequest message with the sasl choice selected SHALL ignore any - value in the name field. - - A client may abort a SASL Bind negotiation by sending a BindRequest - message with a different value in the mechanism field of - SaslCredentials or with an AuthenticationChoice other than sasl. - - If the client sends a BindRequest with the sasl mechanism field as an - empty string, the server MUST return a BindResponse with a resultCode - of authMethodNotSupported. This will allow the client to abort a - negotiation if it wishes to try again with the same SASL mechanism. - - The server indicates completion of the SASL challenge-response - exchange by responding with a BindResponse in which the resultCode - value is not saslBindInProgress. - - The serverSaslCreds field in the BindResponse can be used to include - an optional challenge with a success notification for mechanisms that - are defined to have the server send additional data along with the - indication of successful completion. - -5.2.1.3. Optional Fields - - As discussed above, LDAP provides an optional field for carrying an - initial response in the message initiating the SASL exchange and - provides an optional field for carrying additional data in the - message indicating the outcome of the authentication exchange. As - the mechanism-specific content in these fields may be zero length, - SASL requires protocol specifications to detail how an empty field is - distinguished from an absent field. - - - - - - -Harrison Standards Track [Page 17] - -RFC 4513 LDAP Authentication Methods June 2006 - - - Zero-length initial response data is distinguished from no initial - response data in the initiating message, a BindRequest PDU, by the - presence of the SaslCredentials.credentials OCTET STRING (of length - zero) in that PDU. If the client does not intend to send an initial - response with the BindRequest initiating the SASL exchange, it MUST - omit the SaslCredentials.credentials OCTET STRING (rather than - include an zero-length OCTET STRING). - - Zero-length additional data is distinguished from no additional - response data in the outcome message, a BindResponse PDU, by the - presence of the serverSaslCreds OCTET STRING (of length zero) in that - PDU. If a server does not intend to send additional data in the - BindResponse message indicating outcome of the exchange, the server - SHALL omit the serverSaslCreds OCTET STRING (rather than including a - zero-length OCTET STRING). - -5.2.1.4. Octet Where Negotiated Security Layers Take Effect - - SASL layers take effect following the transmission by the server and - reception by the client of the final BindResponse in the SASL - exchange with a resultCode of success. - - Once a SASL layer providing data integrity or confidentiality - services takes effect, the layer remains in effect until a new layer - is installed (i.e., at the first octet following the final - BindResponse of the Bind operation that caused the new layer to take - effect). Thus, an established SASL layer is not affected by a failed - or non-SASL Bind. - -5.2.1.5. Determination of Supported SASL Mechanisms - - Clients may determine the SASL mechanisms a server supports by - reading the 'supportedSASLMechanisms' attribute from the root DSE - (DSA-Specific Entry) ([RFC4512], Section 5.1). The values of this - attribute, if any, list the mechanisms the server supports in the - current LDAP session state. LDAP servers SHOULD allow all clients -- - even those with an anonymous authorization -- to retrieve the - 'supportedSASLMechanisms' attribute of the root DSE both before and - after the SASL authentication exchange. The purpose of the latter is - to allow the client to detect possible downgrade attacks (see Section - 6.4 and [RFC4422], Section 6.1.2). - - Because SASL mechanisms provide critical security functions, clients - and servers should be configurable to specify what mechanisms are - acceptable and allow only those mechanisms to be used. Both clients - and servers must confirm that the negotiated security level meets - their requirements before proceeding to use the session. - - - - -Harrison Standards Track [Page 18] - -RFC 4513 LDAP Authentication Methods June 2006 - - -5.2.1.6. Rules for Using SASL Layers - - Upon installing a SASL layer, the client SHOULD discard or refresh - all information about the server that it obtained prior to the - initiation of the SASL negotiation and that it did not obtain through - secure mechanisms. - - If a lower-level security layer (such as TLS) is installed, any SASL - layer SHALL be layered on top of such security layers regardless of - the order of their negotiation. In all other respects, the SASL - layer and other security layers act independently, e.g., if both a - TLS layer and a SASL layer are in effect, then removing the TLS layer - does not affect the continuing service of the SASL layer. - -5.2.1.7. Support for Multiple Authentications - - LDAP supports multiple SASL authentications as defined in [RFC4422], - Section 4. - -5.2.1.8. SASL Authorization Identities - - Some SASL mechanisms allow clients to request a desired authorization - identity for the LDAP session ([RFC4422], Section 3.4). The decision - to allow or disallow the current authentication identity to have - access to the requested authorization identity is a matter of local - policy. The authorization identity is a string of UTF-8 [RFC3629] - encoded [Unicode] characters corresponding to the following Augmented - Backus-Naur Form (ABNF) [RFC4234] grammar: - - authzId = dnAuthzId / uAuthzId - - ; distinguished-name-based authz id - dnAuthzId = "dn:" distinguishedName - - ; unspecified authorization id, UTF-8 encoded - uAuthzId = "u:" userid - userid = *UTF8 ; syntax unspecified - - where the distinguishedName rule is defined in Section 3 of [RFC4514] - and the UTF8 rule is defined in Section 1.4 of [RFC4512]. - - The dnAuthzId choice is used to assert authorization identities in - the form of a distinguished name to be matched in accordance with the - distinguishedNameMatch matching rule ([RFC4517], Section 4.2.15). - There is no requirement that the asserted distinguishedName value be - that of an entry in the directory. - - - - - -Harrison Standards Track [Page 19] - -RFC 4513 LDAP Authentication Methods June 2006 - - - The uAuthzId choice allows clients to assert an authorization - identity that is not in distinguished name form. The format of - userid is defined only as a sequence of UTF-8 [RFC3629] encoded - [Unicode] characters, and any further interpretation is a local - matter. For example, the userid could identify a user of a specific - directory service, be a login name, or be an email address. A - uAuthzId SHOULD NOT be assumed to be globally unique. To compare - uAuthzId values, each uAuthzId value MUST be prepared as a "query" - string ([RFC3454], Section 7) using the SASLprep [RFC4013] algorithm, - and then the two values are compared octet-wise. - - The above grammar is extensible. The authzId production may be - extended to support additional forms of identities. Each form is - distinguished by its unique prefix (see Section 3.12 of [RFC4520] for - registration requirements). - -5.2.2. SASL Semantics within LDAP - - Implementers must take care to maintain the semantics of SASL - specifications when handling data that has different semantics in the - LDAP protocol. - - For example, the SASL DIGEST-MD5 authentication mechanism - [DIGEST-MD5] utilizes an authentication identity and a realm that are - syntactically simple strings and semantically simple username - [RFC4013] and realm values. These values are not LDAP DNs, and there - is no requirement that they be represented or treated as such. - -5.2.3. SASL EXTERNAL Authentication Mechanism - - A client can use the SASL EXTERNAL ([RFC4422], Appendix A) mechanism - to request the LDAP server to authenticate and establish a resulting - authorization identity using security credentials exchanged by a - lower security layer (such as by TLS authentication). If the - client's authentication credentials have not been established at a - lower security layer, the SASL EXTERNAL Bind MUST fail with a - resultCode of inappropriateAuthentication. Although this situation - has the effect of leaving the LDAP session in an anonymous state - (Section 4), the state of any installed security layer is unaffected. - - A client may either request that its authorization identity be - automatically derived from its authentication credentials exchanged - at a lower security layer, or it may explicitly provide a desired - authorization identity. The former is known as an implicit - assertion, and the latter as an explicit assertion. - - - - - - -Harrison Standards Track [Page 20] - -RFC 4513 LDAP Authentication Methods June 2006 - - -5.2.3.1. Implicit Assertion - - An implicit authorization identity assertion is performed by invoking - a Bind request of the SASL form using the EXTERNAL mechanism name - that does not include the optional credentials field (found within - the SaslCredentials sequence in the BindRequest). The server will - derive the client's authorization identity from the authentication - identity supplied by a security layer (e.g., a public key certificate - used during TLS layer installation) according to local policy. The - underlying mechanics of how this is accomplished are implementation - specific. - -5.2.3.2. Explicit Assertion - - An explicit authorization identity assertion is performed by invoking - a Bind request of the SASL form using the EXTERNAL mechanism name - that includes the credentials field (found within the SaslCredentials - sequence in the BindRequest). The value of the credentials field (an - OCTET STRING) is the asserted authorization identity and MUST be - constructed as documented in Section 5.2.1.8. - -6. Security Considerations - - Security issues are discussed throughout this document. The - unsurprising conclusion is that security is an integral and necessary - part of LDAP. This section discusses a number of LDAP-related - security considerations. - -6.1. General LDAP Security Considerations - - LDAP itself provides no security or protection from accessing or - updating the directory by means other than through the LDAP protocol, - e.g., from inspection of server database files by database - administrators. - - Sensitive data may be carried in almost any LDAP message, and its - disclosure may be subject to privacy laws or other legal regulation - in many countries. Implementers should take appropriate measures to - protect sensitive data from disclosure to unauthorized entities. - - A session on which the client has not established data integrity and - privacy services (e.g., via StartTLS, IPsec, or a suitable SASL - mechanism) is subject to man-in-the-middle attacks to view and modify - information in transit. Client and server implementers SHOULD take - measures to protect sensitive data in the LDAP session from these - attacks by using data protection services as discussed in this - document. Clients and servers should provide the ability to be - configured to require these protections. A resultCode of - - - -Harrison Standards Track [Page 21] - -RFC 4513 LDAP Authentication Methods June 2006 - - - confidentialityRequired indicates that the server requires - establishment of (stronger) data confidentiality protection in order - to perform the requested operation. - - Access control should always be applied when reading sensitive - information or updating directory information. - - Various security factors, including authentication and authorization - information and data security services may change during the course - of the LDAP session, or even during the performance of a particular - operation. Implementations should be robust in the handling of - changing security factors. - -6.2. StartTLS Security Considerations - - All security gained via use of the StartTLS operation is gained by - the use of TLS itself. The StartTLS operation, on its own, does not - provide any additional security. - - The level of security provided through the use of TLS depends - directly on both the quality of the TLS implementation used and the - style of usage of that implementation. Additionally, a man-in-the- - middle attacker can remove the StartTLS extended operation from the - 'supportedExtension' attribute of the root DSE. Both parties SHOULD - independently ascertain and consent to the security level achieved - once TLS is established and before beginning use of the TLS- - protected session. For example, the security level of the TLS layer - might have been negotiated down to plaintext. - - Clients MUST either warn the user when the security level achieved - does not provide an acceptable level of data confidentiality and/or - data integrity protection, or be configurable to refuse to proceed - without an acceptable level of security. - - As stated in Section 3.1.2, a server may use a local security policy - to determine whether to successfully complete TLS negotiation. - Information in the user's certificate that is originated or verified - by the certification authority should be used by the policy - administrator when configuring the identification and authorization - policy. - - Server implementers SHOULD allow server administrators to elect - whether and when data confidentiality and integrity are required, as - well as elect whether authentication of the client during the TLS - handshake is required. - - Implementers should be aware of and understand TLS security - considerations as discussed in the TLS specification [RFC4346]. - - - -Harrison Standards Track [Page 22] - -RFC 4513 LDAP Authentication Methods June 2006 - - -6.3. Bind Operation Security Considerations - - This section discusses several security considerations relevant to - LDAP authentication via the Bind operation. - -6.3.1. Unauthenticated Mechanism Security Considerations - - Operational experience shows that clients can (and frequently do) - misuse the unauthenticated authentication mechanism of the simple - Bind method (see Section 5.1.2). For example, a client program might - make a decision to grant access to non-directory information on the - basis of successfully completing a Bind operation. LDAP server - implementations may return a success response to an unauthenticated - Bind request. This may erroneously leave the client with the - impression that the server has successfully authenticated the - identity represented by the distinguished name when in reality, an - anonymous authorization state has been established. Clients that use - the results from a simple Bind operation to make authorization - decisions should actively detect unauthenticated Bind requests (by - verifying that the supplied password is not empty) and react - appropriately. - -6.3.2. Name/Password Mechanism Security Considerations - - The name/password authentication mechanism of the simple Bind method - discloses the password to the server, which is an inherent security - risk. There are other mechanisms, such as SASL DIGEST-MD5 - [DIGEST-MD5], that do not disclose the password to the server. - -6.3.3. Password-Related Security Considerations - - LDAP allows multi-valued password attributes. In systems where - entries are expected to have one and only one password, - administrative controls should be provided to enforce this behavior. - - The use of clear text passwords and other unprotected authentication - credentials is strongly discouraged over open networks when the - underlying transport service cannot guarantee confidentiality. LDAP - implementations SHOULD NOT by default support authentication methods - using clear text passwords and other unprotected authentication - credentials unless the data on the session is protected using TLS or - other data confidentiality and data integrity protection. - - The transmission of passwords in the clear -- typically for - authentication or modification -- poses a significant security risk. - This risk can be avoided by using SASL authentication [RFC4422] - - - - - -Harrison Standards Track [Page 23] - -RFC 4513 LDAP Authentication Methods June 2006 - - - mechanisms that do not transmit passwords in the clear or by - negotiating transport or session layer data confidentiality services - before transmitting password values. - - To mitigate the security risks associated with the transfer of - passwords, a server implementation that supports any password-based - authentication mechanism that transmits passwords in the clear MUST - support a policy mechanism that at the time of authentication or - password modification, requires that: - - A TLS layer has been successfully installed. - - OR - - Some other data confidentiality mechanism that protects the - password value from eavesdropping has been provided. - - OR - - The server returns a resultCode of confidentialityRequired for - the operation (i.e., name/password Bind with password value, - SASL Bind transmitting a password value in the clear, add or - modify including a userPassword value, etc.), even if the - password value is correct. - - Server implementations may also want to provide policy mechanisms to - invalidate or otherwise protect accounts in situations where a server - detects that a password for an account has been transmitted in the - clear. - -6.3.4. Hashed Password Security Considerations - - Some authentication mechanisms (e.g., DIGEST-MD5) transmit a hash of - the password value that may be vulnerable to offline dictionary - attacks. Implementers should take care to protect such hashed - password values during transmission using TLS or other - confidentiality mechanisms. - -6.4. SASL Security Considerations - - Until data integrity service is installed on an LDAP session, an - attacker can modify the transmitted values of the - 'supportedSASLMechanisms' attribute response and thus downgrade the - list of available SASL mechanisms to include only the least secure - mechanism. To detect this type of attack, the client may retrieve - the SASL mechanisms the server makes available both before and after - data integrity service is installed on an LDAP session. If the - client finds that the integrity-protected list (the list obtained - - - -Harrison Standards Track [Page 24] - -RFC 4513 LDAP Authentication Methods June 2006 - - - after data integrity service was installed) contains a stronger - mechanism than those in the previously obtained list, the client - should assume the previously obtained list was modified by an - attacker. In this circumstance it is recommended that the client - close the underlying transport connection and then reconnect to - reestablish the session. - -6.5. Related Security Considerations - - Additional security considerations relating to the various - authentication methods and mechanisms discussed in this document - apply and can be found in [RFC4422], [RFC4013], [RFC3454], and - [RFC3629]. - -7. IANA Considerations - - The IANA has updated the LDAP Protocol Mechanism registry to indicate - that this document and [RFC4511] provide the definitive technical - specification for the StartTLS (1.3.6.1.4.1.1466.20037) extended - operation. - - The IANA has updated the LDAP LDAPMessage types registry to indicate - that this document and [RFC4511] provide the definitive technical - specification for the bindRequest (0) and bindResponse (1) message - types. - - The IANA has updated the LDAP Bind Authentication Method registry to - indicate that this document and [RFC4511] provide the definitive - technical specification for the simple (0) and sasl (3) bind - authentication methods. - - The IANA has updated the LDAP authzid prefixes registry to indicate - that this document provides the definitive technical specification - for the dnAuthzId (dn:) and uAuthzId (u:) authzid prefixes. - -8. Acknowledgements - - This document combines information originally contained in RFC 2251, - RFC 2829, and RFC 2830. RFC 2251 was a product of the Access, - Searching, and Indexing of Directories (ASID) Working Group. RFC - 2829 and RFC 2830 were products of the LDAP Extensions (LDAPEXT) - Working Group. - - This document is a product of the IETF LDAP Revision (LDAPBIS) - working group. - - - - - - -Harrison Standards Track [Page 25] - -RFC 4513 LDAP Authentication Methods June 2006 - - -9. Normative References - - [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, - September 1981. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 - (IPv6) Specification", RFC 2460, December 1998. - - [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of - Internationalized Strings ("stringprep")", RFC 3454, - December 2002. - - [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, - "Internationalizing Domain Names in Applications - (IDNA)", RFC 3490, March 2003. - - [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO - 10646", STD 63, RFC 3629, November 2003. - - [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User - Names and Passwords", RFC 4013, February 2005. - - [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 4234, October 2005. - - [RFC4346] Dierks, T. and E. Rescorla, "The TLS Protocol Version - 1.1", RFC 4346, March 2006. - - [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple - Authentication and Security Layer (SASL)", RFC 4422, - June 2006. - - [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access - Protocol (LDAP): Technical Specification Road Map", RFC - 4510, June 2006. - - [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access - Protocol (LDAP): The Protocol", RFC 4511, June 2006. - - [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP): Directory Information Models", RFC 4512, June - 2006. - - - - - - -Harrison Standards Track [Page 26] - -RFC 4513 LDAP Authentication Methods June 2006 - - - [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access - Protocol (LDAP): String Representation of Distinguished - Names", RFC 4514, June 2006. - - [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol - (LDAP): Syntaxes and Matching Rules", RFC 4517, June - 2006. - - [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access - Protocol (LDAP): Schema for User Applications", RFC - 4519, June 2006. - - [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority - (IANA) Considerations for the Lightweight Directory - Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. - - [Unicode] The Unicode Consortium, "The Unicode Standard, Version - 3.2.0" is defined by "The Unicode Standard, Version 3.0" - (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633- - 5), as amended by the "Unicode Standard Annex #27: - Unicode 3.1" (http://www.unicode.org/reports/tr27/) and - by the "Unicode Standard Annex #28: Unicode 3.2" - (http://www.unicode.org/reports/tr28/). - - [X.501] ITU-T Rec. X.501, "The Directory: Models", 1993. - -10. Informative References - - [DIGEST-MD5] Leach, P., Newman, C., and A. Melnikov, "Using Digest - Authentication as a SASL Mechanism", Work in Progress, - March 2006. - - [PLAIN] Zeilenga, K., "The Plain SASL Mechanism", Work in - Progress, March 2005. - - [RFC2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC - 2828, May 2000. - - [RFC4301] Kent, S. and K. Seo, "Security Architecture for the - Internet Protocol", RFC 4301, December 2005. - - [RFC4505] Zeilenga, K., "The Anonymous SASL Mechanism", RFC 4505, - June 2006. - - - - - - - - -Harrison Standards Track [Page 27] - -RFC 4513 LDAP Authentication Methods June 2006 - - -Appendix A. Authentication and Authorization Concepts - - This appendix is non-normative. - - This appendix defines basic terms, concepts, and interrelationships - regarding authentication, authorization, credentials, and identity. - These concepts are used in describing how various security approaches - are utilized in client authentication and authorization. - -A.1. Access Control Policy - - An access control policy is a set of rules defining the protection of - resources, generally in terms of the capabilities of persons or other - entities accessing those resources. Security objects and mechanisms, - such as those described here, enable the expression of access control - policies and their enforcement. - -A.2. Access Control Factors - - A request, when it is being processed by a server, may be associated - with a wide variety of security-related factors. The server uses - these factors to determine whether and how to process the request. - These are called access control factors (ACFs). They might include - source IP address, encryption strength, the type of operation being - requested, time of day, etc.. Some factors may be specific to the - request itself; others may be associated with the transport - connection via which the request is transmitted; and others (e.g., - time of day) may be "environmental". - - Access control policies are expressed in terms of access control - factors; for example, "a request having ACFs i,j,k can perform - operation Y on resource Z". The set of ACFs that a server makes - available for such expressions is implementation specific. - -A.3. Authentication, Credentials, Identity - - Authentication credentials are the evidence supplied by one party to - another, asserting the identity of the supplying party (e.g., a user) - who is attempting to establish a new authorization state with the - other party (typically a server). Authentication is the process of - generating, transmitting, and verifying these credentials and thus - the identity they assert. An authentication identity is the name - presented in a credential. - - There are many forms of authentication credentials. The form used - depends upon the particular authentication mechanism negotiated by - the parties. X.509 certificates, Kerberos tickets, and simple - identity and password pairs are all examples of authentication - - - -Harrison Standards Track [Page 28] - -RFC 4513 LDAP Authentication Methods June 2006 - - - credential forms. Note that an authentication mechanism may - constrain the form of authentication identities used with it. - -A.4. Authorization Identity - - An authorization identity is one kind of access control factor. It - is the name of the user or other entity that requests that operations - be performed. Access control policies are often expressed in terms - of authorization identities; for example, "entity X can perform - operation Y on resource Z". - - The authorization identity of an LDAP session is often semantically - the same as the authentication identity presented by the client, but - it may be different. SASL allows clients to specify an authorization - identity distinct from the authentication identity asserted by the - client's credentials. This permits agents such as proxy servers to - authenticate using their own credentials, yet request the access - privileges of the identity for which they are proxying [RFC4422]. - Also, the form of authentication identity supplied by a service like - TLS may not correspond to the authorization identities used to - express a server's access control policy, thus requiring a server- - specific mapping to be done. The method by which a server composes - and validates an authorization identity from the authentication - credentials supplied by a client is implementation specific. - -Appendix B. Summary of Changes - - This appendix is non-normative. - - This appendix summarizes substantive changes made to RFC 2251, RFC - 2829 and RFC 2830. In addition to the specific changes detailed - below, the reader of this document should be aware that numerous - general editorial changes have been made to the original content from - the source documents. These changes include the following: - - - The material originally found in RFC 2251 Sections 4.2.1 and 4.2.2, - RFC 2829 (all sections except Sections 2 and 4), and RFC 2830 was - combined into a single document. - - - The combined material was substantially reorganized and edited to - group related subjects, improve the document flow, and clarify - intent. - - - Changes were made throughout the text to align with definitions of - LDAP protocol layers and IETF security terminology. - - - - - - -Harrison Standards Track [Page 29] - -RFC 4513 LDAP Authentication Methods June 2006 - - - - Substantial updates and additions were made to security - considerations from both documents based on current operational - experience. - -B.1. Changes Made to RFC 2251 - - This section summarizes the substantive changes made to Sections - 4.2.1 and 4.2.2 of RFC 2251 by this document. Additional substantive - changes to Section 4.2.1 of RFC 2251 are also documented in - [RFC4511]. - -B.1.1. Section 4.2.1 ("Sequencing of the Bind Request") - - - Paragraph 1: Removed the sentence, "If at any stage the client - wishes to abort the bind process it MAY unbind and then drop the - underlying connection". The Unbind operation still permits this - behavior, but it is not documented explicitly. - - - Clarified that the session is moved to an anonymous state upon - receipt of the BindRequest PDU and that it is only moved to a non- - anonymous state if and when the Bind request is successful. - -B.1.2. Section 4.2.2 ("Authentication and Other Security Services") - - - RFC 2251 states that anonymous authentication MUST be performed - using the simple bind method. This specification defines the - anonymous authentication mechanism of the simple bind method and - requires all conforming implementations to support it. Other - authentication mechanisms producing anonymous authentication and - authorization state may also be implemented and used by conforming - implementations. - -B.2. Changes Made to RFC 2829 - - This section summarizes the substantive changes made to RFC 2829. - -B.2.1. Section 4 ("Required security mechanisms") - - - The name/password authentication mechanism (see Section B.2.5 - below) protected by TLS replaces the SASL DIGEST-MD5 mechanism as - LDAP's mandatory-to-implement password-based authentication - mechanism. Implementations are encouraged to continue supporting - SASL DIGEST-MD5 [DIGEST-MD5]. - - - - - - - - -Harrison Standards Track [Page 30] - -RFC 4513 LDAP Authentication Methods June 2006 - - -B.2.2. Section 5.1 ("Anonymous authentication procedure") - - - Clarified that anonymous authentication involves a name value of - zero length and a password value of zero length. The - unauthenticated authentication mechanism was added to handle simple - Bind requests involving a name value with a non-zero length and a - password value of zero length. - -B.2.3. Section 6 ("Password-based authentication") - - - See Section B.2.1. - -B.2.4. Section 6.1 ("Digest authentication") - - - As the SASL-DIGEST-MD5 mechanism is no longer mandatory to - implement, this section is now historical and was not included in - this document. RFC 2829, Section 6.1, continues to document the - SASL DIGEST-MD5 authentication mechanism. - -B.2.5. Section 6.2 ("'simple' authentication choice under TLS - encryption") - - - Renamed the "simple" authentication mechanism to the name/password - authentication mechanism to better describe it. - - - The use of TLS was generalized to align with definitions of LDAP - protocol layers. TLS establishment is now discussed as an - independent subject and is generalized for use with all - authentication mechanisms and other security layers. - - - Removed the implication that the userPassword attribute is the sole - location for storage of password values to be used in - authentication. There is no longer any implied requirement for how - or where passwords are stored at the server for use in - authentication. - -B.2.6. Section 6.3 ("Other authentication choices with TLS") - - - See Section B.2.5. - -B.2.7. Section 7.1 ("Certificate-based authentication with TLS") - - - See Section B.2.5. - - - - - - - - -Harrison Standards Track [Page 31] - -RFC 4513 LDAP Authentication Methods June 2006 - - -B.2.8. Section 8 ("Other mechanisms") - - - All SASL authentication mechanisms are explicitly allowed within - LDAP. Specifically, this means the SASL ANONYMOUS and SASL PLAIN - mechanisms are no longer precluded from use within LDAP. - -B.2.9. Section 9 ("Authorization Identity") - - - Specified matching rules for dnAuthzId and uAuthzId values. In - particular, the DN value in the dnAuthzId form must be matched - using DN matching rules, and the uAuthzId value MUST be prepared - using SASLprep rules before being compared octet-wise. - - - Clarified that uAuthzId values should not be assumed to be globally - unique. - -B.2.10. Section 10 ("TLS Ciphersuites") - - - TLS ciphersuite recommendations are no longer included in this - specification. Implementations must now support the - TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite and should continue to - support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite. - - - Clarified that anonymous authentication involves a name value of - zero length and a password value of zero length. The - unauthenticated authentication mechanism was added to handle simple - Bind requests involving a name value with a non-zero length and a - password value of zero length. - -B.3. Changes Made to RFC 2830 - - This section summarizes the substantive changes made to Sections 3 - and 5 of RFC 2830. Readers should consult [RFC4511] for summaries of - changes to other sections. - -B.3.1. Section 3.6 ("Server Identity Check") - - - Substantially updated the server identity check algorithm to ensure - that it is complete and robust. In particular, the use of all - relevant values in the subjectAltName and the subjectName fields - are covered by the algorithm and matching rules are specified for - each type of value. Mapped (derived) forms of the server identity - may now be used when the mapping is performed in a secure fashion. - - - - - - - - -Harrison Standards Track [Page 32] - -RFC 4513 LDAP Authentication Methods June 2006 - - -B.3.2. Section 3.7 ("Refresh of Server Capabilities Information") - - - Clients are no longer required to always refresh information about - server capabilities following TLS establishment. This is to allow - for situations where this information was obtained through a secure - mechanism. - -B.3.3. Section 5 ("Effects of TLS on a Client's Authorization - Identity") - - - Establishing a TLS layer on an LDAP session may now cause the - authorization state of the LDAP session to change. - -B.3.4. Section 5.2 ("TLS Connection Closure Effects") - - - Closing a TLS layer on an LDAP session changes the authentication - and authorization state of the LDAP session based on local policy. - Specifically, this means that implementations are not required to - change the authentication and authorization states to anonymous - upon TLS closure. - - - Replaced references to RFC 2401 with RFC 4301. - -Author's Address - - Roger Harrison - Novell, Inc. - 1800 S. Novell Place - Provo, UT 84606 - USA - - Phone: +1 801 861 2642 - EMail: roger_harrison@novell.com - - - - - - - - - - - - - - - - - - -Harrison Standards Track [Page 33] - -RFC 4513 LDAP Authentication Methods June 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Harrison Standards Track [Page 34] - diff --git a/source4/ldap_server/devdocs/rfc4514.txt b/source4/ldap_server/devdocs/rfc4514.txt deleted file mode 100644 index 036c077cbf..0000000000 --- a/source4/ldap_server/devdocs/rfc4514.txt +++ /dev/null @@ -1,843 +0,0 @@ - - - - - - -Network Working Group K. Zeilenga, Ed. -Request for Comments: 4514 OpenLDAP Foundation -Obsoletes: 2253 June 2006 -Category: Standards Track - - - Lightweight Directory Access Protocol (LDAP): - String Representation of Distinguished Names - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - The X.500 Directory uses distinguished names (DNs) as primary keys to - entries in the directory. This document defines the string - representation used in the Lightweight Directory Access Protocol - (LDAP) to transfer distinguished names. The string representation is - designed to give a clean representation of commonly used - distinguished names, while being able to represent any distinguished - name. - -1. Background and Intended Usage - - In X.500-based directory systems [X.500], including those accessed - using the Lightweight Directory Access Protocol (LDAP) [RFC4510], - distinguished names (DNs) are used to unambiguously refer to - directory entries [X.501][RFC4512]. - - The structure of a DN [X.501] is described in terms of ASN.1 [X.680]. - In the X.500 Directory Access Protocol [X.511] (and other ITU-defined - directory protocols), DNs are encoded using the Basic Encoding Rules - (BER) [X.690]. In LDAP, DNs are represented in the string form - described in this document. - - It is important to have a common format to be able to unambiguously - represent a distinguished name. The primary goal of this - specification is ease of encoding and decoding. A secondary goal is - to have names that are human readable. It is not expected that LDAP - - - -Zeilenga Standards Track [Page 1] - -RFC 4514 LDAP: Distinguished Names June 2006 - - - implementations with a human user interface would display these - strings directly to the user, but that they would most likely be - performing translations (such as expressing attribute type names in - the local national language). - - This document defines the string representation of Distinguished - Names used in LDAP [RFC4511][RFC4517]. Section 2 details the - RECOMMENDED algorithm for converting a DN from its ASN.1 structured - representation to a string. Section 3 details how to convert a DN - from a string to an ASN.1 structured representation. - - While other documents may define other algorithms for converting a DN - from its ASN.1 structured representation to a string, all algorithms - MUST produce strings that adhere to the requirements of Section 3. - - This document does not define a canonical string representation for - DNs. Comparison of DNs for equality is to be performed in accordance - with the distinguishedNameMatch matching rule [RFC4517]. - - This document is a integral part of the LDAP technical specification - [RFC4510], which obsoletes the previously defined LDAP technical - specification, RFC 3377, in its entirety. This document obsoletes - RFC 2253. Changes since RFC 2253 are summarized in Appendix B. - - This specification assumes familiarity with X.500 [X.500] and the - concept of Distinguished Name [X.501][RFC4512]. - -1.1. Conventions - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in BCP 14 [RFC2119]. - - Character names in this document use the notation for code points and - names from the Unicode Standard [Unicode]. For example, the letter - "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>. - - Note: a glossary of terms used in Unicode can be found in [Glossary]. - Information on the Unicode character encoding model can be found in - [CharModel]. - - - - - - - - - - - -Zeilenga Standards Track [Page 2] - -RFC 4514 LDAP: Distinguished Names June 2006 - - -2. Converting DistinguishedName from ASN.1 to a String - - X.501 [X.501] defines the ASN.1 [X.680] structure of distinguished - name. The following is a variant provided for discussion purposes. - - DistinguishedName ::= RDNSequence - - RDNSequence ::= SEQUENCE OF RelativeDistinguishedName - - RelativeDistinguishedName ::= SET SIZE (1..MAX) OF - AttributeTypeAndValue - - AttributeTypeAndValue ::= SEQUENCE { - type AttributeType, - value AttributeValue } - - This section defines the RECOMMENDED algorithm for converting a - distinguished name from an ASN.1-structured representation to a UTF-8 - [RFC3629] encoded Unicode [Unicode] character string representation. - Other documents may describe other algorithms for converting a - distinguished name to a string, but only strings that conform to the - grammar defined in Section 3 SHALL be produced by LDAP - implementations. - -2.1. Converting the RDNSequence - - If the RDNSequence is an empty sequence, the result is the empty or - zero-length string. - - Otherwise, the output consists of the string encodings of each - RelativeDistinguishedName in the RDNSequence (according to Section - 2.2), starting with the last element of the sequence and moving - backwards toward the first. - - The encodings of adjoining RelativeDistinguishedNames are separated - by a comma (',' U+002C) character. - -2.2. Converting RelativeDistinguishedName - - When converting from an ASN.1 RelativeDistinguishedName to a string, - the output consists of the string encodings of each - AttributeTypeAndValue (according to Section 2.3), in any order. - - Where there is a multi-valued RDN, the outputs from adjoining - AttributeTypeAndValues are separated by a plus sign ('+' U+002B) - character. - - - - - -Zeilenga Standards Track [Page 3] - -RFC 4514 LDAP: Distinguished Names June 2006 - - -2.3. Converting AttributeTypeAndValue - - The AttributeTypeAndValue is encoded as the string representation of - the AttributeType, followed by an equals sign ('=' U+003D) character, - followed by the string representation of the AttributeValue. The - encoding of the AttributeValue is given in Section 2.4. - - If the AttributeType is defined to have a short name (descriptor) - [RFC4512] and that short name is known to be registered [REGISTRY] - [RFC4520] as identifying the AttributeType, that short name, a - <descr>, is used. Otherwise the AttributeType is encoded as the - dotted-decimal encoding, a <numericoid>, of its OBJECT IDENTIFIER. - The <descr> and <numericoid> are defined in [RFC4512]. - - Implementations are not expected to dynamically update their - knowledge of registered short names. However, implementations SHOULD - provide a mechanism to allow their knowledge of registered short - names to be updated. - -2.4. Converting an AttributeValue from ASN.1 to a String - - If the AttributeType is of the dotted-decimal form, the - AttributeValue is represented by an number sign ('#' U+0023) - character followed by the hexadecimal encoding of each of the octets - of the BER encoding of the X.500 AttributeValue. This form is also - used when the syntax of the AttributeValue does not have an LDAP- - specific ([RFC4517], Section 3.1) string encoding defined for it, or - the LDAP-specific string encoding is not restricted to UTF-8-encoded - Unicode characters. This form may also be used in other cases, such - as when a reversible string representation is desired (see Section - 5.2). - - Otherwise, if the AttributeValue is of a syntax that has a LDAP- - specific string encoding, the value is converted first to a UTF-8- - encoded Unicode string according to its syntax specification (see - [RFC4517], Section 3.3, for examples). If that UTF-8-encoded Unicode - string does not have any of the following characters that need - escaping, then that string can be used as the string representation - of the value. - - - a space (' ' U+0020) or number sign ('#' U+0023) occurring at - the beginning of the string; - - - a space (' ' U+0020) character occurring at the end of the - string; - - - - - - -Zeilenga Standards Track [Page 4] - -RFC 4514 LDAP: Distinguished Names June 2006 - - - - one of the characters '"', '+', ',', ';', '<', '>', or '\' - (U+0022, U+002B, U+002C, U+003B, U+003C, U+003E, or U+005C, - respectively); - - - the null (U+0000) character. - - Other characters may be escaped. - - Each octet of the character to be escaped is replaced by a backslash - and two hex digits, which form a single octet in the code of the - character. Alternatively, if and only if the character to be escaped - is one of - - ' ', '"', '#', '+', ',', ';', '<', '=', '>', or '\' - (U+0020, U+0022, U+0023, U+002B, U+002C, U+003B, - U+003C, U+003D, U+003E, U+005C, respectively) - - it can be prefixed by a backslash ('\' U+005C). - - Examples of the escaping mechanism are shown in Section 4. - -3. Parsing a String Back to a Distinguished Name - - The string representation of Distinguished Names is restricted to - UTF-8 [RFC3629] encoded Unicode [Unicode] characters. The structure - of this string representation is specified using the following - Augmented BNF [RFC4234] grammar: - - distinguishedName = [ relativeDistinguishedName - *( COMMA relativeDistinguishedName ) ] - relativeDistinguishedName = attributeTypeAndValue - *( PLUS attributeTypeAndValue ) - attributeTypeAndValue = attributeType EQUALS attributeValue - attributeType = descr / numericoid - attributeValue = string / hexstring - - ; The following characters are to be escaped when they appear - ; in the value to be encoded: ESC, one of <escaped>, leading - ; SHARP or SPACE, trailing SPACE, and NULL. - string = [ ( leadchar / pair ) [ *( stringchar / pair ) - ( trailchar / pair ) ] ] - - leadchar = LUTF1 / UTFMB - LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A / - %x3D / %x3F-5B / %x5D-7F - - trailchar = TUTF1 / UTFMB - TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A / - - - -Zeilenga Standards Track [Page 5] - -RFC 4514 LDAP: Distinguished Names June 2006 - - - %x3D / %x3F-5B / %x5D-7F - - stringchar = SUTF1 / UTFMB - SUTF1 = %x01-21 / %x23-2A / %x2D-3A / - %x3D / %x3F-5B / %x5D-7F - - pair = ESC ( ESC / special / hexpair ) - special = escaped / SPACE / SHARP / EQUALS - escaped = DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE - hexstring = SHARP 1*hexpair - hexpair = HEX HEX - - where the productions <descr>, <numericoid>, <COMMA>, <DQUOTE>, - <EQUALS>, <ESC>, <HEX>, <LANGLE>, <NULL>, <PLUS>, <RANGLE>, <SEMI>, - <SPACE>, <SHARP>, and <UTFMB> are defined in [RFC4512]. - - Each <attributeType>, either a <descr> or a <numericoid>, refers to - an attribute type of an attribute value assertion (AVA). The - <attributeType> is followed by an <EQUALS> and an <attributeValue>. - The <attributeValue> is either in <string> or <hexstring> form. - - If in <string> form, a LDAP string representation asserted value can - be obtained by replacing (left to right, non-recursively) each <pair> - appearing in the <string> as follows: - - replace <ESC><ESC> with <ESC>; - replace <ESC><special> with <special>; - replace <ESC><hexpair> with the octet indicated by the <hexpair>. - - If in <hexstring> form, a BER representation can be obtained from - converting each <hexpair> of the <hexstring> to the octet indicated - by the <hexpair>. - - There is one or more attribute value assertions, separated by <PLUS>, - for a relative distinguished name. - - There is zero or more relative distinguished names, separated by - <COMMA>, for a distinguished name. - - Implementations MUST recognize AttributeType name strings - (descriptors) listed in the following table, but MAY recognize other - name strings. - - - - - - - - - -Zeilenga Standards Track [Page 6] - -RFC 4514 LDAP: Distinguished Names June 2006 - - - String X.500 AttributeType - ------ -------------------------------------------- - CN commonName (2.5.4.3) - L localityName (2.5.4.7) - ST stateOrProvinceName (2.5.4.8) - O organizationName (2.5.4.10) - OU organizationalUnitName (2.5.4.11) - C countryName (2.5.4.6) - STREET streetAddress (2.5.4.9) - DC domainComponent (0.9.2342.19200300.100.1.25) - UID userId (0.9.2342.19200300.100.1.1) - - These attribute types are described in [RFC4519]. - - Implementations MAY recognize other DN string representations. - However, as there is no requirement that alternative DN string - representations be recognized (and, if so, how), implementations - SHOULD only generate DN strings in accordance with Section 2 of this - document. - -4. Examples - - This notation is designed to be convenient for common forms of name. - This section gives a few examples of distinguished names written - using this notation. First is a name containing three relative - distinguished names (RDNs): - - UID=jsmith,DC=example,DC=net - - Here is an example of a name containing three RDNs, in which the - first RDN is multi-valued: - - OU=Sales+CN=J. Smith,DC=example,DC=net - - This example shows the method of escaping of a special characters - appearing in a common name: - - CN=James \"Jim\" Smith\, III,DC=example,DC=net - - The following shows the method for encoding a value that contains a - carriage return character: - - CN=Before\0dAfter,DC=example,DC=net - - In this RDN example, the type in the RDN is unrecognized, and the - value is the BER encoding of an OCTET STRING containing two octets, - 0x48 and 0x69. - - - - -Zeilenga Standards Track [Page 7] - -RFC 4514 LDAP: Distinguished Names June 2006 - - - 1.3.6.1.4.1.1466.0=#04024869 - - Finally, this example shows an RDN whose commonName value consists of - 5 letters: - - Unicode Character Code UTF-8 Escaped - ------------------------------- ------ ------ -------- - LATIN CAPITAL LETTER L U+004C 0x4C L - LATIN SMALL LETTER U U+0075 0x75 u - LATIN SMALL LETTER C WITH CARON U+010D 0xC48D \C4\8D - LATIN SMALL LETTER I U+0069 0x69 i - LATIN SMALL LETTER C WITH ACUTE U+0107 0xC487 \C4\87 - - This could be encoded in printable ASCII [ASCII] (useful for - debugging purposes) as: - - CN=Lu\C4\8Di\C4\87 - -5. Security Considerations - - The following security considerations are specific to the handling of - distinguished names. LDAP security considerations are discussed in - [RFC4511] and other documents comprising the LDAP Technical - Specification [RFC4510]. - -5.1. Disclosure - - Distinguished Names typically consist of descriptive information - about the entries they name, which can be people, organizations, - devices, or other real-world objects. This frequently includes some - of the following kinds of information: - - - the common name of the object (i.e., a person's full name) - - an email or TCP/IP address - - its physical location (country, locality, city, street address) - - organizational attributes (such as department name or - affiliation) - - In some cases, such information can be considered sensitive. In many - countries, privacy laws exist that prohibit disclosure of certain - kinds of descriptive information (e.g., email addresses). Hence, - server implementers are encouraged to support Directory Information - Tree (DIT) structural rules and name forms [RFC4512], as these - provide a mechanism for administrators to select appropriate naming - attributes for entries. Administrators are encouraged to use - mechanisms, access controls, and other administrative controls that - may be available to restrict use of attributes containing sensitive - information in naming of entries. Additionally, use of - - - -Zeilenga Standards Track [Page 8] - -RFC 4514 LDAP: Distinguished Names June 2006 - - - authentication and data security services in LDAP [RFC4513][RFC4511] - should be considered. - -5.2. Use of Distinguished Names in Security Applications - - The transformations of an AttributeValue value from its X.501 form to - an LDAP string representation are not always reversible back to the - same BER (Basic Encoding Rules) or DER (Distinguished Encoding Rules) - form. An example of a situation that requires the DER form of a - distinguished name is the verification of an X.509 certificate. - - For example, a distinguished name consisting of one RDN with one AVA, - in which the type is commonName and the value is of the TeletexString - choice with the letters 'Sam', would be represented in LDAP as the - string <CN=Sam>. Another distinguished name in which the value is - still 'Sam', but is of the PrintableString choice, would have the - same representation <CN=Sam>. - - Applications that require the reconstruction of the DER form of the - value SHOULD NOT use the string representation of attribute syntaxes - when converting a distinguished name to the LDAP format. Instead, - they SHOULD use the hexadecimal form prefixed by the number sign ('#' - U+0023) as described in the first paragraph of Section 2.4. - -6. Acknowledgements - - This document is an update to RFC 2253, by Mark Wahl, Tim Howes, and - Steve Kille. RFC 2253 was a product of the IETF ASID Working Group. - - This document is a product of the IETF LDAPBIS Working Group. - -7. References - -7.1. Normative References - - [REGISTRY] IANA, Object Identifier Descriptors Registry, - <http://www.iana.org/assignments/ldap-parameters>. - - [Unicode] The Unicode Consortium, "The Unicode Standard, Version - 3.2.0" is defined by "The Unicode Standard, Version - 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201- - 61633-5), as amended by the "Unicode Standard Annex - #27: Unicode 3.1" - (http://www.unicode.org/reports/tr27/) and by the - "Unicode Standard Annex #28: Unicode 3.2" - (http://www.unicode.org/reports/tr28/). - - - - - -Zeilenga Standards Track [Page 9] - -RFC 4514 LDAP: Distinguished Names June 2006 - - - [X.501] International Telecommunication Union - - Telecommunication Standardization Sector, "The - Directory -- Models," X.501(1993) (also ISO/IEC 9594- - 2:1994). - - [X.680] International Telecommunication Union - - Telecommunication Standardization Sector, "Abstract - Syntax Notation One (ASN.1) - Specification of Basic - Notation", X.680(1997) (also ISO/IEC 8824-1:1998). - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO - 10646", STD 63, RFC 3629, November 2003. - - [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 4234, October 2005. - - [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access - Protocol (LDAP): Technical Specification Road Map", RFC - 4510, June 2006. - - [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access - Protocol (LDAP): The Protocol", RFC 4511, June 2006. - - [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP): Directory Information Models", RFC 4512, June - 2006. - - [RFC4513] Harrison, R., Ed., "Lightweight Directory Access - Protocol (LDAP): Authentication Methods and Security - Mechanisms", RFC 4513, June 2006. - - [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol - (LDAP): Syntaxes and Matching Rules", RFC 4517, June - 2006. - - [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access - Protocol (LDAP): Schema for User Applications", RFC - 4519, June 2006. - - [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority - (IANA) Considerations for the Lightweight Directory - Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. - - - - - - -Zeilenga Standards Track [Page 10] - -RFC 4514 LDAP: Distinguished Names June 2006 - - -7.2. Informative References - - [ASCII] Coded Character Set--7-bit American Standard Code for - Information Interchange, ANSI X3.4-1986. - - [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report - #17, Character Encoding Model", UTR17, - <http://www.unicode.org/unicode/reports/tr17/>, August - 2000. - - [Glossary] The Unicode Consortium, "Unicode Glossary", - <http://www.unicode.org/glossary/>. - - [X.500] International Telecommunication Union - - Telecommunication Standardization Sector, "The - Directory -- Overview of concepts, models and - services," X.500(1993) (also ISO/IEC 9594-1:1994). - - [X.511] International Telecommunication Union - - Telecommunication Standardization Sector, "The - Directory: Abstract Service Definition", X.511(1993) - (also ISO/IEC 9594-3:1993). - - [X.690] International Telecommunication Union - - Telecommunication Standardization Sector, - "Specification of ASN.1 encoding rules: Basic Encoding - Rules (BER), Canonical Encoding Rules (CER), and - Distinguished Encoding Rules (DER)", X.690(1997) (also - ISO/IEC 8825-1:1998). - - [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - - Technical Specification", RFC 2849, June 2000. - - - - - - - - - - - - - - - - - - - -Zeilenga Standards Track [Page 11] - -RFC 4514 LDAP: Distinguished Names June 2006 - - -Appendix A. Presentation Issues - - This appendix is provided for informational purposes only; it is not - a normative part of this specification. - - The string representation described in this document is not intended - to be presented to humans without translation. However, at times it - may be desirable to present non-translated DN strings to users. This - section discusses presentation issues associated with non-translated - DN strings. Issues with presentation of translated DN strings are - not discussed in this appendix. Transcoding issues are also not - discussed in this appendix. - - This appendix provides guidance for applications presenting DN - strings to users. This section is not comprehensive; it does not - discuss all presentation issues that implementers may face. - - Not all user interfaces are capable of displaying the full set of - Unicode characters. Some Unicode characters are not displayable. - - It is recommended that human interfaces use the optional hex pair - escaping mechanism (Section 2.3) to produce a string representation - suitable for display to the user. For example, an application can - generate a DN string for display that escapes all non-printable - characters appearing in the AttributeValue's string representation - (as demonstrated in the final example of Section 4). - - When a DN string is displayed in free-form text, it is often - necessary to distinguish the DN string from surrounding text. While - this is often done with whitespace (as demonstrated in Section 4), it - is noted that DN strings may end with whitespace. Careful readers of - Section 3 will note that the characters '<' (U+003C) and '>' (U+003E) - may only appear in the DN string if escaped. These characters are - intended to be used in free-form text to distinguish a DN string from - surrounding text. For example, <CN=Sam\ > distinguishes the string - representation of the DN composed of one RDN consisting of the AVA - (the commonName (CN) value 'Sam ') from the surrounding text. It - should be noted to the user that the wrapping '<' and '>' characters - are not part of the DN string. - - DN strings can be quite long. It is often desirable to line-wrap - overly long DN strings in presentations. Line wrapping should be - done by inserting whitespace after the RDN separator character or, if - necessary, after the AVA separator character. It should be noted to - the user that the inserted whitespace is not part of the DN string - and is to be removed before use in LDAP. For example, the following - DN string is long: - - - - -Zeilenga Standards Track [Page 12] - -RFC 4514 LDAP: Distinguished Names June 2006 - - - CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores, - O=OpenLDAP Foundation,ST=California,C=US - - So it has been line-wrapped for readability. The extra whitespace is - to be removed before the DN string is used in LDAP. - - Inserting whitespace is not advised because it may not be obvious to - the user which whitespace is part of the DN string and which - whitespace was added for readability. - - Another alternative is to use the LDAP Data Interchange Format (LDIF) - [RFC2849]. For example: - - # This entry has a long DN... - dn: CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores, - O=OpenLDAP Foundation,ST=California,C=US - CN: Kurt D. Zeilenga - SN: Zeilenga - objectClass: person - -Appendix B. Changes Made since RFC 2253 - - This appendix is provided for informational purposes only, it is not - a normative part of this specification. - - The following substantive changes were made to RFC 2253: - - - Removed IESG Note. The IESG Note has been addressed. - - Replaced all references to ISO 10646-1 with [Unicode]. - - Clarified (in Section 1) that this document does not define a - canonical string representation. - - Clarified that Section 2 describes the RECOMMENDED encoding - algorithm and that alternative algorithms are allowed. Some - encoding options described in RFC 2253 are now treated as - alternative algorithms in this specification. - - Revised specification (in Section 2) to allow short names of any - registered attribute type to appear in string representations of - DNs instead of being restricted to a "published table". Removed - "as an example" language. Added statement (in Section 3) - allowing recognition of additional names but require recognition - of those names in the published table. The table now appears in - Section 3. - - Removed specification of additional requirements for LDAPv2 - implementations which also support LDAPv3 (RFC 2253, Section 4) - as LDAPv2 is now Historic. - - Allowed recognition of alternative string representations. - - Updated Section 2.4 to allow hex pair escaping of all characters - and clarified escaping for when multiple octet UTF-8 encodings - - - -Zeilenga Standards Track [Page 13] - -RFC 4514 LDAP: Distinguished Names June 2006 - - - are present. Indicated that null (U+0000) character is to be - escaped. Indicated that equals sign ('=' U+003D) character may - be escaped as '\='. - - Rewrote Section 3 to use ABNF as defined in RFC 4234. - - Updated the Section 3 ABNF. Changes include: - + allowed AttributeType short names of length 1 (e.g., 'L'), - + used more restrictive <oid> production in AttributeTypes, - + did not require escaping of equals sign ('=' U+003D) - characters, - + did not require escaping of non-leading number sign ('#' - U+0023) characters, - + allowed space (' ' U+0020) to be escaped as '\ ', - + required hex escaping of null (U+0000) characters, and - + removed LDAPv2-only constructs. - - Updated Section 3 to describe how to parse elements of the - grammar. - - Rewrote examples. - - Added reference to documentations containing general LDAP - security considerations. - - Added discussion of presentation issues (Appendix A). - - Added this appendix. - - In addition, numerous editorial changes were made. - -Editor's Address - - Kurt D. Zeilenga - OpenLDAP Foundation - - EMail: Kurt@OpenLDAP.org - - - - - - - - - - - - - - - - - - - - - -Zeilenga Standards Track [Page 14] - -RFC 4514 LDAP: Distinguished Names June 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Zeilenga Standards Track [Page 15] - diff --git a/source4/ldap_server/devdocs/rfc4515.txt b/source4/ldap_server/devdocs/rfc4515.txt deleted file mode 100644 index 86f03ebcd3..0000000000 --- a/source4/ldap_server/devdocs/rfc4515.txt +++ /dev/null @@ -1,675 +0,0 @@ - - - - - - -Network Working Group M. Smith, Ed. -Request for Comments: 4515 Pearl Crescent, LLC -Obsoletes: 2254 T. Howes -Category: Standards Track Opsware, Inc. - June 2006 - - - Lightweight Directory Access Protocol (LDAP): - String Representation of Search Filters - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - Lightweight Directory Access Protocol (LDAP) search filters are - transmitted in the LDAP protocol using a binary representation that - is appropriate for use on the network. This document defines a - human-readable string representation of LDAP search filters that is - appropriate for use in LDAP URLs (RFC 4516) and in other - applications. - -Table of Contents - - 1. Introduction ....................................................2 - 2. LDAP Search Filter Definition ...................................2 - 3. String Search Filter Definition .................................3 - 4. Examples ........................................................5 - 5. Security Considerations .........................................7 - 6. Normative References ............................................7 - 7. Informative References ..........................................8 - 8. Acknowledgements ................................................8 - Appendix A: Changes Since RFC 2254 .................................9 - A.1. Technical Changes ..........................................9 - A.2. Editorial Changes ..........................................9 - - - - - - - -Smith and Howes Standards Track [Page 1] - -RFC 4515 LDAP: String Representation of Search Filters June 2006 - - -1. Introduction - - The Lightweight Directory Access Protocol (LDAP) [RFC4510] defines a - network representation of a search filter transmitted to an LDAP - server. Some applications may find it useful to have a common way of - representing these search filters in a human-readable form; LDAP URLs - [RFC4516] are an example of one such application. This document - defines a human-readable string format for representing the full - range of possible LDAP version 3 search filters, including extended - match filters. - - This document is a integral part of the LDAP technical specification - [RFC4510], which obsoletes the previously defined LDAP technical - specification, RFC 3377, in its entirety. - - This document replaces RFC 2254. Changes to RFC 2254 are summarized - in Appendix A. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in BCP 14 [RFC2119]. - -2. LDAP Search Filter Definition - - An LDAP search filter is defined in Section 4.5.1 of [RFC4511] as - follows: - - Filter ::= CHOICE { - and [0] SET SIZE (1..MAX) OF filter Filter, - or [1] SET SIZE (1..MAX) OF filter Filter, - not [2] Filter, - equalityMatch [3] AttributeValueAssertion, - substrings [4] SubstringFilter, - greaterOrEqual [5] AttributeValueAssertion, - lessOrEqual [6] AttributeValueAssertion, - present [7] AttributeDescription, - approxMatch [8] AttributeValueAssertion, - extensibleMatch [9] MatchingRuleAssertion } - - SubstringFilter ::= SEQUENCE { - type AttributeDescription, - -- initial and final can occur at most once - substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE { - initial [0] AssertionValue, - any [1] AssertionValue, - final [2] AssertionValue } } - - - - - -Smith and Howes Standards Track [Page 2] - -RFC 4515 LDAP: String Representation of Search Filters June 2006 - - - AttributeValueAssertion ::= SEQUENCE { - attributeDesc AttributeDescription, - assertionValue AssertionValue } - - MatchingRuleAssertion ::= SEQUENCE { - matchingRule [1] MatchingRuleId OPTIONAL, - type [2] AttributeDescription OPTIONAL, - matchValue [3] AssertionValue, - dnAttributes [4] BOOLEAN DEFAULT FALSE } - - AttributeDescription ::= LDAPString - -- Constrained to <attributedescription> - -- [RFC4512] - - AttributeValue ::= OCTET STRING - - MatchingRuleId ::= LDAPString - - AssertionValue ::= OCTET STRING - - LDAPString ::= OCTET STRING -- UTF-8 encoded, - -- [Unicode] characters - - The AttributeDescription, as defined in [RFC4511], is a string - representation of the attribute description that is discussed in - [RFC4512]. The AttributeValue and AssertionValue OCTET STRING have - the form defined in [RFC4517]. The Filter is encoded for - transmission over a network using the Basic Encoding Rules (BER) - defined in [X.690], with simplifications described in [RFC4511]. - -3. String Search Filter Definition - - The string representation of an LDAP search filter is a string of - UTF-8 [RFC3629] encoded Unicode characters [Unicode] that is defined - by the following grammar, following the ABNF notation defined in - [RFC4234]. The productions used that are not defined here are - defined in Section 1.4 (Common ABNF Productions) of [RFC4512] unless - otherwise noted. The filter format uses a prefix notation. - - filter = LPAREN filtercomp RPAREN - filtercomp = and / or / not / item - and = AMPERSAND filterlist - or = VERTBAR filterlist - not = EXCLAMATION filter - filterlist = 1*filter - item = simple / present / substring / extensible - simple = attr filtertype assertionvalue - filtertype = equal / approx / greaterorequal / lessorequal - - - -Smith and Howes Standards Track [Page 3] - -RFC 4515 LDAP: String Representation of Search Filters June 2006 - - - equal = EQUALS - approx = TILDE EQUALS - greaterorequal = RANGLE EQUALS - lessorequal = LANGLE EQUALS - extensible = ( attr [dnattrs] - [matchingrule] COLON EQUALS assertionvalue ) - / ( [dnattrs] - matchingrule COLON EQUALS assertionvalue ) - present = attr EQUALS ASTERISK - substring = attr EQUALS [initial] any [final] - initial = assertionvalue - any = ASTERISK *(assertionvalue ASTERISK) - final = assertionvalue - attr = attributedescription - ; The attributedescription rule is defined in - ; Section 2.5 of [RFC4512]. - dnattrs = COLON "dn" - matchingrule = COLON oid - assertionvalue = valueencoding - ; The <valueencoding> rule is used to encode an <AssertionValue> - ; from Section 4.1.6 of [RFC4511]. - valueencoding = 0*(normal / escaped) - normal = UTF1SUBSET / UTFMB - escaped = ESC HEX HEX - UTF1SUBSET = %x01-27 / %x2B-5B / %x5D-7F - ; UTF1SUBSET excludes 0x00 (NUL), LPAREN, - ; RPAREN, ASTERISK, and ESC. - EXCLAMATION = %x21 ; exclamation mark ("!") - AMPERSAND = %x26 ; ampersand (or AND symbol) ("&") - ASTERISK = %x2A ; asterisk ("*") - COLON = %x3A ; colon (":") - VERTBAR = %x7C ; vertical bar (or pipe) ("|") - TILDE = %x7E ; tilde ("~") - - Note that although both the <substring> and <present> productions in - the grammar above can produce the "attr=*" construct, this construct - is used only to denote a presence filter. - - The <valueencoding> rule ensures that the entire filter string is a - valid UTF-8 string and provides that the octets that represent the - ASCII characters "*" (ASCII 0x2a), "(" (ASCII 0x28), ")" (ASCII - 0x29), "\" (ASCII 0x5c), and NUL (ASCII 0x00) are represented as a - backslash "\" (ASCII 0x5c) followed by the two hexadecimal digits - representing the value of the encoded octet. - - - - - - - -Smith and Howes Standards Track [Page 4] - -RFC 4515 LDAP: String Representation of Search Filters June 2006 - - - This simple escaping mechanism eliminates filter-parsing ambiguities - and allows any filter that can be represented in LDAP to be - represented as a NUL-terminated string. Other octets that are part - of the <normal> set may be escaped using this mechanism, for example, - non-printing ASCII characters. - - For AssertionValues that contain UTF-8 character data, each octet of - the character to be escaped is replaced by a backslash and two hex - digits, which form a single octet in the code of the character. For - example, the filter checking whether the "cn" attribute contained a - value with the character "*" anywhere in it would be represented as - "(cn=*\2a*)". - - As indicated by the <valueencoding> rule, implementations MUST escape - all octets greater than 0x7F that are not part of a valid UTF-8 - encoding sequence when they generate a string representation of a - search filter. Implementations SHOULD accept as input strings that - are not valid UTF-8 strings. This is necessary because RFC 2254 did - not clearly define the term "string representation" (and in - particular did not mention that the string representation of an LDAP - search filter is a string of UTF-8-encoded Unicode characters). - -4. Examples - - This section gives a few examples of search filters written using - this notation. - - (cn=Babs Jensen) - (!(cn=Tim Howes)) - (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*))) - (o=univ*of*mich*) - (seeAlso=) - - The following examples illustrate the use of extensible matching. - - (cn:caseExactMatch:=Fred Flintstone) - (cn:=Betty Rubble) - (sn:dn:2.4.6.8.10:=Barney Rubble) - (o:dn:=Ace Industry) - (:1.2.3:=Wilma Flintstone) - (:DN:2.4.6.8.10:=Dino) - - The first example shows use of the matching rule "caseExactMatch." - - The second example demonstrates use of a MatchingRuleAssertion form - without a matchingRule. - - - - - -Smith and Howes Standards Track [Page 5] - -RFC 4515 LDAP: String Representation of Search Filters June 2006 - - - The third example illustrates the use of the ":oid" notation to - indicate that the matching rule identified by the OID "2.4.6.8.10" - should be used when making comparisons, and that the attributes of an - entry's distinguished name should be considered part of the entry - when evaluating the match (indicated by the use of ":dn"). - - The fourth example denotes an equality match, except that DN - components should be considered part of the entry when doing the - match. - - The fifth example is a filter that should be applied to any attribute - supporting the matching rule given (since the <attr> has been - omitted). - - The sixth and final example is also a filter that should be applied - to any attribute supporting the matching rule given. Attributes - supporting the matching rule contained in the DN should also be - considered. - - The following examples illustrate the use of the escaping mechanism. - - (o=Parens R Us \28for all your parenthetical needs\29) - (cn=*\2A*) - (filename=C:\5cMyFile) - (bin=\00\00\00\04) - (sn=Lu\c4\8di\c4\87) - (1.3.6.1.4.1.1466.0=\04\02\48\69) - - The first example shows the use of the escaping mechanism to - represent parenthesis characters. The second shows how to represent - a "*" in an assertion value, preventing it from being interpreted as - a substring indicator. The third illustrates the escaping of the - backslash character. - - The fourth example shows a filter searching for the four-octet value - 00 00 00 04 (hex), illustrating the use of the escaping mechanism to - represent arbitrary data, including NUL characters. - - The fifth example illustrates the use of the escaping mechanism to - represent various non-ASCII UTF-8 characters. Specifically, there - are 5 characters in the <assertionvalue> portion of this example: - LATIN CAPITAL LETTER L (U+004C), LATIN SMALL LETTER U (U+0075), LATIN - SMALL LETTER C WITH CARON (U+010D), LATIN SMALL LETTER I (U+0069), - and LATIN SMALL LETTER C WITH ACUTE (U+0107). - - The sixth and final example demonstrates assertion of a BER-encoded - value. - - - - -Smith and Howes Standards Track [Page 6] - -RFC 4515 LDAP: String Representation of Search Filters June 2006 - - -5. Security Considerations - - This memo describes a string representation of LDAP search filters. - While the representation itself has no known security implications, - LDAP search filters do. They are interpreted by LDAP servers to - select entries from which data is retrieved. LDAP servers should - take care to protect the data they maintain from unauthorized access. - - Please refer to the Security Considerations sections of [RFC4511] and - [RFC4513] for more information. - -6. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO - 10646", STD 63, RFC 3629, November 2003. - - [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 4234, October 2005. - - [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol - (LDAP): Technical Specification Road Map", RFC 4510, June - 2006. - - [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access - Protocol (LDAP): The Protocol", RFC 4511, June 2006. - - [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP): Directory Information Models", RFC 4512, June - 2006. - - [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol - (LDAP): Authentication Methods and Security Mechanisms", - RFC 4513, June 2006. - - [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol - (LDAP): Syntaxes and Matching Rules", RFC 4517, June - 2006. - - [Unicode] The Unicode Consortium, "The Unicode Standard, Version - 3.2.0" is defined by "The Unicode Standard, Version 3.0" - (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), - as amended by the "Unicode Standard Annex #27: Unicode - 3.1" (http://www.unicode.org/reports/tr27/) and by the - "Unicode Standard Annex #28: Unicode 3.2." - - - - -Smith and Howes Standards Track [Page 7] - -RFC 4515 LDAP: String Representation of Search Filters June 2006 - - -7. Informative References - - [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory - Access Protocol (LDAP): Uniform Resource Locator", RFC - 4516, June 2006. - - [X.690] Specification of ASN.1 encoding rules: Basic, Canonical, - and Distinguished Encoding Rules, ITU-T Recommendation - X.690, 1994. - -8. Acknowledgements - - This document replaces RFC 2254 by Tim Howes. RFC 2254 was a product - of the IETF ASID Working Group. - - Changes included in this revised specification are based upon - discussions among the authors, discussions within the LDAP (v3) - Revision Working Group (ldapbis), and discussions within other IETF - Working Groups. The contributions of individuals in these working - groups is gratefully acknowledged. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Smith and Howes Standards Track [Page 8] - -RFC 4515 LDAP: String Representation of Search Filters June 2006 - - -Appendix A: Changes Since RFC 2254 - -A.1. Technical Changes - - Replaced [ISO 10646] reference with [Unicode]. - - The following technical changes were made to the contents of the - "String Search Filter Definition" section: - - Added statement that the string representation is a string of UTF-8- - encoded Unicode characters. - - Revised all of the ABNF to use common productions from [RFC4512]. - - Replaced the "value" rule with a new "assertionvalue" rule within the - "simple", "extensible", and "substring" ("initial", "any", and - "final") rules. This matches a change made in [RFC4517]. - - Added "(" and ")" around the components of the <extensible> - subproductions for clarity. - - Revised the "attr", "matchingrule", and "assertionvalue" ABNF to more - precisely reference productions from the [RFC4512] and [RFC4511] - documents. - - "String Search Filter Definition" section: replaced "greater" and - "less" with "greaterorequal" and "lessorequal" to avoid confusion. - - Introduced the "valueencoding" and associated "normal" and "escaped" - rules to reduce the dependence on descriptive text. The "normal" - production restricts filter strings to valid UTF-8 sequences. - - Added a statement about expected behavior in light of RFC 2254's lack - of a clear definition of "string representation." - -A.2. Editorial Changes - - Changed document title to include "LDAP:" prefix. - - IESG Note: removed note about lack of satisfactory mandatory - authentication mechanisms. - - Header and "Authors' Addresses" sections: added Mark Smith as the - document editor and updated affiliation and contact information. - - "Table of Contents" and "Intellectual Property" sections: added. - - Copyright: updated per latest IETF guidelines. - - - -Smith and Howes Standards Track [Page 9] - -RFC 4515 LDAP: String Representation of Search Filters June 2006 - - - "Abstract" section: separated from introductory material. - - "Introduction" section: new section; separated from the Abstract. - Updated second paragraph to indicate that RFC 2254 is replaced by - this document (instead of RFC 1960). Added reference to the - [RFC4510] document. - - "LDAP Search Filter Definition" section: made corrections to the LDAP - search filter ABNF so it matches that used in [RFC4511]. - - Clarified the definition of 'value' (now 'assertionvalue') to take - into account the fact that it is not precisely an AttributeAssertion - from [RFC4511] Section 4.1.6 (special handling is required for some - characters). Added a note that each octet of a character to be - escaped is replaced by a backslash and two hex digits, which - represent a single octet. - - "Examples" section: added four additional examples: (seeAlso=), - (cn:=Betty Rubble), (:1.2.3:=Wilma Flintstone), and - (1.3.6.1.4.1.1466.0=\04\02\48\69). Replaced one occurrence of "a - value" with "an assertion value". Corrected the description of this - example: (sn:dn:2.4.6.8.10:=Barney Rubble). Replaced the numeric OID - in the first extensible match example with "caseExactMatch" to - demonstrate use of the descriptive form. Used "DN" (uppercase) in - the last extensible match example to remind the reader to treat the - <dnattrs> production as case insensitive. Reworded the description - of the fourth escaping mechanism example to avoid making assumptions - about byte order. Added text to the fifth escaping mechanism example - to spell out what the non-ASCII characters are in Unicode terms. - - "Security Considerations" section: added references to [RFC4511] and - [RFC4513]. - - "Normative References" section: renamed from "References" per new RFC - guidelines. Changed from [1] style to [RFC4511] style throughout the - document. Added entries for [Unicode], [RFC2119], [RFC4513], - [RFC4512], and [RFC4510] and updated the UTF-8 reference. Replaced - RFC 822 reference with a reference to RFC 4234. - - "Informative References" section: (new section) moved [X.690] to this - section. Added a reference to [RFC4516]. - - "Acknowledgements" section: added. - - "Appendix A: Changes Since RFC 2254" section: added. - - Surrounded the names of all ABNF productions with "<" and ">" where - they are used in descriptive text. - - - -Smith and Howes Standards Track [Page 10] - -RFC 4515 LDAP: String Representation of Search Filters June 2006 - - - Replaced all occurrences of "LDAPv3" with "LDAP." - -Authors' Addresses - - Mark Smith, Editor - Pearl Crescent, LLC - 447 Marlpool Dr. - Saline, MI 48176 - USA - - Phone: +1 734 944-2856 - EMail: mcs@pearlcrescent.com - - - Tim Howes - Opsware, Inc. - 599 N. Mathilda Ave. - Sunnyvale, CA 94085 - USA - - Phone: +1 408 744-7509 - EMail: howes@opsware.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Smith and Howes Standards Track [Page 11] - -RFC 4515 LDAP: String Representation of Search Filters June 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Smith and Howes Standards Track [Page 12] - diff --git a/source4/ldap_server/devdocs/rfc4516.txt b/source4/ldap_server/devdocs/rfc4516.txt deleted file mode 100644 index 6de1e1d08a..0000000000 --- a/source4/ldap_server/devdocs/rfc4516.txt +++ /dev/null @@ -1,843 +0,0 @@ - - - - - - -Network Working Group M. Smith, Ed. -Request for Comments: 4516 Pearl Crescent, LLC -Obsoletes: 2255 T. Howes -Category: Standards Track Opsware, Inc. - June 2006 - - - Lightweight Directory Access Protocol (LDAP): - Uniform Resource Locator - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document describes a format for a Lightweight Directory Access - Protocol (LDAP) Uniform Resource Locator (URL). An LDAP URL - describes an LDAP search operation that is used to retrieve - information from an LDAP directory, or, in the context of an LDAP - referral or reference, an LDAP URL describes a service where an LDAP - operation may be progressed. - -Table of Contents - - 1. Introduction ....................................................2 - 2. URL Definition ..................................................2 - 2.1. Percent-Encoding ...........................................4 - 3. Defaults for Fields of the LDAP URL .............................5 - 4. Examples ........................................................6 - 5. Security Considerations .........................................8 - 6. Normative References ............................................9 - 7. Informative References .........................................10 - 8. Acknowledgements ...............................................10 - Appendix A: Changes Since RFC 2255 ................................11 - A.1. Technical Changes .........................................11 - A.2. Editorial Changes .........................................11 - - - - - - -Smith & Howes Standards Track [Page 1] - -RFC 4516 LDAP: Uniform Resource Locator June 2006 - - -1. Introduction - - LDAP is the Lightweight Directory Access Protocol [RFC4510]. This - document specifies the LDAP URL format for version 3 of LDAP and - clarifies how LDAP URLs are resolved. This document also defines an - extension mechanism for LDAP URLs. This mechanism may be used to - provide access to new LDAP extensions. - - Note that not all the parameters of the LDAP search operation - described in [RFC4511] can be expressed using the format defined in - this document. Note also that URLs may be used to represent - reference knowledge, including that for non-search operations. - - This document is an integral part of the LDAP technical specification - [RFC4510], which obsoletes the previously defined LDAP technical - specification, RFC 3377, in its entirety. - - This document replaces RFC 2255. See Appendix A for a list of - changes relative to RFC 2255. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in BCP 14 [RFC2119]. - -2. URL Definition - - An LDAP URL begins with the protocol prefix "ldap" and is defined by - the following grammar, following the ABNF notation defined in - [RFC4234]. - - ldapurl = scheme COLON SLASH SLASH [host [COLON port]] - [SLASH dn [QUESTION [attributes] - [QUESTION [scope] [QUESTION [filter] - [QUESTION extensions]]]]] - ; <host> and <port> are defined - ; in Sections 3.2.2 and 3.2.3 - ; of [RFC3986]. - ; <filter> is from Section 3 of - ; [RFC4515], subject to the - ; provisions of the - ; "Percent-Encoding" section - ; below. - - scheme = "ldap" - - - - - - - -Smith & Howes Standards Track [Page 2] - -RFC 4516 LDAP: Uniform Resource Locator June 2006 - - - dn = distinguishedName ; From Section 3 of [RFC4514], - ; subject to the provisions of - ; the "Percent-Encoding" - ; section below. - - attributes = attrdesc *(COMMA attrdesc) - attrdesc = selector *(COMMA selector) - selector = attributeSelector ; From Section 4.5.1 of - ; [RFC4511], subject to the - ; provisions of the - ; "Percent-Encoding" section - ; below. - - scope = "base" / "one" / "sub" - extensions = extension *(COMMA extension) - extension = [EXCLAMATION] extype [EQUALS exvalue] - extype = oid ; From section 1.4 of [RFC4512]. - - exvalue = LDAPString ; From section 4.1.2 of - ; [RFC4511], subject to the - ; provisions of the - ; "Percent-Encoding" section - ; below. - - EXCLAMATION = %x21 ; exclamation mark ("!") - SLASH = %x2F ; forward slash ("/") - COLON = %x3A ; colon (":") - QUESTION = %x3F ; question mark ("?") - - The "ldap" prefix indicates an entry or entries accessible from the - LDAP server running on the given hostname at the given portnumber. - Note that the <host> may contain literal IPv6 addresses as specified - in Section 3.2.2 of [RFC3986]. - - The <dn> is an LDAP Distinguished Name using the string format - described in [RFC4514]. It identifies the base object of the LDAP - search or the target of a non-search operation. - - The <attributes> construct is used to indicate which attributes - should be returned from the entry or entries. - - The <scope> construct is used to specify the scope of the search to - perform in the given LDAP server. The allowable scopes are "base" - for a base object search, "one" for a one-level search, or "sub" for - a subtree search. - - - - - - -Smith & Howes Standards Track [Page 3] - -RFC 4516 LDAP: Uniform Resource Locator June 2006 - - - The <filter> is used to specify the search filter to apply to entries - within the specified scope during the search. It has the format - specified in [RFC4515]. - - The <extensions> construct provides the LDAP URL with an - extensibility mechanism, allowing the capabilities of the URL to be - extended in the future. Extensions are a simple comma-separated list - of type=value pairs, where the =value portion MAY be omitted for - options not requiring it. Each type=value pair is a separate - extension. These LDAP URL extensions are not necessarily related to - any of the LDAP extension mechanisms. Extensions may be supported or - unsupported by the client resolving the URL. An extension prefixed - with a '!' character (ASCII 0x21) is critical. An extension not - prefixed with a '!' character is non-critical. - - If an LDAP URL extension is implemented (that is, if the - implementation understands it and is able to use it), the - implementation MUST make use of it. If an extension is not - implemented and is marked critical, the implementation MUST NOT - process the URL. If an extension is not implemented and is not - marked critical, the implementation MUST ignore the extension. - - The extension type (<extype>) MAY be specified using the numeric OID - <numericoid> form (e.g., 1.2.3.4) or the descriptor <descr> form - (e.g., myLDAPURLExtension). Use of the <descr> form SHOULD be - restricted to registered object identifier descriptive names. See - [RFC4520] for registration details and usage guidelines for - descriptive names. - - No LDAP URL extensions are defined in this document. Other documents - or a future version of this document MAY define one or more - extensions. - -2.1. Percent-Encoding - - A generated LDAP URL MUST consist only of the restricted set of - characters included in one of the following three productions defined - in [RFC3986]: - - <reserved> - <unreserved> - <pct-encoded> - - Implementations SHOULD accept other valid UTF-8 strings [RFC3629] as - input. An octet MUST be encoded using the percent-encoding mechanism - described in section 2.1 of [RFC3986] in any of these situations: - - - - - -Smith & Howes Standards Track [Page 4] - -RFC 4516 LDAP: Uniform Resource Locator June 2006 - - - The octet is not in the reserved set defined in section 2.2 of - [RFC3986] or in the unreserved set defined in section 2.3 of - [RFC3986]. - - It is the single Reserved character '?' and occurs inside a <dn>, - <filter>, or other element of an LDAP URL. - - It is a comma character ',' that occurs inside an <exvalue>. - - Note that before the percent-encoding mechanism is applied, the - extensions component of the LDAP URL may contain one or more null - (zero) bytes. No other component may. - -3. Defaults for Fields of the LDAP URL - - Some fields of the LDAP URL are optional, as described above. In the - absence of any other specification, the following general defaults - SHOULD be used when a field is absent. Note that other documents MAY - specify different defaulting rules; for example, section 4.1.10 of - [RFC4511] specifies a different rule for determining the correct DN - to use when it is absent in an LDAP URL that is returned as a - referral. - - <host> - If no <host> is given, the client must have some a priori - knowledge of an appropriate LDAP server to contact. - - <port> - The default LDAP port is TCP port 389. - - <dn> - If no <dn> is given, the default is the zero-length DN, "". - - <attributes> - If the <attributes> part is omitted, all user attributes of the - entry or entries should be requested (e.g., by setting the - attributes field AttributeDescriptionList in the LDAP search - request to a NULL list, or by using the special <alluserattrs> - selector "*"). - - <scope> - If <scope> is omitted, a <scope> of "base" is assumed. - - <filter> - If <filter> is omitted, a filter of "(objectClass=*)" is assumed. - - <extensions> - If <extensions> is omitted, no extensions are assumed. - - - -Smith & Howes Standards Track [Page 5] - -RFC 4516 LDAP: Uniform Resource Locator June 2006 - - -4. Examples - - The following are some example LDAP URLs that use the format defined - above. The first example is an LDAP URL referring to the University - of Michigan entry, available from an LDAP server of the client's - choosing: - - ldap:///o=University%20of%20Michigan,c=US - - The next example is an LDAP URL referring to the University of - Michigan entry in a particular ldap server: - - ldap://ldap1.example.net/o=University%20of%20Michigan,c=US - - Both of these URLs correspond to a base object search of the - "o=University of Michigan,c=US" entry using a filter of - "(objectclass=*)", requesting all attributes. - - The next example is an LDAP URL referring to only the postalAddress - attribute of the University of Michigan entry: - - ldap://ldap1.example.net/o=University%20of%20Michigan, - c=US?postalAddress - - The corresponding LDAP search operation is the same as in the - previous example, except that only the postalAddress attribute is - requested. - - The next example is an LDAP URL referring to the set of entries found - by querying the given LDAP server on port 6666 and doing a subtree - search of the University of Michigan for any entry with a common name - of "Babs Jensen", retrieving all attributes: - - ldap://ldap1.example.net:6666/o=University%20of%20Michigan, - c=US??sub?(cn=Babs%20Jensen) - - The next example is an LDAP URL referring to all children of the c=GB - entry: - - LDAP://ldap1.example.com/c=GB?objectClass?ONE - - The objectClass attribute is requested to be returned along with the - entries, and the default filter of "(objectclass=*)" is used. - - The next example is an LDAP URL to retrieve the mail attribute for - the LDAP entry named "o=Question?,c=US", illustrating the use of the - percent-encoding mechanism on the reserved character '?'. - - - - -Smith & Howes Standards Track [Page 6] - -RFC 4516 LDAP: Uniform Resource Locator June 2006 - - - ldap://ldap2.example.com/o=Question%3f,c=US?mail - - The next example (which is broken into two lines for readability) - illustrates the interaction between the LDAP string representation of - the filters-quoting mechanism and the URL-quoting mechanisms. - - ldap://ldap3.example.com/o=Babsco,c=US - ???(four-octet=%5c00%5c00%5c00%5c04) - - The filter in this example uses the LDAP escaping mechanism of \ to - encode three zero or null bytes in the value. In LDAP, the filter - would be written as (four-octet=\00\00\00\04). Because the \ - character must be escaped in a URL, the \s are percent-encoded as %5c - (or %5C) in the URL encoding. - - The next example illustrates the interaction between the LDAP string - representation of the DNs-quoting mechanism and URL-quoting - mechanisms. - - ldap://ldap.example.com/o=An%20Example%5C2C%20Inc.,c=US - - The DN encoded in the above URL is: - - o=An Example\2C Inc.,c=US - - That is, the left-most RDN value is: - - An Example, Inc. - - The following three URLs are equivalent, assuming that the defaulting - rules specified in Section 3 of this document are used: - - ldap://ldap.example.net - ldap://ldap.example.net/ - ldap://ldap.example.net/? - - These three URLs point to the root DSE on the ldap.example.net - server. - - The final two examples show use of a hypothetical, experimental bind - name extension (the value associated with the extension is an LDAP - DN). - - ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com - ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com - - - - - - -Smith & Howes Standards Track [Page 7] - -RFC 4516 LDAP: Uniform Resource Locator June 2006 - - - The two URLs are the same, except that the second one marks the - e-bindname extension as critical. Notice the use of the percent- - encoding mechanism to encode the commas within the distinguished name - value in the e-bindname extension. - -5. Security Considerations - - The general URL security considerations discussed in [RFC3986] are - relevant for LDAP URLs. - - The use of security mechanisms when processing LDAP URLs requires - particular care, since clients may encounter many different servers - via URLs, and since URLs are likely to be processed automatically, - without user intervention. A client SHOULD have a user-configurable - policy that controls which servers the client will establish LDAP - sessions with and with which security mechanisms, and SHOULD NOT - establish LDAP sessions that are inconsistent with this policy. If a - client chooses to reuse an existing LDAP session when resolving one - or more LDAP URLs, it MUST ensure that the session is compatible with - the URL and that no security policies are violated. - - Sending authentication information, no matter the mechanism, may - violate a user's privacy requirements. In the absence of specific - policy permitting authentication information to be sent to a server, - a client should use an anonymous LDAP session. (Note that clients - conforming to previous LDAP URL specifications, where all LDAP - sessions are anonymous and unprotected, are consistent with this - specification; they simply have the default security policy.) Simply - opening a transport connection to another server may violate some - users' privacy requirements, so clients should provide the user with - a way to control URL processing. - - Some authentication methods, in particular, reusable passwords sent - to the server, may reveal easily-abused information to the remote - server or to eavesdroppers in transit and should not be used in URL - processing unless they are explicitly permitted by policy. - Confirmation by the human user of the use of authentication - information is appropriate in many circumstances. Use of strong - authentication methods that do not reveal sensitive information is - much preferred. If the URL represents a referral for an update - operation, strong authentication methods SHOULD be used. Please - refer to the Security Considerations section of [RFC4513] for more - information. - - The LDAP URL format allows the specification of an arbitrary LDAP - search operation to be performed when evaluating the LDAP URL. - Following an LDAP URL may cause unexpected results, for example, the - retrieval of large amounts of data or the initiation of a long-lived - - - -Smith & Howes Standards Track [Page 8] - -RFC 4516 LDAP: Uniform Resource Locator June 2006 - - - search. The security implications of resolving an LDAP URL are the - same as those of resolving an LDAP search query. - -6. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO - 10646", STD 63, RFC 3629, November 2003. - - [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform - Resource Identifier (URI): Generic Syntax", STD 66, RFC - 3986, January 2005. - - [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 4234, October 2005. - - [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol - (LDAP): Technical Specification Road Map", RFC 4510, June - 2006. - - [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access - Protocol (LDAP): The Protocol", RFC 4511, June 2006. - - [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP): Directory Information Models", RFC 4512, June - 2006. - - [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol - (LDAP): Authentication Methods and Security Mechanisms", - RFC 4513, June 2006. - - [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol - (LDAP): String Representation of Distinguished Names", RFC - 4514, June 2006. - - [RFC4515] Smith, M. Ed. and T. Howes, "Lightweight Directory Access - Protocol (LDAP): String Representation of Search Filters", - RFC 4515, June 2006. - - - - - - - - - - - -Smith & Howes Standards Track [Page 9] - -RFC 4516 LDAP: Uniform Resource Locator June 2006 - - -7. Informative References - - [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform - Resource Identifiers (URI): Generic Syntax", RFC 2396, - August 1998. - - [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) - Considerations for the Lightweight Directory Access - Protocol (LDAP)", BCP 64, RFC 4520, June 2006. - -8. Acknowledgements - - The LDAP URL format was originally defined at the University of - Michigan. This material is based upon work supported by the National - Science Foundation under Grant No. NCR-9416667. The support of both - the University of Michigan and the National Science Foundation is - gratefully acknowledged. - - This document obsoletes RFC 2255 by Tim Howes and Mark Smith. - Changes included in this revised specification are based upon - discussions among the authors, discussions within the LDAP (v3) - Revision Working Group (ldapbis), and discussions within other IETF - Working Groups. The contributions of individuals in these working - groups is gratefully acknowledged. Several people in particular have - made valuable comments on this document: RL "Bob" Morgan, Mark Wahl, - Kurt Zeilenga, Jim Sermersheim, and Hallvard Furuseth deserve special - thanks for their contributions. - - - - - - - - - - - - - - - - - - - - - - - - -Smith & Howes Standards Track [Page 10] - -RFC 4516 LDAP: Uniform Resource Locator June 2006 - - -Appendix A: Changes Since RFC 2255 - -A.1. Technical Changes - - The following technical changes were made to the contents of the "URL - Definition" section: - - Revised all of the ABNF to use common productions from [RFC4512]. - - Replaced references to [RFC2396] with a reference to [RFC3986] (this - allows literal IPv6 addresses to be used inside the <host> portion of - the URL, and a note was added to remind the reader of this - enhancement). Referencing [RFC3986] required changes to the ABNF and - text so that productions that are no longer defined by [RFC3986] are - not used. For example, <hostport> is not defined by [RFC3986] so it - has been replaced with host [COLON port]. Note that [RFC3986] - includes new definitions for the "Reserved" and "Unreserved" sets of - characters, and the net result is that the following two additional - characters should be percent-encoded when they appear anywhere in the - data used to construct an LDAP URL: "[" and "]" (these two characters - were first added to the Reserved set by RFC 2732). - - Changed the definition of <attrdesc> to refer to <attributeSelector> - from [RFC4511]. This allows the use of "*" in the <attrdesc> part of - the URL. It is believed that existing implementations of RFC 2255 - already support this. - - Avoided use of <prose-val> (bracketed-string) productions in the - <dn>, <host>, <attrdesc>, and <exvalue> rules. - - Changed the ABNF for <ldapurl> to group the <dn> component with the - preceding <SLASH>. - - Changed the <extype> rule to be an <oid> from [RFC4512]. - - Changed the text about extension types so it references [RFC4520]. - Reordered rules to more closely follow the order in which the - elements appear in the URL. - - "Bindname Extension": removed due to lack of known implementations. - -A.2. Editorial Changes - - Changed document title to include "LDAP:" prefix. - - IESG Note: removed note about lack of satisfactory mandatory - authentication mechanisms. - - - - -Smith & Howes Standards Track [Page 11] - -RFC 4516 LDAP: Uniform Resource Locator June 2006 - - - "Status of this Memo" section: updated boilerplate to match current - I-D guidelines. - - "Abstract" section: separated from introductory material. - - "Table of Contents" and "Intellectual Property" sections: added. - - "Introduction" section: new section; separated from the Abstract. - Changed the text indicate that RFC 2255 is replaced by this document - (instead of RFC 1959). Added text to indicate that LDAP URLs are - used for references and referrals. Fixed typo (replaced the nonsense - phrase "to perform to retrieve" with "used to retrieve"). Added a - note to let the reader know that not all of the parameters of the - LDAP search operation described in [RFC4511] can be expressed using - this format. - - "URL Definition" section: removed second copy of <ldapurl> grammar - and following two paragraphs (editorial error in RFC 2255). Fixed - line break within '!' sequence. Reformatted the ABNF to improve - readability by aligning comments and adding some blank lines. - Replaced "residing in the LDAP server" with "accessible from the LDAP - server" in the sentence immediately following the ABNF. Removed the - sentence "Individual attrdesc names are as defined for - AttributeDescription in [RFC4511]." because [RFC4511]'s - <attributeSelector> is now used directly in the ABNF. Reworded last - paragraph to clarify which characters must be percent-encoded. Added - text to indicate that LDAP URLs are used for references and - referrals. Added text that refers to the ABNF from RFC 4234. - Clarified and strengthened the requirements with respect to - processing of URLs that contain implemented and not implemented - extensions (the approach now closely matches that specified in - [RFC4511] for LDAP controls). - - "Defaults for Fields of the LDAP URL" section: added; formed by - moving text about defaults out of the "URL Definition" section. - Replaced direct reference to the attribute name "*" with a reference - to the special <alluserattrs> selector "*" defined in [RFC4511]. - - "URL Processing" section: removed. - - "Examples" section: Modified examples to use example.com and - example.net hostnames. Added missing '?' to the LDAP URL example - whose filter contains three null bytes. Removed space after one - comma within a DN. Revised the bindname example to use e-bindname. - Changed the name of an attribute used in one example from "int" to - "four-octet" to avoid potential confusion. Added an example that - demonstrates the interaction between DN escaping and URL percent- - encoding. Added some examples to show URL equivalence with respect - - - -Smith & Howes Standards Track [Page 12] - -RFC 4516 LDAP: Uniform Resource Locator June 2006 - - - to the <dn> portion of the URL. Used uppercase in some examples to - remind the reader that some tokens are case-insensitive. - - "Security Considerations" section: Added a note about connection - reuse. Added a note about using strong authentication methods for - updates. Added a reference to [RFC4513]. Added note that simply - opening a connection may violate some users' privacy requirements. - Adopted the working group's revised LDAP terminology specification by - replacing the word "connection" with "LDAP session" or "LDAP - connection" as appropriate. - - "Acknowledgements" section: added statement that this document - obsoletes RFC 2255. Added Kurt Zeilenga, Jim Sermersheim, and - Hallvard Furuseth. - - "Normative References" section: renamed from "References" per new RFC - guidelines. Changed from [1] style to [RFC4511] style throughout the - document. Added references to RFC 4234 and RFC 3629. Updated all - RFC 1738 references to point to the appropriate sections within - [RFC3986]. Updated the LDAP references to refer to LDAPBis WG - documents. Removed the reference to the LDAP Attribute Syntaxes - document and added references to the [RFC4513], [RFC4520], and - [RFC4510] documents. - - "Informative References" section: added. - - Header and "Authors' Addresses" sections: added "editor" next to Mark - Smith's name. Updated affiliation and contact information. - - Copyright: updated the year. - - Throughout the document: surrounded the names of all ABNF productions - with "<" and ">" where they are used in descriptive text. - - - - - - - - - - - - - - - - - - -Smith & Howes Standards Track [Page 13] - -RFC 4516 LDAP: Uniform Resource Locator June 2006 - - -Authors' Addresses - - Mark Smith, Editor - Pearl Crescent, LLC - 447 Marlpool Dr. - Saline, MI 48176 - USA - - Phone: +1 734 944-2856 - EMail: mcs@pearlcrescent.com - - - Tim Howes - Opsware, Inc. - 599 N. Mathilda Ave. - Sunnyvale, CA 94085 - USA - - Phone: +1 408 744-7509 - EMail: howes@opsware.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Smith & Howes Standards Track [Page 14] - -RFC 4516 LDAP: Uniform Resource Locator June 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Smith & Howes Standards Track [Page 15] - diff --git a/source4/ldap_server/devdocs/rfc4517.txt b/source4/ldap_server/devdocs/rfc4517.txt deleted file mode 100644 index 177e08b2ac..0000000000 --- a/source4/ldap_server/devdocs/rfc4517.txt +++ /dev/null @@ -1,2971 +0,0 @@ - - - - - - -Network Working Group S. Legg, Ed. -Request for Comments: 4517 eB2Bcom -Obsoletes: 2252, 2256 June 2006 -Updates: 3698 -Category: Standards Track - - - Lightweight Directory Access Protocol (LDAP): - Syntaxes and Matching Rules - - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - Each attribute stored in a Lightweight Directory Access Protocol - (LDAP) directory, whose values may be transferred in the LDAP - protocol, has a defined syntax that constrains the structure and - format of its values. The comparison semantics for values of a - syntax are not part of the syntax definition but are instead provided - through separately defined matching rules. Matching rules specify an - argument, an assertion value, which also has a defined syntax. This - document defines a base set of syntaxes and matching rules for use in - defining attributes for LDAP directories. - -Table of Contents - - 1. Introduction ....................................................3 - 2. Conventions .....................................................4 - 3. Syntaxes ........................................................4 - 3.1. General Considerations .....................................5 - 3.2. Common Definitions .........................................5 - 3.3. Syntax Definitions .........................................6 - 3.3.1. Attribute Type Description ..........................6 - 3.3.2. Bit String ..........................................6 - 3.3.3. Boolean .............................................7 - 3.3.4. Country String ......................................7 - 3.3.5. Delivery Method .....................................8 - - - -Legg Standards Track [Page 1] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - 3.3.6. Directory String ....................................8 - 3.3.7. DIT Content Rule Description ........................9 - 3.3.8. DIT Structure Rule Description .....................10 - 3.3.9. DN .................................................10 - 3.3.10. Enhanced Guide ....................................11 - 3.3.11. Facsimile Telephone Number ........................12 - 3.3.12. Fax ...............................................12 - 3.3.13. Generalized Time ..................................13 - 3.3.14. Guide .............................................14 - 3.3.15. IA5 String ........................................15 - 3.3.16. Integer ...........................................15 - 3.3.17. JPEG ..............................................15 - 3.3.18. LDAP Syntax Description ...........................16 - 3.3.19. Matching Rule Description .........................16 - 3.3.20. Matching Rule Use Description .....................17 - 3.3.21. Name and Optional UID .............................17 - 3.3.22. Name Form Description .............................18 - 3.3.23. Numeric String ....................................18 - 3.3.24. Object Class Description ..........................18 - 3.3.25. Octet String ......................................19 - 3.3.26. OID ...............................................19 - 3.3.27. Other Mailbox .....................................20 - 3.3.28. Postal Address ....................................20 - 3.3.29. Printable String ..................................21 - 3.3.30. Substring Assertion ...............................22 - 3.3.31. Telephone Number ..................................23 - 3.3.32. Teletex Terminal Identifier .......................23 - 3.3.33. Telex Number ......................................24 - 3.3.34. UTC Time ..........................................24 - 4. Matching Rules .................................................25 - 4.1. General Considerations ....................................25 - 4.2. Matching Rule Definitions .................................27 - 4.2.1. bitStringMatch .....................................27 - 4.2.2. booleanMatch .......................................28 - 4.2.3. caseExactIA5Match ..................................28 - 4.2.4. caseExactMatch .....................................29 - 4.2.5. caseExactOrderingMatch .............................29 - 4.2.6. caseExactSubstringsMatch ...........................30 - 4.2.7. caseIgnoreIA5Match .................................30 - 4.2.8. caseIgnoreIA5SubstringsMatch .......................31 - 4.2.9. caseIgnoreListMatch ................................31 - 4.2.10. caseIgnoreListSubstringsMatch .....................32 - 4.2.11. caseIgnoreMatch ...................................33 - 4.2.12. caseIgnoreOrderingMatch ...........................33 - 4.2.13. caseIgnoreSubstringsMatch .........................34 - 4.2.14. directoryStringFirstComponentMatch ................34 - 4.2.15. distinguishedNameMatch ............................35 - 4.2.16. generalizedTimeMatch ..............................36 - - - -Legg Standards Track [Page 2] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - 4.2.17. generalizedTimeOrderingMatch ......................36 - 4.2.18. integerFirstComponentMatch ........................36 - 4.2.19. integerMatch ......................................37 - 4.2.20. integerOrderingMatch ..............................37 - 4.2.21. keywordMatch ......................................38 - 4.2.22. numericStringMatch ................................38 - 4.2.23. numericStringOrderingMatch ........................39 - 4.2.24. numericStringSubstringsMatch ......................39 - 4.2.25. objectIdentifierFirstComponentMatch ...............40 - 4.2.26. objectIdentifierMatch .............................40 - 4.2.27. octetStringMatch ..................................41 - 4.2.28. octetStringOrderingMatch ..........................41 - 4.2.29. telephoneNumberMatch ..............................42 - 4.2.30. telephoneNumberSubstringsMatch ....................42 - 4.2.31. uniqueMemberMatch .................................43 - 4.2.32. wordMatch .........................................44 - 5. Security Considerations ........................................44 - 6. Acknowledgements ...............................................44 - 7. IANA Considerations ............................................45 - 8. References .....................................................46 - 8.1. Normative References ......................................46 - 8.2. Informative References ....................................48 - Appendix A. Summary of Syntax Object Identifiers ..................49 - Appendix B. Changes from RFC 2252 .................................49 - -1. Introduction - - Each attribute stored in a Lightweight Directory Access Protocol - (LDAP) directory [RFC4510], whose values may be transferred in the - LDAP protocol [RFC4511], has a defined syntax (i.e., data type) that - constrains the structure and format of its values. The comparison - semantics for values of a syntax are not part of the syntax - definition but are instead provided through separately defined - matching rules. Matching rules specify an argument, an assertion - value, which also has a defined syntax. This document defines a base - set of syntaxes and matching rules for use in defining attributes for - LDAP directories. - - Readers are advised to familiarize themselves with the Directory - Information Models [RFC4512] before reading the rest of this - document. Section 3 provides definitions for the base set of LDAP - syntaxes. Section 4 provides definitions for the base set of - matching rules for LDAP. - - This document is an integral part of the LDAP technical specification - [RFC4510], which obsoletes the previously defined LDAP technical - specification, RFC 3377, in its entirety. - - - - -Legg Standards Track [Page 3] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - Sections 4, 5, and 7 of RFC 2252 are obsoleted by [RFC4512]. The - remainder of RFC 2252 is obsoleted by this document. Sections 6 and - 8 of RFC 2256 are obsoleted by this document. The remainder of RFC - 2256 is obsoleted by [RFC4519] and [RFC4512]. All but Section 2.11 - of RFC 3698 is obsoleted by this document. - - A number of schema elements that were included in the previous - revision of the LDAP technical specification are not included in this - revision of LDAP. Public Key Infrastructure schema elements are now - specified in [RFC4523]. Unless reintroduced in future technical - specifications, the remainder are to be considered Historic. - - The changes with respect to RFC 2252 are described in Appendix B of - this document. - -2. Conventions - - In this document, the key words "MUST", "MUST NOT", "REQUIRED", - "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", - and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 - [RFC2119]. - - Syntax definitions are written according to the <SyntaxDescription> - ABNF [RFC4234] rule specified in [RFC4512], and matching rule - definitions are written according to the <MatchingRuleDescription> - ABNF rule specified in [RFC4512], except that the syntax and matching - rule definitions provided in this document are line-wrapped for - readability. When such definitions are transferred as attribute - values in the LDAP protocol (e.g., as values of the ldapSyntaxes and - matchingRules attributes [RFC4512], respectively), then those values - would not contain line breaks. - -3. Syntaxes - - Syntax definitions constrain the structure of attribute values stored - in an LDAP directory, and determine the representation of attribute - and assertion values transferred in the LDAP protocol. - - Syntaxes that are required for directory operation, or that are in - common use, are specified in this section. Servers SHOULD recognize - all the syntaxes listed in this document, but are not required to - otherwise support them, and MAY recognise or support other syntaxes. - However, the definition of additional arbitrary syntaxes is - discouraged since it will hinder interoperability. Client and server - implementations typically do not have the ability to dynamically - recognize new syntaxes. - - - - - -Legg Standards Track [Page 4] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - -3.1. General Considerations - - The description of each syntax specifies how attribute or assertion - values conforming to the syntax are to be represented when - transferred in the LDAP protocol [RFC4511]. This representation is - referred to as the LDAP-specific encoding to distinguish it from - other methods of encoding attribute values (e.g., the Basic Encoding - Rules (BER) encoding [BER] used by X.500 [X.500] directories). - - The LDAP-specific encoding of a given attribute syntax always - produces octet-aligned values. To the greatest extent possible, - encoding rules for LDAP syntaxes should produce character strings - that can be displayed with little or no translation by clients - implementing LDAP. However, clients MUST NOT assume that the LDAP- - specific encoding of a value of an unrecognized syntax is a human- - readable character string. There are a few cases (e.g., the JPEG - syntax) when it is not reasonable to produce a human-readable - representation. - - Each LDAP syntax is uniquely identified with an object identifier - [ASN.1] represented in the dotted-decimal format (short descriptive - names are not defined for syntaxes). These object identifiers are - not intended to be displayed to users. The object identifiers for - the syntaxes defined in this document are summarized in Appendix A. - - A suggested minimum upper bound on the number of characters in an - attribute value with a string-based syntax, or the number of octets - in a value for all other syntaxes, MAY be indicated by appending the - bound inside of curly braces following the syntax's OBJECT IDENTIFIER - in an attribute type definition (see the <noidlen> rule in - [RFC4512]). Such a bound is not considered part of the syntax - identifier. - - For example, "1.3.6.1.4.1.1466.115.121.1.15{64}" in an attribute - definition suggests that the directory server will allow a value of - the attribute to be up to 64 characters long, although it may allow - longer character strings. Note that a single character of the - Directory String syntax can be encoded in more than one octet, since - UTF-8 [RFC3629] is a variable-length encoding. Therefore, a 64- - character string may be more than 64 octets in length. - -3.2. Common Definitions - - The following ABNF rules are used in a number of the syntax - definitions in Section 3.3. - - PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN / - PLUS / COMMA / HYPHEN / DOT / EQUALS / - - - -Legg Standards Track [Page 5] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - SLASH / COLON / QUESTION / SPACE - PrintableString = 1*PrintableCharacter - IA5String = *(%x00-7F) - SLASH = %x2F ; forward slash ("/") - COLON = %x3A ; colon (":") - QUESTION = %x3F ; question mark ("?") - - The <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>, <COMMA>, - <HYPHEN>, <DOT>, <EQUALS>, and <SPACE> rules are defined in - [RFC4512]. - -3.3. Syntax Definitions - -3.3.1. Attribute Type Description - - A value of the Attribute Type Description syntax is the definition of - an attribute type. The LDAP-specific encoding of a value of this - syntax is defined by the <AttributeTypeDescription> rule in - [RFC4512]. - - For example, the following definition of the createTimestamp - attribute type from [RFC4512] is also a value of the Attribute - Type Description syntax. (Note: Line breaks have been added for - readability; they are not part of the value when transferred in - protocol.) - - ( 2.5.18.1 NAME 'createTimestamp' - EQUALITY generalizedTimeMatch - ORDERING generalizedTimeOrderingMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 - SINGLE-VALUE NO-USER-MODIFICATION - USAGE directoryOperation ) - - The LDAP definition for the Attribute Type Description syntax is: - - ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' ) - - This syntax corresponds to the AttributeTypeDescription ASN.1 type - from [X.501]. - -3.3.2. Bit String - - A value of the Bit String syntax is a sequence of binary digits. The - LDAP-specific encoding of a value of this syntax is defined by the - following ABNF: - - BitString = SQUOTE *binary-digit SQUOTE "B" - binary-digit = "0" / "1" - - - -Legg Standards Track [Page 6] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - The <SQUOTE> rule is defined in [RFC4512]. - - Example: - '0101111101'B - - The LDAP definition for the Bit String syntax is: - - ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' ) - - This syntax corresponds to the BIT STRING ASN.1 type from [ASN.1]. - -3.3.3. Boolean - - A value of the Boolean syntax is one of the Boolean values, true or - false. The LDAP-specific encoding of a value of this syntax is - defined by the following ABNF: - - Boolean = "TRUE" / "FALSE" - - The LDAP definition for the Boolean syntax is: - - ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' ) - - This syntax corresponds to the BOOLEAN ASN.1 type from [ASN.1]. - -3.3.4. Country String - - A value of the Country String syntax is one of the two-character - codes from ISO 3166 [ISO3166] for representing a country. The LDAP- - specific encoding of a value of this syntax is defined by the - following ABNF: - - CountryString = 2(PrintableCharacter) - - The <PrintableCharacter> rule is defined in Section 3.2. - - Examples: - - US - AU - - The LDAP definition for the Country String syntax is: - - ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' ) - - This syntax corresponds to the following ASN.1 type from [X.520]: - - PrintableString (SIZE (2)) -- ISO 3166 codes only - - - -Legg Standards Track [Page 7] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - -3.3.5. Delivery Method - - A value of the Delivery Method syntax is a sequence of items that - indicate, in preference order, the service(s) by which an entity is - willing and/or capable of receiving messages. The LDAP-specific - encoding of a value of this syntax is defined by the following ABNF: - - DeliveryMethod = pdm *( WSP DOLLAR WSP pdm ) - - pdm = "any" / "mhs" / "physical" / "telex" / "teletex" / - "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone" - - The <WSP> and <DOLLAR> rules are defined in [RFC4512]. - - Example: - telephone $ videotex - - The LDAP definition for the Delivery Method syntax is: - - ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' ) - - This syntax corresponds to the following ASN.1 type from [X.520]: - - SEQUENCE OF INTEGER { - any-delivery-method (0), - mhs-delivery (1), - physical-delivery (2), - telex-delivery (3), - teletex-delivery (4), - g3-facsimile-delivery (5), - g4-facsimile-delivery (6), - ia5-terminal-delivery (7), - videotex-delivery (8), - telephone-delivery (9) } - -3.3.6. Directory String - - A value of the Directory String syntax is a string of one or more - arbitrary characters from the Universal Character Set (UCS) [UCS]. A - zero-length character string is not permitted. The LDAP-specific - encoding of a value of this syntax is the UTF-8 encoding [RFC3629] of - the character string. Such encodings conform to the following ABNF: - - DirectoryString = 1*UTF8 - - The <UTF8> rule is defined in [RFC4512]. - - - - - -Legg Standards Track [Page 8] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - Example: - This is a value of Directory String containing #!%#@. - - Servers and clients MUST be prepared to receive arbitrary UCS code - points, including code points outside the range of printable ASCII - and code points not presently assigned to any character. - - Attribute type definitions using the Directory String syntax should - not restrict the format of Directory String values, e.g., by - requiring that the character string conforms to specific patterns - described by ABNF. A new syntax should be defined in such cases. - - The LDAP definition for the Directory String syntax is: - - ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' ) - - This syntax corresponds to the DirectoryString parameterized ASN.1 - type from [X.520]. - - The DirectoryString ASN.1 type allows a choice between the - TeletexString, PrintableString, or UniversalString ASN.1 types from - [ASN.1]. However, note that the chosen alternative is not indicated - in the LDAP-specific encoding of a Directory String value. - - Implementations that convert Directory String values from the LDAP- - specific encoding to the BER encoding used by X.500 must choose an - alternative that permits the particular characters in the string and - must convert the characters from the UTF-8 encoding into the - character encoding of the chosen alternative. When converting - Directory String values from the BER encoding to the LDAP-specific - encoding, the characters must be converted from the character - encoding of the chosen alternative into the UTF-8 encoding. These - conversions SHOULD be done in a manner consistent with the Transcode - step of the string preparation algorithms [RFC4518] for LDAP. - -3.3.7. DIT Content Rule Description - - A value of the DIT Content Rule Description syntax is the definition - of a DIT (Directory Information Tree) content rule. The LDAP- - specific encoding of a value of this syntax is defined by the - <DITContentRuleDescription> rule in [RFC4512]. - - Example: - ( 2.5.6.4 DESC 'content rule for organization' - NOT ( x121Address $ telexNumber ) ) - - Note: A line break has been added for readability; it is not part - of the value. - - - -Legg Standards Track [Page 9] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - The LDAP definition for the DIT Content Rule Description syntax is: - - ( 1.3.6.1.4.1.1466.115.121.1.16 - DESC 'DIT Content Rule Description' ) - - This syntax corresponds to the DITContentRuleDescription ASN.1 type - from [X.501]. - -3.3.8. DIT Structure Rule Description - - A value of the DIT Structure Rule Description syntax is the - definition of a DIT structure rule. The LDAP-specific encoding of a - value of this syntax is defined by the <DITStructureRuleDescription> - rule in [RFC4512]. - - Example: - ( 2 DESC 'organization structure rule' FORM 2.5.15.3 ) - - The LDAP definition for the DIT Structure Rule Description syntax is: - - ( 1.3.6.1.4.1.1466.115.121.1.17 - DESC 'DIT Structure Rule Description' ) - - This syntax corresponds to the DITStructureRuleDescription ASN.1 type - from [X.501]. - -3.3.9. DN - - A value of the DN syntax is the (purported) distinguished name (DN) - of an entry [RFC4512]. The LDAP-specific encoding of a value of this - syntax is defined by the <distinguishedName> rule from the string - representation of distinguished names [RFC4514]. - - Examples (from [RFC4514]): - UID=jsmith,DC=example,DC=net - OU=Sales+CN=J. Smith,DC=example,DC=net - CN=John Smith\, III,DC=example,DC=net - CN=Before\0dAfter,DC=example,DC=net - 1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com - CN=Lu\C4\8Di\C4\87 - - The LDAP definition for the DN syntax is: - - ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' ) - - The DN syntax corresponds to the DistinguishedName ASN.1 type from - [X.501]. Note that a BER encoded distinguished name (as used by - X.500) re-encoded into the LDAP-specific encoding is not necessarily - - - -Legg Standards Track [Page 10] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - reversible to the original BER encoding since the chosen string type - in any DirectoryString components of the distinguished name is not - indicated in the LDAP-specific encoding of the distinguished name - (see Section 3.3.6). - -3.3.10. Enhanced Guide - - A value of the Enhanced Guide syntax suggests criteria, which consist - of combinations of attribute types and filter operators, to be used - in constructing filters to search for entries of particular object - classes. The Enhanced Guide syntax improves upon the Guide syntax by - allowing the recommended depth of the search to be specified. - - The LDAP-specific encoding of a value of this syntax is defined by - the following ABNF: - - EnhancedGuide = object-class SHARP WSP criteria WSP - SHARP WSP subset - object-class = WSP oid WSP - subset = "baseobject" / "oneLevel" / "wholeSubtree" - - criteria = and-term *( BAR and-term ) - and-term = term *( AMPERSAND term ) - term = EXCLAIM term / - attributetype DOLLAR match-type / - LPAREN criteria RPAREN / - true / - false - match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX" - true = "?true" - false = "?false" - BAR = %x7C ; vertical bar ("|") - AMPERSAND = %x26 ; ampersand ("&") - EXCLAIM = %x21 ; exclamation mark ("!") - - The <SHARP>, <WSP>, <oid>, <LPAREN>, <RPAREN>, <attributetype>, and - <DOLLAR> rules are defined in [RFC4512]. - - The LDAP definition for the Enhanced Guide syntax is: - - ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' ) - - Example: - person#(sn$EQ)#oneLevel - - The Enhanced Guide syntax corresponds to the EnhancedGuide ASN.1 type - from [X.520]. The EnhancedGuide type references the Criteria ASN.1 - type, also from [X.520]. The <true> rule, above, represents an empty - - - -Legg Standards Track [Page 11] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - "and" expression in a value of the Criteria type. The <false> rule, - above, represents an empty "or" expression in a value of the Criteria - type. - -3.3.11. Facsimile Telephone Number - - A value of the Facsimile Telephone Number syntax is a subscriber - number of a facsimile device on the public switched telephone - network. The LDAP-specific encoding of a value of this syntax is - defined by the following ABNF: - - fax-number = telephone-number *( DOLLAR fax-parameter ) - telephone-number = PrintableString - fax-parameter = "twoDimensional" / - "fineResolution" / - "unlimitedLength" / - "b4Length" / - "a3Width" / - "b4Width" / - "uncompressed" - - The <telephone-number> is a string of printable characters that - complies with the internationally agreed format for representing - international telephone numbers [E.123]. The <PrintableString> rule - is defined in Section 3.2. The <DOLLAR> rule is defined in - [RFC4512]. - - The LDAP definition for the Facsimile Telephone Number syntax is: - - ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number') - - The Facsimile Telephone Number syntax corresponds to the - FacsimileTelephoneNumber ASN.1 type from [X.520]. - -3.3.12. Fax - - A value of the Fax syntax is an image that is produced using the - Group 3 facsimile process [FAX] to duplicate an object, such as a - memo. The LDAP-specific encoding of a value of this syntax is the - string of octets for a Group 3 Fax image as defined in [FAX]. - - The LDAP definition for the Fax syntax is: - - ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' ) - - The ASN.1 type corresponding to the Fax syntax is defined as follows, - assuming EXPLICIT TAGS: - - - - -Legg Standards Track [Page 12] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - Fax ::= CHOICE { - g3-facsimile [3] G3FacsimileBodyPart - } - - The G3FacsimileBodyPart ASN.1 type is defined in [X.420]. - -3.3.13. Generalized Time - - A value of the Generalized Time syntax is a character string - representing a date and time. The LDAP-specific encoding of a value - of this syntax is a restriction of the format defined in [ISO8601], - and is described by the following ABNF: - - GeneralizedTime = century year month day hour - [ minute [ second / leap-second ] ] - [ fraction ] - g-time-zone - - century = 2(%x30-39) ; "00" to "99" - year = 2(%x30-39) ; "00" to "99" - month = ( %x30 %x31-39 ) ; "01" (January) to "09" - / ( %x31 %x30-32 ) ; "10" to "12" - day = ( %x30 %x31-39 ) ; "01" to "09" - / ( %x31-32 %x30-39 ) ; "10" to "29" - / ( %x33 %x30-31 ) ; "30" to "31" - hour = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23" - minute = %x30-35 %x30-39 ; "00" to "59" - - second = ( %x30-35 %x30-39 ) ; "00" to "59" - leap-second = ( %x36 %x30 ) ; "60" - - fraction = ( DOT / COMMA ) 1*(%x30-39) - g-time-zone = %x5A ; "Z" - / g-differential - g-differential = ( MINUS / PLUS ) hour [ minute ] - MINUS = %x2D ; minus sign ("-") - - The <DOT>, <COMMA>, and <PLUS> rules are defined in [RFC4512]. - - The above ABNF allows character strings that do not represent valid - dates (in the Gregorian calendar) and/or valid times (e.g., February - 31, 1994). Such character strings SHOULD be considered invalid for - this syntax. - - The time value represents coordinated universal time (equivalent to - Greenwich Mean Time) if the "Z" form of <g-time-zone> is used; - otherwise, the value represents a local time in the time zone - indicated by <g-differential>. In the latter case, coordinated - - - -Legg Standards Track [Page 13] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - universal time can be calculated by subtracting the differential from - the local time. The "Z" form of <g-time-zone> SHOULD be used in - preference to <g-differential>. - - If <minute> is omitted, then <fraction> represents a fraction of an - hour; otherwise, if <second> and <leap-second> are omitted, then - <fraction> represents a fraction of a minute; otherwise, <fraction> - represents a fraction of a second. - - Examples: - 199412161032Z - 199412160532-0500 - - Both example values represent the same coordinated universal time: - 10:32 AM, December 16, 1994. - - The LDAP definition for the Generalized Time syntax is: - - ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' ) - - This syntax corresponds to the GeneralizedTime ASN.1 type from - [ASN.1], with the constraint that local time without a differential - SHALL NOT be used. - -3.3.14. Guide - - A value of the Guide syntax suggests criteria, which consist of - combinations of attribute types and filter operators, to be used in - constructing filters to search for entries of particular object - classes. The Guide syntax is obsolete and should not be used for - defining new attribute types. - - The LDAP-specific encoding of a value of this syntax is defined by - the following ABNF: - - Guide = [ object-class SHARP ] criteria - - The <object-class> and <criteria> rules are defined in Section - 3.3.10. The <SHARP> rule is defined in [RFC4512]. - - The LDAP definition for the Guide syntax is: - - ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' ) - - The Guide syntax corresponds to the Guide ASN.1 type from [X.520]. - - - - - - -Legg Standards Track [Page 14] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - -3.3.15. IA5 String - - A value of the IA5 String syntax is a string of zero, one, or more - characters from International Alphabet 5 (IA5) [T.50], the - international version of the ASCII character set. The LDAP-specific - encoding of a value of this syntax is the unconverted string of - characters, which conforms to the <IA5String> rule in Section 3.2. - - The LDAP definition for the IA5 String syntax is: - - ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' ) - - This syntax corresponds to the IA5String ASN.1 type from [ASN.1]. - -3.3.16. Integer - - A value of the Integer syntax is a whole number of unlimited - magnitude. The LDAP-specific encoding of a value of this syntax is - the optionally signed decimal digit character string representation - of the number (for example, the number 1321 is represented by the - character string "1321"). The encoding is defined by the following - ABNF: - - Integer = ( HYPHEN LDIGIT *DIGIT ) / number - - The <HYPHEN>, <LDIGIT>, <DIGIT>, and <number> rules are defined in - [RFC4512]. - - The LDAP definition for the Integer syntax is: - - ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' ) - - This syntax corresponds to the INTEGER ASN.1 type from [ASN.1]. - -3.3.17. JPEG - - A value of the JPEG syntax is an image in the JPEG File Interchange - Format (JFIF), as described in [JPEG]. The LDAP-specific encoding of - a value of this syntax is the sequence of octets of the JFIF encoding - of the image. - - The LDAP definition for the JPEG syntax is: - - ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' ) - - The JPEG syntax corresponds to the following ASN.1 type: - - - - - -Legg Standards Track [Page 15] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - JPEG ::= OCTET STRING (CONSTRAINED BY - { -- contents octets are an image in the -- - -- JPEG File Interchange Format -- }) - -3.3.18. LDAP Syntax Description - - A value of the LDAP Syntax Description syntax is the description of - an LDAP syntax. The LDAP-specific encoding of a value of this syntax - is defined by the <SyntaxDescription> rule in [RFC4512]. - - The LDAP definition for the LDAP Syntax Description syntax is: - - ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' ) - - The above LDAP definition for the LDAP Syntax Description syntax is - itself a legal value of the LDAP Syntax Description syntax. - - The ASN.1 type corresponding to the LDAP Syntax Description syntax is - defined as follows, assuming EXPLICIT TAGS: - - LDAPSyntaxDescription ::= SEQUENCE { - identifier OBJECT IDENTIFIER, - description DirectoryString { ub-schema } OPTIONAL } - - The DirectoryString parameterized ASN.1 type is defined in [X.520]. - - The value of ub-schema (an integer) is implementation defined. A - non-normative definition appears in [X.520]. - -3.3.19. Matching Rule Description - - A value of the Matching Rule Description syntax is the definition of - a matching rule. The LDAP-specific encoding of a value of this - syntax is defined by the <MatchingRuleDescription> rule in [RFC4512]. - - Example: - ( 2.5.13.2 NAME 'caseIgnoreMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) - - Note: A line break has been added for readability; it is not part of - the syntax. - - The LDAP definition for the Matching Rule Description syntax is: - - ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' ) - - This syntax corresponds to the MatchingRuleDescription ASN.1 type - from [X.501]. - - - -Legg Standards Track [Page 16] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - -3.3.20. Matching Rule Use Description - - A value of the Matching Rule Use Description syntax indicates the - attribute types to which a matching rule may be applied in an - extensibleMatch search filter [RFC4511]. The LDAP-specific encoding - of a value of this syntax is defined by the - <MatchingRuleUseDescription> rule in [RFC4512]. - - Example: - ( 2.5.13.16 APPLIES ( givenName $ surname ) ) - - The LDAP definition for the Matching Rule Use Description syntax is: - - ( 1.3.6.1.4.1.1466.115.121.1.31 - DESC 'Matching Rule Use Description' ) - - This syntax corresponds to the MatchingRuleUseDescription ASN.1 type - from [X.501]. - -3.3.21. Name and Optional UID - - A value of the Name and Optional UID syntax is the distinguished name - [RFC4512] of an entity optionally accompanied by a unique identifier - that serves to differentiate the entity from others with an identical - distinguished name. - - The LDAP-specific encoding of a value of this syntax is defined by - the following ABNF: - - NameAndOptionalUID = distinguishedName [ SHARP BitString ] - - The <BitString> rule is defined in Section 3.3.2. The - <distinguishedName> rule is defined in [RFC4514]. The <SHARP> rule - is defined in [RFC4512]. - - Note that although the '#' character may occur in the string - representation of a distinguished name, no additional escaping of - this character is performed when a <distinguishedName> is encoded in - a <NameAndOptionalUID>. - - Example: - 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B - - The LDAP definition for the Name and Optional UID syntax is: - - ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' ) - - - - - -Legg Standards Track [Page 17] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - This syntax corresponds to the NameAndOptionalUID ASN.1 type from - [X.520]. - -3.3.22. Name Form Description - - A value of the Name Form Description syntax is the definition of a - name form, which regulates how entries may be named. The LDAP- - specific encoding of a value of this syntax is defined by the - <NameFormDescription> rule in [RFC4512]. - - Example: - ( 2.5.15.3 NAME 'orgNameForm' OC organization MUST o ) - - The LDAP definition for the Name Form Description syntax is: - - ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' ) - - This syntax corresponds to the NameFormDescription ASN.1 type from - [X.501]. - -3.3.23. Numeric String - - A value of the Numeric String syntax is a sequence of one or more - numerals and spaces. The LDAP-specific encoding of a value of this - syntax is the unconverted string of characters, which conforms to the - following ABNF: - - NumericString = 1*(DIGIT / SPACE) - - The <DIGIT> and <SPACE> rules are defined in [RFC4512]. - - Example: - 15 079 672 281 - - The LDAP definition for the Numeric String syntax is: - - ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' ) - - This syntax corresponds to the NumericString ASN.1 type from [ASN.1]. - -3.3.24. Object Class Description - - A value of the Object Class Description syntax is the definition of - an object class. The LDAP-specific encoding of a value of this - syntax is defined by the <ObjectClassDescription> rule in [RFC4512]. - - - - - - -Legg Standards Track [Page 18] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - Example: - ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c - MAY ( searchGuide $ description ) ) - - Note: A line break has been added for readability; it is not part of - the syntax. - - The LDAP definition for the Object Class Description syntax is: - - ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' ) - - This syntax corresponds to the ObjectClassDescription ASN.1 type from - [X.501]. - -3.3.25. Octet String - - A value of the Octet String syntax is a sequence of zero, one, or - more arbitrary octets. The LDAP-specific encoding of a value of this - syntax is the unconverted sequence of octets, which conforms to the - following ABNF: - - OctetString = *OCTET - - The <OCTET> rule is defined in [RFC4512]. Values of this syntax are - not generally human-readable. - - The LDAP definition for the Octet String syntax is: - - ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' ) - - This syntax corresponds to the OCTET STRING ASN.1 type from [ASN.1]. - -3.3.26. OID - - A value of the OID syntax is an object identifier: a sequence of two - or more non-negative integers that uniquely identify some object or - item of specification. Many of the object identifiers used in LDAP - also have IANA registered names [RFC4520]. - - The LDAP-specific encoding of a value of this syntax is defined by - the <oid> rule in [RFC4512]. - - Examples: - 1.2.3.4 - cn - - The LDAP definition for the OID syntax is: - - - - -Legg Standards Track [Page 19] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' ) - - This syntax corresponds to the OBJECT IDENTIFIER ASN.1 type from - [ASN.1]. - -3.3.27. Other Mailbox - - A value of the Other Mailbox syntax identifies an electronic mailbox, - in a particular named mail system. The LDAP-specific encoding of a - value of this syntax is defined by the following ABNF: - - OtherMailbox = mailbox-type DOLLAR mailbox - mailbox-type = PrintableString - mailbox = IA5String - - The <mailbox-type> rule represents the type of mail system in which - the mailbox resides (for example, "MCIMail"), and <mailbox> is the - actual mailbox in the mail system described by <mailbox-type>. The - <PrintableString> and <IA5String> rules are defined in Section 3.2. - The <DOLLAR> rule is defined in [RFC4512]. - - The LDAP definition for the Other Mailbox syntax is: - - ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' ) - - The ASN.1 type corresponding to the Other Mailbox syntax is defined - as follows, assuming EXPLICIT TAGS: - - OtherMailbox ::= SEQUENCE { - mailboxType PrintableString, - mailbox IA5String - } - -3.3.28. Postal Address - - A value of the Postal Address syntax is a sequence of strings of one - or more arbitrary UCS characters, which form an address in a physical - mail system. - - The LDAP-specific encoding of a value of this syntax is defined by - the following ABNF: - - - - - - - - - - -Legg Standards Track [Page 20] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - PostalAddress = line *( DOLLAR line ) - line = 1*line-char - line-char = %x00-23 - / (%x5C "24") ; escaped "$" - / %x25-5B - / (%x5C "5C") ; escaped "\" - / %x5D-7F - / UTFMB - - Each character string (i.e., <line>) of a postal address value is - encoded as a UTF-8 [RFC3629] string, except that "\" and "$" - characters, if they occur in the string, are escaped by a "\" - character followed by the two hexadecimal digit code for the - character. The <DOLLAR> and <UTFMB> rules are defined in [RFC4512]. - - Many servers limit the postal address to no more than six lines of no - more than thirty characters each. - - Example: - 1234 Main St.$Anytown, CA 12345$USA - \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA - - The LDAP definition for the Postal Address syntax is: - - ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' ) - - This syntax corresponds to the PostalAddress ASN.1 type from [X.520]; - that is - - PostalAddress ::= SEQUENCE SIZE(1..ub-postal-line) OF - DirectoryString { ub-postal-string } - - The values of ub-postal-line and ub-postal-string (both integers) are - implementation defined. Non-normative definitions appear in [X.520]. - -3.3.29. Printable String - - A value of the Printable String syntax is a string of one or more - latin alphabetic, numeric, and selected punctuation characters as - specified by the <PrintableCharacter> rule in Section 3.2. - - The LDAP-specific encoding of a value of this syntax is the - unconverted string of characters, which conforms to the - <PrintableString> rule in Section 3.2. - - Example: - This is a PrintableString. - - - - -Legg Standards Track [Page 21] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - The LDAP definition for the PrintableString syntax is: - - ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' ) - - This syntax corresponds to the PrintableString ASN.1 type from - [ASN.1]. - -3.3.30. Substring Assertion - - A value of the Substring Assertion syntax is a sequence of zero, one, - or more character substrings used as an argument for substring - extensible matching of character string attribute values; i.e., as - the matchValue of a MatchingRuleAssertion [RFC4511]. Each substring - is a string of one or more arbitrary characters from the Universal - Character Set (UCS) [UCS]. A zero-length substring is not permitted. - - The LDAP-specific encoding of a value of this syntax is defined by - the following ABNF: - - SubstringAssertion = [ initial ] any [ final ] - - initial = substring - any = ASTERISK *(substring ASTERISK) - final = substring - ASTERISK = %x2A ; asterisk ("*") - - substring = 1*substring-character - substring-character = %x00-29 - / (%x5C "2A") ; escaped "*" - / %x2B-5B - / (%x5C "5C") ; escaped "\" - / %x5D-7F - / UTFMB - - Each <substring> of a Substring Assertion value is encoded as a UTF-8 - [RFC3629] string, except that "\" and "*" characters, if they occur - in the substring, are escaped by a "\" character followed by the two - hexadecimal digit code for the character. - - The Substring Assertion syntax is used only as the syntax of - assertion values in the extensible match. It is not used as an - attribute syntax, or in the SubstringFilter [RFC4511]. - - The LDAP definition for the Substring Assertion syntax is: - - ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' ) - - - - - -Legg Standards Track [Page 22] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - This syntax corresponds to the SubstringAssertion ASN.1 type from - [X.520]. - -3.3.31. Telephone Number - - A value of the Telephone Number syntax is a string of printable - characters that complies with the internationally agreed format for - representing international telephone numbers [E.123]. - - The LDAP-specific encoding of a value of this syntax is the - unconverted string of characters, which conforms to the - <PrintableString> rule in Section 3.2. - - Examples: - +1 512 315 0280 - +1-512-315-0280 - +61 3 9896 7830 - - The LDAP definition for the Telephone Number syntax is: - - ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' ) - - The Telephone Number syntax corresponds to the following ASN.1 type - from [X.520]: - - PrintableString (SIZE(1..ub-telephone-number)) - - The value of ub-telephone-number (an integer) is implementation - defined. A non-normative definition appears in [X.520]. - -3.3.32. Teletex Terminal Identifier - - A value of this syntax specifies the identifier and (optionally) - parameters of a teletex terminal. - - The LDAP-specific encoding of a value of this syntax is defined by - the following ABNF: - - teletex-id = ttx-term *(DOLLAR ttx-param) - ttx-term = PrintableString ; terminal identifier - ttx-param = ttx-key COLON ttx-value ; parameter - ttx-key = "graphic" / "control" / "misc" / "page" / "private" - ttx-value = *ttx-value-octet - - ttx-value-octet = %x00-23 - / (%x5C "24") ; escaped "$" - / %x25-5B - / (%x5C "5C") ; escaped "\" - - - -Legg Standards Track [Page 23] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - / %x5D-FF - - The <PrintableString> and <COLON> rules are defined in Section 3.2. - The <DOLLAR> rule is defined in [RFC4512]. - - The LDAP definition for the Teletex Terminal Identifier syntax is: - - ( 1.3.6.1.4.1.1466.115.121.1.51 - DESC 'Teletex Terminal Identifier' ) - - This syntax corresponds to the TeletexTerminalIdentifier ASN.1 type - from [X.520]. - -3.3.33. Telex Number - - A value of the Telex Number syntax specifies the telex number, - country code, and answerback code of a telex terminal. - - The LDAP-specific encoding of a value of this syntax is defined by - the following ABNF: - - telex-number = actual-number DOLLAR country-code - DOLLAR answerback - actual-number = PrintableString - country-code = PrintableString - answerback = PrintableString - - The <PrintableString> rule is defined in Section 3.2. The <DOLLAR> - rule is defined in [RFC4512]. - - The LDAP definition for the Telex Number syntax is: - - ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' ) - - This syntax corresponds to the TelexNumber ASN.1 type from [X.520]. - -3.3.34. UTC Time - - A value of the UTC Time syntax is a character string representing a - date and time to a precision of one minute or one second. The year - is given as a two-digit number. The LDAP-specific encoding of a - value of this syntax follows the format defined in [ASN.1] for the - UTCTime type and is described by the following ABNF: - - UTCTime = year month day hour minute [ second ] - [ u-time-zone ] - u-time-zone = %x5A ; "Z" - / u-differential - - - -Legg Standards Track [Page 24] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - u-differential = ( MINUS / PLUS ) hour minute - - The <year>, <month>, <day>, <hour>, <minute>, <second>, and <MINUS> - rules are defined in Section 3.3.13. The <PLUS> rule is defined in - [RFC4512]. - - The above ABNF allows character strings that do not represent valid - dates (in the Gregorian calendar) and/or valid times. Such character - strings SHOULD be considered invalid for this syntax. - - The time value represents coordinated universal time if the "Z" form - of <u-time-zone> is used; otherwise, the value represents a local - time. In the latter case, if <u-differential> is provided, then - coordinated universal time can be calculated by subtracting the - differential from the local time. The <u-time-zone> SHOULD be - present in time values, and the "Z" form of <u-time-zone> SHOULD be - used in preference to <u-differential>. - - The LDAP definition for the UTC Time syntax is: - - ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' ) - - Note: This syntax is deprecated in favor of the Generalized Time - syntax. - - The UTC Time syntax corresponds to the UTCTime ASN.1 type from - [ASN.1]. - -4. Matching Rules - - Matching rules are used by directory implementations to compare - attribute values against assertion values when performing Search and - Compare operations [RFC4511]. They are also used when comparing a - purported distinguished name [RFC4512] with the name of an entry. - When modifying entries, matching rules are used to identify values to - be deleted and to prevent an attribute from containing two equal - values. - - Matching rules that are required for directory operation, or that are - in common use, are specified in this section. - -4.1. General Considerations - - A matching rule is applied to attribute values through an - AttributeValueAssertion or MatchingRuleAssertion [RFC4511]. The - conditions under which an AttributeValueAssertion or - MatchingRuleAssertion evaluates to Undefined are specified elsewhere - [RFC4511]. If an assertion is not Undefined, then the result of the - - - -Legg Standards Track [Page 25] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - assertion is the result of applying the selected matching rule. A - matching rule evaluates to TRUE, and in some cases Undefined, as - specified in the description of the matching rule; otherwise, it - evaluates to FALSE. - - Each assertion contains an assertion value. The definition of each - matching rule specifies the syntax for the assertion value. The - syntax of the assertion value is typically, but not necessarily, the - same as the syntax of the attribute values to which the matching rule - may be applied. Note that an AssertionValue in a SubstringFilter - [RFC4511] conforms to the assertion syntax of the equality matching - rule for the attribute type rather than to the assertion syntax of - the substrings matching rule for the attribute type. Conceptually, - the entire SubstringFilter is converted into an assertion value of - the substrings matching rule prior to applying the rule. - - The definition of each matching rule indicates the attribute syntaxes - to which the rule may be applied, by specifying conditions the - corresponding ASN.1 type of a candidate attribute syntax must - satisfy. These conditions are also satisfied if the corresponding - ASN.1 type is a tagged or constrained derivative of the ASN.1 type - explicitly mentioned in the rule description (i.e., ASN.1 tags and - constraints are ignored in checking applicability), or is an - alternative reference notation for the explicitly mentioned type. - Each rule description lists, as examples of applicable attribute - syntaxes, the complete list of the syntaxes defined in this document - to which the matching rule applies. A matching rule may be - applicable to additional syntaxes defined in other documents if those - syntaxes satisfy the conditions on the corresponding ASN.1 type. - - The description of each matching rule indicates whether the rule is - suitable for use as the equality matching rule (EQUALITY), ordering - matching rule (ORDERING), or substrings matching rule (SUBSTR) in an - attribute type definition [RFC4512]. - - Each matching rule is uniquely identified with an object identifier. - The definition of a matching rule should not subsequently be changed. - If a change is desirable, then a new matching rule with a different - object identifier should be defined instead. - - Servers MAY implement the wordMatch and keywordMatch matching rules, - but they SHOULD implement the other matching rules in Section 4.2. - Servers MAY implement additional matching rules. - - Servers that implement the extensibleMatch filter SHOULD allow the - matching rules listed in Section 4.2 to be used in the - extensibleMatch filter and SHOULD allow matching rules to be used - with all attribute types known to the server, where the assertion - - - -Legg Standards Track [Page 26] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - syntax of the matching rule is the same as the value syntax of the - attribute. - - Servers MUST publish, in the matchingRules attribute, the definitions - of matching rules referenced by values of the attributeTypes and - matchingRuleUse attributes in the same subschema entry. Other - unreferenced matching rules MAY be published in the matchingRules - attribute. - - If the server supports the extensibleMatch filter, then the server - MAY use the matchingRuleUse attribute to indicate the applicability - (in an extensibleMatch filter) of selected matching rules to - nominated attribute types. - -4.2. Matching Rule Definitions - - Nominated character strings in assertion and attribute values are - prepared according to the string preparation algorithms [RFC4518] for - LDAP when evaluating the following matching rules: - - numericStringMatch, - numericStringSubstringsMatch, - caseExactMatch, - caseExactOrderingMatch, - caseExactSubstringsMatch, - caseExactIA5Match, - caseIgnoreIA5Match, - caseIgnoreIA5SubstringsMatch, - caseIgnoreListMatch, - caseIgnoreListSubstringsMatch, - caseIgnoreMatch, - caseIgnoreOrderingMatch, - caseIgnoreSubstringsMatch, - directoryStringFirstComponentMatch, - telephoneNumberMatch, - telephoneNumberSubstringsMatch and - wordMatch. - - The Transcode, Normalize, Prohibit, and Check bidi steps are the same - for each of the matching rules. However, the Map and Insignificant - Character Handling steps depend on the specific rule, as detailed in - the description of these matching rules in the sections that follow. - -4.2.1. bitStringMatch - - The bitStringMatch rule compares an assertion value of the Bit String - syntax to an attribute value of a syntax (e.g., the Bit String - syntax) whose corresponding ASN.1 type is BIT STRING. - - - -Legg Standards Track [Page 27] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - If the corresponding ASN.1 type of the attribute syntax does not have - a named bit list [ASN.1] (which is the case for the Bit String - syntax), then the rule evaluates to TRUE if and only if the attribute - value has the same number of bits as the assertion value and the bits - match on a bitwise basis. - - If the corresponding ASN.1 type does have a named bit list, then - bitStringMatch operates as above, except that trailing zero bits in - the attribute and assertion values are treated as absent. - - The LDAP definition for the bitStringMatch rule is: - - ( 2.5.13.16 NAME 'bitStringMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) - - The bitStringMatch rule is an equality matching rule. - -4.2.2. booleanMatch - - The booleanMatch rule compares an assertion value of the Boolean - syntax to an attribute value of a syntax (e.g., the Boolean syntax) - whose corresponding ASN.1 type is BOOLEAN. - - The rule evaluates to TRUE if and only if the attribute value and the - assertion value are both TRUE or both FALSE. - - The LDAP definition for the booleanMatch rule is: - - ( 2.5.13.13 NAME 'booleanMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ) - - The booleanMatch rule is an equality matching rule. - -4.2.3. caseExactIA5Match - - The caseExactIA5Match rule compares an assertion value of the IA5 - String syntax to an attribute value of a syntax (e.g., the IA5 String - syntax) whose corresponding ASN.1 type is IA5String. - - The rule evaluates to TRUE if and only if the prepared attribute - value character string and the prepared assertion value character - string have the same number of characters and corresponding - characters have the same code point. - - In preparing the attribute value and assertion value for comparison, - characters are not case folded in the Map preparation step, and only - Insignificant Space Handling is applied in the Insignificant - Character Handling step. - - - -Legg Standards Track [Page 28] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - The LDAP definition for the caseExactIA5Match rule is: - - ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) - - The caseExactIA5Match rule is an equality matching rule. - -4.2.4. caseExactMatch - - The caseExactMatch rule compares an assertion value of the Directory - String syntax to an attribute value of a syntax (e.g., the Directory - String, Printable String, Country String, or Telephone Number syntax) - whose corresponding ASN.1 type is DirectoryString or one of the - alternative string types of DirectoryString, such as PrintableString - (the other alternatives do not correspond to any syntax defined in - this document). - - The rule evaluates to TRUE if and only if the prepared attribute - value character string and the prepared assertion value character - string have the same number of characters and corresponding - characters have the same code point. - - In preparing the attribute value and assertion value for comparison, - characters are not case folded in the Map preparation step, and only - Insignificant Space Handling is applied in the Insignificant - Character Handling step. - - The LDAP definition for the caseExactMatch rule is: - - ( 2.5.13.5 NAME 'caseExactMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) - - The caseExactMatch rule is an equality matching rule. - -4.2.5. caseExactOrderingMatch - - The caseExactOrderingMatch rule compares an assertion value of the - Directory String syntax to an attribute value of a syntax (e.g., the - Directory String, Printable String, Country String, or Telephone - Number syntax) whose corresponding ASN.1 type is DirectoryString or - one of its alternative string types. - - The rule evaluates to TRUE if and only if, in the code point - collation order, the prepared attribute value character string - appears earlier than the prepared assertion value character string; - i.e., the attribute value is "less than" the assertion value. - - - - - -Legg Standards Track [Page 29] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - In preparing the attribute value and assertion value for comparison, - characters are not case folded in the Map preparation step, and only - Insignificant Space Handling is applied in the Insignificant - Character Handling step. - - The LDAP definition for the caseExactOrderingMatch rule is: - - ( 2.5.13.6 NAME 'caseExactOrderingMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) - - The caseExactOrderingMatch rule is an ordering matching rule. - -4.2.6. caseExactSubstringsMatch - - The caseExactSubstringsMatch rule compares an assertion value of the - Substring Assertion syntax to an attribute value of a syntax (e.g., - the Directory String, Printable String, Country String, or Telephone - Number syntax) whose corresponding ASN.1 type is DirectoryString or - one of its alternative string types. - - The rule evaluates to TRUE if and only if (1) the prepared substrings - of the assertion value match disjoint portions of the prepared - attribute value character string in the order of the substrings in - the assertion value, (2) an <initial> substring, if present, matches - the beginning of the prepared attribute value character string, and - (3) a <final> substring, if present, matches the end of the prepared - attribute value character string. A prepared substring matches a - portion of the prepared attribute value character string if - corresponding characters have the same code point. - - In preparing the attribute value and assertion value substrings for - comparison, characters are not case folded in the Map preparation - step, and only Insignificant Space Handling is applied in the - Insignificant Character Handling step. - - The LDAP definition for the caseExactSubstringsMatch rule is: - - ( 2.5.13.7 NAME 'caseExactSubstringsMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) - - The caseExactSubstringsMatch rule is a substrings matching rule. - -4.2.7. caseIgnoreIA5Match - - The caseIgnoreIA5Match rule compares an assertion value of the IA5 - String syntax to an attribute value of a syntax (e.g., the IA5 String - syntax) whose corresponding ASN.1 type is IA5String. - - - - -Legg Standards Track [Page 30] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - The rule evaluates to TRUE if and only if the prepared attribute - value character string and the prepared assertion value character - string have the same number of characters and corresponding - characters have the same code point. - - In preparing the attribute value and assertion value for comparison, - characters are case folded in the Map preparation step, and only - Insignificant Space Handling is applied in the Insignificant - Character Handling step. - - The LDAP definition for the caseIgnoreIA5Match rule is: - - ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) - - The caseIgnoreIA5Match rule is an equality matching rule. - -4.2.8. caseIgnoreIA5SubstringsMatch - - The caseIgnoreIA5SubstringsMatch rule compares an assertion value of - the Substring Assertion syntax to an attribute value of a syntax - (e.g., the IA5 String syntax) whose corresponding ASN.1 type is - IA5String. - - The rule evaluates to TRUE if and only if (1) the prepared substrings - of the assertion value match disjoint portions of the prepared - attribute value character string in the order of the substrings in - the assertion value, (2) an <initial> substring, if present, matches - the beginning of the prepared attribute value character string, and - (3) a <final> substring, if present, matches the end of the prepared - attribute value character string. A prepared substring matches a - portion of the prepared attribute value character string if - corresponding characters have the same code point. - - In preparing the attribute value and assertion value substrings for - comparison, characters are case folded in the Map preparation step, - and only Insignificant Space Handling is applied in the Insignificant - Character Handling step. - - ( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) - - The caseIgnoreIA5SubstringsMatch rule is a substrings matching rule. - -4.2.9. caseIgnoreListMatch - - The caseIgnoreListMatch rule compares an assertion value that is a - sequence of strings to an attribute value of a syntax (e.g., the - - - -Legg Standards Track [Page 31] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - Postal Address syntax) whose corresponding ASN.1 type is a SEQUENCE - OF the DirectoryString ASN.1 type. - - The rule evaluates to TRUE if and only if the attribute value and the - assertion value have the same number of strings and corresponding - strings (by position) match according to the caseIgnoreMatch matching - rule. - - In [X.520], the assertion syntax for this matching rule is defined to - be: - - SEQUENCE OF DirectoryString {ub-match} - - That is, it is different from the corresponding type for the Postal - Address syntax. The choice of the Postal Address syntax for the - assertion syntax of the caseIgnoreListMatch in LDAP should not be - seen as limiting the matching rule to apply only to attributes with - the Postal Address syntax. - - The LDAP definition for the caseIgnoreListMatch rule is: - - ( 2.5.13.11 NAME 'caseIgnoreListMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) - - The caseIgnoreListMatch rule is an equality matching rule. - -4.2.10. caseIgnoreListSubstringsMatch - - The caseIgnoreListSubstringsMatch rule compares an assertion value of - the Substring Assertion syntax to an attribute value of a syntax - (e.g., the Postal Address syntax) whose corresponding ASN.1 type is a - SEQUENCE OF the DirectoryString ASN.1 type. - - The rule evaluates to TRUE if and only if the assertion value - matches, per the caseIgnoreSubstringsMatch rule, the character string - formed by concatenating the strings of the attribute value, except - that none of the <initial>, <any>, or <final> substrings of the - assertion value are considered to match a substring of the - concatenated string which spans more than one of the original strings - of the attribute value. - - Note that, in terms of the LDAP-specific encoding of the Postal - Address syntax, the concatenated string omits the <DOLLAR> line - separator and the escaping of "\" and "$" characters. - - The LDAP definition for the caseIgnoreListSubstringsMatch rule is: - - ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch' - - - -Legg Standards Track [Page 32] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) - - The caseIgnoreListSubstringsMatch rule is a substrings matching rule. - -4.2.11. caseIgnoreMatch - - The caseIgnoreMatch rule compares an assertion value of the Directory - String syntax to an attribute value of a syntax (e.g., the Directory - String, Printable String, Country String, or Telephone Number syntax) - whose corresponding ASN.1 type is DirectoryString or one of its - alternative string types. - - The rule evaluates to TRUE if and only if the prepared attribute - value character string and the prepared assertion value character - string have the same number of characters and corresponding - characters have the same code point. - - In preparing the attribute value and assertion value for comparison, - characters are case folded in the Map preparation step, and only - Insignificant Space Handling is applied in the Insignificant - Character Handling step. - - The LDAP definition for the caseIgnoreMatch rule is: - - ( 2.5.13.2 NAME 'caseIgnoreMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) - - The caseIgnoreMatch rule is an equality matching rule. - -4.2.12. caseIgnoreOrderingMatch - - The caseIgnoreOrderingMatch rule compares an assertion value of the - Directory String syntax to an attribute value of a syntax (e.g., the - Directory String, Printable String, Country String, or Telephone - Number syntax) whose corresponding ASN.1 type is DirectoryString or - one of its alternative string types. - - The rule evaluates to TRUE if and only if, in the code point - collation order, the prepared attribute value character string - appears earlier than the prepared assertion value character string; - i.e., the attribute value is "less than" the assertion value. - - In preparing the attribute value and assertion value for comparison, - characters are case folded in the Map preparation step, and only - Insignificant Space Handling is applied in the Insignificant - Character Handling step. - - The LDAP definition for the caseIgnoreOrderingMatch rule is: - - - -Legg Standards Track [Page 33] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) - - The caseIgnoreOrderingMatch rule is an ordering matching rule. - -4.2.13. caseIgnoreSubstringsMatch - - The caseIgnoreSubstringsMatch rule compares an assertion value of the - Substring Assertion syntax to an attribute value of a syntax (e.g., - the Directory String, Printable String, Country String, or Telephone - Number syntax) whose corresponding ASN.1 type is DirectoryString or - one of its alternative string types. - - The rule evaluates to TRUE if and only if (1) the prepared substrings - of the assertion value match disjoint portions of the prepared - attribute value character string in the order of the substrings in - the assertion value, (2) an <initial> substring, if present, matches - the beginning of the prepared attribute value character string, and - (3) a <final> substring, if present, matches the end of the prepared - attribute value character string. A prepared substring matches a - portion of the prepared attribute value character string if - corresponding characters have the same code point. - - In preparing the attribute value and assertion value substrings for - comparison, characters are case folded in the Map preparation step, - and only Insignificant Space Handling is applied in the Insignificant - Character Handling step. - - The LDAP definition for the caseIgnoreSubstringsMatch rule is: - - ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) - - The caseIgnoreSubstringsMatch rule is a substrings matching rule. - -4.2.14. directoryStringFirstComponentMatch - - The directoryStringFirstComponentMatch rule compares an assertion - value of the Directory String syntax to an attribute value of a - syntax whose corresponding ASN.1 type is a SEQUENCE with a mandatory - first component of the DirectoryString ASN.1 type. - - Note that the assertion syntax of this matching rule differs from the - attribute syntax of attributes for which this is the equality - matching rule. - - - - - - -Legg Standards Track [Page 34] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - The rule evaluates to TRUE if and only if the assertion value matches - the first component of the attribute value using the rules of - caseIgnoreMatch. - - The LDAP definition for the directoryStringFirstComponentMatch - matching rule is: - - ( 2.5.13.31 NAME 'directoryStringFirstComponentMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) - - The directoryStringFirstComponentMatch rule is an equality matching - rule. When using directoryStringFirstComponentMatch to compare two - attribute values (of an applicable syntax), an assertion value must - first be derived from one of the attribute values. An assertion - value can be derived from an attribute value by taking the first - component of that attribute value. - -4.2.15. distinguishedNameMatch - - The distinguishedNameMatch rule compares an assertion value of the DN - syntax to an attribute value of a syntax (e.g., the DN syntax) whose - corresponding ASN.1 type is DistinguishedName. - - The rule evaluates to TRUE if and only if the attribute value and the - assertion value have the same number of relative distinguished names - and corresponding relative distinguished names (by position) are the - same. A relative distinguished name (RDN) of the assertion value is - the same as an RDN of the attribute value if and only if they have - the same number of attribute value assertions and each attribute - value assertion (AVA) of the first RDN is the same as the AVA of the - second RDN with the same attribute type. The order of the AVAs is - not significant. Also note that a particular attribute type may - appear in at most one AVA in an RDN. Two AVAs with the same - attribute type are the same if their values are equal according to - the equality matching rule of the attribute type. If one or more of - the AVA comparisons evaluate to Undefined and the remaining AVA - comparisons return TRUE then the distinguishedNameMatch rule - evaluates to Undefined. - - The LDAP definition for the distinguishedNameMatch rule is: - - ( 2.5.13.1 NAME 'distinguishedNameMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) - - The distinguishedNameMatch rule is an equality matching rule. - - - - - - -Legg Standards Track [Page 35] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - -4.2.16. generalizedTimeMatch - - The generalizedTimeMatch rule compares an assertion value of the - Generalized Time syntax to an attribute value of a syntax (e.g., the - Generalized Time syntax) whose corresponding ASN.1 type is - GeneralizedTime. - - The rule evaluates to TRUE if and only if the attribute value - represents the same universal coordinated time as the assertion - value. If a time is specified with the minutes or seconds absent, - then the number of minutes or seconds (respectively) is assumed to be - zero. - - The LDAP definition for the generalizedTimeMatch rule is: - - ( 2.5.13.27 NAME 'generalizedTimeMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) - - The generalizedTimeMatch rule is an equality matching rule. - -4.2.17. generalizedTimeOrderingMatch - - The generalizedTimeOrderingMatch rule compares the time ordering of - an assertion value of the Generalized Time syntax to an attribute - value of a syntax (e.g., the Generalized Time syntax) whose - corresponding ASN.1 type is GeneralizedTime. - - The rule evaluates to TRUE if and only if the attribute value - represents a universal coordinated time that is earlier than the - universal coordinated time represented by the assertion value. - - The LDAP definition for the generalizedTimeOrderingMatch rule is: - - ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) - - The generalizedTimeOrderingMatch rule is an ordering matching rule. - -4.2.18. integerFirstComponentMatch - - The integerFirstComponentMatch rule compares an assertion value of - the Integer syntax to an attribute value of a syntax (e.g., the DIT - Structure Rule Description syntax) whose corresponding ASN.1 type is - a SEQUENCE with a mandatory first component of the INTEGER ASN.1 - type. - - - - - - -Legg Standards Track [Page 36] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - Note that the assertion syntax of this matching rule differs from the - attribute syntax of attributes for which this is the equality - matching rule. - - The rule evaluates to TRUE if and only if the assertion value and the - first component of the attribute value are the same integer value. - - The LDAP definition for the integerFirstComponentMatch matching rule - is: - - ( 2.5.13.29 NAME 'integerFirstComponentMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) - - The integerFirstComponentMatch rule is an equality matching rule. - When using integerFirstComponentMatch to compare two attribute values - (of an applicable syntax), an assertion value must first be derived - from one of the attribute values. An assertion value can be derived - from an attribute value by taking the first component of that - attribute value. - -4.2.19. integerMatch - - The integerMatch rule compares an assertion value of the Integer - syntax to an attribute value of a syntax (e.g., the Integer syntax) - whose corresponding ASN.1 type is INTEGER. - - The rule evaluates to TRUE if and only if the attribute value and the - assertion value are the same integer value. - - The LDAP definition for the integerMatch matching rule is: - - ( 2.5.13.14 NAME 'integerMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) - - The integerMatch rule is an equality matching rule. - -4.2.20. integerOrderingMatch - - The integerOrderingMatch rule compares an assertion value of the - Integer syntax to an attribute value of a syntax (e.g., the Integer - syntax) whose corresponding ASN.1 type is INTEGER. - - The rule evaluates to TRUE if and only if the integer value of the - attribute value is less than the integer value of the assertion - value. - - The LDAP definition for the integerOrderingMatch matching rule is: - - - - -Legg Standards Track [Page 37] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - ( 2.5.13.15 NAME 'integerOrderingMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) - - The integerOrderingMatch rule is an ordering matching rule. - -4.2.21. keywordMatch - - The keywordMatch rule compares an assertion value of the Directory - String syntax to an attribute value of a syntax (e.g., the Directory - String syntax) whose corresponding ASN.1 type is DirectoryString. - - The rule evaluates to TRUE if and only if the assertion value - character string matches any keyword in the attribute value. The - identification of keywords in the attribute value and the exactness - of the match are both implementation specific. - - The LDAP definition for the keywordMatch rule is: - - ( 2.5.13.33 NAME 'keywordMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) - -4.2.22. numericStringMatch - - The numericStringMatch rule compares an assertion value of the - Numeric String syntax to an attribute value of a syntax (e.g., the - Numeric String syntax) whose corresponding ASN.1 type is - NumericString. - - The rule evaluates to TRUE if and only if the prepared attribute - value character string and the prepared assertion value character - string have the same number of characters and corresponding - characters have the same code point. - - In preparing the attribute value and assertion value for comparison, - characters are not case folded in the Map preparation step, and only - numericString Insignificant Character Handling is applied in the - Insignificant Character Handling step. - - The LDAP definition for the numericStringMatch matching rule is: - - ( 2.5.13.8 NAME 'numericStringMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) - - The numericStringMatch rule is an equality matching rule. - - - - - - - -Legg Standards Track [Page 38] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - -4.2.23. numericStringOrderingMatch - - The numericStringOrderingMatch rule compares an assertion value of - the Numeric String syntax to an attribute value of a syntax (e.g., - the Numeric String syntax) whose corresponding ASN.1 type is - NumericString. - - The rule evaluates to TRUE if and only if, in the code point - collation order, the prepared attribute value character string - appears earlier than the prepared assertion value character string; - i.e., the attribute value is "less than" the assertion value. - - In preparing the attribute value and assertion value for comparison, - characters are not case folded in the Map preparation step, and only - numericString Insignificant Character Handling is applied in the - Insignificant Character Handling step. - - The rule is identical to the caseIgnoreOrderingMatch rule except that - all space characters are skipped during comparison (case is - irrelevant as the characters are numeric). - - The LDAP definition for the numericStringOrderingMatch matching rule - is: - - ( 2.5.13.9 NAME 'numericStringOrderingMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) - - The numericStringOrderingMatch rule is an ordering matching rule. - -4.2.24. numericStringSubstringsMatch - - The numericStringSubstringsMatch rule compares an assertion value of - the Substring Assertion syntax to an attribute value of a syntax - (e.g., the Numeric String syntax) whose corresponding ASN.1 type is - NumericString. - - The rule evaluates to TRUE if and only if (1) the prepared substrings - of the assertion value match disjoint portions of the prepared - attribute value character string in the order of the substrings in - the assertion value, (2) an <initial> substring, if present, matches - the beginning of the prepared attribute value character string, and - (3) a <final> substring, if present, matches the end of the prepared - attribute value character string. A prepared substring matches a - portion of the prepared attribute value character string if - corresponding characters have the same code point. - - In preparing the attribute value and assertion value for comparison, - characters are not case folded in the Map preparation step, and only - - - -Legg Standards Track [Page 39] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - numericString Insignificant Character Handling is applied in the - Insignificant Character Handling step. - - The LDAP definition for the numericStringSubstringsMatch matching - rule is: - - ( 2.5.13.10 NAME 'numericStringSubstringsMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) - - The numericStringSubstringsMatch rule is a substrings matching rule. - -4.2.25. objectIdentifierFirstComponentMatch - - The objectIdentifierFirstComponentMatch rule compares an assertion - value of the OID syntax to an attribute value of a syntax (e.g., the - Attribute Type Description, DIT Content Rule Description, LDAP Syntax - Description, Matching Rule Description, Matching Rule Use - Description, Name Form Description, or Object Class Description - syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory - first component of the OBJECT IDENTIFIER ASN.1 type. - - Note that the assertion syntax of this matching rule differs from the - attribute syntax of attributes for which this is the equality - matching rule. - - The rule evaluates to TRUE if and only if the assertion value matches - the first component of the attribute value using the rules of - objectIdentifierMatch. - - The LDAP definition for the objectIdentifierFirstComponentMatch - matching rule is: - - ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) - - The objectIdentifierFirstComponentMatch rule is an equality matching - rule. When using objectIdentifierFirstComponentMatch to compare two - attribute values (of an applicable syntax), an assertion value must - first be derived from one of the attribute values. An assertion - value can be derived from an attribute value by taking the first - component of that attribute value. - -4.2.26. objectIdentifierMatch - - The objectIdentifierMatch rule compares an assertion value of the OID - syntax to an attribute value of a syntax (e.g., the OID syntax) whose - corresponding ASN.1 type is OBJECT IDENTIFIER. - - - - -Legg Standards Track [Page 40] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - The rule evaluates to TRUE if and only if the assertion value and the - attribute value represent the same object identifier; that is, the - same sequence of integers, whether represented explicitly in the - <numericoid> form of <oid> or implicitly in the <descr> form (see - [RFC4512]). - - If an LDAP client supplies an assertion value in the <descr> form and - the chosen descriptor is not recognized by the server, then the - objectIdentifierMatch rule evaluates to Undefined. - - The LDAP definition for the objectIdentifierMatch matching rule is: - - ( 2.5.13.0 NAME 'objectIdentifierMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) - - The objectIdentifierMatch rule is an equality matching rule. - -4.2.27. octetStringMatch - - The octetStringMatch rule compares an assertion value of the Octet - String syntax to an attribute value of a syntax (e.g., the Octet - String or JPEG syntax) whose corresponding ASN.1 type is the OCTET - STRING ASN.1 type. - - The rule evaluates to TRUE if and only if the attribute value and the - assertion value are the same length and corresponding octets (by - position) are the same. - - The LDAP definition for the octetStringMatch matching rule is: - - ( 2.5.13.17 NAME 'octetStringMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) - - The octetStringMatch rule is an equality matching rule. - -4.2.28. octetStringOrderingMatch - - The octetStringOrderingMatch rule compares an assertion value of the - Octet String syntax to an attribute value of a syntax (e.g., the - Octet String or JPEG syntax) whose corresponding ASN.1 type is the - OCTET STRING ASN.1 type. - - The rule evaluates to TRUE if and only if the attribute value appears - earlier in the collation order than the assertion value. The rule - compares octet strings from the first octet to the last octet, and - from the most significant bit to the least significant bit within the - octet. The first occurrence of a different bit determines the - ordering of the strings. A zero bit precedes a one bit. If the - - - -Legg Standards Track [Page 41] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - strings contain different numbers of octets but the longer string is - identical to the shorter string up to the length of the shorter - string, then the shorter string precedes the longer string. - - The LDAP definition for the octetStringOrderingMatch matching rule - is: - - ( 2.5.13.18 NAME 'octetStringOrderingMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) - - The octetStringOrderingMatch rule is an ordering matching rule. - -4.2.29. telephoneNumberMatch - - The telephoneNumberMatch rule compares an assertion value of the - Telephone Number syntax to an attribute value of a syntax (e.g., the - Telephone Number syntax) whose corresponding ASN.1 type is a - PrintableString representing a telephone number. - - The rule evaluates to TRUE if and only if the prepared attribute - value character string and the prepared assertion value character - string have the same number of characters and corresponding - characters have the same code point. - - In preparing the attribute value and assertion value for comparison, - characters are case folded in the Map preparation step, and only - telephoneNumber Insignificant Character Handling is applied in the - Insignificant Character Handling step. - - The LDAP definition for the telephoneNumberMatch matching rule is: - - ( 2.5.13.20 NAME 'telephoneNumberMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) - - The telephoneNumberMatch rule is an equality matching rule. - -4.2.30. telephoneNumberSubstringsMatch - - The telephoneNumberSubstringsMatch rule compares an assertion value - of the Substring Assertion syntax to an attribute value of a syntax - (e.g., the Telephone Number syntax) whose corresponding ASN.1 type is - a PrintableString representing a telephone number. - - The rule evaluates to TRUE if and only if (1) the prepared substrings - of the assertion value match disjoint portions of the prepared - attribute value character string in the order of the substrings in - the assertion value, (2) an <initial> substring, if present, matches - the beginning of the prepared attribute value character string, and - - - -Legg Standards Track [Page 42] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - (3) a <final> substring, if present, matches the end of the prepared - attribute value character string. A prepared substring matches a - portion of the prepared attribute value character string if - corresponding characters have the same code point. - - In preparing the attribute value and assertion value substrings for - comparison, characters are case folded in the Map preparation step, - and only telephoneNumber Insignificant Character Handling is applied - in the Insignificant Character Handling step. - - The LDAP definition for the telephoneNumberSubstringsMatch matching - rule is: - - ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) - - The telephoneNumberSubstringsMatch rule is a substrings matching - rule. - -4.2.31. uniqueMemberMatch - - The uniqueMemberMatch rule compares an assertion value of the Name - And Optional UID syntax to an attribute value of a syntax (e.g., the - Name And Optional UID syntax) whose corresponding ASN.1 type is - NameAndOptionalUID. - - The rule evaluates to TRUE if and only if the <distinguishedName> - components of the assertion value and attribute value match according - to the distinguishedNameMatch rule and either, (1) the <BitString> - component is absent from both the attribute value and assertion - value, or (2) the <BitString> component is present in both the - attribute value and the assertion value and the <BitString> component - of the assertion value matches the <BitString> component of the - attribute value according to the bitStringMatch rule. - - Note that this matching rule has been altered from its description in - X.520 [X.520] in order to make the matching rule commutative. Server - implementors should consider using the original X.520 semantics - (where the matching was less exact) for approximate matching of - attributes with uniqueMemberMatch as the equality matching rule. - - The LDAP definition for the uniqueMemberMatch matching rule is: - - ( 2.5.13.23 NAME 'uniqueMemberMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 ) - - The uniqueMemberMatch rule is an equality matching rule. - - - - -Legg Standards Track [Page 43] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - -4.2.32. wordMatch - - The wordMatch rule compares an assertion value of the Directory - String syntax to an attribute value of a syntax (e.g., the Directory - String syntax) whose corresponding ASN.1 type is DirectoryString. - - The rule evaluates to TRUE if and only if the assertion value word - matches, according to the semantics of caseIgnoreMatch, any word in - the attribute value. The precise definition of a word is - implementation specific. - - The LDAP definition for the wordMatch rule is: - - ( 2.5.13.32 NAME 'wordMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) - -5. Security Considerations - - In general, the LDAP-specific encodings for syntaxes defined in this - document do not define canonical encodings. That is, a - transformation from an LDAP-specific encoding into some other - encoding (e.g., BER) and back into the LDAP-specific encoding will - not necessarily reproduce exactly the original octets of the LDAP- - specific encoding. Therefore, an LDAP-specific encoding should not - be used where a canonical encoding is required. - - Furthermore, the LDAP-specific encodings do not necessarily enable an - alternative encoding of values of the Directory String and DN - syntaxes to be reconstructed; e.g., a transformation from a - Distinguished Encoding Rules (DER) [BER] encoding to an LDAP-specific - encoding and back to a DER encoding may not reproduce the original - DER encoding. Therefore, LDAP-specific encodings should not be used - where reversibility to DER is needed; e.g., for the verification of - digital signatures. Instead, DER or a DER-reversible encoding should - be used. - - When interpreting security-sensitive fields (in particular, fields - used to grant or deny access), implementations MUST ensure that any - matching rule comparisons are done on the underlying abstract value, - regardless of the particular encoding used. - -6. Acknowledgements - - This document is primarily a revision of RFC 2252 by M. Wahl, A. - Coulbeck, T. Howes, and S. Kille. RFC 2252 was a product of the IETF - ASID Working Group. - - - - - -Legg Standards Track [Page 44] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - This document is based on input from the IETF LDAPBIS working group. - The author would like to thank Kathy Dally for editing the early - drafts of this document, and Jim Sermersheim and Kurt Zeilenga for - their significant contributions to this revision. - -7. IANA Considerations - - The Internet Assigned Numbers Authority (IANA) has updated the LDAP - descriptors registry [BCP64] as indicated by the following templates: - - Subject: Request for LDAP Descriptor Registration Update - Descriptor (short name): see comment - Object Identifier: see comment - Person & email address to contact for further information: - Steven Legg <steven.legg@eb2bcom.com> - Usage: see comment - Specification: RFC 4517 - Author/Change Controller: IESG - - NAME Type OID - ------------------------------------------------------------------ - bitStringMatch M 2.5.13.16 - booleanMatch M 2.5.13.13 - caseExactIA5Match M 1.3.6.1.4.1.1466.109.114.1 - caseExactMatch M 2.5.13.5 - caseExactOrderingMatch M 2.5.13.6 - caseExactSubstringsMatch M 2.5.13.7 - caseIgnoreIA5Match M 1.3.6.1.4.1.1466.109.114.2 - caseIgnoreListMatch M 2.5.13.11 - caseIgnoreListSubstringsMatch M 2.5.13.12 - caseIgnoreMatch M 2.5.13.2 - caseIgnoreOrderingMatch M 2.5.13.3 - caseIgnoreSubstringsMatch M 2.5.13.4 - directoryStringFirstComponentMatch M 2.5.13.31 - distinguishedNameMatch M 2.5.13.1 - generalizedTimeMatch M 2.5.13.27 - generalizedTimeOrderingMatch M 2.5.13.28 - integerFirstComponentMatch M 2.5.13.29 - integerMatch M 2.5.13.14 - integerOrderingMatch M 2.5.13.15 - keywordMatch M 2.5.13.33 - numericStringMatch M 2.5.13.8 - numericStringOrderingMatch M 2.5.13.9 - numericStringSubstringsMatch M 2.5.13.10 - objectIdentifierFirstComponentMatch M 2.5.13.30 - octetStringMatch M 2.5.13.17 - octetStringOrderingMatch M 2.5.13.18 - telephoneNumberMatch M 2.5.13.20 - - - -Legg Standards Track [Page 45] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - telephoneNumberSubstringsMatch M 2.5.13.21 - uniqueMemberMatch M 2.5.13.23 - wordMatch M 2.5.13.32 - - The descriptor for the object identifier 2.5.13.0 was incorrectly - registered as objectIdentifiersMatch (extraneous \`s') in BCP 64. - It has been changed to the following, with a reference to - RFC 4517. - - NAME Type OID - ------------------------------------------------------------------ - objectIdentifierMatch M 2.5.13.0 - - Subject: Request for LDAP Descriptor Registration - Descriptor (short name): caseIgnoreIA5SubstringsMatch - Object Identifier: 1.3.6.1.4.1.1466.109.114.3 - Person & email address to contact for further information: - Steven Legg <steven.legg@eb2bcom.com> - Usage: other (M) - Specification: RFC 4517 - Author/Change Controller: IESG - -8. References - -8.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO - 10646", STD 63, RFC 3629, November 2003. - - [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 4234, October 2005. - - [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol - (LDAP): Technical Specification Road Map", RFC 4510, June - 2006. - - [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access - Protocol (LDAP): The Protocol", RFC 4511, June 2006. - - [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP): Directory Information Models", RFC 4512, June - 2006. - - - - - - -Legg Standards Track [Page 46] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol - (LDAP): String Representation of Distinguished Names", RFC - 4514, June 2006. - - [RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP): Internationalized String Preparation", RFC 4518, - June 2006. - - [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) - Considerations for the Lightweight Directory Access - Protocol (LDAP)", BCP 64, RFC 4520, June 2006. - - [E.123] Notation for national and international telephone numbers, - ITU-T Recommendation E.123, 1988. - - [FAX] Standardization of Group 3 facsimile apparatus for - document transmission - Terminal Equipment and Protocols - for Telematic Services, ITU-T Recommendation T.4, 1993 - - [T.50] International Reference Alphabet (IRA) (Formerly - International Alphabet No. 5 or IA5) Information - Technology - 7-Bit Coded Character Set for Information - Interchange, ITU-T Recommendation T.50, 1992 - - [X.420] ITU-T Recommendation X.420 (1996) | ISO/IEC 10021-7:1997, - Information Technology - Message Handling Systems (MHS): - Interpersonal messaging system - - [X.501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994, - Information Technology - Open Systems Interconnection - - The Directory: Models - - [X.520] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994, - Information Technology - Open Systems Interconnection - - The Directory: Selected attribute types - - [ASN.1] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002, - Information technology - Abstract Syntax Notation One - (ASN.1): Specification of basic notation - - [ISO3166] ISO 3166, "Codes for the representation of names of - countries". - - [ISO8601] ISO 8601:2004, "Data elements and interchange formats -- - Information interchange -- Representation of dates and - times". - - - - - -Legg Standards Track [Page 47] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - [UCS] Universal Multiple-Octet Coded Character Set (UCS) - - Architecture and Basic Multilingual Plane, ISO/IEC 10646- - 1: 1993 (with amendments). - - [JPEG] JPEG File Interchange Format (Version 1.02). Eric - Hamilton, C-Cube Microsystems, Milpitas, CA, September 1, - 1992. - -8.2. Informative References - - [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol - (LDAP): Schema for User Applications", RFC 4519, June - 2006. - - [RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP) Schema Definitions for X.509 Certificates", RFC - 4523, June 2006. - - [X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994, - Information Technology - Open Systems Interconnection - - The Directory: Overview of concepts, models and services - - [BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002, - Information technology - ASN.1 encoding rules: - Specification of Basic Encoding Rules (BER), Canonical - Encoding Rules (CER) and Distinguished Encoding Rules - (DER) - - - - - - - - - - - - - - - - - - - - - - - - -Legg Standards Track [Page 48] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - -Appendix A. Summary of Syntax Object Identifiers - - The following list summarizes the object identifiers assigned to the - syntaxes defined in this document. - - Syntax OBJECT IDENTIFIER - ============================================================== - Attribute Type Description 1.3.6.1.4.1.1466.115.121.1.3 - Bit String 1.3.6.1.4.1.1466.115.121.1.6 - Boolean 1.3.6.1.4.1.1466.115.121.1.7 - Country String 1.3.6.1.4.1.1466.115.121.1.11 - Delivery Method 1.3.6.1.4.1.1466.115.121.1.14 - Directory String 1.3.6.1.4.1.1466.115.121.1.15 - DIT Content Rule Description 1.3.6.1.4.1.1466.115.121.1.16 - DIT Structure Rule Description 1.3.6.1.4.1.1466.115.121.1.17 - DN 1.3.6.1.4.1.1466.115.121.1.12 - Enhanced Guide 1.3.6.1.4.1.1466.115.121.1.21 - Facsimile Telephone Number 1.3.6.1.4.1.1466.115.121.1.22 - Fax 1.3.6.1.4.1.1466.115.121.1.23 - Generalized Time 1.3.6.1.4.1.1466.115.121.1.24 - Guide 1.3.6.1.4.1.1466.115.121.1.25 - IA5 String 1.3.6.1.4.1.1466.115.121.1.26 - Integer 1.3.6.1.4.1.1466.115.121.1.27 - JPEG 1.3.6.1.4.1.1466.115.121.1.28 - LDAP Syntax Description 1.3.6.1.4.1.1466.115.121.1.54 - Matching Rule Description 1.3.6.1.4.1.1466.115.121.1.30 - Matching Rule Use Description 1.3.6.1.4.1.1466.115.121.1.31 - Name And Optional UID 1.3.6.1.4.1.1466.115.121.1.34 - Name Form Description 1.3.6.1.4.1.1466.115.121.1.35 - Numeric String 1.3.6.1.4.1.1466.115.121.1.36 - Object Class Description 1.3.6.1.4.1.1466.115.121.1.37 - Octet String 1.3.6.1.4.1.1466.115.121.1.40 - OID 1.3.6.1.4.1.1466.115.121.1.38 - Other Mailbox 1.3.6.1.4.1.1466.115.121.1.39 - Postal Address 1.3.6.1.4.1.1466.115.121.1.41 - Printable String 1.3.6.1.4.1.1466.115.121.1.44 - Substring Assertion 1.3.6.1.4.1.1466.115.121.1.58 - Telephone Number 1.3.6.1.4.1.1466.115.121.1.50 - Teletex Terminal Identifier 1.3.6.1.4.1.1466.115.121.1.51 - Telex Number 1.3.6.1.4.1.1466.115.121.1.52 - UTC Time 1.3.6.1.4.1.1466.115.121.1.53 - -Appendix B. Changes from RFC 2252 - - This annex lists the significant differences between this - specification and RFC 2252. - - - - - -Legg Standards Track [Page 49] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - This annex is provided for informational purposes only. It is not a - normative part of this specification. - - 1. The IESG Note has been removed. - - 2. The major part of Sections 4, 5 and 7 has been moved to [RFC4512] - and revised. Changes to the parts of these sections moved to - [RFC4512] are detailed in [RFC4512]. - - 3. BNF descriptions of syntax formats have been replaced by ABNF - [RFC4234] specifications. - - 4. The ambiguous statement in RFC 2252, Section 4.3 regarding the - use of a backslash quoting mechanism to escape separator symbols - has been removed. The escaping mechanism is now explicitly - represented in the ABNF for the syntaxes where this provision - applies. - - 5. The description of each of the LDAP syntaxes has been expanded so - that they are less dependent on knowledge of X.500 for - interpretation. - - 6. The relationship of LDAP syntaxes to corresponding ASN.1 type - definitions has been made explicit. - - 7. The set of characters allowed in a <PrintableString> (formerly - <printablestring>) has been corrected to align with the - PrintableString ASN.1 type in [ASN.1]. Specifically, the double - quote character has been removed and the single quote character - and equals sign have been added. - - 8. Values of the Directory String, Printable String and Telephone - Number syntaxes are now required to have at least one character. - - 9. The <DITContentRuleDescription>, <NameFormDescription> and - <DITStructureRuleDescription> rules have been moved to [RFC4512]. - - 10. The corresponding ASN.1 type for the Other Mailbox syntax has - been incorporated from RFC 1274. - - 11. A corresponding ASN.1 type for the LDAP Syntax Description syntax - has been invented. - - 12. The Binary syntax has been removed because it was not adequately - specified, implementations with different incompatible - interpretations exist, and it was confused with the ;binary - transfer encoding. - - - - -Legg Standards Track [Page 50] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - 13. All discussion of transfer options, including the ";binary" - option, has been removed. All imperatives regarding binary - transfer of values have been removed. - - 14. The Delivery Method, Enhanced Guide, Guide, Octet String, Teletex - Terminal Identifier and Telex Number syntaxes from RFC 2256 have - been incorporated. - - 15. The <criteria> rule for the Enhanced Guide and Guide syntaxes has - been extended to accommodate empty "and" and "or" expressions. - - 16. An encoding for the <ttx-value> rule in the Teletex Terminal - Identifier syntax has been defined. - - 17. The PKI-related syntaxes (Certificate, Certificate List and - Certificate Pair) have been removed. They are reintroduced in - [RFC4523] (as is the Supported Algorithm syntax from RFC 2256). - - 18. The MHS OR Address syntax has been removed since its - specification (in RFC 2156) is not at draft standard maturity. - - 19. The DL Submit Permission syntax has been removed as it depends on - the MHS OR Address syntax. - - 20. The Presentation Address syntax has been removed since its - specification (in RFC 1278) is not at draft standard maturity. - - 21. The ACI Item, Access Point, Audio, Data Quality, DSA Quality, DSE - Type, LDAP Schema Description, Master And Shadow Access Points, - Modify Rights, Protocol Information, Subtree Specification, - Supplier Information, Supplier Or Consumer and Supplier And - Consumer syntaxes have been removed. These syntaxes are - referenced in RFC 2252, but not defined. - - 22. The LDAP Schema Definition syntax (defined in RFC 2927) and the - Mail Preference syntax have been removed on the grounds that they - are out of scope for the core specification. - - 23. The description of each of the matching rules has been expanded - so that they are less dependent on knowledge of X.500 for - interpretation. - - 24. The caseIgnoreIA5SubstringsMatch matching rule from RFC 2798 has - been added. - - 25. The caseIgnoreListSubstringsMatch, caseIgnoreOrderingMatch and - caseIgnoreSubstringsMatch matching rules have been added to the - list of matching rules for which the provisions for handling - - - -Legg Standards Track [Page 51] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - - leading, trailing and multiple adjoining whitespace characters - apply (now through string preparation). This is consistent with - the definitions of these matching rules in X.500. The - caseIgnoreIA5SubstringsMatch rule has also been added to the - list. - - 26. The specification of the octetStringMatch matching rule from - RFC 2256 has been added to this document. - - 27. The presentationAddressMatch matching rule has been removed as it - depends on an assertion syntax (Presentation Address) that is not - at draft standard maturity. - - 28. The protocolInformationMatch matching rule has been removed as it - depends on an undefined assertion syntax (Protocol Information). - - 29. The definitive reference for ASN.1 has been changed from X.208 to - X.680 since X.680 is the version of ASN.1 referred to by X.500. - - 30. The specification of the caseIgnoreListSubstringsMatch matching - rule from RFC 2798 & X.520 has been added. - - 31. String preparation algorithms have been applied to the character - string matching rules. - - 32. The specifications of the booleanMatch, caseExactMatch, - caseExactOrderingMatch, caseExactSubstringsMatch, - directoryStringFirstComponentMatch, integerOrderingMatch, - keywordMatch, numericStringOrderingMatch, - octetStringOrderingMatch and wordMatch matching rules from - RFC 3698 & X.520 have been added. - -Author's Address - - Steven Legg - eB2Bcom - Suite3, Woodhouse Corporate Centre - 935 Station Street - Box Hill North, Victoria 3129 - AUSTRALIA - - Phone: +61 3 9896 7830 - Fax: +61 3 9896 7801 - EMail: steven.legg@eb2bcom.com - - - - - - - -Legg Standards Track [Page 52] - -RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Legg Standards Track [Page 53] - diff --git a/source4/ldap_server/devdocs/rfc4518.txt b/source4/ldap_server/devdocs/rfc4518.txt deleted file mode 100644 index f886bdfb5d..0000000000 --- a/source4/ldap_server/devdocs/rfc4518.txt +++ /dev/null @@ -1,787 +0,0 @@ - - - - - - -Network Working Group K. Zeilenga -Request for Comments: 4518 OpenLDAP Foundation -Category: Standards Track June 2006 - - - Lightweight Directory Access Protocol (LDAP): - Internationalized String Preparation - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - The previous Lightweight Directory Access Protocol (LDAP) technical - specifications did not precisely define how character string matching - is to be performed. This led to a number of usability and - interoperability problems. This document defines string preparation - algorithms for character-based matching rules defined for use in - LDAP. - -1. Introduction - -1.1. Background - - A Lightweight Directory Access Protocol (LDAP) [RFC4510] matching - rule [RFC4517] defines an algorithm for determining whether a - presented value matches an attribute value in accordance with the - criteria defined for the rule. The proposition may be evaluated to - True, False, or Undefined. - - True - the attribute contains a matching value, - - False - the attribute contains no matching value, - - Undefined - it cannot be determined whether the attribute contains - a matching value. - - - - - - -Zeilenga Standards Track [Page 1] - -RFC 4518 LDAP: Internationalized String Preparation June 2006 - - - For instance, the caseIgnoreMatch matching rule may be used to - compare whether the commonName attribute contains a particular value - without regard for case and insignificant spaces. - -1.2. X.500 String Matching Rules - - "X.520: Selected attribute types" [X.520] provides (among other - things) value syntaxes and matching rules for comparing values - commonly used in the directory [X.500]. These specifications are - inadequate for strings composed of Unicode [Unicode] characters. - - The caseIgnoreMatch matching rule [X.520], for example, is simply - defined as being a case-insensitive comparison where insignificant - spaces are ignored. For printableString, there is only one space - character and case mapping is bijective, hence this definition is - sufficient. However, for Unicode string types such as - universalString, this is not sufficient. For example, a case- - insensitive matching implementation that folded lowercase characters - to uppercase would yield different results than an implementation - that used uppercase to lowercase folding. Or one implementation may - view space as referring to only SPACE (U+0020), a second - implementation may view any character with the space separator (Zs) - property as a space, and another implementation may view any - character with the whitespace (WS) category as a space. - - The lack of precise specification for character string matching has - led to significant interoperability problems. When used in - certificate chain validation, security vulnerabilities can arise. To - address these problems, this document defines precise algorithms for - preparing character strings for matching. - -1.3. Relationship to "stringprep" - - The character string preparation algorithms described in this - document are based upon the "stringprep" approach [RFC3454]. In - "stringprep", presented and stored values are first prepared for - comparison so that a character-by-character comparison yields the - "correct" result. - - The approach used here is a refinement of the "stringprep" [RFC3454] - approach. Each algorithm involves two additional preparation steps. - - a) Prior to applying the Unicode string preparation steps outlined in - "stringprep", the string is transcoded to Unicode. - - b) After applying the Unicode string preparation steps outlined in - "stringprep", the string is modified to appropriately handle - characters insignificant to the matching rule. - - - -Zeilenga Standards Track [Page 2] - -RFC 4518 LDAP: Internationalized String Preparation June 2006 - - - Hence, preparation of character strings for X.500 [X.500] matching - [X.501] involves the following steps: - - 1) Transcode - 2) Map - 3) Normalize - 4) Prohibit - 5) Check Bidi (Bidirectional) - 6) Insignificant Character Handling - - These steps are described in Section 2. - - It is noted that while various tables of Unicode characters included - or referenced by this specification are derived from Unicode - [Unicode] data, these tables are to be considered definitive for the - purpose of implementing this specification. - -1.4. Relationship to the LDAP Technical Specification - - This document is an integral part of the LDAP technical specification - [RFC4510], which obsoletes the previously defined LDAP technical - specification [RFC3377] in its entirety. - - This document details new LDAP internationalized character string - preparation algorithms used by [RFC4517] and possible other technical - specifications defining LDAP syntaxes and/or matching rules. - -1.5. Relationship to X.500 - - LDAP is defined [RFC4510] in X.500 terms as an X.500 access - mechanism. As such, there is a strong desire for alignment between - LDAP and X.500 syntax and semantics. The character string - preparation algorithms described in this document are based upon - "Internationalized String Matching Rules for X.500" [XMATCH] proposal - to ITU/ISO Joint Study Group 2. - -1.6. Conventions and Terms - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in BCP 14 [RFC2119]. - - Character names in this document use the notation for code points and - names from the Unicode Standard [Unicode]. For example, the letter - "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>. - In the lists of mappings and the prohibited characters, the "U+" is - - - - - -Zeilenga Standards Track [Page 3] - -RFC 4518 LDAP: Internationalized String Preparation June 2006 - - - left off to make the lists easier to read. The comments for - character ranges are shown in square brackets (such as "[CONTROL - CHARACTERS]") and do not come from the standard. - - Note: a glossary of terms used in Unicode can be found in [Glossary]. - Information on the Unicode character encoding model can be found in - [CharModel]. - - The term "combining mark", as used in this specification, refers to - any Unicode [Unicode] code point that has a mark property (Mn, Mc, - Me). Appendix A provides a definitive list of combining marks. - -2. String Preparation - - The following six-step process SHALL be applied to each presented and - attribute value in preparation for character string matching rule - evaluation. - - 1) Transcode - 2) Map - 3) Normalize - 4) Prohibit - 5) Check bidi - 6) Insignificant Character Handling - - Failure in any step causes the assertion to evaluate to Undefined. - - The character repertoire of this process is Unicode 3.2 [Unicode]. - - Note that this six-step process specification is intended to describe - expected matching behavior. Implementations are free to use - alternative processes so long as the matching rule evaluation - behavior provided is consistent with the behavior described by this - specification. - -2.1. Transcode - - Each non-Unicode string value is transcoded to Unicode. - - PrintableString [X.680] values are transcoded directly to Unicode. - - UniversalString, UTF8String, and bmpString [X.680] values need not be - transcoded as they are Unicode-based strings (in the case of - bmpString, a subset of Unicode). - - TeletexString [X.680] values are transcoded to Unicode. As there is - no standard for mapping TeletexString values to Unicode, the mapping - is left a local matter. - - - -Zeilenga Standards Track [Page 4] - -RFC 4518 LDAP: Internationalized String Preparation June 2006 - - - For these and other reasons, use of TeletexString is NOT RECOMMENDED. - - The output is the transcoded string. - -2.2. Map - - SOFT HYPHEN (U+00AD) and MONGOLIAN TODO SOFT HYPHEN (U+1806) code - points are mapped to nothing. COMBINING GRAPHEME JOINER (U+034F) and - VARIATION SELECTORs (U+180B-180D, FF00-FE0F) code points are also - mapped to nothing. The OBJECT REPLACEMENT CHARACTER (U+FFFC) is - mapped to nothing. - - CHARACTER TABULATION (U+0009), LINE FEED (LF) (U+000A), LINE - TABULATION (U+000B), FORM FEED (FF) (U+000C), CARRIAGE RETURN (CR) - (U+000D), and NEXT LINE (NEL) (U+0085) are mapped to SPACE (U+0020). - - All other control code (e.g., Cc) points or code points with a - control function (e.g., Cf) are mapped to nothing. The following is - a complete list of these code points: U+0000-0008, 000E-001F, 007F- - 0084, 0086-009F, 06DD, 070F, 180E, 200C-200F, 202A-202E, 2060-2063, - 206A-206F, FEFF, FFF9-FFFB, 1D173-1D17A, E0001, E0020-E007F. - - ZERO WIDTH SPACE (U+200B) is mapped to nothing. All other code - points with Separator (space, line, or paragraph) property (e.g., Zs, - Zl, or Zp) are mapped to SPACE (U+0020). The following is a complete - list of these code points: U+0020, 00A0, 1680, 2000-200A, 2028-2029, - 202F, 205F, 3000. - - For case ignore, numeric, and stored prefix string matching rules, - characters are case folded per B.2 of [RFC3454]. - - The output is the mapped string. - -2.3. Normalize - - The input string is to be normalized to Unicode Form KC - (compatibility composed) as described in [UAX15]. The output is the - normalized string. - -2.4. Prohibit - - All Unassigned code points are prohibited. Unassigned code points - are listed in Table A.1 of [RFC3454]. - - Characters that, per Section 5.8 of [RFC3454], change display - properties or are deprecated are prohibited. These characters are - listed in Table C.8 of [RFC3454]. - - - - -Zeilenga Standards Track [Page 5] - -RFC 4518 LDAP: Internationalized String Preparation June 2006 - - - Private Use code points are prohibited. These characters are listed - in Table C.3 of [RFC3454]. - - All non-character code points are prohibited. These code points are - listed in Table C.4 of [RFC3454]. - - Surrogate codes are prohibited. These characters are listed in Table - C.5 of [RFC3454]. - - The REPLACEMENT CHARACTER (U+FFFD) code point is prohibited. - - The step fails if the input string contains any prohibited code - point. Otherwise, the output is the input string. - -2.5. Check bidi - - Bidirectional characters are ignored. - -2.6. Insignificant Character Handling - - In this step, the string is modified to ensure proper handling of - characters insignificant to the matching rule. This modification - differs from matching rule to matching rule. - - Section 2.6.1 applies to case ignore and exact string matching. - Section 2.6.2 applies to numericString matching. - Section 2.6.3 applies to telephoneNumber matching. - -2.6.1. Insignificant Space Handling - - For the purposes of this section, a space is defined to be the SPACE - (U+0020) code point followed by no combining marks. - - NOTE - The previous steps ensure that the string cannot contain - any code points in the separator class, other than SPACE - (U+0020). - - For input strings that are attribute values or non-substring - assertion values: If the input string contains no non-space - character, then the output is exactly two SPACEs. Otherwise (the - input string contains at least one non-space character), the string - is modified such that the string starts with exactly one space - character, ends with exactly one SPACE character, and any inner - (non-empty) sequence of space characters is replaced with exactly two - SPACE characters. For instance, the input strings - "foo<SPACE>bar<SPACE><SPACE>", result in the output - "<SPACE>foo<SPACE><SPACE>bar<SPACE>". - - - - -Zeilenga Standards Track [Page 6] - -RFC 4518 LDAP: Internationalized String Preparation June 2006 - - - For input strings that are substring assertion values: If the string - being prepared contains no non-space characters, then the output - string is exactly one SPACE. Otherwise, the following steps are - taken: - - - If the input string is an initial substring, it is modified to - start with exactly one SPACE character; - - - If the input string is an initial or an any substring that ends in - one or more space characters, it is modified to end with exactly - one SPACE character; - - - If the input string is an any or a final substring that starts in - one or more space characters, it is modified to start with exactly - one SPACE character; and - - - If the input string is a final substring, it is modified to end - with exactly one SPACE character. - - For instance, for the input string "foo<SPACE>bar<SPACE><SPACE>" as - an initial substring, the output would be - "<SPACE>foo<SPACE><SPACE>bar<SPACE>". As an any or final substring, - the same input would result in "foo<SPACE>bar<SPACE>". - - Appendix B discusses the rationale for the behavior. - -2.6.2. numericString Insignificant Character Handling - - For the purposes of this section, a space is defined to be the SPACE - (U+0020) code point followed by no combining marks. - - All spaces are regarded as insignificant and are to be removed. - - For example, removal of spaces from the Form KC string: - "<SPACE><SPACE>123<SPACE><SPACE>456<SPACE><SPACE>" - would result in the output string: - "123456" - and the Form KC string: - "<SPACE><SPACE><SPACE>" - would result in the output string: - "" (an empty string). - -2.6.3. telephoneNumber Insignificant Character Handling - - For the purposes of this section, a hyphen is defined to be a - HYPHEN-MINUS (U+002D), ARMENIAN HYPHEN (U+058A), HYPHEN (U+2010), - NON-BREAKING HYPHEN (U+2011), MINUS SIGN (U+2212), SMALL HYPHEN-MINUS - (U+FE63), or FULLWIDTH HYPHEN-MINUS (U+FF0D) code point followed by - - - -Zeilenga Standards Track [Page 7] - -RFC 4518 LDAP: Internationalized String Preparation June 2006 - - - no combining marks and a space is defined to be the SPACE (U+0020) - code point followed by no combining marks. - - All hyphens and spaces are considered insignificant and are to be - removed. - - For example, removal of hyphens and spaces from the Form KC string: - "<SPACE><HYPHEN>123<SPACE><SPACE>456<SPACE><HYPHEN>" - would result in the output string: - "123456" - and the Form KC string: - "<HYPHEN><HYPHEN><HYPHEN>" - would result in the (empty) output string: - "". - -3. Security Considerations - - "Preparation of Internationalized Strings ("stringprep")" [RFC3454] - security considerations generally apply to the algorithms described - here. - -4. Acknowledgements - - The approach used in this document is based upon design principles - and algorithms described in "Preparation of Internationalized Strings - ('stringprep')" [RFC3454] by Paul Hoffman and Marc Blanchet. Some - additional guidance was drawn from Unicode Technical Standards, - Technical Reports, and Notes. - - This document is a product of the IETF LDAP Revision (LDAPBIS) - Working Group. - -5. References - -5.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of - Internationalized Strings ("stringprep")", RFC 3454, - December 2002. - - [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP): Technical Specification Road Map", RFC 4510, - June 2006. - - - - - -Zeilenga Standards Track [Page 8] - -RFC 4518 LDAP: Internationalized String Preparation June 2006 - - - [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol - (LDAP): Syntaxes and Matching Rules", RFC 4517, June - 2006. - - [Unicode] The Unicode Consortium, "The Unicode Standard, Version - 3.2.0" is defined by "The Unicode Standard, Version - 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201- - 61633-5), as amended by the "Unicode Standard Annex - #27: Unicode 3.1" - (http://www.unicode.org/reports/tr27/) and by the - "Unicode Standard Annex #28: Unicode 3.2" - (http://www.unicode.org/reports/tr28/). - - [UAX15] Davis, M. and M. Duerst, "Unicode Standard Annex #15: - Unicode Normalization Forms, Version 3.2.0". - <http://www.unicode.org/unicode/reports/tr15/tr15- - 22.html>, March 2002. - - [X.680] International Telecommunication Union - - Telecommunication Standardization Sector, "Abstract - Syntax Notation One (ASN.1) - Specification of Basic - Notation", X.680(2002) (also ISO/IEC 8824-1:2002). - -5.2. Informative References - - [X.500] International Telecommunication Union - - Telecommunication Standardization Sector, "The - Directory -- Overview of concepts, models and - services," X.500(1993) (also ISO/IEC 9594-1:1994). - - [X.501] International Telecommunication Union - - Telecommunication Standardization Sector, "The - Directory -- Models," X.501(1993) (also ISO/IEC 9594- - 2:1994). - - [X.520] International Telecommunication Union - - Telecommunication Standardization Sector, "The - Directory: Selected Attribute Types", X.520(1993) (also - ISO/IEC 9594-6:1994). - - [Glossary] The Unicode Consortium, "Unicode Glossary", - <http://www.unicode.org/glossary/>. - - [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report - #17, Character Encoding Model", UTR17, - <http://www.unicode.org/unicode/reports/tr17/>, August - 2000. - - - - -Zeilenga Standards Track [Page 9] - -RFC 4518 LDAP: Internationalized String Preparation June 2006 - - - [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access - Protocol (v3): Technical Specification", RFC 3377, - September 2002. - - [RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory - Access Protocol (LDAP): String Representation of Search - Filters", RFC 4515, June 2006. - - [XMATCH] Zeilenga, K., "Internationalized String Matching Rules - for X.500", Work in Progress. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Zeilenga Standards Track [Page 10] - -RFC 4518 LDAP: Internationalized String Preparation June 2006 - - -Appendix A. Combining Marks - - This appendix is normative. - - This table was derived from Unicode [Unicode] data files; it lists - all code points with the Mn, Mc, or Me properties. This table is to - be considered definitive for the purposes of implementation of this - specification. - - 0300-034F 0360-036F 0483-0486 0488-0489 0591-05A1 - 05A3-05B9 05BB-05BC 05BF 05C1-05C2 05C4 064B-0655 0670 - 06D6-06DC 06DE-06E4 06E7-06E8 06EA-06ED 0711 0730-074A - 07A6-07B0 0901-0903 093C 093E-094F 0951-0954 0962-0963 - 0981-0983 09BC 09BE-09C4 09C7-09C8 09CB-09CD 09D7 - 09E2-09E3 0A02 0A3C 0A3E-0A42 0A47-0A48 0A4B-0A4D - 0A70-0A71 0A81-0A83 0ABC 0ABE-0AC5 0AC7-0AC9 0ACB-0ACD - 0B01-0B03 0B3C 0B3E-0B43 0B47-0B48 0B4B-0B4D 0B56-0B57 - 0B82 0BBE-0BC2 0BC6-0BC8 0BCA-0BCD 0BD7 0C01-0C03 - 0C3E-0C44 0C46-0C48 0C4A-0C4D 0C55-0C56 0C82-0C83 - 0CBE-0CC4 0CC6-0CC8 0CCA-0CCD 0CD5-0CD6 0D02-0D03 - 0D3E-0D43 0D46-0D48 0D4A-0D4D 0D57 0D82-0D83 0DCA - 0DCF-0DD4 0DD6 0DD8-0DDF 0DF2-0DF3 0E31 0E34-0E3A - 0E47-0E4E 0EB1 0EB4-0EB9 0EBB-0EBC 0EC8-0ECD 0F18-0F19 - 0F35 0F37 0F39 0F3E-0F3F 0F71-0F84 0F86-0F87 0F90-0F97 - 0F99-0FBC 0FC6 102C-1032 1036-1039 1056-1059 1712-1714 - 1732-1734 1752-1753 1772-1773 17B4-17D3 180B-180D 18A9 - 20D0-20EA 302A-302F 3099-309A FB1E FE00-FE0F FE20-FE23 - 1D165-1D169 1D16D-1D172 1D17B-1D182 1D185-1D18B - 1D1AA-1D1AD - -Appendix B. Substrings Matching - - This appendix is non-normative. - - In the absence of substrings matching, the insignificant space - handling for case ignore/exact matching could be simplified. - Specifically, the handling could be to require that all sequences of - one or more spaces be replaced with one space and, if the string - contains non-space characters, removal of all leading spaces and - trailing spaces. - - In the presence of substrings matching, this simplified space - handling would lead to unexpected and undesirable matching behavior. - For instance: - - 1) (CN=foo\20*\20bar) would match the CN value "foobar"; - - - - - -Zeilenga Standards Track [Page 11] - -RFC 4518 LDAP: Internationalized String Preparation June 2006 - - - 2) (CN=*\20foobar\20*) would match "foobar", but - (CN=*\20*foobar*\20*) would not. - - Note to readers not familiar with LDAP substrings matching: the LDAP - filter [RFC4515] assertion (CN=A*B*C) says to "match any value (of - the attribute CN) that begins with A, contains B after A, ends with C - where C is also after B." - - The first case illustrates that this simplified space handling would - cause leading and trailing spaces in substrings of the string to be - regarded as insignificant. However, only leading and trailing (as - well as multiple consecutive spaces) of the string (as a whole) are - insignificant. - - The second case illustrates that this simplified space handling would - cause sub-partitioning failures. That is, if a prepared any - substring matches a partition of the attribute value, then an - assertion constructed by subdividing that substring into multiple - substrings should also match. - - In designing an appropriate approach for space handling for - substrings matching, one must study key aspects of X.500 case - exact/ignore matching. X.520 [X.520] says: - - The [substrings] rule returns TRUE if there is a partitioning of - the attribute value (into portions) such that: - - - the specified substrings (initial, any, final) match - different portions of the value in the order of the strings - sequence; - - - initial, if present, matches the first portion of the value; - - - final, if present, matches the last portion of the value; - - - any, if present, matches some arbitrary portion of the - value. - - That is, the substrings assertion (CN=foo\20*\20bar) matches the - attribute value "foo<SPACE><SPACE>bar" as the value can be - partitioned into the portions "foo<SPACE>" and "<SPACE>bar" meeting - the above requirements. - - - - - - - - - -Zeilenga Standards Track [Page 12] - -RFC 4518 LDAP: Internationalized String Preparation June 2006 - - - X.520 also says: - - [T]he following spaces are regarded as not significant: - - - leading spaces (i.e., those preceding the first character - that is not a space); - - - trailing spaces (i.e., those following the last character - that is not a space); - - - multiple consecutive spaces (these are taken as equivalent - to a single space character). - - This statement applies to the assertion values and attribute values - as whole strings, and not individually to substrings of an assertion - value. In particular, the statements should be taken to mean that if - an assertion value and attribute value match without any - consideration to insignificant characters, then that assertion value - should also match any attribute value that differs only by inclusion - nor removal of insignificant characters. - - Hence the assertion (CN=foo\20*\20bar) matches - "foo<SPACE><SPACE><SPACE>bar" and "foo<SPACE>bar" as these values - only differ from "foo<SPACE><SPACE>bar" by the inclusion or removal - of insignificant spaces. - - Astute readers of this text will also note that there are special - cases where the specified space handling does not ignore spaces that - could be considered insignificant. For instance, the assertion - (CN=\20*\20*\20) does not match "<SPACE><SPACE><SPACE>" - (insignificant spaces present in value) or " " (insignificant spaces - not present in value). However, as these cases have no practical - application that cannot be met by simple assertions, e.g., (cn=\20), - and this minor anomaly can only be fully addressed by a preparation - algorithm to be used in conjunction with character-by-character - partitioning and matching, the anomaly is considered acceptable. - -Author's Address - - Kurt D. Zeilenga - OpenLDAP Foundation - - EMail: Kurt@OpenLDAP.org - - - - - - - - -Zeilenga Standards Track [Page 13] - -RFC 4518 LDAP: Internationalized String Preparation June 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Zeilenga Standards Track [Page 14] - diff --git a/source4/ldap_server/devdocs/rfc4519.txt b/source4/ldap_server/devdocs/rfc4519.txt deleted file mode 100644 index f2e9b7c4b6..0000000000 --- a/source4/ldap_server/devdocs/rfc4519.txt +++ /dev/null @@ -1,1963 +0,0 @@ - - - - - - -Network Working Group A. Sciberras, Ed. -Request for Comments: 4519 eB2Bcom -Obsoletes: 2256 June 2006 -Updates: 2247, 2798, 2377 -Category: Standards Track - - - Lightweight Directory Access Protocol (LDAP): - Schema for User Applications - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document is an integral part of the Lightweight Directory Access - Protocol (LDAP) technical specification. It provides a technical - specification of attribute types and object classes intended for use - by LDAP directory clients for many directory services, such as White - Pages. These objects are widely used as a basis for the schema in - many LDAP directories. This document does not cover attributes used - for the administration of directory servers, nor does it include - directory objects defined for specific uses in other documents. - - - - - - - - - - - - - - - - - - - -Sciberras Standards Track [Page 1] - -RFC 4519 LDAP: Schema for User Applications June 2006 - - -Table of Contents - - 1. Introduction ....................................................3 - 1.1. Relationship with Other Specifications .....................3 - 1.2. Conventions ................................................4 - 1.3. General Issues .............................................4 - 2. Attribute Types .................................................4 - 2.1. 'businessCategory' .........................................5 - 2.2. 'c' ........................................................5 - 2.3. 'cn' .......................................................5 - 2.4. 'dc' .......................................................6 - 2.5. 'description' ..............................................6 - 2.6. 'destinationIndicator' .....................................7 - 2.7. 'distinguishedName' ........................................7 - 2.8. 'dnQualifier' ..............................................8 - 2.9. 'enhancedSearchGuide' ......................................8 - 2.10. 'facsimileTelephoneNumber' ................................9 - 2.11. 'generationQualifier' .....................................9 - 2.12. 'givenName' ...............................................9 - 2.13. 'houseIdentifier' .........................................9 - 2.14. 'initials' ...............................................10 - 2.15. 'internationalISDNNumber' ................................10 - 2.16. 'l' ......................................................10 - 2.17. 'member' .................................................11 - 2.18. 'name' ...................................................11 - 2.19. 'o' ......................................................11 - 2.20. 'ou' .....................................................12 - 2.21. 'owner' ..................................................12 - 2.22. 'physicalDeliveryOfficeName' .............................12 - 2.23. 'postalAddress' ..........................................13 - 2.24. 'postalCode' .............................................13 - 2.25. 'postOfficeBox' ..........................................14 - 2.26. 'preferredDeliveryMethod' ................................14 - 2.27. 'registeredAddress' ......................................14 - 2.28. 'roleOccupant' ...........................................15 - 2.29. 'searchGuide' ............................................15 - 2.30. 'seeAlso' ................................................15 - 2.31. 'serialNumber' ...........................................16 - 2.32. 'sn' .....................................................16 - 2.33. 'st' .....................................................16 - 2.34. 'street' .................................................17 - 2.35. 'telephoneNumber' ........................................17 - 2.36. 'teletexTerminalIdentifier' ..............................17 - 2.37. 'telexNumber' ............................................18 - 2.38. 'title' ..................................................18 - 2.39. 'uid' ....................................................18 - 2.40. 'uniqueMember' ...........................................19 - 2.41. 'userPassword' ...........................................19 - - - -Sciberras Standards Track [Page 2] - -RFC 4519 LDAP: Schema for User Applications June 2006 - - - 2.42. 'x121Address' ............................................20 - 2.43. 'x500UniqueIdentifier' ...................................20 - 3. Object Classes .................................................20 - 3.1. 'applicationProcess' ......................................21 - 3.2. 'country' .................................................21 - 3.3. 'dcObject' ................................................21 - 3.4. 'device' ..................................................21 - 3.5. 'groupOfNames' ............................................22 - 3.6. 'groupOfUniqueNames' ......................................22 - 3.7. 'locality' ................................................23 - 3.8. 'organization' ............................................23 - 3.9. 'organizationalPerson' ....................................24 - 3.10. 'organizationalRole' .....................................24 - 3.11. 'organizationalUnit' .....................................24 - 3.12. 'person' .................................................25 - 3.13. 'residentialPerson' ......................................25 - 3.14. 'uidObject' ..............................................26 - 4. IANA Considerations ............................................26 - 5. Security Considerations ........................................28 - 6. Acknowledgements ...............................................28 - 7. References .....................................................29 - 7.1. Normative References ......................................29 - 7.2. Informative References ....................................30 - Appendix A Changes Made Since RFC 2256 ...........................32 - -1. Introduction - - This document provides an overview of attribute types and object - classes intended for use by Lightweight Directory Access Protocol - (LDAP) directory clients for many directory services, such as White - Pages. Originally specified in the X.500 [X.500] documents, these - objects are widely used as a basis for the schema in many LDAP - directories. This document does not cover attributes used for the - administration of directory servers, nor does it include directory - objects defined for specific uses in other documents. - -1.1. Relationship with Other Specifications - - This document is an integral part of the LDAP technical specification - [RFC4510], which obsoletes the previously defined LDAP technical - specification, RFC 3377, in its entirety. In terms of RFC 2256, - Sections 6 and 8 of RFC 2256 are obsoleted by [RFC4517]. Sections - 5.1, 5.2, 7.1, and 7.2 of RFC 2256 are obsoleted by [RFC4512]. The - remainder of RFC 2256 is obsoleted by this document. The technical - specification for the 'dc' attribute type and 'dcObject' object class - found in RFC 2247 are superseded by sections 2.4 and 3.3 of this - document. The remainder of RFC 2247 remains in force. - - - - -Sciberras Standards Track [Page 3] - -RFC 4519 LDAP: Schema for User Applications June 2006 - - - This document updates RFC 2798 by replacing the informative - description of the 'uid' attribute type with the definitive - description provided in Section 2.39 of this document. - - This document updates RFC 2377 by replacing the informative - description of the 'uidObject' object class with the definitive - description provided in Section 3.14 of this document. - - A number of schema elements that were included in the previous - revision of the LDAP Technical Specification are not included in this - revision of LDAP. PKI-related schema elements are now specified in - [RFC4523]. Unless reintroduced in future technical specifications, - the remainder are to be considered Historic. - - The descriptions in this document SHALL be considered definitive for - use in LDAP. - -1.2. Conventions - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. - -1.3. General Issues - - This document references Syntaxes defined in Section 3 of [RFC4517] - and Matching Rules defined in Section 4 of [RFC4517]. - - The definitions of Attribute Types and Object Classes are written - using the Augmented Backus-Naur Form (ABNF) [RFC4234] of - AttributeTypeDescription and ObjectClassDescription given in - [RFC4512]. Lines have been folded for readability. When such values - are transferred as attribute values in the LDAP Protocol, the values - will not contain line breaks. - -2. Attribute Types - - The attribute types contained in this section hold user information. - - There is no requirement that servers implement the 'searchGuide' and - 'teletexTerminalIdentifier' attribute types. In fact, their use is - greatly discouraged. - - An LDAP server implementation SHOULD recognize the rest of the - attribute types described in this section. - - - - - - -Sciberras Standards Track [Page 4] - -RFC 4519 LDAP: Schema for User Applications June 2006 - - -2.1. 'businessCategory' - - The 'businessCategory' attribute type describes the kinds of business - performed by an organization. Each kind is one value of this - multi-valued attribute. - (Source: X.520 [X.520]) - - ( 2.5.4.15 NAME 'businessCategory' - EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) - - 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax - [RFC4517]. - - Examples: "banking", "transportation", and "real estate". - -2.2. 'c' - - The 'c' ('countryName' in X.500) attribute type contains a two-letter - ISO 3166 [ISO3166] country code. - (Source: X.520 [X.520]) - - ( 2.5.4.6 NAME 'c' - SUP name - SYNTAX 1.3.6.1.4.1.1466.115.121.1.11 - SINGLE-VALUE ) - - 1.3.6.1.4.1.1466.115.121.1.11 refers to the Country String syntax - [RFC4517]. - - Examples: "DE", "AU" and "FR". - -2.3. 'cn' - - The 'cn' ('commonName' in X.500) attribute type contains names of an - object. Each name is one value of this multi-valued attribute. If - the object corresponds to a person, it is typically the person's full - name. - (Source: X.520 [X.520]) - - ( 2.5.4.3 NAME 'cn' - SUP name ) - - Examples: "Martin K Smith", "Marty Smith" and "printer12". - - - - - - -Sciberras Standards Track [Page 5] - -RFC 4519 LDAP: Schema for User Applications June 2006 - - -2.4. 'dc' - - The 'dc' ('domainComponent' in RFC 1274) attribute type is a string - holding one component, a label, of a DNS domain name - [RFC1034][RFC2181] naming a host [RFC1123]. That is, a value of this - attribute is a string of ASCII characters adhering to the following - ABNF [RFC4234]: - - label = (ALPHA / DIGIT) [*61(ALPHA / DIGIT / HYPHEN) (ALPHA / DIGIT)] - ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z" - DIGIT = %x30-39 ; "0"-"9" - HYPHEN = %x2D ; hyphen ("-") - - The encoding of IA5String for use in LDAP is simply the characters of - the ASCII label. The equality matching rule is case insensitive, as - is today's DNS. (Source: RFC 2247 [RFC2247] and RFC 1274 [RFC 1274]) - - ( 0.9.2342.19200300.100.1.25 NAME 'dc' - EQUALITY caseIgnoreIA5Match - SUBSTR caseIgnoreIA5SubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 - SINGLE-VALUE ) - - 1.3.6.1.4.1.1466.115.121.1.26 refers to the IA5 String syntax - [RFC4517]. - - Examples: Valid values include "example" and "com" but not - "example.com". The latter is invalid as it contains multiple domain - components. - - It is noted that the directory service will not ensure that values of - this attribute conform to the host label restrictions [RFC1123] - illustrated by the <label> production provided above. It is the - directory client's responsibility to ensure that the labels it stores - in this attribute are appropriately restricted. - - Directory applications supporting International Domain Names SHALL - use the ToASCII method [RFC3490] to produce the domain component - label. The special considerations discussed in Section 4 of RFC 3490 - [RFC3490] should be taken, depending on whether the domain component - is used for "stored" or "query" purposes. - -2.5. 'description' - - The 'description' attribute type contains human-readable descriptive - phrases about the object. Each description is one value of this - multi-valued attribute. - (Source: X.520 [X.520]) - - - -Sciberras Standards Track [Page 6] - -RFC 4519 LDAP: Schema for User Applications June 2006 - - - ( 2.5.4.13 NAME 'description' - EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) - - 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax - [RFC4517]. - - Examples: "a color printer", "Maintenance is done every Monday, at - 1pm.", and "distribution list for all technical staff". - -2.6. 'destinationIndicator' - - The 'destinationIndicator' attribute type contains country and city - strings associated with the object (the addressee) needed to provide - the Public Telegram Service. The strings are composed in accordance - with CCITT Recommendations F.1 [F.1] and F.31 [F.31]. Each string is - one value of this multi-valued attribute. - (Source: X.520 [X.520]) - - ( 2.5.4.27 NAME 'destinationIndicator' - EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 ) - - 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax - [RFC4517]. - - Examples: "AASD" as a destination indicator for Sydney, Australia. - "GBLD" as a destination indicator for London, United - Kingdom. - - It is noted that the directory will not ensure that values of this - attribute conform to the F.1 and F.31 CCITT Recommendations. It is - the application's responsibility to ensure destination indicators - that it stores in this attribute are appropriately constructed. - -2.7. 'distinguishedName' - - The 'distinguishedName' attribute type is not used as the name of the - object itself, but it is instead a base type from which some user - attribute types with a DN syntax can inherit. - - It is unlikely that values of this type itself will occur in an - entry. LDAP server implementations that do not support attribute - subtyping need not recognize this attribute in requests. Client - implementations MUST NOT assume that LDAP servers are capable of - performing attribute subtyping. - - - -Sciberras Standards Track [Page 7] - -RFC 4519 LDAP: Schema for User Applications June 2006 - - - (Source: X.520 [X.520]) - - ( 2.5.4.49 NAME 'distinguishedName' - EQUALITY distinguishedNameMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) - - 1.3.6.1.4.1.1466.115.121.1.12 refers to the DN syntax [RFC4517]. - -2.8. 'dnQualifier' - - The 'dnQualifier' attribute type contains disambiguating information - strings to add to the relative distinguished name of an entry. The - information is intended for use when merging data from multiple - sources in order to prevent conflicts between entries that would - otherwise have the same name. Each string is one value of this - multi-valued attribute. It is recommended that a value of the - 'dnQualifier' attribute be the same for all entries from a particular - source. - (Source: X.520 [X.520]) - - ( 2.5.4.46 NAME 'dnQualifier' - EQUALITY caseIgnoreMatch - ORDERING caseIgnoreOrderingMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 ) - - 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax - [RFC4517]. - - Examples: "20050322123345Z" - timestamps can be used to disambiguate - information. - "123456A" - serial numbers can be used to disambiguate - information. - -2.9. 'enhancedSearchGuide' - - The 'enhancedSearchGuide' attribute type contains sets of information - for use by directory clients in constructing search filters. Each - set is one value of this multi-valued attribute. - (Source: X.520 [X.520]) - - ( 2.5.4.47 NAME 'enhancedSearchGuide' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 ) - - 1.3.6.1.4.1.1466.115.121.1.21 refers to the Enhanced Guide syntax - [RFC4517]. - - - - - -Sciberras Standards Track [Page 8] - -RFC 4519 LDAP: Schema for User Applications June 2006 - - - Examples: "person#(sn$APPROX)#wholeSubtree" and - "organizationalUnit#(ou$SUBSTR)#oneLevel". - -2.10. 'facsimileTelephoneNumber' - - The 'facsimileTelephoneNumber' attribute type contains telephone - numbers (and, optionally, the parameters) for facsimile terminals. - Each telephone number is one value of this multi-valued attribute. - (Source: X.520 [X.520]) - - ( 2.5.4.23 NAME 'facsimileTelephoneNumber' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 ) - - 1.3.6.1.4.1.1466.115.121.1.22 refers to the Facsimile Telephone - Number syntax [RFC4517]. - - Examples: "+61 3 9896 7801" and "+81 3 347 7418$fineResolution". - -2.11. 'generationQualifier' - - The 'generationQualifier' attribute type contains name strings that - are typically the suffix part of a person's name. Each string is one - value of this multi-valued attribute. - (Source: X.520 [X.520]) - - ( 2.5.4.44 NAME 'generationQualifier' - SUP name ) - - Examples: "III", "3rd", and "Jr.". - -2.12. 'givenName' - - The 'givenName' attribute type contains name strings that are the - part of a person's name that is not their surname. Each string is - one value of this multi-valued attribute. - (Source: X.520 [X.520]) - - ( 2.5.4.42 NAME 'givenName' - SUP name ) - - Examples: "Andrew", "Charles", and "Joanne". - -2.13. 'houseIdentifier' - - The 'houseIdentifier' attribute type contains identifiers for a - building within a location. Each identifier is one value of this - multi-valued attribute. - (Source: X.520 [X.520]) - - - -Sciberras Standards Track [Page 9] - -RFC 4519 LDAP: Schema for User Applications June 2006 - - - ( 2.5.4.51 NAME 'houseIdentifier' - EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) - - 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax - [RFC4517]. - - Example: "20" to represent the house number 20. - -2.14. 'initials' - - The 'initials' attribute type contains strings of initials of some or - all of an individual's names, except the surname(s). Each string is - one value of this multi-valued attribute. - (Source: X.520 [X.520]) - - ( 2.5.4.43 NAME 'initials' - SUP name ) - - Examples: "K. A." and "K". - -2.15. 'internationalISDNNumber' - - The 'internationalISDNNumber' attribute type contains Integrated - Services Digital Network (ISDN) addresses, as defined in the - International Telecommunication Union (ITU) Recommendation E.164 - [E.164]. Each address is one value of this multi-valued attribute. - (Source: X.520 [X.520]) - - ( 2.5.4.25 NAME 'internationalISDNNumber' - EQUALITY numericStringMatch - SUBSTR numericStringSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) - - 1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax - [RFC4517]. - - Example: "0198 333 333". - -2.16. 'l' - - The 'l' ('localityName' in X.500) attribute type contains names of a - locality or place, such as a city, county, or other geographic - region. Each name is one value of this multi-valued attribute. - (Source: X.520 [X.520]) - - - - - -Sciberras Standards Track [Page 10] - -RFC 4519 LDAP: Schema for User Applications June 2006 - - - ( 2.5.4.7 NAME 'l' - SUP name ) - - Examples: "Geneva", "Paris", and "Edinburgh". - -2.17. 'member' - - The 'member' attribute type contains the distinguished names of - objects that are on a list or in a group. Each name is one value of - this multi-valued attribute. - (Source: X.520 [X.520]) - - ( 2.5.4.31 NAME 'member' - SUP distinguishedName ) - - Examples: "cn=James Clarke,ou=Finance,o=Widget\, Inc." and - "cn=John Xerri,ou=Finance,o=Widget\, Inc." may - be two members of the financial team (group) at Widget, - Inc., in which case, both of these distinguished names - would be present as individual values of the member - attribute. - -2.18. 'name' - - The 'name' attribute type is the attribute supertype from which user - attribute types with the name syntax inherit. Such attribute types - are typically used for naming. The attribute type is multi-valued. - - It is unlikely that values of this type itself will occur in an - entry. LDAP server implementations that do not support attribute - subtyping need not recognize this attribute in requests. Client - implementations MUST NOT assume that LDAP servers are capable of - performing attribute subtyping. - (Source: X.520 [X.520]) - - ( 2.5.4.41 NAME 'name' - EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) - - 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax - [RFC4517]. - -2.19. 'o' - - The 'o' ('organizationName' in X.500) attribute type contains the - names of an organization. Each name is one value of this - multi-valued attribute. - - - -Sciberras Standards Track [Page 11] - -RFC 4519 LDAP: Schema for User Applications June 2006 - - - (Source: X.520 [X.520]) - - ( 2.5.4.10 NAME 'o' - SUP name ) - - Examples: "Widget", "Widget, Inc.", and "Widget, Incorporated.". - -2.20. 'ou' - - The 'ou' ('organizationalUnitName' in X.500) attribute type contains - the names of an organizational unit. Each name is one value of this - multi-valued attribute. - (Source: X.520 [X.520]) - - ( 2.5.4.11 NAME 'ou' - SUP name ) - - Examples: "Finance", "Human Resources", and "Research and - Development". - -2.21. 'owner' - - The 'owner' attribute type contains the distinguished names of - objects that have an ownership responsibility for the object that is - owned. Each owner's name is one value of this multi-valued - attribute. - (Source: X.520 [X.520]) - - ( 2.5.4.32 NAME 'owner' - SUP distinguishedName ) - - Example: The mailing list object, whose DN is "cn=All Employees, - ou=Mailing List,o=Widget\, Inc.", is owned by the Human - Resources Director. - - Therefore, the value of the 'owner' attribute within the - mailing list object, would be the DN of the director (role): - "cn=Human Resources Director,ou=employee,o=Widget\, Inc.". - -2.22. 'physicalDeliveryOfficeName' - - The 'physicalDeliveryOfficeName' attribute type contains names that a - Postal Service uses to identify a post office. - (Source: X.520 [X.520]) - - - - - - - -Sciberras Standards Track [Page 12] - -RFC 4519 LDAP: Schema for User Applications June 2006 - - - ( 2.5.4.19 NAME 'physicalDeliveryOfficeName' - EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) - - 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax - [RFC4517]. - - Examples: "Bremerhaven, Main" and "Bremerhaven, Bonnstrasse". - -2.23. 'postalAddress' - - The 'postalAddress' attribute type contains addresses used by a - Postal Service to perform services for the object. Each address is - one value of this multi-valued attribute. - (Source: X.520 [X.520]) - - ( 2.5.4.16 NAME 'postalAddress' - EQUALITY caseIgnoreListMatch - SUBSTR caseIgnoreListSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) - - 1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax - [RFC4517]. - - Example: "15 Main St.$Ottawa$Canada". - -2.24. 'postalCode' - - The 'postalCode' attribute type contains codes used by a Postal - Service to identify postal service zones. Each code is one value of - this multi-valued attribute. - (Source: X.520 [X.520]) - - ( 2.5.4.17 NAME 'postalCode' - EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) - - 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax - [RFC4517]. - - Example: "22180", to identify Vienna, VA, in the USA. - - - - - - - - -Sciberras Standards Track [Page 13] - -RFC 4519 LDAP: Schema for User Applications June 2006 - - -2.25. 'postOfficeBox' - - The 'postOfficeBox' attribute type contains postal box identifiers - that a Postal Service uses when a customer arranges to receive mail - at a box on the premises of the Postal Service. Each postal box - identifier is a single value of this multi-valued attribute. - (Source: X.520 [X.520]) - - ( 2.5.4.18 NAME 'postOfficeBox' - EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) - - 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax - [RFC4517]. - - Example: "Box 45". - -2.26. 'preferredDeliveryMethod' - - The 'preferredDeliveryMethod' attribute type contains an indication - of the preferred method of getting a message to the object. - (Source: X.520 [X.520]) - - ( 2.5.4.28 NAME 'preferredDeliveryMethod' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.14 - SINGLE-VALUE ) - - 1.3.6.1.4.1.1466.115.121.1.14 refers to the Delivery Method syntax - [RFC4517]. - - Example: If the mhs-delivery Delivery Method is preferred over - telephone-delivery, which is preferred over all other - methods, the value would be: "mhs $ telephone". - -2.27. 'registeredAddress' - - The 'registeredAddress' attribute type contains postal addresses - suitable for reception of telegrams or expedited documents, where it - is necessary to have the recipient accept delivery. Each address is - one value of this multi-valued attribute. - (Source: X.520 [X.520]) - - ( 2.5.4.26 NAME 'registeredAddress' - SUP postalAddress - SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) - - - - - -Sciberras Standards Track [Page 14] - -RFC 4519 LDAP: Schema for User Applications June 2006 - - - 1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax - [RFC4517]. - - Example: "Receptionist$Widget, Inc.$15 Main St.$Ottawa$Canada". - -2.28. 'roleOccupant' - - The 'roleOccupant' attribute type contains the distinguished names of - objects (normally people) that fulfill the responsibilities of a role - object. Each distinguished name is one value of this multi-valued - attribute. - (Source: X.520 [X.520]) - - ( 2.5.4.33 NAME 'roleOccupant' - SUP distinguishedName ) - - Example: The role object, "cn=Human Resources - Director,ou=Position,o=Widget\, Inc.", is fulfilled by two - people whose object names are "cn=Mary - Smith,ou=employee,o=Widget\, Inc." and "cn=James - Brown,ou=employee,o=Widget\, Inc.". The 'roleOccupant' - attribute will contain both of these distinguished names, - since they are the occupants of this role. - -2.29. 'searchGuide' - - The 'searchGuide' attribute type contains sets of information for use - by clients in constructing search filters. It is superseded by - 'enhancedSearchGuide', described above in Section 2.9. Each set is - one value of this multi-valued attribute. - (Source: X.520 [X.520]) - - ( 2.5.4.14 NAME 'searchGuide' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 ) - - 1.3.6.1.4.1.1466.115.121.1.25 refers to the Guide syntax [RFC4517]. - - Example: "person#sn$EQ". - -2.30. 'seeAlso' - - The 'seeAlso' attribute type contains the distinguished names of - objects that are related to the subject object. Each related object - name is one value of this multi-valued attribute. - (Source: X.520 [X.520]) - - ( 2.5.4.34 NAME 'seeAlso' - SUP distinguishedName ) - - - -Sciberras Standards Track [Page 15] - -RFC 4519 LDAP: Schema for User Applications June 2006 - - - Example: The person object "cn=James Brown,ou=employee,o=Widget\, - Inc." is related to the role objects "cn=Football Team - Captain,ou=sponsored activities,o=Widget\, Inc." and - "cn=Chess Team,ou=sponsored activities,o=Widget\, Inc.". - Since the role objects are related to the person object, the - 'seeAlso' attribute will contain the distinguished name of - each role object as separate values. - -2.31. 'serialNumber' - - The 'serialNumber' attribute type contains the serial numbers of - devices. Each serial number is one value of this multi-valued - attribute. - (Source: X.520 [X.520]) - - ( 2.5.4.5 NAME 'serialNumber' - EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 ) - - 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax - [RFC4517]. - - Examples: "WI-3005" and "XF551426". - -2.32. 'sn' - - The 'sn' ('surname' in X.500) attribute type contains name strings - for the family names of a person. Each string is one value of this - multi-valued attribute. - (Source: X.520 [X.520]) - - ( 2.5.4.4 NAME 'sn' - SUP name ) - - Example: "Smith". - -2.33. 'st' - - The 'st' ('stateOrProvinceName' in X.500) attribute type contains the - full names of states or provinces. Each name is one value of this - multi-valued attribute. - (Source: X.520 [X.520]) - - ( 2.5.4.8 NAME 'st' - SUP name ) - - Example: "California". - - - -Sciberras Standards Track [Page 16] - -RFC 4519 LDAP: Schema for User Applications June 2006 - - -2.34. 'street' - - The 'street' ('streetAddress' in X.500) attribute type contains site - information from a postal address (i.e., the street name, place, - avenue, and the house number). Each street is one value of this - multi-valued attribute. - (Source: X.520 [X.520]) - - ( 2.5.4.9 NAME 'street' - EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) - - 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax - [RFC4517]. - - Example: "15 Main St.". - -2.35. 'telephoneNumber' - - The 'telephoneNumber' attribute type contains telephone numbers that - comply with the ITU Recommendation E.123 [E.123]. Each number is one - value of this multi-valued attribute. - (Source: X.520 [X.520]) - - ( 2.5.4.20 NAME 'telephoneNumber' - EQUALITY telephoneNumberMatch - SUBSTR telephoneNumberSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) - - 1.3.6.1.4.1.1466.115.121.1.50 refers to the Telephone Number syntax - [RFC4517]. - - Example: "+1 234 567 8901". - -2.36. 'teletexTerminalIdentifier' - - The withdrawal of Recommendation F.200 has resulted in the withdrawal - of this attribute. - (Source: X.520 [X.520]) - - ( 2.5.4.22 NAME 'teletexTerminalIdentifier' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 ) - - 1.3.6.1.4.1.1466.115.121.1.51 refers to the Teletex Terminal - Identifier syntax [RFC4517]. - - - - - -Sciberras Standards Track [Page 17] - -RFC 4519 LDAP: Schema for User Applications June 2006 - - -2.37. 'telexNumber' - - The 'telexNumber' attribute type contains sets of strings that are a - telex number, country code, and answerback code of a telex terminal. - Each set is one value of this multi-valued attribute. - (Source: X.520 [X.520]) - - ( 2.5.4.21 NAME 'telexNumber' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 ) - - 1.3.6.1.4.1.1466.115.121.1.52 refers to the Telex Number syntax - [RFC4517]. - - Example: "12345$023$ABCDE". - -2.38. 'title' - - The 'title' attribute type contains the title of a person in their - organizational context. Each title is one value of this multi-valued - attribute. - (Source: X.520 [X.520]) - - ( 2.5.4.12 NAME 'title' - SUP name ) - Examples: "Vice President", "Software Engineer", and "CEO". - -2.39. 'uid' - - The 'uid' ('userid' in RFC 1274) attribute type contains computer - system login names associated with the object. Each name is one - value of this multi-valued attribute. - (Source: RFC 2798 [RFC2798] and RFC 1274 [RFC1274]) - - ( 0.9.2342.19200300.100.1.1 NAME 'uid' - EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) - - 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax - [RFC4517]. - - Examples: "s9709015", "admin", and "Administrator". - - - - - - - - - -Sciberras Standards Track [Page 18] - -RFC 4519 LDAP: Schema for User Applications June 2006 - - -2.40. 'uniqueMember' - - The 'uniqueMember' attribute type contains the distinguished names of - an object that is on a list or in a group, where the relative - distinguished names of the object include a value that distinguishes - between objects when a distinguished name has been reused. Each - distinguished name is one value of this multi-valued attribute. - (Source: X.520 [X.520]) - - ( 2.5.4.50 NAME 'uniqueMember' - EQUALITY uniqueMemberMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 ) - - 1.3.6.1.4.1.1466.115.121.1.34 refers to the Name and Optional UID - syntax [RFC4517]. - - Example: If "ou=1st Battalion,o=Defense,c=US" is a battalion that was - disbanded, establishing a new battalion with the "same" name - would have a unique identifier value added, resulting in - "ou=1st Battalion, o=Defense,c=US#'010101'B". - -2.41. 'userPassword' - - The 'userPassword' attribute contains octet strings that are known - only to the user and the system to which the user has access. Each - string is one value of this multi-valued attribute. - - The application SHOULD prepare textual strings used as passwords by - transcoding them to Unicode, applying SASLprep [RFC4013], and - encoding as UTF-8. The determination of whether a password is - textual is a local client matter. - (Source: X.509 [X.509]) - - ( 2.5.4.35 NAME 'userPassword' - EQUALITY octetStringMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) - - 1.3.6.1.4.1.1466.115.121.1.40 refers to the Octet String syntax - [RFC4517]. - - Passwords are stored using an Octet String syntax and are not - encrypted. Transfer of cleartext passwords is strongly discouraged - where the underlying transport service cannot guarantee - confidentiality and may result in disclosure of the password to - unauthorized parties. - - An example of a need for multiple values in the 'userPassword' - attribute is an environment where every month the user is expected to - - - -Sciberras Standards Track [Page 19] - -RFC 4519 LDAP: Schema for User Applications June 2006 - - - use a different password generated by some automated system. During - transitional periods, like the last and first day of the periods, it - may be necessary to allow two passwords for the two consecutive - periods to be valid in the system. - -2.42. 'x121Address' - - The 'x121Address' attribute type contains data network addresses as - defined by ITU Recommendation X.121 [X.121]. Each address is one - value of this multi-valued attribute. - (Source: X.520 [X.520]) - - ( 2.5.4.24 NAME 'x121Address' - EQUALITY numericStringMatch - SUBSTR numericStringSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) - - 1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax - [RFC4517]. - - Example: "36111222333444555". - -2.43. 'x500UniqueIdentifier' - - The 'x500UniqueIdentifier' attribute type contains binary strings - that are used to distinguish between objects when a distinguished - name has been reused. Each string is one value of this multi-valued - attribute. - - In X.520 [X.520], this attribute type is called 'uniqueIdentifier'. - This is a different attribute type from both the 'uid' and - 'uniqueIdentifier' LDAP attribute types. The 'uniqueIdentifier' - attribute type is defined in [RFC4524]. - (Source: X.520 [X.520]) - - ( 2.5.4.45 NAME 'x500UniqueIdentifier' - EQUALITY bitStringMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) - - 1.3.6.1.4.1.1466.115.121.1.6 refers to the Bit String syntax - [RFC4517]. - -3. Object Classes - - LDAP servers SHOULD recognize all the Object Classes listed here as - values of the 'objectClass' attribute (see [RFC4512]). - - - - - -Sciberras Standards Track [Page 20] - -RFC 4519 LDAP: Schema for User Applications June 2006 - - -3.1. 'applicationProcess' - - The 'applicationProcess' object class definition is the basis of an - entry that represents an application executing in a computer system. - (Source: X.521 [X.521]) - - ( 2.5.6.11 NAME 'applicationProcess' - SUP top - STRUCTURAL - MUST cn - MAY ( seeAlso $ - ou $ - l $ - description ) ) - -3.2. 'country' - - The 'country' object class definition is the basis of an entry that - represents a country. - (Source: X.521 [X.521]) - - ( 2.5.6.2 NAME 'country' - SUP top - STRUCTURAL - MUST c - MAY ( searchGuide $ - description ) ) - -3.3. 'dcObject' - - The 'dcObject' object class permits an entry to contains domain - component information. This object class is defined as auxiliary, - because it will be used in conjunction with an existing structural - object class. - (Source: RFC 2247 [RFC2247]) - - ( 1.3.6.1.4.1.1466.344 NAME 'dcObject' - SUP top - AUXILIARY - MUST dc ) - -3.4. 'device' - - The 'device' object class is the basis of an entry that represents an - appliance, computer, or network element. - (Source: X.521 [X.521]) - - - - - -Sciberras Standards Track [Page 21] - -RFC 4519 LDAP: Schema for User Applications June 2006 - - - ( 2.5.6.14 NAME 'device' - SUP top - STRUCTURAL - MUST cn - MAY ( serialNumber $ - seeAlso $ - owner $ - ou $ - o $ - l $ - description ) ) - -3.5. 'groupOfNames' - - The 'groupOfNames' object class is the basis of an entry that - represents a set of named objects including information related to - the purpose or maintenance of the set. - (Source: X.521 [X.521]) - - ( 2.5.6.9 NAME 'groupOfNames' - SUP top - STRUCTURAL - MUST ( member $ - cn ) - MAY ( businessCategory $ - seeAlso $ - owner $ - ou $ - o $ - description ) ) - -3.6. 'groupOfUniqueNames' - - The 'groupOfUniqueNames' object class is the same as the - 'groupOfNames' object class except that the object names are not - repeated or reassigned within a set scope. - (Source: X.521 [X.521]) - - - - - - - - - - - - - - -Sciberras Standards Track [Page 22] - -RFC 4519 LDAP: Schema for User Applications June 2006 - - - ( 2.5.6.17 NAME 'groupOfUniqueNames' - SUP top - STRUCTURAL - MUST ( uniqueMember $ - cn ) - MAY ( businessCategory $ - seeAlso $ - owner $ - ou $ - o $ - description ) ) - -3.7. 'locality' - - The 'locality' object class is the basis of an entry that represents - a place in the physical world. - (Source: X.521 [X.521]) - - ( 2.5.6.3 NAME 'locality' - SUP top - STRUCTURAL - MAY ( street $ - seeAlso $ - searchGuide $ - st $ - l $ - description ) ) - -3.8. 'organization' - - The 'organization' object class is the basis of an entry that - represents a structured group of people. - (Source: X.521 [X.521]) - - ( 2.5.6.4 NAME 'organization' - SUP top - STRUCTURAL - MUST o - MAY ( userPassword $ searchGuide $ seeAlso $ - businessCategory $ x121Address $ registeredAddress $ - destinationIndicator $ preferredDeliveryMethod $ - telexNumber $ teletexTerminalIdentifier $ - telephoneNumber $ internationalISDNNumber $ - facsimileTelephoneNumber $ street $ postOfficeBox $ - postalCode $ postalAddress $ physicalDeliveryOfficeName $ - st $ l $ description ) ) - - - - - -Sciberras Standards Track [Page 23] - -RFC 4519 LDAP: Schema for User Applications June 2006 - - -3.9. 'organizationalPerson' - - The 'organizationalPerson' object class is the basis of an entry that - represents a person in relation to an organization. - (Source: X.521 [X.521]) - - ( 2.5.6.7 NAME 'organizationalPerson' - SUP person - STRUCTURAL - MAY ( title $ x121Address $ registeredAddress $ - destinationIndicator $ preferredDeliveryMethod $ - telexNumber $ teletexTerminalIdentifier $ - telephoneNumber $ internationalISDNNumber $ - facsimileTelephoneNumber $ street $ postOfficeBox $ - postalCode $ postalAddress $ physicalDeliveryOfficeName $ - ou $ st $ l ) ) - -3.10. 'organizationalRole' - - The 'organizationalRole' object class is the basis of an entry that - represents a job, function, or position in an organization. - (Source: X.521 [X.521]) - - ( 2.5.6.8 NAME 'organizationalRole' - SUP top - STRUCTURAL - MUST cn - MAY ( x121Address $ registeredAddress $ destinationIndicator $ - preferredDeliveryMethod $ telexNumber $ - teletexTerminalIdentifier $ telephoneNumber $ - internationalISDNNumber $ facsimileTelephoneNumber $ - seeAlso $ roleOccupant $ preferredDeliveryMethod $ - street $ postOfficeBox $ postalCode $ postalAddress $ - physicalDeliveryOfficeName $ ou $ st $ l $ - description ) ) - -3.11. 'organizationalUnit' - - The 'organizationalUnit' object class is the basis of an entry that - represents a piece of an organization. - (Source: X.521 [X.521]) - - - - - - - - - - -Sciberras Standards Track [Page 24] - -RFC 4519 LDAP: Schema for User Applications June 2006 - - - ( 2.5.6.5 NAME 'organizationalUnit' - SUP top - STRUCTURAL - MUST ou - MAY ( businessCategory $ description $ destinationIndicator $ - facsimileTelephoneNumber $ internationalISDNNumber $ l $ - physicalDeliveryOfficeName $ postalAddress $ postalCode $ - postOfficeBox $ preferredDeliveryMethod $ - registeredAddress $ searchGuide $ seeAlso $ st $ street $ - telephoneNumber $ teletexTerminalIdentifier $ - telexNumber $ userPassword $ x121Address ) ) - -3.12 'person' - - The 'person' object class is the basis of an entry that represents a - human being. - (Source: X.521 [X.521]) - - ( 2.5.6.6 NAME 'person' - SUP top - STRUCTURAL - MUST ( sn $ - cn ) - MAY ( userPassword $ - telephoneNumber $ - seeAlso $ description ) ) - -3.13. 'residentialPerson' - - The 'residentialPerson' object class is the basis of an entry that - includes a person's residence in the representation of the person. - (Source: X.521 [X.521]) - - ( 2.5.6.10 NAME 'residentialPerson' - SUP person - STRUCTURAL - MUST l - MAY ( businessCategory $ x121Address $ registeredAddress $ - destinationIndicator $ preferredDeliveryMethod $ - telexNumber $ teletexTerminalIdentifier $ - telephoneNumber $ internationalISDNNumber $ - facsimileTelephoneNumber $ preferredDeliveryMethod $ - street $ postOfficeBox $ postalCode $ postalAddress $ - physicalDeliveryOfficeName $ st $ l ) ) - - - - - - - -Sciberras Standards Track [Page 25] - -RFC 4519 LDAP: Schema for User Applications June 2006 - - -3.14. 'uidObject' - - The 'uidObject' object class permits an entry to contains user - identification information. This object class is defined as - auxiliary, because it will be used in conjunction with an existing - structural object class. - (Source: RFC 2377 [RFC2377]) - - ( 1.3.6.1.1.3.1 NAME 'uidObject' - SUP top - AUXILIARY - MUST uid ) - -4. IANA Considerations - - The Internet Assigned Numbers Authority (IANA) has updated the LDAP - descriptors registry as indicated in the following template: - - Subject: Request for LDAP Descriptor Registration Update - Descriptor (short name): see comments - Object Identifier: see comments - Person & email address to contact for further information: - Andrew Sciberras <andrew.sciberras@eb2bcom.com> - Usage: (A = attribute type, O = Object Class) see comment - Specification: RFC 4519 - Author/Change Controller: IESG - - Comments - - In the LDAP descriptors registry, the following descriptors (short - names) have been updated to refer to RFC 4519. Names that need to - be reserved, rather than assigned to an Object Identifier, will - contain an Object Identifier value of RESERVED. - - NAME Type OID - ------------------------ ---- ---------------------------- - applicationProcess O 2.5.6.11 - businessCategory A 2.5.4.15 - c A 2.5.4.6 - cn A 2.5.4.3 - commonName A 2.5.4.3 - country O 2.5.6.2 - countryName A 2.5.4.6 - dc A 0.9.2342.19200300.100.1.25 - dcObject O 1.3.6.1.4.1.1466.344 - description A 2.5.4.13 - destinationIndicator A 2.5.4.27 - device O 2.5.6.14 - - - -Sciberras Standards Track [Page 26] - -RFC 4519 LDAP: Schema for User Applications June 2006 - - - NAME Type OID - ------------------------ ---- ---------------------------- - distinguishedName A 2.5.4.49 - dnQualifier A 2.5.4.46 - domainComponent A 0.9.2342.19200300.100.1.25 - enhancedSearchGuide A 2.5.4.47 - facsimileTelephoneNumber A 2.5.4.23 - generationQualifier A 2.5.4.44 - givenName A 2.5.4.42 - gn A RESERVED - groupOfNames O 2.5.6.9 - groupOfUniqueNames O 2.5.6.17 - houseIdentifier A 2.5.4.51 - initials A 2.5.4.43 - internationalISDNNumber A 2.5.4.25 - l A 2.5.4.7 - locality O 2.5.6.3 - localityName A 2.5.4.7 - member A 2.5.4.31 - name A 2.5.4.41 - o A 2.5.4.10 - organization O 2.5.6.4 - organizationName A 2.5.4.10 - organizationalPerson O 2.5.6.7 - organizationalRole O 2.5.6.8 - organizationalUnit O 2.5.6.5 - organizationalUnitName A 2.5.4.11 - ou A 2.5.4.11 - owner A 2.5.4.32 - person O 2.5.6.6 - physicalDeliveryOfficeName A 2.5.4.19 - postalAddress A 2.5.4.16 - postalCode A 2.5.4.17 - postOfficeBox A 2.5.4.18 - preferredDeliveryMethod A 2.5.4.28 - registeredAddress A 2.5.4.26 - residentialPerson O 2.5.6.10 - roleOccupant A 2.5.4.33 - searchGuide A 2.5.4.14 - seeAlso A 2.5.4.34 - serialNumber A 2.5.4.5 - sn A 2.5.4.4 - st A 2.5.4.8 - street A 2.5.4.9 - surname A 2.5.4.4 - telephoneNumber A 2.5.4.20 - teletexTerminalIdentifier A 2.5.4.22 - telexNumber A 2.5.4.21 - - - -Sciberras Standards Track [Page 27] - -RFC 4519 LDAP: Schema for User Applications June 2006 - - - NAME Type OID - ------------------------ ---- ---------------------------- - title A 2.5.4.12 - uid A 0.9.2342.19200300.100.1.1 - uidObject O 1.3.6.1.1.3.1 - uniqueMember A 2.5.4.50 - userid A 0.9.2342.19200300.100.1.1 - userPassword A 2.5.4.35 - x121Address A 2.5.4.24 - x500UniqueIdentifier A 2.5.4.45 - -5. Security Considerations - - Attributes of directory entries are used to provide descriptive - information about the real-world objects they represent, which can be - people, organizations, or devices. Most countries have privacy laws - regarding the publication of information about people. - - Transfer of cleartext passwords is strongly discouraged where the - underlying transport service cannot guarantee confidentiality and - integrity, since this may result in disclosure of the password to - unauthorized parties. - - Multiple attribute values for the 'userPassword' attribute need to be - used with care. Especially reset/deletion of a password by an - administrator without knowing the old user password gets tricky or - impossible if multiple values for different applications are present. - - Certainly, applications that intend to replace the 'userPassword' - value(s) with new value(s) should use modify/replaceValues (or - modify/deleteAttribute+addAttribute). In addition, server - implementations are encouraged to provide administrative controls - that, if enabled, restrict the 'userPassword' attribute to one value. - - Note that when used for authentication purposes [RFC4513], the user - need only prove knowledge of one of the values, not all of the - values. - -6. Acknowledgements - - The definitions, on which this document is based, have been developed - by committees for telecommunications and international standards. - - This document is an update of RFC 2256 by Mark Wahl. RFC 2256 was a - product of the IETF ASID Working Group. - - - - - - -Sciberras Standards Track [Page 28] - -RFC 4519 LDAP: Schema for User Applications June 2006 - - - The 'dc' attribute type definition and the 'dcObject' object class - definition in this document supersede the specification in RFC 2247 - by S. Kille, M. Wahl, A. Grimstad, R. Huber, and S. Sataluri. - - The 'uid' attribute type definition in this document supersedes the - specification of the 'userid' in RFC 1274 by P. Barker and S. Kille - and of the uid in RFC 2798 by M. Smith. - - The 'uidObject' object class definition in this document supersedes - the specification of the 'uidObject' in RFC 2377 by A. Grimstad, R. - Huber, S. Sataluri, and M. Wahl. - - This document is based upon input of the IETF LDAPBIS working group. - The author wishes to thank S. Legg and K. Zeilenga for their - significant contribution to this update. The author would also like - to thank Kathy Dally, who edited early versions of this document. - -7. References - -7.1. Normative References - - [E.123] Notation for national and international telephone numbers, - ITU-T Recommendation E.123, 1988 - - [E.164] The international public telecommunication numbering plan, - ITU-T Recommendation E.164, 1997 - - [F.1] Operational Provisions For The International Public - Telegram Service Transmission System, CCITT Recommendation - F.1, 1992 - - [F.31] Telegram Retransmission System, CCITT Recommendation F.31, - 1988 - - [ISO3166] ISO 3166, "Codes for the representation of names of - countries". - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC1123] Braden, R., "Requirements for Internet Hosts - Application - and Support", STD 3, RFC 1123, October 1989. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - - -Sciberras Standards Track [Page 29] - -RFC 4519 LDAP: Schema for User Applications June 2006 - - - [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, - "Internationalizing Domain Names in Applications (IDNA)", - RFC 3490, March 2003. - - [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names - and Passwords", RFC 4013, February 2005. - - [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 4234, October 2005. - - [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol - (LDAP): Technical Specification Road Map", RFC 4510, June - 2006. - - [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP): Directory Information Models", RFC 4512, June - 2006. - - [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol - (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006. - - [X.121] International numbering plan for public data networks, - ITU-T Recommendation X.121, 1996 - - [X.509] The Directory: Authentication Framework, ITU-T - Recommendation X.509, 1993 - - [X.520] The Directory: Selected Attribute Types, ITU-T - Recommendation X.520, 1993 - - [X.521] The Directory: Selected Object Classes. ITU-T - Recommendation X.521, 1993 - -7.2. Informative References - - [RFC1274] Barker, P. and S. Kille, "The COSINE and Internet X.500 - Schema", RFC 1274, November 1991. - - [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. - Sataluri, "Using Domains in LDAP/X.500 Distinguished - Names", RFC 2247, January 1998. - - [RFC2377] Grimstad, A., Huber, R., Sataluri, S., and M. Wahl, - "Naming Plan for Internet Directory-Enabled Applications", - RFC 2377, September 1998. - - [RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object - Class", RFC 2798, April 2000. - - - -Sciberras Standards Track [Page 30] - -RFC 4519 LDAP: Schema for User Applications June 2006 - - - [RFC4513] Harrison R., Ed., "Lightweight Directory Access Protocol - (LDAP): Authentication Methods and Security Mechanisms", - RFC 4513, June 2006. - - [RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP) Schema Definitions for X.509 Certificates", RFC - 4523, June 2006. - - [RFC4524] Zeilenga, E., Ed., "COSINE LDAP/X.500 Schema", RFC 4524, - June 2006. - - [X.500] ITU-T Recommendations X.500 (1993) | ISO/IEC 9594-1:1994, - Information Technology - Open Systems Interconnection - - The Directory: Overview of concepts, models and services. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Sciberras Standards Track [Page 31] - -RFC 4519 LDAP: Schema for User Applications June 2006 - - -Appendix A. Changes Made Since RFC 2256 - - This appendix lists the changes that have been made from RFC 2256 to - RFC 4519. - - This appendix is not a normative part of this specification, which - has been provided for informational purposes only. - - 1. Replaced the document title. - - 2. Removed the IESG Note. - - 3. Dependencies on RFC 1274 have been eliminated. - - 4. Added a Security Considerations section and an IANA - Considerations section. - - 5. Deleted the conformance requirement for subschema object - classes in favor of a statement in [RFC4517]. - - 6. Added explanation to attribute types and to each object class. - - 7. Removed Section 4, Syntaxes, and Section 6, Matching Rules, - (moved to [RFC4517]). - - 8. Removed the certificate-related attribute types: - authorityRevocationList, cACertificate, - certificateRevocationList, crossCertificatePair, - deltaRevocationList, supportedAlgorithms, and userCertificate. - - Removed the certificate-related Object Classes: - certificationAuthority, certificationAuthority-V2, - cRLDistributionPoint, strongAuthenticationUser, and - userSecurityInformation - - LDAP PKI is now discussed in [RFC4523]. - - 9. Removed the dmdName, knowledgeInformation, - presentationAddress, protocolInformation, and - supportedApplicationContext attribute types and the dmd, - applicationEntity, and dSA object classes. - - 10. Deleted the aliasedObjectName and objectClass attribute type - definitions. Deleted the alias and top object class - definitions. They are included in [RFC4512]. - - - - - - -Sciberras Standards Track [Page 32] - -RFC 4519 LDAP: Schema for User Applications June 2006 - - - 11. Added the 'dc' attribute type from RFC 2247, making the - distinction between 'stored' and 'query' values when preparing - IDN strings. - - 12. Numerous editorial changes. - - 13. Removed upper bound after the SYNTAX oid in all attribute - definitions where it appeared. - - 14. Added text about Unicode, SASLprep [RFC4013], and UTF-8 for - userPassword. - - 15. Included definitions, comments and references for 'dcObject' - and 'uidObject'. - - 16. Replaced PKI schema references to use RFC 4523. - - 17. Spelt out and referenced ABNF on first usage. - - 18. Removed Section 2.4 (Source). Replaced the source table with - explicit references for each definition. - - 19. All references to an attribute type or object class are - enclosed in single quotes. - - 20. The layout of attribute type definitions has been changed to - provide consistency throughout the document: - > Section Heading - > Description of Attribute type - > Multivalued description - > Source Information - > Definition - > Example - > Additional Comments - - Adding this consistent output included the addition of - examples to some definitions. - - 21. References to alternate names for attributes types are - provided with a reference to where they were originally - specified. - - 22. Clarification of the description of 'distinguishedName' and - 'name', in regards to these attribute types being supertypes. - - 23. Spelt out ISDN on first usage. - - - - - -Sciberras Standards Track [Page 33] - -RFC 4519 LDAP: Schema for User Applications June 2006 - - - 24. Inserted a reference to [RFC4517] for the - 'teletexTerminalIdentifier' definition's SYNTAX OID. - - 25. Additional names were added to the IANA Considerations. Names - include 'commonName', 'dcObject', 'domainComponent', 'GN', - 'localityName', 'organizationName', 'organizationUnitName', - 'surname', 'uidObject' and 'userid'. - - 26. Renamed all instances of supercede to supersede. - - 27. Moved [F.1], [F.31] and [RFC4013] from informative to - normative references. - - 28. Changed the 'c' definition to be consistent with X.500. - -Author's Address - - Andrew Sciberras - eB2Bcom - Suite 3, Woodhouse Corporate Centre, - 935 Station Street, - Box Hill North, Victoria 3129 - AUSTRALIA - - Phone: +61 3 9896 7833 - EMail: andrew.sciberras@eb2bcom.com - - - - - - - - - - - - - - - - - - - - - - - - - -Sciberras Standards Track [Page 34] - -RFC 4519 LDAP: Schema for User Applications June 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Sciberras Standards Track [Page 35] - diff --git a/source4/ldap_server/devdocs/rfc4520.txt b/source4/ldap_server/devdocs/rfc4520.txt deleted file mode 100644 index 9ef5daadea..0000000000 --- a/source4/ldap_server/devdocs/rfc4520.txt +++ /dev/null @@ -1,1067 +0,0 @@ - - - - - - -Network Working Group K. Zeilenga -Request for Comments: 4520 OpenLDAP Foundation -BCP: 64 June 2006 -Obsoletes: 3383 -Category: Best Current Practice - - - Internet Assigned Numbers Authority (IANA) Considerations for - the Lightweight Directory Access Protocol (LDAP) - -Status of This Memo - - This document specifies an Internet Best Current Practices for the - Internet Community, and requests discussion and suggestions for - improvements. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document provides procedures for registering extensible elements - of the Lightweight Directory Access Protocol (LDAP). The document - also provides guidelines to the Internet Assigned Numbers Authority - (IANA) describing conditions under which new values can be assigned. - -1. Introduction - - The Lightweight Directory Access Protocol [RFC4510] (LDAP) is an - extensible protocol. LDAP supports: - - - the addition of new operations, - - the extension of existing operations, and - - the extensible schema. - - This document details procedures for registering values used to - unambiguously identify extensible elements of the protocol, including - the following: - - - LDAP message types - - LDAP extended operations and controls - - LDAP result codes - - LDAP authentication methods - - LDAP attribute description options - - Object Identifier descriptors - - - - - -Zeilenga Best Current Practice [Page 1] - -RFC 4520 IANA Considerations for LDAP June 2006 - - - These registries are maintained by the Internet Assigned Numbers - Authority (IANA). - - In addition, this document provides guidelines to IANA describing the - conditions under which new values can be assigned. - - This document replaces RFC 3383. - -2. Terminology and Conventions - - This section details terms and conventions used in this document. - -2.1. Policy Terminology - - The terms "IESG Approval", "Standards Action", "IETF Consensus", - "Specification Required", "First Come First Served", "Expert Review", - and "Private Use" are used as defined in BCP 26 [RFC2434]. - - The term "registration owner" (or "owner") refers to the party - authorized to change a value's registration. - -2.2. Requirement Terminology - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in BCP 14 [RFC2119]. In - this case, "the specification", as used by BCP 14, refers to the - processing of protocols being submitted to the IETF standards - process. - -2.3. Common ABNF Productions - - A number of syntaxes in this document are described using ABNF - [RFC4234]. These syntaxes rely on the following common productions: - - ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z" - LDIGIT = %x31-39 ; "1"-"9" - DIGIT = %x30 / LDIGIT ; "0"-"9" - HYPHEN = %x2D ; "-" - DOT = %x2E ; "." - number = DIGIT / ( LDIGIT 1*DIGIT ) - keychar = ALPHA / DIGIT / HYPHEN - leadkeychar = ALPHA - keystring = leadkeychar *keychar - keyword = keystring - - Keywords are case insensitive. - - - - -Zeilenga Best Current Practice [Page 2] - -RFC 4520 IANA Considerations for LDAP June 2006 - - -3. IANA Considerations for LDAP - - This section details each kind of protocol value that can be - registered and provides IANA guidelines on how to assign new values. - - IANA may reject obviously bogus registrations. - - LDAP values specified in RFCs MUST be registered. Other LDAP values, - except those in private-use name spaces, SHOULD be registered. RFCs - SHOULD NOT reference, use, or otherwise recognize unregistered LDAP - values. - -3.1. Object Identifiers - - Numerous LDAP schema and protocol elements are identified by Object - Identifiers (OIDs) [X.680]. Specifications that assign OIDs to - elements SHOULD state who delegated the OIDs for their use. - - For IETF-developed elements, specifications SHOULD use OIDs under - "Internet Directory Numbers" (1.3.6.1.1.x). For elements developed - by others, any properly delegated OID can be used, including those - under "Internet Directory Numbers" (1.3.6.1.1.x) or "Internet Private - Enterprise Numbers" (1.3.6.1.4.1.x). - - Internet Directory Numbers (1.3.6.1.1.x) will be assigned upon Expert - Review with Specification Required. Only one OID per specification - will be assigned. The specification MAY then assign any number of - OIDs within this arc without further coordination with IANA. - - Internet Private Enterprise Numbers (1.3.6.1.4.1.x) are assigned by - IANA <http://www.iana.org/cgi-bin/enterprise.pl>. Practices for IANA - assignment of Internet Private Enterprise Numbers are detailed in RFC - 2578 [RFC2578]. - - To avoid interoperability problems between early implementations of a - "work in progress" and implementations of the published specification - (e.g., the RFC), experimental OIDs SHOULD be used in "works in - progress" and early implementations. OIDs under the Internet - Experimental OID arc (1.3.6.1.3.x) may be used for this purpose. - Practices for IANA assignment of these Internet Experimental numbers - are detailed in RFC 2578 [RFC2578]. - -3.2. Protocol Mechanisms - - LDAP provides a number of Root DSA-Specific Entry (DSE) attributes - for discovery of protocol mechanisms identified by OIDs, including - the supportedControl, supportedExtension, and supportedFeatures - attributes [RFC4512]. - - - -Zeilenga Best Current Practice [Page 3] - -RFC 4520 IANA Considerations for LDAP June 2006 - - - A registry of OIDs used for discovery of protocol mechanisms is - provided to allow implementors and others to locate the technical - specification for these protocol mechanisms. Future specifications - of additional Root DSE attributes holding values identifying protocol - mechanisms MAY extend this registry for their values. - - Protocol mechanisms are registered on a First Come First Served - basis. - -3.3. LDAP Syntaxes - - This registry provides a listing of LDAP syntaxes [RFC4512]. Each - LDAP syntax is identified by an OID. This registry is provided to - allow implementors and others to locate the technical specification - describing a particular LDAP Syntax. - - LDAP Syntaxes are registered on a First Come First Served with - Specification Required basis. - - Note: Unlike object classes, attribute types, and various other kinds - of schema elements, descriptors are not used in LDAP to - identify LDAP Syntaxes. - -3.4. Object Identifier Descriptors - - LDAP allows short descriptive names (or descriptors) to be used - instead of a numeric Object Identifier to identify select protocol - extensions [RFC4511], schema elements [RFC4512], LDAP URL [RFC4516] - extensions, and other objects. - - Although the protocol allows the same descriptor to refer to - different object identifiers in certain cases and the registry - supports multiple registrations of the same descriptor (each - indicating a different kind of schema element and different object - identifier), multiple registrations of the same descriptor are to be - avoided. All such multiple registration requests require Expert - Review. - - Descriptors are restricted to strings of UTF-8 [RFC3629] encoded - Unicode characters restricted by the following ABNF: - - name = keystring - - Descriptors are case insensitive. - - Multiple names may be assigned to a given OID. For purposes of - registration, an OID is to be represented in numeric OID form (e.g., - 1.1.0.23.40) conforming to the following ABNF: - - - -Zeilenga Best Current Practice [Page 4] - -RFC 4520 IANA Considerations for LDAP June 2006 - - - numericoid = number 1*( DOT number ) - - While the protocol places no maximum length restriction upon - descriptors, they should be short. Descriptors longer than 48 - characters may be viewed as too long to register. - - A value ending with a hyphen ("-") reserves all descriptors that - start with that value. For example, the registration of the option - "descrFamily-" reserves all options that start with "descrFamily-" - for some related purpose. - - Descriptors beginning with "x-" are for Private Use and cannot be - registered. - - Descriptors beginning with "e-" are reserved for experiments and will - be registered on a First Come First Served basis. - - All other descriptors require Expert Review to be registered. - - The registrant need not "own" the OID being named. - - The OID name space is managed by the ISO/IEC Joint Technical - Committee 1 - Subcommittee 6. - -3.5. AttributeDescription Options - - An AttributeDescription [RFC4512] can contain zero or more options - specifying additional semantics. An option SHALL be restricted to a - string of UTF-8 encoded Unicode characters limited by the following - ABNF: - - option = keystring - - Options are case insensitive. - - While the protocol places no maximum length restriction upon option - strings, they should be short. Options longer than 24 characters may - be viewed as too long to register. - - Values ending with a hyphen ("-") reserve all option names that start - with the name. For example, the registration of the option - "optionFamily-" reserves all options that start with "optionFamily-" - for some related purpose. - - Options beginning with "x-" are for Private Use and cannot be - registered. - - - - - -Zeilenga Best Current Practice [Page 5] - -RFC 4520 IANA Considerations for LDAP June 2006 - - - Options beginning with "e-" are reserved for experiments and will be - registered on a First Come First Served basis. - - All other options require Standards Action or Expert Review with - Specification Required to be registered. - -3.6. LDAP Message Types - - Each protocol message is encapsulated in an LDAPMessage envelope - [RFC4511. The protocolOp CHOICE indicates the type of message - encapsulated. Each message type consists of an ASN.1 identifier in - the form of a keyword and a non-negative choice number. The choice - number is combined with the class (APPLICATION) and data type - (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the message's - encoding. The choice numbers for existing protocol messages are - implicit in the protocol's ASN.1 defined in [RFC4511]. - - New values will be registered upon Standards Action. - - Note: LDAP provides extensible messages that reduce but do not - eliminate the need to add new message types. - -3.7. LDAP Authentication Method - - The LDAP Bind operation supports multiple authentication methods - [RFC4511]. Each authentication choice consists of an ASN.1 - identifier in the form of a keyword and a non-negative integer. - - The registrant SHALL classify the authentication method usage using - one of the following terms: - - COMMON - method is appropriate for common use on the - Internet. - LIMITED USE - method is appropriate for limited use. - OBSOLETE - method has been deprecated or otherwise found to - be inappropriate for any use. - - Methods without publicly available specifications SHALL NOT be - classified as COMMON. New registrations of the class OBSOLETE cannot - be registered. - - New authentication method integers in the range 0-1023 require - Standards Action to be registered. New authentication method - integers in the range 1024-4095 require Expert Review with - Specification Required. New authentication method integers in the - range 4096-16383 will be registered on a First Come First Served - basis. Keywords associated with integers in the range 0-4095 SHALL - NOT start with "e-" or "x-". Keywords associated with integers in - - - -Zeilenga Best Current Practice [Page 6] - -RFC 4520 IANA Considerations for LDAP June 2006 - - - the range 4096-16383 SHALL start with "e-". Values greater than or - equal to 16384 and keywords starting with "x-" are for Private Use - and cannot be registered. - - Note: LDAP supports Simple Authentication and Security Layers - [RFC4422] as an authentication choice. SASL is an extensible - authentication framework. - -3.8. LDAP Result Codes - - LDAP result messages carry a resultCode enumerated value to indicate - the outcome of the operation [RFC4511]. Each result code consists of - an ASN.1 identifier in the form of a keyword and a non-negative - integer. - - New resultCodes integers in the range 0-1023 require Standards Action - to be registered. New resultCode integers in the range 1024-4095 - require Expert Review with Specification Required. New resultCode - integers in the range 4096-16383 will be registered on a First Come - First Served basis. Keywords associated with integers in the range - 0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with - integers in the range 4096-16383 SHALL start with "e-". Values - greater than or equal to 16384 and keywords starting with "x-" are - for Private Use and cannot be registered. - -3.9. LDAP Search Scope - - LDAP SearchRequest messages carry a scope-enumerated value to - indicate the extent of search within the DIT [RFC4511]. Each search - value consists of an ASN.1 identifier in the form of a keyword and a - non-negative integer. - - New scope integers in the range 0-1023 require Standards Action to be - registered. New scope integers in the range 1024-4095 require Expert - Review with Specification Required. New scope integers in the range - 4096-16383 will be registered on a First Come First Served basis. - Keywords associated with integers in the range 0-4095 SHALL NOT start - with "e-" or "x-". Keywords associated with integers in the range - 4096-16383 SHALL start with "e-". Values greater than or equal to - 16384 and keywords starting with "x-" are for Private Use and cannot - be registered. - -3.10. LDAP Filter Choice - - LDAP filters are used in making assertions against an object - represented in the directory [RFC4511]. The Filter CHOICE indicates - a type of assertion. Each Filter CHOICE consists of an ASN.1 - identifier in the form of a keyword and a non-negative choice number. - - - -Zeilenga Best Current Practice [Page 7] - -RFC 4520 IANA Considerations for LDAP June 2006 - - - The choice number is combined with the class (APPLICATION) and data - type (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the - message's encoding. - - Note: LDAP provides the extensibleMatching choice, which reduces but - does not eliminate the need to add new filter choices. - -3.11. LDAP ModifyRequest Operation Type - - The LDAP ModifyRequest carries a sequence of modification operations - [RFC4511]. Each kind (e.g., add, delete, replace) of operation - consists of an ASN.1 identifier in the form of a keyword and a non- - negative integer. - - New operation type integers in the range 0-1023 require Standards - Action to be registered. New operation type integers in the range - 1024-4095 require Expert Review with Specification Required. New - operation type integers in the range 4096-16383 will be registered on - a First Come First Served basis. Keywords associated with integers - in the range 0-4095 SHALL NOT start with "e-" or "x-". Keywords - associated with integers in the range 4096-16383 SHALL start with - "e-". Values greater than or equal to 16384 and keywords starting - with "x-" are for Private Use and cannot be registered. - -3.12. LDAP authzId Prefixes - - Authorization Identities in LDAP are strings conforming to the - <authzId> production [RFC4513]. This production is extensible. Each - new specific authorization form is identified by a prefix string - conforming to the following ABNF: - - prefix = keystring COLON - COLON = %x3A ; COLON (":" U+003A) - - Prefixes are case insensitive. - - While the protocol places no maximum length restriction upon prefix - strings, they should be short. Prefixes longer than 12 characters - may be viewed as too long to register. - - Prefixes beginning with "x-" are for Private Use and cannot be - registered. - - Prefixes beginning with "e-" are reserved for experiments and will be - registered on a First Come First Served basis. - - All other prefixes require Standards Action or Expert Review with - Specification Required to be registered. - - - -Zeilenga Best Current Practice [Page 8] - -RFC 4520 IANA Considerations for LDAP June 2006 - - -3.13. Directory Systems Names - - The IANA-maintained "Directory Systems Names" registry [IANADSN] of - valid keywords for well-known attributes was used in the LDAPv2 - string representation of a distinguished name [RFC1779]. LDAPv2 is - now Historic [RFC3494]. - - Directory systems names are not known to be used in any other - context. LDAPv3 [RFC4514] uses Object Identifier Descriptors - [Section 3.2] (which have a different syntax than directory system - names). - - New Directory System Names will no longer be accepted. For - historical purposes, the current list of registered names should - remain publicly available. - -4. Registration Procedure - - The procedure given here MUST be used by anyone who wishes to use a - new value of a type described in Section 3 of this document. - - The first step is for the requester to fill out the appropriate form. - Templates are provided in Appendix A. - - If the policy is Standards Action, the completed form SHOULD be - provided to the IESG with the request for Standards Action. Upon - approval of the Standards Action, the IESG SHALL forward the request - (possibly revised) to IANA. The IESG SHALL be regarded as the - registration owner of all values requiring Standards Action. - - If the policy is Expert Review, the requester SHALL post the - completed form to the <directory@apps.ietf.org> mailing list for - public review. The review period is two (2) weeks. If a revised - form is later submitted, the review period is restarted. Anyone may - subscribe to this list by sending a request to <directory- - request@apps.ietf.org>. During the review, objections may be raised - by anyone (including the Expert) on the list. After completion of - the review, the Expert, based on public comments, SHALL either - approve the request and forward it to the IANA OR deny the request. - In either case, the Expert SHALL promptly notify the requester of the - action. Actions of the Expert may be appealed [RFC2026]. The Expert - is appointed by Applications Area Directors. The requester is viewed - as the registration owner of values registered under Expert Review. - - If the policy is First Come First Served, the requester SHALL submit - the completed form directly to the IANA: <iana@iana.org>. The - requester is viewed as the registration owner of values registered - under First Come First Served. - - - -Zeilenga Best Current Practice [Page 9] - -RFC 4520 IANA Considerations for LDAP June 2006 - - - Neither the Expert nor IANA will take position on the claims of - copyright or trademark issues regarding completed forms. - - Prior to submission of the Internet Draft (I-D) to the RFC Editor but - after IESG review and tentative approval, the document editor SHOULD - revise the I-D to use registered values. - -5. Registration Maintenance - - This section discusses maintenance of registrations. - -5.1. Lists of Registered Values - - IANA makes lists of registered values readily available to the - Internet community on its web site: <http://www.iana.org/>. - -5.2. Change Control - - The registration owner MAY update the registration subject to the - same constraints and review as with new registrations. In cases - where the registration owner is unable or is unwilling to make - necessary updates, the IESG MAY assume ownership of the registration - in order to update the registration. - -5.3. Comments - - For cases where others (anyone other than the registration owner) - have significant objections to the claims in a registration and the - registration owner does not agree to change the registration, - comments MAY be attached to a registration upon Expert Review. For - registrations owned by the IESG, the objections SHOULD be addressed - by initiating a request for Expert Review. - - The form of these requests is ad hoc, but MUST include the specific - objections to be reviewed and SHOULD contain (directly or by - reference) materials supporting the objections. - -6. Security Considerations - - The security considerations detailed in BCP 26 [RFC2434] are - generally applicable to this document. Additional security - considerations specific to each name space are discussed in Section - 3, where appropriate. - - Security considerations for LDAP are discussed in documents - comprising the technical specification [RFC4510]. - - - - - -Zeilenga Best Current Practice [Page 10] - -RFC 4520 IANA Considerations for LDAP June 2006 - - -7. Acknowledgement - - This document is a product of the IETF LDAP Revision (LDAPBIS) - Working Group (WG). This document is a revision of RFC 3383, also a - product of the LDAPBIS WG. - - This document includes text borrowed from "Guidelines for Writing an - IANA Considerations Section in RFCs" [RFC2434] by Thomas Narten and - Harald Alvestrand. - -8. References - -8.1. Normative References - - [RFC2026] Bradner, S., "The Internet Standards Process -- Revision - 3", BCP 9, RFC 2026, October 1996. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26, RFC 2434, - October 1998. - - [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, - "Structure of Management Information Version 2 (SMIv2)", - STD 58, RFC 2578, April 1999. - - [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO - 10646", STD 63, RFC 3629, November 2003. - - [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 4234, October 2005. - - [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol - (LDAP): Technical Specification Road Map", RFC 4510, June - 2006. - - [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access - Protocol (LDAP): The Protocol", RFC 4511, June 2006. - - [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP): Directory Information Models", RFC 4512, June - 2006. - - [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol - (LDAP): Authentication Methods and Security Mechanisms", - RFC 4513, June 2006. - - - -Zeilenga Best Current Practice [Page 11] - -RFC 4520 IANA Considerations for LDAP June 2006 - - - [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory Access - Protocol (LDAP): Uniform Resource Locator", RFC 4516, June - 2006. - - [Unicode] The Unicode Consortium, "The Unicode Standard, Version - 3.2.0" is defined by "The Unicode Standard, Version 3.0" - (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), - as amended by the "Unicode Standard Annex #27: Unicode - 3.1" (http://www.unicode.org/reports/tr27/) and by the - "Unicode Standard Annex #28: Unicode 3.2" - (http://www.unicode.org/reports/tr28/). - - [X.680] International Telecommunication Union - Telecommunication - Standardization Sector, "Abstract Syntax Notation One - (ASN.1) - Specification of Basic Notation", X.680(2002) - (also ISO/IEC 8824-1:2002). - -8.2. Informative References - - [RFC1779] Kille, S., "A String Representation of Distinguished - Names", RFC 1779, March 1995. - - [RFC3494] Zeilenga, K.,"Lightweight Directory Access Protocol - version 2 (LDAPv2) to Historic Status", RFC 3494, March - 2003. - - [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol - (LDAP): String Representation of Distinguished Names", RFC - 4514, June 2006. - - [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple - Authentication and Security Layer (SASL)", RFC 4422, June - 2006. - - [IANADSN] IANA, "Directory Systems Names", - http://www.iana.org/assignments/directory-system-names. - - - - - - - - - - - - - - - -Zeilenga Best Current Practice [Page 12] - -RFC 4520 IANA Considerations for LDAP June 2006 - - -Appendix A. Registration Templates - - This appendix provides registration templates for registering new - LDAP values. Note that more than one value may be requested by - extending the template by listing multiple values, or through use of - tables. - -A.1. LDAP Object Identifier Registration Template - - Subject: Request for LDAP OID Registration - - Person & email address to contact for further information: - - Specification: (I-D) - - Author/Change Controller: - - Comments: - - (Any comments that the requester deems relevant to the request.) - -A.2. LDAP Protocol Mechanism Registration Template - - Subject: Request for LDAP Protocol Mechanism Registration - - Object Identifier: - - Description: - - Person & email address to contact for further information: - - Usage: (One of Control or Extension or Feature or other) - - Specification: (RFC, I-D, URI) - - Author/Change Controller: - - Comments: - - (Any comments that the requester deems relevant to the request.) - - - - - - - - - - - -Zeilenga Best Current Practice [Page 13] - -RFC 4520 IANA Considerations for LDAP June 2006 - - -A.3. LDAP Syntax Registration Template - - Subject: Request for LDAP Syntax Registration - - Object Identifier: - - Description: - - Person & email address to contact for further information: - - Specification: (RFC, I-D, URI) - - Author/Change Controller: - - Comments: - - (Any comments that the requester deems relevant to the request.) - -A.4. LDAP Descriptor Registration Template - - Subject: Request for LDAP Descriptor Registration - - Descriptor (short name): - - Object Identifier: - - Person & email address to contact for further information: - - Usage: (One of administrative role, attribute type, matching rule, - name form, object class, URL extension, or other) - - Specification: (RFC, I-D, URI) - - Author/Change Controller: - - Comments: - - (Any comments that the requester deems relevant to the request.) - - - - - - - - - - - - - -Zeilenga Best Current Practice [Page 14] - -RFC 4520 IANA Considerations for LDAP June 2006 - - -A.5. LDAP Attribute Description Option Registration Template - - Subject: Request for LDAP Attribute Description Option Registration - Option Name: - - Family of Options: (YES or NO) - - Person & email address to contact for further information: - - Specification: (RFC, I-D, URI) - - Author/Change Controller: - - Comments: - - (Any comments that the requester deems relevant to the request.) - -A.6. LDAP Message Type Registration Template - - Subject: Request for LDAP Message Type Registration - - LDAP Message Name: - - Person & email address to contact for further information: - - Specification: (Approved I-D) - - Comments: - - (Any comments that the requester deems relevant to the request.) - -A.7. LDAP Authentication Method Registration Template - - Subject: Request for LDAP Authentication Method Registration - - Authentication Method Name: - - Person & email address to contact for further information: - - Specification: (RFC, I-D, URI) - - Intended Usage: (One of COMMON, LIMITED-USE, OBSOLETE) - - Author/Change Controller: - - Comments: - - (Any comments that the requester deems relevant to the request.) - - - -Zeilenga Best Current Practice [Page 15] - -RFC 4520 IANA Considerations for LDAP June 2006 - - -A.8. LDAP Result Code Registration Template - - Subject: Request for LDAP Result Code Registration - - Result Code Name: - - Person & email address to contact for further information: - - Specification: (RFC, I-D, URI) - - Author/Change Controller: - - Comments: - - (Any comments that the requester deems relevant to the request.) - -A.8. LDAP Search Scope Registration Template - - Subject: Request for LDAP Search Scope Registration - - Search Scope Name: - - Filter Scope String: - - Person & email address to contact for further information: - - Specification: (RFC, I-D, URI) - - Author/Change Controller: - - Comments: - - (Any comments that the requester deems relevant to the request.) - - - - - - - - - - - - - - - - - - -Zeilenga Best Current Practice [Page 16] - -RFC 4520 IANA Considerations for LDAP June 2006 - - -A.9. LDAP Filter Choice Registration Template - - Subject: Request for LDAP Filter Choice Registration - - Filter Choice Name: - - Person & email address to contact for further information: - - Specification: (RFC, I-D, URI) - - Author/Change Controller: - - Comments: - - (Any comments that the requester deems relevant to the request.) - -A.10. LDAP ModifyRequest Operation Registration Template - - Subject: Request for LDAP ModifyRequest Operation Registration - - ModifyRequest Operation Name: - - Person & email address to contact for further information: - - Specification: (RFC, I-D, URI) - - Author/Change Controller: - - Comments: - - (Any comments that the requester deems relevant to the request.) - -Appendix B. Changes since RFC 3383 - - This informative appendix provides a summary of changes made since - RFC 3383. - - - Object Identifier Descriptors practices were updated to require - all descriptors defined in RFCs to be registered and - recommending all other descriptors (excepting those in - private-use name space) be registered. Additionally, all - requests for multiple registrations of the same descriptor are - now subject to Expert Review. - - - Protocol Mechanisms practices were updated to include values of - the 'supportedFeatures' attribute type. - - - - - -Zeilenga Best Current Practice [Page 17] - -RFC 4520 IANA Considerations for LDAP June 2006 - - - - LDAP Syntax, Search Scope, Filter Choice, ModifyRequest - operation, and authzId prefixes registries were added. - - - References to RFCs comprising the LDAP technical specifications - have been updated to latest revisions. - - - References to ISO 10646 have been replaced with [Unicode]. - - - The "Assigned Values" appendix providing initial registry - values was removed. - - - Numerous editorial changes were made. - -Author's Address - - Kurt D. Zeilenga - OpenLDAP Foundation - - EMail: Kurt@OpenLDAP.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Zeilenga Best Current Practice [Page 18] - -RFC 4520 IANA Considerations for LDAP June 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Zeilenga Best Current Practice [Page 19] - diff --git a/source4/ldap_server/devdocs/rfc4521.txt b/source4/ldap_server/devdocs/rfc4521.txt deleted file mode 100644 index 813ff1e30f..0000000000 --- a/source4/ldap_server/devdocs/rfc4521.txt +++ /dev/null @@ -1,899 +0,0 @@ - - - - - - -Network Working Group K. Zeilenga -Request for Comments: 4521 OpenLDAP Foundation -BCP: 118 June 2006 -Category: Best Current Practice - - - Considerations for - Lightweight Directory Access Protocol (LDAP) Extensions - -Status of This Memo - - This document specifies an Internet Best Current Practices for the - Internet Community, and requests discussion and suggestions for - improvements. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - The Lightweight Directory Access Protocol (LDAP) is extensible. It - provides mechanisms for adding new operations, extending existing - operations, and expanding user and system schemas. This document - discusses considerations for designers of LDAP extensions. - - - - - - - - - - - - - - - - - - - - - - - - - - -Zeilenga Best Current Practice [Page 1] - -RFC 4521 LDAP Extensions June 2006 - - -Table of Contents - - 1. Introduction ....................................................3 - 1.1. Terminology ................................................3 - 2. General Considerations ..........................................4 - 2.1. Scope of Extension .........................................4 - 2.2. Interaction between extensions .............................4 - 2.3. Discovery Mechanism ........................................4 - 2.4. Internationalization Considerations ........................5 - 2.5. Use of the Basic Encoding Rules ............................5 - 2.6. Use of Formal Languages ....................................5 - 2.7. Examples ...................................................5 - 2.8. Registration of Protocol Values ............................5 - 3. LDAP Operation Extensions .......................................6 - 3.1. Controls ...................................................6 - 3.1.1. Extending Bind Operation with Controls ..............6 - 3.1.2. Extending the Start TLS Operation with Controls .....7 - 3.1.3. Extending the Search Operation with Controls ........7 - 3.1.4. Extending the Update Operations with Controls .......8 - 3.1.5. Extending the Responseless Operations with Controls..8 - 3.2. Extended Operations ........................................8 - 3.3. Intermediate Responses .....................................8 - 3.4. Unsolicited Notifications ..................................9 - 4. Extending the LDAP ASN.1 Definition .............................9 - 4.1. Result Codes ...............................................9 - 4.2. LDAP Message Types .........................................9 - 4.3. Authentication Methods ....................................10 - 4.4. General ASN.1 Extensibility ...............................10 - 5. Schema Extensions ..............................................10 - 5.1. LDAP Syntaxes .............................................11 - 5.2. Matching Rules ............................................11 - 5.3. Attribute Types ...........................................12 - 5.4. Object Classes ............................................12 - 6. Other Extension Mechanisms .....................................12 - 6.1. Attribute Description Options .............................12 - 6.2. Authorization Identities ..................................12 - 6.3. LDAP URL Extensions .......................................12 - 7. Security Considerations ........................................12 - 8. Acknowledgements ...............................................13 - 9. References .....................................................13 - 9.1. Normative References ......................................13 - 9.2. Informative References ....................................15 - - - - - - - - - -Zeilenga Best Current Practice [Page 2] - -RFC 4521 LDAP Extensions June 2006 - - -1. Introduction - - The Lightweight Directory Access Protocol (LDAP) [RFC4510] is an - extensible protocol. - - LDAP allows for new operations to be added and for existing - operations to be enhanced [RFC4511]. - - LDAP allows additional schema to be defined [RFC4512][RFC4517]. This - can include additional object classes, attribute types, matching - rules, additional syntaxes, and other elements of schema. LDAP - provides an ability to extend attribute types with options [RFC4512]. - - LDAP supports a Simple Authentication and Security Layer (SASL) - authentication method [RFC4511][RFC4513]. SASL [RFC4422] is - extensible. LDAP may be extended to support additional - authentication methods [RFC4511]. - - LDAP supports establishment of Transport Layer Security (TLS) - [RFC4511][RFC4513]. TLS [RFC4346] is extensible. - - LDAP has an extensible Uniform Resource Locator (URL) format - [RFC4516]. - - Lastly, LDAP allows for certain extensions to the protocol's Abstract - Syntax Notation - One (ASN.1) [X.680] definition to be made. This - facilitates a wide range of protocol enhancements, for example, new - result codes needed to support extensions to be added through - extension of the protocol's ASN.1 definition. - - This document describes practices that engineers should consider when - designing extensions to LDAP. - -1.1. Terminology - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in BCP 14 [RFC2119]. In - this document, "the specification", as used by BCP 14, RFC 2119, - refers to the engineering of LDAP extensions. - - The term "Request Control" refers to a control attached to a client- - generated message sent to a server. The term "Response Control" - refers to a control attached to a server-generated message sent to a - client. - - - - - - -Zeilenga Best Current Practice [Page 3] - -RFC 4521 LDAP Extensions June 2006 - - - DIT stands for Directory Information Tree. - DSA stands for Directory System Agent, a server. - DSE stands for DSA-Specific Entry. - DUA stands for Directory User Agent, a client. - DN stands for Distinguished Name. - -2. General Considerations - -2.1. Scope of Extension - - Mutually agreeing peers may, within the confines of an extension, - agree to significant changes in protocol semantics. However, - designers MUST consider the impact of an extension upon protocol - peers that have not agreed to implement or otherwise recognize and - support the extension. Extensions MUST be "truly optional" - [RFC2119]. - -2.2. Interaction between extensions - - Designers SHOULD consider how extensions they engineer interact with - other extensions. - - Designers SHOULD consider the extensibility of extensions they - specify. Extensions to LDAP SHOULD themselves be extensible. - - Except where it is stated otherwise, extensibility is implied. - -2.3. Discovery Mechanism - - Extensions SHOULD provide adequate discovery mechanisms. - - As LDAP design is based upon the client-request/server-response - paradigm, the general discovery approach is for the client to - discover the capabilities of the server before utilizing a particular - extension. Commonly, this discovery involves querying the root DSE - and/or other DSEs for operational information associated with the - extension. LDAP provides no mechanism for a server to discover the - capabilities of a client. - - The 'supportedControl' attribute [RFC4512] is used to advertise - supported controls. The 'supportedExtension' attribute [RFC4512] is - used to advertise supported extended operations. The - 'supportedFeatures' attribute [RFC4512] is used to advertise - features. Other root DSE attributes MAY be defined to advertise - other capabilities. - - - - - - -Zeilenga Best Current Practice [Page 4] - -RFC 4521 LDAP Extensions June 2006 - - -2.4. Internationalization Considerations - - LDAP is designed to support the full Unicode [Unicode] repertory of - characters. Extensions SHOULD avoid unnecessarily restricting - applications to subsets of Unicode (e.g., Basic Multilingual Plane, - ISO 8859-1, ASCII, Printable String). - - LDAP Language Tag options [RFC3866] provide a mechanism for tagging - text (and other) values with language information. Extensions that - define attribute types SHOULD allow use of language tags with these - attributes. - -2.5. Use of the Basic Encoding Rules - - Numerous elements of LDAP are described using ASN.1 [X.680] and are - encoded using a particular subset [Protocol, Section 5.2] of the - Basic Encoding Rules (BER) [X.690]. To allow reuse of - parsers/generators used in implementing the LDAP "core" technical - specification [RFC4510], it is RECOMMENDED that extension elements - (e.g., extension specific contents of controlValue, requestValue, - responseValue fields) described by ASN.1 and encoded using BER be - subjected to the restrictions of [Protocol, Section 5.2]. - -2.6. Use of Formal Languages - - Formal languages SHOULD be used in specifications in accordance with - IESG guidelines [FORMAL]. - -2.7. Examples - - Example DN strings SHOULD conform to the syntax defined in [RFC4518]. - Example LDAP filter strings SHOULD conform to the syntax defined in - [RFC4515]. Example LDAP URLs SHOULD conform to the syntax defined in - [RFC4516]. Entries SHOULD be represented using LDIF [RFC2849]. - -2.8. Registration of Protocol Values - - Designers SHALL register protocol values of their LDAP extensions in - accordance with BCP 64, RFC 4520 [RFC4520]. Specifications that - create new extensible protocol elements SHALL extend existing - registries or establish new registries for values of these elements - in accordance with BCP 64, RFC 4520 [RFC4520] and BCP 26, RFC 2434 - [RFC2434]. - - - - - - - - -Zeilenga Best Current Practice [Page 5] - -RFC 4521 LDAP Extensions June 2006 - - -3. LDAP Operation Extensions - - Extensions SHOULD use controls in defining extensions that complement - existing operations. Where the extension to be defined does not - complement an existing operation, designers SHOULD consider defining - an extended operation instead. - - For example, a subtree delete operation could be designed as either - an extension of the delete operation or as a new operation. As the - feature complements the existing delete operation, use of the control - mechanism to extend the delete operation is likely more appropriate. - - As a counter (and contrived) example, a locate services operation (an - operation that would return for a DN a set of LDAP URLs to services - that may hold the entry named by this DN) could be designed as either - a search operation or a new operation. As the feature doesn't - complement the search operation (e.g., the operation is not contrived - to search for entries held in the Directory Information Tree), it is - likely more appropriate to define a new operation using the extended - operation mechanism. - -3.1. Controls - - Controls [Protocol, Section 4.1.11] are the RECOMMENDED mechanism for - extending existing operations. The existing operation can be a base - operation defined in [RFC4511] (e.g., search, modify) , an extended - operation (e.g., Start TLS [RFC4511], Password Modify [RFC3062]), or - an operation defined as an extension to a base or extended operation. - - Extensions SHOULD NOT return Response controls unless the server has - specific knowledge that the client can make use of the control. - Generally, the client requests the return of a particular response - control by providing a related request control. - - An existing operation MAY be extended to return IntermediateResponse - messages [Protocol, Section 4.13]. - - Specifications of controls SHALL NOT attach additional semantics to - the criticality of controls beyond those defined in [Protocol, - Section 4.1.11]. A specification MAY mandate the criticality take on - a particular value (e.g., TRUE or FALSE), where appropriate. - -3.1.1. Extending Bind Operation with Controls - - Controls attached to the request and response messages of a Bind - Operation [RFC4511] are not protected by any security layers - established by that Bind operation. - - - - -Zeilenga Best Current Practice [Page 6] - -RFC 4521 LDAP Extensions June 2006 - - - Specifications detailing controls extending the Bind operation SHALL - detail that the Bind negotiated security layers do not protect the - information contained in these controls and SHALL detail how the - information in these controls is protected or why the information - does not need protection. - - It is RECOMMENDED that designers consider alternative mechanisms for - providing the function. For example, an extended operation issued - subsequent to the Bind operation (hence, protected by the security - layers negotiated by the Bind operation) might be used to provide the - desired function. - - Additionally, designers of Bind control extensions MUST also consider - how the controls' semantics interact with individual steps of a - multi-step Bind operation. Note that some steps are optional and - thus may require special attention in the design. - -3.1.2. Extending the Start TLS Operation with Controls - - Controls attached to the request and response messages of a Start TLS - Operation [RFC4511] are not protected by the security layers - established by the Start TLS operation. - - Specifications detailing controls extending the Start TLS operation - SHALL detail that the Start TLS negotiated security layers do not - protect the information contained in these controls and SHALL detail - how the information in these controls is protected or why the - information does not need protection. - - It is RECOMMENDED that designers consider alternative mechanisms for - providing the function. For example, an extended operation issued - subsequent to the Start TLS operation (hence, protected by the - security layers negotiated by the Start TLS operation) might be used - to provided the desired function. - -3.1.3. Extending the Search Operation with Controls - - The Search operation processing has two distinct phases: - - - finding the base object; and - - - searching for objects at or under that base object. - - Specifications of controls extending the Search Operation should - clearly state in which phase(s) the control's semantics apply. - Semantics of controls that are not specific to the Search Operation - SHOULD apply in the finding phase. - - - - -Zeilenga Best Current Practice [Page 7] - -RFC 4521 LDAP Extensions June 2006 - - -3.1.4. Extending the Update Operations with Controls - - Update operations have properties of atomicity, consistency, - isolation, and durability ([ACID]). - - - atomicity: All or none of the DIT changes requested are made. - - - consistency: The resulting DIT state must be conform to schema - and other constraints. - - - isolation: Intermediate states are not exposed. - - - durability: The resulting DIT state is preserved until - subsequently updated. - - When defining a control that requests additional (or other) DIT - changes be made to the DIT, these additional changes SHOULD NOT be - treated as part of a separate transaction. The specification MUST be - clear as to whether the additional DIT changes are part of the same - or a separate transaction as the DIT changes expressed in the request - of the base operation. - - When defining a control that requests additional (or other) DIT - changes be made to the DIT, the specification MUST be clear as to the - order in which these and the base changes are to be applied to the - DIT. - -3.1.5. Extending the Responseless Operations with Controls - - The Abandon and Unbind operations do not include a response message. - For this reason, specifications for controls designed to be attached - to Abandon and Unbind requests SHOULD mandate that the control's - criticality be FALSE. - -3.2. Extended Operations - - Extended Operations [Protocol, Section 4.12] are the RECOMMENDED - mechanism for defining new operations. An extended operation - consists of an ExtendedRequest message, zero or more - IntermediateResponse messages, and an ExtendedResponse message. - -3.3. Intermediate Responses - - Extensions SHALL use IntermediateResponse messages instead of - ExtendedResponse messages to return intermediate results. - - - - - - -Zeilenga Best Current Practice [Page 8] - -RFC 4521 LDAP Extensions June 2006 - - -3.4. Unsolicited Notifications - - Unsolicited notifications [Protocol, Section 4.4] offer a capability - for the server to notify the client of events not associated with the - operation currently being processed. - - Extensions SHOULD be designed such that unsolicited notifications are - not returned unless the server has specific knowledge that the client - can make use of the notification. Generally, the client requests the - return of a particular unsolicited notification by performing a - related extended operation. - - For example, a time hack extension could be designed to return - unsolicited notifications at regular intervals that were enabled by - an extended operation (which possibly specified the desired - interval). - -4. Extending the LDAP ASN.1 Definition - - LDAP allows limited extension [Protocol, Section 4] of the LDAP ASN.1 - definition [Protocol, Appendix B] to be made. - -4.1. Result Codes - - Extensions that specify new operations or enhance existing operations - often need to define new result codes. The extension SHOULD be - designed such that a client has a reasonably clear indication of the - nature of the successful or non-successful result. - - Extensions SHOULD use existing result codes to indicate conditions - that are consistent with the intended meaning [RFC4511][X.511] of - these codes. Extensions MAY introduce new result codes [RFC4520] - where no existing result code provides an adequate indication of the - nature of the result. - - Extensions SHALL NOT disallow or otherwise restrict the return of - general service result codes, especially those reporting a protocol, - service, or security problem, or indicating that the server is unable - or unwilling to complete the operation. - -4.2. LDAP Message Types - - While extensions can specify new types of LDAP messages by extending - the protocolOp CHOICE of the LDAPMessage SEQUENCE, this is generally - unnecessary and inappropriate. Existing operation extension - mechanisms (e.g., extended operations, unsolicited notifications, and - intermediate responses) SHOULD be used instead. However, there may - be cases where an extension does not fit well into these mechanisms. - - - -Zeilenga Best Current Practice [Page 9] - -RFC 4521 LDAP Extensions June 2006 - - - In such cases, a new extension mechanism SHOULD be defined that can - be used by multiple extensions that have similar needs. - -4.3. Authentication Methods - - The Bind operation currently supports two authentication methods, - simple and SASL. SASL [RFC4422] is an extensible authentication - framework used by multiple application-level protocols (e.g., BEEP, - IMAP, SMTP). It is RECOMMENDED that new authentication processes be - defined as SASL mechanisms. New LDAP authentication methods MAY be - added to support new authentication frameworks. - - The Bind operation's primary function is to establish the LDAP - association [RFC4513]. No other operation SHALL be defined (or - extended) to establish the LDAP association. However, other - operations MAY be defined to establish other security associations - (e.g., IPsec). - -4.4. General ASN.1 Extensibility - - Section 4 of [RFC4511] states the following: - - In order to support future extensions to this protocol, - extensibility is implied where it is allowed per ASN.1 (i.e., - sequence, set, choice, and enumerated types are extensible). In - addition, ellipses (...) have been supplied in ASN.1 types that - are explicitly extensible as discussed in [RFC4520]. Because of - the implied extensibility, clients and servers MUST (unless - otherwise specified) ignore trailing SEQUENCE components whose - tags they do not recognize. - - Designers SHOULD avoid introducing extensions that rely on - unsuspecting implementations to ignore trailing components of - SEQUENCE whose tags they do not recognize. - -5. Schema Extensions - - Extensions defining LDAP schema elements SHALL provide schema - definitions conforming with syntaxes defined in [Models, Section - 4.1]. While provided definitions MAY be reformatted (line wrapped) - for readability, this SHALL be noted in the specification. - - For definitions that allow a NAME field, new schema elements SHOULD - provide one and only one name. The name SHOULD be short. - - Each schema definition allows a DESC field. The DESC field, if - provided, SHOULD contain a short descriptive phrase. The DESC field - MUST be regarded as informational. That is, the specification MUST - - - -Zeilenga Best Current Practice [Page 10] - -RFC 4521 LDAP Extensions June 2006 - - - be written such that its interpretation is the same with and without - the provided DESC fields. - - The extension SHALL NOT mandate that implementations provide the same - DESC field in the schema they publish. Implementors MAY replace or - remove the DESC field. - - Published schema elements SHALL NOT be redefined. Replacement schema - elements (new OIDs, new NAMEs) SHOULD be defined as needed. - - Schema designers SHOULD reuse existing schema elements, where - appropriate. However, any reuse MUST not alter the semantics of the - element. - -5.1. LDAP Syntaxes - - Each LDAP syntax [RFC4517] is defined in terms of ASN.1 [X.680]. - Each extension detailing an LDAP syntax MUST specify the ASN.1 data - definition associated with the syntax. A distinct LDAP syntax SHOULD - be created for each distinct ASN.1 data definition (including - constraints). - - Each LDAP syntax SHOULD have a string encoding defined for it. It is - RECOMMENDED that this string encoding be restricted to UTF-8 - [RFC3629] encoded Unicode [Unicode] characters. Use of Generic - String Encoding Rules (GSER) [RFC3641][RFC3642] or other generic - string encoding rules to provide string encodings for complex ASN.1 - data definitions is RECOMMENDED. Otherwise, it is RECOMMENDED that - the string encoding be described using a formal language (e.g., ABNF - [RFC4234]). Formal languages SHOULD be used in specifications in - accordance with IESG guidelines [FORMAL]. - - If no string encoding is defined, the extension SHALL specify how the - transfer encoding is to be indicated. Generally, the extension - SHOULD mandate use of binary or other transfer encoding option. - -5.2. Matching Rules - - Three basic kinds of matching rules (e.g., EQUALITY, ORDERING, and - SUBSTRING) may be associated with an attribute type. In addition, - LDAP provides an extensible matching rule mechanism. - - The matching rule specification SHOULD detail which kind of matching - rule it is and SHOULD describe which kinds of values it can be used - with. - - In addition to requirements stated in the LDAP technical - specification, equality matching rules SHOULD be commutative. - - - -Zeilenga Best Current Practice [Page 11] - -RFC 4521 LDAP Extensions June 2006 - - -5.3. Attribute Types - - Designers SHOULD carefully consider how the structure of values is to - be restricted. Designers SHOULD consider that servers will only - enforce constraints of the attribute's syntax. That is, an attribute - intended to hold URIs, but that has directoryString syntax, is not - restricted to values that are URIs. - - Designers SHOULD carefully consider which matching rules, if any, are - appropriate for the attribute type. Matching rules specified for an - attribute type MUST be compatible with the attribute type's syntax. - - Extensions specifying operational attributes MUST detail how servers - are to maintain and/or utilize values of each operational attribute. - -5.4. Object Classes - - Designers SHOULD carefully consider whether each attribute of an - object class is required ("MUST") or allowed ("MAY"). - - Extensions specifying object classes that allow (or require) - operational attributes MUST specify how servers are to maintain - and/or utilize entries belonging to these object classes. - -6. Other Extension Mechanisms - -6.1. Attribute Description Options - - Each option is identified by a string of letters, numbers, and - hyphens. This string SHOULD be short. - -6.2. Authorization Identities - - Extensions interacting with authorization identities SHALL support - the LDAP authzId format [RFC4513]. The authzId format is extensible. - -6.3. LDAP URL Extensions - - LDAP URL extensions are identified by a short string, a descriptor. - Like other descriptors, the string SHOULD be short. - -7. Security Considerations - - LDAP does not place undue restrictions on the kinds of extensions - that can be implemented. While this document attempts to outline - some specific issues that designers need to consider, it is not (and - - - - - -Zeilenga Best Current Practice [Page 12] - -RFC 4521 LDAP Extensions June 2006 - - - cannot be) all encompassing. Designers MUST do their own evaluations - of the security considerations applicable to their extensions. - - Designers MUST NOT assume that the LDAP "core" technical - specification [RFC4510] adequately addresses the specific concerns - surrounding their extensions or assume that their extensions have no - specific concerns. - - Extension specifications, however, SHOULD note whether security - considerations specific to the feature they are extending, as well as - general LDAP security considerations, apply to the extension. - -8. Acknowledgements - - The author thanks the IETF LDAP community for their thoughtful - comments. - - This work builds upon "LDAP Extension Style Guide" [GUIDE] by Bruce - Greenblatt. - -9. References - -9.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26, RFC 2434, - October 1998. - - [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - - Technical Specification", RFC 2849, June 2000. - - [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO - 10646", STD 63, RFC 3629, November 2003. - - [RFC3641] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1 - Types", RFC 3641, October 2003. - - [RFC3642] Legg, S., "Common Elements of Generic String Encoding - Rules (GSER) Encodings", RFC 3642, October 2003. - - [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP): Directory Information Models", RFC 4512, June - 2006. - - - - - -Zeilenga Best Current Practice [Page 13] - -RFC 4521 LDAP Extensions June 2006 - - - [RFC3866] Zeilenga, K., Ed., "Language Tags and Ranges in the - Lightweight Directory Access Protocol (LDAP)", RFC 3866, - July 2004. - - [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 4234, October 2005. - - [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol - (LDAP): Technical Specification Road Map", RFC 4510, June - 2006. - - [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access - Protocol (LDAP): The Protocol", RFC 4511, June 2006. - - [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP): Directory Information Models", RFC 4512, June - 2006. - - [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol - (LDAP): Authentication Methods and Security Mechanisms", - RFC 4513, June 2006. - - [RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory Access - Protocol (LDAP): String Representation of Search Filters", - RFC 4515, June 2006. - - [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory Access - Protocol (LDAP): Uniform Resource Locator", RFC 4516, June - 2006. - - [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol - (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006. - - [RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP): String Representation of Distinguished Names", RFC - 4518, June 2006. - - [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) - Considerations for the Lightweight Directory Access - Protocol (LDAP)", BCP 64, RFC 4520, June 2006. - - [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple - Authentication and Security Layer (SASL)", RFC 4422, June - 2006. - - - - - - - -Zeilenga Best Current Practice [Page 14] - -RFC 4521 LDAP Extensions June 2006 - - - [Unicode] The Unicode Consortium, "The Unicode Standard, Version - 3.2.0" is defined by "The Unicode Standard, Version 3.0" - (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), - as amended by the "Unicode Standard Annex #27: Unicode - 3.1" (http://www.unicode.org/reports/tr27/) and by the - "Unicode Standard Annex #28: Unicode 3.2" - (http://www.unicode.org/reports/tr28/). - - [FORMAL] IESG, "Guidelines for the use of formal languages in IETF - specifications", - <http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in- - specs.txt>, 2001. - - [X.511] International Telecommunication Union - Telecommunication - Standardization Sector, "The Directory: Abstract Service - Definition", X.511(1993) (also ISO/IEC 9594-3:1993). - - [X.680] International Telecommunication Union - Telecommunication - Standardization Sector, "Abstract Syntax Notation One - (ASN.1) - Specification of Basic Notation", X.680(2002) - (also ISO/IEC 8824-1:2002). - - [X.690] International Telecommunication Union - Telecommunication - Standardization Sector, "Specification of ASN.1 encoding - rules: Basic Encoding Rules (BER), Canonical Encoding - Rules (CER), and Distinguished Encoding Rules (DER)", - X.690(2002) (also ISO/IEC 8825-1:2002). - -9.2. Informative References - - [ACID] Section 4 of ISO/IEC 10026-1:1992. - - [GUIDE] Greenblatt, B., "LDAP Extension Style Guide", Work in - Progress. - - [RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation", - RFC 3062, February 2001. - - [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security - (TLS) Protocol Version 1.1", RFC 4346, April 2006. - -Author's Address - - Kurt D. Zeilenga - OpenLDAP Foundation - - EMail: Kurt@OpenLDAP.org - - - - -Zeilenga Best Current Practice [Page 15] - -RFC 4521 LDAP Extensions June 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Zeilenga Best Current Practice [Page 16] - diff --git a/source4/ldap_server/devdocs/rfc4522.txt b/source4/ldap_server/devdocs/rfc4522.txt deleted file mode 100644 index 11156a07f1..0000000000 --- a/source4/ldap_server/devdocs/rfc4522.txt +++ /dev/null @@ -1,451 +0,0 @@ - - - - - - -Network Working Group S. Legg -Request for Comments: 4522 eB2Bcom -Category: Standards Track June 2006 - - - Lightweight Directory Access Protocol (LDAP): - The Binary Encoding Option - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - Each attribute stored in a Lightweight Directory Access Protocol - (LDAP) directory has a defined syntax (i.e., data type). A syntax - definition specifies how attribute values conforming to the syntax - are normally represented when transferred in LDAP operations. This - representation is referred to as the LDAP-specific encoding to - distinguish it from other methods of encoding attribute values. This - document defines an attribute option, the binary option, that can be - used to specify that the associated attribute values are instead - encoded according to the Basic Encoding Rules (BER) used by X.500 - directories. - -Table of Contents - - 1. Introduction ....................................................2 - 2. Conventions .....................................................2 - 3. The Binary Option ...............................................2 - 4. Syntaxes Requiring Binary Transfer ..............................3 - 5. Attributes Returned in a Search .................................4 - 6. All User Attributes .............................................4 - 7. Conflicting Requests ............................................5 - 8. Security Considerations .........................................5 - 9. IANA Considerations .............................................5 - 10. References .....................................................5 - 10.1. Normative References ......................................5 - 10.2. Informative References ....................................6 - - - - -Legg Standards Track [Page 1] - -RFC 4522 LDAP: The Binary Encoding Option June 2006 - - -1. Introduction - - Each attribute stored in a Lightweight Directory Access Protocol - (LDAP) directory [RFC4510] has a defined syntax (i.e., data type) - which constrains the structure and format of its values. - - The description of each syntax [RFC4517] specifies how attribute or - assertion values [RFC4512] conforming to the syntax are normally - represented when transferred in LDAP operations [RFC4511]. This - representation is referred to as the LDAP-specific encoding to - distinguish it from other methods of encoding attribute values. - - This document defines an attribute option, the binary option, which - can be used in an attribute description [RFC4512] in an LDAP - operation to specify that the associated attribute values or - assertion values are, or are requested to be, encoded according to - the Basic Encoding Rules (BER) [BER] as used by X.500 [X.500] - directories, instead of the usual LDAP-specific encoding. - - The binary option was originally defined in RFC 2251 [RFC2251]. The - LDAP technical specification [RFC4510] has obsoleted the previously - defined LDAP technical specification [RFC3377], which included RFC - 2251. The binary option was not included in the revised LDAP - technical specification for a variety of reasons including - implementation inconsistencies. No attempt is made here to resolve - the known inconsistencies. - - This document reintroduces the binary option for use with certain - attribute syntaxes, such as certificate syntax [RFC4523], that - specifically require it. No attempt has been made to address use of - the binary option with attributes of syntaxes that do not require its - use. Unless addressed in a future specification, this use is to be - avoided. - -2. Conventions - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in BCP 14, RFC 2119 - [BCP14]. - -3. The Binary Option - - The binary option is indicated with the attribute option string - "binary" in an attribute description. Note that, like all attribute - options, the string representing the binary option is case - insensitive. - - - - -Legg Standards Track [Page 2] - -RFC 4522 LDAP: The Binary Encoding Option June 2006 - - - Where the binary option is present in an attribute description, the - associated attribute values or assertion values MUST be BER encoded - (otherwise the values are encoded according to the LDAP-specific - encoding [RFC4517] for the attribute's syntax). Note that it is - possible for a syntax to be defined such that its LDAP-specific - encoding is exactly the same as its BER encoding. - - In terms of the protocol [RFC4511], the binary option specifies that - the contents octets of the associated AttributeValue or - AssertionValue OCTET STRING are a complete BER encoding of the - relevant value. - - The binary option is not a tagging option [RFC4512], so the presence - of the binary option does not specify an attribute subtype. An - attribute description containing the binary option references exactly - the same attribute as the attribute description without the binary - option. The supertype/subtype relationships of attributes with - tagging options are not altered in any way by the presence or absence - of the binary option. - - An attribute description SHALL be treated as unrecognized if it - contains the binary option and the syntax of the attribute does not - have an associated ASN.1 type [RFC4517], or the BER encoding of - values of that type is not supported. - - The presence or absence of the binary option only affects the - transfer of attribute and assertion values in the protocol; servers - store any particular attribute value in a format of their choosing. - -4. Syntaxes Requiring Binary Transfer - - The attribute values of certain attribute syntaxes are defined - without an LDAP-specific encoding and are required to be transferred - in the BER-encoded form. For the purposes of this document, these - syntaxes are said to have a binary transfer requirement. The - certificate, certificate list, certificate pair, and supported - algorithm syntaxes [RFC4523] are examples of syntaxes with a binary - transfer requirement. These syntaxes also have an additional - requirement that the exact BER encoding must be preserved. Note that - this is a property of the syntaxes themselves, and not a property of - the binary option. In the absence of this requirement, LDAP clients - would need to re-encode values using the Distinguished Encoding Rules - (DER). - - - - - - - - -Legg Standards Track [Page 3] - -RFC 4522 LDAP: The Binary Encoding Option June 2006 - - -5. Attributes Returned in a Search - - An LDAP search request [RFC4511] contains a list of the attributes - (the requested attributes list) to be returned from each entry - matching the search filter. An attribute description in the - requested attributes list also implicitly requests all subtypes of - the attribute type in the attribute description, whether through - attribute subtyping or attribute tagging option subtyping [RFC4512]. - - The requested attributes list MAY contain attribute descriptions with - the binary option, but MUST NOT contain two attribute descriptions - with the same attribute type and the same tagging options (even if - only one of them has the binary option). The binary option in an - attribute description in the requested attributes list implicitly - applies to all the subtypes of the attribute type in the attribute - description (however, see Section 7). - - Attributes of a syntax with the binary transfer requirement, if - returned, SHALL be returned in the binary form (i.e., with the binary - option in the attribute description and the associated attribute - values BER encoded) regardless of whether the binary option was - present in the request (for the attribute or for one of its - supertypes). - - Attributes of a syntax without the binary transfer requirement, if - returned, SHOULD be returned in the form explicitly requested. That - is, if the attribute description in the requested attributes list - contains the binary option, then the corresponding attribute in the - result SHOULD be in the binary form. If the attribute description in - the request does not contain the binary option, then the - corresponding attribute in the result SHOULD NOT be in the binary - form. A server MAY omit an attribute from the result if it does not - support the requested encoding. - - Regardless of the encoding chosen, a particular attribute value is - returned at most once. - -6. All User Attributes - - If the list of attributes in a search request is empty or contains - the special attribute description string "*", then all user - attributes are requested to be returned. - - Attributes of a syntax with the binary transfer requirement, if - returned, SHALL be returned in the binary form. - - - - - - -Legg Standards Track [Page 4] - -RFC 4522 LDAP: The Binary Encoding Option June 2006 - - - Attributes of a syntax without the binary transfer requirement and - having a defined LDAP-specific encoding SHOULD NOT be returned in the - binary form. - - Attributes of a syntax without the binary transfer requirement and - without a defined LDAP-specific encoding may be returned in the - binary form or omitted from the result. - -7. Conflicting Requests - - A particular attribute could be explicitly requested by an attribute - description and/or implicitly requested by the attribute descriptions - of one or more of its supertypes, or by the special attribute - description string "*". If the binary option is present in at least - one, but not all, of these attribute descriptions then the effect of - the request with respect to binary transfer is implementation - defined. - -8. Security Considerations - - When interpreting security-sensitive fields, and in particular fields - used to grant or deny access, implementations MUST ensure that any - matching rule comparisons are done on the underlying abstract value, - regardless of the particular encoding used. - -9. IANA Considerations - - The Internet Assigned Numbers Authority (IANA) has updated the LDAP - attribute description option registry [BCP64] as indicated by the - following template: - - Subject: - Request for LDAP Attribute Description Option Registration - Option Name: binary - Family of Options: NO - Person & email address to contact for further information: - Steven Legg <steven.legg@eb2bcom.com> - Specification: RFC 4522 - Author/Change Controller: IESG - -10. References - -10.1. Normative References - - [BCP14] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - - - - -Legg Standards Track [Page 5] - -RFC 4522 LDAP: The Binary Encoding Option June 2006 - - - [BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) - Considerations for the Lightweight Directory Access - Protocol (LDAP)", BCP 64, RFC 4520, June 2006. - - [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol - (LDAP): Technical Specification Road Map", RFC RFC 4510, - June 2006. - - [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol - (LDAP): The Protocol", RFC 4511, June 2006. - - [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP): Directory Information Models", RFC 4512, June - 2006. - - [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol - (LDAP): Syntaxes and Matching Rules", RFC 4517, June - 2006. - - [RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP) Schema Definitions for X.509 Certificates", RFC - 4523, June 2006. - - [BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1, - Information Technology - ASN.1 encoding rules: - Specification of Basic Encoding Rules (BER), Canonical - Encoding Rules (CER) and Distinguished Encoding Rules - (DER). - -10.2. Informative References - - [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory - Access Protocol (v3)", RFC 2251, December 1997. - - [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access - Protocol (v3): Technical Specification", RFC 3377, - September 2002. - - [X.500] ITU-T Recommendation X.500 (02/01) | ISO/IEC 9594-1:2001, - Information technology - Open Systems Interconnection - - The Directory: Overview of concepts, models and services - - - - - - - - - - -Legg Standards Track [Page 6] - -RFC 4522 LDAP: The Binary Encoding Option June 2006 - - -Author's Address - - Dr. Steven Legg - eB2Bcom - Suite 3, Woodhouse Corporate Centre - 935 Station Street - Box Hill North, Victoria 3129 - AUSTRALIA - - Phone: +61 3 9896 7830 - Fax: +61 3 9896 7801 - EMail: steven.legg@eb2bcom.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Legg Standards Track [Page 7] - -RFC 4522 LDAP: The Binary Encoding Option June 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Legg Standards Track [Page 8] - diff --git a/source4/ldap_server/devdocs/rfc4523.txt b/source4/ldap_server/devdocs/rfc4523.txt deleted file mode 100644 index d2589811c7..0000000000 --- a/source4/ldap_server/devdocs/rfc4523.txt +++ /dev/null @@ -1,1347 +0,0 @@ - - - - - - -Network Working Group K. Zeilenga -Request for Comments: 4523 OpenLDAP Foundation -Obsoletes: 2252, 2256, 2587 June 2006 -Category: Standards Track - - - Lightweight Directory Access Protocol (LDAP) - Schema Definitions for X.509 Certificates - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - - Abstract - - This document describes schema for representing X.509 certificates, - X.521 security information, and related elements in directories - accessible using the Lightweight Directory Access Protocol (LDAP). - The LDAP definitions for these X.509 and X.521 schema elements - replace those provided in RFCs 2252 and 2256. - -1. Introduction - - This document provides LDAP [RFC4510] schema definitions [RFC4512] - for a subset of elements specified in X.509 [X.509] and X.521 - [X.521], including attribute types for certificates, cross - certificate pairs, and certificate revocation lists; matching rules - to be used with these attribute types; and related object classes. - LDAP syntax definitions are also provided for associated assertion - and attribute values. - - As the semantics of these elements are as defined in X.509 and X.521, - knowledge of X.509 and X.521 is necessary to make use of the LDAP - schema definitions provided herein. - - This document, together with [RFC4510], obsoletes RFCs 2252 and 2256 - in their entirety. The changes (in this document) made since RFC - 2252 and RFC 2256 include: - - - addition of pkiUser, pkiCA, and deltaCRL classes; - - - -Zeilenga Standards Track [Page 1] - -RFC 4523 LDAP X.509 Schema June 2006 - - - - update of attribute types to include equality matching rules in - accordance with their X.500 specifications; - - - addition of certificate, certificate pair, certificate list, - and algorithm identifier matching rules; and - - - addition of LDAP syntax for assertion syntaxes for these - matching rules. - - This document obsoletes RFC 2587. The X.509 schema descriptions for - LDAPv2 [RFC1777] are Historic, as is LDAPv2 [RFC3494]. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in BCP 14 [RFC2119]. - - Schema definitions are provided using LDAP description formats - [RFC4512]. Definitions provided here are formatted (line wrapped) - for readability. - -2. Syntaxes - - This section describes various syntaxes used in LDAP to transfer - certificates and related data types. - -2.1. Certificate - - ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'X.509 Certificate' ) - - A value of this syntax is an X.509 Certificate [X.509, clause 7]. - - Due to changes made to the definition of a Certificate through time, - no LDAP-specific encoding is defined for this syntax. Values of this - syntax SHOULD be encoded using Distinguished Encoding Rules (DER) - [X.690] and MUST only be transferred using the ;binary transfer - option [RFC4522]; that is, by requesting and returning values using - attribute descriptions such as "userCertificate;binary". - - As values of this syntax contain digitally signed data, values of - this syntax and the form of each value MUST be preserved as - presented. - -2.2. CertificateList - - ( 1.3.6.1.4.1.1466.115.121.1.9 DESC 'X.509 Certificate List' ) - - A value of this syntax is an X.509 CertificateList [X.509, clause - 7.3]. - - - -Zeilenga Standards Track [Page 2] - -RFC 4523 LDAP X.509 Schema June 2006 - - - Due to changes made to the definition of a CertificateList through - time, no LDAP-specific encoding is defined for this syntax. Values - of this syntax SHOULD be encoded using DER [X.690] and MUST only be - transferred using the ;binary transfer option [RFC4522]; that is, by - requesting and returning values using attribute descriptions such as - "certificateRevocationList;binary". - - As values of this syntax contain digitally signed data, values of - this syntax and the form of each value MUST be preserved as - presented. - -2.3. CertificatePair - - ( 1.3.6.1.4.1.1466.115.121.1.10 DESC 'X.509 Certificate Pair' ) - - A value of this syntax is an X.509 CertificatePair [X.509, clause - 11.2.3]. - - Due to changes made to the definition of an X.509 CertificatePair - through time, no LDAP-specific encoding is defined for this syntax. - Values of this syntax SHOULD be encoded using DER [X.690] and MUST - only be transferred using the ;binary transfer option [RFC4522]; that - is, by requesting and returning values using attribute descriptions - such as "crossCertificatePair;binary". - - As values of this syntax contain digitally signed data, values of - this syntax and the form of each value MUST be preserved as - presented. - -2.4. SupportedAlgorithm - - ( 1.3.6.1.4.1.1466.115.121.1.49 - DESC 'X.509 Supported Algorithm' ) - - A value of this syntax is an X.509 SupportedAlgorithm [X.509, clause - 11.2.7]. - - Due to changes made to the definition of an X.509 SupportedAlgorithm - through time, no LDAP-specific encoding is defined for this syntax. - Values of this syntax SHOULD be encoded using DER [X.690] and MUST - only be transferred using the ;binary transfer option [RFC4522]; that - is, by requesting and returning values using attribute descriptions - such as "supportedAlgorithms;binary". - - As values of this syntax contain digitally signed data, values of - this syntax and the form of the value MUST be preserved as presented. - - - - - -Zeilenga Standards Track [Page 3] - -RFC 4523 LDAP X.509 Schema June 2006 - - -2.5. CertificateExactAssertion - - ( 1.3.6.1.1.15.1 DESC 'X.509 Certificate Exact Assertion' ) - - A value of this syntax is an X.509 CertificateExactAssertion [X.509, - clause 11.3.1]. Values of this syntax MUST be encoded using the - Generic String Encoding Rules (GSER) [RFC3641]. Appendix A.1 - provides an equivalent Augmented Backus-Naur Form (ABNF) [RFC4234] - grammar for this syntax. - -2.6. CertificateAssertion - - ( 1.3.6.1.1.15.2 DESC 'X.509 Certificate Assertion' ) - - A value of this syntax is an X.509 CertificateAssertion [X.509, - clause 11.3.2]. Values of this syntax MUST be encoded using GSER - [RFC3641]. Appendix A.2 provides an equivalent ABNF [RFC4234] - grammar for this syntax. - -2.7. CertificatePairExactAssertion - - ( 1.3.6.1.1.15.3 - DESC 'X.509 Certificate Pair Exact Assertion' ) - - A value of this syntax is an X.509 CertificatePairExactAssertion - [X.509, clause 11.3.3]. Values of this syntax MUST be encoded using - GSER [RFC3641]. Appendix A.3 provides an equivalent ABNF [RFC4234] - grammar for this syntax. - -2.8. CertificatePairAssertion - - ( 1.3.6.1.1.15.4 DESC 'X.509 Certificate Pair Assertion' ) - - A value of this syntax is an X.509 CertificatePairAssertion [X.509, - clause 11.3.4]. Values of this syntax MUST be encoded using GSER - [RFC3641]. Appendix A.4 provides an equivalent ABNF [RFC4234] - grammar for this syntax. - -2.9. CertificateListExactAssertion - - ( 1.3.6.1.1.15.5 - DESC 'X.509 Certificate List Exact Assertion' ) - - A value of this syntax is an X.509 CertificateListExactAssertion - [X.509, clause 11.3.5]. Values of this syntax MUST be encoded using - GSER [RFC3641]. Appendix A.5 provides an equivalent ABNF grammar for - this syntax. - - - - -Zeilenga Standards Track [Page 4] - -RFC 4523 LDAP X.509 Schema June 2006 - - -2.10. CertificateListAssertion - - ( 1.3.6.1.1.15.6 DESC 'X.509 Certificate List Assertion' ) - - A value of this syntax is an X.509 CertificateListAssertion [X.509, - clause 11.3.6]. Values of this syntax MUST be encoded using GSER - [RFC3641]. Appendix A.6 provides an equivalent ABNF [RFC4234] - grammar for this syntax. - -2.11. AlgorithmIdentifier - - ( 1.3.6.1.1.15.7 DESC 'X.509 Algorithm Identifier' ) - - A value of this syntax is an X.509 AlgorithmIdentifier [X.509, Clause - 7]. Values of this syntax MUST be encoded using GSER [RFC3641]. - - Appendix A.7 provides an equivalent ABNF [RFC4234] grammar for this - syntax. - -3. Matching Rules - - This section introduces a set of certificate and related matching - rules for use in LDAP. These rules are intended to act in accordance - with their X.500 counterparts. - -3.1. certificateExactMatch - - The certificateExactMatch matching rule compares the presented - certificate exact assertion value with an attribute value of the - certificate syntax as described in clause 11.3.1 of [X.509]. - - ( 2.5.13.34 NAME 'certificateExactMatch' - DESC 'X.509 Certificate Exact Match' - SYNTAX 1.3.6.1.1.15.1 ) - -3.2. certificateMatch - - The certificateMatch matching rule compares the presented certificate - assertion value with an attribute value of the certificate syntax as - described in clause 11.3.2 of [X.509]. - - ( 2.5.13.35 NAME 'certificateMatch' - DESC 'X.509 Certificate Match' - SYNTAX 1.3.6.1.1.15.2 ) - - - - - - - -Zeilenga Standards Track [Page 5] - -RFC 4523 LDAP X.509 Schema June 2006 - - -3.3. certificatePairExactMatch - - The certificatePairExactMatch matching rule compares the presented - certificate pair exact assertion value with an attribute value of the - certificate pair syntax as described in clause 11.3.3 of [X.509]. - - ( 2.5.13.36 NAME 'certificatePairExactMatch' - DESC 'X.509 Certificate Pair Exact Match' - SYNTAX 1.3.6.1.1.15.3 ) - -3.4. certificatePairMatch - - The certificatePairMatch matching rule compares the presented - certificate pair assertion value with an attribute value of the - certificate pair syntax as described in clause 11.3.4 of [X.509]. - - ( 2.5.13.37 NAME 'certificatePairMatch' - DESC 'X.509 Certificate Pair Match' - SYNTAX 1.3.6.1.1.15.4 ) - -3.5. certificateListExactMatch - - The certificateListExactMatch matching rule compares the presented - certificate list exact assertion value with an attribute value of the - certificate pair syntax as described in clause 11.3.5 of [X.509]. - - ( 2.5.13.38 NAME 'certificateListExactMatch' - DESC 'X.509 Certificate List Exact Match' - SYNTAX 1.3.6.1.1.15.5 ) - -3.6. certificateListMatch - - The certificateListMatch matching rule compares the presented - certificate list assertion value with an attribute value of the - certificate pair syntax as described in clause 11.3.6 of [X.509]. - - ( 2.5.13.39 NAME 'certificateListMatch' - DESC 'X.509 Certificate List Match' - SYNTAX 1.3.6.1.1.15.6 ) - - - - - - - - - - - - -Zeilenga Standards Track [Page 6] - -RFC 4523 LDAP X.509 Schema June 2006 - - -3.7. algorithmIdentifierMatch - - The algorithmIdentifierMatch mating rule compares a presented - algorithm identifier with an attribute value of the supported - algorithm as described in clause 11.3.7 of [X.509]. - - ( 2.5.13.40 NAME 'algorithmIdentifier' - DESC 'X.509 Algorithm Identifier Match' - SYNTAX 1.3.6.1.1.15.7 ) - -4. Attribute Types - - This section details a set of certificate and related attribute types - for use in LDAP. - -4.1. userCertificate - - The userCertificate attribute holds the X.509 certificates issued to - the user by one or more certificate authorities, as discussed in - clause 11.2.1 of [X.509]. - - ( 2.5.4.36 NAME 'userCertificate' - DESC 'X.509 user certificate' - EQUALITY certificateExactMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 ) - - As required by this attribute type's syntax, values of this attribute - are requested and transferred using the attribute description - "userCertificate;binary". - -4.2. cACertificate - - The cACertificate attribute holds the X.509 certificates issued to - the certificate authority (CA), as discussed in clause 11.2.2 of - [X.509]. - - ( 2.5.4.37 NAME 'cACertificate' - DESC 'X.509 CA certificate' - EQUALITY certificateExactMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 ) - - As required by this attribute type's syntax, values of this attribute - are requested and transferred using the attribute description - "cACertificate;binary". - - - - - - - -Zeilenga Standards Track [Page 7] - -RFC 4523 LDAP X.509 Schema June 2006 - - -4.3. crossCertificatePair - - The crossCertificatePair attribute holds an X.509 certificate pair, - as discussed in clause 11.2.3 of [X.509]. - - ( 2.5.4.40 NAME 'crossCertificatePair' - DESC 'X.509 cross certificate pair' - EQUALITY certificatePairExactMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.10 ) - - As required by this attribute type's syntax, values of this attribute - are requested and transferred using the attribute description - "crossCertificatePair;binary". - -4.4. certificateRevocationList - - The certificateRevocationList attribute holds certificate lists, as - discussed in 11.2.4 of [X.509]. - - ( 2.5.4.39 NAME 'certificateRevocationList' - DESC 'X.509 certificate revocation list' - EQUALITY certificateListExactMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 ) - - As required by this attribute type's syntax, values of this attribute - are requested and transferred using the attribute description - "certificateRevocationList;binary". - -4.5. authorityRevocationList - - The authorityRevocationList attribute holds certificate lists, as - discussed in 11.2.5 of [X.509]. - - ( 2.5.4.38 NAME 'authorityRevocationList' - DESC 'X.509 authority revocation list' - EQUALITY certificateListExactMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 ) - - As required by this attribute type's syntax, values of this attribute - are requested and transferred using the attribute description - "authorityRevocationList;binary". - - - - - - - - - - -Zeilenga Standards Track [Page 8] - -RFC 4523 LDAP X.509 Schema June 2006 - - -4.6. deltaRevocationList - - The deltaRevocationList attribute holds certificate lists, as - discussed in 11.2.6 of [X.509]. - - ( 2.5.4.53 NAME 'deltaRevocationList' - DESC 'X.509 delta revocation list' - EQUALITY certificateListExactMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 ) - - As required by this attribute type's syntax, values of this attribute - MUST be requested and transferred using the attribute description - "deltaRevocationList;binary". - -4.7. supportedAlgorithms - - The supportedAlgorithms attribute holds supported algorithms, as - discussed in 11.2.7 of [X.509]. - - ( 2.5.4.52 NAME 'supportedAlgorithms' - DESC 'X.509 supported algorithms' - EQUALITY algorithmIdentifierMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.49 ) - - As required by this attribute type's syntax, values of this attribute - MUST be requested and transferred using the attribute description - "supportedAlgorithms;binary". - -5. Object Classes - - This section details a set of certificate-related object classes for - use in LDAP. - -5.1. pkiUser - - This object class is used in augment entries for objects that may be - subject to certificates, as defined in clause 11.1.1 of [X.509]. - - ( 2.5.6.21 NAME 'pkiUser' - DESC 'X.509 PKI User' - SUP top AUXILIARY - MAY userCertificate ) - - - - - - - - - -Zeilenga Standards Track [Page 9] - -RFC 4523 LDAP X.509 Schema June 2006 - - -5.2. pkiCA - - This object class is used to augment entries for objects that act as - certificate authorities, as defined in clause 11.1.2 of [X.509] - - ( 2.5.6.22 NAME 'pkiCA' - DESC 'X.509 PKI Certificate Authority' - SUP top AUXILIARY - MAY ( cACertificate $ certificateRevocationList $ - authorityRevocationList $ crossCertificatePair ) ) - -5.3. cRLDistributionPoint - - This class is used to represent objects that act as CRL distribution - points, as discussed in clause 11.1.3 of [X.509]. - - ( 2.5.6.19 NAME 'cRLDistributionPoint' - DESC 'X.509 CRL distribution point' - SUP top STRUCTURAL - MUST cn - MAY ( certificateRevocationList $ - authorityRevocationList $ deltaRevocationList ) ) - -5.4. deltaCRL - - The deltaCRL object class is used to augment entries to hold delta - revocation lists, as discussed in clause 11.1.4 of [X.509]. - - ( 2.5.6.23 NAME 'deltaCRL' - DESC 'X.509 delta CRL' - SUP top AUXILIARY - MAY deltaRevocationList ) - -5.5. strongAuthenticationUser - - This object class is used to augment entries for objects - participating in certificate-based authentication, as defined in - clause 6.15 of [X.521]. This object class is deprecated in favor of - pkiUser. - - ( 2.5.6.15 NAME 'strongAuthenticationUser' - DESC 'X.521 strong authentication user' - SUP top AUXILIARY - MUST userCertificate ) - - - - - - - -Zeilenga Standards Track [Page 10] - -RFC 4523 LDAP X.509 Schema June 2006 - - -5.6. userSecurityInformation - - This object class is used to augment entries with needed additional - associated security information, as defined in clause 6.16 of - [X.521]. - - ( 2.5.6.18 NAME 'userSecurityInformation' - DESC 'X.521 user security information' - SUP top AUXILIARY - MAY ( supportedAlgorithms ) ) - -5.7. certificationAuthority - - This object class is used to augment entries for objects that act as - certificate authorities, as defined in clause 6.17 of [X.521]. This - object class is deprecated in favor of pkiCA. - - ( 2.5.6.16 NAME 'certificationAuthority' - DESC 'X.509 certificate authority' - SUP top AUXILIARY - MUST ( authorityRevocationList $ - certificateRevocationList $ cACertificate ) - MAY crossCertificatePair ) - -5.8. certificationAuthority-V2 - - This object class is used to augment entries for objects that act as - certificate authorities, as defined in clause 6.18 of [X.521]. This - object class is deprecated in favor of pkiCA. - - ( 2.5.6.16.2 NAME 'certificationAuthority-V2' - DESC 'X.509 certificate authority, version 2' - SUP certificationAuthority AUXILIARY - MAY deltaRevocationList ) - -6. Security Considerations - - General certificate considerations [RFC3280] apply to LDAP-aware - certificate applications. General LDAP security considerations - [RFC4510] apply as well. - - While elements of certificate information are commonly signed, these - signatures only protect the integrity of the signed information. In - the absence of data integrity protections in LDAP (or lower layer, - e.g., IPsec), a server is not assured that client certificate request - (or other request) was unaltered in transit. Likewise, a client - cannot be assured that the results of the query were unaltered in - - - - -Zeilenga Standards Track [Page 11] - -RFC 4523 LDAP X.509 Schema June 2006 - - - transit. Hence, it is generally recommended that implementations - make use of authentication and data integrity services in LDAP - [RFC4513][RFC4511]. - -7. IANA Considerations - -7.1. Object Identifier Registration - - The IANA has registered an LDAP Object Identifier [RFC4520] for use - in this technical specification. - - Subject: Request for LDAP OID Registration - Person & email address to contact for further information: - Kurt Zeilenga <kurt@OpenLDAP.org> - Specification: RFC 4523 - Author/Change Controller: IESG - Comments: - Identifies the LDAP X.509 Certificate schema elements - introduced in this document. - -7.2. Descriptor Registration - - The IANA has updated the LDAP - Descriptor registry [RFC44520] as indicated below. - - Subject: Request for LDAP Descriptor Registration - Descriptor (short name): see table - Object Identifier: see table - Person & email address to contact for further information: - Kurt Zeilenga <kurt@OpenLDAP.org> - Usage: see table - Specification: RFC 4523 - Author/Change Controller: IESG - - algorithmIdentifierMatch M 2.5.13.40 - authorityRevocationList A 2.5.4.38 * - cACertificate A 2.5.4.37 * - cRLDistributionPoint O 2.5.6.19 * - certificateExactMatch M 2.5.13.34 - certificateListExactMatch M 2.5.13.38 - certificateListMatch M 2.5.13.39 - certificateMatch M 2.5.13.35 - certificatePairExactMatch M 2.5.13.36 - certificatePairMatch M 2.5.13.37 - certificateRevocationList A 2.5.4.39 * - certificationAuthority O 2.5.6.16 * - certificationAuthority-V2 O 2.5.6.16.2 * - crossCertificatePair A 2.5.4.40 * - - - -Zeilenga Standards Track [Page 12] - -RFC 4523 LDAP X.509 Schema June 2006 - - - deltaCRL O 2.5.6.23 * - deltaRevocationList A 2.5.4.53 * - pkiCA O 2.5.6.22 * - pkiUser O 2.5.6.21 * - strongAuthenticationUser O 2.5.6.15 * - supportedAlgorithms A 2.5.4.52 * - userCertificate A 2.5.4.36 * - userSecurityInformation O 2.5.6.18 * - - * Updates previous registration - -8. Acknowledgements - - This document is based on X.509, a product of the ITU-T. A number of - LDAP schema definitions were based on those found in RFCs 2252 and - 2256, both products of the IETF ASID WG. The ABNF productions in - Appendix A were provided by Steven Legg. Additional material was - borrowed from prior works by David Chadwick and Steven Legg to refine - the LDAP X.509 schema. - -9. References - -9.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC3641] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1 - Types", RFC 3641, October 2003. - - [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol - (LDAP): Technical Specification Road Map", RFC 4510, June - 2006. - - [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP): Directory Information Models", RFC 4512, June - 2006. - - [RFC4522] Legg, S., "Lightweight Directory Access Protocol (LDAP): - The Binary Encoding Option", RFC 4522, June 2006. - - [X.509] International Telecommunication Union - Telecommunication - Standardization Sector, "The Directory: Authentication - Framework", X.509(2000). - - - - - - - -Zeilenga Standards Track [Page 13] - -RFC 4523 LDAP X.509 Schema June 2006 - - - [X.521] International Telecommunication Union - Telecommunication - Standardization Sector, "The Directory: Selected Object - Classes", X.521(2000). - - [X.690] International Telecommunication Union - Telecommunication - Standardization Sector, "Specification of ASN.1 encoding - rules: Basic Encoding Rules (BER), Canonical Encoding - Rules (CER), and Distinguished Encoding Rules (DER)", - X.690(2002) (also ISO/IEC 8825-1:2002). - -9.2. Informative References - - [RFC1777] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory - Access Protocol", RFC 1777, March 1995. - - [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): - Mapping between X.400 and RFC 822/MIME", RFC 2156, January - 1998. - - [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet - X.509 Public Key Infrastructure Certificate and - Certificate Revocation List (CRL) Profile", RFC 3280, - April 2002. - - [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol - version 2 (LDAPv2) to Historic Status", RFC 3494, March - 2003. - - [RFC3642] Legg, S., "Common Elements of Generic String Encoding - Rules (GSER) Encodings", RFC 3642, October 2003. - - [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 4234, October 2005. - - [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access - Protocol (LDAP): The Protocol", RFC 4511, June 2006. - - [RFC4513] Harrison, R. Ed., "Lightweight Directory Access Protocol - (LDAP): Authentication Methods and Security Mechanisms", - RFC 4513, June 2006. - - [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) - Considerations for the Lightweight Directory Access - Protocol (LDAP)", BCP 64, RFC 4520, June 2006. - - - - - - - -Zeilenga Standards Track [Page 14] - -RFC 4523 LDAP X.509 Schema June 2006 - - -Appendix A. - - This appendix is informative. - - This appendix provides ABNF [RFC4234] grammars for GSER-based - [RFC3641] LDAP-specific encodings specified in this document. These - grammars where produced using, and relying on, Common Elements for - GSER Encodings [RFC3642]. - -A.1. CertificateExactAssertion - - CertificateExactAssertion = "{" sp cea-serialNumber "," - sp cea-issuer sp "}" - - cea-serialNumber = id-serialNumber msp CertificateSerialNumber - cea-issuer = id-issuer msp Name - - id-serialNumber = - %x73.65.72.69.61.6C.4E.75.6D.62.65.72 ; 'serialNumber' - id-issuer = %x69.73.73.75.65.72 ; 'issuer' - - Name = id-rdnSequence ":" RDNSequence - id-rdnSequence = %x72.64.6E.53.65.71.75.65.6E.63.65 ; 'rdnSequence' - - CertificateSerialNumber = INTEGER - -A.2. CertificateAssertion - -CertificateAssertion = "{" [ sp ca-serialNumber ] - [ sep sp ca-issuer ] - [ sep sp ca-subjectKeyIdentifier ] - [ sep sp ca-authorityKeyIdentifier ] - [ sep sp ca-certificateValid ] - [ sep sp ca-privateKeyValid ] - [ sep sp ca-subjectPublicKeyAlgID ] - [ sep sp ca-keyUsage ] - [ sep sp ca-subjectAltName ] - [ sep sp ca-policy ] - [ sep sp ca-pathToName ] - [ sep sp ca-subject ] - [ sep sp ca-nameConstraints ] sp "}" - -ca-serialNumber = id-serialNumber msp CertificateSerialNumber -ca-issuer = id-issuer msp Name -ca-subjectKeyIdentifier = id-subjectKeyIdentifier msp - SubjectKeyIdentifier -ca-authorityKeyIdentifier = id-authorityKeyIdentifier msp - AuthorityKeyIdentifier - - - -Zeilenga Standards Track [Page 15] - -RFC 4523 LDAP X.509 Schema June 2006 - - -ca-certificateValid = id-certificateValid msp Time -ca-privateKeyValid = id-privateKeyValid msp GeneralizedTime -ca-subjectPublicKeyAlgID = id-subjectPublicKeyAlgID msp - OBJECT-IDENTIFIER -ca-keyUsage = id-keyUsage msp KeyUsage -ca-subjectAltName = id-subjectAltName msp AltNameType -ca-policy = id-policy msp CertPolicySet -ca-pathToName = id-pathToName msp Name -ca-subject = id-subject msp Name -ca-nameConstraints = id-nameConstraints msp NameConstraintsSyntax - -id-subjectKeyIdentifier = - %x73.75.62.6A.65.63.74.4B.65.79.49.64.65.6E.74.69.66.69.65.72 - ; 'subjectKeyIdentifier' -id-authorityKeyIdentifier = - %x61.75.74.68.6F.72.69.74.79.4B.65.79.49.64.65.6E.74.69.66.69.65.72 - ; 'authorityKeyIdentifier' -id-certificateValid = %x63.65.72.74.69.66.69.63.61.74.65.56.61.6C.69.64 - ; 'certificateValid' -id-privateKeyValid = %x70.72.69.76.61.74.65.4B.65.79.56.61.6C.69.64 - ; 'privateKeyValid' -id-subjectPublicKeyAlgID = - %x73.75.62.6A.65.63.74.50.75.62.6C.69.63.4B.65.79.41.6C.67.49.44 - ; 'subjectPublicKeyAlgID' -id-keyUsage = %x6B.65.79.55.73.61.67.65 ; 'keyUsage' -id-subjectAltName = %x73.75.62.6A.65.63.74.41.6C.74.4E.61.6D.65 - ; 'subjectAltName' -id-policy = %x70.6F.6C.69.63.79 ; 'policy' -id-pathToName = %x70.61.74.68.54.6F.4E.61.6D.65 ; 'pathToName' -id-subject = %x73.75.62.6A.65.63.74 ; 'subject' -id-nameConstraints = %x6E.61.6D.65.43.6F.6E.73.74.72.61.69.6E.74.73 - ; 'nameConstraints' - -SubjectKeyIdentifier = KeyIdentifier - -KeyIdentifier = OCTET-STRING - -AuthorityKeyIdentifier = "{" [ sp aki-keyIdentifier ] - [ sep sp aki-authorityCertIssuer ] - [ sep sp aki-authorityCertSerialNumber ] sp "}" - -aki-keyIdentifier = id-keyIdentifier msp KeyIdentifier -aki-authorityCertIssuer = id-authorityCertIssuer msp GeneralNames - -GeneralNames = "{" sp GeneralName *( "," sp GeneralName ) sp "}" -GeneralName = gn-otherName - / gn-rfc822Name - / gn-dNSName - - - -Zeilenga Standards Track [Page 16] - -RFC 4523 LDAP X.509 Schema June 2006 - - - / gn-x400Address - / gn-directoryName - / gn-ediPartyName - / gn-uniformResourceIdentifier - / gn-iPAddress - / gn-registeredID - -gn-otherName = id-otherName ":" OtherName -gn-rfc822Name = id-rfc822Name ":" IA5String -gn-dNSName = id-dNSName ":" IA5String -gn-x400Address = id-x400Address ":" ORAddress -gn-directoryName = id-directoryName ":" Name -gn-ediPartyName = id-ediPartyName ":" EDIPartyName -gn-iPAddress = id-iPAddress ":" OCTET-STRING -gn-registeredID = gn-id-registeredID ":" OBJECT-IDENTIFIER - -gn-uniformResourceIdentifier = id-uniformResourceIdentifier - ":" IA5String - -id-otherName = %x6F.74.68.65.72.4E.61.6D.65 ; 'otherName' -gn-id-registeredID = %x72.65.67.69.73.74.65.72.65.64.49.44 - ; 'registeredID' - -OtherName = "{" sp on-type-id "," sp on-value sp "}" -on-type-id = id-type-id msp OBJECT-IDENTIFIER -on-value = id-value msp Value - ;; <Value> as defined in Section 3 of [RFC3641] - -id-type-id = %x74.79.70.65.2D.69.64 ; 'type-id' -id-value = %x76.61.6C.75.65 ; 'value' - -ORAddress = dquote *SafeIA5Character dquote -SafeIA5Character = %x01-21 / %x23-7F / ; ASCII minus dquote - dquote dquote ; escaped double quote -dquote = %x22 ; '"' (double quote) - -;; Note: The <ORAddress> rule encodes the x400Address component -;; of a GeneralName as a character string between double quotes. -;; The character string is first derived according to Section 4.1 -;; of [RFC2156], and then any embedded double quotes are escaped -;; by being repeated. This resulting string is output between -;; double quotes. - -EDIPartyName = "{" [ sp nameAssigner "," ] sp partyName sp "}" -nameAssigner = id-nameAssigner msp DirectoryString -partyName = id-partyName msp DirectoryString -id-nameAssigner = %x6E.61.6D.65.41.73.73.69.67.6E.65.72 - ; 'nameAssigner' - - - -Zeilenga Standards Track [Page 17] - -RFC 4523 LDAP X.509 Schema June 2006 - - -id-partyName = %x70.61.72.74.79.4E.61.6D.65 ; 'partyName' - -aki-authorityCertSerialNumber = id-authorityCertSerialNumber - msp CertificateSerialNumber - -id-keyIdentifier = %x6B.65.79.49.64.65.6E.74.69.66.69.65.72 - ; 'keyIdentifier' -id-authorityCertIssuer = - %x61.75.74.68.6F.72.69.74.79.43.65.72.74.49.73.73.75.65.72 - ; 'authorityCertIssuer' - -id-authorityCertSerialNumber = %x61.75.74.68.6F.72.69.74.79.43 - %x65.72.74.53.65.72.69.61.6C.4E.75.6D.62.65.72 - ; 'authorityCertSerialNumber' - -Time = time-utcTime / time-generalizedTime -time-utcTime = id-utcTime ":" UTCTime -time-generalizedTime = id-generalizedTime ":" GeneralizedTime -id-utcTime = %x75.74.63.54.69.6D.65 ; 'utcTime' -id-generalizedTime = %x67.65.6E.65.72.61.6C.69.7A.65.64.54.69.6D.65 - ; 'generalizedTime' - -KeyUsage = BIT-STRING / key-usage-bit-list -key-usage-bit-list = "{" [ sp key-usage *( "," sp key-usage ) ] sp "}" - -;; Note: The <key-usage-bit-list> rule encodes the one bits in -;; a KeyUsage value as a comma separated list of identifiers. - -key-usage = id-digitalSignature - / id-nonRepudiation - / id-keyEncipherment - / id-dataEncipherment - / id-keyAgreement - / id-keyCertSign - / id-cRLSign - / id-encipherOnly - / id-decipherOnly - -id-digitalSignature = %x64.69.67.69.74.61.6C.53.69.67.6E.61.74 - %x75.72.65 ; 'digitalSignature' -id-nonRepudiation = %x6E.6F.6E.52.65.70.75.64.69.61.74.69.6F.6E - ; 'nonRepudiation' -id-keyEncipherment = %x6B.65.79.45.6E.63.69.70.68.65.72.6D.65.6E.74 - ; 'keyEncipherment' -id-dataEncipherment = %x64.61.74.61.45.6E.63.69.70.68.65.72.6D.65.6E - %x74 ; "dataEncipherment' -id-keyAgreement = %x6B.65.79.41.67.72.65.65.6D.65.6E.74 - ; 'keyAgreement' - - - -Zeilenga Standards Track [Page 18] - -RFC 4523 LDAP X.509 Schema June 2006 - - -id-keyCertSign = %x6B.65.79.43.65.72.74.53.69.67.6E - ; 'keyCertSign' -id-cRLSign = %x63.52.4C.53.69.67.6E ; "cRLSign" -id-encipherOnly = %x65.6E.63.69.70.68.65.72.4F.6E.6C.79 - ; 'encipherOnly' -id-decipherOnly = %x64.65.63.69.70.68.65.72.4F.6E.6C.79 - ; 'decipherOnly' - -AltNameType = ant-builtinNameForm / ant-otherNameForm - -ant-builtinNameForm = id-builtinNameForm ":" BuiltinNameForm -ant-otherNameForm = id-otherNameForm ":" OBJECT-IDENTIFIER - -id-builtinNameForm = %x62.75.69.6C.74.69.6E.4E.61.6D.65.46.6F.72.6D - ; 'builtinNameForm' -id-otherNameForm = %x6F.74.68.65.72.4E.61.6D.65.46.6F.72.6D - ; 'otherNameForm' - -BuiltinNameForm = id-rfc822Name - / id-dNSName - / id-x400Address - / id-directoryName - / id-ediPartyName - / id-uniformResourceIdentifier - / id-iPAddress - / id-registeredId - -id-rfc822Name = %x72.66.63.38.32.32.4E.61.6D.65 ; 'rfc822Name' -id-dNSName = %x64.4E.53.4E.61.6D.65 ; 'dNSName' -id-x400Address = %x78.34.30.30.41.64.64.72.65.73.73 ; 'x400Address' -id-directoryName = %x64.69.72.65.63.74.6F.72.79.4E.61.6D.65 - ; 'directoryName' -id-ediPartyName = %x65.64.69.50.61.72.74.79.4E.61.6D.65 - ; 'ediPartyName' -id-iPAddress = %x69.50.41.64.64.72.65.73.73 ; 'iPAddress' -id-registeredId = %x72.65.67.69.73.74.65.72.65.64.49.64 - ; 'registeredId' - -id-uniformResourceIdentifier = %x75.6E.69.66.6F.72.6D.52.65.73.6F.75 - %x72.63.65.49.64.65.6E.74.69.66.69.65.72 - ; 'uniformResourceIdentifier' - -CertPolicySet = "{" sp CertPolicyId *( "," sp CertPolicyId ) sp "}" -CertPolicyId = OBJECT-IDENTIFIER - -NameConstraintsSyntax = "{" [ sp ncs-permittedSubtrees ] - [ sep sp ncs-excludedSubtrees ] sp "}" - - - - -Zeilenga Standards Track [Page 19] - -RFC 4523 LDAP X.509 Schema June 2006 - - -ncs-permittedSubtrees = id-permittedSubtrees msp GeneralSubtrees -ncs-excludedSubtrees = id-excludedSubtrees msp GeneralSubtrees - -id-permittedSubtrees = - %x70.65.72.6D.69.74.74.65.64.53.75.62.74.72.65.65.73 - ; 'permittedSubtrees' -id-excludedSubtrees = - %x65.78.63.6C.75.64.65.64.53.75.62.74.72.65.65.73 - ; 'excludedSubtrees' - -GeneralSubtrees = "{" sp GeneralSubtree - *( "," sp GeneralSubtree ) sp "}" -GeneralSubtree = "{" sp gs-base - [ "," sp gs-minimum ] - [ "," sp gs-maximum ] sp "}" - -gs-base = id-base msp GeneralName -gs-minimum = id-minimum msp BaseDistance -gs-maximum = id-maximum msp BaseDistance - -id-base = %x62.61.73.65 ; 'base' -id-minimum = %x6D.69.6E.69.6D.75.6D ; 'minimum' -id-maximum = %x6D.61.78.69.6D.75.6D ; 'maximum' - -BaseDistance = INTEGER-0-MAX - -A.3. CertificatePairExactAssertion - - CertificatePairExactAssertion = "{" [ sp cpea-issuedTo ] - [sep sp cpea-issuedBy ] sp "}" - ;; At least one of <cpea-issuedTo> or <cpea-issuedBy> MUST be present. - - cpea-issuedTo = id-issuedToThisCAAssertion msp - CertificateExactAssertion - cpea-issuedBy = id-issuedByThisCAAssertion msp - CertificateExactAssertion - - id-issuedToThisCAAssertion = %x69.73.73.75.65.64.54.6F.54.68.69.73 - %x43.41.41.73.73.65.72.74.69.6F.6E ; 'issuedToThisCAAssertion' - id-issuedByThisCAAssertion = %x69.73.73.75.65.64.42.79.54.68.69.73 - %x43.41.41.73.73.65.72.74.69.6F.6E ; 'issuedByThisCAAssertion' - - - - - - - - - - -Zeilenga Standards Track [Page 20] - -RFC 4523 LDAP X.509 Schema June 2006 - - -A.4. CertificatePairAssertion - - CertificatePairAssertion = "{" [ sp cpa-issuedTo ] - [sep sp cpa-issuedBy ] sp "}" - ;; At least one of <cpa-issuedTo> and <cpa-issuedBy> MUST be present. - - cpa-issuedTo = id-issuedToThisCAAssertion msp CertificateAssertion - cpa-issuedBy = id-issuedByThisCAAssertion msp CertificateAssertion - -A.5. CertificateListExactAssertion - - CertificateListExactAssertion = "{" sp clea-issuer "," - sp clea-thisUpdate - [ "," sp clea-distributionPoint ] sp "}" - - clea-issuer = id-issuer msp Name - clea-thisUpdate = id-thisUpdate msp Time - clea-distributionPoint = id-distributionPoint msp - DistributionPointName - - id-thisUpdate = %x74.68.69.73.55.70.64.61.74.65 ; 'thisUpdate' - id-distributionPoint = - %x64.69.73.74.72.69.62.75.74.69.6F.6E.50.6F.69.6E.74 - ; 'distributionPoint' - - DistributionPointName = dpn-fullName / dpn-nameRelativeToCRLIssuer - - dpn-fullName = id-fullName ":" GeneralNames - dpn-nameRelativeToCRLIssuer = id-nameRelativeToCRLIssuer ":" - RelativeDistinguishedName - - id-fullName = %x66.75.6C.6C.4E.61.6D.65 ; 'fullName' - id-nameRelativeToCRLIssuer = %x6E.61.6D.65.52.65.6C.61.74.69.76.65 - %x54.6F.43.52.4C.49.73.73.75.65.72 ; 'nameRelativeToCRLIssuer' - -A.6. CertificateListAssertion - - CertificateListAssertion = "{" [ sp cla-issuer ] - [ sep sp cla-minCRLNumber ] - [ sep sp cla-maxCRLNumber ] - [ sep sp cla-reasonFlags ] - [ sep sp cla-dateAndTime ] - [ sep sp cla-distributionPoint ] - [ sep sp cla-authorityKeyIdentifier ] sp "}" - - cla-issuer = id-issuer msp Name - cla-minCRLNumber = id-minCRLNumber msp CRLNumber - cla-maxCRLNumber = id-maxCRLNumber msp CRLNumber - - - -Zeilenga Standards Track [Page 21] - -RFC 4523 LDAP X.509 Schema June 2006 - - - cla-reasonFlags = id-reasonFlags msp ReasonFlags - cla-dateAndTime = id-dateAndTime msp Time - - cla-distributionPoint = id-distributionPoint msp - DistributionPointName - - cla-authorityKeyIdentifier = id-authorityKeyIdentifier msp - AuthorityKeyIdentifier - - id-minCRLNumber = %x6D.69.6E.43.52.4C.4E.75.6D.62.65.72 - ; 'minCRLNumber' - id-maxCRLNumber = %x6D.61.78.43.52.4C.4E.75.6D.62.65.72 - ; 'maxCRLNumber' - id-reasonFlags = %x72.65.61.73.6F.6E.46.6C.61.67.73 ; 'reasonFlags' - id-dateAndTime = %x64.61.74.65.41.6E.64.54.69.6D.65 ; 'dateAndTime' - - CRLNumber = INTEGER-0-MAX - - ReasonFlags = BIT-STRING - / "{" [ sp reason-flag *( "," sp reason-flag ) ] sp "}" - - reason-flag = id-unused - / id-keyCompromise - / id-cACompromise - / id-affiliationChanged - / id-superseded - / id-cessationOfOperation - / id-certificateHold - / id-privilegeWithdrawn - / id-aACompromise - - id-unused = %x75.6E.75.73.65.64 ; 'unused' - id-keyCompromise = %x6B.65.79.43.6F.6D.70.72.6F.6D.69.73.65 - ; 'keyCompromise' - id-cACompromise = %x63.41.43.6F.6D.70.72.6F.6D.69.73.65 - ; 'cACompromise' - id-affiliationChanged = - %x61.66.66.69.6C.69.61.74.69.6F.6E.43.68.61.6E.67.65.64 - ; 'affiliationChanged' - id-superseded = %x73.75.70.65.72.73.65.64.65.64 ; 'superseded' - id-cessationOfOperation = - %x63.65.73.73.61.74.69.6F.6E.4F.66.4F.70.65.72.61.74.69.6F.6E - ; 'cessationOfOperation' - id-certificateHold = %x63.65.72.74.69.66.69.63.61.74.65.48.6F.6C.64 - ; 'certificateHold' - id-privilegeWithdrawn = - %x70.72.69.76.69.6C.65.67.65.57.69.74.68.64.72.61.77.6E - ; 'privilegeWithdrawn' - - - -Zeilenga Standards Track [Page 22] - -RFC 4523 LDAP X.509 Schema June 2006 - - - id-aACompromise = %x61.41.43.6F.6D.70.72.6F.6D.69.73.65 - ; 'aACompromise' - -A.7. AlgorithmIdentifier - - AlgorithmIdentifier = "{" sp ai-algorithm - [ "," sp ai-parameters ] sp "}" - - ai-algorithm = id-algorithm msp OBJECT-IDENTIFIER - ai-parameters = id-parameters msp Value - id-algorithm = %x61.6C.67.6F.72.69.74.68.6D ; 'algorithm' - id-parameters = %x70.61.72.61.6D.65.74.65.72.73 ; 'parameters' - -Author's Address - - Kurt D. Zeilenga - OpenLDAP Foundation - - EMail: Kurt@OpenLDAP.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Zeilenga Standards Track [Page 23] - -RFC 4523 LDAP X.509 Schema June 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Zeilenga Standards Track [Page 24] - diff --git a/source4/ldap_server/devdocs/rfc4524.txt b/source4/ldap_server/devdocs/rfc4524.txt deleted file mode 100644 index fa36be27a3..0000000000 --- a/source4/ldap_server/devdocs/rfc4524.txt +++ /dev/null @@ -1,1403 +0,0 @@ - - - - - - -Network Working Group K. Zeilenga, Ed. -Request for Comments: 4524 OpenLDAP Foundation -Obsoletes: 1274 June 2006 -Updates: 2247, 2798 -Category: Standards Track - - - COSINE LDAP/X.500 Schema - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document provides a collection of schema elements for use with - the Lightweight Directory Access Protocol (LDAP) from the COSINE and - Internet X.500 pilot projects. - - This document obsoletes RFC 1274 and updates RFCs 2247 and 2798. - -Table of Contents - - 1. Introduction ....................................................3 - 1.1. Relationship to Other Documents ............................3 - 1.2. Terminology and Conventions ................................4 - 2. COSINE Attribute Types ..........................................4 - 2.1. associatedDomain ...........................................4 - 2.2. associatedName .............................................5 - 2.3. buildingName ...............................................5 - 2.4. co .........................................................5 - 2.5. documentAuthor .............................................6 - 2.6. documentIdentifier .........................................6 - 2.7. documentLocation ...........................................6 - 2.8. documentPublisher ..........................................7 - 2.9. documentTitle ..............................................7 - 2.10. documentVersion ...........................................7 - 2.11. drink .....................................................8 - 2.12. homePhone .................................................8 - 2.13. homePostalAddress .........................................8 - - - -Zeilenga Standards Track [Page 1] - -RFC 4524 COSINE LDAP/X.500 Schema June 2006 - - - 2.14. host ......................................................9 - 2.15. info ......................................................9 - 2.16. mail ......................................................9 - 2.17. manager ..................................................10 - 2.18. mobile ...................................................10 - 2.19. organizationalStatus .....................................11 - 2.20. pager ....................................................11 - 2.21. personalTitle ............................................11 - 2.22. roomNumber ...............................................12 - 2.23. secretary ................................................12 - 2.24. uniqueIdentifier .........................................12 - 2.25. userClass ................................................13 - 3. COSINE Object Classes ..........................................13 - 3.1. account ...................................................13 - 3.2. document ..................................................14 - 3.3. documentSeries ............................................14 - 3.4. domain ....................................................15 - 3.5. domainRelatedObject .......................................16 - 3.6. friendlyCountry ...........................................16 - 3.7. rFC822LocalPart ...........................................17 - 3.8. room ......................................................18 - 3.9. simpleSecurityObject ......................................18 - 4. Security Considerations ........................................18 - 5. IANA Considerations ............................................19 - 6. Acknowledgements ...............................................20 - 7. References .....................................................20 - 7.1. Normative References ......................................20 - 7.2. Informative References ....................................21 - Appendix A. Changes since RFC 1274 ...............................23 - A.1. LDAP Short Names .........................................23 - A.2. pilotObject ..............................................23 - A.3. pilotPerson ..............................................23 - A.4. dNSDomain ................................................24 - A.5. pilotDSA and qualityLabelledData .........................24 - A.6. Attribute Syntaxes .......................................24 - Appendix B. Changes since RFC 2247 ...............................24 - - - - - - - - - - - - - - - -Zeilenga Standards Track [Page 2] - -RFC 4524 COSINE LDAP/X.500 Schema June 2006 - - -1. Introduction - - In the late 1980s, X.500 Directory Services were standardized by the - CCITT (Commite' Consultatif International de Telegraphique et - Telephonique), now a part of the ITU (International Telephone Union). - This lead to Directory Service piloting activities in the early - 1990s, including the COSINE (Co-operation and Open Systems - Interconnection in Europe) PARADISE Project pilot [COSINEpilot] in - Europe. Motivated by needs for large-scale directory pilots, RFC - 1274 was published to standardize the directory schema and naming - architecture for use in the COSINE and other Internet X.500 pilots - [RFC1274]. - - In the years that followed, X.500 Directory Services have evolved to - incorporate new capabilities and even new protocols. In particular, - the Lightweight Directory Access Protocol (LDAP) [RFC4510] was - introduced in the early 1990s [RFC1487], with Version 3 of LDAP - introduced in the late 1990s [RFC2251] and subsequently revised in - 2005 [RFC4510]. - - While much of the material in RFC 1274 has been superceded by - subsequently published ITU-T Recommendations and IETF RFCs, many of - the schema elements lack standardized schema descriptions for use in - modern X.500 and LDAP directory services despite the fact that these - schema elements are in wide use today. As the old schema - descriptions cannot be used without adaptation, interoperability - issues may arise due to lack of standardized modern schema - descriptions. - - This document addresses these issues by offering standardized schema - descriptions, where needed, for widely used COSINE schema elements. - -1.1. Relationship to Other Documents - - This document, together with [RFC4519] and [RFC4517], obsoletes RFC - 1274 in its entirety. [RFC4519] replaces Sections 9.3.1 (Userid) and - 9.3.21 (Domain Component) of RFC 1274. [RFC4517] replaces Section - 9.4 (Generally useful syntaxes) of RFC 1274. - - This document replaces the remainder of RFC 1274. Appendix A - discusses changes since RFC 1274, as well as why certain schema - elements were not brought forward in this revision of the COSINE - schema. All elements not brought are to be regarded as Historic. - - The description of the 'domain' object class provided in this - document supercedes that found in RFC 2247. That is, Section 3.4 of - this document replaces Section 5.2 of [RFC2247]. - - - - -Zeilenga Standards Track [Page 3] - -RFC 4524 COSINE LDAP/X.500 Schema June 2006 - - - Some of the schema elements specified here were described in RFC 2798 - (inetOrgPerson schema). This document supersedes these descriptions. - This document, together with [RFC4519], replaces Section 9.1.3 of RFC - 2798. - -1.2. Terminology and Conventions - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in BCP 14 [RFC2119]. - - DIT stands for Directory Information Tree. - DN stands for Distinguished Name. - DSA stands for Directory System Agent, a server. - DSE stands for DSA-Specific Entry. - DUA stands for Directory User Agent, a client. - - These terms are discussed in [RFC4512]. - - Schema definitions are provided using LDAP description formats - [RFC4512]. Definitions provided here are formatted (line wrapped) - for readability. - -2. COSINE Attribute Types - - This section details COSINE attribute types for use in LDAP. - -2.1. associatedDomain - - The 'associatedDomain' attribute specifies DNS [RFC1034][RFC2181] - host names [RFC1123] that are associated with an object. That is, - values of this attribute should conform to the following ABNF: - - domain = root / label *( DOT label ) - root = SPACE - label = LETDIG [ *61( LETDIG / HYPHEN ) LETDIG ] - LETDIG = %x30-39 / %x41-5A / %x61-7A ; "0" - "9" / "A"-"Z" / "a"-"z" - SPACE = %x20 ; space (" ") - HYPHEN = %x2D ; hyphen ("-") - DOT = %x2E ; period (".") - - For example, the entry in the DIT with a DN <DC=example,DC=com> might - have an associated domain of "example.com". - - ( 0.9.2342.19200300.100.1.37 NAME 'associatedDomain' - EQUALITY caseIgnoreIA5Match - SUBSTR caseIgnoreIA5SubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) - - - -Zeilenga Standards Track [Page 4] - -RFC 4524 COSINE LDAP/X.500 Schema June 2006 - - - The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the - 'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are - described in [RFC4517]. - - Note that the directory will not ensure that values of this attribute - conform to the <domain> production provided above. It is the - application's responsibility to ensure that domains it stores in this - attribute are appropriately represented. - - Also note that applications supporting Internationalized Domain Names - SHALL use the ToASCII method [RFC3490] to produce <label> components - of the <domain> production. - -2.2. associatedName - - The 'associatedName' attribute specifies names of entries in the - organizational DIT associated with a DNS domain [RFC1034][RFC2181]. - - ( 0.9.2342.19200300.100.1.38 NAME 'associatedName' - EQUALITY distinguishedNameMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) - - The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the - 'distinguishedNameMatch' rule are described in [RFC4517]. - -2.3. buildingName - - The 'buildingName' attribute specifies names of the buildings where - an organization or organizational unit is based, for example, "The - White House". - - ( 0.9.2342.19200300.100.1.48 NAME 'buildingName' - EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) - - The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the - 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described - in [RFC4517]. - -2.4. co - - The 'co' (Friendly Country Name) attribute specifies names of - countries in human-readable format, for example, "Germany" and - "Federal Republic of Germany". It is commonly used in conjunction - with the 'c' (Country Name) [RFC4519] attribute (whose values are - restricted to the two-letter codes defined in [ISO3166]). - - - - -Zeilenga Standards Track [Page 5] - -RFC 4524 COSINE LDAP/X.500 Schema June 2006 - - - ( 0.9.2342.19200300.100.1.43 NAME 'co' - EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) - - The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the - 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described - in [RFC4517]. - -2.5. documentAuthor - - The 'documentAuthor' attribute specifies the distinguished names of - authors (or editors) of a document. For example, - - ( 0.9.2342.19200300.100.1.14 NAME 'documentAuthor' - EQUALITY distinguishedNameMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) - - The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the - 'distinguishedNameMatch' rule are described in [RFC4517]. - -2.6. documentIdentifier - - The 'documentIdentifier' attribute specifies unique identifiers for a - document. A document may be identified by more than one unique - identifier. For example, RFC 3383 and BCP 64 are unique identifiers - that (presently) refer to the same document. - - ( 0.9.2342.19200300.100.1.11 NAME 'documentIdentifier' - EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) - - The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the - 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described - in [RFC4517]. - -2.7. documentLocation - - The 'documentLocation' attribute specifies locations of the document - original. - - ( 0.9.2342.19200300.100.1.15 NAME 'documentLocation' - EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) - - - - - -Zeilenga Standards Track [Page 6] - -RFC 4524 COSINE LDAP/X.500 Schema June 2006 - - - The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the - 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described - in [RFC4517]. - -2.8. documentPublisher - - The 'documentPublisher' attribute is the persons and/or organizations - that published the document. Documents that are jointly published - have one value for each publisher. - - ( 0.9.2342.19200300.100.1.56 NAME 'documentPublisher' - EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) - - The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the - 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described - in [RFC4517]. - -2.9. documentTitle - - The 'documentTitle' attribute specifies the titles of a document. - Multiple values are allowed to accommodate both long and short - titles, or other situations where a document has multiple titles, for - example, "The Lightweight Directory Access Protocol Technical - Specification" and "The LDAP Technical Specification". - - ( 0.9.2342.19200300.100.1.12 NAME 'documentTitle' - EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) - - The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the - 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described - in [RFC4517]. - -2.10. documentVersion - - The 'documentVersion' attribute specifies the version information of - a document. - - ( 0.9.2342.19200300.100.1.13 NAME 'documentVersion' - EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) - - - - - - -Zeilenga Standards Track [Page 7] - -RFC 4524 COSINE LDAP/X.500 Schema June 2006 - - - The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the - 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described - in [RFC4517]. - -2.11. drink - - The 'drink' (favoriteDrink) attribute specifies the favorite drinks - of an object (or person), for instance, "cola" and "beer". - - ( 0.9.2342.19200300.100.1.5 NAME 'drink' - EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) - - The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the - 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described - in [RFC4517]. - -2.12. homePhone - - The 'homePhone' (Home Telephone Number) attribute specifies home - telephone numbers (e.g., "+1 775 555 1234") associated with a person. - - ( 0.9.2342.19200300.100.1.20 NAME 'homePhone' - EQUALITY telephoneNumberMatch - SUBSTR telephoneNumberSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) - - The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the - 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are - described in [RFC4517]. - -2.13. homePostalAddress - - The 'homePostalAddress' attribute specifies home postal addresses for - an object. Each value should be limited to up to 6 directory strings - of 30 characters each. (Note: It is not intended that the directory - service enforce these limits.) - - ( 0.9.2342.19200300.100.1.39 NAME 'homePostalAddress' - EQUALITY caseIgnoreListMatch - SUBSTR caseIgnoreListSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) - - The PostalAddress (1.3.6.1.4.1.1466.115.121.1.41) syntax and the - 'caseIgnoreListMatch' and 'caseIgnoreListSubstringsMatch' rules are - described in [RFC4517]. - - - - -Zeilenga Standards Track [Page 8] - -RFC 4524 COSINE LDAP/X.500 Schema June 2006 - - -2.14. host - - The 'host' attribute specifies host computers, generally by their - primary fully qualified domain name (e.g., my-host.example.com). - - ( 0.9.2342.19200300.100.1.9 NAME 'host' - EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) - - The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the - 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described - in [RFC4517]. - -2.15. info - - The 'info' attribute specifies any general information pertinent to - an object. This information is not necessarily descriptive of the - object. - - Applications should not attach specific semantics to values of this - attribute. The 'description' attribute [RFC4519] is available for - specifying descriptive information pertinent to an object. - - ( 0.9.2342.19200300.100.1.4 NAME 'info' - EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{2048} ) - - The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the - 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described - in [RFC4517]. - -2.16. mail - - The 'mail' (rfc822mailbox) attribute type holds Internet mail - addresses in Mailbox [RFC2821] form (e.g., user@example.com). - - ( 0.9.2342.19200300.100.1.3 NAME 'mail' - EQUALITY caseIgnoreIA5Match - SUBSTR caseIgnoreIA5SubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) - - The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the - 'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are - described in [RFC4517]. - - - - - -Zeilenga Standards Track [Page 9] - -RFC 4524 COSINE LDAP/X.500 Schema June 2006 - - - Note that the directory will not ensure that values of this attribute - conform to the <Mailbox> production [RFC2821]. It is the - application's responsibility to ensure that domains it stores in this - attribute are appropriately represented. - - Additionally, the directory will compare values per the matching - rules named in the above attribute type description. As these rules - differ from rules that normally apply to <Mailbox> comparisons, - operational issues may arise. For example, the assertion - (mail=joe@example.com) will match "JOE@example.com" even though the - <local-parts> differ. Also, where a user has two <Mailbox>es whose - addresses differ only by case of the <local-part>, both cannot be - listed as values of the user's mail attribute (as they are considered - equal by the 'caseIgnoreIA5Match' rule). - - Also note that applications supporting internationalized domain names - SHALL use the ToASCII method [RFC3490] to produce <sub-domain> - components of the <Mailbox> production. - -2.17. manager - - The 'manager' attribute specifies managers, by distinguished name, of - the person (or entity). - - ( 0.9.2342.19200300.100.1.10 NAME 'manager' - EQUALITY distinguishedNameMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) - - The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the - 'distinguishedNameMatch' rule are described in [RFC4517]. - -2.18. mobile - - The 'mobile' (mobileTelephoneNumber) attribute specifies mobile - telephone numbers (e.g., "+1 775 555 6789") associated with a person - (or entity). - - ( 0.9.2342.19200300.100.1.41 NAME 'mobile' - EQUALITY telephoneNumberMatch - SUBSTR telephoneNumberSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) - - The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the - 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are - described in [RFC4517]. - - - - - - -Zeilenga Standards Track [Page 10] - -RFC 4524 COSINE LDAP/X.500 Schema June 2006 - - -2.19. organizationalStatus - - The 'organizationalStatus' attribute specifies categories by which a - person is often referred to in an organization. Examples of usage in - academia might include "undergraduate student", "researcher", - "professor", and "staff". Multiple values are allowed where the - person is in multiple categories. - - Directory administrators and application designers SHOULD consider - carefully the distinctions between this and the 'title' and - 'userClass' attributes. - - ( 0.9.2342.19200300.100.1.45 NAME 'organizationalStatus' - EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) - - The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the - 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described - in [RFC4517]. - -2.20. pager - - The 'pager' (pagerTelephoneNumber) attribute specifies pager - telephone numbers (e.g., "+1 775 555 5555") for an object. - - ( 0.9.2342.19200300.100.1.42 NAME 'pager' - EQUALITY telephoneNumberMatch - SUBSTR telephoneNumberSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) - - The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the - 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are - described in [RFC4517]. - -2.21. personalTitle - - The 'personalTitle' attribute specifies personal titles for a person. - Examples of personal titles are "Frau", "Dr.", "Herr", and - "Professor". - - ( 0.9.2342.19200300.100.1.40 NAME 'personalTitle' - EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) - - - - - - -Zeilenga Standards Track [Page 11] - -RFC 4524 COSINE LDAP/X.500 Schema June 2006 - - - The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the - 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described - in [RFC4517]. - -2.22. roomNumber - - The 'roomNumber' attribute specifies the room number of an object. - During periods of renumbering, or in other circumstances where a room - has multiple valid room numbers associated with it, multiple values - may be provided. Note that the 'cn' (commonName) attribute type - SHOULD be used for naming room objects. - - ( 0.9.2342.19200300.100.1.6 NAME 'roomNumber' - EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) - - The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the - 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described - in [RFC4517]. - -2.23. secretary - - The 'secretary' attribute specifies secretaries and/or administrative - assistants, by distinguished name. - - ( 0.9.2342.19200300.100.1.21 NAME 'secretary' - EQUALITY distinguishedNameMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) - - The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the - 'distinguishedNameMatch' rule are described in [RFC4517]. - -2.24. uniqueIdentifier - - The 'uniqueIdentifier' attribute specifies a unique identifier for an - object represented in the Directory. The domain within which the - identifier is unique and the exact semantics of the identifier are - for local definition. For a person, this might be an institution- - wide payroll number. For an organizational unit, it might be a - department code. - - ( 0.9.2342.19200300.100.1.44 NAME 'uniqueIdentifier' - EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) - - - - - -Zeilenga Standards Track [Page 12] - -RFC 4524 COSINE LDAP/X.500 Schema June 2006 - - - The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the - 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described - in [RFC4517]. - - Note: X.520 also describes an attribute called 'uniqueIdentifier' - (2.5.4.45), which is called 'x500UniqueIdentifier' in LDAP - [RFC4519]. The attribute detailed here ought not be confused - with 'x500UniqueIdentifier'. - -2.25. userClass - - The 'userClass' attribute specifies categories of computer or - application user. The semantics placed on this attribute are for - local interpretation. Examples of current usage of this attribute in - academia are "student", "staff", and "faculty". Note that the - 'organizationalStatus' attribute type is now often preferred, as it - makes no distinction between persons as opposed to users. - - ( 0.9.2342.19200300.100.1.8 NAME 'userClass' - EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) - - The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the - 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described - in [RFC4517]. - -3. COSINE Object Classes - - This section details COSINE object classes for use in LDAP. - -3.1. account - - The 'account' object class is used to define entries representing - computer accounts. The 'uid' attribute SHOULD be used for naming - entries of this object class. - - ( 0.9.2342.19200300.100.4.5 NAME 'account' - SUP top STRUCTURAL - MUST uid - MAY ( description $ seeAlso $ l $ o $ ou $ host ) ) - - The 'top' object class is described in [RFC4512]. The 'description', - 'seeAlso', 'l', 'o', 'ou', and 'uid' attribute types are described in - [RFC4519]. The 'host' attribute type is described in Section 2 of - this document. - - - - - -Zeilenga Standards Track [Page 13] - -RFC 4524 COSINE LDAP/X.500 Schema June 2006 - - - 3.3. documentSeriesExample: - - dn: uid=kdz,cn=Accounts,dc=Example,dc=COM - objectClass: account - uid: kdz - seeAlso: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM - -3.2. document - - The 'document' object class is used to define entries that represent - documents. - - ( 0.9.2342.19200300.100.4.6 NAME 'document' - SUP top STRUCTURAL - MUST documentIdentifier - MAY ( cn $ description $ seeAlso $ l $ o $ ou $ - documentTitle $ documentVersion $ documentAuthor $ - documentLocation $ documentPublisher ) ) - - The 'top' object class is described in [RFC4512]. The 'cn', - 'description', 'seeAlso', 'l', 'o', and 'ou' attribute types are - described in [RFC4519]. The 'documentIdentifier', 'documentTitle', - 'documentVersion', 'documentAuthor', 'documentLocation', and - 'documentPublisher' attribute types are described in Section 2 of - this document. - - Example: - - dn: documentIdentifier=RFC 4524,cn=RFC,dc=Example,dc=COM - objectClass: document - documentIdentifier: RFC 4524 - documentTitle: COSINE LDAP/X.500 Schema - documentAuthor: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM - documentLocation: http://www.rfc-editor.org/rfc/rfc4524.txt - documentPublisher: Internet Engineering Task Force - description: A collection of schema elements for use in LDAP - description: Obsoletes RFC 1274 - seeAlso: documentIdentifier=RFC 4510,cn=RFC,dc=Example,dc=COM - seeAlso: documentIdentifier=RFC 1274,cn=RFC,dc=Example,dc=COM - -3.3. documentSeries - - The 'documentSeries' object class is used to define an entry that - represents a series of documents (e.g., The Request For Comments - memos). - - - - - - -Zeilenga Standards Track [Page 14] - -RFC 4524 COSINE LDAP/X.500 Schema June 2006 - - - ( 0.9.2342.19200300.100.4.9 NAME 'documentSeries' - SUP top STRUCTURAL - MUST cn - MAY ( description $ l $ o $ ou $ seeAlso $ - telephonenumber ) ) - - The 'top' object class is described in [RFC4512]. The 'description', - 'l', 'o', 'ou', 'seeAlso', and 'telephoneNumber' attribute types are - described in [RFC4519]. - - Example: - - dn: cn=RFC,dc=Example,dc=COM - objectClass: documentSeries - cn: Request for Comments - cn: RFC - description: a series of memos about the Internet - -3.4. domain - - The 'domain' object class is used to define entries that represent - DNS domains for objects that are not organizations, organizational - units, or other kinds of objects more appropriately defined using an - object class specific to the kind of object being defined (e.g., - 'organization', 'organizationUnit'). - - The 'dc' attribute should be used for naming entries of the 'domain' - object class. - - ( 0.9.2342.19200300.100.4.13 NAME 'domain' - SUP top STRUCTURAL - MUST dc - MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ - x121Address $ registeredAddress $ destinationIndicator $ - preferredDeliveryMethod $ telexNumber $ - teletexTerminalIdentifier $ telephoneNumber $ - internationaliSDNNumber $ facsimileTelephoneNumber $ street $ - postOfficeBox $ postalCode $ postalAddress $ - physicalDeliveryOfficeName $ st $ l $ description $ o $ - associatedName ) ) - - The 'top' object class and the 'dc', 'userPassword', 'searchGuide', - 'seeAlso', 'businessCategory', 'x121Address', 'registeredAddress', - 'destinationIndicator', 'preferredDeliveryMethod', 'telexNumber', - 'teletexTerminalIdentifier', 'telephoneNumber', - 'internationaliSDNNumber', 'facsimileTelephoneNumber', 'street', - 'postOfficeBox', 'postalCode', 'postalAddress', - 'physicalDeliveryOfficeName', 'st', 'l', 'description', and 'o' types - - - -Zeilenga Standards Track [Page 15] - -RFC 4524 COSINE LDAP/X.500 Schema June 2006 - - - are described in [RFC4519]. The 'associatedName' attribute type is - described in Section 2 of this document. - - Example: - - dn: dc=com - objectClass: domain - dc: com - description: the .COM TLD - -3.5. domainRelatedObject - - The 'domainRelatedObject' object class is used to define entries that - represent DNS domains that are "equivalent" to an X.500 domain, e.g., - an organization or organizational unit. - - ( 0.9.2342.19200300.100.4.17 NAME 'domainRelatedObject' - SUP top AUXILIARY - MUST associatedDomain ) - - The 'top' object class is described in [RFC4512]. The - 'associatedDomain' attribute type is described in Section 2 of this - document. - - Example: - - dn: dc=example,dc=com - objectClass: organization - objectClass: dcObject - objectClass: domainRelatedObject - dc: example - associatedDomain: example.com - o: Example Organization - - The 'organization' and 'dcObject' object classes and the 'dc' and 'o' - attribute types are described in [RFC4519]. - -3.6. friendlyCountry - - The 'friendlyCountry' object class is used to define entries - representing countries in the DIT. The object class is used to allow - friendlier naming of countries than that allowed by the object class - 'country' [RFC4519]. - - ( 0.9.2342.19200300.100.4.18 NAME 'friendlyCountry' - SUP country STRUCTURAL - MUST co ) - - - - -Zeilenga Standards Track [Page 16] - -RFC 4524 COSINE LDAP/X.500 Schema June 2006 - - - The 'country' object class is described in [RFC4519]. The 'co' - attribute type is described in Section 2 of this document. - - Example: - - dn: c=DE - objectClass: country - objectClass: friendlyCountry - c: DE - co: Deutschland - co: Germany - co: Federal Republic of Germany - co: FRG - - The 'c' attribute type is described in [RFC4519]. - -3.7. rFC822LocalPart - - The 'rFC822LocalPart' object class is used to define entries that - represent the local part of Internet mail addresses [RFC2822]. This - treats the local part of the address as a 'domain' object. - - ( 0.9.2342.19200300.100.4.14 NAME 'rFC822localPart' - SUP domain STRUCTURAL - MAY ( cn $ description $ destinationIndicator $ - facsimileTelephoneNumber $ internationaliSDNNumber $ - physicalDeliveryOfficeName $ postalAddress $ postalCode $ - postOfficeBox $ preferredDeliveryMethod $ registeredAddress $ - seeAlso $ sn $ street $ telephoneNumber $ - teletexTerminalIdentifier $ telexNumber $ x121Address ) ) - - The 'domain' object class is described in Section 3.4 of this - document. The 'cn', 'description', 'destinationIndicator', - 'facsimileTelephoneNumber', 'internationaliSDNNumber, - 'physicalDeliveryOfficeName', 'postalAddress', 'postalCode', - 'postOfficeBox', 'preferredDeliveryMethod', 'registeredAddress', - 'seeAlso', 'sn, 'street', 'telephoneNumber', - 'teletexTerminalIdentifier', 'telexNumber', and 'x121Address' - attribute types are described in [RFC4519]. - - Example: - - dn: dc=kdz,dc=example,dc=com - objectClass: domain - objectClass: rFC822LocalPart - dc: kdz - associatedName: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM - - - - -Zeilenga Standards Track [Page 17] - -RFC 4524 COSINE LDAP/X.500 Schema June 2006 - - - The 'dc' attribute type is described in [RFC4519]. - -3.8. room - - The 'room' object class is used to define entries representing rooms. - The 'cn' (commonName) attribute SHOULD be used for naming entries of - this object class. - - ( 0.9.2342.19200300.100.4.7 NAME 'room' - SUP top STRUCTURAL - MUST cn - MAY ( roomNumber $ description $ seeAlso $ telephoneNumber ) ) - - The 'top' object class is described in [RFC4512]. The 'cn', - 'description', 'seeAlso', and 'telephoneNumber' attribute types are - described in [RFC4519]. The 'roomNumber' attribute type is described - in Section 2 of this document. - - dn: cn=conference room,dc=example,dc=com - objectClass: room - cn: conference room - telephoneNumber: +1 755 555 1111 - -3.9. simpleSecurityObject - - The 'simpleSecurityObject' object class is used to require an entry - to have a 'userPassword' attribute when the entry's structural object - class does not require (or allow) the 'userPassword attribute'. - - ( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject' - SUP top AUXILIARY - MUST userPassword ) - - The 'top' object class is described in [RFC4512]. The 'userPassword' - attribute type is described in [RFC4519]. - - dn: dc=kdz,dc=Example,dc=COM - objectClass: account - objectClass: simpleSecurityObject - uid: kdz - userPassword: My Password - seeAlso: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM - -4. Security Considerations - - General LDAP security considerations [RFC4510] are applicable to the - use of this schema. Additional considerations are noted above where - appropriate. - - - -Zeilenga Standards Track [Page 18] - -RFC 4524 COSINE LDAP/X.500 Schema June 2006 - - - Directories administrators should ensure that access to sensitive - information be restricted to authorized entities and that appropriate - data security services, including data integrity and data - confidentiality, are used to protect against eavesdropping. - - Simple authentication (e.g., plain text passwords) mechanisms should - only be used when adequate data security services are in place. LDAP - offers reasonably strong authentication and data security services - [RFC4513]. - -5. IANA Considerations - - The Internet Assigned Numbers Authority (IANA) has updated the LDAP - descriptors registry [RFC4520] as indicated in the following - template: - - Subject: Request for LDAP Descriptor Registration Update - Descriptor (short name): see comment - Object Identifier: see comments - Person & email address to contact for further information: - Kurt Zeilenga <kurt@OpenLDAP.org> - Usage: see comments - Specification: RFC 4524 - Author/Change Controller: IESG - Comments: - - The following descriptors have been updated to refer to RFC 4524. - - NAME Type OID - ------------------------ ---- -------------------------- - account O 0.9.2342.19200300.100.4.5 - associatedDomain A 0.9.2342.19200300.100.1.37 - associatedName A 0.9.2342.19200300.100.1.38 - buildingName A 0.9.2342.19200300.100.1.48 - co A 0.9.2342.19200300.100.1.43 - document O 0.9.2342.19200300.100.4.6 - documentAuthor A 0.9.2342.19200300.100.1.14 - documentIdentifier A 0.9.2342.19200300.100.1.11 - documentLocation A 0.9.2342.19200300.100.1.15 - documentPublisher A 0.9.2342.19200300.100.1.56 - documentSeries O 0.9.2342.19200300.100.4.8 - documentTitle A 0.9.2342.19200300.100.1.12 - documentVersion A 0.9.2342.19200300.100.1.13 - domain O 0.9.2342.19200300.100.4.13 - domainRelatedObject O 0.9.2342.19200300.100.4.17 - drink A 0.9.2342.19200300.100.1.5 - favouriteDrink A* 0.9.2342.19200300.100.1.5 - friendlyCountry O 0.9.2342.19200300.100.4.18 - - - -Zeilenga Standards Track [Page 19] - -RFC 4524 COSINE LDAP/X.500 Schema June 2006 - - - friendlyCountryName A* 0.9.2342.19200300.100.1.43 - homePhone A 0.9.2342.19200300.100.1.20 - homePostalAddress A 0.9.2342.19200300.100.1.39 - homeTelephone A* 0.9.2342.19200300.100.1.20 - host A 0.9.2342.19200300.100.1.9 - info A 0.9.2342.19200300.100.1.4 - mail A 0.9.2342.19200300.100.1.3 - manager A 0.9.2342.19200300.100.1.10 - mobile A 0.9.2342.19200300.100.1.41 - mobileTelephoneNumber A* 0.9.2342.19200300.100.1.41 - organizationalStatus A 0.9.2342.19200300.100.1.45 - pager A 0.9.2342.19200300.100.1.42 - pagerTelephoneNumber A* 0.9.2342.19200300.100.1.42 - personalTitle A 0.9.2342.19200300.100.1.40 - rFC822LocalPart O 0.9.2342.19200300.100.4.14 - rfc822Mailbox A* 0.9.2342.19200300.100.1.3 - room O 0.9.2342.19200300.100.4.7 - roomNumber A 0.9.2342.19200300.100.1.6 - secretary A 0.9.2342.19200300.100.1.21 - simpleSecurityObject O 0.9.2342.19200300.100.4.19 - singleLevelQuality A 0.9.2342.19200300.100.1.50 - uniqueIdentifier A 0.9.2342.19200300.100.1.44 - userClass A 0.9.2342.19200300.100.1.8 - - where Type A is Attribute, Type O is ObjectClass, and * - indicates that the registration is historic in nature. - -6. Acknowledgements - - This document is based on RFC 1274, by Paul Barker and Steve Kille, - as well as on RFC 2247, by Steve Kill, Mark Wahl, Al Grimstad, Rick - Huber, and Sri Satulari. - -7. References - -7.1. Normative References - - [RFC1034] Mockapetris, P., "Domain names - concepts and - facilities", STD 13, RFC 1034, November 1987. - - [RFC1123] Braden, R., "Requirements for Internet Hosts - - Application and Support", STD 3, RFC 1123, October - 1989. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - - - - -Zeilenga Standards Track [Page 20] - -RFC 4524 COSINE LDAP/X.500 Schema June 2006 - - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. - Sataluri, "Using Domains in LDAP/X.500 Distinguished - Names", RFC 2247, January 1998. - - [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC - 2821, April 2001. - - [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April - 2001. - - [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, - "Internationalizing Domain Names in Applications - (IDNA)", RFC 3490, March 2003. - - [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access - Protocol (LDAP): Technical Specification Road Map", RFC - 4510, June 2006. - - [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP): Directory Information Models", RFC 4512, June - 2006. - - [RFC4513] Harrison, R., "Lightweight Directory Access Protocol - (LDAP): Authentication Methods and Security - Mechanisms", RFC 4513, June 2006. - - [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol - (LDAP): Syntaxes and Matching Rules", RC 4517, June - 2006. - - [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access - Protocol (LDAP): Schema for User Applications", RFC - 4519, June 2006. - - [X.501] International Telecommunication Union - - Telecommunication Standardization Sector, "The - Directory -- Models," X.501(1993) (also ISO/IEC 9594- - 2:1994). - -7.2. Informative References - - [COSINEpilot] Goodman, D., "PARADISE" section of the March 1991 - INTERNET MONTHLY REPORTS (p. 28-29), - http://www.iana.org/periodic-reports/imr-mar91.txt - - - - -Zeilenga Standards Track [Page 21] - -RFC 4524 COSINE LDAP/X.500 Schema June 2006 - - - [ISO3166] International Organization for Standardization, "Codes - for the representation of names of countries", ISO - 3166. - - [RFC1274] Barker, P. and S. Kille, "The COSINE and Internet X.500 - Schema", RFC 1274, November 1991. - - [RFC1279] Hardcastle-Kille, S., "X.500 and Domains", RFC 1279, - November 1991. - - [RFC1487] Yeong, W., Howes, T., and S. Kille, "X.500 Lightweight - Directory Access Protocol", RFC 1487, July 1993. - - [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight - Directory Access Protocol (v3)", RFC 2251, December - 1997. - - [RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object - Class", RFC 2798, April 2000. - - [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol - version 2 (LDAPv2) to Historic Status", RFC 3494, March - 2003. - - [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority - (IANA) Considerations for the Lightweight Directory - Access Protocol (LDAP)", BCP 64, RFC 4520. - - - - - - - - - - - - - - - - - - - - - - - - -Zeilenga Standards Track [Page 22] - -RFC 4524 COSINE LDAP/X.500 Schema June 2006 - - -Appendix A. Changes since RFC 1274 - - This document represents a substantial rewrite of RFC 1274. The - following sections summarize the substantive changes. - -A.1. LDAP Short Names - - A number of COSINE attribute types have short names in LDAP. - - X.500 Name LDAP Short Name - ------------- --------------- - domainComponent dc - favoriteDrink drink - friendCountryName co - homeTelephoneNumber homePhone - mobileTelephoneNumber mobile - pagerTelephoneNumber pager - rfc822Mailbox mail - userid uid - - While the LDAP short names are generally used in LDAP, some - implementations may (for legacy reasons [RFC3494]) recognize the - attribute type by its X.500 name. Hence, the X.500 names have been - reserved solely for this purpose. - - Note: 'uid' and 'dc' are described in [RFC4519]. - -A.2. pilotObject - - The 'pilotObject' object class was not brought forward as its - function is largely replaced by operational attributes introduced in - X.500(93) [X.501] and version 3 of LDAP [RFC4512]. For instance, the - function of the 'lastModifiedBy' and 'lastModifiedTime' attribute - types is now served by the 'creatorsName', 'createTimestamp', - 'modifiersName', and 'modifyTimestamp' operational attributes - [RFC4512]. - -A.3. pilotPerson - - The 'pilotPerson' object class was not brought forward as its - function is largely replaced by the 'organizationalPerson' [RFC4512] - object class and its subclasses, such as 'inetOrgPerson' [RFC2798]. - - Most of the related attribute types (e.g., 'mail', 'manager') were - brought forward as they are used in other object classes. - - - - - - -Zeilenga Standards Track [Page 23] - -RFC 4524 COSINE LDAP/X.500 Schema June 2006 - - -A.4. dNSDomain - - The 'dNSDomain' object class and related attribute types were not - brought forward as its use is primarily experimental [RFC1279]. - -A.5. pilotDSA and qualityLabelledData - - The 'pilotDSA' and 'qualityLabelledData' object classes, as well as - related attribute types, were not brought forward as its use is - primarily experimental [QoS]. - -A.6. Attribute Syntaxes - - RFC 1274 defined and used caseIgnoreIA5StringSyntax attribute syntax. - This has been replaced with the IA5String syntax and appropriate - matching rules in 'mail' and 'associatedDomain'. - - RFC 1274 restricted 'mail' to have non-zero length values. This - restriction is not reflected in the IA5String syntax used in the - definitions provided in this specification. However, as values are - to conform to the <Mailbox> production, the 'mail' should not contain - zero-length values. Unfortunately, the directory service will not - enforce this restriction. - -Appendix B. Changes since RFC 2247 - - The 'domainNameForm' name form was not brought forward as - specification of name forms used in LDAP is left to a future - specification. - -Editor's Address - - Kurt D. Zeilenga - OpenLDAP Foundation - - EMail: Kurt@OpenLDAP.org - - - - - - - - - - - - - - - -Zeilenga Standards Track [Page 24] - -RFC 4524 COSINE LDAP/X.500 Schema June 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Zeilenga Standards Track [Page 25] - diff --git a/source4/ldap_server/devdocs/rfc4525.txt b/source4/ldap_server/devdocs/rfc4525.txt deleted file mode 100644 index 6e15e4f6e9..0000000000 --- a/source4/ldap_server/devdocs/rfc4525.txt +++ /dev/null @@ -1,339 +0,0 @@ - - - - - - -Network Working Group K. Zeilenga -Request for Comments: 4525 OpenLDAP Foundation -Category: Informational June 2006 - - - Lightweight Directory Access Protocol (LDAP) - Modify-Increment Extension - - -Status of This Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard of any kind. Distribution of this - memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document describes an extension to the Lightweight Directory - Access Protocol (LDAP) Modify operation to support an increment - capability. This extension is useful in provisioning applications, - especially when combined with the assertion control and/or the pre- - read or post-read control extension. - -Table of Contents - - 1. Background and Intended Use .....................................1 - 2. The Modify-Increment Extension ..................................2 - 3. LDIF Support ....................................................2 - 4. Security Considerations .........................................3 - 5. IANA Considerations .............................................3 - 5.1. Object Identifier ..........................................3 - 5.2. LDAP Protocol Mechanism ....................................3 - 5.3. LDAP Protocol Mechanism ....................................4 - 6. References ......................................................4 - 6.1. Normative References .......................................4 - 6.2. Informative References .....................................5 - -1. Background and Intended Use - - The Lightweight Directory Access Protocol (LDAP) [RFC4510] does not - currently provide an operation to increment values of an attribute. - A client must read the values of the attribute and then modify those - values to increment them by the desired amount. As the values may be - updated by other clients between this add and modify, the client must - - - -Zeilenga Informational [Page 1] - -RFC 4525 LDAP Modify-Increment Extension June 2006 - - - be careful to construct the modify request so that it fails in this - case, and upon failure, to re-read the values and construct a new - modify request. - - This document extends the LDAP Modify Operation [RFC4511] to support - an increment values capability. This feature is intended to be used - with either the LDAP pre-read or post-read control extensions - [RFC4527]. This feature may also be used with the LDAP assertion - control extension [RFC4528] to provide test-and-increment - functionality. - - In this document key words "MUST", "MUST NOT", "REQUIRED", "SHALL", - "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and - "OPTIONAL" are to be interpreted as described in BCP 14 [RFC2119]. - -2. The Modify-Increment Extension - - This document extends the LDAP Modify request to support a increment - values capability. Implementations of this extension SHALL support - an additional ModifyRequest operation enumeration value increment - (3), as described herein. Implementations not supporting this - extension will treat this value as they would an unlisted value, - e.g., as a protocol error. - - The increment (3) operation value specifies that an increment values - modification is requested. All existing values of the modification - attribute are to be incremented by the listed value. The - modification attribute must be appropriate for the request (e.g., it - must have INTEGER or other increment-able values), and the - modification must provide one and only one value. If the attribute - is not appropriate for the request, a constraintViolation or other - appropriate error is to be returned. If multiple values are - provided, a protocolError is to be returned. - - Servers supporting this feature SHOULD publish the object identifier - (OID) 1.3.6.1.1.14 as a value of the 'supportedFeatures' [RFC4512] - attribute in the root DSE. Clients supporting this feature SHOULD - NOT use the feature unless they know the server supports it. - -3. LDIF Support - - To represent Modify-Increment requests in LDAP Data Interchange - Format [RFC2849], the ABNF [RFC4234] production <mod-spec> is - extended as follows: - - mod-spec =/ "increment:" FILL AttributeDescription SEP - attrval-spec "-" SEP - - - - -Zeilenga Informational [Page 2] - -RFC 4525 LDAP Modify-Increment Extension June 2006 - - - For example, - - # Increment uidNumber - dn: cn=max-assigned uidNumber,dc=example,dc=com - changetype: modify - increment: uidNumber - uidNumber: 1 - - - - This LDIF fragment represents a Modify request to increment the - value(s) of uidNumber by 1. - -4. Security Considerations - - General LDAP security considerations [RFC4510], as well as those - specific to the LDAP Modify [RFC4511], apply to this Modify-Increment - extension. Beyond these considerations, it is noted that - introduction of this extension should reduce application complexity - (by providing one operation for what presently requires multiple - operations) and, hence, it may aid in the production of correct and - secure implementations. - -5. IANA Considerations - - Registration of the following values [RFC4520] have been completed. - -5.1. Object Identifier - - The IANA has assigned an LDAP Object Identifier to identify the LDAP - Modify-Increment feature, as defined in this document. - - Subject: Request for LDAP Object Identifier Registration - Person & email address to contact for further information: - Kurt Zeilenga <kurt@OpenLDAP.org> - Specification: RFC 4525 - Author/Change Controller: Author - Comments: - Identifies the LDAP Modify-Increment feature - -5.2. LDAP Protocol Mechanism - - The following LDAP Protocol Mechanism has been registered. - - Subject: Request for LDAP Protocol Mechanism Registration - Object Identifier: 1.3.6.1.1.14 - Description: Modify-Increment - Person & email address to contact for further information: - Kurt Zeilenga <kurt@openldap.org> - - - -Zeilenga Informational [Page 3] - -RFC 4525 LDAP Modify-Increment Extension June 2006 - - - Usage: Feature - Specification: RFC 4525 - Author/Change Controller: Kurt Zeilenga <kurt@openldap.org> - Comments: none - -5.3. LDAP Protocol Mechanism - - The IANA has assigned an LDAP ModifyRequest Operation Type (3) - [RFC4520] for use in this document. - - Subject: Request for LDAP Protocol Mechanism Registration - ModifyRequest Operation Name: increment - Description: Modify-Increment - Person & email address to contact for further information: - Kurt Zeilenga <kurt@openldap.org> - Usage: Feature - Specification: RFC 4525 - Author/Change Controller: Kurt Zeilenga <kurt@openldap.org> - Comments: none - -6. References - -6.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 4234, October 2005. - - [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - - Technical Specification", RFC 2849, June 2000. - - [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access - Protocol (LDAP): Technical Specification Road Map", RFC - 4510, June 2006. - - [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access - Protocol (LDAP): The Protocol", RFC 4511, June 2006. - - [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP): Directory Information Models", RFC 4512, June - 2006. - - - - - - - - -Zeilenga Informational [Page 4] - -RFC 4525 LDAP Modify-Increment Extension June 2006 - - -6.2. Informative References - - [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority - (IANA) Considerations for the Lightweight Directory - Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. - - [RFC4527] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP) Read Entry Controls", RFC 4527, June 2006. - - [RFC4528] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP) Assertion Control", RFC 4528, June 2006. - -Author's Address - - Kurt D. Zeilenga - OpenLDAP Foundation - - EMail: Kurt@OpenLDAP.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Zeilenga Informational [Page 5] - -RFC 4525 LDAP Modify-Increment Extension June 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Zeilenga Informational [Page 6] - diff --git a/source4/ldap_server/devdocs/rfc4526.txt b/source4/ldap_server/devdocs/rfc4526.txt deleted file mode 100644 index 9795632b99..0000000000 --- a/source4/ldap_server/devdocs/rfc4526.txt +++ /dev/null @@ -1,283 +0,0 @@ - - - - - - -Network Working Group K. Zeilenga -Request for Comments: 4526 OpenLDAP Foundation -Category: Standards Track June 2006 - - - Lightweight Directory Access Protocol (LDAP) - Absolute True and False Filters - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document extends the Lightweight Directory Access Protocol - (LDAP) to support absolute True and False filters based upon similar - capabilities found in X.500 directory systems. The document also - extends the String Representation of LDAP Search Filters to support - these filters. - -Table of Contents - - 1. Background ......................................................1 - 2. Absolute True and False Filters .................................2 - 3. Security Considerations .........................................2 - 4. IANA Considerations .............................................3 - 5. References ......................................................3 - 5.1. Normative References .......................................3 - 5.2. Informative References .....................................3 - -1. Background - - The X.500 Directory Access Protocol (DAP) [X.511] supports absolute - True and False assertions. An 'and' filter with zero elements always - evaluates to True. An 'or' filter with zero elements always - evaluates to False. These filters are commonly used when requesting - DSA-specific Entries (DSEs) that do not necessarily have - 'objectClass' attributes; that is, where "(objectClass=*)" may - evaluate to False. - - - - -Zeilenga Standards Track [Page 1] - -RFC 4526 LDAP Absolute True and False Filters June 2006 - - - Although LDAPv2 [RFC1777][RFC3494] placed no restriction on the - number of elements in 'and' and 'or' filter sets, the LDAPv2 string - representation [RFC1960][RFC3494] could not represent empty 'and' and - 'or' filter sets. Due to this, absolute True or False filters were - (unfortunately) eliminated from LDAPv3 [RFC4510]. - - This documents extends LDAPv3 to support absolute True and False - assertions by allowing empty 'and' and 'or' in Search filters - [RFC4511] and extends the filter string representation [RFC4515] to - allow empty filter lists. - - It is noted that certain search operations, such as those used to - retrieve subschema information [RFC4512], require use of particular - filters. This document does not change these requirements. - - This feature is intended to allow a more direct mapping between DAP - and LDAP (as needed to implement DAP-to-LDAP gateways). - - In this document, the key words "MUST", "MUST NOT", "REQUIRED", - "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", - and "OPTIONAL" are to be interpreted as described in BCP 14 - [RFC2119]. - -2. Absolute True and False Filters - - Implementations of this extension SHALL allow 'and' and 'or' choices - with zero filter elements. - - An 'and' filter consisting of an empty set of filters SHALL evaluate - to True. This filter is represented by the string "(&)". - - An 'or' filter consisting of an empty set of filters SHALL evaluate - to False. This filter is represented by the string "(|)". - - Servers supporting this feature SHOULD publish the Object Identifier - 1.3.6.1.4.1.4203.1.5.3 as a value of the 'supportedFeatures' - [RFC4512] attribute in the root DSE. - - Clients supporting this feature SHOULD NOT use the feature unless - they know that the server supports it. - -3. Security Considerations - - The (re)introduction of absolute True and False filters is not - believed to raise any new security considerations. - - Implementors of this (or any) LDAPv3 extension should be familiar - with general LDAPv3 security considerations [RFC4510]. - - - -Zeilenga Standards Track [Page 2] - -RFC 4526 LDAP Absolute True and False Filters June 2006 - - -4. IANA Considerations - - Registration of this feature has been completed by the IANA - [RFC4520]. - - Subject: Request for LDAP Protocol Mechanism Registration Object - Identifier: 1.3.6.1.4.1.4203.1.5.3 Description: True/False filters - Person & email address to contact for further information: - Kurt Zeilenga <kurt@openldap.org> Usage: Feature Specification: - RFC 4526 Author/Change Controller: IESG Comments: none - - This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its - IANA-assigned private enterprise allocation [PRIVATE], for use in - this specification. - -5. References - -5.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC4510] Zeilenga, K., Ed, "Lightweight Directory Access - Protocol (LDAP): Technical Specification Road Map", RFC - 4510, June 2006. - - [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access - Protocol (LDAP): The Protocol", RFC 4511, June 2006. - - [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP): Directory Information Models", RFC 4512, June - 2006. - - [RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory - Access Protocol (LDAP): String Representation of Search - Filters", RFC 4515, June 2006. - -5.2. Informative References - - [RFC1777] Yeong, W., Howes, T., and S. Kille, "Lightweight - Directory Access Protocol", RFC 1777, March 1995. - - [RFC1960] Howes, T., "A String Representation of LDAP Search - Filters", RFC 1960, June 1996. - - [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol - version 2 (LDAPv2) to Historic Status", RFC 3494, March - 2003. - - - -Zeilenga Standards Track [Page 3] - -RFC 4526 LDAP Absolute True and False Filters June 2006 - - - [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority - (IANA) Considerations for the Lightweight Directory - Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. - - [X.500] International Telecommunication Union - - Telecommunication Standardization Sector, "The - Directory -- Overview of concepts, models and - services," X.500(1993) (also ISO/IEC 9594-1:1994). - - [X.501] International Telecommunication Union - - Telecommunication Standardization Sector, "The - Directory -- Models," X.501(1993) (also ISO/IEC 9594- - 2:1994). - - [X.511] International Telecommunication Union - - Telecommunication Standardization Sector, "The - Directory: Abstract Service Definition", X.511(1993) - (also ISO/IEC 9594-3:1993). - - [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", - http://www.openldap.org/foundation/oid-delegate.txt. - - [PRIVATE] IANA, "Private Enterprise Numbers", - http://www.iana.org/assignments/enterprise-numbers. - -Author's Address - - Kurt D. Zeilenga - OpenLDAP Foundation - - EMail: Kurt@OpenLDAP.org - - - - - - - - - - - - - - - - - - - - -Zeilenga Standards Track [Page 4] - -RFC 4526 LDAP Absolute True and False Filters June 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Zeilenga Standards Track [Page 5] - diff --git a/source4/ldap_server/devdocs/rfc4527.txt b/source4/ldap_server/devdocs/rfc4527.txt deleted file mode 100644 index de6e5d0d54..0000000000 --- a/source4/ldap_server/devdocs/rfc4527.txt +++ /dev/null @@ -1,451 +0,0 @@ - - - - - - -Network Working Group K. Zeilenga -Request for Comments: 4527 OpenLDAP Foundation -Category: Standards Track June 2006 - - - Lightweight Directory Access Protocol (LDAP) - Read Entry Controls - - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document specifies an extension to the Lightweight Directory - Access Protocol (LDAP) to allow the client to read the target entry - of an update operation. The client may request to read the entry - before and/or after the modifications are applied. These reads are - done as an atomic part of the update operation. - -Table of Contents - - 1. Background and Intent of Use ....................................2 - 2. Terminology .....................................................2 - 3. Read Entry Controls .............................................3 - 3.1. The Pre-Read Controls ......................................3 - 3.2. The Post-Read Controls .....................................3 - 4. Interaction with Other Controls .................................4 - 5. Security Considerations .........................................4 - 6. IANA Considerations .............................................5 - 6.1. Object Identifier ..........................................5 - 6.2. LDAP Protocol Mechanisms ...................................5 - 7. Acknowledgement .................................................5 - 8. References ......................................................6 - 8.1. Normative References .......................................6 - 8.2. Informative References .....................................7 - - - - - - -Zeilenga Standards Track [Page 1] - -RFC 4527 LDAP Read Entry Controls June 2006 - - -1. Background and Intent of Use - - This document specifies an extension to the Lightweight Directory - Access Protocol (LDAP) [RFC4510] to allow the client to read the - target entry of an update operation (e.g., Add, Delete, Modify, - ModifyDN). The extension utilizes controls [RFC4511] attached to - update requests to request and return copies of the target entry. - One request control, called the Pre-Read request control, indicates - that a copy of the entry before application of update is to be - returned. Another control, called the Post-Read request control, - indicates that a copy of the entry after application of the update is - to be returned. Each request control has a corresponding response - control used to return the entry. - - To ensure proper isolation, the controls are processed as an atomic - part of the update operation. - - The functionality offered by these controls is based upon similar - functionality in the X.500 Directory Access Protocol (DAP) [X.511]. - - The Pre-Read controls may be used to obtain replaced or deleted - values of modified attributes or a copy of the entry being deleted. - - The Post-Read controls may be used to obtain values of operational - attributes, such as the 'entryUUID' [RFC4530] and 'modifyTimestamp' - [RFC4512] attributes, updated by the server as part of the update - operation. - -2. Terminology - - Protocol elements are described using ASN.1 [X.680] with implicit - tags. The term "BER-encoded" means the element is to be encoded - using the Basic Encoding Rules [X.690] under the restrictions - detailed in Section 5.1 of [RFC4511]. - - DN stands for Distinguished Name. - DSA stands for Directory System Agent (i.e., a directory server). - DSE stands for DSA-specific Entry. - - In this document, the key words "MUST", "MUST NOT", "REQUIRED", - "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", - and "OPTIONAL" are to be interpreted as described in BCP 14 - [RFC2119]. - - - - - - - - -Zeilenga Standards Track [Page 2] - -RFC 4527 LDAP Read Entry Controls June 2006 - - -3. Read Entry Controls - -3.1. The Pre-Read Controls - - The Pre-Read request and response controls are identified by the - 1.3.6.1.1.13.1 object identifier. Servers implementing these - controls SHOULD publish 1.3.6.1.1.13.1 as a value of the - 'supportedControl' [RFC4512] in their root DSE. - - The Pre-Read request control is a LDAP Control [RFC4511] whose - controlType is 1.3.6.1.1.13.1 and whose controlValue is a BER-encoded - AttributeSelection [RFC4511], as extended by [RFC3673]. The - criticality may be TRUE or FALSE. This control is appropriate for - the modifyRequest, delRequest, and modDNRequest LDAP messages. - - The corresponding response control is a LDAP Control whose - controlType is 1.3.6.1.1.13.1 and whose the controlValue, an OCTET - STRING, contains a BER-encoded SearchResultEntry. The criticality - may be TRUE or FALSE. This control is appropriate for the - modifyResponse, delResponse, and modDNResponse LDAP messages with a - resultCode of success (0). - - When the request control is attached to an appropriate update LDAP - request, the control requests the return of a copy of the target - entry prior to the application of the update. The AttributeSelection - indicates, as discussed in [RFC4511][RFC3673], which attributes are - requested to appear in the copy. The server is to return a - SearchResultEntry containing, subject to access controls and other - constraints, values of the requested attributes. - - The normal processing of the update operation and the processing of - this control MUST be performed as one atomic action isolated from - other update operations. - - If the update operation fails (in either normal or control - processing), no Pre-Read response control is provided. - -3.2. The Post-Read Controls - - The Post-Read request and response controls are identified by the - 1.3.6.1.1.13.2 object identifier. Servers implementing these - controls SHOULD publish 1.3.6.1.1.13.2 as a value of the - 'supportedControl' [RFC4512] in their root DSE. - - The Post-Read request control is a LDAP Control [RFC4511] whose - controlType is 1.3.6.1.1.13.2 and whose controlValue, an OCTET - STRING, contains a BER-encoded AttributeSelection [RFC4511], as - extended by [RFC3673]. The criticality may be TRUE or FALSE. This - - - -Zeilenga Standards Track [Page 3] - -RFC 4527 LDAP Read Entry Controls June 2006 - - - control is appropriate for the addRequest, modifyRequest, and - modDNRequest LDAP messages. - - The corresponding response control is a LDAP Control whose - controlType is 1.3.6.1.1.13.2 and whose controlValue is a BER-encoded - SearchResultEntry. The criticality may be TRUE or FALSE. This - control is appropriate for the addResponse, modifyResponse, and - modDNResponse LDAP messages with a resultCode of success (0). - - When the request control is attached to an appropriate update LDAP - request, the control requests the return of a copy of the target - entry after the application of the update. The AttributeSelection - indicates, as discussed in [RFC4511][RFC3673], which attributes are - requested to appear in the copy. The server is to return a - SearchResultEntry containing, subject to access controls and other - constraints, values of the requested attributes. - - The normal processing of the update operation and the processing of - this control MUST be performed as one atomic action isolated from - other update operations. - - If the update operation fails (in either normal or control - processing), no Post-Read response control is provided. - -4. Interaction with Other Controls - - The Pre-Read and Post-Read controls may be combined with each other - and/or with a variety of other controls. When combined with the - assertion control [RFC4528] and/or the manageDsaIT control [RFC3296], - the semantics of each control included in the combination applies. - The Pre-Read and Post-Read controls may be combined with other - controls as detailed in other technical specifications. - -5. Security Considerations - - The controls defined in this document extend update operations to - support read capabilities. Servers MUST ensure that the client is - authorized for reading of the information provided in this control - and that the client is authorized to perform the requested directory - update. - - Security considerations for the update operations [RFC4511] extended - by this control, as well as general LDAP security considerations - [RFC4510], generally apply to implementation and use of this - extension - - - - - - -Zeilenga Standards Track [Page 4] - -RFC 4527 LDAP Read Entry Controls June 2006 - - -6. IANA Considerations - - Registration of the following protocol values [RFC4520] have been - completed by the IANA. - -6.1. Object Identifier - - The IANA has registered an LDAP Object Identifier to identify LDAP - protocol elements defined in this document. - - Subject: Request for LDAP Object Identifier Registration - Person & email address to contact for further information: - Kurt Zeilenga <kurt@OpenLDAP.org> - Specification: RFC 4527 - Author/Change Controller: IESG - Comments: Identifies the LDAP Read Entry Controls - -6.2. LDAP Protocol Mechanisms - - The IANA has registered the LDAP Protocol Mechanism described in this - document. - - Subject: Request for LDAP Protocol Mechanism Registration - Object Identifier: 1.3.6.1.1.13.1 - Description: LDAP Pre-read Control - Person & email address to contact for further information: - Kurt Zeilenga <kurt@openldap.org> - Usage: Control - Specification: RFC 4527 - Author/Change Controller: IESG - Comments: none - - Subject: Request for LDAP Protocol Mechanism Registration - Object Identifier: 1.3.6.1.1.13.2 - Description: LDAP Post-read Control - Person & email address to contact for further information: - Kurt Zeilenga <kurt@openldap.org> - Usage: Control - Specification: RFC 4527 - Author/Change Controller: IESG - Comments: none - -7. Acknowledgement - - The LDAP Pre-Read and Post-Read controls are modeled after similar - capabilities offered in the DAP [X.511]. - - - - - -Zeilenga Standards Track [Page 5] - -RFC 4527 LDAP Read Entry Controls June 2006 - - -8. References - -8.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC3296] Zeilenga, K., "Named Subordinate References in - Lightweight Directory Access Protocol (LDAP) - Directories", RFC 3296, July 2002. - - [RFC3673] Zeilenga, K., "Lightweight Directory Access Protocol - version 3 (LDAPv3): All Operational Attributes", RFC - 3673, December 2003. - - [RFC4510] Zeilenga, K., Ed, "Lightweight Directory Access - Protocol (LDAP): Technical Specification Road Map", RFC - 4510, June 2006. - - [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access - Protocol (LDAP): The Protocol", RFC 4511, June 2006. - - [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP): Directory Information Models", RFC 4512, June - 2006. - - [RFC4528] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP) Assertion Control", RFC 4528, June 2006. - - [X.680] International Telecommunication Union - - Telecommunication Standardization Sector, "Abstract - Syntax Notation One (ASN.1) - Specification of Basic - Notation", X.680(1997) (also ISO/IEC 8824-1:1998). - - [X.690] International Telecommunication Union - - Telecommunication Standardization Sector, - "Specification of ASN.1 encoding rules: Basic Encoding - Rules (BER), Canonical Encoding Rules (CER), and - Distinguished Encoding Rules (DER)", X.690(1997) (also - ISO/IEC 8825-1:1998). - - - - - - - - - - - -Zeilenga Standards Track [Page 6] - -RFC 4527 LDAP Read Entry Controls June 2006 - - -8.2. Informative References - - [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority - (IANA) Considerations for the Lightweight Directory - Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. - - [RFC4530] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP) EntryUUID Operational Attribute", RFC 4530, June - 2006. - - [X.511] International Telecommunication Union - - Telecommunication Standardization Sector, "The - Directory: Abstract Service Definition", X.511(1993) - (also ISO/IEC 9594-3:1993). - -Author's Address - - Kurt D. Zeilenga - OpenLDAP Foundation - - EMail: Kurt@OpenLDAP.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Zeilenga Standards Track [Page 7] - -RFC 4527 LDAP Read Entry Controls June 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Zeilenga Standards Track [Page 8] - diff --git a/source4/ldap_server/devdocs/rfc4528.txt b/source4/ldap_server/devdocs/rfc4528.txt deleted file mode 100644 index 5b1fee0c1b..0000000000 --- a/source4/ldap_server/devdocs/rfc4528.txt +++ /dev/null @@ -1,339 +0,0 @@ - - - - - - -Network Working Group K. Zeilenga -Request for Comments: 4528 OpenLDAP Foundation -Category: Standards Track June 2006 - - - Lightweight Directory Access Protocol (LDAP) - Assertion Control - - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document defines the Lightweight Directory Access Protocol - (LDAP) Assertion Control, which allows a client to specify that a - directory operation should only be processed if an assertion applied - to the target entry of the operation is true. It can be used to - construct "test and set", "test and clear", and other conditional - operations. - -Table of Contents - - 1. Overview ........................................................2 - 2. Terminology .....................................................2 - 3. The Assertion Control ...........................................2 - 4. Security Considerations .........................................3 - 5. IANA Considerations .............................................4 - 5.1. Object Identifier ..........................................4 - 5.2. LDAP Protocol Mechanism ....................................4 - 5.3. LDAP Result Code ...........................................4 - 6. Acknowledgements ................................................5 - 7. References ......................................................5 - 7.1. Normative References .......................................5 - 7.2. Informative References .....................................5 - - - - - - - -Zeilenga Standards Track [Page 1] - -RFC 4528 LDAP Assertion Control June 2006 - - -1. Overview - - This document defines the Lightweight Directory Access Protocol - (LDAP) [RFC4510] assertion control. The assertion control allows the - client to specify a condition that must be true for the operation to - be processed normally. Otherwise, the operation is not performed. - For instance, the control can be used with the Modify operation - [RFC4511] to perform atomic "test and set" and "test and clear" - operations. - - The control may be attached to any update operation to support - conditional addition, deletion, modification, and renaming of the - target object. The asserted condition is evaluated as an integral - part the operation. - - The control may also be used with the search operation. Here, the - assertion is applied to the base object of the search before - searching for objects that match the search scope and filter. - - The control may also be used with the compare operation. Here, it - extends the compare operation to allow a more complex assertion. - -2. Terminology - - Protocol elements are described using ASN.1 [X.680] with implicit - tags. The term "BER-encoded" means the element is to be encoded - using the Basic Encoding Rules [X.690] under the restrictions - detailed in Section 5.1 of [RFC4511]. - - DSA stands for Directory System Agent (or server). - DSE stands for DSA-specific Entry. - - In this document, the key words "MUST", "MUST NOT", "REQUIRED", - "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", - and "OPTIONAL" are to be interpreted as described in BCP 14 - [RFC2119]. - -3. The Assertion Control - - The assertion control is an LDAP Control [RFC4511] whose controlType - is 1.3.6.1.1.12 and whose controlValue is a BER-encoded Filter - [Protocol, Section 4.5.1]. The criticality may be TRUE or FALSE. - There is no corresponding response control. - - The control is appropriate for both LDAP interrogation and update - operations [RFC4511], including Add, Compare, Delete, Modify, - ModifyDN (rename), and Search. It is inappropriate for Abandon, - Bind, Unbind, and StartTLS operations. - - - -Zeilenga Standards Track [Page 2] - -RFC 4528 LDAP Assertion Control June 2006 - - - When the control is attached to an LDAP request, the processing of - the request is conditional on the evaluation of the Filter as applied - against the target of the operation. If the Filter evaluates to - TRUE, then the request is processed normally. If the Filter - evaluates to FALSE or Undefined, then assertionFailed (122) - resultCode is returned, and no further processing is performed. - - For Add, Compare, and ModifyDN operations, the target is indicated by - the entry field in the request. For Modify operations, the target is - indicated by the object field. For Delete operations, the target is - indicated by the DelRequest type. For Compare operations and all - update operations, the evaluation of the assertion MUST be performed - as an integral part of the operation. That is, the evaluation of the - assertion and the normal processing of the operation SHALL be done as - one atomic action. - - For Search operations, the target is indicated by the baseObject - field, and the evaluation is done after "finding" but before - "searching" [RFC4511]. Hence, no entries or continuations references - are returned if the assertion fails. - - Servers implementing this technical specification SHOULD publish the - object identifier 1.3.6.1.1.12 as a value of the 'supportedControl' - attribute [RFC4512] in their root DSE. A server MAY choose to - advertise this extension only when the client is authorized to use - it. - - Other documents may specify how this control applies to other LDAP - operations. In doing so, they must state how the target entry is - determined. - -4. Security Considerations - - The filter may, like other components of the request, contain - sensitive information. When it does, this information should be - appropriately protected. - - As with any general assertion mechanism, the mechanism can be used to - determine directory content. Hence, this mechanism SHOULD be subject - to appropriate access controls. - - Some assertions may be very complex, requiring significant time and - resources to evaluate. Hence, this mechanism SHOULD be subject to - appropriate administrative controls. - - - - - - - -Zeilenga Standards Track [Page 3] - -RFC 4528 LDAP Assertion Control June 2006 - - - Security considerations for the base operations [RFC4511] extended by - this control, as well as general LDAP security considerations - [RFC4510], generally apply to implementation and use of this - extension. - -5. IANA Considerations - -5.1. Object Identifier - - The IANA has assigned an LDAP Object Identifier [RFC4520] to identify - the LDAP Assertion Control defined in this document. - - Subject: Request for LDAP Object Identifier Registration - Person & email address to contact for further information: - Kurt Zeilenga <kurt@OpenLDAP.org> - Specification: RFC 4528 - Author/Change Controller: IESG - Comments: - Identifies the LDAP Assertion Control - -5.2. LDAP Protocol Mechanism - - Registration of this protocol mechanism [RFC4520] is requested. - - Subject: Request for LDAP Protocol Mechanism Registration - Object Identifier: 1.3.6.1.1.12 - Description: Assertion Control - Person & email address to contact for further information: - Kurt Zeilenga <kurt@openldap.org> - Usage: Control - Specification: RFC 4528 - Author/Change Controller: IESG - Comments: none - -5.3. LDAP Result Code - - The IANA has assigned an LDAP Result Code [RFC4520] called - 'assertionFailed' (122). - - Subject: LDAP Result Code Registration - Person & email address to contact for further information: - Kurt Zeilenga <kurt@OpenLDAP.org> - Result Code Name: assertionFailed - Specification: RFC 4528 - Author/Change Controller: IESG - Comments: none - - - - - -Zeilenga Standards Track [Page 4] - -RFC 4528 LDAP Assertion Control June 2006 - - -6. Acknowledgements - - The assertion control concept is attributed to Morteza Ansari. - -7. References - -7.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access - Protocol (LDAP): Technical Specification Road Map", RFC - 4510, June 2006. - - [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access - Protocol (LDAP): The Protocol", RFC 4511, June 2006. - - [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP): Directory Information Models", RFC 4512, June - 2006. - - [X.680] International Telecommunication Union - - Telecommunication Standardization Sector, "Abstract - Syntax Notation One (ASN.1) - Specification of Basic - Notation", X.680(2002) (also ISO/IEC 8824-1:2002). - - [X.690] International Telecommunication Union - - Telecommunication Standardization Sector, - "Specification of ASN.1 encoding rules: Basic Encoding - Rules (BER), Canonical Encoding Rules (CER), and - Distinguished Encoding Rules (DER)", X.690(2002) (also - ISO/IEC 8825-1:2002). - -7.2. Informative References - - [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority - (IANA) Considerations for the Lightweight Directory - Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. - -Author's Address - - Kurt D. Zeilenga - OpenLDAP Foundation - - EMail: Kurt@OpenLDAP.org - - - - - -Zeilenga Standards Track [Page 5] - -RFC 4528 LDAP Assertion Control June 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Zeilenga Standards Track [Page 6] - diff --git a/source4/ldap_server/devdocs/rfc4529.txt b/source4/ldap_server/devdocs/rfc4529.txt deleted file mode 100644 index 47449c040f..0000000000 --- a/source4/ldap_server/devdocs/rfc4529.txt +++ /dev/null @@ -1,339 +0,0 @@ - - - - - - -Network Working Group K. Zeilenga -Request for Comments: 4529 OpenLDAP Foundation -Category: Informational June 2006 - - - Requesting Attributes by Object Class in the - Lightweight Directory Access Protocol (LDAP) - -Status of This Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard of any kind. Distribution of this - memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - The Lightweight Directory Access Protocol (LDAP) search operation - provides mechanisms for clients to request all user application - attributes, all operational attributes, and/or attributes selected by - their description. This document extends LDAP to support a mechanism - that LDAP clients may use to request the return of all attributes of - an object class. - -Table of Contents - - 1. Background and Intended Use .....................................1 - 2. Terminology .....................................................2 - 3. Return of all Attributes of an Object Class .....................2 - 4. Security Considerations .........................................3 - 5. IANA Considerations .............................................3 - 6. References ......................................................4 - 6.1. Normative References .......................................4 - 6.2. Informative References .....................................4 - -1. Background and Intended Use - - In the Lightweight Directory Access Protocol (LDAP) [RFC4510], the - search operation [RFC4511] supports requesting the return of a set of - attributes. This set is determined by a list of attribute - descriptions. Two special descriptors are defined to request all - user attributes ("*") [RFC4511] and all operational attributes ("+") - [RFC3673]. However, there is no convenient mechanism for requesting - pre-defined sets of attributes such as the set of attributes used to - represent a particular class of object. - - - -Zeilenga Informational [Page 1] - -RFC 4529 Requesting Attributes by Object Class June 2006 - - - This document extends LDAP to allow an object class identifier to be - specified in attributes lists, such as in Search requests, to request - the return of all attributes belonging to an object class. The - COMMERCIAL AT ("@", U+0040) character is used to distinguish an - object class identifier from an attribute descriptions. - - For example, the attribute list of "@country" is equivalent to the - attribute list of 'c', 'searchGuide', 'description', and - 'objectClass'. This object class is described in [RFC4519]. - - This extension is intended primarily to be used where the user is in - direct control of the parameters of the LDAP search operation, for - instance when entering an LDAP URL [RFC4516] into a web browser, such - as <ldap:///dc=example,dc=com?@organization?base>. - -2. Terminology - - In this document, the key words "MUST", "MUST NOT", "REQUIRED", - "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", - and "OPTIONAL" are to be interpreted as described in BCP 14 - [RFC2119]. - - DSA stands for Directory System Agent (or server). - DSE stands for DSA-specific Entry. - -3. Return of All Attributes of an Object Class - - This extension allows object class identifiers to be provided in the - attributes field of the LDAP SearchRequest [RFC4511] or other request - values of the AttributeSelection data type (e.g., attributes field in - pre/post read controls [ReadEntry]) and/or <attributeSelector> - production (e.g., attributes of an LDAP URL [RFC4516]). For each - object class identified in the attributes field, the request is to be - treated as if each attribute allowed by that class (by "MUST" or - "MAY", directly or by "SUP"erior) [RFC4512] were itself listed. - - This extension extends the <attributeSelector> [RFC4511] production - as indicated by the following ABNF [RFC4234]: - - attributeSelector =/ objectclassdescription - objectclassdescription = ATSIGN oid options - ATSIGN = %x40 ; COMMERCIAL AT ("@" U+0040) - - where <oid> and <options> productions are as defined in [RFC4512]. - - - - - - - -Zeilenga Informational [Page 2] - -RFC 4529 Requesting Attributes by Object Class June 2006 - - - The <oid> component of an <objectclassdescription> production - identifies the object class by short name (descr) or object - identifier (numericoid). If the value of the <oid> component is - unrecognized or does not refer to an object class, the object class - description is to be treated as an unrecognized attribute - description. - - The <options> production is included in the grammar for extensibility - purposes. An object class description with an unrecognized or - inappropriate option is to be treated as unrecognized. - - Although object class description options and attribute description - options share the same syntax, they are not semantically related. - This document does not define any object description option. - - Servers supporting this feature SHOULD publish the object identifier - (OID) 1.3.6.1.4.1.4203.1.5.2 as a value of the 'supportedFeatures' - [RFC4512] attribute in the root DSE. Clients supporting this feature - SHOULD NOT use the feature unless they know that the server supports - it. - -4. Security Considerations - - This extension provides a shorthand for requesting all attributes of - an object class. Because these attributes could have been listed - individually, introduction of this shorthand is not believed to raise - additional security considerations. - - Implementors of this LDAP extension should be familiar with security - considerations applicable to the LDAP search operation [RFC4511], as - well as with general LDAP security considerations [RFC4510]. - -5. IANA Considerations - - Registration of the LDAP Protocol Mechanism [RFC4520] defined in this - document has been completed. - - Subject: Request for LDAP Protocol Mechanism Registration - Object Identifier: 1.3.6.1.4.1.4203.1.5.2 - Description: OC AD Lists - Person & email address to contact for further information: - Kurt Zeilenga <kurt@openldap.org> - Usage: Feature - Specification: RFC 4529 - Author/Change Controller: Kurt Zeilenga <kurt@openldap.org> - Comments: none - - - - - -Zeilenga Informational [Page 3] - -RFC 4529 Requesting Attributes by Object Class June 2006 - - - This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its - IANA-assigned private enterprise allocation [PRIVATE], for use in - this specification. - -6. References - -6.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for - Syntax Specifications: ABNF", RFC 4234, October 2005. - - [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access - Protocol (LDAP): Technical Specification Road Map", RFC - 4510, June 2006. - - [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access - Protocol (LDAP): The Protocol", RFC 4511, June 2006. - - [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP): Directory Information Models", RFC 4512, June - 2006. - - [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory - Access Protocol (LDAP): Uniform Resource Locator", RFC - 4516, June 2006. - - [X.680] International Telecommunication Union - - Telecommunication Standardization Sector, "Abstract - Syntax Notation One (ASN.1) - Specification of Basic - Notation", X.680(2002) (also ISO/IEC 8824-1:2002). - -6.2. Informative References - - [RFC3673] Zeilenga, K., "Lightweight Directory Access Protocol - version 3 (LDAPv3): All Operational Attributes", RFC - 3673, December 2003. - - [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access - Protocol (LDAP): Schema for User Applications", RFC - 4519, June 2006. - - [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority - (IANA) Considerations for the Lightweight Directory - Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. - - - - -Zeilenga Informational [Page 4] - -RFC 4529 Requesting Attributes by Object Class June 2006 - - - [ReadEntry] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP) Read Entry Controls", RFC 4527, June 2006. - - [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", - http://www.openldap.org/foundation/oid-delegate.txt. - - [PRIVATE] IANA, "Private Enterprise Numbers", - http://www.iana.org/assignments/enterprise-numbers. - -Author's Address - - Kurt D. Zeilenga - OpenLDAP Foundation - - EMail: Kurt@OpenLDAP.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Zeilenga Informational [Page 5] - -RFC 4529 Requesting Attributes by Object Class June 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Zeilenga Informational [Page 6] - diff --git a/source4/ldap_server/devdocs/rfc4530.txt b/source4/ldap_server/devdocs/rfc4530.txt deleted file mode 100644 index 219a7c2d0c..0000000000 --- a/source4/ldap_server/devdocs/rfc4530.txt +++ /dev/null @@ -1,451 +0,0 @@ - - - - - - -Network Working Group K. Zeilenga -Request for Comments: 4530 OpenLDAP Foundation -Category: Standards Track June 2006 - - - Lightweight Directory Access Protocol (LDAP) - entryUUID Operational Attribute - - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document describes the LDAP/X.500 'entryUUID' operational - attribute and associated matching rules and syntax. The attribute - holds a server-assigned Universally Unique Identifier (UUID) for the - object. Directory clients may use this attribute to distinguish - objects identified by a distinguished name or to locate an object - after renaming. - - - - - - - - - - - - - - - - - - - - - - -Zeilenga Standards Track [Page 1] - -RFC 4530 LDAP entryUUID June 2006 - - -Table of Contents - - 1. Background and Intended Use .....................................2 - 2. UUID Schema Elements ............................................3 - 2.1. UUID Syntax ................................................3 - 2.2. 'uuidMatch' Matching Rule ..................................3 - 2.3. 'uuidOrderingMatch' Matching Rule ..........................3 - 2.4. 'entryUUID' Attribute ......................................4 - 3. Security Considerations .........................................4 - 4. IANA Considerations .............................................5 - 4.1. Object Identifier Registration .............................5 - 4.2. UUID Syntax Registration ...................................5 - 4.3. 'uuidMatch' Descriptor Registration ........................5 - 4.4. 'uuidOrderingMatch' Descriptor Registration ................5 - 4.5. 'entryUUID' Descriptor Registration ........................6 - 5. Acknowledgements ................................................6 - 6. References ......................................................6 - 6.1. Normative References .......................................6 - 6.2. Informative References .....................................7 - -1. Background and Intended Use - - In X.500 Directory Services [X.501], such as those accessible using - the Lightweight Directory Access Protocol (LDAP) [RFC4510], an object - is identified by its distinguished name (DN). However, DNs are not - stable identifiers. That is, a new object may be identified by a DN - that previously identified another (now renamed or deleted) object. - - A Universally Unique Identifier (UUID) is "an identifier unique - across both space and time, with respect to the space of all UUIDs" - [RFC4122]. UUIDs are used in a wide range of systems. - - This document describes the 'entryUUID' operational attribute, which - holds the UUID assigned to the object by the server. Clients may use - this attribute to distinguish objects identified by a particular - distinguished name or to locate a particular object after renaming. - - This document defines the UUID syntax, the 'uuidMatch' and - 'uuidOrderingMatch' matching rules, and the 'entryUUID' attribute - type. - - Schema definitions are provided using LDAP description formats - [RFC4512]. Definitions provided here are formatted (line wrapped) - for readability. - - - - - - - -Zeilenga Standards Track [Page 2] - -RFC 4530 LDAP entryUUID June 2006 - - - In this document, the key words "MUST", "MUST NOT", "REQUIRED", - "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", - and "OPTIONAL" are to be interpreted as described in BCP 14 - [RFC2119]. - -2. UUID Schema Elements - -2.1. UUID Syntax - - A Universally Unique Identifier (UUID) [RFC4122] is a 16-octet (128- - bit) value that identifies an object. The ASN.1 [X.680] type UUID is - defined to represent UUIDs as follows: - - UUID ::= OCTET STRING (SIZE(16)) - -- constrained to an UUID [RFC4122] - - In LDAP, UUID values are encoded using the [ASCII] character string - representation described in [RFC4122]. For example, - "597ae2f6-16a6-1027-98f4-d28b5365dc14". - - The following is an LDAP syntax description suitable for publication - in subschema subentries. - - ( 1.3.6.1.1.16.1 DESC 'UUID' ) - -2.2. 'uuidMatch' Matching Rule - - The 'uuidMatch' matching rule compares an asserted UUID with a stored - UUID for equality. Its semantics are the same as the - 'octetStringMatch' [X.520][RFC4517] matching rule. The rule differs - from 'octetStringMatch' in that the assertion value is encoded using - the UUID string representation instead of the normal OCTET STRING - string representation. - - The following is an LDAP matching rule description suitable for - publication in subschema subentries. - - ( 1.3.6.1.1.16.2 NAME 'uuidMatch' - SYNTAX 1.3.6.1.1.16.1 ) - -2.3. 'uuidOrderingMatch' Matching Rule - - The 'uuidOrderingMatch' matching rule compares an asserted UUID with - a stored UUID for ordering. Its semantics are the same as the - 'octetStringOrderingMatch' [X.520][RFC4517] matching rule. The rule - differs from 'octetStringOrderingMatch' in that the assertion value - is encoded using the UUID string representation instead of the normal - OCTET STRING string representation. - - - -Zeilenga Standards Track [Page 3] - -RFC 4530 LDAP entryUUID June 2006 - - - The following is an LDAP matching rule description suitable for - publication in subschema subentries. - - ( 1.3.6.1.1.16.3 NAME 'uuidOrderingMatch' - SYNTAX 1.3.6.1.1.16.1 ) - - Note that not all UUID variants have a defined ordering; and even - where it does, servers are not obligated to assign UUIDs in any - particular order. This matching rule is provided for completeness. - -2.4. 'entryUUID' Attribute - - The 'entryUUID' operational attribute provides the Universally Unique - Identifier (UUID) assigned to the entry. - - The following is an LDAP attribute type description suitable for - publication in subschema subentries. - - ( 1.3.6.1.1.16.4 NAME 'entryUUID' - DESC 'UUID of the entry' - EQUALITY uuidMatch - ORDERING uuidOrderingMatch - SYNTAX 1.3.6.1.1.16.1 - SINGLE-VALUE - NO-USER-MODIFICATION - USAGE directoryOperation ) - - Servers SHALL generate and assign a new UUID to each entry upon its - addition to the directory and provide that UUID as the value of the - 'entryUUID' operational attribute. An entry's UUID is immutable. - - UUID are to be generated in accordance with Section 4 of [RFC4122]. - In particular, servers MUST ensure that each generated UUID is unique - in space and time. - -3. Security Considerations - - An entry's relative distinguish name (RDN) is composed from attribute - values of the entry, which are commonly descriptive of the object the - entry represents. Although deployers are encouraged to use naming - attributes whose values are widely disclosable [RFC4514], entries are - often named using information that cannot be disclosed to all - parties. As UUIDs do not contain any descriptive information of the - object they identify, UUIDs may be used to identify a particular - entry without disclosure of its contents. - - General UUID security considerations [RFC4122] apply. - - - - -Zeilenga Standards Track [Page 4] - -RFC 4530 LDAP entryUUID June 2006 - - - General LDAP security considerations [RFC4510] apply. - -4. IANA Considerations - - The IANA has registered the LDAP values [RFC4520] specified in this - document. - -4.1. Object Identifier Registration - - Subject: Request for LDAP OID Registration - Person & email address to contact for further information: - Kurt Zeilenga <kurt@OpenLDAP.org> - Specification: RFC 4530 - Author/Change Controller: IESG - Comments: - Identifies the UUID schema elements - -4.2. UUID Syntax Registration - - Subject: Request for LDAP Syntax Registration - Object Identifier: 1.3.6.1.1.16.1 - Description: UUID - Person & email address to contact for further information: - Kurt Zeilenga <kurt@OpenLDAP.org> - Specification: RFC 4530 - Author/Change Controller: IESG - Comments: - Identifies the UUID syntax - -4.3. 'uuidMatch' Descriptor Registration - - Subject: Request for LDAP Descriptor Registration - Descriptor (short name): uuidMatch - Object Identifier: 1.3.6.1.1.16.2 - Person & email address to contact for further information: - Kurt Zeilenga <kurt@OpenLDAP.org> - Usage: Matching Rule - Specification: RFC 4530 - Author/Change Controller: IESG - -4.4. 'uuidOrderingMatch' Descriptor Registration - - Subject: Request for LDAP Descriptor Registration - Descriptor (short name): uuidOrderingMatch - Object Identifier: 1.3.6.1.1.16.3 - Person & email address to contact for further information: - Kurt Zeilenga <kurt@OpenLDAP.org> - Usage: Matching Rule - - - -Zeilenga Standards Track [Page 5] - -RFC 4530 LDAP entryUUID June 2006 - - - Specification: RFC 4530 - Author/Change Controller: IESG - -4.5. 'entryUUID' Descriptor Registration - - The IANA has registered the LDAP 'entryUUID' descriptor. - - Subject: Request for LDAP Descriptor Registration - Descriptor (short name): entryUUID - Object Identifier: 1.3.6.1.1.16.4 - Person & email address to contact for further information: - Kurt Zeilenga <kurt@OpenLDAP.org> - Usage: Attribute Type - Specification: RFC 4530 - Author/Change Controller: IESG - -5. Acknowledgements - - This document is based upon discussions in the LDAP Update and - Duplication Protocols (LDUP) WG. Members of the LDAP Directorate - provided review. - -6. References - -6.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally - Unique IDentifier (UUID) URN Namespace", RFC 4122, July - 2005. - - [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access - Protocol (LDAP): Technical Specification Road Map", RFC - 4510, June 2006. - - [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP): Directory Information Models", RFC 4512, June - 2006. - - [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol - (LDAP): Syntaxes and Matching Rules", RFC 4517, June - 2006. - - [ASCII] Coded Character Set--7-bit American Standard Code for - Information Interchange, ANSI X3.4-1986. - - - - -Zeilenga Standards Track [Page 6] - -RFC 4530 LDAP entryUUID June 2006 - - - [X.501] International Telecommunication Union - - Telecommunication Standardization Sector, "The - Directory -- Models," X.501(1993) (also ISO/IEC 9594- - 2:1994). - - [X.520] International Telecommunication Union - - Telecommunication Standardization Sector, "The - Directory: Selected Attribute Types", X.520(1993) (also - ISO/IEC 9594-6:1994). - - [X.680] International Telecommunication Union - - Telecommunication Standardization Sector, "Abstract - Syntax Notation One (ASN.1) - Specification of Basic - Notation", X.680(2002) (also ISO/IEC 8824-1:2002). - -6.2. Informative References - - [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access - Protocol (LDAP): String Representation of Distinguished - Names", RFC 4514, June 2006. - - [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority - (IANA) Considerations for the Lightweight Directory - Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. - -Author's Address - - Kurt D. Zeilenga - OpenLDAP Foundation - - EMail: Kurt@OpenLDAP.org - - - - - - - - - - - - - - - - - - - - -Zeilenga Standards Track [Page 7] - -RFC 4530 LDAP entryUUID June 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Zeilenga Standards Track [Page 8] - diff --git a/source4/ldap_server/devdocs/rfc4531.txt b/source4/ldap_server/devdocs/rfc4531.txt deleted file mode 100644 index b551d441cb..0000000000 --- a/source4/ldap_server/devdocs/rfc4531.txt +++ /dev/null @@ -1,507 +0,0 @@ - - - - - - -Network Working Group K. Zeilenga -Request for Comments: 4531 OpenLDAP Foundation -Category: Experimental June 2006 - - - Lightweight Directory Access Protocol (LDAP) - Turn Operation - - -Status of This Memo - - This memo defines an Experimental Protocol for the Internet - community. It does not specify an Internet standard of any kind. - Discussion and suggestions for improvement are requested. - Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This specification describes a Lightweight Directory Access Protocol - (LDAP) extended operation to reverse (or "turn") the roles of client - and server for subsequent protocol exchanges in the session, or to - enable each peer to act as both client and server with respect to the - other. - -Table of Contents - - 1. Background and Intent of Use ....................................2 - 1.1. Terminology ................................................2 - 2. Turn Operation ..................................................2 - 2.1. Turn Request ...............................................3 - 2.2. Turn Response ..............................................3 - 3. Authentication ..................................................3 - 3.1. Use with TLS and Simple Authentication .....................4 - 3.2. Use with TLS and SASL EXTERNAL .............................4 - 3.3. Use of Mutual Authentication and SASL EXTERNAL .............4 - 4. TLS and SASL Security Layers ....................................5 - 5. Security Considerations .........................................6 - 6. IANA Considerations .............................................6 - 6.1. Object Identifier ..........................................6 - 6.2. LDAP Protocol Mechanism ....................................7 - 7. References ......................................................7 - 7.1. Normative References .......................................7 - 7.2. Informative References .....................................8 - - - - -Zeilenga Experimental [Page 1] - -RFC 4531 LDAP Turn Operation June 2006 - - -1. Background and Intent of Use - - The Lightweight Directory Access Protocol (LDAP) [RFC4510][RFC4511] - is a client-server protocol that typically operates over reliable - octet-stream transports, such as the Transport Control Protocol - (TCP). Generally, the client initiates the stream by connecting to - the server's listener at some well-known address. - - There are cases where it is desirable for the server to initiate the - stream. Although it certainly is possible to write a technical - specification detailing how to implement server-initiated LDAP - sessions, this would require the design of new authentication and - other security mechanisms to support server-initiated LDAP sessions. - - Instead, this document introduces an operation, the Turn operation, - which may be used to reverse the client-server roles of the protocol - peers. This allows the initiating protocol peer to become the server - (after the reversal). - - As an additional feature, the Turn operation may be used to allow - both peers to act in both roles. This is useful where both peers are - directory servers that desire to request, as LDAP clients, that - operations be performed by the other. This may be useful in - replicated and/or distributed environments. - - This operation is intended to be used between protocol peers that - have established a mutual agreement, by means outside of the - protocol, that requires reversal of client-server roles, or allows - both peers to act both as client and server. - -1.1. Terminology - - Protocol elements are described using ASN.1 [X.680] with implicit - tags. The term "BER-encoded" means the element is to be encoded - using the Basic Encoding Rules [X.690] under the restrictions - detailed in Section 5.1 of [RFC4511]. - -2. Turn Operation - - The Turn operation is defined as an LDAP-Extended Operation - [Protocol, Section 4.12] identified by the 1.3.6.1.1.19 OID. The - function of the Turn Operation is to request that the client-server - roles be reversed, or, optionally, to request that both protocol - peers be able to act both as client and server in respect to the - other. - - - - - - -Zeilenga Experimental [Page 2] - -RFC 4531 LDAP Turn Operation June 2006 - - -2.1. Turn Request - - The Turn request is an ExtendedRequest where the requestName field - contains the 1.3.6.1.1.19 OID and the requestValue field is a BER- - encoded turnValue: - - turnValue ::= SEQUENCE { - mutual BOOLEAN DEFAULT FALSE, - identifier LDAPString - } - - A TRUE mutual field value indicates a request to allow both peers to - act both as client and server. A FALSE mutual field value indicates - a request to reserve the client and server roles. - - The value of the identifier field is a locally defined policy - identifier (typically associated with a mutual agreement for which - this turn is be executed as part of). - -2.2. Turn Response - - A Turn response is an ExtendedResponse where the responseName and - responseValue fields are absent. A resultCode of success is returned - if and only if the responder is willing and able to turn the session - as requested. Otherwise, a different resultCode is returned. - -3. Authentication - - This extension's authentication model assumes separate authentication - of the peers in each of their roles. A separate Bind exchange is - expected between the peers in their new roles to establish identities - in these roles. - - Upon completion of the Turn, the responding peer in its new client - role has an anonymous association at the initiating peer in its new - server role. If the turn was mutual, the authentication association - of the initiating peer in its pre-existing client role is left intact - at the responding peer in its pre-existing server role. If the turn - was not mutual, this association is void. - - The responding peer may establish its identity in its client role by - requesting and successfully completing a Bind operation. - - The remainder of this section discusses some authentication - scenarios. In the protocol exchange illustrations, A refers to the - initiating peer (the original client) and B refers to the responding - peer (the original server). - - - - -Zeilenga Experimental [Page 3] - -RFC 4531 LDAP Turn Operation June 2006 - - -3.1. Use with TLS and Simple Authentication - - A->B: StartTLS Request - B->A: StartTLS(success) Response - A->B: Bind(Simple(cn=B,dc=example,dc=net,B's secret)) Request - B->A: Bind(success) Response - A->B: Turn(TRUE,"XXYYZ") Request - B->A: Turn(success) Response - B->A: Bind(Simple(cn=A,dc=example,dc=net,A's secret)) Request - A->B: Bind(success) Response - - In this scenario, TLS (Transport Layer Security) [RFC4346] is started - and the initiating peer (the original client) establishes its - identity with the responding peer prior to the Turn using the - DN/password mechanism of the Simple method of the Bind operation. - After the turn, the responding peer, in its new client role, - establishes its identity with the initiating peer in its new server - role. - -3.2. Use with TLS and SASL EXTERNAL - - A->B: StartTLS Request - B->A: StartTLS(success) Response - A->B: Bind(SASL(EXTERNAL)) Request - B->A: Bind(success) Response - A->B: Turn(TRUE,"XXYYZ") Request - B->A: Turn(success) Response - B->A: Bind(SASL(EXTERNAL)) Request - A->B: Bind(success) Response - - In this scenario, TLS is started (with each peer providing a valid - certificate), and the initiating peer (the original client) - establishes its identity through the use of the EXTERNAL mechanism of - the SASL (Simple Authentication and Security Layer) [RFC4422] method - of the Bind operation prior to the Turn. After the turn, the - responding peer, in its new client role, establishes its identity - with the initiating peer in its new server role. - -3.3. Use of Mutual Authentication and SASL EXTERNAL - - A number of SASL mechanisms, such as GSSAPI [SASL-K5], support mutual - authentication. The initiating peer, in its new server role, may use - the identity of the responding peer, established by a prior - authentication exchange, as its source for "external" identity in - subsequent EXTERNAL exchange. - - A->B: Bind(SASL(GSSAPI)) Request - <intermediate messages> - - - -Zeilenga Experimental [Page 4] - -RFC 4531 LDAP Turn Operation June 2006 - - - B->A: Bind(success) Response - A->B: Turn(TRUE,"XXYYZ") Request - B->A: Turn(success) Response - B->A: Bind(SASL(EXTERNAL)) Request - A->B: Bind(success) Response - - In this scenario, a GSSAPI mutual-authentication exchange is - completed between the initiating peer (the original client) and the - responding server (the original server) prior to the turn. After the - turn, the responding peer, in its new client role, requests that the - initiating peer utilize an "external" identity to establish its LDAP - authorization identity. - -4. TLS and SASL Security Layers - - As described in [RFC4511], LDAP supports both Transport Layer - Security (TLS) [RFC4346] and Simple Authentication and Security Layer - (SASL) [RFC4422] security frameworks. The following table - illustrates the relationship between the LDAP message layer, SASL - layer, TLS layer, and transport connection within an LDAP session. - - +----------------------+ - | LDAP message layer | - +----------------------+ > LDAP PDUs - +----------------------+ < data - | SASL layer | - +----------------------+ > SASL-protected data - +----------------------+ < data - | TLS layer | - Application +----------------------+ > TLS-protected data - ------------+----------------------+ < data - Transport | transport connection | - +----------------------+ - - This extension does not alter this relationship, nor does it remove - the general restriction against multiple TLS layers, nor does it - remove the general restriction against multiple SASL layers. - - As specified in [RFC4511], the StartTLS operation is used to initiate - negotiation of a TLS layer. If a TLS is already installed, the - StartTLS operation must fail. Upon establishment of the TLS layer, - regardless of which peer issued the request to start TLS, the peer - that initiated the LDAP session (the original client) performs the - "server identity check", as described in Section 3.1.5 of [RFC4513], - treating itself as the "client" and its peer as the "server". - - As specified in [RFC4422], a newly negotiated SASL security layer - replaces the installed SASL security layer. Though the client/server - - - -Zeilenga Experimental [Page 5] - -RFC 4531 LDAP Turn Operation June 2006 - - - roles in LDAP, and hence SASL, may be reversed in subsequent - exchanges, only one SASL security layer may be installed at any - instance. - -5. Security Considerations - - Implementors should be aware that the reversing of client/server - roles and/or allowing both peers to act as client and server likely - introduces security considerations not foreseen by the authors of - this document. In particular, the security implications of the - design choices made in the authentication and data security models - for this extension (discussed in Sections 3 and 4, respectively) are - not fully studied. It is hoped that experimentation with this - extension will lead to better understanding of the security - implications of these models and other aspects of this extension, and - that appropriate considerations will be documented in a future - document. The following security considerations are apparent at this - time. - - Implementors should take special care to process LDAP, SASL, TLS, and - other events in the appropriate roles for the peers. Note that while - the Turn reverses the client/server roles with LDAP, and in SASL - authentication exchanges, it does not reverse the roles within the - TLS layer or the transport connection. - - The responding server (the original server) should restrict use of - this operation to authorized clients. Client knowledge of a valid - identifier should not be the sole factor in determining authorization - to turn. - - Where the peers except to establish TLS, TLS should be started prior - to the Turn and any request to authenticate via the Bind operation. - - LDAP security considerations [RFC4511][RFC4513] generally apply to - this extension. - -6. IANA Considerations - - The following values [RFC4520] have been registered by the IANA. - -6.1. Object Identifier - - The IANA has assigned an LDAP Object Identifier to identify the LDAP - Turn Operation, as defined in this document. - - - - - - - -Zeilenga Experimental [Page 6] - -RFC 4531 LDAP Turn Operation June 2006 - - - Subject: Request for LDAP Object Identifier Registration - Person & email address to contact for further information: - Kurt Zeilenga <kurt@OpenLDAP.org> - Specification: RFC 4531 - Author/Change Controller: Author - Comments: - Identifies the LDAP Turn Operation - -6.2. LDAP Protocol Mechanism - - The IANA has registered the LDAP Protocol Mechanism described in this - document. - - Subject: Request for LDAP Protocol Mechanism Registration - Object Identifier: 1.3.6.1.1.19 - Description: LDAP Turn Operation - Person & email address to contact for further information: - Kurt Zeilenga <kurt@openldap.org> - Usage: Extended Operation - Specification: RFC 4531 - Author/Change Controller: Author - Comments: none - -7. References - -7.1. Normative References - - [RFC4346] Dierks, T. and, E. Rescorla, "The Transport Layer - Security (TLS) Protocol Version 1.1", RFC 4346, April - 2006. - - [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple - Authentication and Security Layer (SASL)", RFC 4422, - June 2006. - - [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access - Protocol (LDAP): Technical Specification Road Map", RFC - 4510, June 2006. - - [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access - Protocol (LDAP): The Protocol", RFC 4511, June 2006. - - [RFC4513] Harrison, R., Ed., "Lightweight Directory Access - Protocol (LDAP): Authentication Methods and Security - Mechanisms", RFC 4513, June 2006. - - - - - - -Zeilenga Experimental [Page 7] - -RFC 4531 LDAP Turn Operation June 2006 - - - [X.680] International Telecommunication Union - - Telecommunication Standardization Sector, "Abstract - Syntax Notation One (ASN.1) - Specification of Basic - Notation", X.680(2002) (also ISO/IEC 8824-1:2002). - - [X.690] International Telecommunication Union - - Telecommunication Standardization Sector, - "Specification of ASN.1 encoding rules: Basic Encoding - Rules (BER), Canonical Encoding Rules (CER), and - Distinguished Encoding Rules (DER)", X.690(2002) (also - ISO/IEC 8825-1:2002). - -7.2. Informative References - - [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority - (IANA) Considerations for the Lightweight Directory - Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. - - [SASL-K5] Melnikov, A., Ed., "The Kerberos V5 ("GSSAPI") SASL - Mechanism", Work in Progress, May 2006. - -Author's Address - - Kurt D. Zeilenga - OpenLDAP Foundation - - EMail: Kurt@OpenLDAP.org - - - - - - - - - - - - - - - - - - - - - - - - -Zeilenga Experimental [Page 8] - -RFC 4531 LDAP Turn Operation June 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Zeilenga Experimental [Page 9] - diff --git a/source4/ldap_server/devdocs/rfc4532.txt b/source4/ldap_server/devdocs/rfc4532.txt deleted file mode 100644 index 277b3b7442..0000000000 --- a/source4/ldap_server/devdocs/rfc4532.txt +++ /dev/null @@ -1,395 +0,0 @@ - - - - - - -Network Working Group K. Zeilenga -Request for Comments: 4532 OpenLDAP Foundation -Category: Standards Track June 2006 - - - Lightweight Directory Access Protocol (LDAP) - "Who am I?" Operation - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This specification provides a mechanism for Lightweight Directory - Access Protocol (LDAP) clients to obtain the authorization identity - the server has associated with the user or application entity. This - mechanism is specified as an LDAP extended operation called the LDAP - "Who am I?" operation. - -1. Background and Intent of Use - - This specification describes a Lightweight Directory Access Protocol - (LDAP) [RFC4510] operation that clients can use to obtain the primary - authorization identity, in its primary form, that the server has - associated with the user or application entity. The operation is - called the "Who am I?" operation. - - This specification is intended to replace the existing Authorization - Identity Controls [RFC3829] mechanism, which uses Bind request and - response controls to request and return the authorization identity. - Bind controls are not protected by security layers established by the - Bind operation that includes them. While it is possible to establish - security layers using StartTLS [RFC4511][RFC4513] prior to the Bind - operation, it is often desirable to use security layers established - by the Bind operation. An extended operation sent after a Bind - operation is protected by the security layers established by the Bind - operation. - - - - - -Zeilenga Standards Track [Page 1] - -RFC 4532 LDAP "Who am I?" Operation June 2006 - - - There are other cases where it is desirable to request the - authorization identity that the server associated with the client - separately from the Bind operation. For example, the "Who am I?" - operation can be augmented with a Proxied Authorization Control - [RFC4370] to determine the authorization identity that the server - associates with the identity asserted in the Proxied Authorization - Control. The "Who am I?" operation can also be used prior to the - Bind operation. - - Servers often associate multiple authorization identities with the - client, and each authorization identity may be represented by - multiple authzId [RFC4513] strings. This operation requests and - returns the authzId that the server considers primary. In the - specification, the term "the authorization identity" and "the - authzId" are generally to be read as "the primary authorization - identity" and the "the primary authzId", respectively. - -1.1. Conventions Used in This Document - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in BCP 14 [RFC2119]. - -2. The "Who am I?" Operation - - The "Who am I?" operation is defined as an LDAP Extended Operation - [RFC4511] identified by the whoamiOID Object Identifier (OID). This - section details the syntax of the operation's whoami request and - response messages. - - whoamiOID ::= "1.3.6.1.4.1.4203.1.11.3" - -2.1. The whoami Request - - The whoami request is an ExtendedRequest with a requestName field - containing the whoamiOID OID and an absent requestValue field. For - example, a whoami request could be encoded as the sequence of octets - (in hex): - - 30 1e 02 01 02 77 19 80 17 31 2e 33 2e 36 2e 31 - 2e 34 2e 31 2e 34 32 30 33 2e 31 2e 31 31 2e 33 - - - - - - - - - - -Zeilenga Standards Track [Page 2] - -RFC 4532 LDAP "Who am I?" Operation June 2006 - - -2.2. The whoami Response - - The whoami response is an ExtendedResponse where the responseName - field is absent and the response field, if present, is empty or an - authzId [RFC4513]. For example, a whoami response returning the - authzId "u:xxyyz@EXAMPLE.NET" (in response to the example request) - would be encoded as the sequence of octets (in hex): - - 30 21 02 01 02 78 1c 0a 01 00 04 00 04 00 8b 13 - 75 3a 78 78 79 79 7a 40 45 58 41 4d 50 4c 45 2e - 4e 45 54 - -3. Operational Semantics - - The "Who am I?" operation provides a mechanism, a whoami Request, for - the client to request that the server return the authorization - identity it currently associates with the client. It also provides a - mechanism, a whoami Response, for the server to respond to that - request. - - Servers indicate their support for this extended operation by - providing a whoamiOID object identifier as a value of the - 'supportedExtension' attribute type in their root DSE. The server - SHOULD advertise this extension only when the client is willing and - able to perform this operation. - - If the server is willing and able to provide the authorization - identity it associates with the client, the server SHALL return a - whoami Response with a success resultCode. If the server is treating - the client as an anonymous entity, the response field is present but - empty. Otherwise, the server provides the authzId [RFC4513] - representing the authorization identity it currently associates with - the client in the response field. - - If the server is unwilling or unable to provide the authorization - identity it associates with the client, the server SHALL return a - whoami Response with an appropriate non-success resultCode (such as - operationsError, protocolError, confidentialityRequired, - insufficientAccessRights, busy, unavailable, unwillingToPerform, or - other) and an absent response field. - - As described in [RFC4511] and [RFC4513], an LDAP session has an - "anonymous" association until the client has been successfully - authenticated using the Bind operation. Clients MUST NOT invoke the - "Who am I?" operation while any Bind operation is in progress, - including between two Bind requests made as part of a multi-stage - - - - - -Zeilenga Standards Track [Page 3] - -RFC 4532 LDAP "Who am I?" Operation June 2006 - - - Bind operation. Where a whoami Request is received in violation of - this absolute prohibition, the server should return a whoami Response - with an operationsError resultCode. - -4. Extending the "Who am I?" Operation with Controls - - Future specifications may extend the "Who am I?" operation using the - control mechanism [RFC4511]. When extended by controls, the "Who am - I?" operation requests and returns the authorization identity the - server associates with the client in a particular context indicated - by the controls. - -4.1. Proxied Authorization Control - - The Proxied Authorization Control [RFC4370] is used by clients to - request that the operation it is attached to operate under the - authorization of an assumed identity. The client provides the - identity to assume in the Proxied Authorization request control. If - the client is authorized to assume the requested identity, the server - executes the operation as if the requested identity had issued the - operation. - - As servers often map the asserted authzId to another identity - [RFC4513], it is desirable to request that the server provide the - authzId it associates with the assumed identity. - - When a Proxied Authorization Control is be attached to the "Who am - I?" operation, the operation requests the return of the authzId the - server associates with the identity asserted in the Proxied - Authorization Control. The authorizationDenied (123) result code is - used to indicate that the server does not allow the client to assume - the asserted identity. - -5. Security Considerations - - Identities associated with users may be sensitive information. When - they are, security layers [RFC4511][RFC4513] should be established to - protect this information. This mechanism is specifically designed to - allow security layers established by a Bind operation to protect the - integrity and/or confidentiality of the authorization identity. - - Servers may place access control or other restrictions upon the use - of this operation. As stated in Section 3, the server SHOULD - advertise this extension when it is willing and able to perform the - operation. - - As with any other extended operations, general LDAP security - considerations [RFC4510] apply. - - - -Zeilenga Standards Track [Page 4] - -RFC 4532 LDAP "Who am I?" Operation June 2006 - - -6. IANA Considerations - - The OID 1.3.6.1.4.1.4203.1.11.3 is used to identify the LDAP "Who am - I?" extended operation. This OID was assigned [ASSIGN] by the - OpenLDAP Foundation, under its IANA-assigned private enterprise - allocation [PRIVATE], for use in this specification. - - Registration of this protocol mechanism [RFC4520] has been completed - by the IANA. - - Subject: Request for LDAP Protocol Mechanism Registration - Object Identifier: 1.3.6.1.4.1.4203.1.11.3 - Description: Who am I? - Person & email address to contact for further information: - Kurt Zeilenga <kurt@openldap.org> - Usage: Extended Operation - Specification: RFC 4532 - Author/Change Controller: IESG - Comments: none - -7. Acknowledgement - - This document borrows from prior work in this area, including - "Authentication Response Control" [RFC3829] by Rob Weltman, Mark - Smith, and Mark Wahl. - - The LDAP "Who am I?" operation takes it's name from the UNIX - whoami(1) command. The whoami(1) command displays the effective user - ID. - -8. References - -8.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC4370] Weltman, R., "Lightweight Directory Access Protocol (LDAP) - Proxied Authorization Control", RFC 4370, February 2006. - - [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol - (LDAP): Technical Specification Road Map", RFC 4510, June - 2006. - - [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access - Protocol (LDAP): The Protocol", RFC 4511, June 2006. - - - - - -Zeilenga Standards Track [Page 5] - -RFC 4532 LDAP "Who am I?" Operation June 2006 - - - [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol - (LDAP): Authentication Methods and Security Mechanisms", - RFC 4513, June 2006. - -8.2. Informative References - - [RFC3829] Weltman, R., Smith, M., and M. Wahl, "Lightweight Directory - Access Protocol (LDAP) Authorization Identity Request and - Response Controls", RFC 3829, July 2004. - - [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) - Considerations for the Lightweight Directory Access - Protocol (LDAP)", BCP 64, RFC 4520, June 2006. - - [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", - http://www.openldap.org/foundation/oid-delegate.txt. - - [PRIVATE] IANA, "Private Enterprise Numbers", - http://www.iana.org/assignments/enterprise-numbers. - -Author's Address - - Kurt D. Zeilenga - OpenLDAP Foundation - - EMail: Kurt@OpenLDAP.org - - - - - - - - - - - - - - - - - - - - - - - - - -Zeilenga Standards Track [Page 6] - -RFC 4532 LDAP "Who am I?" Operation June 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Zeilenga Standards Track [Page 7] - diff --git a/source4/ldap_server/devdocs/rfc4533.txt b/source4/ldap_server/devdocs/rfc4533.txt deleted file mode 100644 index 5f507ceae8..0000000000 --- a/source4/ldap_server/devdocs/rfc4533.txt +++ /dev/null @@ -1,1795 +0,0 @@ - - - - - - -Network Working Group K. Zeilenga -Request for Comments: 4533 OpenLDAP Foundation -Category: Experimental J.H. Choi - IBM Corporation - June 2006 - - - The Lightweight Directory Access Protocol (LDAP) - Content Synchronization Operation - -Status of This Memo - - This memo defines an Experimental Protocol for the Internet - community. It does not specify an Internet standard of any kind. - Discussion and suggestions for improvement are requested. - Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -IESG Note - - The IESG notes that this work was originally discussed in the LDUP - working group. The group came to consensus on a different approach, - documented in RFC 3928; that document is on the standards track and - should be reviewed by those considering implementation of this - proposal. - -Abstract - - This specification describes the Lightweight Directory Access - Protocol (LDAP) Content Synchronization Operation. The operation - allows a client to maintain a copy of a fragment of the Directory - Information Tree (DIT). It supports both polling for changes and - listening for changes. The operation is defined as an extension of - the LDAP Search Operation. - - - - - - - - - - - - - - -Zeilenga & Choi Experimental [Page 1] - -RFC 4533 LDAP Content Synchronization Operation June 2006 - - -Table of Contents - - 1. Introduction ....................................................3 - 1.1. Background .................................................3 - 1.2. Intended Usage .............................................4 - 1.3. Overview ...................................................5 - 1.4. Conventions ................................................8 - 2. Elements of the Sync Operation ..................................8 - 2.1. Common ASN.1 Elements ......................................9 - 2.2. Sync Request Control .......................................9 - 2.3. Sync State Control ........................................10 - 2.4. Sync Done Control .........................................10 - 2.5. Sync Info Message .........................................11 - 2.6. Sync Result Codes .........................................11 - 3. Content Synchronization ........................................11 - 3.1. Synchronization Session ...................................12 - 3.2. Content Determination .....................................12 - 3.3. refreshOnly Mode ..........................................13 - 3.4. refreshAndPersist Mode ....................................16 - 3.5. Search Request Parameters .................................17 - 3.6. objectName ................................................18 - 3.7. Canceling the Sync Operation ..............................19 - 3.8. Refresh Required ..........................................19 - 3.9. Chattiness Considerations .................................20 - 3.10. Operation Multiplexing ...................................21 - 4. Meta Information Considerations ................................22 - 4.1. Entry DN ..................................................22 - 4.2. Operational Attributes ....................................22 - 4.3. Collective Attributes .....................................23 - 4.4. Access and Other Administrative Controls ..................23 - 5. Interaction with Other Controls ................................23 - 5.1. ManageDsaIT Control .......................................24 - 5.2. Subentries Control ........................................24 - 6. Shadowing Considerations .......................................24 - 7. Security Considerations ........................................25 - 8. IANA Considerations ............................................26 - 8.1. Object Identifier .........................................26 - 8.2. LDAP Protocol Mechanism ...................................26 - 8.3. LDAP Result Codes .........................................26 - 9. Acknowledgements ...............................................26 - 10. Normative References ..........................................27 - 11. Informative References ........................................28 - Appendix A. CSN-based Implementation Considerations ..............29 - - - - - - - - -Zeilenga & Choi Experimental [Page 2] - -RFC 4533 LDAP Content Synchronization Operation June 2006 - - -1. Introduction - - The Lightweight Directory Access Protocol (LDAP) [RFC4510] provides a - mechanism, the search operation [RFC4511], that allows a client to - request directory content matching a complex set of assertions and to - request that the server return this content, subject to access - control and other restrictions, to the client. However, LDAP does - not provide (despite the introduction of numerous extensions in this - area) an effective and efficient mechanism for maintaining - synchronized copies of directory content. This document introduces a - new mechanism specifically designed to meet the content - synchronization requirements of sophisticated directory applications. - - This document defines the LDAP Content Synchronization Operation, or - Sync Operation for short, which allows a client to maintain a - synchronized copy of a fragment of a Directory Information Tree - (DIT). The Sync Operation is defined as a set of controls and other - protocol elements that extend the Search Operation. - -1.1. Background - - Over the years, a number of content synchronization approaches have - been suggested for use in LDAP directory services. These approaches - are inadequate for one or more of the following reasons: - - - failure to ensure a reasonable level of convergence; - - - failure to detect that convergence cannot be achieved (without - reload); - - - require pre-arranged synchronization agreements; - - - require the server to maintain histories of past changes to DIT - content and/or meta information; - - - require the server to maintain synchronization state on a per- - client basis; and/or - - - are overly chatty. - - The Sync Operation provides eventual convergence of synchronized - content when possible and, when not, notification that a full reload - is required. - - The Sync Operation does not require pre-arranged synchronization - agreements. - - - - - -Zeilenga & Choi Experimental [Page 3] - -RFC 4533 LDAP Content Synchronization Operation June 2006 - - - The Sync Operation does not require that servers maintain or use any - history of past changes to the DIT or to meta information. However, - servers may maintain and use histories (e.g., change logs, - tombstones, DIT snapshots) to reduce the number of messages generated - and to reduce their size. As it is not always feasible to maintain - and use histories, the operation may be implemented using purely - (current) state-based approaches. The Sync Operation allows use of - either the state-based approach or the history-based approach on an - operation-by-operation basis to balance the size of history and the - amount of traffic. The Sync Operation also allows the combined use - of the state-based and the history-based approaches. - - The Sync Operation does not require that servers maintain - synchronization state on a per-client basis. However, servers may - maintain and use per-client state information to reduce the number of - messages generated and the size of such messages. - - A synchronization mechanism can be considered overly chatty when - synchronization traffic is not reasonably bounded. The Sync - Operation traffic is bounded by the size of updated (or new) entries - and the number of unchanged entries in the content. The operation is - designed to avoid full content exchanges, even when the history - information available to the server is insufficient to determine the - client's state. The operation is also designed to avoid transmission - of out-of-content history information, as its size is not bounded by - the content and it is not always feasible to transmit such history - information due to security reasons. - - This document includes a number of non-normative appendices providing - additional information to server implementors. - -1.2. Intended Usage - - The Sync Operation is intended to be used in applications requiring - eventually-convergent content synchronization. Upon completion of - each synchronization stage of the operation, all information to - construct a synchronized client copy of the content has been provided - to the client or the client has been notified that a complete content - reload is necessary. Except for transient inconsistencies due to - concurrent operation (or other) processing at the server, the client - copy is an accurate reflection of the content held by the server. - Transient inconsistencies will be resolved by subsequent - synchronization operations. - - - - - - - - -Zeilenga & Choi Experimental [Page 4] - -RFC 4533 LDAP Content Synchronization Operation June 2006 - - - Possible uses include the following: - - - White page service applications may use the Sync Operation to - maintain a current copy of a DIT fragment, for example, a mail - user agent that uses the sync operation to maintain a local - copy of an enterprise address book. - - - Meta-information engines may use the Sync Operation to maintain - a copy of a DIT fragment. - - - Caching proxy services may use the Sync Operation to maintain a - coherent content cache. - - - Lightweight master-slave replication between heterogeneous - directory servers. For example, the Sync Operation can be used - by a slave server to maintain a shadow copy of a DIT fragment. - (Note: The International Telephone Union (ITU) has defined the - X.500 Directory [X.500] Information Shadowing Protocol (DISP) - [X.525], which may be used for master-slave replication between - directory servers. Other experimental LDAP replication - protocols also exist.) - - This protocol is not intended to be used in applications requiring - transactional data consistency. - - As this protocol transfers all visible values of entries belonging to - the content upon change instead of change deltas, this protocol is - not appropriate for bandwidth-challenged applications or deployments. - -1.3. Overview - - This section provides an overview of basic ways the Sync Operation - can be used to maintain a synchronized client copy of a DIT fragment. - - - Polling for changes: refreshOnly mode - - - Listening for changes: refreshAndPersist mode - -1.3.1. Polling for Changes (refreshOnly) - - To obtain its initial client copy, the client issues a Sync request: - a search request with the Sync Request Control with mode set to - refreshOnly. The server, much like it would with a normal search - operation, returns (subject to access controls and other - restrictions) the content matching the search criteria (baseObject, - scope, filter, attributes). Additionally, with each entry returned, - the server provides a Sync State Control indicating state add. This - control contains the Universally Unique Identifier (UUID) [UUID] of - - - -Zeilenga & Choi Experimental [Page 5] - -RFC 4533 LDAP Content Synchronization Operation June 2006 - - - the entry [RFC4530]. Unlike the Distinguished Name (DN), which may - change over time, an entry's UUID is stable. The initial content is - followed by a SearchResultDone with a Sync Done Control. The Sync - Done Control provides a syncCookie. The syncCookie represents - session state. - - To poll for updates to the client copy, the client reissues the Sync - Operation with the syncCookie previously returned. The server, much - as it would with a normal search operation, determines which content - would be returned as if the operation were a normal search operation. - However, using the syncCookie as an indicator of what content the - client was sent previously, the server sends copies of entries that - have changed with a Sync State Control indicating state add. For - each changed entry, all (modified or unmodified) attributes belonging - to the content are sent. - - The server may perform either or both of the two distinct - synchronization phases that are distinguished by how to synchronize - entries deleted from the content: the present and the delete phases. - When the server uses a single phase for the refresh stage, each phase - is marked as ended by a SearchResultDone with a Sync Done Control. A - present phase is identified by a FALSE refreshDeletes value in the - Sync Done Control. A delete phase is identified by a TRUE - refreshDeletes value. The present phase may be followed by a delete - phase. The two phases are delimited by a refreshPresent Sync Info - Message having a FALSE refreshDone value. In the case that both the - phases are used, the present phase is used to bring the client copy - up to the state at which the subsequent delete phase can begin. - - In the present phase, the server sends an empty entry (i.e., no - attributes) with a Sync State Control indicating state present for - each unchanged entry. - - The delete phase may be used when the server can reliably determine - which entries in the prior client copy are no longer present in the - content and the number of such entries is less than or equal to the - number of unchanged entries. In the delete mode, the server sends an - empty entry with a Sync State Control indicating state delete for - each entry that is no longer in the content, instead of returning an - empty entry with state present for each present entry. - - The server may send syncIdSet Sync Info Messages containing the set - of UUIDs of either unchanged present entries or deleted entries, - instead of sending multiple individual messages. If refreshDeletes - of syncIdSet is set to FALSE, the UUIDs of unchanged present entries - are contained in the syncUUIDs set; if refreshDeletes of syncIdSet is - set to TRUE, the UUIDs of the entries no longer present in the - content are contained in the syncUUIDs set. An optional cookie can - - - -Zeilenga & Choi Experimental [Page 6] - -RFC 4533 LDAP Content Synchronization Operation June 2006 - - - be included in the syncIdSet to represent the state of the content - after synchronizing the presence or the absence of the entries - contained in the syncUUIDs set. - - The synchronized copy of the DIT fragment is constructed by the - client. - - If refreshDeletes of syncDoneValue is FALSE, the new copy includes - all changed entries returned by the reissued Sync Operation, as well - as all unchanged entries identified as being present by the reissued - Sync Operation, but whose content is provided by the previous Sync - Operation. The unchanged entries not identified as being present are - deleted from the client content. They had been either deleted, - moved, or otherwise scoped-out from the content. - - If refreshDeletes of syncDoneValue is TRUE, the new copy includes all - changed entries returned by the reissued Sync Operation, as well as - all other entries of the previous copy except for those that are - identified as having been deleted from the content. - - The client can, at some later time, re-poll for changes to this - synchronized client copy. - -1.3.2. Listening for Changes (refreshAndPersist) - - Polling for changes can be expensive in terms of server, client, and - network resources. The refreshAndPersist mode allows for active - updates of changed entries in the content. - - By selecting the refreshAndPersist mode, the client requests that the - server send updates of entries that are changed after the initial - refresh content is determined. Instead of sending a SearchResultDone - Message as in polling, the server sends a Sync Info Message to the - client indicating that the refresh stage is complete and then enters - the persist stage. After receipt of this Sync Info Message, the - client will construct a synchronized copy as described in Section - 1.3.1. - - The server may then send change notifications as the result of the - original Sync search request, which now remains persistent in the - server. For entries to be added to the returned content, the server - sends a SearchResultEntry (with attributes) with a Sync State Control - indicating state add. For entries to be deleted from the content, - the server sends a SearchResultEntry containing no attributes and a - Sync State Control indicating state delete. For entries to be - modified in the return content, the server sends a SearchResultEntry - (with attributes) with a Sync State Control indicating state modify. - - - - -Zeilenga & Choi Experimental [Page 7] - -RFC 4533 LDAP Content Synchronization Operation June 2006 - - - Upon modification of an entry, all (modified or unmodified) - attributes belonging to the content are sent. - - Note that renaming an entry of the DIT may cause an add state change - where the entry is renamed into the content, a delete state change - where the entry is renamed out of the content, and a modify state - change where the entry remains in the content. Also note that a - modification of an entry of the DIT may cause an add, delete, or - modify state change to the content. - - Upon receipt of a change notification, the client updates its copy of - the content. - - If the server desires to update the syncCookie during the persist - stage, it may include the syncCookie in any Sync State Control or - Sync Info Message returned. - - The operation persists until canceled [RFC3909] by the client or - terminated by the server. A Sync Done Control shall be attached to - SearchResultDone Message to provide a new syncCookie. - -1.4. Conventions - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in BCP 14 [RFC2119]. - - Protocol elements are described using ASN.1 [X.680] with implicit - tags. The term "BER-encoded" means the element is to be encoded - using the Basic Encoding Rules [X.690] under the restrictions - detailed in Section 5.1 of [RFC4511]. - -2. Elements of the Sync Operation - - The Sync Operation is defined as an extension to the LDAP Search - Operation [RFC4511] where the directory user agent (DUA or client) - submits a SearchRequest Message with a Sync Request Control and the - directory system agent (DSA or server) responds with zero or more - SearchResultEntry Messages, each with a Sync State Control; zero or - more SearchResultReference Messages, each with a Sync State Control; - zero or more Sync Info Intermediate Response Messages; and a - SearchResultDone Message with a Sync Done Control. - - To allow clients to discover support for this operation, servers - implementing this operation SHOULD publish 1.3.6.1.4.1.4203.1.9.1.1 - as a value of the 'supportedControl' attribute [RFC4512] of the root - DSA-specific entry (DSE). A server MAY choose to advertise this - extension only when the client is authorized to use it. - - - -Zeilenga & Choi Experimental [Page 8] - -RFC 4533 LDAP Content Synchronization Operation June 2006 - - -2.1. Common ASN.1 Elements - -2.1.1. syncUUID - - The syncUUID data type is an OCTET STRING holding a 128-bit - (16-octet) Universally Unique Identifier (UUID) [UUID]. - - syncUUID ::= OCTET STRING (SIZE(16)) - -- constrained to UUID - -2.1.2. syncCookie - - The syncCookie is a notational convenience to indicate that, while - the syncCookie type is encoded as an OCTET STRING, its value is an - opaque value containing information about the synchronization session - and its state. Generally, the session information would include a - hash of the operation parameters that the server requires not be - changed and the synchronization state information would include a - commit (log) sequence number, a change sequence number, or a time - stamp. For convenience of description, the term "no cookie" refers - either to a null cookie or to a cookie with pre-initialized - synchronization state. - - syncCookie ::= OCTET STRING - -2.2. Sync Request Control - - The Sync Request Control is an LDAP Control [RFC4511] where the - controlType is the object identifier 1.3.6.1.4.1.4203.1.9.1.1 and the - controlValue, an OCTET STRING, contains a BER-encoded - syncRequestValue. The criticality field is either TRUE or FALSE. - - syncRequestValue ::= SEQUENCE { - mode ENUMERATED { - -- 0 unused - refreshOnly (1), - -- 2 reserved - refreshAndPersist (3) - }, - cookie syncCookie OPTIONAL, - reloadHint BOOLEAN DEFAULT FALSE - } - - The Sync Request Control is only applicable to the SearchRequest - Message. - - - - - - -Zeilenga & Choi Experimental [Page 9] - -RFC 4533 LDAP Content Synchronization Operation June 2006 - - -2.3. Sync State Control - - The Sync State Control is an LDAP Control [RFC4511] where the - controlType is the object identifier 1.3.6.1.4.1.4203.1.9.1.2 and the - controlValue, an OCTET STRING, contains a BER-encoded syncStateValue. - The criticality is FALSE. - - syncStateValue ::= SEQUENCE { - state ENUMERATED { - present (0), - add (1), - modify (2), - delete (3) - }, - entryUUID syncUUID, - cookie syncCookie OPTIONAL - } - - The Sync State Control is only applicable to SearchResultEntry and - SearchResultReference Messages. - -2.4. Sync Done Control - - The Sync Done Control is an LDAP Control [RFC4511] where the - controlType is the object identifier 1.3.6.1.4.1.4203.1.9.1.3 and the - controlValue contains a BER-encoded syncDoneValue. The criticality - is FALSE (and hence absent). - - syncDoneValue ::= SEQUENCE { - cookie syncCookie OPTIONAL, - refreshDeletes BOOLEAN DEFAULT FALSE - } - - The Sync Done Control is only applicable to the SearchResultDone - Message. - - - - - - - - - - - - - - - - -Zeilenga & Choi Experimental [Page 10] - -RFC 4533 LDAP Content Synchronization Operation June 2006 - - -2.5. Sync Info Message - - The Sync Info Message is an LDAP Intermediate Response Message - [RFC4511] where responseName is the object identifier - 1.3.6.1.4.1.4203.1.9.1.4 and responseValue contains a BER-encoded - syncInfoValue. The criticality is FALSE (and hence absent). - - syncInfoValue ::= CHOICE { - newcookie [0] syncCookie, - refreshDelete [1] SEQUENCE { - cookie syncCookie OPTIONAL, - refreshDone BOOLEAN DEFAULT TRUE - }, - refreshPresent [2] SEQUENCE { - cookie syncCookie OPTIONAL, - refreshDone BOOLEAN DEFAULT TRUE - }, - syncIdSet [3] SEQUENCE { - cookie syncCookie OPTIONAL, - refreshDeletes BOOLEAN DEFAULT FALSE, - syncUUIDs SET OF syncUUID - } - } - -2.6. Sync Result Codes - - The following LDAP resultCode [RFC4511] is defined: - - e-syncRefreshRequired (4096) - -3. Content Synchronization - - The Sync Operation is invoked when the client sends a SearchRequest - Message with a Sync Request Control. - - The absence of a cookie or an initialized synchronization state in a - cookie indicates a request for initial content, while the presence of - a cookie representing a state of a client copy indicates a request - for a content update. Synchronization Sessions are discussed in - Section 3.1. Content Determination is discussed in Section 3.2. - - The mode is either refreshOnly or refreshAndPersist. The refreshOnly - and refreshAndPersist modes are discussed in Sections 3.3 and 3.4, - respectively. The refreshOnly mode consists only of a refresh stage, - while the refreshAndPersist mode consists of a refresh stage and a - subsequent persist stage. - - - - - -Zeilenga & Choi Experimental [Page 11] - -RFC 4533 LDAP Content Synchronization Operation June 2006 - - -3.1. Synchronization Session - - A sequence of Sync Operations where the last cookie returned by the - server for one operation is provided by the client in the next - operation is said to belong to the same Synchronization Session. - - The client MUST specify the same content-controlling parameters (see - Section 3.5) in each Search Request of the session. The client - SHOULD also issue each Sync request of a session under the same - authentication and authorization associations with equivalent - integrity and protections. If the server does not recognize the - request cookie or the request is made under different associations or - non-equivalent protections, the server SHALL return the initial - content as if no cookie had been provided or return an empty content - with the e-syncRefreshRequired LDAP result code. The decision - between the return of the initial content and the return of the empty - content with the e-syncRefreshRequired result code MAY be based on - reloadHint in the Sync Request Control from the client. If the - server recognizes the request cookie as representing empty or initial - synchronization state of the client copy, the server SHALL return the - initial content. - - A Synchronization Session may span multiple LDAP sessions between the - client and the server. The client SHOULD issue each Sync request of - a session to the same server. (Note: Shadowing considerations are - discussed in Section 6.) - -3.2. Content Determination - - The content to be provided is determined by parameters of the Search - Request, as described in [RFC4511], and possibly other controls. The - same content parameters SHOULD be used in each Sync request of a - session. If different content is requested and the server is - unwilling or unable to process the request, the server SHALL return - the initial content as if no cookie had been provided or return an - empty content with the e-syncRefreshRequired LDAP result code. The - decision between the return of the initial content and the return of - the empty content with the e-syncRefreshRequired result code MAY be - based on reloadHint in the Sync Request Control from the client. - - The content may not necessarily include all entries or references - that would be returned by a normal search operation, nor, for those - entries included, all attributes returned by a normal search. When - the server is unwilling or unable to provide synchronization for any - attribute for a set of entries, the server MUST treat all filter - components matching against these attributes as Undefined and MUST - NOT return these attributes in SearchResultEntry responses. - - - - -Zeilenga & Choi Experimental [Page 12] - -RFC 4533 LDAP Content Synchronization Operation June 2006 - - - Servers SHOULD support synchronization for all non-collective user- - application attributes for all entries. - - The server may also return continuation references to other servers - or to itself. The latter is allowed as the server may partition the - entries it holds into separate synchronization contexts. - - The client may chase all or some of these continuations, each as a - separate content synchronization session. - -3.3. refreshOnly Mode - - A Sync request with mode refreshOnly and with no cookie is a poll for - initial content. A Sync request with mode refreshOnly and with a - cookie representing a synchronization state is a poll for content - update. - -3.3.1. Initial Content Poll - - Upon receipt of the request, the server provides the initial content - using a set of zero or more SearchResultEntry and - SearchResultReference Messages followed by a SearchResultDone - Message. - - Each SearchResultEntry Message SHALL include a Sync State Control of - state add, an entryUUID containing the entry's UUID, and no cookie. - Each SearchResultReference Message SHALL include a Sync State Control - of state add, an entryUUID containing the UUID associated with the - reference (normally the UUID of the associated named referral - [RFC3296] object), and no cookie. The SearchResultDone Message SHALL - include a Sync Done Control having refreshDeletes set to FALSE. - - A resultCode value of success indicates that the operation - successfully completed. Otherwise, the result code indicates the - nature of the failure. The server may return e-syncRefreshRequired - result code on the initial content poll if it is safe to do so when - it is unable to perform the operation due to various reasons. - reloadHint is set to FALSE in the SearchRequest Message requesting - the initial content poll. - - If the operation is successful, a cookie representing the - synchronization state of the current client copy SHOULD be returned - for use in subsequent Sync Operations. - -3.3.2. Content Update Poll - - Upon receipt of the request, the server provides the content refresh - using a set of zero or more SearchResultEntry and - - - -Zeilenga & Choi Experimental [Page 13] - -RFC 4533 LDAP Content Synchronization Operation June 2006 - - - SearchResultReference Messages followed by a SearchResultDone - Message. - - The server is REQUIRED to: - - a) provide the sequence of messages necessary for eventual - convergence of the client's copy of the content to the server's - copy, - - b) treat the request as an initial content request (e.g., ignore - the cookie or the synchronization state represented in the - cookie), - - c) indicate that the incremental convergence is not possible by - returning e-syncRefreshRequired, - - d) return a resultCode other than success or e- - syncRefreshRequired. - - A Sync Operation may consist of a single present phase, a single - delete phase, or a present phase followed by a delete phase. - - In each phase, for each entry or reference that has been added to the - content or been changed since the previous Sync Operation indicated - by the cookie, the server returns a SearchResultEntry or - SearchResultReference Message, respectively, each with a Sync State - Control consisting of state add, an entryUUID containing the UUID of - the entry or reference, and no cookie. Each SearchResultEntry - Message represents the current state of a changed entry. Each - SearchResultReference Message represents the current state of a - changed reference. - - In the present phase, for each entry that has not been changed since - the previous Sync Operation, an empty SearchResultEntry is returned - whose objectName reflects the entry's current DN, whose attributes - field is empty, and whose Sync State Control consists of state - present, an entryUUID containing the UUID of the entry, and no - cookie. For each reference that has not been changed since the - previous Sync Operation, an empty SearchResultReference containing an - empty SEQUENCE OF LDAPURL is returned with a Sync State Control - consisting of state present, an entryUUID containing the UUID of the - entry, and no cookie. No messages are sent for entries or references - that are no longer in the content. - - Multiple empty entries with a Sync State Control of state present - SHOULD be coalesced into one or more Sync Info Messages of syncIdSet - value with refreshDeletes set to FALSE. syncUUIDs contain a set of - UUIDs of the entries and references unchanged since the last Sync - - - -Zeilenga & Choi Experimental [Page 14] - -RFC 4533 LDAP Content Synchronization Operation June 2006 - - - Operation. syncUUIDs may be empty. The Sync Info Message of - syncIdSet may contain a cookie to represent the state of the content - after performing the synchronization of the entries in the set. - - In the delete phase, for each entry no longer in the content, the - server returns a SearchResultEntry whose objectName reflects a past - DN of the entry or is empty, whose attributes field is empty, and - whose Sync State Control consists of state delete, an entryUUID - containing the UUID of the deleted entry, and no cookie. For each - reference no longer in the content, a SearchResultReference - containing an empty SEQUENCE OF LDAPURL is returned with a Sync State - Control consisting of state delete, an entryUUID containing the UUID - of the deleted reference, and no cookie. - - Multiple empty entries with a Sync State Control of state delete - SHOULD be coalesced into one or more Sync Info Messages of syncIdSet - value with refreshDeletes set to TRUE. syncUUIDs contain a set of - UUIDs of the entries and references that have been deleted from the - content since the last Sync Operation. syncUUIDs may be empty. The - Sync Info Message of syncIdSet may contain a cookie to represent the - state of the content after performing the synchronization of the - entries in the set. - - When a present phase is followed by a delete phase, the two phases - are delimited by a Sync Info Message containing syncInfoValue of - refreshPresent, which may contain a cookie representing the state - after completing the present phase. The refreshPresent contains - refreshDone, which is always FALSE in the refreshOnly mode of Sync - Operation because it is followed by a delete phase. - - If a Sync Operation consists of a single phase, each phase and hence - the Sync Operation are marked as ended by a SearchResultDone Message - with Sync Done Control, which SHOULD contain a cookie representing - the state of the content after completing the Sync Operation. The - Sync Done Control contains refreshDeletes, which is set to FALSE for - the present phase and set to TRUE for the delete phase. - - If a Sync Operation consists of a present phase followed by a delete - phase, the Sync Operation is marked as ended at the end of the delete - phase by a SearchResultDone Message with Sync Done Control, which - SHOULD contain a cookie representing the state of the content after - completing the Sync Operation. The Sync Done Control contains - refreshDeletes, which is set to TRUE. - - The client can specify whether it prefers to receive an initial - content by supplying reloadHint of TRUE or to receive a e- - syncRefreshRequired resultCode by supplying reloadHint of FALSE - (hence absent), in the case that the server determines that it is - - - -Zeilenga & Choi Experimental [Page 15] - -RFC 4533 LDAP Content Synchronization Operation June 2006 - - - impossible or inefficient to achieve the eventual convergence by - continuing the current incremental synchronization thread. - - A resultCode value of success indicates that the operation is - successfully completed. A resultCode value of e-syncRefreshRequired - indicates that a full or partial refresh is needed. Otherwise, the - result code indicates the nature of failure. A cookie is provided in - the Sync Done Control for use in subsequent Sync Operations for - incremental synchronization. - -3.4. refreshAndPersist Mode - - A Sync request with mode refreshAndPersist asks for initial content - or content update (during the refresh stage) followed by change - notifications (during the persist stage). - -3.4.1. refresh Stage - - The content refresh is provided as described in Section 3.3, except - that the successful completion of content refresh is indicated by - sending a Sync Info Message of refreshDelete or refreshPresent with a - refreshDone value set to TRUE instead of a SearchResultDone Message - with resultCode success. A cookie SHOULD be returned in the Sync - Info Message to represent the state of the content after finishing - the refresh stage of the Sync Operation. - -3.4.2. persist Stage - - Change notifications are provided during the persist stage. - - As updates are made to the DIT, the server notifies the client of - changes to the content. DIT updates may cause entries and references - to be added to the content, deleted from the content, or modified - within the content. DIT updates may also cause references to be - added, deleted, or modified within the content. - - Where DIT updates cause an entry to be added to the content, the - server provides a SearchResultEntry Message that represents the entry - as it appears in the content. The message SHALL include a Sync State - Control with state of add, an entryUUID containing the entry's UUID, - and an optional cookie. - - Where DIT updates cause a reference to be added to the content, the - server provides a SearchResultReference Message that represents the - reference in the content. The message SHALL include a Sync State - Control with state of add, an entryUUID containing the UUID - associated with the reference, and an optional cookie. - - - - -Zeilenga & Choi Experimental [Page 16] - -RFC 4533 LDAP Content Synchronization Operation June 2006 - - - Where DIT updates cause an entry to be modified within the content, - the server provides a SearchResultEntry Message that represents the - entry as it appears in the content. The message SHALL include a Sync - State Control with state of modify, an entryUUID containing the - entry's UUID, and an optional cookie. - - Where DIT updates cause a reference to be modified within the - content, the server provides a SearchResultReference Message that - represents the reference in the content. The message SHALL include a - Sync State Control with state of modify, an entryUUID containing the - UUID associated with the reference, and an optional cookie. - - Where DIT updates cause an entry to be deleted from the content, the - server provides a SearchResultEntry Message with no attributes. The - message SHALL include a Sync State Control with state of delete, an - entryUUID containing the entry's UUID, and an optional cookie. - - Where DIT updates cause a reference to be deleted from the content, - the server provides a SearchResultReference Message with an empty - SEQUENCE OF LDAPURL. The message SHALL include a Sync State Control - with state of delete, an entryUUID containing the UUID associated - with the reference, and an optional cookie. - - Multiple empty entries with a Sync State Control of state delete - SHOULD be coalesced into one or more Sync Info Messages of syncIdSet - value with refreshDeletes set to TRUE. syncUUIDs contain a set of - UUIDs of the entries and references that have been deleted from the - content. The Sync Info Message of syncIdSet may contain a cookie to - represent the state of the content after performing the - synchronization of the entries in the set. - - With each of these messages, the server may provide a new cookie to - be used in subsequent Sync Operations. Additionally, the server may - also return Sync Info Messages of choice newCookie to provide a new - cookie. The client SHOULD use the newest (last) cookie it received - from the server in subsequent Sync Operations. - -3.5. Search Request Parameters - - As stated in Section 3.1, the client SHOULD specify the same - content-controlling parameters in each Search Request of the session. - All fields of the SearchRequest Message are considered content- - controlling parameters except for sizeLimit and timeLimit. - - - - - - - - -Zeilenga & Choi Experimental [Page 17] - -RFC 4533 LDAP Content Synchronization Operation June 2006 - - -3.5.1. baseObject - - As with the normal search operation, the refresh and persist stages - are not isolated from DIT changes. It is possible that the entry - referred to by the baseObject is deleted, renamed, or moved. It is - also possible that the alias object used in finding the entry - referred to by the baseObject is changed such that the baseObject - refers to a different entry. - - If the DIT is updated during processing of the Sync Operation in a - manner that causes the baseObject no longer to refer to any entry or - in a manner that changes the entry the baseObject refers to, the - server SHALL return an appropriate non-success result code, such as - noSuchObject, aliasProblem, aliasDereferencingProblem, referral, or - e-syncRefreshRequired. - -3.5.2. derefAliases - - This operation does not support alias dereferencing during searching. - The client SHALL specify neverDerefAliases or derefFindingBaseObj for - the SearchRequest derefAliases parameter. The server SHALL treat - other values (e.g., derefInSearching, derefAlways) as protocol - errors. - -3.5.3. sizeLimit - - The sizeLimit applies only to entries (regardless of their state in - Sync State Control) returned during the refreshOnly operation or the - refresh stage of the refreshAndPersist operation. - -3.5.4. timeLimit - - For a refreshOnly Sync Operation, the timeLimit applies to the whole - operation. For a refreshAndPersist operation, the timeLimit applies - only to the refresh stage including the generation of the Sync Info - Message with a refreshDone value of TRUE. - -3.5.5. filter - - The client SHOULD avoid filter assertions that apply to the values of - the attributes likely to be considered by the server as ones holding - meta-information. See Section 4. - -3.6. objectName - - The Sync Operation uses entryUUID values provided in the Sync State - Control as the primary keys to entries. The client MUST use these - entryUUIDs to correlate synchronization messages. - - - -Zeilenga & Choi Experimental [Page 18] - -RFC 4533 LDAP Content Synchronization Operation June 2006 - - - In some circumstances, the DN returned may not reflect the entry's - current DN. In particular, when the entry is being deleted from the - content, the server may provide an empty DN if the server does not - wish to disclose the entry's current DN (or, if deleted from the DIT, - the entry's last DN). - - Also note that the entry's DN may be viewed as meta information (see - Section 4.1). - -3.7. Canceling the Sync Operation - - Servers MUST implement the LDAP Cancel [RFC3909] Operation and - support cancellation of outstanding Sync Operations as described - here. - - To cancel an outstanding Sync Operation, the client issues an LDAP - Cancel [RFC3909] Operation. - - If at any time the server becomes unwilling or unable to continue - processing a Sync Operation, the server SHALL return a - SearchResultDone with a non-success resultCode indicating the reason - for the termination of the operation. - - Whether the client or the server initiated the termination, the - server may provide a cookie in the Sync Done Control for use in - subsequent Sync Operations. - -3.8. Refresh Required - - In order to achieve the eventually-convergent synchronization, the - server may terminate the Sync Operation in the refresh or persist - stages by returning an e-syncRefreshRequired resultCode to the - client. If no cookie is provided, a full refresh is needed. If a - cookie representing a synchronization state is provided in this - response, an incremental refresh is needed. - - To obtain a full refresh, the client then issues a new - synchronization request with no cookie. To obtain an incremental - reload, the client issues a new synchronization with the provided - cookie. - - The server may choose to provide a full copy in the refresh stage - (e.g., ignore the cookie or the synchronization state represented in - the cookie) instead of providing an incremental refresh in order to - achieve the eventual convergence. - - - - - - -Zeilenga & Choi Experimental [Page 19] - -RFC 4533 LDAP Content Synchronization Operation June 2006 - - - The decision between the return of the initial content and the return - of the e-syncRefreshRequired result code may be based on reloadHint - in the Sync Request Control from the client. - - In the case of persist stage Sync, the server returns the resultCode - of e-syncRefreshRequired to the client to indicate that the client - needs to issue a new Sync Operation in order to obtain a synchronized - copy of the content. If no cookie is provided, a full refresh is - needed. If a cookie representing a synchronization state is - provided, an incremental refresh is needed. - - The server may also return e-syncRefreshRequired if it determines - that a refresh would be more efficient than sending all the messages - required for convergence. - - Note that the client may receive one or more of SearchResultEntry, - SearchResultReference, and/or Sync Info Messages before it receives a - SearchResultDone Message with the e-syncRefreshRequired result code. - -3.9. Chattiness Considerations - - The server MUST ensure that the number of entry messages generated to - refresh the client content does not exceed the number of entries - presently in the content. While there is no requirement for servers - to maintain history information, if the server has sufficient history - to allow it to reliably determine which entries in the prior client - copy are no longer present in the content and the number of such - entries is less than or equal to the number of unchanged entries, the - server SHOULD generate delete entry messages instead of present entry - messages (see Section 3.3.2). - - When the amount of history information maintained in the server is - not enough for the clients to perform infrequent refreshOnly Sync - Operations, it is likely that the server has incomplete history - information (e.g., due to truncation) by the time those clients - connect again. - - The server SHOULD NOT resort to full reload when the history - information is not enough to generate delete entry messages. The - server SHOULD generate either present entry messages only or present - entry messages followed by delete entry messages to bring the client - copy to the current state. In the latter case, the present entry - messages bring the client copy to a state covered by the history - information maintained in the server. - - The server SHOULD maintain enough (current or historical) state - information (such as a context-wide last modify time stamp) to - determine if no changes were made in the context since the content - - - -Zeilenga & Choi Experimental [Page 20] - -RFC 4533 LDAP Content Synchronization Operation June 2006 - - - refresh was provided and, when no changes were made, generate zero - delete entry messages instead of present messages. - - The server SHOULD NOT use the history information when its use does - not reduce the synchronization traffic or when its use can expose - sensitive information not allowed to be received by the client. - - The server implementor should also consider chattiness issues that - span multiple Sync Operations of a session. As noted in Section 3.8, - the server may return e-syncRefreshRequired if it determines that a - reload would be more efficient than continuing under the current - operation. If reloadHint in the Sync Request is TRUE, the server may - initiate a reload without directing the client to request a reload. - - The server SHOULD transfer a new cookie frequently to avoid having to - transfer information already provided to the client. Even where DIT - changes do not cause content synchronization changes to be - transferred, it may be advantageous to provide a new cookie using a - Sync Info Message. However, the server SHOULD avoid overloading the - client or network with Sync Info Messages. - - During persist mode, the server SHOULD coalesce multiple outstanding - messages updating the same entry. The server MAY delay generation of - an entry update in anticipation of subsequent changes to that entry - that could be coalesced. The length of the delay should be long - enough to allow coalescing of update requests issued back to back but - short enough that the transient inconsistency induced by the delay is - corrected in a timely manner. - - The server SHOULD use the syncIdSet Sync Info Message when there are - multiple delete or present messages to reduce the amount of - synchronization traffic. - - Also note that there may be many clients interested in a particular - directory change, and that servers attempting to service all of these - at once may cause congestion on the network. The congestion issues - are magnified when the change requires a large transfer to each - interested client. Implementors and deployers of servers should take - steps to prevent and manage network congestion. - -3.10. Operation Multiplexing - - The LDAP protocol model [RFC4511] allows operations to be multiplexed - over a single LDAP session. Clients SHOULD NOT maintain multiple - LDAP sessions with the same server. Servers SHOULD ensure that - responses from concurrently processed operations are interleaved - fairly. - - - - -Zeilenga & Choi Experimental [Page 21] - -RFC 4533 LDAP Content Synchronization Operation June 2006 - - - Clients SHOULD combine Sync Operations whose result set is largely - overlapping. This avoids having to return multiple messages, once - for each overlapping session, for changes to entries in the overlap. - - Clients SHOULD NOT combine Sync Operations whose result sets are - largely non-overlapping. This ensures that an event requiring an - e-syncRefreshRequired response can be limited to as few result sets - as possible. - -4. Meta Information Considerations - -4.1. Entry DN - - As an entry's DN is constructed from its relative DN (RDN) and the - entry's parent's DN, it is often viewed as meta information. - - While renaming or moving to a new superior causes the entry's DN to - change, that change SHOULD NOT, by itself, cause synchronization - messages to be sent for that entry. However, if the renaming or the - moving could cause the entry to be added or deleted from the content, - appropriate synchronization messages should be generated to indicate - this to the client. - - When a server treats the entry's DN as meta information, the server - SHALL either - - - evaluate all MatchingRuleAssertions [RFC4511] to TRUE if - matching a value of an attribute of the entry, otherwise - Undefined, or - - - evaluate all MatchingRuleAssertion with dnAttributes of TRUE as - Undefined. - - The latter choice is offered for ease of server implementation. - -4.2. Operational Attributes - - Where values of an operational attribute are determined by values not - held as part of the entry it appears in, the operational attribute - SHOULD NOT support synchronization of that operational attribute. - - For example, in servers that implement the X.501 subschema model - [X.501], servers should not support synchronization of the - subschemaSubentry attribute as its value is determined by values held - and administrated in subschema subentries. - - - - - - -Zeilenga & Choi Experimental [Page 22] - -RFC 4533 LDAP Content Synchronization Operation June 2006 - - - As a counter example, servers that implement aliases [RFC4512][X.501] - can support synchronization of the aliasedObjectName attribute as its - values are held and administrated as part of the alias entries. - - Servers SHOULD support synchronization of the following operational - attributes: createTimestamp, modifyTimestamp, creatorsName, - modifiersName [RFC4512]. Servers MAY support synchronization of - other operational attributes. - -4.3. Collective Attributes - - A collective attribute is "a user attribute whose values are the same - for each member of an entry collection" [X.501]. Use of collective - attributes in LDAP is discussed in [RFC3671]. - - Modification of a collective attribute generally affects the content - of multiple entries, which are the members of the collection. It is - inefficient to include values of collective attributes visible in - entries of the collection, as a single modification of a collective - attribute requires transmission of multiple SearchResultEntry (one - for each entry of the collection that the modification affected). - - Servers SHOULD NOT synchronize collective attributes appearing in - entries of any collection. Servers MAY support synchronization of - collective attributes appearing in collective attribute subentries. - -4.4. Access and Other Administrative Controls - - Entries are commonly subject to access and other administrative - Controls. While portions of the policy information governing a - particular entry may be held in the entry, policy information is - often held elsewhere (in superior entries, in subentries, in the root - DSE, in configuration files, etc.). Because of this, changes to - policy information make it difficult to ensure eventual convergence - during incremental synchronization. - - Where it is impractical or infeasible to generate content changes - resulting from a change to policy information, servers may opt to - return e-syncRefreshRequired or to treat the Sync Operation as an - initial content request (e.g., ignore the cookie or the - synchronization state represented in the cookie). - -5. Interaction with Other Controls - - The Sync Operation may be used with: - - - ManageDsaIT Control [RFC3296] - - - - -Zeilenga & Choi Experimental [Page 23] - -RFC 4533 LDAP Content Synchronization Operation June 2006 - - - - Subentries Control [RFC3672] - - as described below. The Sync Operation may be used with other LDAP - extensions as detailed in other documents. - -5.1. ManageDsaIT Control - - The ManageDsaIT Control [RFC3296] indicates that the operation acts - upon the DSA Information Tree and causes referral and other special - entries to be treated as object entries with respect to the - operation. - -5.2. Subentries Control - - The Subentries Control is used with the search operation "to control - the visibility of entries and subentries which are within scope" - [RFC3672]. When used with the Sync Operation, the subentries control - and other factors (search scope, filter, etc.) are used to determine - whether an entry or subentry appears in the content. - -6. Shadowing Considerations - - As noted in [RFC4511], some servers may hold shadow copies of entries - that can be used to answer search and comparison queries. Such - servers may also support content synchronization requests. This - section discusses considerations for implementors and deployers for - the implementation and deployment of the Sync operation in shadowed - directories. - - While a client may know of multiple servers that are equally capable - of being used to obtain particular directory content from, a client - SHOULD NOT assume that each of these servers is equally capable of - continuing a content synchronization session. As stated in Section - 3.1, the client SHOULD issue each Sync request of a Sync session to - the same server. - - However, through domain naming or IP address redirection or other - techniques, multiple physical servers can be made to appear as one - logical server to a client. Only servers that are equally capable in - regards to their support for the Sync operation and that hold equally - complete copies of the entries should be made to appear as one - logical server. In particular, each physical server acting as one - logical server SHOULD be equally capable of continuing a content - synchronization based upon cookies provided by any of the other - physical servers without requiring a full reload. Because there is - no standard LDAP shadowing mechanism, the specification of how to - independently implement equally capable servers (as well as the - precise definition of "equally capable") is left to future documents. - - - -Zeilenga & Choi Experimental [Page 24] - -RFC 4533 LDAP Content Synchronization Operation June 2006 - - - Note that it may be difficult for the server to reliably determine - what content was provided to the client by another server, especially - in the shadowing environments that allow shadowing events to be - coalesced. For these servers, the use of the delete phase discussed - in Section 3.3.2 may not be applicable. - -7. Security Considerations - - In order to maintain a synchronized copy of the content, a client is - to delete information from its copy of the content as described - above. However, the client may maintain knowledge of information - disclosed to it by the server separate from its copy of the content - used for synchronization. Management of this knowledge is beyond the - scope of this document. Servers should be careful not to disclose - information for content the client is not authorized to have - knowledge of and/or about. - - While the information provided by a series of refreshOnly Sync - Operations is similar to that provided by a series of Search - Operations, persist stage may disclose additional information. A - client may be able to discern information about the particular - sequence of update operations that caused content change. - - Implementors should take precautions against malicious cookie - content, including malformed cookies or valid cookies used with - different security associations and/or protections in an attempt to - obtain unauthorized access to information. Servers may include a - digital signature in the cookie to detect tampering. - - The operation may be the target of direct denial-of-service attacks. - Implementors should provide safeguards to ensure the operation is not - abused. Servers may place access control or other restrictions upon - the use of this operation. - - Note that even small updates to the directory may cause a significant - amount of traffic to be generated to clients using this operation. A - user could abuse its update privileges to mount an indirect denial of - service to these clients, other clients, and/or portions of the - network. Servers should provide safeguards to ensure that update - operations are not abused. - - Implementors of this (or any) LDAP extension should be familiar with - general LDAP security considerations [RFC4510]. - - - - - - - - -Zeilenga & Choi Experimental [Page 25] - -RFC 4533 LDAP Content Synchronization Operation June 2006 - - -8. IANA Considerations - - Registration of the following values have been completed by the IANA - [RFC4520]. - -8.1. Object Identifier - - The OID arc 1.3.6.1.4.1.4203.1.9.1 was assigned [ASSIGN] by the - OpenLDAP Foundation, under its IANA-assigned private enterprise - allocation [PRIVATE], for use in this specification. - -8.2. LDAP Protocol Mechanism - - The IANA has registered the LDAP Protocol Mechanism described in this - document. - - Subject: Request for LDAP Protocol Mechanism Registration - Object Identifier: 1.3.6.1.4.1.4203.1.9.1.1 - Description: LDAP Content Synchronization Control - Person & email address to contact for further information: - Kurt Zeilenga <kurt@openldap.org> - Usage: Control - Specification: RFC 4533 - Author/Change Controller: Kurt D. Zeilenga, Jong Hyuk Choi - Comments: none - -8.3. LDAP Result Codes - - The IANA has registered the LDAP Result Code described in this - document. - - Subject: LDAP Result Code Registration - Person & email address to contact for further information: - Kurt Zeilenga <kurt@OpenLDAP.org> - Result Code Name: e-syncRefreshRequired (4096) - Specification: RFC 4533 - Author/Change Controller: Kurt D. Zeilenga, Jong Hyuk Choi - Comments: none - -9. Acknowledgements - - This document borrows significantly from the LDAP Client Update - Protocol [RFC3928], a product of the IETF LDUP working group. This - document also benefited from Persistent Search [PSEARCH], Triggered - Search [TSEARCH], and Directory Synchronization [DIRSYNC] works. - This document also borrows from "Lightweight Directory Access - Protocol (v3)" [RFC2251]. - - - - -Zeilenga & Choi Experimental [Page 26] - -RFC 4533 LDAP Content Synchronization Operation June 2006 - - -10. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC3296] Zeilenga, K., "Named Subordinate References in - Lightweight Directory Access Protocol (LDAP) - Directories", RFC 3296, July 2002. - - [RFC3671] Zeilenga, K., "Collective Attributes in the Lightweight - Directory Access Protocol (LDAP)", RFC 3671, December - 2003. - - [RFC3672] Zeilenga, K., "Subentries in the Lightweight Directory - Access Protocol (LDAP)", RFC 3672, December 2003. - - [RFC3909] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP) Cancel Operation", RFC 3909, October 2004. - - [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol - (LDAP): Technical Specification Road Map", RFC 4510, June - 2006. - - [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access - Protocol (LDAP): The Protocol", RFC 4511, June 2006. - - [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP): Directory Information Models", RFC 4512, June - 2006. - - [RFC4530] Zeilenga, K., "Lightweight Directory Access Protocol - (LDAP) entryUUID Operational Attribute", RFC 4530, June - 2006. - - [UUID] International Organization for Standardization (ISO), - "Information technology - Open Systems Interconnection - - Remote Procedure Call", ISO/IEC 11578:1996 - - [X.501] International Telecommunication Union - Telecommunication - Standardization Sector, "The Directory -- Models," - X.501(1993) (also ISO/IEC 9594-2:1994). - - [X.680] International Telecommunication Union - Telecommunication - Standardization Sector, "Abstract Syntax Notation One - (ASN.1) - Specification of Basic Notation", X.680(1997) - (also ISO/IEC 8824-1:1998). - - - - - -Zeilenga & Choi Experimental [Page 27] - -RFC 4533 LDAP Content Synchronization Operation June 2006 - - - [X.690] International Telecommunication Union - Telecommunication - Standardization Sector, "Specification of ASN.1 encoding - rules: Basic Encoding Rules (BER), Canonical Encoding - Rules (CER), and Distinguished Encoding Rules (DER)", - X.690(1997) (also ISO/IEC 8825-1:1998). - -11. Informative References - - [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory - Access Protocol (v3)", RFC 2251, December 1997. - - [RFC3928] Megginson, R., Ed., Smith, M., Natkovich, O., and J. - Parham, "Lightweight Directory Access Protocol (LDAP) - Client Update Protocol (LCUP)", RFC 3928, October 2004. - - [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) - Considerations for the Lightweight Directory Access - Protocol (LDAP)", BCP 64, RFC 4520, June 2006. - - [PRIVATE] IANA, "Private Enterprise Numbers", - http://www.iana.org/assignments/enterprise-numbers. - - [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", - http://www.openldap.org/foundation/oid-delegate.txt. - - [X.500] International Telecommunication Union - Telecommunication - Standardization Sector, "The Directory -- Overview of - concepts, models and services," X.500(1993) (also ISO/IEC - 9594-1:1994). - - [X.525] International Telecommunication Union - Telecommunication - Standardization Sector, "The Directory: Replication", - X.525(1993). - - [DIRSYNC] Armijo, M., "Microsoft LDAP Control for Directory - Synchronization", Work in Progress. - - [PSEARCH] Smith, M., et al., "Persistent Search: A Simple LDAP - Change Notification Mechanism", Work in Progress. - - [TSEARCH] Wahl, M., "LDAPv3 Triggered Search Control", Work in - Progress. - - - - - - - - - -Zeilenga & Choi Experimental [Page 28] - -RFC 4533 LDAP Content Synchronization Operation June 2006 - - -Appendix A. CSN-based Implementation Considerations - - This appendix is provided for informational purposes only; it is not - a normative part of the LDAP Content Synchronization Operation's - technical specification. - - This appendix discusses LDAP Content Synchronization Operation server - implementation considerations associated with Change Sequence Number - based approaches. - - Change Sequence Number based approaches are targeted for use in - servers that do not maintain history information (e.g., change logs, - state snapshots) about changes made to the Directory and hence, must - rely on current directory state and minimal synchronization state - information embedded in Sync Cookie. Servers that maintain history - information should consider other approaches that exploit the history - information. - - A Change Sequence Number is effectively a time stamp that has - sufficient granularity to ensure that the precedence relationship in - time of two updates to the same object can be determined. Change - Sequence Numbers are not to be confused with Commit Sequence Numbers - or Commit Log Record Numbers. A Commit Sequence Number allows one to - determine how two commits (to the same object or different objects) - relate to each other in time. A Change Sequence Number associated - with different entries may be committed out of order. In the - remainder of this Appendix, the term CSN refers to a Change Sequence - Number. - - In these approaches, the server not only maintains a CSN for each - directory entry (the entry CSN) but also maintains a value that we - will call the context CSN. The context CSN is the greatest committed - entry CSN that is not greater than any outstanding (uncommitted) - entry CSNs for all entries in a directory context. The values of - context CSN are used in syncCookie values as synchronization state - indicators. - - As search operations are not isolated from individual directory - update operations and individual update operations cannot be assumed - to be serialized, one cannot assume that the returned content - incorporates each relevant change whose change sequence number is - less than or equal to the greatest entry CSN in the content. The - content incorporates all the relevant changes whose change sequence - numbers are less than or equal to context CSN before search - processing. The content may also incorporate any subset of the - changes whose change sequence number is greater than context CSN - before search processing but less than or equal to the context CSN - after search processing. The content does not incorporate any of the - - - -Zeilenga & Choi Experimental [Page 29] - -RFC 4533 LDAP Content Synchronization Operation June 2006 - - - changes whose CSN is greater than the context CSN after search - processing. - - A simple server implementation could use the value of the context CSN - before search processing to indicate state. Such an implementation - would embed this value into each SyncCookie returned. We'll call - this the cookie CSN. When a refresh was requested, the server would - simply generate "update" messages for all entries in the content - whose CSN is greater than the supplied cookie CSN and generate - "present" messages for all other entries in the content. However, if - the current context CSN is the same as the cookie CSN, the server - should instead generate zero "updates" and zero "delete" messages and - indicate a refreshDeletes of TRUE, as the directory has not changed. - - The implementation should also consider the impact of changes to meta - information, such as access controls, that affect content - determination. One approach is for the server to maintain a - context-wide meta information CSN or meta CSN. This meta CSN would - be updated whenever meta information affecting content determination - was changed. If the value of the meta CSN is greater than the cookie - CSN, the server should ignore the cookie and treat the request as an - initial request for content. - - Additionally, servers may want to consider maintaining some per- - session history information to reduce the number of messages needed - to be transferred during incremental refreshes. Specifically, a - server could record information about entries as they leave the scope - of a disconnected sync session and later use this information to - generate delete messages instead of present messages. - - When the history information is truncated, the CSN of the latest - truncated history information entry may be recorded as the truncated - CSN of the history information. The truncated CSN may be used to - determine whether a client copy can be covered by the history - information by comparing it to the synchronization state contained in - the cookie supplied by the client. - - When there is a large number of sessions, it may make sense to - maintain such history only for the selected clients. Also, servers - taking this approach need to consider resource consumption issues to - ensure reasonable server operation and to protect against abuse. It - may be appropriate to restrict this mode of operation by policy. - - - - - - - - - -Zeilenga & Choi Experimental [Page 30] - -RFC 4533 LDAP Content Synchronization Operation June 2006 - - -Authors' Addresses - - Kurt D. Zeilenga - OpenLDAP Foundation - - EMail: Kurt@OpenLDAP.org - - - Jong Hyuk Choi - IBM Corporation - - EMail: jongchoi@us.ibm.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Zeilenga & Choi Experimental [Page 31] - -RFC 4533 LDAP Content Synchronization Operation June 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78 and at www.rfc-editor.org/copyright.html, and - except as set forth therein, the authors retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Zeilenga & Choi Experimental [Page 32] - diff --git a/source4/libcli/resolve/dns_ex.c b/source4/libcli/resolve/dns_ex.c index 1b5037273a..79ed78340c 100644 --- a/source4/libcli/resolve/dns_ex.c +++ b/source4/libcli/resolve/dns_ex.c @@ -283,14 +283,19 @@ static void run_child_getaddrinfo(struct dns_ex_state *state, int fd) hints.ai_flags = AI_ADDRCONFIG | AI_NUMERICSERV; ret = getaddrinfo(state->name.name, "0", &hints, &res_list); + /* try to fallback in case of error */ + if (state->do_fallback) { + switch (ret) { #ifdef EAI_NODATA - if (ret == EAI_NODATA && state->do_fallback) { -#else - if (ret == EAI_NONAME && state->do_fallback) { + case EAI_NODATA: #endif - /* getaddrinfo() doesn't handle CNAME records */ - run_child_dns_lookup(state, fd); - return; + case EAI_NONAME: + /* getaddrinfo() doesn't handle CNAME records */ + run_child_dns_lookup(state, fd); + return; + default: + break; + } } if (ret != 0) { goto done; diff --git a/source4/torture/rpc/samr.c b/source4/torture/rpc/samr.c index 0f2ca03b01..36e3207399 100644 --- a/source4/torture/rpc/samr.c +++ b/source4/torture/rpc/samr.c @@ -2593,6 +2593,56 @@ static bool test_AddMultipleMembersToAlias(struct dcerpc_pipe *p, struct torture return true; } +static bool test_GetAliasMembership(struct dcerpc_pipe *p, + struct torture_context *tctx, + struct policy_handle *domain_handle) +{ + struct samr_GetAliasMembership r; + struct lsa_SidArray sids; + struct samr_Ids rids; + NTSTATUS status; + + torture_comment(tctx, "Testing GetAliasMembership\n"); + + if (torture_setting_bool(tctx, "samba4", false)) { + torture_skip(tctx, "skipping GetAliasMembership against s4"); + } + + r.in.domain_handle = domain_handle; + r.in.sids = &sids; + r.out.rids = &rids; + + sids.num_sids = 0; + sids.sids = talloc_zero_array(tctx, struct lsa_SidPtr, sids.num_sids); + + status = dcerpc_samr_GetAliasMembership(p, tctx, &r); + torture_assert_ntstatus_ok(tctx, status, + "samr_GetAliasMembership failed"); + + torture_assert_int_equal(tctx, sids.num_sids, rids.count, + "protocol misbehaviour"); + + sids.num_sids = 1; + sids.sids = talloc_zero_array(tctx, struct lsa_SidPtr, sids.num_sids); + sids.sids[0].sid = dom_sid_parse_talloc(tctx, "S-1-5-32-1-2-3-1"); + + status = dcerpc_samr_GetAliasMembership(p, tctx, &r); + torture_assert_ntstatus_ok(tctx, status, + "samr_GetAliasMembership failed"); + +#if 0 + /* only true for w2k8 it seems + * win7, xp, w2k3 will return a 0 length array pointer */ + + torture_assert(tctx, (rids.ids && !rids.count), + "samr_GetAliasMembership protocol misbehaviour"); +#endif + torture_assert(tctx, (!rids.ids && rids.count), + "samr_GetAliasMembership protocol misbehaviour"); + + return true; +} + static bool test_TestPrivateFunctionsUser(struct dcerpc_pipe *p, struct torture_context *tctx, struct policy_handle *user_handle) { @@ -6504,6 +6554,7 @@ static bool test_OpenDomain(struct dcerpc_pipe *p, struct torture_context *tctx, ret &= test_RemoveMemberFromForeignDomain(p, tctx, &domain_handle); ret &= test_CreateAlias(p, tctx, &domain_handle, TEST_ALIASNAME, &alias_handle, sid, true); ret &= test_CreateDomainGroup(p, tctx, &domain_handle, TEST_GROUPNAME, &group_handle, sid, true); + ret &= test_GetAliasMembership(p, tctx, &domain_handle); ret &= test_QueryDomainInfo(p, tctx, &domain_handle); ret &= test_QueryDomainInfo2(p, tctx, &domain_handle); ret &= test_EnumDomainUsers_all(p, tctx, &domain_handle); diff --git a/source4/torture/rpc/spoolss.c b/source4/torture/rpc/spoolss.c index 772ca09f13..489174bde6 100644 --- a/source4/torture/rpc/spoolss.c +++ b/source4/torture/rpc/spoolss.c @@ -5,7 +5,7 @@ Copyright (C) Tim Potter 2003 Copyright (C) Stefan Metzmacher 2005 Copyright (C) Jelmer Vernooij 2007 - Copyright (C) Guenther Deschner 2009 + Copyright (C) Guenther Deschner 2009-2010 This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by @@ -860,42 +860,101 @@ static bool test_EnumPrinters(struct torture_context *tctx, return true; } +static bool test_GetPrinterDriver2(struct torture_context *tctx, + struct dcerpc_pipe *p, + struct policy_handle *handle, + const char *driver_name); + +static bool test_GetPrinter_level(struct torture_context *tctx, + struct dcerpc_pipe *p, + struct policy_handle *handle, + uint32_t level, + union spoolss_PrinterInfo *info) +{ + struct spoolss_GetPrinter r; + uint32_t needed; + + r.in.handle = handle; + r.in.level = level; + r.in.buffer = NULL; + r.in.offered = 0; + r.out.needed = &needed; + + torture_comment(tctx, "Testing GetPrinter level %u\n", r.in.level); + + torture_assert_ntstatus_ok(tctx, dcerpc_spoolss_GetPrinter(p, tctx, &r), + "GetPrinter failed"); + + if (W_ERROR_EQUAL(r.out.result, WERR_INSUFFICIENT_BUFFER)) { + DATA_BLOB blob = data_blob_talloc(tctx, NULL, needed); + data_blob_clear(&blob); + r.in.buffer = &blob; + r.in.offered = needed; + + torture_assert_ntstatus_ok(tctx, dcerpc_spoolss_GetPrinter(p, tctx, &r), + "GetPrinter failed"); + } + + torture_assert_werr_ok(tctx, r.out.result, "GetPrinter failed"); + + CHECK_NEEDED_SIZE_LEVEL(spoolss_PrinterInfo, r.out.info, r.in.level, lp_iconv_convenience(tctx->lp_ctx), needed, 4); + + if (info && r.out.info) { + *info = *r.out.info; + } + + return true; +} + + static bool test_GetPrinter(struct torture_context *tctx, struct dcerpc_pipe *p, - struct policy_handle *handle) + struct policy_handle *handle) { - NTSTATUS status; - struct spoolss_GetPrinter r; - uint16_t levels[] = {0, 1, 2, 3, 4, 5, 6, 7, 8}; + uint32_t levels[] = {0, 1, 2, 3, 4, 5, 6, 7, 8}; int i; - uint32_t needed; for (i=0;i<ARRAY_SIZE(levels);i++) { - r.in.handle = handle; - r.in.level = levels[i]; - r.in.buffer = NULL; - r.in.offered = 0; - r.out.needed = &needed; - torture_comment(tctx, "Testing GetPrinter level %u\n", r.in.level); + union spoolss_PrinterInfo info; - status = dcerpc_spoolss_GetPrinter(p, tctx, &r); - torture_assert_ntstatus_ok(tctx, status, "GetPrinter failed"); + ZERO_STRUCT(info); - if (W_ERROR_EQUAL(r.out.result, WERR_INSUFFICIENT_BUFFER)) { - DATA_BLOB blob = data_blob_talloc(tctx, NULL, needed); - data_blob_clear(&blob); - r.in.buffer = &blob; - r.in.offered = needed; - status = dcerpc_spoolss_GetPrinter(p, tctx, &r); + torture_assert(tctx, test_GetPrinter_level(tctx, p, handle, levels[i], &info), + "failed to call GetPrinter"); + + if ((levels[i] == 2) && info.info2.drivername && strlen(info.info2.drivername)) { + torture_assert(tctx, + test_GetPrinterDriver2(tctx, p, handle, info.info2.drivername), + "failed to call test_GetPrinterDriver2"); } + } + + return true; +} - torture_assert_ntstatus_ok(tctx, status, "GetPrinter failed"); +static bool test_SetPrinter(struct torture_context *tctx, + struct dcerpc_pipe *p, + struct policy_handle *handle, + struct spoolss_SetPrinterInfoCtr *info_ctr, + struct spoolss_DevmodeContainer *devmode_ctr, + struct sec_desc_buf *secdesc_ctr, + enum spoolss_PrinterControl command) +{ + struct spoolss_SetPrinter r; - torture_assert_werr_ok(tctx, r.out.result, "GetPrinter failed"); + r.in.handle = handle; + r.in.info_ctr = info_ctr; + r.in.devmode_ctr = devmode_ctr; + r.in.secdesc_ctr = secdesc_ctr; + r.in.command = command; - CHECK_NEEDED_SIZE_LEVEL(spoolss_PrinterInfo, r.out.info, r.in.level, lp_iconv_convenience(tctx->lp_ctx), needed, 4); - } + torture_comment(tctx, "Testing SetPrinter Level %d\n", r.in.info_ctr->level); + + torture_assert_ntstatus_ok(tctx, dcerpc_spoolss_SetPrinter(p, tctx, &r), + "failed to call SetPrinter"); + torture_assert_werr_ok(tctx, r.out.result, + "failed to call SetPrinter"); return true; } @@ -942,8 +1001,8 @@ static bool test_SetPrinter_errors(struct torture_context *tctx, struct spoolss_SetPrinterInfo5 info5; struct spoolss_SetPrinterInfo6 info6; struct spoolss_SetPrinterInfo7 info7; - struct spoolss_DeviceModeInfo info8; - struct spoolss_DeviceModeInfo info9; + struct spoolss_SetPrinterInfo8 info8; + struct spoolss_SetPrinterInfo9 info9; info_ctr.level = levels[i]; @@ -1064,8 +1123,8 @@ static bool test_SetPrinter_errors(struct torture_context *tctx, static void clear_info2(struct spoolss_SetPrinterInfoCtr *r) { if ((r->level == 2) && (r->info.info2)) { - r->info.info2->secdesc = NULL; - r->info.info2->devmode = NULL; + r->info.info2->secdesc_ptr = 0; + r->info.info2->devmode_ptr = 0; } } @@ -2607,6 +2666,181 @@ static bool test_SetPrinterDataEx(struct torture_context *tctx, return true; } +static bool test_GetChangeID_PrinterData(struct torture_context *tctx, + struct dcerpc_pipe *p, + struct policy_handle *handle, + uint32_t *change_id) +{ + enum winreg_Type type; + union spoolss_PrinterData data; + + torture_assert(tctx, + test_GetPrinterData(tctx, p, handle, "ChangeID", &type, &data), + "failed to call GetPrinterData"); + + torture_assert(tctx, type == REG_DWORD, "unexpected type"); + + *change_id = data.value; + + return true; +} + +static bool test_GetChangeID_PrinterDataEx(struct torture_context *tctx, + struct dcerpc_pipe *p, + struct policy_handle *handle, + uint32_t *change_id) +{ + enum winreg_Type type; + union spoolss_PrinterData data; + + torture_assert(tctx, + test_GetPrinterDataEx(tctx, p, handle, "PrinterDriverData", "ChangeID", &type, &data), + "failed to call GetPrinterData"); + + torture_assert(tctx, type == REG_DWORD, "unexpected type"); + + *change_id = data.value; + + return true; +} + +static bool test_GetChangeID_PrinterInfo(struct torture_context *tctx, + struct dcerpc_pipe *p, + struct policy_handle *handle, + uint32_t *change_id) +{ + union spoolss_PrinterInfo info; + + torture_assert(tctx, test_GetPrinter_level(tctx, p, handle, 0, &info), + "failed to query Printer level 0"); + + *change_id = info.info0.change_id; + + return true; +} + +static bool test_ChangeID(struct torture_context *tctx, + struct dcerpc_pipe *p, + struct policy_handle *handle) +{ + uint32_t change_id, change_id_ex, change_id_info; + uint32_t change_id2, change_id_ex2, change_id_info2; + union spoolss_PrinterInfo info; + const char *comment; + + + torture_comment(tctx, "Testing ChangeID: id change test #1\n"); + + torture_assert(tctx, test_GetChangeID_PrinterData(tctx, p, handle, &change_id), + "failed to query for ChangeID"); + torture_assert(tctx, test_GetChangeID_PrinterDataEx(tctx, p, handle, &change_id_ex), + "failed to query for ChangeID"); + torture_assert(tctx, test_GetChangeID_PrinterInfo(tctx, p, handle, &change_id_info), + "failed to query for ChangeID"); + + torture_assert_int_equal(tctx, change_id, change_id_ex, + "change_ids should all be equal"); + torture_assert_int_equal(tctx, change_id_ex, change_id_info, + "change_ids should all be equal"); + + + torture_comment(tctx, "Testing ChangeID: id change test #2\n"); + + torture_assert(tctx, test_GetChangeID_PrinterData(tctx, p, handle, &change_id), + "failed to query for ChangeID"); + torture_assert(tctx, test_GetPrinter_level(tctx, p, handle, 2, &info), + "failed to query Printer level 2"); + torture_assert(tctx, test_GetChangeID_PrinterDataEx(tctx, p, handle, &change_id_ex), + "failed to query for ChangeID"); + torture_assert(tctx, test_GetChangeID_PrinterInfo(tctx, p, handle, &change_id_info), + "failed to query for ChangeID"); + torture_assert_int_equal(tctx, change_id, change_id_ex, + "change_id should not have changed"); + torture_assert_int_equal(tctx, change_id_ex, change_id_info, + "change_id should not have changed"); + + + torture_comment(tctx, "Testing ChangeID: id change test #3\n"); + + torture_assert(tctx, test_GetChangeID_PrinterData(tctx, p, handle, &change_id), + "failed to query for ChangeID"); + torture_assert(tctx, test_GetChangeID_PrinterDataEx(tctx, p, handle, &change_id_ex), + "failed to query for ChangeID"); + torture_assert(tctx, test_GetChangeID_PrinterInfo(tctx, p, handle, &change_id_info), + "failed to query for ChangeID"); + torture_assert(tctx, test_GetPrinter_level(tctx, p, handle, 2, &info), + "failed to query Printer level 2"); + comment = talloc_strdup(tctx, info.info2.comment); + + { + struct spoolss_SetPrinterInfoCtr info_ctr; + struct spoolss_DevmodeContainer devmode_ctr; + struct sec_desc_buf secdesc_ctr; + struct spoolss_SetPrinterInfo2 info2; + + ZERO_STRUCT(info_ctr); + ZERO_STRUCT(devmode_ctr); + ZERO_STRUCT(secdesc_ctr); + + info2.servername = info.info2.servername; + info2.printername = info.info2.printername; + info2.sharename = info.info2.sharename; + info2.portname = info.info2.portname; + info2.drivername = info.info2.drivername; + info2.comment = "torture_comment"; + info2.location = info.info2.location; + info2.devmode_ptr = 0; + info2.sepfile = info.info2.sepfile; + info2.printprocessor = info.info2.printprocessor; + info2.datatype = info.info2.datatype; + info2.parameters = info.info2.parameters; + info2.secdesc_ptr = 0; + info2.attributes = info.info2.attributes; + info2.priority = info.info2.priority; + info2.defaultpriority = info.info2.defaultpriority; + info2.starttime = info.info2.starttime; + info2.untiltime = info.info2.untiltime; + info2.status = info.info2.status; + info2.cjobs = info.info2.cjobs; + info2.averageppm = info.info2.averageppm; + + info_ctr.level = 2; + info_ctr.info.info2 = &info2; + + torture_assert(tctx, test_SetPrinter(tctx, p, handle, &info_ctr, &devmode_ctr, &secdesc_ctr, 0), + "failed to call SetPrinter"); + + info2.comment = comment; + + torture_assert(tctx, test_SetPrinter(tctx, p, handle, &info_ctr, &devmode_ctr, &secdesc_ctr, 0), + "failed to call SetPrinter"); + + } + + torture_assert(tctx, test_GetChangeID_PrinterData(tctx, p, handle, &change_id2), + "failed to query for ChangeID"); + torture_assert(tctx, test_GetChangeID_PrinterDataEx(tctx, p, handle, &change_id_ex2), + "failed to query for ChangeID"); + torture_assert(tctx, test_GetChangeID_PrinterInfo(tctx, p, handle, &change_id_info2), + "failed to query for ChangeID"); + + torture_assert_int_equal(tctx, change_id2, change_id_ex2, + "change_ids should all be equal"); + torture_assert_int_equal(tctx, change_id_ex2, change_id_info2, + "change_ids should all be equal"); + + torture_assert(tctx, (change_id < change_id2), + talloc_asprintf(tctx, "change_id %d needs to be larger than change_id %d", + change_id2, change_id)); + torture_assert(tctx, (change_id_ex < change_id_ex2), + talloc_asprintf(tctx, "change_id %d needs to be larger than change_id %d", + change_id_ex2, change_id_ex)); + torture_assert(tctx, (change_id_info < change_id_info2), + talloc_asprintf(tctx, "change_id %d needs to be larger than change_id %d", + change_id_info2, change_id_info)); + + return true; +} static bool test_SecondaryClosePrinter(struct torture_context *tctx, struct dcerpc_pipe *p, @@ -2837,6 +3071,10 @@ static bool test_OpenPrinterEx(struct torture_context *tctx, ret = false; } + if (!test_ChangeID(tctx, p, &handle)) { + ret = false; + } + if (!torture_setting_bool(tctx, "samba3", false)) { if (!test_SecondaryClosePrinter(tctx, p, &handle)) { ret = false; @@ -2965,38 +3203,55 @@ static bool test_GetPrinterDriver2(struct torture_context *tctx, const char *driver_name) { struct spoolss_GetPrinterDriver2 r; + uint16_t levels[] = {1, 2, 3, 4, 5, 6, 8, 101 }; uint32_t needed; uint32_t server_major_version; uint32_t server_minor_version; + int i; r.in.handle = handle; - r.in.architecture = "W32X86"; - r.in.level = 1; - r.in.buffer = NULL; - r.in.offered = 0; - r.in.client_major_version = 0; + r.in.architecture = SPOOLSS_ARCHITECTURE_NT_X86; + r.in.client_major_version = 3; r.in.client_minor_version = 0; r.out.needed = &needed; r.out.server_major_version = &server_major_version; r.out.server_minor_version = &server_minor_version; - torture_comment(tctx, "Testing GetPrinterDriver2 level %d\n", r.in.level); + for (i=0;i<ARRAY_SIZE(levels);i++) { + + r.in.buffer = NULL; + r.in.offered = 0; + r.in.level = levels[i]; + + torture_comment(tctx, "Testing GetPrinterDriver2(%s) level %d\n", + driver_name, r.in.level); - torture_assert_ntstatus_ok(tctx, dcerpc_spoolss_GetPrinterDriver2(p, tctx, &r), - "failed to call GetPrinterDriver2"); - if (W_ERROR_EQUAL(r.out.result, WERR_INSUFFICIENT_BUFFER)) { - DATA_BLOB blob = data_blob_talloc(tctx, NULL, needed); - data_blob_clear(&blob); - r.in.buffer = &blob; - r.in.offered = needed; torture_assert_ntstatus_ok(tctx, dcerpc_spoolss_GetPrinterDriver2(p, tctx, &r), "failed to call GetPrinterDriver2"); - } + if (W_ERROR_EQUAL(r.out.result, WERR_INSUFFICIENT_BUFFER)) { + DATA_BLOB blob = data_blob_talloc(tctx, NULL, needed); + data_blob_clear(&blob); + r.in.buffer = &blob; + r.in.offered = needed; + torture_assert_ntstatus_ok(tctx, dcerpc_spoolss_GetPrinterDriver2(p, tctx, &r), + "failed to call GetPrinterDriver2"); + } - torture_assert_werr_ok(tctx, r.out.result, - "failed to call GetPrinterDriver2"); + if (W_ERROR_EQUAL(r.out.result, WERR_INVALID_LEVEL)) { + switch (r.in.level) { + case 101: + case 8: + continue; + default: + break; + } + } - CHECK_NEEDED_SIZE_LEVEL(spoolss_DriverInfo, r.out.info, r.in.level, lp_iconv_convenience(tctx->lp_ctx), needed, 4); + torture_assert_werr_ok(tctx, r.out.result, + "failed to call GetPrinterDriver2"); + + CHECK_NEEDED_SIZE_LEVEL(spoolss_DriverInfo, r.out.info, r.in.level, lp_iconv_convenience(tctx->lp_ctx), needed, 4); + } return true; } |