WIXLIB

Starting gskkyman . . . . . . . . . . . . . . . . . . . . .Creating, Opening and Deleting a Key Database File . . . . . . . .Changing a Key Database Password . . . . . . . . . . . . . .Storing an Encrypted Key Database Password . . . . . . . . . . .Creating a Self-Signed Server or Client Certificate . . . . . . . . .Creating a Certificate Request . . . . . . . . . . . . . . . . .Creating a certificate to be used with a fixed Diffie-Hellman key exchangeSending the Certificate Request . . . . . . . . . . . . . . . .Receiving the Signed Certificate or Renewal Certificate . . . . . . .Managing Keys and Certificates . . . . . . . . . . . . . . . .Importing a Certificate from a File as a Trusted CA Certificate . . . . .Importing a Certificate from a File with its Private Key . . . . . . . .Using gskkyman to be Your Own Certificate Authority (CA) . . . . . .GSKKYMAN Command Line Mode Syntax . . . . . . . . . . . . .GSKKYMAN (gskkyman utility) Command . . . . . . . . . . . .GSKKYMAN Command Line Mode Examples . . . . . . . . . . hapter 16. Obtaining LDAP SSL Diagnostic Information . . . . . . . 239GSKTRACE (gsktrace utility) Command . . . . . . . . . . . . . . . 239Chapter 17. Performance tuning . . . . . . . .Overview . . . . . . . . . . . . . . . . .General LDAP server performance considerations . .Threads . . . . . . . . . . . . . . . . .Debug settings . . . . . . . . . . . . . .Storage in the LDAP virtual machine . . . . . .LDAP server cache tuning . . . . . . . . . .LDBM performance considerations . . . . . . . .Storage in the LDAP virtual machine for LDBM data .LDAP server initialization time with LDBM . . . .Database commit processing . . . . . . . . .DASD space for LDBM data . . . . . . . . .Monitoring performance with cn monitor search . . .Monitor search examples. . . . . . . . . . .Large access groups considerations . . . . . . .LE heap pools considerations . . . . . . . . .GDBM (Changelog) performance considerations . . .SDBM performance considerations . . . . . . . 49250Appendix A. Initial LDAP server schema . . . . . . . . . . . . . . 251Appendix B. Supported server controlsauthenticateOnly . . . . . . . . . .IBMModifyDNRealignDNAttributesControl .IBMModifyDNTimelimitControl . . . . .IBMSchemaReplaceByValueControl . . .manageDsalT . . . . . . . . . . .PersistentSearch . . . . . . . . . .replicateOperationalAttributes . . . . .261261261262262263263265Appendix C. Abbreviations and Acronyms . . . . . . . . . . . . . 267Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . 271Programming Interface Information . . . . . . . . . . . . . . . . . 272Trademarks. . . . . . . . . . . . . . . . . . . . . . . . . . 273Contentsvii

Glossary. . . . . . . . . . . . . . . . . . . . . . . . . . 275Bibliography . . . . . . . . . . . . . . . .Where to Get z/VM Publications . . . . . . . . .z/VM Base Library . . . . . . . . . . . . . .Overview . . . . . . . . . . . . . . . .Installation, Migration, and Service . . . . . . .Planning and Administration. . . . . . . . . .Customization and Tuning . . . . . . . . . .Operation and Use . . . . . . . . . . . . .Application Programming . . . . . . . . . . .Diagnosis . . . . . . . . . . . . . . . .Publications for z/VM Optional Features . . . . . .Data Facility Storage Management Subsystem for VMDirectory Maintenance Facility for z/VM . . . . .Performance Toolkit for VM . . . . . . . . . .RACF Security Server for z/VM . . . . . . . .RSCS Networking for z/VM . . . . . . . . . .Other TCP/IP Related Publications . . . . . . . 95Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297viiiz/VM: TCP/IP LDAP Administration Guide

About This BookThe LDAP server supports Lightweight Directory Access Protocol (LDAP) and runsas a stand-alone daemon. It is based on a client/server model that provides clientaccess to an LDAP server. The LDAP server provides an easy way to maintaindirectory information in a central location for storage, updating, retrieval, andexchange.Who Should Read This BookThis document is intended to assist LDAP administrators. LDAP administratorsshould be experienced and have previous knowledge of directory services. It is alsointended for anyone that will be implementing the directory service.What You Should Know before Reading This BookYou should have a good understanding of the TCP/IP in general and how z/VMimplements the TCP/IP protocol suite. Also, you should understand the LightweightDirectory Access Protocol (LDAP).How to Use This BookThis topic describes important terminology and style conventions used in this book.How the Term “internet” Is Used in This BookIn this book, an internet is a logical collection of networks supported by routers,gateways, bridges, hosts, and various layers of protocols, which permit the networkto function as a large, virtual network.Note: The term “internet” is used as a generic term for a TCP/IP network, andshould not be confused with the Internet, which consists of large nationalbackbone networks (such as MILNET, NSFNet, and CREN) and a myriad ofregional and local campus networks worldwide.How to Read Syntax DiagramsThis section describes how to read the syntax diagrams in this book.Getting Started: To read a syntax diagram, follow the path of the line. Read fromleft to right and top to bottom.v The symbol indicates the beginning of a syntax diagram.v The symbol, at the end of a line, indicates that the syntax diagramcontinues on the next line.v The symbol, at the beginning of a line, indicates that a syntax diagramcontinues from the previous line.v The symbol indicates the end of a syntax diagram.Syntax items (for example, a keyword or variable) may be:v Directly on the line (required)v Above the line (default)v Below the line (optional). Copyright IBM Corp. 2007ix

Syntax Diagram DescriptionExampleAbbreviations:Uppercase letters denote the shortest acceptableabbreviation. If an item appears entirely in uppercaseletters, it cannot be abbreviated. KEYWOrd You can type the item in uppercase letters, lowercaseletters, or any combination.In this example, you can enter KEYWO, KEYWOR, orKEYWORD in any combination of uppercase andlowercase letters.Symbols:You must code these symbols exactly as they appear inthe syntax diagram.*Asterisk:Colon,Comma Equal ed lowercase items (like this) denote variables. KEYWOrd var name repeat In this example, var name represents a variable you mustspecify when you code the KEYWORD command.Repetition:An arrow returning to the left means that the item can berepeated.A character within the arrow means you must separaterepeated items with that character., repeat A footnote (1) by the arrow references a limit that tellshow many times the item can be repeated.(1) repeat Notes:1Specify repeat up to 5 times.Required Choices:When two or more items are in a stack and one of them ison the line, you must specify one item.In this example, you must choose A, B, or C.xz/VM: TCP/IP LDAP Administration Guide ABC

Syntax Diagram DescriptionExampleOptional Choice:When an item is below the line, the item is optional. In thisexample, you can choose A or nothing at all.When two or more items are in a stack below the line, allof them are optional. In this example, you can choose A,B, C, or nothing at all. A ABCDefaults:Defaults are above the line. The system uses the defaultunless you override it. You can override the default bycoding an option from the stack below the line.A BCIn this example, A is the default. You can override A bychoosing B or C.Repeatable Choices:A stack of items followed by an arrow returning to the leftmeans that you can select more than one item or, in some cases, repeat a single item.ABCIn this example, you can choose any combination of A, B,or C. Syntax Fragments:Some diagrams, because of their length, must fragmentthe syntax. The fragment name appears between verticalbars in the diagram. The expanded fragment appears inthe diagram after a heading with the same fragmentname.In this example, the fragment is named “A Fragment.” A Fragment A Fragment:ABCWhere to Find More InformationOther z/VM manuals contain information about LDAP:v For information about configuring the LDAP server, see z/VM: TCP/IP Planningand Customization.v LDAP client utilities are documented in z/VM: TCP/IP User’s Guide.v Information about LDAP messages is in z/VM: TCP/IP Messages and Codes.Appendix C, “Abbreviations and Acronyms,” on page 267, lists the abbreviationsand acronyms that are used throughout this book.The “Glossary” on page 275, defines terms used throughout this book that areassociated with TCP/IP communication in an internet environment.For more information about related publications, see the books listed in the“Bibliography” on page 293.About This Bookxi

Links to Other Online BooksIf you are viewing the Adobe Portable Document Format (PDF) version of thisbook, it may contain links to other books. A link to another book is based onthe name of the requested PDF file. The name of the PDF file for an IBM bookis unique and identifies both the book and the edition. The book links providedin this book are for the editions (PDF names) that were current when the PDFfile for this book was generated. However, newer editions of some books (withdifferent PDF names) may exist. A link from this book to another book worksonly when a PDF file with the requested name resides in the same directoryas this book.How to Send Your Comments to IBMIBM welcomes your comments. You can use any of the following methods:v Complete and mail the Readers’ Comments form (if one is provided at the backof this book) or send your comments to the following address:IBM CorporationMHVRCFS, Mail Station P1812455 South RoadPoughkeepsie, New York 12601-5400U.S.A.v Send your comments by FAX:– United States and Canada: 1-845-432-9405– Other Countries: 1 845 432 9405v Send your comments by electronic mail to one of the following addresses:– Internet: mhvrcfs@us.ibm.com– IBMLink (US customers only): IBMUSM10(MHVRCFS)Be sure to include the following in your comment or note:v Title and complete publication number of the bookv Page number, section title, or topic you are commenting onIf you would like a reply, be sure to also include your name, postal or e-mailaddress, telephone number, or FAX number.When you send information to IBM, you grant IBM a nonexclusive right to use ordistribute the information in any way it believes appropriate without incurring anyobligation to you.xiiz/VM: TCP/IP LDAP Administration Guide

Chapter 1. Data modelThe LDAP data model is closely aligned with the X.500 data model. In this model, adirectory service provides a hierarchically organized set of entries. Each of theseentries is represented by an object class. The object class of the entry determinesthe set of attributes which are required to be present in the entry as well as the setof attributes that can optionally appear in the entry. An attribute is represented byan attribute type and one or more attribute values. In addition to the attribute typeand values, each attribute has an associated syntax which describes the format ofthe attribute values. Examples of attribute syntaxes for LDAP directory includedirectory string and binary.To summarize, the directory is made up of entries. Each entry contains a set ofattributes. These attributes can be single or multi-valued (have one or more valuesassociated with them). The object class of an entry determines the set of attributesthat must exist and the set of attributes that may exist in the entry.Every entry in the directory has a distinguished name (DN). The DN is the namethat uniquely identifies an entry in the directory. A DN is made up of attribute valuepairs, separated by commas. For example:cn Ben Gray,ou editing,o New York Times,c UScn Lucille White,ou editing,o New York Times,c UScn Tom Brown,ou reporting,o New York Times,c USThe order of the component attribute value pairs is important. The DN contains onecomponent for each level of the directory hierarchy. LDAP directory DNs begin withthe most specific attribute (usually some sort of name), and continue withprogressively broader attributes, often ending with a country attribute.Relative distinguished namesEach component of a DN is referred to as a relative distinguished name (RDN). Itidentifies an entry distinctly from any other entries which have the same parent. Inthe examples above, the RDN cn Ben Gray separates the first entry from thesecond entry, (with RDN cn Lucille White). The attribute value pair or pairsmaking up the RDN for an entry must also be present as an attribute value pair orpairs in the entry. This is not true of the other components of the DN. When usingthe LDBM backend, LDBM adds the attribute value pairs in the RDN to the entry ifthey are not already present.RDNs can contain multiple attribute value pairs. So-called multivalued RDNs usetwo or more attribute value pairs from the directory entry to define the name of theentry relative to its parent. An example where this would be useful would be wherea directory hierarchy of users was being defined for a large university. Thishierarchy would be segmented by campus. A problem is encountered, however,when it is discovered that there is more than one John Smith at the downtowncampus. The RDN cannot simply be the name of the user. What can be done,however, is to add a unique value to the RDN, thus ensuring its uniqueness acrossthe campus. Typically universities hand out serial numbers to their students.Coupling the student number with the person’s name is one method of solving theproblem of having a unique RDN under a parent in the directory hierarchy. Theentry’s RDN might look something like:cn John Smith studentNumber 123456. Copyright IBM Corp. 20071

The plus sign ( ) is used to delimit separate attribute value pairs within an RDN.The entry’s DN might look like:cn John Smith studentNumber 123456, ou downtown, o Big University, c USAny attribute can be used to make up an RDN except:v attributes with binary syntax.Note: The userPassword attribute is binary, therefore, it cannot appear in anRDN.v attributes that are marked NO-USER-MODIFICATION in the schema, becausethese attributes cannot be added to an entry by a user.v the aclEntry, aclPropagate, entryOwner, and ownerPropagate attributes.Distinguished name syntaxThe Distinguished Name (DN) syntax supported by this server is based on IETFRFC 2253 LDAP (v3): UTF-8 String Representation of Distinguished Names. Asemicolon (;) character may be used to separate RDNs in a distinguished name,although the comma (,) character is the typical notation. A plus sign ( ) is used toseparate attribute value pairs in an RDN.White space (blank) characters may be present on either side of the comma orsemicolon. The white space characters are ignored, and the semicolon replacedwith a comma.In addition, space characters may be present between an attribute value pair and aplus sign ( ), between an attribute type and an equal sign ( ), and between anequal sign ( ) and an attribute value. These space characters are ignored whenparsing.A value may be surrounded by quotation marks, which are not part of the value.Inside the quoted value, the following characters can occur without any escaping:v A space or pound sign (#) character occurring at the beginning of the stringv A space character occurring at the end of the stringv One of the characters– apostrophe (’)– equal sign ( )– plus sign ( )– backslash (\)– less than sign ( )– greater than sign ( )– semicolon (;)Alternatively, a single character to be escaped may be prefixed by a backslash (\).This method may be used to escape any of the characters listed above, plus thequotation mark. Pound signs (#) and space characters that do not occur at thebeginning of a string can also be escaped, but this is not required.This notation is designed to be convenient for common forms of name. This sectiongives a few examples of distinguished names written using this

TCP/IP LDAP Administration Guide. About This Book The LDAP server supports Lightweight Directory Access Protocol (LDAP) and runs as a stand-alone daemon. It is based on a client/server model that provides client access to an LDAP server. The LDAP server provides an easy way to maintain di