DCE Security Registry and LDAP Integration Guide - IBM · PDF fileIBM® Distributed Computing Environment Version 3.2 for AIX® and Solaris DCE Security Registry and LDAP Integration

IBM® Distributed Computing Environment Version3.2 for AIX® and Solaris

DCE Security Registry and LDAPIntegration Guide

��

IBM® Distributed Computing Environment Version3.2 for AIX® and Solaris

DCE Security Registry and LDAPIntegration Guide

��

NoteBefore using this document, read the general information under “Appendix C. Notices” on page 105.

First Edition (July 2001)

This edition applies to Version 3.2 of IBM Distributed Computing Environment for AIX and Solaris and to allsubsequent releases and modifications until otherwise indicated in new editions or technical newsletters.

Order publications through your IBM representative or the IBM branch office serving your locality. Publications arenot stocked at the address below.

IBM welcomes your comments. Send your comments to the following address:International Business Machines CorporationDepartment VLXA11400 Burnet RoadAustin, Texas78758

When you send information to IBM, you grant IBM a nonexclusive right to use or distribute the information in anyway it believes appropriate without incurring any obligation to you.

This documentation and the software to which it relates are derived in part from materials supplied by the following:

Copyright © 1995, 1996 Open Software Foundation, Inc.

Copyright © 1990, 1991, 1992, 1993, 1994, 1995, 1996 Digital Equipment Corporation

Copyright © 1990, 1991, 1992, 1993, 1994, 1995, 1996 Hewlett-Packard Company

Copyright © 1989, 1990, 1991, 1992, 1993, 1994, 1995, 1996 Transarc Corporation

Copyright © 1990, 1991 Siemens Nixdorf Informationssysteme AG

Copyright © 1985, 1999 Massachusetts Institute of Technology

Copyright © 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University ofCalifornia

Copyright © 1995, 1996 Hitachi, Ltd.

Licensee agrees that it will comply with and will require its Distributors to comply with all then-applicable laws, rulesand regulations (i) relating to the export or re-export of technical data when exporting or re-exporting a LicensedProgram or Documentation, and (ii) required to limit a governmental agency’s rights in the Licensed Program,Documentation or associated technical data by affixing a Restricted Rights notice to the Licensed Program,Documentation and/or technical data equivalent to or substantially as follows: ″Use, duplication or disclosure by theU.S. Government is subject to restrictions as set forth in DFARS 52.227-7013(c)(1)(i)-(ii); FAR 52.227-19; and FAR52.227-14, Alternate III, as applicable or in the equivalent clause of any other applicable Federal governmentregulations.″

© Copyright International Business Machines Corporation 2001. All rights reserved.US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contractwith IBM Corp.

Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixAudience . . . . . . . . . . . . . . . . . . . . . . . . . . . ixApplicability . . . . . . . . . . . . . . . . . . . . . . . . . . ixDocument usage . . . . . . . . . . . . . . . . . . . . . . . . ixRelated Documents . . . . . . . . . . . . . . . . . . . . . . . ixTypographic and Keying Conventions . . . . . . . . . . . . . . . . . x

Chapter 1. Introduction to DCE Security Registry and LDAP Integration . . 1Benefits of LDAP integration . . . . . . . . . . . . . . . . . . . . 1DCE security service . . . . . . . . . . . . . . . . . . . . . . . 1Overview of legacy DCE security severs . . . . . . . . . . . . . . . . 2Physical security of the legacy database . . . . . . . . . . . . . . . . 3Overview of LDAP security servers . . . . . . . . . . . . . . . . . . 3Physical security of the LDAP registry . . . . . . . . . . . . . . . . . 4Data structure. . . . . . . . . . . . . . . . . . . . . . . . . . 5

Legacy security data structure. . . . . . . . . . . . . . . . . . . 5LDAP security data structure . . . . . . . . . . . . . . . . . . . 5

Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Chapter 2. Planning Considerations . . . . . . . . . . . . . . . . . 9DCE version . . . . . . . . . . . . . . . . . . . . . . . . . . 9Supported versions of LDAP . . . . . . . . . . . . . . . . . . . . 9Performance considerations . . . . . . . . . . . . . . . . . . . . 9Sharing objects and attributes . . . . . . . . . . . . . . . . . . . 10LDAP directory considerations . . . . . . . . . . . . . . . . . . . 10

DCE and Kerberos LDIF files . . . . . . . . . . . . . . . . . . 10Loading DCE schema definitions in the LDAP directory . . . . . . . . . 10Configuring LDAP indexed attributes . . . . . . . . . . . . . . . . 11Storing principals, groups, and orgs . . . . . . . . . . . . . . . . 11Sharing a common principal in a DCE cell . . . . . . . . . . . . . . 12Reserved names . . . . . . . . . . . . . . . . . . . . . . . 12Master key considerations . . . . . . . . . . . . . . . . . . . . 12

Data consistency . . . . . . . . . . . . . . . . . . . . . . . . 13Security configuration . . . . . . . . . . . . . . . . . . . . . . 13

Security overview . . . . . . . . . . . . . . . . . . . . . . . 13Configuring an LDAP bind protocol . . . . . . . . . . . . . . . . 14Configuring DCE server entries in the LDAP directory . . . . . . . . . 20Configuring a realm entry in the LDAP directory . . . . . . . . . . . . 21Configuring LDAP access control . . . . . . . . . . . . . . . . . 22Additional security considerations . . . . . . . . . . . . . . . . . 24

Chapter 3. Configuration and Migration . . . . . . . . . . . . . . . 25LDAP security servers . . . . . . . . . . . . . . . . . . . . . . 25

LDAP migration security server . . . . . . . . . . . . . . . . . . 25LDAP master security server . . . . . . . . . . . . . . . . . . . 26LDAP slave security server . . . . . . . . . . . . . . . . . . . 26

Security server migration . . . . . . . . . . . . . . . . . . . . . 26Allowed migration scenarios . . . . . . . . . . . . . . . . . . . 27The .ldap_data file . . . . . . . . . . . . . . . . . . . . . . 27Overview of migration . . . . . . . . . . . . . . . . . . . . . 28Migrating a legacy slave to a migration server . . . . . . . . . . . . 31Migrating a legacy slave to an LDAP security slave . . . . . . . . . . 32Migrating a legacy master to an LDAP security master . . . . . . . . . 34

© Copyright IBM Corp. 2001 iii

Forcing the migration server to become the LDAP security master . . . . . 35Raising the version of the security registry . . . . . . . . . . . . . . 36

Configuring LDAP security servers. . . . . . . . . . . . . . . . . . 37Configuring an LDAP security slave from a command line . . . . . . . . 37Configuring an LDAP security slave from smitty (AIX only) . . . . . . . . 37Unconfiguring LDAP security servers . . . . . . . . . . . . . . . . 38

Returning LDAP security servers to legacy security servers . . . . . . . . 40

Chapter 4. Administration . . . . . . . . . . . . . . . . . . . . 41LDAP initialization options . . . . . . . . . . . . . . . . . . . . . 41Referencing DNs for DCE policy information . . . . . . . . . . . . . . 41Resetting LDAP settings for the DCE security registry . . . . . . . . . . 41Configuring the DCE registry policy and properties. . . . . . . . . . . . 41Deleting objects and attributes . . . . . . . . . . . . . . . . . . . 42DCE LDAP error messages . . . . . . . . . . . . . . . . . . . . 42Troubleshooting procedures . . . . . . . . . . . . . . . . . . . . 43

Backup and recovery of the system after failure in the security server. . . . 44Recovering the LDAP security master by converting an LDAP security slave

to an LDAP security master . . . . . . . . . . . . . . . . . . 45Recovering LDAP security slaves . . . . . . . . . . . . . . . . . 46Converting an LDAP security master to an LDAP security slave . . . . . . 46Forcibly deleting an LDAP security slave . . . . . . . . . . . . . . 46Designating a new LDAP security master when the current LDAP security

master fails . . . . . . . . . . . . . . . . . . . . . . . . 47LDAP commands . . . . . . . . . . . . . . . . . . . . . . . . 48

config.dce. . . . . . . . . . . . . . . . . . . . . . . . . . 49dcecp registry ldapdelete . . . . . . . . . . . . . . . . . . . . 51dcecp registry migrate . . . . . . . . . . . . . . . . . . . . . 53dcecp registry modify . . . . . . . . . . . . . . . . . . . . . 56

Appendix A. Default DCE LDAP Tree . . . . . . . . . . . . . . . . 57DCE Objects. . . . . . . . . . . . . . . . . . . . . . . . . . 57

krbRealmName-v2=<cell_name> . . . . . . . . . . . . . . . . . 57cn=attrschema . . . . . . . . . . . . . . . . . . . . . . . . 57cn=group . . . . . . . . . . . . . . . . . . . . . . . . . . 57cn=mkey . . . . . . . . . . . . . . . . . . . . . . . . . . 58cn=organization . . . . . . . . . . . . . . . . . . . . . . . 58cn=principal . . . . . . . . . . . . . . . . . . . . . . . . . 58cn=replist . . . . . . . . . . . . . . . . . . . . . . . . . . 59cn=uniqueID . . . . . . . . . . . . . . . . . . . . . . . . . 59

Appendix B. DCE and Kerberos Schema Definitions . . . . . . . . . . 61DCE object classes . . . . . . . . . . . . . . . . . . . . . . . 61

DCEAcl . . . . . . . . . . . . . . . . . . . . . . . . . . 61DCEDir. . . . . . . . . . . . . . . . . . . . . . . . . . . 61DCEERA . . . . . . . . . . . . . . . . . . . . . . . . . . 61DCEGroup . . . . . . . . . . . . . . . . . . . . . . . . . 62DCELegacyDB . . . . . . . . . . . . . . . . . . . . . . . . 62DCELog . . . . . . . . . . . . . . . . . . . . . . . . . . 62DCEOrg . . . . . . . . . . . . . . . . . . . . . . . . . . 63DCEPolicy . . . . . . . . . . . . . . . . . . . . . . . . . 63DCEPrincipal . . . . . . . . . . . . . . . . . . . . . . . . 64DCERealm . . . . . . . . . . . . . . . . . . . . . . . . . 64DCEReplist . . . . . . . . . . . . . . . . . . . . . . . . . 65DCEUniqueID . . . . . . . . . . . . . . . . . . . . . . . . 65DCEUnix . . . . . . . . . . . . . . . . . . . . . . . . . . 66

iv IBM DCE Version 3.2 for AIX and Solaris: DCE Security Registry and LDAP Integration

DCEXATTR . . . . . . . . . . . . . . . . . . . . . . . . . 66SecMapExt . . . . . . . . . . . . . . . . . . . . . . . . . 66

DCE attributes . . . . . . . . . . . . . . . . . . . . . . . . . 67dceAclDefRealmName . . . . . . . . . . . . . . . . . . . . . 67dceAclDefRealmUUID . . . . . . . . . . . . . . . . . . . . . 67dceAclEntries . . . . . . . . . . . . . . . . . . . . . . . . 67dceBadOriginIP. . . . . . . . . . . . . . . . . . . . . . . . 67dceBadOriginString . . . . . . . . . . . . . . . . . . . . . . 67dceCreateTimestamp . . . . . . . . . . . . . . . . . . . . . 68dceCreatorsUUID . . . . . . . . . . . . . . . . . . . . . . . 68dceDefaultTktLife . . . . . . . . . . . . . . . . . . . . . . . 68dceDefDirAclEntries . . . . . . . . . . . . . . . . . . . . . . 68dceDefObjAclEntries . . . . . . . . . . . . . . . . . . . . . . 69dceDirName . . . . . . . . . . . . . . . . . . . . . . . . . 69dceDisableTime . . . . . . . . . . . . . . . . . . . . . . . 69dceDomain . . . . . . . . . . . . . . . . . . . . . . . . . 69dceDomainCacheState . . . . . . . . . . . . . . . . . . . . . 69dceFullName . . . . . . . . . . . . . . . . . . . . . . . . 70dceGoodOriginIP . . . . . . . . . . . . . . . . . . . . . . . 70dceGoodOriginString . . . . . . . . . . . . . . . . . . . . . . 70dceGoodSinceDate . . . . . . . . . . . . . . . . . . . . . . 70dceGroupName . . . . . . . . . . . . . . . . . . . . . . . 70dceHintForeignMembershipUUIDs . . . . . . . . . . . . . . . . . 70dceHintMembershipUUIDs. . . . . . . . . . . . . . . . . . . . 71dceID . . . . . . . . . . . . . . . . . . . . . . . . . . . 71dceInternalData . . . . . . . . . . . . . . . . . . . . . . . 71dceIsRequired . . . . . . . . . . . . . . . . . . . . . . . . 71dceJournalID . . . . . . . . . . . . . . . . . . . . . . . . 71dceKeyParts . . . . . . . . . . . . . . . . . . . . . . . . . 72dceLastUnixIDGroup . . . . . . . . . . . . . . . . . . . . . . 72dceLastUnixIDOrg. . . . . . . . . . . . . . . . . . . . . . . 72dceLastUnixIDPerson . . . . . . . . . . . . . . . . . . . . . 72dceLowUnixIDGroup . . . . . . . . . . . . . . . . . . . . . . 73dceLowUnixIDOrg . . . . . . . . . . . . . . . . . . . . . . . 73dceLowUnixIDPerson . . . . . . . . . . . . . . . . . . . . . 73dceMaxUnixID . . . . . . . . . . . . . . . . . . . . . . . . 73dceMinTktLife . . . . . . . . . . . . . . . . . . . . . . . . 73dceModifiersUUID . . . . . . . . . . . . . . . . . . . . . . . 74dceModifyTimestamp . . . . . . . . . . . . . . . . . . . . . 74dcePasswordMaxLength . . . . . . . . . . . . . . . . . . . . 74dcePolicyFlags . . . . . . . . . . . . . . . . . . . . . . . . 74dcePrimaryGroup . . . . . . . . . . . . . . . . . . . . . . . 74dceProjlistOK . . . . . . . . . . . . . . . . . . . . . . . . 75dceQuota . . . . . . . . . . . . . . . . . . . . . . . . . . 75dceReadOnlyReplica. . . . . . . . . . . . . . . . . . . . . . 75dceReadVersion . . . . . . . . . . . . . . . . . . . . . . . 75dceReplicaInfo . . . . . . . . . . . . . . . . . . . . . . . . 75dceReplicaTwrs. . . . . . . . . . . . . . . . . . . . . . . . 76dceRsaCurKeyVersion . . . . . . . . . . . . . . . . . . . . . 76dceRsaKeyOk . . . . . . . . . . . . . . . . . . . . . . . . 76dceSecMapSubtreeGroup . . . . . . . . . . . . . . . . . . . . 76dceSecMapSubtreeOther . . . . . . . . . . . . . . . . . . . . 76dceSecMapSubtreePrinc . . . . . . . . . . . . . . . . . . . . 76dceShadowPwdOK . . . . . . . . . . . . . . . . . . . . . . 77dceUnauthenticatedQuota . . . . . . . . . . . . . . . . . . . . 77dceUnboundTktsOK . . . . . . . . . . . . . . . . . . . . . . 77

Contents v

dceUniqueIDCfg . . . . . . . . . . . . . . . . . . . . . . . 77dceUnixObject . . . . . . . . . . . . . . . . . . . . . . . . 77dceUnixPassword . . . . . . . . . . . . . . . . . . . . . . . 78dceUUID . . . . . . . . . . . . . . . . . . . . . . . . . . 78dceUUID . . . . . . . . . . . . . . . . . . . . . . . . . . 78dceWriteVersion . . . . . . . . . . . . . . . . . . . . . . . 78dceXattrDefn. . . . . . . . . . . . . . . . . . . . . . . . . 78dceXattrName . . . . . . . . . . . . . . . . . . . . . . . . 79dceXattrValue . . . . . . . . . . . . . . . . . . . . . . . . 79description . . . . . . . . . . . . . . . . . . . . . . . . . 79gecos . . . . . . . . . . . . . . . . . . . . . . . . . . . 79homeDirectory . . . . . . . . . . . . . . . . . . . . . . . . 79ixLastUpdate. . . . . . . . . . . . . . . . . . . . . . . . . 80krbKdcServiceName . . . . . . . . . . . . . . . . . . . . . . 80krbRealmName-V2 . . . . . . . . . . . . . . . . . . . . . . 80loginShell . . . . . . . . . . . . . . . . . . . . . . . . . . 80maxFailedLogins . . . . . . . . . . . . . . . . . . . . . . . 80passwordMaxRepeatedChars . . . . . . . . . . . . . . . . . . 80passwordMinOtherChars . . . . . . . . . . . . . . . . . . . . 81passwordTimeReuse. . . . . . . . . . . . . . . . . . . . . . 81secAcctLife . . . . . . . . . . . . . . . . . . . . . . . . . 81secPwdAlpha . . . . . . . . . . . . . . . . . . . . . . . . 81secPwdSpaces . . . . . . . . . . . . . . . . . . . . . . . . 81secPwdValid . . . . . . . . . . . . . . . . . . . . . . . . . 81timeExpireLockout. . . . . . . . . . . . . . . . . . . . . . . 81unixID . . . . . . . . . . . . . . . . . . . . . . . . . . . 81unixPwdValid . . . . . . . . . . . . . . . . . . . . . . . . 82unixPwdVersion . . . . . . . . . . . . . . . . . . . . . . . 82

Kerberos object classes . . . . . . . . . . . . . . . . . . . . . 82KrbAlias . . . . . . . . . . . . . . . . . . . . . . . . . . 82KrbAuthObject . . . . . . . . . . . . . . . . . . . . . . . . 82KrbKey . . . . . . . . . . . . . . . . . . . . . . . . . . . 83KrbKeyCfg . . . . . . . . . . . . . . . . . . . . . . . . . 84KrbLog . . . . . . . . . . . . . . . . . . . . . . . . . . . 84KrbModifierInfo . . . . . . . . . . . . . . . . . . . . . . . . 84KrbMstrKey . . . . . . . . . . . . . . . . . . . . . . . . . 84KrbPolicy . . . . . . . . . . . . . . . . . . . . . . . . . . 85KrbPrincipal . . . . . . . . . . . . . . . . . . . . . . . . . 86KrbRealm-v2. . . . . . . . . . . . . . . . . . . . . . . . . 87KrbRealmExt . . . . . . . . . . . . . . . . . . . . . . . . 87

Kerberos attributes . . . . . . . . . . . . . . . . . . . . . . . 87accountExpires . . . . . . . . . . . . . . . . . . . . . . . . 87badPasswordTime. . . . . . . . . . . . . . . . . . . . . . . 88badPwdCount . . . . . . . . . . . . . . . . . . . . . . . . 88krbAdmAclDB . . . . . . . . . . . . . . . . . . . . . . . . 88krbAdmKeyLocation . . . . . . . . . . . . . . . . . . . . . . 89krbAdmServiceObject . . . . . . . . . . . . . . . . . . . . . 89krbAliasedObjectName . . . . . . . . . . . . . . . . . . . . . 89krbAttributes . . . . . . . . . . . . . . . . . . . . . . . . . 89krbCurKeyVersion . . . . . . . . . . . . . . . . . . . . . . . 90krbDeleteType . . . . . . . . . . . . . . . . . . . . . . . . 90krbEncTypeSupport . . . . . . . . . . . . . . . . . . . . . . 90krbExtraData. . . . . . . . . . . . . . . . . . . . . . . . . 91krbHintAliases . . . . . . . . . . . . . . . . . . . . . . . . 91krbKdcServiceObject . . . . . . . . . . . . . . . . . . . . . . 91krbKeyData . . . . . . . . . . . . . . . . . . . . . . . . . 91

vi IBM DCE Version 3.2 for AIX and Solaris: DCE Security Registry and LDAP Integration

krbKeyExpires . . . . . . . . . . . . . . . . . . . . . . . . 92krbKeyName. . . . . . . . . . . . . . . . . . . . . . . . . 92krbKeyType . . . . . . . . . . . . . . . . . . . . . . . . . 93krbKeyVersion . . . . . . . . . . . . . . . . . . . . . . . . 93krbModifiersName . . . . . . . . . . . . . . . . . . . . . . . 93krbModifyTimestamp . . . . . . . . . . . . . . . . . . . . . . 94krbMstrKeyData . . . . . . . . . . . . . . . . . . . . . . . 94krbMultKeyVersionsOK . . . . . . . . . . . . . . . . . . . . . 95krbNextKeyVersion . . . . . . . . . . . . . . . . . . . . . . 95krbPolicyName . . . . . . . . . . . . . . . . . . . . . . . . 95krbPolicyNameRef . . . . . . . . . . . . . . . . . . . . . . 95krbPolicyObject . . . . . . . . . . . . . . . . . . . . . . . . 96krbPrincipalDN . . . . . . . . . . . . . . . . . . . . . . . . 96krbPrincipalName . . . . . . . . . . . . . . . . . . . . . . . 96krbPrincipalType . . . . . . . . . . . . . . . . . . . . . . . 96krbPrincSubTree . . . . . . . . . . . . . . . . . . . . . . . 97krbPwdServiceObject . . . . . . . . . . . . . . . . . . . . . 97krbRealmName-v2 . . . . . . . . . . . . . . . . . . . . . . 97krbRedundancyPolicy . . . . . . . . . . . . . . . . . . . . . 97krbSaltTypeSupport . . . . . . . . . . . . . . . . . . . . . . 98krbSecretKeyCfg . . . . . . . . . . . . . . . . . . . . . . . 98krbTaggedDataList . . . . . . . . . . . . . . . . . . . . . . 99krbTrustedAdmObject . . . . . . . . . . . . . . . . . . . . . 99lastLogon . . . . . . . . . . . . . . . . . . . . . . . . . . 99logType . . . . . . . . . . . . . . . . . . . . . . . . . . 100maxPwdAge . . . . . . . . . . . . . . . . . . . . . . . . 100maxRenewAge . . . . . . . . . . . . . . . . . . . . . . . 100maxTicketAge . . . . . . . . . . . . . . . . . . . . . . . . 100minPwdAge . . . . . . . . . . . . . . . . . . . . . . . . 100minPwdLength . . . . . . . . . . . . . . . . . . . . . . . 100passwordDictFiles . . . . . . . . . . . . . . . . . . . . . . 101passwordExpireTime . . . . . . . . . . . . . . . . . . . . . 101passwordMaxAge . . . . . . . . . . . . . . . . . . . . . . 101passwordMinAge. . . . . . . . . . . . . . . . . . . . . . . 101passwordMinDiffChars. . . . . . . . . . . . . . . . . . . . . 101passwordMinLength . . . . . . . . . . . . . . . . . . . . . 102pwdHistoryLength . . . . . . . . . . . . . . . . . . . . . . 102pwdLastSet. . . . . . . . . . . . . . . . . . . . . . . . . 102secAcctExpires . . . . . . . . . . . . . . . . . . . . . . . 102secAcctValid . . . . . . . . . . . . . . . . . . . . . . . . 102userAccountControl . . . . . . . . . . . . . . . . . . . . . . 103

Appendix C. Notices . . . . . . . . . . . . . . . . . . . . . . 105Trademarks. . . . . . . . . . . . . . . . . . . . . . . . . . 107

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Contents vii

viii IBM DCE Version 3.2 for AIX and Solaris: DCE Security Registry and LDAP Integration

Preface

This book describes DCE Security Registry and LDAP Integration in IBM®

Distributed Computing Environment (DCE) 3.2. It provides system administratorswith the information needed to migrate the DCE security registry to an LDAPdirectory. It also provides information you need to configure and administer LDAPsecurity servers.

AudienceThis guide is written for system and network administrators who have previouslyused LDAP and administered in an AIX® or Solaris environment.

ApplicabilityThis book applies to the IBM DCE 3.2 offering and related updates. See yoursoftware license for details.

Document usageThis manual is organized into the following main sections:

Chapter 1: Overview of DCE Security Registry and LDAP IntegrationDescribes DCE Security Registry and LDAP integration. Chapter 1 alsogives a general overview of LDAP security server configurations.

Chapter 2: Planning ConsiderationsDescribes issues that you need to consider before migrating the DCEsecurity registry to an LDAP directory.

Chapter 3: Configuration and MigrationExplains LDAP security server configurations and provides steps formigrating the DCE security registry to an LDAP directory. Chapter 3 alsoincludes directions for the configuring and unconfiguring of LDAP securityservers.

Chapter 4: AdministrationDescribes common LDAP security server administration tasks along withnew and updated commands that are used to configure and migrate LDAPsecurity servers.

AppendixAppendix A describes the default DCE LDAP tree. Appendix B describes theobjects and attributes in the DCE and Kerberos schema definitions.

Related DocumentsFor additional information about DCE refer to the following documents:

v IBM DCE Version 3.2 for AIX: Quick Beginnings

v IBM DCE Version 3.2 for Solaris: Quick Beginnings

v IBM DCE Version 3.2 for AIX and Solaris: Administration Commands Reference

v IBM DCE Version 3.2 for AIX: Release Notes

v IBM DCE Version 3.2 for Solaris: Release Notes

v IBM DCE Version 3.2 for AIX and Solaris: Administration Guide—Introduction

v IBM DCE Version 3.2 for AIX and Solaris: Administration Guide

© Copyright IBM Corp. 2001 ix

v IBM DCE Version 3.2 for AIX and Solaris: Introduction to DCE

Typographic and Keying ConventionsThis guide uses the following typographic conventions:

Bold Bold words or characters represent system elements that you must useliterally, such as commands, options, and pathnames.

Italic Italic words or characters represent variable values that you must supply.Italic type also introduces new DCE terms.

Constant widthExamples and information that the system displays appear in constantwidth typeface.

[ ] Brackets enclose optional items in format descriptions and syntaxdescriptions.

{ } Braces enclose a list from which you must choose an item in formatdescriptions and syntax descriptions.

| A vertical bar separates items in a list of choices.

< > Angle brackets enclose the name of a key on the keyboard.

... Horizontal ellipsis points indicate that you can repeat the preceding itemone or more times.

dcelocalThe Open Software Foundation (OSF) variable dcelocal in this documentequates to the AIX variable /opt/dcelocal.

dceshareThe OSF variable dceshare in this document equates to the AIX variable/opt/dcelocal.

This guide uses the following keying conventions:

<Ctrl- x> or | xThe notation <Ctrl- x> or | x followed by the name of a key indicates acontrol character sequence. For example, <Ctrl-C> means that you holddown the control key while pressing <C>.

<Return>The notation <Return> refers to the key on your terminal or workstationthat is labeled with the word Return or Enter, or with a left arrow.

x IBM DCE Version 3.2 for AIX and Solaris: DCE Security Registry and LDAP Integration

Chapter 1. Introduction to DCE Security Registry and LDAPIntegration

DCE Security Registry and LDAP Integration is a new feature in IBM DCE 3.2 forAIX and Solaris. This feature enhances IBM DCE by moving security informationthat is stored in the DCE specific database known as the security registry to aLightweight Directory Access Protocol (LDAP) directory.

This chapter describes the legacy DCE security registry configuration along with thesecurity registry data structure in LDAP.

Note: It is assumed that the users of this book have LDAP experience. Therefore,LDAP concepts and terminology are not explained.

Benefits of LDAP integrationMigrating the DCE security registry to LDAP provides several major benefits:

v Eliminates an extra database for administrators to backup and maintain.

After the security registry is moved to an LDAP directory, the security registry isbacked up during LDAP backups.

v Reduces limitations on database size.

The traditional DCE security model not only stores security information in localfiles, it also keeps the registry in the security server’s address space. While thistechnique can improve performance, it also puts a limitation on the size of theregistry. By moving the security information to LDAP, the database can be scaledup to support a larger number of users than the legacy security registry cansupport.

v Allows other applications to share security data with DCE.

An LDAP directory can be used as a centralized repository for user information.Once the DCE security registry has been migrated to LDAP, DCEobjects—principals, groups, and organizations—can be shared with otherapplications. For example, the DCE security authentication service is based onthe Kerberos Version 5 protocol, so DCE information stored in LDAP includes, asa subset, the information required by a Kerberos implementation.

v Allows you to associate DCE objects with other objects in the LDAP directory.

For example, by attaching DCE principal information to an existing person object,you can associate a DCE principal with a person object already configured in thedirectory. Then all of the information about a person is located on one objectinstead of on various objects throughout the database.

DCE security serviceThe DCE security service consists of the following services:

Registry serviceMaintains the registry database, which is a replicated database ofprincipals, groups, organizations, accounts, and administrative policies.

Authentication serviceHandles user authentication (the process of verifying that principals arecorrectly identified). The authentication service also issues tickets that a

© Copyright IBM Corp. 2001 1

principal uses to access remote services. The ticket contains data that ispresented by the principal requesting the service to the principal providingthe service.

Privilege serviceSupplies the user’s privilege attributes, which are used to ensure that aprincipal has the rights to perform requested operations.

In addition, the DCE Security Service provides the following:

Access control list (ACL) facilityEstablishes and grants access rights to an object based on the object’saccess permissions.

Extended registry attribute (ERA) facilityProvides tools to extend the registry database schema to define additionalattributes and tools to attach those attributes to registry objects.

The registry service is a replicated service that manages the cell’s securitydatabase. The security database contains entries for security entities, which arecalled principals. A principal can be a user or a server, for example. The databasealso contains information that is associated with each principal; for example,encryption keys, which are used in authentication, authorization, and encryption ofmessages. The registry service enables administrators to access and modify thedatabase of DCE users.

For more information about the DCE security service see the IBM DCE Version 3.2for AIX and Solaris: Administration Guide—Core Components.

Overview of legacy DCE security severs

Note: Throughout this book the term legacy security server is used to describesecurity servers that store their data in the DCE security registry instead of inLDAP.

Each legacy DCE security server maintains a working copy of the registry databasein virtual memory and a permanent copy on disk. All reads and updates operate onthe copy stored in virtual memory. When the servers startup, they use the copy thatis on disk to initialize the copy in virtual memory. The servers use an atomic updatelog to guarantee the database state in the event of server failure.

The registry database can be replicated within its cell. Each instance of a securityserver in a cell maintains a working copy of the database. The combination of asecurity server and its data (the registry database) is referred to as a replica.Typically, you create several replicas in a cell to enhance performance andreliability.

The security servers automatically keep the replicas in a cell consistent. This meansthat any changes that you make to the registry database are automatically reflectedin all replicas. Updates are made to only one database, and the changes arepropagated to all others. While propagations are pending, all replicas are accessibleeven if they are not completely up-to-date. In other words, even replicas to whichthe changes were not yet applied are available. This replication mechanism ensuresthat all replicas remain available for login validation and for read operations evenwhen changes are in the process of being propagated.

2 IBM DCE Version 3.2 for AIX and Solaris: DCE Security Registry and LDAP Integration

Only one replica in a cell, the master replica, accepts updates to its database fromclients. Other replicas, called slave replicas, accept only reads from clients. Afterthe database is updated, the master replica propagates updates to the slavereplicas. For example, either a master or a slave replica can provide accountinformation to a client program such as /bin/login. However, if you are adding anaccount or changing password information, those updates can be handled by themaster replica only.

Figure 1 shows the legacy master security server.

Physical security of the legacy databaseThe DCE security service provides safeguards for network security, protectinginformation that is transmitted across the network by guaranteeing the identities ofprincipals who engage in cross-machine communications. However, the securityserver and the database that it serves reside on a local machine. The registrydatabase is only as secure as the security provided by the machine on which itresides.

In addition to ensuring that sensitive data can be accessed on the local machineonly by root, you need to provide physical security for the machine on which thesecurity server resides. This can include placing the machine in a locked room,keeping a log of when and by whom the machine is accessed, and any othermethods that might be appropriate to your needs.

Overview of LDAP security serversIn a cell that has been entirely migrated to use DCE Security Registry and LDAPIntegration, this feature eliminates the local registry databases and stores securitydata in an LDAP directory.

After legacy DCE security servers are migrated to LDAP, they no longer maintain aworking copy of the registry database in virtual memory. They also do not maintaina copy of the registry on a local disk. Instead, LDAP security servers store allregistry data in an LDAP directory. All reads and updates operate on the data in the

Mastersecurityserver

Memory

registry

and

prop queue

Rgy_datafiles

Update_log

Updates written toupdate_log

Updates written tomemory registry andprop queue

Registry data isread from diskwhen secd starts

Checkpoint writesmemory registry todisk

Prop queuethread pushesupdates toreplicas

Figure 1. Legacy Master Security Server

Chapter 1. Introduction to DCE Security Registry and LDAP Integration 3

LDAP directory. Also, an atomic update log is no longer necessary since updatesare immediately written to the LDAP directory.

DCE no longer replicates the registry database. Instead, the LDAP directory reflectsany changes that you make to security data and the LDAP replication featuremaintains consistency between LDAP servers. The LDAP master security servermust point to a read/write LDAP server.

There are three types of LDAP security servers: the LDAP master security server,LDAP slave security servers, and the LDAP migration security server. The followinglist describes each type of security server:

LDAP master security serverThe LDAP master security server accepts reads and updates from clients. Itis the only replica in the cell that accepts updates to its database.

LDAP slave security serverThe LDAP slave security server is a read-only replica security server thatretrieves all registry data from LDAP.

LDAP migration security serverThis is a special type of security server that is used to migrate the legacysecurity registry to LDAP. The migration server obtains security registry datafrom the legacy master’s propagation queue and migrates it to an LDAPdirectory. After the initial migration is complete, the migration servercontinues to receive updates from the master security server and writesthem to LDAP. This keeps LDAP synchronized with the master securityserver in the cell. This server only exists until the LDAP security master isonline. Figure 3 on page 25 shows the migration server configuration.

Either an LDAP security master or an LDAP security slave can provide accountinformation to a client program such as /bin/login. However, only the LDAP securitymaster can accept updates such as adding an account or changing passwordinformation. Allowing only one replica to modify security data helps maintain dataconsistency.

Physical security of the LDAP registryThe DCE Security Service provides safeguards for network security. It protectsinformation that is transmitted across the network from security client to securityserver by guaranteeing the identities of principals who engage in cross-machinecommunications. However, the data passed between the LDAP server and the DCEsecurity servers is not encrypted unless Secure Sockets Layer (SSL) is being used.The registry database is only as secure as the security provided by the LDAPdirectory.

In addition to ensuring that sensitive data can be accessed on the local machineonly by root, you need to provide physical security for the machines on which theLDAP directory and the DCE security servers reside. This can include placing themachine in a locked room, keeping a log of when and by whom the machine isaccessed, and any other methods that might be appropriate to your needs. Keep inmind that information DCE uses to connect to LDAP is stored in clear-text format ina file only accessible by root on each DCE security server.

For a more secure environment, configure the LDAP server and the LDAP mastersecurity server on the same machine.


See “Additional security considerations” on page 24 for more information aboutsecuring the LDAP registry.

Data structureThis section describes the structure of security data in LDAP. It is assumed thatusers have used LDAP, so LDAP terms and concepts are not explained.

Legacy security data structureThe DCE security registry consists of many databases that are stored in files thatcontain portions of the data required for each security object. These files are storedin /opt/dcelocal/var/security/rgy_data. The security registry stores these databasesin memory and periodically writes them to disk. For a list of objects in the legacysecurity registry see the IBM DCE Version 3.2 for AIX and Solaris: AdministrationGuide—Introduction.

LDAP security data structureDCE Security Registry and LDAP Integration replaces the DCE registry databasewith an LDAP directory, which in turn uses another database, such as DB2®, as itsbackend.

The DCE objects—principal, group, and org—are based on core LDAP objectclasses such as person, group of names, and organization. DCE Security Registryand LDAP Integration attaches DCE account attributes to the principal objectinstead of pointing to an account object.

Additionally, the principal, group, and org objects use auxiliary object classes. Theseobject classes are DCE and Kerberos specific and contain all the attributes neededto describe a DCE object.

There are other attributes that are associated with the principal, group, and orgobjects by being placed in a separate structural object. The separate object is achild of the principal, group, or org structural object. This is necessary for thefollowing reasons:

v Some attributes are associated with multiple object types. Because of this, aseparate object, the UniqueID, attaches to each object type. The UniqueID isalso configured in its own object for security reasons.

v The login information that is stored in the DCELog object is updated frequently.When the security server writes to LDAP, caching might occur on the LDAPserver. Instead of recaching the entire principal, group, or org object, the LDAPserver needs to cache only the small part of the data that was changed.

v There might be multiple versions of a key associated with each principal object.Therefore, the key information belongs to a separate structural object.

v User-defined ERAs are stored as binary objects in a separate ERA structuralobject.

“Appendix B. DCE and Kerberos Schema Definitions” on page 61 contains theLDAP DCE security schema. Consult the schema for definitions of the objects in theLDAP tree.

The journal design has not changed for DCE Security Registry and LDAPIntegration. The principal database contains a pointer to the journal data. Data iswritten to the journal and compared with data from the same time on the masterserver in the login_activity area.


Some registry information that is local to the server is kept on the local machineand in memory.

LimitationsWith the exception of storing the security registry in an LDAP directory, LDAPsecurity servers operate similarly to legacy security servers. Therefore, you usemost of the same commands to administer LDAP security servers. However thereare a few legacy security functions that are not supported by LDAP securityservers. A list of these unsupported features and limitations follows:

v When you issue the sec_admin -s command on a legacy security server, youcan provide the replica’s name as it appears on the replica list. LDAP securityservers do not support this feature. However, you can continue to provide the cellname, the global name, or the network address of the host. For more informationabut the sec_admin command, consult the IBM DCE Version 3.2 for AIX andSolaris: Administration Commands Reference.

v Some information in the output from the sec_admin command is not valid in aDCE cell that has been fully migrated to LDAP. The sequence number and lastupdate are not maintained in the LDAP directory since DCE propagation is nolonger taking place. During migration, the migration server and legacy securityservers maintain this data. However, LDAP security slaves appear to be out ofdate. Once migration is complete, and all security servers are using LDAP, DCEno longer replicates the registry database and the sequence number and lastupdate should be ignored.

v Unlike legacy security servers, LDAP security servers do not support containerACLs unless the container object is created by DCE. Container ACLs aremeaningful only when DCE creates directories. If DCE attributes are attached toexisting LDAP objects, the ACL’s of the parent are ignored. For more informationabout container ACLs on legacy DCE security servers, see the IBM DCE Version3.2 for AIX and Solaris: Administration Guide—Core Components.

v LDAP does not support DCE aliases. An alias is an alternate name for a primaryname.

v Legacy DCE allows principals, groups, and orgs to be renamed using eitherdcecp or rgy_edit or by using the sec_rgy_pgo_rename API. This functionalityis not supported after security data is migrated to LDAP.

If the master security server is running DCE 3.2 and detects an LDAP migrationserver configured in the cell, these commands are rejected.

If the master security server is not running DCE 3.2 and a command is issued torename a principal, group, or org, the LDAP replicas indicate that they haveperformed the function when they have not. This keeps the master securityserver from continuously trying to perform the update. However, the legacydatabase and the LDAP database will have inconsistent data.

v If DCE objects are located in multiple subtrees, dcecp catalog commands searchthe default DCE subtree under the realm only. If DCE objects are in differentsubtrees, use LDAP searches for catalog functions.

v It is strongly recommended that you use only case-insensitive names for DCErealms, principals, groups, and organizations. This is because some LDAPservers (such as SecureWay® LDAP) convert any name to single case whenprocessing the name in a DN or an ACL. Converting names to single case cancauses improper results with some LDAP operations. For example, you cannothave one primary name stored as joe_programmer and another one stored asJOE_PROGRAMMER because LDAP reads them both as joe_programmer andtreats them as the same primary name.


v DCE does not allow you to change a master key on LDAP enabled securityservers.



Chapter 2. Planning Considerations

This chapter discusses issues you must consider before you migrate the DCEsecurity registry to an LDAP directory. Also, follow the planning considerations listedin your LDAP documentation.

DCE versionIf you intend to run a combination of legacy security servers and LDAP securityservers, legacy replicas still function and can be running versions of DCE below 3.2as long as the master security server has not been migrated to LDAP.

If you intend to migrate an entire cell to LDAP-based security, all security servers inthe cell must be running DCE 3.2. During migration to LDAP, the DCE registryversion is modified to secd.dce.1.3. Any security servers in the cell that cannotsupport this registry version are shut down by the legacy master. This is triggeredby an attempt to propagate an update to the down-level servers. Propagation doesnot occur after the master security server has been migrated to LDAP. So, if adown-level server is undetected (that is, no updates have occurred) and the masteris migrated to LDAP, it is possible for a server to continue running and provide staledata. Therefore, it is recommended that the cell administrator unconfigure anysecurity servers which do not support DCE 3.2 prior to migrating the master securityserver to LDAP.

Supported versions of LDAPDCE 3.2 supports the following LDAP server implementations:

v IBM SecureWay Directory 3.2.1 for AIX and Solaris and Windows NT®

v iPlanet Directory Server 4.13 on Solaris 7

v iPlanet Directory Server 5.0 on Solaris 8.

The IBM SecureWay Directory client v3.2.1 is shipped on the DCE 3.2 CD. The3.2.1 client must be installed on all security server machines before they aremigrated to LDAP.

The IBM SecureWay Directory client requires a minimum e-fix of 3.2.2–SWD-0001.e-fixes are available on the IBM SecureWay Web site atwww.ibm.com/secureway/directory

DCE supports the v3 LDAP protocols only, and the LDAP database must be aUTF8 database.

Performance considerationsPlease refer to the following documents for information about performanceimplications when storing security registry data in LDAP.

v DCE 3.2 for AIX Readme

v DCE 3.2 for Solaris Readme

v DCE 3.2 for AIX Readme Addendum

v DCE 3.2 for Solaris Readme Addendum


http://www.ibm.com/secureway/directory

Sharing objects and attributesStoring the DCE security registry in LDAP allows you to share information withother applications. This sharing of data has ramifications that impact administrationand must be understood before you decide to migrate the DCE registry data.

v Changes made to DCE information stored in LDAP might alter behavior of DCEor another application. Therefore, it is recommended that you modify thisinformation through a single interface. Administration of common data objectsthrough multiple interfaces in a shared LDAP directory may cause inconsistencyin the view of the data across different applications.

v If you are running a combination of legacy security servers and LDAP securityservers, changes to DCE information should only be made through DCEinterfaces. There is no mechanism for propagating changes made directly toLDAP back to legacy DCE security servers.

v Exercise caution when you modify LDAP attributes that might affect DCE. CertainDCE attributes in LDAP might point to other DCE objects. These attributes mustalways point to a DCE object in order for DCE to work correctly. In order toensure that DCE continues to work correctly once migrated to LDAP, it isrequired that all DCE objects be created by DCE (rather than anotherapplication). Consult the DCE schema in “Appendix B. DCE and KerberosSchema Definitions” on page 61 for a description of the objects and attributesthat are required for DCE to operate correctly.

LDAP directory considerationsKeep the following LDAP directory considerations in mind when migrating the DCEsecurity registry to an LDAP directory.

DCE and Kerberos LDIF filesDCE 3.2 is shipped with the following three sets of LDIF files:

v LDIF files for IBM SecureWay Directory 3.2.1

v LDIF files for iPlanet Directory Server 4.13

v LDIF files for iPlanet Directory Server 5.0

Each set of files contains one LDIF file that contains DCE schema definitions andone LDIF file that contains Kerberos schema definitions. These schema definitionsare necessary to store DCE security data in the LDAP directory. The Kerberosportion of the schema might already be installed. If the schema on the LDAPservers does not already have the DCE and Kerberos schema installed, you mustinstall and load it on all the LDAP installations that will be storing DCE securitydata. You must load the Kerberos schema before you load the DCE schema.

“Appendix B. DCE and Kerberos Schema Definitions” on page 61 describes theDCE and Kerberos schema.

Loading DCE schema definitions in the LDAP directoryWhen you load the DCE and Kerberos schema definitions, your LDAP server mightreturn error messages stating that some definitions you are attempting to load arealready defined in your LDAP directory. This is not a problem if the definitionsalready loaded in your LDAP directory are the same as the definitions in theshipped LDIF files.


Configuring LDAP indexed attributesIf your LDAP server allows you to configure the indexing of schema attributes, it isrecommended that you configure the schema attributes used by DCE for searchoperations in an equality index. DCE uses the following attributes for searchoperations:

v krbRealmName-v2

v krbPrincipalName

v krbPolicyName

v krbKeyVersion

v dceDirName

v dceXattrName

v dceGroupName

v dceUUID

v UnixID

Configuring these attributes in an equality index can improve performance whenDCE searches for information in the LDAP directory. It is recommended that you donot configure any other attributes defined in the Kerberos and DCE schema in anindex, since this slows down performance when DCE writes attributes to the LDAPdirectory. If you are using the IBM SecureWay Directory server, you do not need toconfigure the indexing of attributes because the shipped LDIF files for SecureWayDirectory configure the indexing of attributes.

Storing principals, groups, and orgsA DCE principal, group, or org name must be unique within the LDAP database. Inorder to accomplish this, the cell name is appended to the current DCE principal,group, or org name prior to being stored in LDAP. For example, the principalcell_admin is stored as cell_admin@artichoke_cell. Because DCE cells must haveunique names, this allows data for multiple DCE cells to be stored in one LDAPdirectory.

The principal, group, and org names are stored in the following LDAP attributes:

principalkrbPrincipalName

group dceGroupName

org krbPolicyName

The objects that contain the krbPrincipalName, dceGroupName, and krbPolicyNameattributes are created within the krbRealm tree, unless an object with those namesalready exists in one of the subtrees indicated by krbPrincSubTree. If an object withthose names already exists, the DCE attributes are added to the existing object.

When you migrate your cell to LDAP, you must decide where DCE stores eachprincipal, group, or org that is migrated to LDAP. You can store each principal,group, or org in either of the following entries:

v A new entry configured by DCE under the realm entry (this is the default)

v An entry that already resides in the LDAP directory under a subtree listed in thekrbPrincSubtree attribute of the realm entry and that contains thekrbPrincipalName, dceGroupName, or krbPolicyNameRef attribute with the namespecified in the format name@realm. The entry must also contain the appropriateauxiliary object classes, either krbprincipal, krbpolicy, or dcegroup.

Chapter 2. Planning Considerations 11

Sharing a common principal in a DCE cellIf a DCE application shares a common principal with DCE, both principals havetheir own keytab file. If the DCE client changes the common principal’s password,only the DCE client’s keytab file reflects the change. When the client applicationtries to login as that user, it fails because it still has the old password. Users needto be aware of the implications of sharing common principals with DCE.

Reserved namesSome principals and accounts are reserved for use by various system operations.You cannot delete reserved principals. You can modify, but you must not directlydelete, reserved accounts. However, you can delete reserved accounts indirectly bydeleting the group or organization specified in the account.

The following is a partial list of reserved principals and accounts. In the list,cell_name is the name of your cell.

v Reserved principals

– dce-ptgt

– krbtgt/cell_name

– dce-rgy

v Reserved accounts

– dce-ptgt none none

– krgtgt/cell_name none none

– dce-rgy none none

Do not delete reserved principals and accounts.

Master key considerationsThe legacy DCE security service design requires each security server to have itsown master key. Each legacy security server encrypts all passwords with its ownmaster key and stores this data in the server’s local database. When using LDAPas a backing store, one security server writes all the data to LDAP, while the othersecurity servers read this data. Therefore, all of the servers accessing LDAP mustuse the same master key. When you migrate the first server to LDAP, you canchoose where to store the master key. Choose one of the following methods toshare the master key information:

v Store the master key in LDAP. The format of the key in LDAP is defined by theLDAP Kerberos schema and might be used by other applications that abide bythat schema. To make the master key readable in LDAP, set appropriate LDAPACLs on the object.

v Store the master key in a filesystem. Place a copy of the master key in the localfilesystem of each LDAP security server, or place the key in a distributedfilesystem accessible by each of the servers. When you choose to store the keyin a filesystem, a pointer to the key file is created in LDAP.

Currently, the key cannot be moved in or out of LDAP after the migration of themigration slave, so care must be taken when choosing the initial location of themaster key. If the key is stored in the local filesystem and the key hasn’t beenmoved to the server being migrated (or configured as an LDAP slave), the server islikely to be unable to run due to ″Decrypt Integrity Check″ failures.

DCE does not allow you to change a master key on LDAP enabled security servers.


Data consistencyThe LDAP server maintains consistency of security data that is stored in LDAPdirectories, although DCE maintains consistency with legacy security servers in apartially-migrated cell. DCE is not notified when an LDAP application modifies datain the LDAP directory. Therefore, until all of the security servers in a cell aremigrated to LDAP, you must use DCE interfaces to modify data that DCE stores inLDAP. If you modify security data using an LDAP application, the updates are onlyaccessible to migrated servers and not to legacy servers. This means you getinconsistent information between LDAP security servers and legacy securityservers.

Security configurationThis section describes the configuration tasks that are required to protect DCEregistry data in an LDAP directory.

Security overviewThe following figure illustrates a request to access DCE registry data and showshow the request and the associated DCE registry data are protected:

The following example shows how a principal delete operation request and theassociated DCE registry data are protected:

1. The DCE client uses the RPC authenticated protocol with client and serverauthentication and data integrity to establish a secure connection with the DCEsecurity server. The principal delete request is sent over this secure connection.A legacy DCE security server also performs this step.

2. If DCE auditing is enabled on the DCE security server, the DCE security serveraudits the request. A legacy DCE security server also performs this step.

3. The DCE security server uses an LDAP bind protocol to establish a secureconnection with the LDAP server. The amount of security provided with thisconnection depends on which LDAP bind protocol you choose to configure. See“Configuring an LDAP bind protocol” on page 14 for more information.

4. The DCE security server requests the LDAP server to return the DCE ACL dataassociated with the target principal.

5. If the LDAP server supports auditing and auditing is enabled, the LDAP serveraudits the request.

6. The LDAP server determines if the DCE security server has permission to readthe requested data based on the identity of the DCE security server and theLDAP ACL configured on the requested data. If the DCE server does havepermission, the LDAP server returns the DCE ACL data.

7. The DCE security server determines from the DCE ACL data whether the DCEclient has the permission to delete the principal. A legacy DCE security server

LDAP server(LDAP access

control andLDAP

auditing)

DCEclient

authenticatedRPC protocol

LDAP bindprotocol

DCE securityserver

(DCE accesscontrol and

DCE auditing)

Figure 2. Security overview


also performs this step. If the client has the correct permission, the DCEsecurity server requests the LDAP server to delete the principal data.

8. If the LDAP server supports auditing and auditing is enabled, the request isaudited.

9. The LDAP server determines if the DCE security server has permission todelete the requested data based on the identity of the DCE security server andthe LDAP ACL configured on the requested data. If so, the LDAP server deletesthe data.

Configuring an LDAP bind protocolYou must decide which method you want the DCE security server to use to bind toand transmit data to and from the LDAP server. After you select a bind method, youmust configure your server to use that method using the steps in the followingsections. DCE 3.2 supports the following authentication and data transmissionmethods:

v Simple bind

v Simple bind with SSL

v SASL CRAM-MD5 bind (supported by IBM SecureWay Directory only)

v SASL CRAM-MD5 bind with SSL (supported by IBM SecureWay Directory only)

v SASL SSL bind

Table 1 summarizes the protection provided by each authentication method. Afteryou decide which type of authentication you are using, you must perform theconfiguration required for that method.

Table 1. Supported authentication and data transmission methods

Method LDAP Client(secd)

LDAP ServerAuthentication

Data PrivacyDuringTransmission

Data IntegrityDuringTransmission

Simple bind Yes (DN andPassword)

No No No

Simple bind withSSL

Yes (DN andPassword)

Yes (SSL withpublic keytechnology)

Yes (SSLnegotiatedalgorithm)


SASLCRAM-MD5bind*

Yes (DN andCRAM-MD5protocol provingknowledge ofpassword)


No (but cleartext password isnot transmitted)

No

SASLCRAM-MD5 bindwith SSL*





SASL SSL bind Yes (SSL withpublic keytechnology)




*The SASL CRAM-MD5 bind and SASL CRAM-MD5 with SSL bind are supported by IBMSecureWay Directory only.


Configuring a simple bindA simple bind provides an easy way for the DCE security server to authenticate itsidentity to the LDAP server through the use of an LDAP distinguished name (DN)and password. This method does not provide a way for the DCE security server toauthenticate the identity of the LDAP server, and it does not protect the privacy andintegrity of the transmitted data.

Perform the following steps to configure a simple bind:

1. Determine if the LDAP server can accept simple bind requests from an LDAP(non-SSL) port. If it cannot accept simple bind requests from an LDAP port, youcannot use this method.

2. Configure a method of protecting the privacy of the userPassword attribute.Valid methods are a one-way hashing algorithm (this is the preferred method) ora two-way encryption algorithm.

3. In the LDAP directory, configure an entry with a userPassword attribute torepresent the DCE security server. See “Configuring DCE server entries in theLDAP directory” on page 20 for more information.

4. Specify the following parameters when you migrate a DCE security server usingthe dcecp registry migrate command or when you configure an LDAP securityslave using the config.dce command:

dcecp registry migrateparameter

config.dce parameter value

-auth_type -ldap_auth simple

-bind_dn -ldap_dn DN of the entry representing the DCEsecurity server

-bind_dn_pw -ldap_dn_pw value stored in the userPasswordattribute of the entry representing theDCE security server

For more information about configuring or migrating an LDAP security serversee “Chapter 3. Configuration and Migration” on page 25.

After you configure a simple bind, the DCE security server performs the followingsteps to establish a secure transmission with the LDAP server:

1. The DCE security server issues a simple bind request to the LDAP server. Inthis request, the DCE security server sends the LDAP server the DN and userpassword specified during migration or configuration. The DN and userpassword are sent in the clear with no data integrity protection.

2. The LDAP server attempts to authenticate the identity of the DCE securityserver by comparing the user password from the request with the value storedin the userPassword attribute of the requested DN.

3. If authentication is successful, the DCE security server has an authenticatedLDAP identity. This identity is the DN that was sent with the LDAP bind request.

4. The DCE security server and the LDAP server transmit information to eachother. All information is transmitted in clear text with no data integrity protection.

Configuring a simple bind with SSLThe simple bind with SSL authentication method combines the simple bind methodwith the SSL protocol. It provides a simple way for the DCE security server toauthenticate its identity to the LDAP server through the use of an LDAP DN andpassword. It also provides a public key method for the LDAP server to authenticateits identity to the DCE security server and to ensure data privacy and integrityduring transmission.


Perform the following steps to configure a simple bind with SSL:

1. Determine if your LDAP server can accept requests to an SSL port for aserver-authenticated SSL session. Also determine if the LDAP server can acceptrequests for a simple bind while in the SSL session. If your LDAP server doesnot meet both of these conditions, you cannot use the simple bind with SSLauthentication method.

2. Configure your LDAP server so that it can accept server-authenticated SSLrequests.

3. If your LDAP server supports it, configure a method of protecting the privacy ofthe userPassword attribute. Valid methods are a one-way hashing algorithm(this is the preferred method) or a two-way encryption algorithm.

4. Configure an SSL key database file containing the certificate of your LDAPserver on the machine containing the DCE security server.





-auth_type -ldap_auth simple



-ssl -ldap_ssl none

-keyring -ldap_keyring key database filename

-keyring_pw -ldap_keyring_pw key database password


After you configure a simple bind with SSL, the DCE security server performs thefollowing steps to transmit data to the LDAP server:

1. The DCE security server requests a server-authenticated SSL session with theLDAP server.

2. The DCE security server authenticates the identity of the LDAP server bymeans of the SSL protocol with public key technology.

3. If authentication is successful, the LDAP server and the DCE security servernegotiate an algorithm to use for encryption and data integrity by means of theSSL protocol. The strongest algorithm supported by both parties is chosen.

4. Using the SSL session, the DCE security server issues a simple bind request tothe LDAP server. In this request, the DCE security server sends the LDAPserver the DN and user password specified in configuration or migration. TheDN and user password are protected using the negotiated encryption and dataintegrity algorithm.

5. If authentication is successful, the authenticated DCE security server has anauthenticated LDAP identity. This identity is the DN sent with the LDAP bindrequest.


6. The LDAP server and the DCE security server transmit additional information toeach other over the SSL session. All information is transmitted using thenegotiated encryption and data integrity algorithm.

Configuring an SASL CRAM-MD5 bind

Note: The SASL CRAM-MD5 bind is supported by IBM SecureWay Directory only.

An SASL CRAM-MD5 bind provides a method for the DCE security server toauthenticate its identity to the LDAP server through the use of a DN andCRAM-MD5. This method does not protect the privacy and integrity of thetransmitted data. However, a clear text password is not transmitted.

Perform the following steps to configure a simple bind:

1. Determine if the LDAP server can accept SASL bind requests with theCRAM-MD5 mechanism. If it cannot accept SASL CRAM-MD5 bind requests,you cannot use this method.

2. Configure a method of protecting the privacy of the userPassword attribute.Valid methods are clear text or a two-way encryption algorithm.





-auth_type -ldap_auth cram-md5




After you configure an SASL CRAM-MD5 bind, the DCE security server performsthe following steps to establish a secure transmission with the LDAP server:

1. The DCE security server issues an LDAP SASL bind with CRAM-MD5mechanism request. In this request, the DCE security server sends the LDAPserver the DN and user password specified during migration or configuration.

2. The DCE security server and the LDAP server use the CRAM-MD5 protocol toprove that they both know the clear text user password value without actuallysending the value over the network. During this challenge and response, bothservers are able to authenticate each other’s identities.

3. If authentication is successful, the DCE security server has an authenticatedLDAP identity. This identity is the DN that was sent with the LDAP bind request.

4. The DCE security server and the LDAP server transmit information to eachother. All information is transmitted in clear text with no data integrity protection.


Configuring an SASL CRAM-MD5 bind with SSL

Note: The SASL CRAM-MD5 bind with SSL is supported by IBM SecureWayDirectory only.

The SASL CRAM-MD5 bind with SSL authentication method combines the SASLCRAM-MD5 bind method with the SSL protocol. It provides a method for the DCEsecurity server to authenticate its identity to the LDAP server through the use of anLDAP DN and password. It also provides a public key method for the LDAP serverto authenticate its identity to the DCE security server and to ensure data privacyand integrity during transmission.

Perform the following steps to configure an SASL CRAM-MD5 bind with SSL:

1. Determine if your LDAP server can accept requests to an SSL port for aserver-authenticated SSL session. Also determine if the LDAP server can acceptrequests for an SASL CRAM-MD5 bind while in the SSL session. If your LDAPserver does not meet both of these conditions, you cannot use the SASLCRAM-MD5 bind with SSL authentication method.

2. Configure your LDAP server so that it can accept server-authenticated SSLrequests.

3. If your LDAP server supports it, configure a method of protecting the privacy ofthe userPassword attribute. Valid methods are clear text or a two-wayencryption algorithm.

4. Configure an SSL key database file containing the certificate of your LDAPserver on the machine containing the DCE security server.








-ssl -ldap_ssl none

-keyring -ldap_keyring key database filename



After you configure an SASL CRAM-MD5 bind with SSL, the DCE security serverperforms the following steps to transmit data to the LDAP server:

1. The DCE security server requests a server-authenticated SSL session with theLDAP server.

2. The DCE security server authenticates the identity of the LDAP server bymeans of the SSL protocol with public key technology.


3. If authentication is successful, the LDAP server and the DCE security servernegotiate an algorithm to use for encryption and data integrity by means of theSSL protocol. The strongest algorithm supported by both parties is chosen.

4. The DCE security server uses the SSL session to issue an LDAP SASL bindwith CRAM-MD5 mechanism request. In this request, the DCE security serversends the LDAP server the DN and user password specified during migration orconfiguration. The DN and user password are protected using the negotiatedencryption and data integrity algorithm.

5. If authentication is successful, the authenticated DCE security server has anauthenticated LDAP identity. This identity is the DN sent with the LDAP bindrequest.

6. The LDAP server and the DCE security server transmit additional information toeach other over the SSL session. All information is transmitted using thenegotiated encryption and data integrity algorithm.

Configuring an SASL SSL bindThe SASL SSL authentication method provides a strong way for the DCE securityserver to authenticate its identity to the LDAP server through the use of the SSLprotocol with public key technology. The LDAP server also authenticates its identityto the DCE security server using the SSL protocol with public key technology. Thismethod also provides for data privacy and integrity protection of protected data.

Perform the following steps to configure and SASL SSL bind:

1. Determine if your LDAP server can accept requests for a client and serverauthenticated SSL session. Also determine if the LDAP server can acceptrequests for an LDAP bind using the external SSL mechanism while in the SSLsession. If your LDAP server does not meet both of these conditions, youcannot use the SASL SSL bind authentication method.

2. Configure your LDAP server so that it can accept requests for a client- andserver-authenticated SSL session.

3. On the machine containing the DCE security server, configure an SSL keydatabase file containing the X509 certificate of the LDAP server.

4. Use a Certificate Authority to obtain an X509 certificate and private key for theDCE security server.

5. On the machine containing the DCE security server, store the X509 certificateand private key for the DCE security server in the SSL key database file andassign a name to this X509 and private key pair.

6. In the key database file of the LDAP server, store the X509 certificate for theDCE security server.

7. Some LDAP servers, such as the iPlanet Directory Server Version 4, provide away of mapping an X509 certificate to a DN. If your LDAP server provides thiscapability, configure the mapping of the certificate to the DN as instructed in thedocumentation for your LDAP server.





-ssl -ldap_ssl none




-keyring -ldap_keyring key database file[:name ofX509/private key pair]



The DCE security server performs the following steps to establish a securetransmission with the LDAP server:

1. The DCE security server requests a client and server-authenticated SSL sessionwith the LDAP server.

2. The LDAP server authenticates its identity to the DCE security server by meansof the SSL protocol and public key technology.

3. If authentication of the LDAP server is successful, the DCE security serverauthenticates its identity to the LDAP server by means of SSL and public keytechnology.

4. If authentication of the DCE security server is successful, the DCE securityserver has an authenticated LDAP identity. Refer to the documentation providedwith your LDAP server to determine how your LDAP server determines thisidentity. The IBM SecureWay Directory Server uses the inverted Subject DN inthe X509 certificate as the identity. The iPlanet Version 4 Directory Server usesthe DN of a mapped directory entry, if configured, as the identity.

5. The DCE security server and the LDAP server negotiate an algorithm to use forencryption and data integrity by means of the SSL protocol. The strongestalgorithm supported by both parties is chosen.

6. The DCE security server and the LDAP server transmit all data over theprotected SSL session. All data is protected using the negotiated encryption anddata integrity algorithm.

Configuring DCE server entries in the LDAP directoryYou must configure DCE server entries in the LDAP directory if the DCE securityserver binds to the LDAP server using one of the following methods:

v Simple bind

v Simple bind with SSL

v CRAM-MD5 bind

v CRAM-MD5 bind with SSL

If you are using one of the listed bind methods, you must configure in the LDAPdirectory an entry with a userPassword attribute to represent the DCE securityserver. You can configure the entry using any structural object class and assign theentry any DN. If you configure the entry using a structural object class that does notcontain the userPassword attribute, you can use the KrbAuthObject auxiliary objectclass to add the userPassword attribute to the entry . The KrbAuthObject auxiliaryobject class is defined in the Kerberos LDIF files that are shipped with DCE.

The following is an example of two entries configured for two different DCE securityservers.

DN: serviceName=servera.deptabc.ibm.com, dc=deptabc, dc=IBM, dc=COMobjectclass: eServiceobjectclass: krbAuthObject


serviceName: servera.deptabc.ibm.com, dc=deptabc, dc=IBM, dc=COMuserPassword: mysecret3897250332

DN: serviceName=serverb.deptabc.ibm.com, dc=deptabc, dc=IBM, dc=COMobjectclass: eServiceobjectclass: krbAuthObjectserviceName: servera.deptabc.ibm.com, dc=deptabc, dc=IBM, dc=COMuserPassword: mysecret58293847821359

Configuring a realm entry in the LDAP directoryYou must configure an entry to represent the DCE security registry database. Thisentry is referred to as the realm entry. DCE uses this entry as the base for storingDCE security data. Do the following to configure the realm entry:

v Choose a location for the realm entry in the directory information tree (DIT). Thislocation must be serviced by trusted LDAP servers only. See “Additional securityconsiderations” on page 24 for more information.

v Assign the realm entry an RDN of krbRealmName-v2=realmname whererealmname is the name of the DCE cell without the preceding /.../. For example,if the name if the DCE cell is /.../artichoke_cell, configure artichoke_cell as therealmname.

v Use the KrbRealm-v2 structural object class and DCERealm auxiliary objectclass to configure the realm entry.

v Add the required krbRealmName-v2 attribute to the entry, and configure thisattribute with the same realm name that is in the RDN.

v Add the required krbPrincSubtree attribute to the realm entry, and configure thisattribute with a list of one or more DNs. Each DN represents a directory sub-treeentry under which DCE searches for DCE principal, DCE group, and DCEorganization data. Do the following to ensure the security of each DN specified inthe krbPrincSubtree:

– Make sure each DN resides in a directory location that can be serviced onlyby trusted LDAP servers.

– Make sure each DN can be protected with LDAP ACLs so that only trustedidentities can configure DCE attributes under the DN.

You also need to be sure that at least one DN in the krbPrincSubtree entry is theDN of the realm entry or a DN under which the realm entry resides. BecauseLDAP performs searches fastest when able to search an entire suffix, it isrecommended that you configure only the DNs of LDAP suffixes in the realmentry. However, you must not configure the DN of a suffix in the krbPrincSubtreeentry if any entries under the suffix are serviced by untrusted LDAP servers. Youalso must not configure the DN of a suffix in the krbPrincSubtree entry if the youcannot protect all entries residing under the suffix from untrusted identitiesconfiguring DCE attributes.

v Add the krbKdcServiceObject attribute to the realm entry, and configure thisattribute with the DN of each DCE security service entry.

v Add the krbTrustedAdmObject attribute to the realm entry, and configure thisattribute with the DN of each DCE security service entry.

In the following example the DN of the realm entry is ″krbRealmName-v2=realm1,ou=Austin″. This DN and the DN of ″cn=dept1, ou=Austin″ are the only DNsconfigured in krbPrincSubtree. Therefore, DCE searches only under the realm entry


and the ″cn=dept1, ou=Austin″ for DCE principals, groups, and organizations. Therealm contains two DCE servers: servera.deptabc.ibm.com andserverb.deptabc.ibm.com.

DN: krbRealmName-v2=realm1, ou=Austinobjectclass:KrbRealm-v2objectclass: KrbRealmExtkrbRealmName-v2: realm1krbPrincSubtree: krbRealmName-v2=realm1, ou=AustinkrbPrincSubtree: cn=dept1, ou=AustinkrbKdcServiceObject:

serviceName=servera.deptabc.ibm.com,dc=deptabc,dc=IBM,dc=COMkrbKdcServiceObject:

serviceName=serverb.deptabc.ibm.com,dc=deptabc,dc=IBM,dc=COMkrbTrustedAdmObject:

serviceName=servera.deptabc.ibm.com,dc=deptabc,dc=IBM,dc=COMkrbTrustedAdmObject:

serviceName=serverb.deptabc.ibm.com,dc=deptabc,dc=IBM,dc=COM

Configuring LDAP access controlYou must use the access control mechanisms offered by your LDAP server toprotect all entries in the LDAP directory that the DCE security servers in your celluse for storing and retrieving data. DCE attributes can reside in the following LDAPentries:

Realm entryThe DCE security servers store and retrieve data defining the DCE registry,DCE registry properties, and DCE registry policy in this entry.

Entries under the realm entryIn these entries, the DCE security servers store and retrieve data definingthe DCE master key, the DCE registry log, DCE extended registry attribute(ERA) definitions, DCE ACLs, and DCE replication lists.

Entries under the realm entry and each sub-tree referenced by thekrbPrincSubtree attribute of the realm entry

In these entries, the DCE security servers store and retrieve data definingDCE principals, DCE groups, DCE organizations, DCE directories, and anyDCE ACLs and DCE ERAs associated with these objects.

The following sections give recommendations on how to configure access controlon these entries. These recommendations assume you use only DCE interfaces toconfigure in the LDAP directory the registry data for your DCE cell. Duringmigration, DCE interfaces are the only supported method to configure DCE registrydata in the LDAP directory.

After your cell is fully migrated to LDAP, you might want to modify the accesscontrol configuration so that other trusted identities can configure selected registrydata for your DCE cell in the LDAP directory. If so, carefully evaluate the Kerberosand DCE schemas used by DCE so that you do not configure permissions thatcould compromise the security of your DCE cell.

The Kerberos and DCE schemas are listed in Appendix B and in the LDIF schemafiles that are shipped with DCE. When you determine which attributes must beprotected for access control, it is important that you have a complete list of allattributes defined in the Kerberos and DCE schemas. Therefore, it is recommendedthat you refer to the shipped LDIF Kerberos and DCE schema files rather than


Appendix B for this information because the shipped files might contain last minutechanges. It also is recommended that you refer to the Readme file for last minutechanges to the schema.

Configuring access control for the realm entry and entries underthe realm entryConfigure propagation access control for the realm entry that gives all DCE securityservers in the cell permission to do the following:

v Add child entries to the current entry

v Delete the current entry

v Perform write, read, search, and compare operations on attributes defined in anyof the object classes that are included in the Kerberos and DCE schemas.

v Perform write, read, search, and compare operations on the membership and cnattributes

If desired, you can give other identities permission to perform read and searchoperations on attributes defined in most of the object classes included in theKerberos and DCE schemas. However, it is critically important that you not give anyidentity other than the DCE security servers in the cell permission to read orcompare attributes defined in the following object classes:

v Attributes defined in the KrbMstrKey object class

v Attributes defined in the KrbKey object class

Configuring access control for entries under referenced sub-treeentriesFor each referenced sub-tree, either configure propagation access control or add tothe existing propagation access control configuration. The propagation accesscontrol configuration needs to give all DCE security servers in the cell permission todo the following:

v Add child entries to the current entry

v Delete the current entry

v Perform write, read, search, and compare operations on all attributes defined inthe following object classes.

– KrbPrincipal

– DCEPrincipal

– KrbPolicy

– DCEPolicy

– DCEOrg

– DCEGroup

– DCEERA

– KrbKey

– KrbLog

– DCELog

– DCEUniqueID

– DCEUNIX

– DCEDir

– DCEACL

v Perform write, read, search, and compare operations on the membership and cnattributes


If desired, you can give other identities permission to perform read and searchoperations on attributes defined in any of the previously mentioned object classesexcept for KrbKey. It is critically important that you not give any identity other thanthe DCE security servers in the cell permission to read attributes defined in theKrbKey object class.

Additional security considerationsThe following are additional security considerations:

v If your LDAP server replicates data to other LDAP servers, it is important that thisgroup of LDAP servers be configured to use a strong protocol to authenticatetheir identities to each other, and that they use strong algorithms to protect dataduring transmission.

v The root administrator of your master LDAP server and the root administrators ofall replica LDAP servers have complete access to all data in the LDAP directory.Therefore, the LDAP root administrators must be trusted in your DCE cell. If theLDAP root administrators cannot be trusted, it is recommended that youconfigure different instances of your LDAP servers for use by your DCE cell, andassign trusted LDAP root administrators to these new instances of LDAP servers.

v The LDAP servers are part of the trusted computer base for your DCE cell. It isrecommended that you physically protect the master LDAP server and keep it ina locked room.

v If the DCE security server binds to the LDAP server with a user password,configure a user password value that is difficult to guess and change this valuefrequently.

v If a strong LDAP bind protocol is desired and the LDAP servers cannot beconfigured to support this protocol, it is recommended that the LDAP rootadministrator set up the realm entry as a referral to a different LDAP server,which can support the strong LDAP bind protocol.

v If your LDAP servers use back-end databases, you must evaluatecommunications between the LDAP servers and the back-end databases and theprotection mechanisms offered by the back-end databases.

v If auditing is required, you must enable both DCE and LDAP auditing.


Chapter 3. Configuration and Migration

This chapter describes the different types of LDAP security servers and outlines thesteps you use to migrate the DCE security registry to an LDAP directory. It alsoprovides steps for the configuring and unconfiguring of LDAP security servers.

LDAP security serversThere are three different LDAP security servers. Like the legacy security model, theLDAP security model has both master security servers and slave security servers.There is also a special type of LDAP server that is called an LDAP migrationsecurity server.

LDAP migration security serverThe LDAP migration security server (migration server) is a special type of slavesecurity server that is used to migrate the legacy DCE security registry to LDAP.Security data is initially migrated from a legacy replica to the migration server thesame way security data is migrated to a legacy replica. When initialized, themigration server receives updates from the legacy master’s propagation queue. Themigration server writes updates to LDAP to keep it in sync with the legacy master inthe cell. In all other ways the migration server operates as a slave security serverthat reads data from LDAP instead of from local files or an in-memory copy of thesecurity registry. Figure 3 shows the migration server configuration.

The migration server does not have a local registry. When clients request securitydata, the migration server retrieves it from the LDAP directory instead of retrieving itfrom an in-memory security database. The migration server does not maintain anupdate_log file for data that it is unable to write to LDAP. Instead, it returns errors tothe master security server. The legacy master continues to try to update themigration server until it is successful.

After you have a migration server in a cell, DCE continues to use the legacy DCEpreference rules for accessing security data. This means that even though you havea migration server in a cell, it is not automatically the preferred server for readingsecurity data.

Mastersecurityserver

LDAPmigrationsecurityserver

LDAPDirectory

Memory

registry and

prop queue

Rgy_datafiles

Update_log

Updates written toupdate_log

Updateswritten toand dataread fromLDAPDirectory

Updates written tomemory registry andprop queue

Registry datais read fromdisk whensecd starts

Checkpointwrites memoryregistry to disk

Prop queuethread pushesupdates toreplicas

Figure 3. LDAP migration security server


To maintain the current security model of one read/write server and multipleread-only replicas, only one server can send updates to LDAP. This means thatthere can be only one migration server in a cell.

After it is configured, the migration server cannot be moved. If you decide thisserver should not be the migration server, unconfigure it and identify a newmigration server. After the migration server is unconfigured, LDAP still contains DCEsecurity data. This data should be removed.

LDAP master security serverThe LDAP master security server is a read/write master security server. The LDAPsecurity master reads from and writes to LDAP for all registry data. It does notmaintain an in-memory registry, an update_log file, or a propagation queue. Afteryou are satisfied with the stability of your cell using the LDAP migration server andLDAP slave security servers, migrate the legacy master to the LDAP securitymaster. If you are unable to migrate the legacy master to the LDAP security masterbecause the legacy master is down or because DCE cannot be upgraded to IBMDCE 3.2, you can force the migration server to become the LDAP security master.However, it is recommended that the legacy master become the LDAP securitymaster because there is a potential for data loss when you force the migrationserver to become the LDAP security master because updates from the mastersecurity server might be pending.

After the LDAP security master is migrated, the migration server becomes an LDAPsecurity slave. This insures that there is only one DCE security server that writes toLDAP.

After you convert the legacy master to an LDAP security master, there is no way torevert back to the legacy security function.

LDAP slave security serverThe LDAP slave security server is a read-only replica. The primary differencebetween a legacy slave and an LDAP security slave is that the LDAP security slavedoes not have a local registry or maintain an update_log file. It also does notreceive updates from the master’s propagation queue. Instead it reads security datafrom the LDAP directory as required. However, if a legacy master is sendingupdates to the LDAP security slave, the LDAP security slave acts as though it isupdating and indicates to the master that it is up-to-date.

Figure 4 shows the LDAP security master and slave security servers.

Security server migrationThis section gives a brief outline of the steps you use to migrate the securityregistry to an LDAP directory. Specific migration steps follow the migration overview.

LDAPmastersecurityserver

LDAPslave

securityserver

LDAPDirectoryUpdates

written toand read

from LDAPDirectory

Reads datafrom LDAPDirectory

Figure 4. LDAP security master and LDAP security slave servers


Allowed migration scenariosDCE Security Registry and LDAP Integration supports certain migration scenariosonly. For example, you cannot migrate the legacy master to be the migration server.Table 2 summarizes the migration scenarios that are allowed when you migratelegacy and LDAP security servers. It also shows the type of command (migrate ordesignate) that is required. Use the dcecp registry designate and dcecp registrymigrate commands to change the server roles.

Table 2. Allowed migration scenariosFrom To TypeLegacy master Legacy slave DesignateLegacy master LDAP security master MigrateLegacy slave Legacy master DesignateLegacy slave LDAP security slave MigrateLegacy slave LDAP migration server MigrateLDAP security slave LDAP security master DesignateLDAP security master LDAP security slave DesignateLDAP migration server LDAP security master Force MigrateLDAP migration server LDAP security slave Migrate**The LDAP migration server is automatically migrated to an LDAP security slave when thelegacy master is migrated to an LDAP security master.

The .ldap_data fileWhen you migrate a legacy slave to an LDAP migration server, the dcecp registrymigrate command uses the options you specify to create a .ldap_data file. This filecontains information about the following registry migrate options:

v -ssl

v -auth_type

v -bind_dn

v -bind_dn_pw

v -keyring

v -keyring_pw

v -ldap_host

v -master_key_in_ldap

v -dce_master_key

Before performing a migration to an LDAP security slave or an LDAP securitymaster, the registry migrate command checks for a .ldap_data file in the/opt/dcelocal/var/security/ldap_data directory.

When you migrate to the migration server by using the dcecp registry migrate-migrationslave command, you must enter all of the parameters required for thecommand. The values you enter are used to create the .ldap_data file.

After the migration server is in place, you can copy the .ldap_data file to anymachine you are migrating to an LDAP security slave or LDAP security master.When you specify -ldapslave or -ldapmaster without any LDAP connectionparameters, the registry migrate command checks for the .ldap_data file and usesthe values contained in the file. However, if you enter any of the parameterscontained in the .ldap_data file, on the registry migrate command line, the.ldap_data file is not used and the normal parameter requirements apply.

Chapter 3. Configuration and Migration 27

For example, if you copied the .ldap_data file from the migration server to asecurity replica that is to become an LDAP slave, the replica can be migrated usingthe following command:dcecp -c registry migrate -ldapslave

If you copy a .ldap_data file from another system, be sure that you also copy anyfiles that are listed in the .ldap_data file.

Overview of migrationThe DCE security registry is migrated to an LDAP directory in a series of steps.First, one legacy slave is migrated to an LDAP migration server. Then each legacyslave is migrated to an LDAP security slave and the registry version number israised. Finally, the legacy master is migrated to an LDAP security master.

In addition to the master security server, it is recommended that there be twolegacy security slaves in the cell during migration. One legacy slave becomes theLDAP migration server and initially migrates all the registry information to LDAP.The other legacy slave initializes the migration server, relieving the master securityserver of this task.

You must be authenticated as cell_admin to perform registry migrate commands.

Before you migrateTo ensure a successful migration to LDAP, verify that the following conditions havebeen met before beginning migration:

v DCE 3.2 is installed on all server machines that you are migrating.

v There are at least two legacy slaves in the cell you are migrating.

v The LDAP client package is installed on all server machines you are migrating.

v The master key is available to each security server you are migrating.

All LDAP security servers must have access to the same master key file. If youstore the master key in LDAP (by specifying the -master_key_in_ldap flag whenyou migrate), it is automatically available to all security servers. However, if youstore the master key in a file, you must copy the key file to each server. Thedefault location is the local filesystem in /opt/dcelocal/var/security/.mkey. Priorto migrating a legacy security server to LDAP, make a backup copy of theexisting .mkey file on the server and then copy the common master key file tothe local filesystem. To specify an alternate location for the key file, use the-dce_master_key flag when you migrate the server.

Ensure that the master key is secure. The legacy DCE implementation sets thepermissions on the master key so it is accessible as read/write by root only.

v The administrator has set LDAP ACLs on the DCERealm and KrbMstrKeyobjects.

v The LDIF file for the DCE related schema has been installed on LDAP serversthat will serve DCE security servers.

v The krbRealm for the DCE cell has been created in LDAP.

v There are one or more entries configured in LDAP to represent the DCE securityservers in the realm. The DCE security servers use these entries to bind toLDAP.

v The SEC_REP_INIT_FROM_UUID has been set to allow one of the legacyslaves to initialize the legacy slave that is being migrated to the migration server.This allows the master server to continue accepting updates during initialization.


Recommended migration scenarioThis section provides a broad overview of the steps you use to migrate the legacyDCE security registry to an LDAP directory. More specific information about themigration steps follows.

Perform the following steps to migrate the legacy DCE security registry to an LDAPdirectory:

1. Set the SEC_REP_INIT_FROM_UUID environment variable on the mastersecurity server machine with the UUID of a legacy replica that will initialize theLDAP migration server.

2. Use the dcecp -c registry migrate -migrationslave command to convert onelegacy slave into an LDAP Migration security server. See the section titled“Migrating a legacy slave to a migration server” on page 31 for more informationabout this command.

After you perform this step, the migration server migrates all the registryinformation to the LDAP directory. For more information about the migrationserver see the section titled “LDAP migration security server” on page 25.

The DCE cell can continue to operate in this state for an indefinite period.However, it is recommended that you migrate the security servers to LDAP onceyou are comfortable with the performance and stability of the cell. If you do notcomplete the migration of all the security servers, any changes made to theLDAP database using LDAP interfaces are not passed to the legacy master orany legacy slaves.

After you are sure that the security data stored in LDAP is correct and is in syncwith the legacy master’s security data, move on to the next step.

If there is a problem at this stage, unconfigure the migration server and removeany extraneous data from LDAP.

3. Use the dcecp -c registry migrate -ldapslave command to convert all legacyslaves into LDAP security slaves. See “Migrating a legacy slave to an LDAPsecurity slave” on page 32 for more information about performing this step.

After you convert the legacy slaves to LDAP, they no longer have a localdatabase and no longer process the propagations from the legacy master.When they receive requests from clients, they retrieve the data from LDAP.

Although it is strongly recommended that you continue the migration process, itis not mandatory. The cell can remain in this state with a migration server and alegacy master for an undetermined amount of time. However if you do notcontinue migration, any changes made to the LDAP database using LDAPinterfaces do not get passed to the legacy master. Therefore, if you do notcontinue the migration process, you can only retrieve data that is updatedthrough LDAP interfaces from the migration server or an LDAP security slave.

If there is a problem at this stage unconfigure the LDAP security slaves.

4. Unconfigure all security servers that have not been migrated to LDAP.

5. Use the dcecp -c registry modify -version secd.dce.1.3 command to raisethe registry version to secd.dce.1.3.

This only works if the legacy master is running DCE 3.2. To ensure that alldownlevel servers shut down, issue any command that updates the registrydatabase. When the master attempts to propagate the update, all downlevelservers shut down. Although this insures that all downlevel servers shut down, itdoes not insure that all level 3.2 security servers have been migrated to LDAP.

Note: The registry version can be raised only one level at a time. If it iscurrently at 1.2.2, it must be raised to 1.2.2a before it is raised to 1.3.


6. Use the dceback command to back up legacy DCE security data on the legacymaster. To do this, enter the following at the command prompt:dceback dumpsecurity -destfile <destfile>dceback dumpmisc -destfile <destfile2>

7. Use the dcecp -c registry migrate -ldapmaster command to convert thelegacy master into an LDAP security master. For more information aboutperforming this step see “Migrating a legacy master to an LDAP securitymaster” on page 34

Attention: After you convert the legacy master to an LDAP security master,there is no way to revert back to the legacy security function.

After you perform this step, the LDAP security master writes security data toLDAP (rather than to memory and local databases), and the migration serverbecomes an LDAP security slave. Any DCE 3.2 security servers that have notbeen migrated to LDAP no longer receive updates from the master and must beunconfigured. Replicas that do not receive updates return outdated informationto clients.

The legacy master can be converted to an LDAP security master even if all thelegacy slaves in the cell have not been converted to LDAP security slaves.

If the migration to the LDAP security master fails, run the following commands:stop.dcedceback restoremisc -sourcefile <misc_backup_file>dceback restoresecurity -sourcefile <sec_backup_file>start.dce

Alternate migration scenarioInstead of converting the legacy master to an LDAP security master, the alternatemigration scenario forces the LDAP migration server to become the LDAP securitymaster. Use force migration when it is impossible to upgrade the legacy master toDCE 3.2 or when the legacy master is not working. If possible, convert a DCE 3.2legacy security server to the master and follow the recommended migration stepsinstead of using the force option.

There is a potential for problems to occur if you do not follow the steps in thismigration scenario exactly. For example, it is possible that the cell will be left withtwo masters (the legacy master and the LDAP security master). Make sure that youfollow the steps carefully so that there will only be one master security server.

The force option does not insure that the LDAP database is up-to-date. Unlike therecommended migration scenario, the force migration scenario automatically raisesthe registry version to 1.3. You do not have to manually raise the registry version.However, because the LDAP security master does not propagate to slaves, theexisting downlevel security servers do not automatically shut down.

This section provides a broad overview of the steps you use to force a migration toLDAP. More specific information about the migration commands follows.

Perform the following steps to force a migration to LDAP:

1. Perform “steps 1-4 from the recommended migration scenario” on page 29.

2. Stop the legacy master security server.

3. Use the dcecp -c registry modify -version secd.dce.1.2.2 command to raisethe registry version to secd.dce.1.2.2. After migration, the LDAP master securityserver automatically raises the registry version from 1.2.2 to 1.3


4. Use the dcecp -c registry migrate -ldapmaster -force command to force themigration server to become the LDAP security master. For more informationabout performing this step see “Forcing the migration server to become theLDAP security master” on page 35.

Attention: After you issue this command, you cannot convert the migrationserver back to a legacy slave. Because this server was the migration server, itcontinues making updates to LDAP. However, it no longer propagates updatesto non-migrated slave replicas. Any unmigrated replicas do not receive updatesand must be unconfigured from the cell. If you do not unconfigure them, theywill have stale data.

After you perform this step, the LDAP security master begins to write data toLDAP, and legacy slaves no longer receive updates.

You are allowed to force the migration server to become the LDAP securitymaster even if all the legacy slaves in the cell have not been converted to LDAPsecurity slaves or if some of the legacy slaves have been unconfigured from thecell. However, because updates are no longer propagated from the master, anyremaining legacy slaves will have stale data. If there are any replicas runningDCE 3.2 that were not migrated, they must be migrated or they will not receiveupdates.

5. If the legacy master is still configured, unconfigure it. Perform the followingsteps to unconfigure the legacy master.

a. Perform a local unconfiguration on the legacy master by entering thefollowing command:unconfig.dce -config_type local -force sec_srv

b. Remove all entries for the local machine from the/opt/dcelocal/etc/security/pe_site file.

c. Perform an admin unconfiguration on the legacy master from anothermachine on the cell. Enter the following on the selected machine’s commandline:unconfig.dce -config_type admin -dce_hostname <leg_master_dce_hostname>-host_id <leg_master_host_id> sec_rep

If you do not unconfigure the legacy master, there will be two master securityservers in the cell (the legacy master and the new LDAP security master). Thiscauses unpredictable results and ultimately corrupts the database.

6. Unconfigure all DCE security servers that have not been migrated to LDAP.

Migrating a legacy slave to a migration serverYou can migrate a legacy replica to a migration server from the command line, oryou can use smitty on AIX. Whichever method you use, you must perform the stepson the machine you are migrating.

Migrating a legacy slave to a migration server from a commandlineEnter the following command at a command prompt to migrate a legacy slave to amigration server :dcecp> registry migrate -migrationslave-ldap_host <hostname:port |"list of hostnames"> -bind_dn <bind_dn>-bind_dn_pw <bind_dn_pw> [-ssl {-auth_type <ssl | cram-md5>} |-auth_type <simple | ssl | cram-md5>] [-keyring <ldap_keyring_file>][-keyring_pw <ldap_keyring_pw>] [-master_key_in_ldap][-dce_master_key <dce_master_key_file>] [-delete_type <all | krb_dce | dce>]dcecp>


Migrating a legacy slave to a migration server from smitty (AIXonly)To migrate a legacy slave to a migration server using smitty, perform the followingsteps on the machine that is designated as the LDAP security master:

1. Start smitty as root with fastpath:

smitty dcepol

or perform the following sequence of smitty menu options:

1. Communication Applications and Services2. DCE (Distributed Computing Environment)3. DCE Security & Users Administration4. Registry Policies and Properties

2. Select Migrate Local Security Server to LDAP, and press <Enter>.

3. Select Migrate Local Security Replica Server to an LDAP MigrationReplica Server, and press <Enter>.

4. Enter the LDAP directory server hostname or hostname:port pair in the LDAPSERVER Information List field. You can enter a single value or a list ofhostnames and hostname:ports.

5. Enter the DN the security server uses to bind to the LDAP server in the LDAPDISTINGUISHED NAME field.

6. Enter the password of the DN the security server uses to bind to the LDAPserver in the LDAP DISTINGUISHED NAME Password field.

7. Press <F4> in the LDAP AUTHENTICATION Method field for a list ofauthentication methods. Valid methods are simple, SSL, and cram-md5.Simple is the default. Select the appropriate authentication method, and press<Enter>.

8. Press <Tab> to select Yes or No in the Use SSL Communication? field.

9. Enter the pathname for the keyring file in the LDAP KEYRING file field if youare using SSL communication. If you do not enter a value, SSL uses thedefault keyring file ($LDAPHOME/lib/ldapkey/.kdb).

10. Enter the keyring password in the LDAP KEYRING Password field if you areusing SSL communication. If you do not enter a value, SSL uses the passwordthat is encrypted in the appropriate password stash file.

11. Press <Tab> to select yes or no in the Store DCE Master Key in LDAP fieldto indicate if the DCE Master Key is being stored in LDAP. The default is no.

12. If the DCE master key is not going to be stored in LDAP, enter thefully-qualified path for the master key in the DCE Master Key file field. Thedefault location is /opt/dcelocal/var/security/.mkey.

13. Press <F4> in the DCE/LDAP Deletion Policy field for a list of deletionpolicies. Valid policies are all, DCE and Kerberos, and DCE. The default is all.

14. Press <Enter> to select Do.

15. Enter the cell administrator’s password when prompted.

Migrating a legacy slave to an LDAP security slaveYou can migrate a legacy slave to an LDAP security slave from a command line, oryou can use smitty on AIX. Whichever method you use, you must perform the stepson the machine that you are migrating.


Migrating a legacy slave to an LDAP security slave from acommand lineEnter the following command at a command prompt to migrate a legacy slave to anLDAP security slave:dcecp> registry migrate -ldapslave-ldap_host <hostname:port |"list of hostnames"> -bind_dn <bind_dn>-bind_dn_pw <bind_dn_pw> [-ssl {-auth_type <ssl | cram-md5>} |-auth_type <simple | ssl | cram-md5>] [-keyring <ldap_keyring_file>][-keyring_pw <ldap_keyring_pw] [-master_key_in_ldap][-dce_master_key <dce_master_key_file>]dcecp>

Note: If you are using a .ldap_data file, you do not need to enter any of theregistry migrate connection parameters. For more information about the.ldap_data file, see “The .ldap_data file” on page 27.

Migrating a legacy slave to an LDAP security slave from smitty(AIX only)To migrate a legacy slave to an LDAP security slave from smitty, perform thefollowing steps on the machine that is designated as the LDAP master securityserver:


smitty dcepol




3. Select Migrate Local Security Replica Server to an LDAP Replica Server,and press <Enter>.

4. Enter the LDAP directory server hostname or hostname:port pair in the LDAPSERVER Information List field. You can enter a single value, or you canenter a list of hostnames and hostname:port pairs.












Migrating a legacy master to an LDAP security masterYou can migrate a legacy master to an LDAP security master from a command line,or you can use smitty on AIX. Whichever method you use, you must perform thesteps on the machine that you are migrating.

After you convert the legacy master to an LDAP security master, there is not a wayto revert back to the legacy security function. Make sure that you are ready to runusing only LDAP before you migrate the master security server.

Migrating a legacy master to an LDAP security master from acommand lineEnter the following command at a command prompt to migrate a legacy master toan LDAP security master:dcecp> registry migrate -ldapmaster [-force]-ldap_host <hostname:port |"list of hostnames"> -bind_dn <bind_dn>-bind_dn_pw <bind_dn_pw> [-ssl {-auth_type <ssl | cram-md5>} |-auth_type <simple | ssl | cram-md5>] [-keyring <ldap_keyring_file>][-keyring_pw <ldap_keyring_pw>] [-master_key_in_ldap][-dce_master_key <dce_master_key_file>][-delete_type <all | krb_dce | dce | no_delete]dcecp>

Note: If you are using a .ldap_data file, you do not need to enter any of theregistry migrate connection parameters. For more information about the.ldap_data file, see “The .ldap_data file” on page 27.

Migrating a legacy master to an LDAP security master fromsmitty (AIX only)To migrate a legacy master to an LDAP security master from smitty, perform thefollowing steps on the machine that is designated as the LDAP master securityserver:


smitty dcepol




3. Select Migrate Local Master Security Server to an LDAP Master SecurityServer, and press <Enter>.

4. Enter the LDAP directory server hostname or hostname:port pair in the LDAPSERVER Information List field. You can enter a single value, or you canenter a list of hostnames and hostname:port pairs.










13. Press <F4> in the DCE/LDAP Deletion Policy field for a list of deletionpolicies. Valid policies are all, DCE and Kerberos, DCE, and No delete. Thedefault is all.



Forcing the migration server to become the LDAP security masterYou can force the migration server to become the LDAP security master from acommand line, or you can use smitty on AIX. Whichever method you use, you mustperform the steps on the machine that you are migrating to the LDAP securitymaster.

Because there is a potential for data loss, force the migration server to become theLDAP security master only when it is impossible to upgrade the legacy master toDCE 3.2 or when the legacy master is not working. After you force the migrationserver to become an LDAP security master, you cannot convert it back to a legacyslave.

Force migrating from a command lineEnter the following command at a command prompt to force the migration server tobecome an LDAP master security server:dcecp> registry migrate -ldapmaster -force-ldap_host <hostname:port |"list of hostnames"> -bind_dn <bind_dn>-bind_dn_pw <bind_dn_pw> [-ssl {-auth_type <ssl | cram-md5>} |-auth_type <simple | ssl | cram-md5>] [-keyring <ldap_keyring_file>][-keyring_pw <ldap_keyring_pw>] [-master_key_in_ldap][-dce_master_key <dce_master_key_file>][-ldapdeleteype <all | krb_dce | dce | no_delete>]dcecp>

Force migrating from smitty (AIX only)To force a migration server to become the LDAP security master from smitty,perform the following steps on the machine that is designated as the LDAP mastersecurity server:



smitty dcepol




3. Select Migrate Local LDAP Migration Server to an LDAP Master SecurityServer, and press <Enter>.

4. Enter the LDAP directory server hostname or hostname:port pair in the in theLDAP SERVER Information List field. You can enter a single value or a list ofhostnames and hostname:port pairs. If you enter a list, the list must beenclosed by quotation marks (″″).





9. Enter the pathname for the keyring file in the LDAP KEYRING file field if youare using SSL communication. If you do not enter a value, SSL uses thedefault keyring file ($LDAPHOME/lib/ldapkey/.sth).




13. Press <F4> in the DCE/LDAP Deletion Policy field for a list of deletionpolicies. Valid policies are all, DCE and Kerberos, DCE, and No delete. Thedefault is all.



Raising the version of the security registryTo raise the version number of the security registry to secd.dce.1.3, enter thefollowing at the command prompt:dcecp> -c registry modify -version secd.dce.1.3dcecp>

You cannot raise the registry version if the legacy master is not running DCE 3.2.After you change the security server version, all security servers that are notrunning DCE 3.2 automatically shut down.


Note: The registry version can be raised only one level at a time. If it is currently at1.2.2, it must be raised to 1.2.2a before it is raised to 1.3.

Configuring LDAP security serversThis section describes how to configure and unconfigure LDAP security servers.You can migrate an existing security server to be an LDAP master security serveror an LDAP migration security server. You can migrate an existing slave to be anLDAP security slave after migrating another slave to the LDAP migration server. Youcan configure an LDAP security slave after either the migration server or legacymaster has been migrated to be the LDAP security master.

You can configure an LDAP security slave from a command line, or you can usesmitty on AIX. Whichever method you use, you must perform the steps on themachine that you are migrating to the LDAP security slave.

Configuring an LDAP security slave from a command lineEnter the following command at a command prompt to configure an LDAP securityslave:config.dce [-sec_server_name <security_server>] [-cell_name <cell_name>][-cell_admin <cell_admin id>] [-admin_pwd <password>][-sec_master <master_security_server>] [-cds_server <cds_server>][-autostart <yes | no>] [-clean_autostart <yes | no>] [-protocol <tcp udp>][-time_server <server_id>] [-sync_clocks <yes | no>][-certificate_based_login <yes | no>] [-kdc_profile <kdc_profile>][-kdc_ini_file <kdc_ini_file>] [-kdc_passphrase <kdc_passphrase>][-group_rsp_path <filename>] [-rsp_file <filename>][ldap_auth <simple | ssl | cram-md5>] [-ldap_dn <ldap_dn>][-ldap_dn_pw <ldap_dn_pw>] [-ldap_keyring <ldap_keyring_file>][-ldap_keyring_pw <ldap_keyring_pw>] [-ldap_ssl <yes | no>][-ldap_registry] [-ldap_master_key_in_ldap <yes | no>][-ldap_dce_master_key <dce_master_key_file>][-ldap_server <ldap_server | ldap_server:port_number>]sec_rep

For more information about the config.dce command, consult IBM DCE Version 3.2for AIX and Solaris: Administration Commands Reference.

Configuring an LDAP security slave from smitty (AIX only)Perform the following steps to configure an LDAP security slave using smitty:

1. As root, start smitty with mkdcesrv fastpath:

smitty mkdcesrv


1. Communication Applications and Services2. DCE (Distributed Computing Environment)3. Configure DCE/DFS4. Configure DCE/DFS Servers

2. Select the SECURITY Server option, and press <Enter>.

3. Select the secondary option, and press <Enter>.

4. If you are not using the default cell_admin, enter the name of the celladministrator’s account at the Cell ADMINISTRATOR’s account prompt.

5. If you want to give the security replica a name, enter your choice in theSecurity Server name field. If you do not specify a name, the default is the


dce_hostname of the machine. Use the default unless you are completely surethat the name you specify is unique throughout the entire cell.

6. Press <Tab> to select yes in the Use LDAP to store security informationfield.

7. Enter the names of the LDAP servers or LDAP servers and ports to use in theLDAP SERVER Information List field.

8. Enter the distinguished name used to authenticate in LDAP in the LDAPDISTINGUISHED NAME field.

9. Enter the password for the LDAP distinguished name in the LDAPDISTINGUISHED NAME Password field.

10. Press <Tab> to select the LDAP authentication method in the LDAPAUTHENTICATION Method field. Valid values are simple, ssl, and cram-md5.The default is simple.

11. Press <Tab> to select yes or no in the Use SSL Communication field toindicate if SSL communication is being used to communicate between DCEand LDAP.

12. Enter the pathname for the keyring file in the LDAP KEYRING file field if youare using SSL communication. If you do not enter a value, SSL uses thedefault keyring file ($LDAPHOME/lib/ldapkey/.sth).


14. Press <Tab> to select yes or no in the Store DCE Master Key in LDAP fieldto indicate if the DCE Master Key is stored in LDAP. The default is no.

15. If the DCE master key is not going to be stored in LDAP, enter thefully-qualified path for the master key file in the DCE Master Key file field. Thedefault location is /opt/dcelocal/var/security/.mkey.

16. Press <Tab> to select yes or no in the Use Certificate based login field toindicate that PK certificate authentication should be enabled.

17. If PK certificate authentication is to be used, enter the fully-qualified path forthe file containing the ENTRUST PROFILE for the security server.

18. If PK certificate authentication is to be used, enter the fully-qualified path forthe ENTRUST INITIALIZATION file.

19. If PK certificate authentication is to be used, enter the ENTRUST PROFILEpassword for the DCE security server.

20. If the machine is already configured as a client, all other fields are filled in. Ifthe machine is not already configured as a client, specify the TCP/IPhostnames of the Master Security Server and of the central directory server(CDS) Server.


22. When prompted, enter the cell administrator’s password.

Unconfiguring LDAP security serversThe steps for unconfiguring an LDAP security server are the same steps forunconfiguring a legacy security server. You can unconfigure either type of securityserver without indicating which type of security server you are unconfiguring. Formore information about unconfiguring security servers, see the IBM DCE Version3.2 for AIX: Quick Beginnings, the IBM DCE Version 3.2 for Solaris: QuickBeginnings, or the IBM DCE Version 3.2 for AIX and Solaris: AdministrationCommands Reference.


Unconfiguring LDAP servers from a command lineEnter the following command at the command prompt to unconfigure an LDAPserver:unconfig.dce -config_type full[-cell_admin <cell_admin id>] [-dependents][-force] [-pwdstr_principal <password_strength_principal id>]components

Unconfiguring LDAP servers from SMIT (AIX only)Perform the following steps to unconfigure an LDAP server by using SMIT:

1. Start SMIT as root with the unconfig.dce fastpath:

smit rmdce

or select the following sequence of SMIT menu options:

1. Communications Applications and Services2. DCE (Distributed Computing Environment)3. Unconfigure DCE/DFS

2. Choose one of the following at the Type of Unconfiguration select box:

v full unconfiguration for this machine

v local only unconfiguration for this machine

v admin only unconfiguration for another machine

3. At the COMPONENTS to Remove panel enter or select from the pull-down listthe components that you want to remove.

For the admin only unconfiguration, enter the dce_hostname of the machinefor which you are unconfiguring components in the Client Machine’s DCEHOSTNAME field.

For the full unconfiguration and local unconfiguration, the RemoveDEPENDENT Components? field defaults to No. Change this field to Yes onlyif you have selected a component and are sure that you want to unconfigureevery component that depends on the presence of the component you selected.For example, all components depend on the presence of dced. Therefore, if youselect dced as the only client to unconfigure and change RemoveDEPENDENT Components? to Yes, the result will be the same as if you hadselected All for COMPONENTS to Remove.

Note: If you are unconfiguring a Password Strength server, you must enter itsID in the Principal ID for Password Strength Server field.

4. If you are not using the default cell_admin, enter the name of the celladministrator’s account at the Cell ADMINISTRATOR’s account prompt.

5. For the full unconfiguration and the local only unconfiguration, theOVERRIDE Dependency Checking? field defaults to No. Change this field toYes only if you are sure that you want to unconfigure a component withoutunconfiguring other components that are dependent on it. For example, if youunconfigure RPC but leave sec_cl and cds_cl configured, these two will not beable to function properly.

6. Select Do.

7. If prompted, enter the cell administrator’s password for the full unconfigurationand the admin unconfiguration.


Returning LDAP security servers to legacy security serversAfter you migrate the legacy master to LDAP, you cannot return LDAP securityservers to legacy security servers. However, if you have not migrated the legacymaster, perform the following steps to return an LDAP migration server or an LDAPsecurity slave to a legacy slave.

1. Use the unconfig.dce command to unconfigure the LDAP migration server orLDAP slave security server.

2. Manually remove DCE data from LDAP if you are unconfiguring the migrationserver. See “Deleting objects and attributes” on page 42 for information aboutremoving DCE data from LDAP.

3. Use the config.dce command to configure a legacy slave on the samemachine. See theIBM DCE Version 3.2 for AIX: Quick Beginnings or the IBMDCE Version 3.2 for Solaris: Quick Beginnings for more information aboutconfiguring a legacy security server.


Chapter 4. Administration

This chapter provides information you need to administer LDAP security servers. Italso provides troubleshooting procedures along with new and updated commandsthat are used to configure and migrate LDAP security servers.

LDAP initialization optionsThe DCE 3.2 CD contains a file that contains a list of LDAP defaults. dcecp orconfig copies the .ldap_options.defaults file to the .ldap_options.defaults file inthe /opt/dcelocal/var/security/ldap_data directory, if it does not already exist. Thesecurity server reads the .ldap_options file, if it exists, before attempting to bindwith the LDAP server. The .ldap_options file can contain any of the followingvalues shown with their LDAP default value. These values can be modified.

LDAP_OPT_TIMELIMIT 0LDAP_OPT_REFHOPLIMIT 10LDAP_OPT_DEREF 0LDAP_OPT_REFERRALS LDAP_OPT_ONLDAP_OPT_DEBUG 0LDAP_OPT_SSL_TIMEOUT 43200

These are the only LDAP options that can be modified. Any other options set in thisfile are ignored. Because DCE has its own time-outs, the DCE time-outs overrideany other time-outs you set in this file. The version is always set to 3. A # signbeginning any line in the file causes that line to be treated as a comment, and it isignored.

Referencing DNs for DCE policy informationWhen creating DCE principals, groups, or orgs, all subtrees in the krbPrincSubTreeattribute on the realm are searched for dceusername@dcecellname. If a matchingentry is found, the DCE data is attached to that object. If a matching entry is notfound, DCE creates the appropriate object as a child under the realm object.

Resetting LDAP settings for the DCE security registryIf you need to reset any of the LDAP settings for the DCE security registry, run theconfig.dce command with the appropriate new settings. If DCE is running, the newvalues do not take affect until the security server is stopped and restarted.

Use the -ldap_keyring option to enter the LDAP keyring file name and the LDAPkeyring entry. These are specified in the form of -ldap_keyringkeyring_file:keyring_entry. If you reset the keyring file name, you must reset thekeyring entry also. If you do not reset the keyring entry, the value is cleared.

Configuring the DCE registry policy and propertiesIn the LDAP configuration, the DCE security servers read the DCE registry policyand property attributes only when the servers are started. Therefore, if you changethe value in a DCE registry policy or DCE registry property attribute, DCE does notread this value until you restart the DCE security servers.


Deleting objects and attributesThe ldapdeletetype registry attribute specifies what information DCE deletes whenit removes information from LDAP. After you have migrated at least one securityserver to LDAP, you can set the ldapdeletetype registry attribute with dcecpregistry modify -ldapdeletetype {all | krb_dce | dce | no_delete}. You can alsospecify the ldapdeletetype registry attribute when you migrate a legacy securityserver to become the migration server or the LDAP master security server. You dothis by specifying the -delete_type {all | krb_dce | dce | no_delete} option on thedcecp registry migrate command.

You can query the current ldapdeletetype by using the dcecp registry showcommand. The following list describes the different delete levels. All of the deletelevels, except no_delete, delete the Attrschema and Replist objects.

all Deletes all DCE and Kerberos attributes and the objects they are attachedto including persons, groups, and organizations.

krb_dce

Deletes objects that are wholly owned by DCE and Kerberos includingKrbLog, DCELog, DCEUniqueID, DCEAcl, and KrbKey along with all of theattributes associated with DCE and Kerberos attached to other objects. Itdoes not delete persons, groups, or organizations.

dce Deletes attributes in the current cell that are wholly owned by DCEincluding DCEUniqueID, DCEAcl, and attributes within DCELog. It alsodeletes DCE attributes within the persons, groups, and organizations. Itdoes not delete attributes and objects that Kerberos applications use.

no_deleteDoes not remove any information from LDAP. This value can be used onlyafter the entire cell has been migrated to LDAP, and it can only be specifiedon the LDAP security master.

Consult the DCE schema in “Appendix B. DCE and Kerberos Schema Definitions”on page 61 for a description of the objects and attributes that are required for DCEto operate correctly.

DCE LDAP error messagesConsult the IBM DCE Version 3.2 for AIX and Solaris: Problem Determination Guidefor information about LDAP-related error messages.

When running DCE security servers that have been migrated to LDAP, it is possiblefor errors to occur on LDAP library calls. When an error does occur on an LDAPfunction call during secd execution, it is logged to one of the DCE serviceability logsin /opt/dcelocal/var/svc, and converted to a DCE message number. The LDAPerrors are mapped to DCE errors to support interoperability for clients that have notbeen modified to support LDAP.

Consult the serviceability logs for help in problem determination. The status text inthe log is close to describing the error that occurred. However, the suggested actionmight not be accurate because it applies to an LDAP error.

The following example shows the format of the logged message:%1 returned %2 during %3


%1 is the failing function call. %2 is its return code or reason for failure. %3 is theDCE function that contains the failing function call. For example, the following errormessage might appear in the serviceability log:

ldap_search_s returned LDAP_NO_SUCH_OBJECT during rgy_ldap_find_dn

The following table shows the DCE status code and message ID that is returned foreach LDAP result code:

Table 3. DCE Status Codes and Corresponding LDAP Result Codes

DCE Status Code DCE MessageID

LDAP Result Code

rpc_s_call_timeout 0x16C9A06C LDAP_TIMELIMIT_EXCEEDEDLDAP_REFERRAL_LIMIT_EXCEEDED

rpc_s_comm_failure 0x16C9A016 LDAP_CONNECT_ERROR

sec_attr_bad_bind_authn_svc 0x17122161 LDAP_AUTH_UNKNOWN

sec_attr_inst_exists 0x17122148 LDAP_TYPE_OR_VALUE_EXISTS

sec_attr_inst_not_found 0x17122144 LDAP_NO_SUCH_ATTRIBUTE

sec_rgy_cant_allocate_memory 0x17122085 LDAP_NO_MEMORYLDAP_URL_ERR_MEM

sec_rgy_cant_authenticate 0x17122095 LDAP_INVALID_CREDENTIALS

sec_rgy_not_authorized 0x17122081 LDAP_INSUFFICIENT_ACCESS

sec_rgy_not_implemented 0x17122073 LDAP_UNWILLING_TO_PERFORMLDAP_NOT_SUPPORTED

sec_rgy_object_exists 0x17122075 LDAP_ALREADY_EXISTS

sec_rgy_object_not_found 0x1712207A LDAP_NO_SUCH_OBJECT

sec_rgy_server_unavailable 0x1712207B LDAP_BUSY, LDAP_UNAVAILABLELDAP_SERVER_DOWN

sec_s_authz_unsupp 0x17122001 LDAP_STRONG_AUTH_NOT_SUPTLDAP_STRONG_AUTH_REQUIREDLDAP_PARTIAL_RESULTSLDAP_CONFIDENTIALITY_REQDLDAP_INAPPROPRIATE_AUTH

sec_s_pgmerr 0x1712200C LDAP_OPERATIONS_ERRORLDAP_PROTOCOL_ERRORLDAP_SIZELIMIT_EXCEEDEDLDAP_UNDEFINED_TYPELDAP_INAPPROPRIATE_MATCHINGLDAP_ALIAS_DEREF_PROBLEMLDAP_NO_OBJECT_CLASS_MODSLDAP_URL_ERR_NODN

sec_rgy_bad_data 0x17122084 Returned for all LDAP result codesencountered

Troubleshooting proceduresThis chapter contains procedures for troubleshooting LDAP security servers. Usethese procedures only when network or hardware failures disrupt operation of theregistry or when you encounter problems that you cannot remedy in any other way.

Use the following procedures after all of the security servers in the cell have beenmigrated to LDAP. Until then, use the recovery procedures in the IBM DCE Version

Chapter 4. Administration 43

3.2 for AIX and Solaris: Administration Guide—Core Components. Only legacysecurity servers can be used in the directions specified in the IBM DCE Version 3.2for AIX and Solaris: Administration Guide—Core Components.

Backup and recovery of the system after failure in the security serverUse the following procedures if there is a catastrophic failure in the security server.

Backing up the registry databaseAlthough most DCE registry data is stored in LDAP, you must still back up theregistry database as well as backing up the LDAP directory. Refer to your LDAPdocumentation for instructions on backing up an LDAP directory.

To run the DCE backup procedures, ensure that you are logged into DCE throughan administrative account. Then, run the DCE control program, dcecp, to do thebackup.

To back up the registry database:

1. Enter the registry disable command to put the LDAP master security serverinto maintenance mode. The following command sets the master registry in thecell giverny.com to maintenance mode:

dcecp> registry disable /.../giverny.com/subsys/dce/sec/masterdcecp>

After you set the LDAP security master to maintenance mode, it refuses allupdates.

2. Use one of the following methods to back up DCE data:

v Use the dceback command to back up DCE data. To do this, enter thefollowing at the command prompt:dceback dumpsecurity -destfile <destfile>dceback dumpmisc -destfile <destfile2>

v Back up data manually:

a. Back up the registry files that remain in/opt/declocal/var/secuirty/rgy_data. Also, if the master key is storedlocally, back up the .mkey file. Because the master key can existanywhere on the system, you must make sure that it is backed upproperly.

b. Use tar to back up the following:

– /opt/dcelocal

– /var/dce (AIX only)

– /opt/dcelocal/var (Solaris only)

– /krb5

– /etc/dce (AIX only)

– /opt/dcelocal/etc (Solaris only)

– the master key if it is not stored in LDAP

3. Back up the LDAP directory by using the instructions supplied in the LDAPdocumentation.

4. After the backup completes, use the following command to take the LDAPsecurity master out of maintenance state:

dcecp> registry enable /.../giverny.com/subsys/dce/sec/masterdcecp>


The security server resumes accepting updates.

Note: The previous examples supplied the name of the primary registry site to theregistry enable and registry disable commands. If you do not supply aregistry site name, the commands use the site named in the _s(sec_)variable. If this variable is not set, the commands use the primary registry ofthe machine’s default cell.

Restoring the registry databaseThe steps in this procedure assume that the old security server is no longerpowered up.

1. Install a new machine in the network. Assign the new machine the same IPaddress and hostname as the old security server.

2. Install DCE on the machine, but do not configure it.

3. Use one of the following methods to restore DCE data:

v Use the dceback command to restore DCE data. To do this, enter thefollowing at a command prompt:dceback restoresecurity -sourcefile <destfile>dceback restoremisc -sourcefile <destfile2>

v Untar the saved directories.

– /opt/dcelocal

– /var/dce (AIX only)

– /opt/dcelocal/var (Solaris only)

– /krb5

– /etc/dce (AIX only)

– /opt/dcelocal/etc (Solaris only)

– the master key if it is not stored in LDAP

4. If necessary, restore the LDAP directory by using the instructions supplied byyour LDAP documentation.

5. Restart the system.

Recovering the LDAP security master by converting an LDAP securityslave to an LDAP security master

The procedures described in this section might not be as useful as they were forlegacy security servers that maintained their own databases. However, the stepsmight be useful if the remaining databases on the local machine become corrupted.

You can use either of the following methods to recover an LDAP security masterwhen its local database is damaged:

v Use the dcecp registry designate command to make an LDAP security slavethe LDAP security master and create an LDAP security slave on the host of theformer LDAP security master.

v Restore the master from a backup. This method is described in “Restoring theregistry database”.

Use these methods only when the local security databases have been damaged.When the LDAP directory is damaged, use an LDAP replica with the latestdatabase or a backup to recover the LDAP data.

The following steps describe how to use the dcecp registry designate commandto convert an LDAP security slave to an LDAP security master. Use the registry


designate -master command only if the LDAP security master’s local databasesare irrevocably damaged and you are unable to use the registry designatecommand without the -master option.

Follow these steps to convert an LDAP security slave to an LDAP security master:

1. Choose the LDAP security slave that you are converting to be the new LDAPsecurity master.

2. Issue the following registry designate -master command to change the defaulthost to the master registry:dcecp> registry designate /.../musee.com/subsys/dce/sec/art -masterdcecp>

3. Use the registry show -replica command to verify the change.

4. Use standard UNIX® commands to delete the old LDAP security master’sdatabases and master key file if it is not stored in LDAP by deleting thedirectory dcelocal/var/security/rgy_data and the file that held the master key.

5. Use the registry delete command with the -force option to remove the oldLDAP security master from the replica list. The following example deletes theold master named history from the replica list:dcecp> registry delete /.../musee.com/subsys/dce/sec/history -forcedcecp>

Recovering LDAP security slavesBecause LDAP security slaves maintain very little local data, it is recommended thatyou unconfigure and reconfigure a corrupted LDAP security slave.

1. Unconfigure the LDAP security slave by entering the following at a commandprompt.unconfig.dce sec_rep

2. Reconfigure the LDAP security slave on the same machine. For instructions onconfiguring LDAP security slaves see “Configuring LDAP security servers” onpage 37.

Converting an LDAP security master to an LDAP security slaveUse the following procedure to convert an LDAP security master to an LDAPsecurity slave. Use this procedure only if you have more than one LDAP securitymaster running on your network or on the internet, which is a highly unusualcondition.

1. Choose the LDAP security master that you are converting to an LDAP securityslave.

2. Issue the following registry designate -slave command to change the masterto a slave:dcecp> registry designate /.../dublin.com/subsys/dce/sec/lit -slavedcecp>

3. Use the registry show -replica command to verify the change.

Forcibly deleting an LDAP security slaveTo forcibly delete an LDAP security slave, issue the registry delete command withthe -force option, supplying the name of the registry to delete as an argument. Thiscommand deletes the LDAP security slave from the LDAP security master’s replicalist. The following sample deletes the LDAP security slave at/.../giverny.com/subsys/dce/sec/lit_server_2:


dcecp> registry delete /.../giverny.com/subsys/dce/sec/lit_server_2-forcedcecp>

If the default replica is not the master, dcecp automatically binds to the master.

If a forcibly deleted LDAP security slave continues operation, use the registrydestroy command to stop the server and delete its database. When you use theregistry destroy command, you must enter the name of the LDAP security slavethat you want to stop. The following example shows the registry destroy commandused to delete the LDAP security slave at/.../giverny.com/subsys/dce/sec/lit_server_2:

dcecp> registry destroy /.../giverny.com/subsys/dce/sec/lit_server_2dcecp>

Alternatively, you can simply stop secd (by using the dcecp registry stopcommand) and destroy the LDAP security slave by deleting or renaming itsdatabase. You can use the unconfig.dce sec_rep command to completely cleanup a security replica.

Designating a new LDAP security master when the current LDAPsecurity master fails

If the LDAP security master has failed and will be unavailable for an extendedperiod, use the following steps to designate an existing LDAP security slave as thenew LDAP security master:

Note: After you perform these steps, the previous master is no longer configured inthe cell.

1. Choose the new LDAP security master site. An LDAP security slave mustalready exist on the host you choose.

2. Log into the host that is the new LDAP security master.

3. Edit the /opt/dcelocal/etc/security/pe_site file and remove any entries for theold LDAP security master. Then, set the TRY_PE_SITE environment variable tohave a value of 1.

4. Log into DCE as the cell administrator.

5. Enter the registry designate command to set the new LDAP security master.When you issue this command, supply the name of the security server to bemade the new LDAP security master as an argument. The old LDAP securitymaster is not contacted during this operation. This command might take severalminutes to complete.dcecp> registry designate /.../henry.com/subsys/dce/sec/cheyenne-masterdcecp>

6. Enter the registry show command to verify that the new LDAP security masterhas become the master:dcecp> registry show /.../henry.com/subsys/dce/sec/cheyennedcecp>

7. Use the following steps to unconfigure the old LDAP security master:

a. Enter the registry delete command to remove the old LDAP security masterfrom the replica list:dcecp> registry delete /.../henry.com/subsys/dce/sec/bourbon -forcedcecp>


b. Enter the rpcgroup remove command to delete the old LDAP securitymaster from the security rpc groups /.:/sec, /.:/sec-v1, and /.:/sec-l:dcecp> rpcgroup remove /.:/sec -member /.../henry.com/subsys/dce/sec/bourbondcecp>dcecp> rpcgroup remove /.:/sec-v1 -member /.../henry.com/subsys/dce/sec/bourbondcecp>rpcgroup remove /.:/sec-l -member /.../henry.com/subsys/dce/sec/bourbondcecp>

c. Enter the object delete command to delete the cds object for the old LDAPsecurity master from the cds namespace:

dcecp> object delete /.:/subsys/dce/sec/bourbondcecp>

d. Enter the group remove command to remove the host of the old LDAPsecurity master from the security server group:dcecp> group remove /.:/subsys/dce/sec_servers -member /.:/hosts/bourbon/selfdcecp>

e. Enter the unconfig.dce command to unconfigure the administrative portionof the old LDAP security master:$ unconfig.dce -config_type admin -dce_hostname bourbon sec_rep

Note: You can replace sec_rep in the above command with all if you wantto unconfigure all DCE components on the old LDAP security master.

LDAP commandsYou use common DCE commands such as registry designate, start.dce,stop.dce, and unconfig.dce to administer and unconfigure LDAP security servers.However, there is a new command, dcecp registry migrate, that is used to migratelegacy security servers to LDAP. The dcecp registry ldapdelete command deletesDCE data from LDAP. There are also new options for the config.dce and dcecpregistry modify commands.

Note: LDAP does not support the following legacy security registry command andcommand option:

When you issue the sec_admin -s command on a legacy security server,you can provide the replica’s name as it appears on the replica list. LDAPsecurity servers do not support this feature. You can, however, continue toprovide the cell name, the global name, or the network address of the host.For more information abut the sec_admin command, consult the IBM DCEVersion 3.2 for AIX and Solaris: Administration Commands Reference.

This section describes the following commands:

v registry migrate

v registry ldapdelete

This section also describes the new options on the config.dce and registry modifycommands.


config.dce

PurposeConfigures the DCE components.

Note: This command exists in previous releases of DCE. However, several newoptions have been added to this command to support the configuration ofLDAP slave security servers. Only the new options are listed here. Consultthe IBM DCE Version 3.2 for AIX and Solaris: Administration CommandsReference for a complete synopsis and list of options and a more thoroughexplanation of this command.

Synopsisconfig.dce[-ldap_auth {simple | ssl | cram-md5}][-ldap_dce_master_key dce_master_key_file][-ldap_dn dn][-ldap_dn_pw dn_pw][-ldap_keyring -ldap_keyring[:entry]][-ldap_keyring_pw ldap_keyring_pw][-ldap_master_key_in_ldap {yes | no}][-ldap_registry][-ldap_server ldap_server | ldap_server:port_number |

″ldap_server:port_number ldap_server ldap_server:port_number″][ldap_ssl {yes | no}]

Options-ldap_auth {simple | ssl | cram-md}

Specifies the type of authentication to use. The default value is simple.

-ldap_dce_master_key ldap_dce_master_key_fileSpecifies the file that contains the master key for the DCE security registry ifthe key is not being stored in LDAP. This parameter is optional. If it is leftunspecified, the default file, /opt/dcelocal/var/security/.mkey, is used.

-ldap_dn dnSpecifies the DN the security server uses to bind to the LDAP server.

-ldap_dn_pw dn_pwSpecifies the password for the DN that the security server uses to bind to theLDAP server.

-ldap_keyring -ldap_keyring[:entry]Identifies the pathname of a keyring file and, optionally, an entry in the keyringfile to be used for SSL authentication. This parameter is optional. If it is leftunspecified, a default key ring file (/$LDAPHOME/lib/ldapkey/.kdb) is used.

-ldap_keyring_pw ldap_keyring_pwSpecifies the password that is used to protect the contents of the key databaseused for SSL authentication. If the password is unspecified, it can be obtainedfrom a password stash file that contains an encrypted version of the password.It is assumed that the password stash file has the same name as the keyringdatabase file, but with an extension of .sth instead of .kdb. It is also assumedthat the password stash file resides in the same directory as the keyringdatabase file.


-ldap_master_key_in_ldap {yes | no}Indicates whether or not the security server uses the master key stored inLDAP. If yes is specified, the security server uses the master key stored inLDAP.

-ldap_registryOnly used if a security server is being configured. It indicates that the securityregistry is being stored in an LDAP database. Use only if you are configuring amaster security server (sec_srv) or a replica security server (sec_rep).

-ldap_server ldap_server_ip | ldap_server:portSpecifies the IP host name or the IP address of the LDAP master securityserver. Also, it optionally specifies the port to use when binding to the LDAPdirectory server. This option can contain single value or a list of server andserver:port pairs. This list must be enclosed by quotation marks (″″). If youspecified -ldap_registry yes, then you must also specify the ldap_server_ipinformation.

-ldap_ssl {yes | no}Indicates if SSL is being used. SSL automatically uses the default values for theldap_keyring and ldap_keyring_pw parameters. If the default values are notappropriate, change the values in the ldap_keyring and ldap_keyring_pwparameters.

DescriptionThis command supports configuration of LDAP slave security servers only. Use thedcecp registry migrate command to configure a migration server or an LDAPmaster security server.

You can change the -ldap_auth, -ldap_dn, -ldap_dn_pw, -ldap_keyring,-ldap_keyring_pw, -ldap_server, -ldap_ssl, –ldap_master_key_in_ldap, and–ldap_dce_master_key settings after the security server is configured using LDAP.Specify a new value for the settings that need to be updated and config.dceupdates the /opt/dcelocal/var/security/ldap_data/.ldap_data file.

The settings of the -ldap_registry option cannot be changed by the config.dcecommand. Instead, use the dcecp -c registry migrate commands to change howsecd maintains its data.


dcecp registry ldapdelete

PurposeDeletes DCE data in LDAP for the specified cell.

Synopsisregistry ldapdelete[-cell_name cell_name][-delete_type {all | dce | krb_dce}][-force][-ldap_options ldap_options_file]{[-ldap_data ldap_data_file] |[-auth_type {simple | ssl | cram-md5}][-bind_dn bind_dn][-bind_dn_pw bind_dn_pw][[-ssl]-keyring ldap_keyring_file [:entry]-keyring_pw ldap_keyring_pw][-ldap_host hostname | hostname:port | ″list of hostname and/or hostname:port″]}

Options-auth_type {simple | ssl | cram-md5}

Specifies the type of authentication to use: simple, ssl, or cram-md5. Thedefault is simple.

-bind_dn bind_dnSpecifies the DN DCE uses to bind to the LDAP server.

-bind_dn_pw bind_dn_pwSpecifies the password for the bind_dn that DCE uses to bind to the LDAPserver.

-cell_name cell_nameIdentifies the name of the cell in which you want to remove DCE data fromLDAP. If left unspecified, this option defaults to the current cell name. Thisoption is required if the machine that you are running this command on is notconfigured into a DCE cell.

-delete_type {all | dce | krb_dce}Specifies the type of data that is removed from LDAP when data is deleted. Thevalid values are all, dce, and krb_dce. If this parameter is not specified, DCEattempts to retrieve the current ldapdeletetype setting from the LDAPdatabase. If the ldapdeletetype setting cannot be retrieved, DCE defaults thesetting to all. If the current ldapdeletetype setting is no_delete, you mustspecify the -delete_type option.

-forceIndicates that the delete verification prompt should be skipped.

-keyring[:entry]Identifies the pathname of the keyring file, and optionally an entry in the file, tobe used for SSL authentication.

-keyring_pwSpecifies the password that is used to protect the contents of the key databaseused for SSL authentication. If the password is unspecified, it can be obtainedfrom a password stash file that contains an encrypted version of the password.It is assumed that the password stash file has the same name as the keyring


database file, but with an extension of .sth instead of .kdb. It is also assumedthat the password stash file resides in the same directory as the keyringdatabase file.

-ldap_dataIdentifies the pathname of a .ldap_data file. On a configured LDAP replica, inthe /opt/dcelocal/var/security/ldap_data directory, you can find an LDAP datafile (.ldap_data). You can copy this file and modify it to match the configurationof the cell for which you want to delete the DCE data in LDAP. If the -ldap_dataoption is specified, then none of the following parameters may be specified:-ldap_host, -bind_dn, -bind_dn_pw, -keyring, -keyring_pw, -ssl, -auth_type.

-ldap_hostContains the hostname or hostname:port pair of the LDAP directory servers.You can specify a single value or you can enter a list of hostnames orhostname:port pairs.

-ldap_optionsIdentifies the pathname of an .ldap_options file. On a configured LDAP replica,in the /opt/dcelocal/var/security/ldap_data directory, you can find an LDAPoptions file (.ldap_options). On any DCE 3.2 security replica, in the/opt/dcelocal/var/security/ldap_data directory, you can find a default LDAPoptions file (.ldap_options.defaults). You can copy this file and modify it tomatch the configuration of the cell for which you wish to delete the DCE data inLDAP.

-sslIndicates if SSL is being used. SSL automatically uses the default values for the-keyring and -keyring_pw parameters. If the default values are notappropriate, change the values in the ldap_keyring and ldap_keyring_pwparameters.

DescriptionDeletes DCE data in LDAP for the specified cell. This command can be run on anymachine that has DCE 3.2 installed. The machine does not need to be configuredinto a cell, but the LDAP client must be installed on the machine.

Examplesdcecp> registry ldapdelete -cell_name big_cell -ldap_host fastest:9361-bind_dn cn=admin -bind_dn_pw secret

dcecp> registry ldapdelete -cell_name big_cell -ldap_data /tmp/my_data-ldap_options /tmp/my_options -force


dcecp registry migrate

PurposeMigrates legacy security servers to LDAP security servers.

Synopsisregistry migrate{-migrationslave | -ldapmaster [-force] | -ldapslave}-bind_dn bind_dn-bind_dn_pw bind_dn_pw-ldaphost hostname | hostname:port | ″list of hostname and/or hostname:port″[-auth_type {simple | ssl | cram-md5}][-dce_master_key dce_master_key_file][-delete_type {all | krb_dce | dce | no_delete}][-keyring[:entry]ldap_keyring_file][-keyring_pw ldap_keyring_pw][-master_key_in_ldap][-ssl]

Options-auth_type { simple | ssl | cram-md5}

Specifies the type of authentication to use, simple, ssl, or cram-md5. Thedefault is simple. If you specified –ssl yes, you cannot use the defaultauth_type, simple.

-bind_dn bind_dnSpecifies the DN the security server uses to bind to the LDAP server.

-bind_dn_pw bind_dn_pwSpecifies the password for the bind_dn that the security server uses to bind tothe LDAP server.

-dce_master_key ldap_dce_master_key_fileSpecifies the file that contains the master key for the DCE security registry ifthe key is not being stored in LDAP. This parameter is optional. If it is leftunspecified, the default file, /opt/dcelocal/var/security/.mkey, is used.

-delete_type {all | krb_dce | dce | no_delete}Specifies which objects and attributes DCE deletes from LDAP. Specifying alldeletes all attributes and any object that contains DCE data in the local cell.Specifying krb_dce deletes attributes that are associated with Kerberos andDCE only. The structural objects that DCE created or that DCE attachedattributes to are not deleted. Specifying dce deletes attributes that areassociated with DCE only. It leaves attributes and objects that Kerberosapplications use. all is the default value. Specifying no_delete causes nothingto be deleted when DCE commands are used. This option is valid only when-ldapmaster or -migrationslave is specified. The no_delete value is only validwhen -ldapmaster is specified.

-forceForces the local master or LDAP migration security server to become an LDAPsecurity master even if the LDAP migration server is not up-to-date. Used onlywith the -ldapmaster option. This parameter is required if the local securityserver is an LDAP migration server and you want to migrate it to be the LDAPsecurity master.

--keyring[:entry]Identifies the pathname of an existing keyring file and, optionally, an entry in the


keyring file to be used for SSL authentication. This parameter is optional. If it isleft unspecified, a default keyring file ($LDAPHOME/lib/ldapkey/.kdb) is used.

-keyring_pwSpecifies the password that is used to protect the contents of the key databaseused for SSL authentication. If the password is unspecified, it can be obtainedfrom a password stash file that contains an encrypted version of the password.It is assumed that the password stash file has the same name as the keyringdatabase file, but with an extension of .sth instead of .kdb. It is also assumedthat the password stash file resides in the same directory as the keyringdatabase file.

-ldaphostContains the hostname or hostname:port pair of the LDAP directory servers.You can specify a single value or you can enter a list of hostnames andhostname:port pairs. If you specify a list, the list must be enclosed by doublequotation marks, and each item in the list must be separated by one or morespaces. For example, –ldaphost ″host1[:port] ″host2[:port]″ You must specifythis parameter when designating a migration server, LDAP security master, orLDAP security slave.

-ldapmasterMakes the local legacy master the LDAP security master. (Can also be used onthe LDAP migration server with the -force flag to force the secd on that machineto become the LDAP master security server. Use caution when doing thisbecause the LDAP migration security server might not have received allupdates from the master security server).

-ldapslaveMakes the local legacy slave an LDAP security slave.

-master_key_in_ldapIndicates if the security server uses the master key stored in LDAP.

-migrationslaveMakes the local legacy slave an LDAP migration server.

-sslIndicates if SSL is being used. SSL automatically uses the default values for theldap_keyring and ldap_keyring_pw parameters. If the default values are notappropriate, change the values in the ldap_keyring and ldap_keyring_pwparameters.

DescriptionThis is a new dcecp registry command for DCE 3.2. It migrates legacy securityservers to LDAP security servers. This command must be run on the servermachine that is being migrated.

When you migrate a legacy slave to an LDAP migration server, the dcecp registrymigrate command uses the options you specify to create a .ldap_data file. This filecontains information about the following registry migrate options:

v -ssl

v -auth_type

v -bind_dn

v -bind_dn_pw

v -keyring

v -keyring_pw

v -ldap_host


v -master_key_in_ldap

v -dce_master_key

Before performing a migration to an LDAP security slave or an LDAP securitymaster, the registry migrate command checks for a .ldap_data file in the/opt/dcelocal/var/security/ldap_data directory.

When you migrate to the migration server by using the dcecp registry migrate-migrationslavecommand, you must enter all of the parameters required for thecommand. The values you enter are used to create the .ldap_data file.

After the migration server is in place, you can copy the .ldap_data file to anymachine you are migrating to an LDAP security slave or LDAP security master.When you specify -ldapslave or -ldapmaster without any LDAP connectionparameters, the registry migrate command checks for the .ldap_data file and usesthe values contained in the file. However, if you enter any of the parameterscontained in the .ldap_data file, on the registry migrate command line, the.ldap_data file is not used and the normal parameter requirements apply.

For example, if you copied the .ldap_data file from the migration server to asecurity replica that is to become an LDAP slave, the replica can be migrated usingthe following command:dcecp -c registry migrate -ldapslave

If you copy a .ldap_data file from another system, be sure that you also copy anyfiles that are listed in the .ldap_data file.

It is recommended that the cell administrator perform all registry migratecommands when migrating a legacy security server to an LDAP security server.


dcecp registry modify

PurposeChanges attributes of the registry.

Note: This command exists in previous releases of DCE. However, the–ldapdeletetype option has been added to support the administration ofLDAP security servers. This section lists the options that are used to specifythe ldapdeleltetype attribute only. Consult the IBM DCE Version 3.2 for AIXand Solaris: Administration Commands Reference for a complete synopsisand list of options and a more thorough explanation of this command.

Synopsisregistry modify[registry_replica_name][-ldapdeletetype {all | krb_dce | dce | no_delete}]

Optionsregistry_replica_name

The name of one registry replica to act on. When the -ldapdeletetype option isspecified, the registry replica name must be either the LDAP master securityserver or the LDAP migration server. The -ldapdeletetype is stored in LDAP,and these servers are the only security servers with write access to LDAP.

If no registry replica name is supplied with the -ldapdeletetype option, thenregistry_replica_name defaults to either the LDAP migration server or theLDAP master security server, whichever is active in the cell.

When used with the -ldapdeletetype option, the registry_replica_name can beone of the following:

v The global name of a replica to bind to in a specific cell, such as/.../gumby1/subsys/dce/sec/oddball.

v The name of a replica as it appears on the replica in the local cell, such assubsys/dce/sec/oddball.

-ldapdeletetype {all | krb_dce | dce | no_delete}Specifies which objects and attributes DCE deletes from LDAP. Specifying alldeletes all attributes and any object that contains DCE data in the local cell.Specifying krb_dce deletes attributes that are associated with Kerberos andDCE only. The structural objects that DCE created or that DCE attachedattributes to are not deleted. Specifying dce deletes attributes that areassociated with DCE only. It leaves attributes and objects that Kerberosapplications use. all is the default value. Specifying no_delete causes nothingto be deleted when DCE commands are used. The no_delete value for thisoption cannot be specified when there is an LDAP migration server in the cell.The -ldapdeletetype option can only be specified when at least one LDAPsecurity server is in the cell.


Appendix A. Default DCE LDAP Tree

krbRealmName-v2=<cell_name>

v cn=attrschema

v cn=group

v cn=mkey

v cn=organization

v cn=policy

v cn=principal

v cn=replist

v cn=uniqueid

DCE ObjectsThis section describes the objects found in the default DCE LDAP tree.

krbRealmName-v2=<cell_name>DN krbRealmName-v2=<cell_name>

Object classes

v KrbRealm-v2

v KrbRealmExt

v DCEPolicy

v KrbPolicy

v DCERealm

cn=attrschemaDN cn=attrschema, krbRealmName-v2=<cell_name>

DescriptionBy default DCE attribute schemas definitions are created as DCEXattrobjects that are children of DN=cn=xattrschema, krbRealmName-v2=<cell_name>

Object Classes

v container

v dcedir

cn=groupDN cn=group, krbRealmName-v2=<cell_name>

DescriptionBy default DCE groups are created as groupOfUniqueNames objects thatare children of DN=cn=group, krbRealmName-v2=<cell_name>. Theycontain the DCEGroup auxiliary class. All DCE groups have the followingtwo objects as children (identified by their RDNs).

v cn=dceacl

object class: DCEAcl

v cn=uniqueid


object class: DCEUniqueID

Object classes

v container

v DCEDir

cn=mkeyDN cn=mkey, krbRealmName-v2=<cell_name>

Object classes

v KrbMstrKey

cn=organizationDN cn=organization, krbRealmName-v2=<cell_name>

DescriptionBy default DCE organizations are created as organization objects that arechildren of DN=cn=organization, krbRealmName-v2=<cell_name>. Theycontain the following auxiliary classes

v KrbPolicy

v DCEOrg

v DCEPolicy

All DCE organizations have the following 2 objects as children (identified bytheir RDNs):

v cn=dceacl


v cn=uniqueid


Object classes

v container

v DCEDir

cn=principalDN cn=principal, krbRealmName-v2=<cell_name>

DescriptionBy default DCE principals are created as person objects that are children ofDN =cn=principal, krbRealmName-v2=<cell_name>. Each principal containsthe KrbPrincipal auxiliary class.

All DCE principals have the following two objects as children (identified bytheir RDNs):

v cn=dceacl


v cn=uniqueid


When accounts are created for a principal, the following 2 objects arecreated as children of the DCEPrincipal:

v cn=krbLog


object class: KrbLog

auxiliary object classes: DCELog and DCELogExt

v keyversion=1

object class: KrbKey

It is possible for a DCE principal to have directories as part of their names.When this occurs, a person object is created for each directory along thepath, and that directory contains the following child object:

v cn=dcediracl


Object classes

v container

v DCEDir

cn=replistDN cn=replist, krbRealmName-v2=<cell_name>

DescriptionBy default, DCE replicas are created as DCEReplist objects that arechildren of DN=cn=replist, krbRealmName-v2=<cell_name>.

Object classes

v container

v DCEdir

cn=uniqueIDDN cn=uniqueID, krbRealmName-v2=<cell_name>

Object classes

v DCEUniqueID

Appendix A. Default DCE LDAP Tree 59


Appendix B. DCE and Kerberos Schema Definitions

This appendix describes the objects and attributes found in the DCE and Kerberosschemas.

DCE object classesThis section describes the DCE object classes found in the LDAP schema.

DCEAclDescription

A structural object class for use in configuring an entry to represent a DCEACL for an associated DCE object. The associated DCE object can be aDCE directory, DCE principal, DCE group, DCE organization, DCE realmpolicy, DCE ERA, or DCE replication list. The entry representing the DCEACL must reside directly below the entry representing the associated DCEobject and the RDN of this entry must contain the string cn=DCEAcl. It canalso contain additional strings if this is required to uniquely identify theentry. The relationship between the entry representing the DCE ACL andthe entry representing the associated DCE object is many-to-one with eachDCE ACL containing a different ACL manager type.

Sup top, Structural

Mandatory attributes

v cn

v dceAclEntries

Optional attributes

v dceAclDefRealmName

v dceAclDefRealmUUID

v dceDefDirAclEntries

v dceDefObjAclEntries

DCEDirDescription

An auxiliary object class for use in configuring an entry to represent a DCEdirectory name. Configuring a DCE directory name is required only if theentry is not already configured as a DCE principal and the user wants touse the DCE directory name for DCE registry search operations. If an entryis already configured as a DCE principal, DCE uses the principal name(krbPrincipalName attribute) as the DCE directory name.

Sup top, Auxiliary


v dceDirName

DCEERADescription

A structural object class for use in configuring an entry to represent auser-defined DCE extended registry attribute (ERA) for a DCE principal,DCE group, or DCE organization. The entry representing the DCE ERA


must reside directly below an entry representing a DCE principal, DCEgroup, or DCE organization and must contain an RDN ofdceXattrName=name. The relationship between the entry representing theDCE ERA and the entry representing the DCE principal, DCE group, orDCE organization is many-to-one, with each ERA configured with a differentname. The relationship between the entry representing the DCE ERA andthe entry representing the DCE XATTR is many-to-one with each DCE ERAassociated with a different DCE principal, DCE group, or DCE organization.

Sup top, Structural


v dceXattrName

v secUUID

Optional attributes

v dceXattrValue

DCEGroupDescription

An auxiliary object for use in configuring an entry with a membershipattribute to represent a DCE group. The entry must reside under one of thesubtrees listed in the krbPrincSubtree attribute of the entry representing theDCERealm.

Sup top, Auxiliary


v dceGroupName

Optional attributes

v dceFullName

v dceIsRequired

v dceProjlistOK

v dceUnixObject

Note: DCE 3.2 does not support the dceUnixObject attribute.

DCELegacyDBDescription

An auxiliary object class for use in configuring legacy database informationin an entry representing a DCE object.

Sup top, Auxiliary

Optional attributes

v dceID

DCELogDescription

An auxiliary object class for configuring an existing entry representing aKerberos login activity record to also represent a DCE login activity record.The existing entry must have been configured with the KrbLog structuralobject class.

Sup top, Auxiliary



v dceJournalID

Optional attributes

v dceBadOriginIP

v dceBadOriginString

v dceDisableTime

v dceGoodOriginIP

v dceGoodOriginString

DCEOrgDescription

An auxiliary object class for use in configuring an entry to represent a DCEorganization. The entry must reside under a subtree listed in thekrbPrincipalName attribute of the entry representing the DCE realm.

Sup DCEPolicy, auxiliary

Optional attributes

v dceFullName

v dceHintForeignMembershipUUIDS

v dceHintMembershipUUIDs

v dceIsRequired

v dceProjListOk

DCEPolicyDescription

An auxiliary object class for use in configuring DCE policy attributes for anassociated DCE principal or DCE realm. The DCE policy attributes canreside in the entry representing the DCE principal or realm, a referencedDCE organization, or both. If the same DCE policy attribute resides in bothentries, the DCE policy attributes from the referenced organization areused. The krbPolicyNameRef attribute is used to reference a DCEorganization for a DCE principal. The krbPolicyObject is used to reference aDCE policy for a DCE realm. (See also “DCEPrincipal” on page 64 and“DCERealm” on page 64.)

Sup KrbPolicy, Auxiliary

Optional attributes

v dcePolicyFlags

v dcePasswordMaxLength

v maxFailedLogins

v passwordMaxRepeatedChars

v passwordMinOtherChars

v passwordTimeReuse

v secAcctLife

v secPwdAlpha

v secPwdSpaces

v timeExpireLockout

Appendix B. DCE and Kerberos Schema Definitions 63

DCEPrincipalDescription

An auxiliary object for use in configuring an entry to represent a DCEprincipal.

Sup KrbPrincipal, Auxiliary

Optional attributes

v dceCreateTimestamp

v dceCreatorsUUID

v dceFullname

v dceGoodSinceDate

v dceHintForeignMembershipUUIDs

v dceHintMembershipUUIDs

v dceIsRequired

v dceKeyParts

v dceModifiersUUID

v dceModifyTimestamp

v dcePrimaryGroup

v dceProjlistOK

v dceQuota

v dceRsaCurKeyVersion

v dceRsaKeyOk

v dceUnixObject

Note: DCE 3.2 does not support the dceUnixObject attribute

DCERealmDescription

An auxiliary class for use in configuring an entry to represent a DCE realm.The entry also must be configured using the KrbRealm-v2 structural objectclass. See also “KrbRealm-v2” on page 87.

Sup KrbRealmExt, Auxiliary

Optional attributes

v dceDefaultTktLife

v dceDomainCacheState

v dceInternalData

v dceLastUnixIDGroup

v dceLastUnixIDOrg

v dceLastUnixIDPerson

v dceLowUnixIDGroup

v dceLowUnixIDOrg

v dceLowUnixIDPerson

v dceMaxUnixID

v dceMinTktLife

v dceReadVersion

v dceSecMapSubtreeGroup


v dceSecMapSubtreeOther

v dceSecMapSubtreePrinc

v dceShadowPwdOK

v dceUnauthenticatedQuota

v dceUnboundTktsOK

v dceUniqueIDCfg

v dceWriteVersion

DCEReplistDescription

A structural object class for use in configuring an entry to represent a DCEreplication list for a server in a DCE realm. The entry representing the DCEreplication list must reside directly below a DCE replication list containerand must have an RDN of krbKdcServiceName=server, where server is thename of the DCE server. The DCE replication list container must residedirectly below the entry representing the associated DCE realm and musthave an RDN of cn=DCEReplists. The relationship between the entryrepresenting the DCE replication list and the DCE replication list containeris many-to-one with each DCE replication list containing a different servername. The relationship between the DCE replication list container and theentry that represents the DCE realm is one-to-one.

Sup top, Structural


v dceReplicaInfo

v dceReplicaTwrs

v krbKdcServiceName

Optional attributes

v dceReadOnlyReplica

DCEUniqueIDDescription

A structural object class for use in configuring an entry to represent uniqueidentifier information for an associated DCE principal, group, organization,directory, realm, or replist. This object class is used only if thedceUniqueIDCfg attribute of the entry representing the DCE realm is set toDEFAULT. The entry representing the unique identifier information mustreside directly below the entry representing the associated DCE object andmust have a creator identity that is a trusted identity (one of the identitieslisted in the krbKdcServiceObject or krbTrustedAdmObject attribute of theentry representing the DCE realm). In addition, the cn attribute of the entryrepresenting the unique identifier information must contain the valueUniqueID. The process that creates a DCE unique identifier entry mustensure that identifier information is unique and should set the ACLs on theentry so it cannot be modified. The process that returns information from aDCE unique identifier entry must ensure that the entry was created by atrusted identity.

Sup top, Structural


v cn


v dceUUID

Optional attributes

v dceDomain

v krbRealmNave-v2

v unixID

DCEUnixDescription

An auxiliary object class for use in configuring UNIX attributes for a DCEprincipal. The UNIX attributes can reside in the entry representing the DCEprincipal, the entry that is referenced by the dceUnixObject of the entry thatrepresents the DCE principal, or both. If the same UNIX attribute resides intwo entries, DCE uses the UNIX attributes from the entry referenced bydceUnixObject.

Sup top, Auxiliary

Optional attributes

v dceUnixPassword

v gecos

v homeDirectory

v ixLastUpdate

v loginShell

v secPwdValid

v unixPwdValid

v unixPwdVersion

DCEXATTRDescription

A structural object class for use in configuring an entry to represent a DCEextended attribute (XATTR) for a DCE realm. The entry representing theDCE XATTR must reside directly below a DCE XATTRS container and musthave an RDN of dceXattrName=name, where name is the name of theextended attribute. The DCE XATTRS container must reside directly belowthe entry representing the DCE realm and must have a DN ofcn=DCEXattrs. The relationship between the entry representing the DCEXATTR and the DCE XATTRS container is many-to-one with each XATTRcontaining a different name. The relationship between the DCE XATTRScontainer and the entry that represents the DCE realm is one-to-one.

Sup top, Structural


v dceXattrDefn

v dceXattrName

v dceUUID

SecMapExtDescription

An auxiliary object class for configuration of additional attributes in an entryconfigured with the SecMap structural object class.


Sup top, Auxiliary

Optional attributes

v unixID

DCE attributesThis section describes the DCE attributes found in the LDAP schema.

dceAclDefRealmNameDescription

The name of the default DCE realm for this ACL.

SyntaxIA5 string

Value Single-valued

EqualityCase exact match

dceAclDefRealmUUIDDescription

The DCE UUID of the default DCE realm for this ACL.

SyntaxIA5 string

Value Single-valued


dceAclEntriesDescription

A list of DCE structures that define a DCE ACL for an associated DCEobject. Each DCE structure is binary data of type rsdb_acl_entry_t anddefines an entry in the DCE ACL.

SyntaxBinary

Value Multi-valued

dceBadOriginIPDescription

IP address of originator of last bad login.

SyntaxInterval

Value Single-valued

dceBadOriginStringDescription

Remote procedure call (RPC) string binding address of originator of lastbad login.


SyntaxDirectory String

Value Single-valued


dceCreateTimestampDescription

The date and time when the identity stored in the dceCreatorsUUIDattribute first added Kerberos and DCE attributes to a principal entry usingan interface that supports the setting of the dceCreateTimestamp attribute.

SyntaxInterval

Value Single-valued

dceCreatorsUUIDDescription

A pair of UUIDs separated by a colon (:) , which indicates the DCE principalthat first added Kerberos and DCE attributes to a principal entry using aninterface that supports the setting of the dceCreatorsUUID attribute. Thefirst UUID is the principal UUID and the second UUID is an optional realmUUID. If the realm UUID is absent, the UUID of the current realm is used.

SyntaxIA5 string

Value Single-valued


dceDefaultTktLifeDescription

Default time a ticket is valid. Refer to the DCE documentation forinformation on how to interpret the value in this field.

SyntaxInteger

Value Single-valued

dceDefDirAclEntriesDescription

A set of DCE structures that define the DCE default ACL for all DCEdirectories created under the associated DCE directory. Each DCE structureis binary data of type rsdb_acl_entry_t and defines an entry in the DCEACL.

SyntaxBinary

Value Multi-valued


dceDefObjAclEntriesDescription

A set of DCE structures that define the DCE default ACL for all DCE objectscreated under the associated DCE directory. Each DCE structure is binarydata of type rsdb_acl_entry_t and defines an entry in the DCE ACL.

SyntaxBinary

Value Multi-valued

dceDirNameDescription

The name of a DCE directory in the format dir@realm. DCE uses thisattribute only if an entry is NOT configured to represent a DCE principal.Otherwise, DCE uses the principal name (configured in thekrbPrincipalName attribute) as the DCE directory name.

SyntaxDirectory String

Value Single-valued


dceDisableTimeDescription

The date and time a DCE account was disabled.

SyntaxGeneralized time

Value Single-valued

dceDomainDescription

One of the following values indicating a DCE domain:

v 0=principal

v 1=group

v 2=organization

SyntaxInteger

Value Single-valued

dceDomainCacheStateDescription

DCE domain cache state attribute.


Value Single-valued


dceFullNameDescription

A descriptive name or comment.

SyntaxDirectory string

Value single valued

dceGoodOriginIPDescription

IP address of originator of the last successful login.

SyntaxInterval

Value Single-valued

dceGoodOriginStringDescription

RPC string binding address of originator of the last successful login.


Value Single-valued


dceGoodSinceDateDescription

Date when ticket was good.


Value Single-valued

dceGroupNameDescription

The name of a DCE group.


Value Single-valued


dceHintForeignMembershipUUIDsDescription

A list of UUID pairs. Each UUID pair identifies a DCE group from a foreignDCE realm of which the DCE principal represented by this entry is amember. The first UUID in the pair identifies the UUID of the group. The


second UUID in the pair identifies the UUID of the realm. An @ symbol isused as the separator between the two UUIDs.

SyntaxIA5 string

Value Multi-valued


dceHintMembershipUUIDsDescription

A set of UUIDs. Each UUID identifies a DCE group in the local DCE realmof which the DCE principal represented by this entry is a member.

SyntaxIA5 string

Value Multi-valued


dceIDDescription

An ID used by the legacy DCE database to identify the DCE legacy objectrepresented by this entry.

SyntaxInteger

Value Single-valued

dceInternalDataDescription

Internal data used by DCE.

Syntaxbinary

Value Single-valued

dceIsRequiredDescription

A boolean value indicating whether the DCE object represented in this entryis required. If this attribute is omitted, DCE assumes dceIsRequired=FALSE.

SyntaxBoolean

Value Single-valued

dceJournalIDDescription

A number indicating the numeric ID of a DCE entry in the DCE journaldatabase.


SyntaxInteger

Value Single-valued

dceKeyPartsDescription

One of the following values identifying the keys DCE objects require toidentify the account for the associated DCE principal:

v 1=DCE principal

v 2=DCE principal and DCE group

v 3=DCE principal, DCE group, and DCE organization

If this attribute is omitted, DCE assumes dceKeyParts=1 (DCE principalonly).

SyntaxInteger

Value Single-valued

dceLastUnixIDGroupDescription

Last UNIX ID assigned to a DCE group.

SyntaxIA5 string

Value Single-valued


dceLastUnixIDOrgDescription

Last UNIX ID assigned to a DCE organization.

SyntaxIA5 string

Value Single-valued


dceLastUnixIDPersonDescription

Last UNIX ID assigned to a DCE principal.

SyntaxIA5 string

Value Single-valued



dceLowUnixIDGroupDescription

The lowest UNIX ID that this DCE realm assigns to a DCE group.

SyntaxIA5 string

Value Single-valued


dceLowUnixIDOrgDescription

The lowest UNIX ID that this DCE realm assigns to a DCE organization.

SyntaxIA5 string

Value Single-valued


dceLowUnixIDPersonDescription

The lowest UNIX ID that this DCE realm assigns to a DCE principal.

SyntaxIA5 string

Value Single-valued


dceMaxUnixIDDescription

The highest UNIX ID that this DCE realm assigns to a DCE object.

SyntaxIA5 string

Value Single-valued


dceMinTktLifeDescription

A value indicating the minimum time that a Kerberos ticket issued by thisregistry is valid.

SyntaxInteger

Value Single-valued


dceModifiersUUIDDescription

A pair of UUIDs separated by the @ character, which indicates the UUID ofthe last DCE principal that modified a Kerberos or DCE attribute associatedwith this principal entry and that made the modification using an interfacethat supports the dceModifiersUUID attribute. The first UUID is the principalUUID and the optional second UUID is the realm UUID. If the second UUIDis omitted, the UUID of the current realm is used.

SyntaxIA5 string

Value Single-valued


dceModifyTimestampDescription

The date and time when the identity specified in the dceModifiersUUIDattribute made the last modification. It is the responsibility of the identity thatmade the modification to add or update the dceModifyTimstamp attribute.

SyntaxInterval

Value Single-valued

dcePasswordMaxLengthDescription

The maximum number of characters in a password.

SyntaxInteger

Value Single-valued

dcePolicyFlagsDescription

A value containing one or more of the following flags:

v sec_rgy_acct_admin_valid (0x1)

v sec_rgy_acct_admin_audit (0x2)

v sec_rgy_acct_admin_client (0x8)

v sec_rgy_acct_admin_LSUSER (0x10)

v sec_rgy_acct_admin_server (0x4)

v sec_rgy_acct_admin_none =0

SyntaxInteger

Value Single-valued

dcePrimaryGroupDescription

The UUID of the primary group to which this DCE principal is a member.


SyntaxIA5 string

Value Single-valued


dceProjlistOKDescription

A boolean value indicating whether it is okay for this group to be included inthe project list of a DCE principal. If this attribute is omitted, DCE assumesdceProjlist=FALSE.

SyntaxBoolean

Value Single-valued

dceQuotaDescription

Maximum number of DCE objects that can be added by this DCE principal.This attribute is supported only when the DCE interfaces are used to addDCE objects. This attribute is not supported when other interfaces (such asLDAP interfaces) are used to add DCE objects.

SyntaxInteger

Value Single-valued

dceReadOnlyReplicaDescription

A boolean value indicating whether this is a read-only replica server.

SyntaxBoolean

Value Single-valued

dceReadVersionDescription

A value indicating the earliest version of DCE that can correctly read fromthis DCE registry database.

SyntaxInteger

Value Single-valued

dceReplicaInfoDescription

A DCE structure of type rs_replica_mgt_item_p_t containing informationabout a DCE replication list.

SyntaxBinary


Value Single-valued

dceReplicaTwrsDescription

An array of bytes used to define a set of DCE replica towers.

SyntaxIA5 string

Value Single-valued


dceRsaCurKeyVersionDescription

The current version of an associated RSA key.

SyntaxInteger

Value Single-valued

dceRsaKeyOkDescription

If true, it is OK for the principal to have an RSA private key.

SyntaxBoolean

Value Single-valued

dceSecMapSubtreeGroupDescription

The DN of an entry representing a subtree under which SecMap entries forDCE groups are configured.

SyntaxDN

Value Single-valued

dceSecMapSubtreeOtherDescription

The DN of an entry representing a subtree under which SecMap entries forDCE objects other than DCE principals and groups are configured.

SyntaxDN

Value Single-valued

dceSecMapSubtreePrincDescription

The DN of an entry representing a subtree under which SecMap entries forDCE principals are configured.


SyntaxDN

Value Single-valued

dceShadowPwdOKDescription

If true, no protected UNIX passwords are transmitted remotely.

SyntaxBoolean

Value Single-valued

dceUnauthenticatedQuotaDescription

A value indicating the quota for unauthenticated users.

SyntaxInteger

Value Single-valued

dceUnboundTktsOKDescription

If true, all tickets generated from this DCE realm are usable at any clientsite (not bound to the host from which the client requested the certificate).The tickets contain no client addresses.

SyntaxBoolean

Value Single-valued

dceUniqueIDCfgDescription

A value indicating the configuration of DCE UUID information. The followingvalues are available:

v 1=DEFAULT (Entries of type DCEUniqueID are used to store DCEUUIDs).

v 2=SECMAP (Entries of type SecMap are used to store DCE UUIDs).

If this attribute is not configured, the DEFAULT configuration is used.

Note: DCE 3.2 supports only the default setting of this attribute.

SyntaxInteger

Value Single-valued

dceUnixObject

Note: DCE 3.2 does not use this attribute.

DescriptionThe DN of an entry for DCE to use in obtaining UNIX information for this


DCE principal. If a conflict occurs between an attribute configured in thisDCE principal entry and an attribute configured in the referenced entry,DCE uses the attribute configured in the referenced entry.

SyntaxDN

Value Single-valued

dceUnixPasswordDescription

A UNIX password associated with a DCE principal account.

SyntaxInteger

Value Single-valued

dceUUIDDescription

A DCE universal unique identifier (UUID)

SyntaxIA5 string

Value Single-valued

dceUUIDDescription

A DCE universal unique identifier (UUID)

SyntaxIA5 string

Value Single-valued

dceWriteVersionDescription

A value indicating the earliest version of DCE that can correctly write to thisDCE registry database.

SyntaxInteger

Value Single-valued

dceXattrDefnDescription

A DCE structure of type rsdb_attr_schema_entry_t, which defines a DCEextended attribute.

SyntaxBinary

Value Single-valued


dceXattrNameDescription

The name of a DCE extended attribute definition.


Value Single-valued


dceXattrValueDescription

The value of a DCE extended attribute. The value is binary data of the typedefined in an associated DCE-extended attribute definition.

SyntaxBinary

Value Single-valued

descriptionDescription

Attribute common to CIM and LDAP schema to provide lengthy descriptionsof a directory object entries.


Value Single-valued

EqualityCase ignore match

gecosDescription

User gecos information.


Value Single-valued

homeDirectoryDescription

The absolute path to the home directory.


Value Single-valued



ixLastUpdateDescription

Time of the last update.

SyntaxInteger

Value Single-valued

krbKdcServiceNameDescription

Name of a KDC service. The name must be the same as the namespecified in the serviceName attribute of the KDC service entry referencedby the krbKdcServiceObject attribute of the realm entry.


Value Single-valued


krbRealmName-V2Description

Kerberos realm name-case exact match version.


Value Single-valued


loginShellDescription

The path to the login shell.


Value Single-valued


maxFailedLoginsSyntax

Integer

Value Multi-valued with only one value supported

passwordMaxRepeatedCharsSyntax

Integer



passwordMinOtherCharsSyntax

Integer


passwordTimeReuseSyntax

Integer


secAcctLifeSyntax

Integer

Value Single-valued

secPwdAlphaSyntax

Boolean

Value Single-valued

secPwdSpacesSyntax

Boolean

Value Single-valued

secPwdValidSyntax

Boolean

Value Single-valued

timeExpireLockoutSyntax

Integer


unixIDDescription

The UNIX ID of the associated DCE principal. If the entry representing theassociated DCE principal contains a dceUnixObject attribute, and the entryreferenced by this attribute contains an uid attribute, the UNIX ID specifiedin this attribute is used and the unixID attribute is ignored.

SyntaxIA5 string


Value Single-valued


unixPwdValidDescription

If true, the UNIX password for the associated DCE principal is valid.

SyntaxBoolean

Value Single-valued

unixPwdVersionDescription

The version of the UNIX password for the associated DCE principal.

SyntaxInteger

Value Single-valued

Kerberos object classesThis section describes the Kerberos object classes in the LDAP schema.

KrbAliasDescription

An auxiliary object class for use in configuring an association between anentry containing security identity information and another entry. ThekrbAliasedObjectName is configured in the entry with security identityinformation and contains a forward reference to a target entry. ThekrbHintAliases attribute is configured in the target entry and contains abackward reference to the entry with the security identity information.Kerberos ignores the forward and backward references. However, higherlevel applications can use these references to associate a security identitywith a target entry and then verify that the target entry allows thisassociation. For example, a higher-level application can use the forwardreference to associate an entry representing a Kerberos principal with anentry representing a person, and then use the backward reference todetermine whether the entry representing the person allows thisassociation.

Sup Top, auxiliary

Optional attributes

v krbAliasedObjectName

v krbHintAliases

Note: DCE 3.2 does not support any attributes in this object class.

KrbAuthObjectDescription

Authentication information that can be added to a directory entry.


Sup Top, auxiliary


v userPassword

Optional attributes

v uid

Optional attributes

v uid

Note: DCE 3.2 does not support any attributes in this object class.

KrbKeyDescription

A structural object class for use in configuring an entry to represent a set ofKerberos keys for an associated Kerberos principal. IfkrbSecretKeyCfg=KRBKEY (which is the default), the entry that isrepresenting the Kerberos key must reside directly below the entryrepresenting the associated Kerberos principal. IfkrbSecredKeyCfg=KRBKEY-SUBTREE, the entry representing the Kerberoskey must reside directly below an entry with an RDN of ″cn=KEYS″ and the″cn=KEYS″ entry must reside directly below the realm entry. In both cases,the entry representing the Kerberos key must have a creator identity that isa KDC service in the realm or an LDAP administrator that is trusted in therealm. The DN recorded by LDAP in the creatorsName attribute of the entryrepresenting the Kerberos key must be listed in the krbKdcServiceObject orkrbTrustedAdmObject attribute of the entry representing the realm.

The relationship between the entry that represents the Kerberos key andthe entry that represents the associated Kerberos principal is many-to-one.This is because multiple Kerberos keys can be created for a single principalwith each key having a different version number, KDC service identity, orboth. The RDN of the entry representing the Kerberos key must contain astring that indicates the contents of the krbKeyVersion attribute for thatentry. For example, ″krbKeyVersion=1″. If the contents of additionalattributes are required to uniquely identity the entry, the RDN also mustinclude this information. For example, ″krbKeyVersion=1krbKdcServiceName=serverA″ or ″krbKeyVersion=1 krbPrincipalDN=AliceSmith″)

Sup top, Structural


v krbKeyVersion

v krbKeyData

Optional attributes

v krbKdcServiceName

v krbKeyExpires

v krbNextKeyVersion

v krbPrincipalDN

Note: DCE 3.2 does not use the following attributes:

v krbKdcServiceName

v krbPrincipalDn


KrbKeyCfgDescription

An auxiliary object class for use in configuring the krbSecretKeyCfg attributein the realm entry.

Sup top, Auxiliary

Optional attributes

v krbSecretKeyCfg

KrbLogDescription

A structural object class for use in configuring an entry to represent aKerberos login activity record for an associated Kerberos principal. Theentry representing the Kerberos login activity record must reside directlybelow the entry representing the associated Kerberos principal and musthave a creator identity that is a KDC service in the realm. The DN recordedby LDAP in the creatorsName attribute of the entry representing theKerberos login activity record must be listed in the krbKdcServiceObjectattribute of the entry representing the realm.)

The relationship between the entry that represents the Kerberos loginactivity record and the entry that represents the associated Kerberosprincipal is one-to-many. This is because multiple KrbLog entries can becreated for a single principal with each KrbLog entry maintained by adifferent KDC service. The RDN of the entry representing the Kerberoslogin activity must be ″cn=KrbLog″.

Sup top, Structural


v cn

Optional attributes

v badPasswordTime

v badPwdCount

v lastLogon

KrbModifierInfoDescription

An auxiliary object class used to add the KDC modifier information.

Sup top, Auxiliary


v krbModifiersName

v krbModifyTimestamp

KrbMstrKeyDescription

A structural object class for use in configuring an entry to represent aKerberos master key. The entry representing the Kerberos master key mustreside directly below an entry with an RDN of ″cn=MKEYS″ and the″cn=MKEYS″ entry must reside directly below the entry representing theKerberos realm.


The relationship between the entry representing the Kerberos master keyand the ″cn=MKEYS″ entry is many-to-one. This is because multipleKerberos master keys can be created for a single realm with each keyhaving a different version number or KDC service identity.

The RDN of the entry representing the Kerberos master key must contain astring that indicates the contents of the krbKeyVersion attribute for thatentry, for example, ″krbKeyVersion=1″. If the contents of additionalattributes are required to uniquely identity the entry, the RDN also mustinclude this information, for example, ″krbKeyVersion=1krbKdcServiceName=serverA″.

Sup top, Structural


v krbKeyVersion

v krbMstrKeyData

Optional attributes

v krbKdcServiceName

v krbKeyExpires

v krbKeyName

v krbNextKeyVersion

Note: DCE 3.2 does not use krbKdcServiceName attribute.

KrbPolicyDescription

An auxiliary object class for use in configuring Kerberos policy attributes foran associated Kerberos principal or Kerberos realm. The Kerberos policyattributes can reside in the entry representing the Kerberos principal orrealm, the entry referenced by the krbPolicyObject attribute of the entryrepresenting the Kerberos principal or realm, or both. If the same policyattribute is configured in both entries, the policy attribute from the entryrepresenting the principal or realm is used.

Some Kerberos policy values can be configured using one of two sets ofattributes. For these attributes, the krbRedundancyPolicy attribute in theentry representing the realm determines which set of attributes to use. Forexample, the maximum password lifetime value can be stored in themaxPwdAge or passwordMaxAge attribute. The krbRedundancyPolicyattribute determines which of these two attributes to use.

Note: For a DCE principal, DCE 3.2 uses the krbPolicyNameRef attributerather than the krbPolicyObject attribute of the DCE principal entry toreference an entry with policy information.

Sup top, Auxiliary

Optional attributes

v accountExpires

v krbAttributes

v krbMultKeyVersionsOK

v krbPolicyName

v maxPwdAge

v maxRenewAge


v maxTicketAge

v minPwdAge

v minPwdLength

v passwordExpireTime

v passwordDictFiles

v passwordMaxAge

v passwordMinAge

v passwordMinDiffChars

v passwordMinLength

v pwdHistoryLength

v secAcctExpires

v secAcctValid

v userAccountControl

Note: DCE 3.2 supports only the default configuration of thekrbRedundancyPolicy attribute in the realm entry. Therefore, DCE3.2 does not use the following attributes:

v account expires (use secAcctExpires instead)

v maxPwdAge (use passwordMaxAge instead)

v minPwdAge (use passwordMinAge instead)

v minPwdLength (use passwordMinLength instead)

v userAccountControl (use secAcctValid instead)

KrbPrincipalDescription

An auxiliary class for use in configuring an entry to represent a Kerberosprincipal.

Sup top, Auxiliary


v krbPrincipalName

Optional attributes

v krbCurKeyVersion

v krbExtraData

v krbPolicyNameRef

v krbPolicyObject

v krbPrincipalType

v krbSecretKeyCfg

v krbTaggedDataList

v pwdLastSet


v krbExtraData

v krbPolicyObject

v krbPolicyNameRef

v krbPrincipalType

v krbTaggedDataList


v pwdLastSet

KrbRealm-v2Description

Represents a Kerberos security realm.

Sup top, Structural


v krbPrincSubTree

v krbRealmName-v2

KrbRealmExtDescription

Auxiliary object used to configure policy attributes for a security realm or aserver within a security realm.

Sup KrbPolicy, Auxiliary

Optional Attributes

v krbAdmAclDB

v krbAdmServiceObject

v krbDeleteType

v krbEncTypeSupport

v krbKdcServiceObject

v krbKeyType

v krbPolicyObject

v krbPwdServiceObject

v krbReduncancyPolicy

v krbSaltTypeSupport

v krbTrustedAdmObject


v krbAdmAclDb

v krbAdmKeyLocation

v krbAdmServiceObject

v krbEncTypeSupport

v krbKeyType

v krbPolicyObject

v krbPwdServiceObject

v krbSaltTypeSupport

Kerberos attributesThis section describes the Kerberos attributes in the LDAP schema.

accountExpires



DescriptionA value indicating when the account expires. The value is stored as a largeinteger that represents the number of seconds elapsed since 00:00:00,January 1, 1970. A value of TIMEQ_FOREVER (-1) indicates that theaccount never expires.

SyntaxInterval

Value Single-valued

badPasswordTimeDescription

A value indicating the last time the user tried to log onto the account usingan incorrect password. The value is stored as a large integer thatrepresents the number of seconds elapsed since 00:00:00, January 1,1970. A value of zero (0) means that the last password time is unknown.Each KDC server in the realm maintains its own badPasswordTimeattribute. To get an accurate value for the user’s last bad password time inthe realm, query the badPasswordTime attribute of each KDC server, anduse the largest value.

SyntaxInterval

Value Single-valued

badPwdCountDescription

A value indicating the number of times the user tried to log on to theaccount using an incorrect password. A value of zero (0) indicates that thevalue is unknown. Each KDC server in the realm maintains its ownbadPwdCount attribute. To get an accurate value for the user’s total badpassword attempts in the realm, query the badPwdCount attribute of eachKDC server in the realm, and use the sum of the values.

SyntaxInteger

Value Single-valued

krbAdmAclDB


DescriptionThe location of an ACL database for Kerberos administration services. Thelocation must be specified in URL format, that is, FILE://path/filename.


Value Single-valued



krbAdmKeyLocation


DescriptionThe location of a keytab file containing the key used by the Kerberosadministration services. The location must be specified in URL format, forexample, FILE://path/filename


Value Single-valued


krbAdmServiceObject


DescriptionA set of references to entries, with each entry representing a Kerberosadministration service in the realm.

SyntaxDN

Value Multi-valued

EqualityDN match

krbAliasedObjectName


DescriptionContains the DN of the object pointed to by this Kerberos alias object.

SyntaxDN

Value Single-valued

EqualityDN Match

krbAttributesDescription

A value containing one or more flags. The following flags are available:

v KRB5_KDB_DISALLOW_DUP_SKEY = 0x00000020

v KRB5_KDB_DISALLOW_POSTDATED = 0x00000001

v KRB5_KDB_DIALLOW_PROXIABLE = 0x00000010

v KRB5_KDB_DISALLOW_RENEWABLE = 0x00000008

v KRB5_KDB_DIALLOW_TGT_BASED = 0x00000004

v KRB5_KDB_DISALLOW_SVR = 0x00001000

v KRB5_KDB_NEW_PRINC = 0x00008000


v KRB5_KDB_PWCHANGE_SERVICE = 0x00002000

v KRB5_KDB_REQUIRES_HW_AUTH = 0x00000100

v KRB5_KDB_REQUIRES_PWCHANGE = 0x00000200

v KRB5_KDB_SUPPORT_DESMD5 = 0x00004000

v USER_TO_USER = 0x00010000

SyntaxInteger

Value Single-valued

krbCurKeyVersionDescription

A value indicating the current version of a key.

SyntaxInteger

Value Single-valued

krbDeleteTypeDescription

Contains one of the following values defining how the DCE interfacesprocesses delete requests:

v 1=no deletes allowed

v 2=only DCE attributes deleted

v 3=only DCE and Kerberos attributes deleted

v 4=all attributes in the entry deleted

SyntaxInteger

Value Single-valued

krbEncTypeSupport


DescriptionA set of supported encryption type values. The available values are:

00 ENCTYPE_NULL01 ENCTYPE_DES_CBC_CRC

DES cbc mode with CRC-3202 ENCTYPE_DES_CBC_MD4

DES cbc mode with RSA-MD403 ENCTYPE_DES_CBC_MD5

DES cbc mode with RSA-MD504 ENCTYPE_DES_CBC_RAW

DES cbc mode raw05 ENCTYPE_DES3_CBC_SHA

DES-3 cbc mode with NIST-SHA06 ENCTYPE_DES3_CBC_RAW

DES-3 cbc mode raw


91 ENCTYPE_RSA_PRIVKEYRSA private key; required for support of DCE

99 ENCTYPE_UNKNOWN

SyntaxInteger

Value Multi-valued.

krbExtraData


DescriptionExtra data that is associated with a Kerberos principal and that has anapplication-specified meaning. This attribute is provided to support theKerberos kadmin APIs.


Value Single-valued


krbHintAliases


DescriptionA set of backward references to entries that can serve as aliases for thisentry.

SyntaxDN

Value Multi-valued

EqualityDN match

krbKdcServiceObjectDescription

A set of references to entries, with each entry representing a KDC servicein the realm.

SyntaxDN

Value Multi-valued

EqualityDN match

krbKeyDataDescription

A set of values with each value containing an encrypted key andinformation about the encrypted key. Each value is specified in the followingformat:


<enctype> <salttype> <mkeyver> <keylen> <saltlen> <keyvalue> <saltvalue>

This attribute contains the following values:

enc typeTwo decimal characters that indicate the encryption algorithm thatwas used to generate the key. See “krbEncTypeSupport” onpage 90 for a list of possible enc type values.

salt typeTwo decimal characters that indicate the type of salt value that wasused to generate the key. See “krbSaltTypeSupport” on page 98 fora list of possible salt type values.

mkey versionTwo decimal characters that indicate the version of the master keythat was used to transform the key into an encrypted key.

key lenFour decimal characters that indicate the length (in bytes) of theencrypted key.

salt lenFour decimal characters that indicate the length of the salt value(″0000″ if no salt value).

key valueThe encrypted key.

salt valueIf it is specified, this is the salt value.

For example, 01990000080000\23!\23%@!\23\24 defines an encrypted keywith a length of 8 bytes and a value of \23!\23%@!\23\24. The key wasgenerated using DES encryption and no salt value; then, encrypted withmaster key version 0. As another example,05040000140006&*&*&*&*&*&*&*mysalt defines an encrypted key with alength of 8 bytes and a value of &*&*&*&*&*&*&. The key was generatedusing triple-DES encryption with a special salt type value that has a lengthof 6 and a value of mysalt; then, encrypted with master key version 0.’

SyntaxBinary

Value multi-valued

krbKeyExpiresDescription

A value that indicates the date and time when a key expires.

SyntaxInterval

Value Single-valued

krbKeyName


DescriptionName of a secret key.



Value Single-valued


krbKeyType


DescriptionA set of key types. Each key type is specified in the following format:0 1 2 3 4+--+--+--+--+| enc |salt ||type |type |+--+--+--+--+

This attribute contains the following values:

enc typeTwo decimal characters indicating the encryption type of the key.See “krbEncTypeSupport” on page 90 for a list of available values.

salt typeTwo decimal characters that indicate the salt type of the key. See“krbSaltTypeSupport” on page 98 for a list of available values.

For example, ″0199″ indicates a key that is generated with DES encryptionand no salt. As another example, ″0500″ indicates that a key that isgenerated using triple DES encryption and a normal salt type value

SyntaxIA5 string

Value Multi-valued

krbKeyVersionDescription

Version of a secret key.

SyntaxInterval

Value Single-valued

krbModifiersNameDescription

Name of the principal that last modified a KDC attribute associated with thisprincipal entry and that makes the modification using an interface that willset the the krbModifiersName attribute when the modification is made.


Value Single-valued


EqualityCase ignore match

krbModifyTimestampDescription

Time that the principal specified in the krbModifiersName attribute made themodification using an interface that supports the setting of thekrbModifyTimestamp attribute.

SyntaxInterval

Value Single-valued

krbMstrKeyDataDescription

A set of master key data. For each master key, it contains either the masterkey value or the URL address where the master key value is stored andinformation about the master key. Data about each master key is specifiedin the following format:0 10 1 2 3 4 5 6 7 8 9 0 1 2 3 4+--+--+--+--+--+--+--+--+--+--+--+--+--+--+----------+-----------+|enc |salt |value|mkeylen or| salt |mkey value| salt ||type |type |orURL|mkeyURL len| len |or mkeyURL| value |+--+--+--+--+--+--+--+--+--+--+--+--+--+--+----------+-----------+

This attribute contains the following information:

enc typeTwo decimal characters that indicate the encryption algorithm thatwas used to generate the master key. See “krbKeyType” onpage 93 for a list of enc type values.

salt typeTwo decimal characters that indicate the type of salt value that wasused to generate the master key. See “krbKeyType” on page 93 fora list of salt type values.

value or URLContains the decimal characters ″00″ if the master key value isstored in krbMstrKeyData or ″01″ if the URL address of the masterkey value is stored in krbMstrKeyData.

mkeylen or mkeyref lenFour decimal characters that indicate the length (in bytes) of eitherthe master key value or the URL address where the master key isstored.

salt lenFour decimal characters that indicate the length (in bytes) of thesalt value. 0000 represents no salt value.

mkey value or mkeyURLContains either the master key value or the URL address where themaster key is stored.

salt valueThe salt value. This value might not be specified.


For example, 01990000080000\23!\23%@!\23\24 defines a master keyvalue with a length of 8 bytes and a value of \23!\23%@!\23\24. The keywas generated using DES encryption and no salt value. As anotherexample, 05040100180006file://mypath/mkeymysalt defines a master keythat is stored at the URL address of file://mypath/mkey and this URLaddress has a length of 18 bytes. The master key was generated usingtriple-DES encryption with a special salt type value that has a length of 6bytes and a value of mysalt.

SyntaxBinary

Value Multi-valued

krbMultKeyVersionsOKDescription

True if multiple versions of a key for each encryption type can be stored forthis account.

SyntaxBoolean

Value Single-valued

krbNextKeyVersionDescription

A value that indicates the next version of a key.

SyntaxInteger

Value Single-valued

krbPolicyNameDescription

Name for a Kerberos policy in the form policy@realm. policy is the name ofa policy and must be unique within the realm. realm is the name of therealm. The realm name must conform to the rules described in RFC 1510and must be the same as the realm name specified in thekrbRealmName-v2 attribute of the realm entry. Also the name of a DCEorganization in the form of policy@realm.


Value Single-valued


krbPolicyNameRefDescription

Name for a policy in the form policy@realm. policy is the name of a policyand must be unique within the realm. realm is the name of the realm. Therealm name must conform to the rules described in RFC 1510 and must be


the same as the realm name specified in the krbRealmName-v2 attribute ofthe realm entry. This attribute must contain the name of a DCEorganization.


Value Single-valued


krbPolicyObject


DescriptionForward reference to an entry containing policy information.

SyntaxDN

Value Single-valued

EqualityDN match

krbPrincipalDN


DescriptionForward reference to an associated principal entry.

SyntaxDN

Value Single-valued

EqualityDN match

krbPrincipalNameDescription

Kerberos principal identity for a user in the form principal@realm. Forexample, mary@myrealm


Value Single-valued


krbPrincipalType


DescriptionValue defining the type of a principal. The available principal type valuesare:


0 KRB5_NT_UNKNOWN1 KRB5_NT_PRINCIPAL2 KRB5_NT_SRV_INST3 KRB5_NT_SRV_HST4 KRB5_NT_SRV_XHST5 KRB5_NT_UID

SyntaxInteger

Value Single-valued

krbPrincSubTreeDescription

A set of forward references to an entry that starts a sub-tree whereprincipals, groups, and organizations in the realm are configured.

SyntaxDN

Value Multi-valued

EqualityDN match

krbPwdServiceObject


DescriptionA set of references to entries, with each entry representing a passwordservice in the realm.

SyntaxDN

Value Multi-valued

EqualityDN match

krbRealmName-v2Description

Kerberos realm name-case exact version.


Value Single-valued


krbRedundancyPolicyDescription

Contains one of the following values that indicate which set of attributes touse for those attributes that have the same logical meaning:

01 Use the set of attributes from the Netscape or IBM and Tivolischema. This is the default.


02 Use the set of attributes from the Microsoft schema.

If this attribute is not configured, the default is used.

Note: DCE 3.2 supports only the default setting for this attribute.The following table lists the sets of attributes that have the same logicalmeanings and the schemas in which these attributes are defined.

Netscape or IBM and Tivoli Schema Microsoft Schema

passwordExpireTime computed from pwdLastSet and maxPwdAge

passwordMaxAge maxPwdAge

passwordMinAge minPwdAge

passwordMinLength minPwdLength

secAcctExpires accountExpires

secAcctValid userAccountControl (!Account Disable)

SyntaxInteger

Value Single-valued

krbSaltTypeSupport


DescriptionA set of values that define the supported salt types. The available valuesare:

00 KRB5_KDB_SALTTYPE_NORMAL01 KRB5_KDB_SALTTYPE_V402 KRB5_KDB_SALTTYPE_NOREALM03 KRB5_KDB_SALTTYPE_ONLYREALM04 KRB5_KDB_SALTTYPE_SPECIAL05 KRB5_KDB_SALTTYPE_AFS399 KRB5_KDB_NO_SALT_VALUE

SyntaxInteger

Value Multi-valued

krbSecretKeyCfgDescription

Contains one of the following values that indicate where the secret key for aKerberos principal is configured.

1 = KRBKEYIndicates that the secret key is stored in one or more KrbKeyentries with each KrbKey entry residing directly below theassociated principal entry. This is the default.

2 = KRBKEY-SUBTREEIndicates that the secret key is stored in one or more KrbKey


entries with each KrbKey entry residing directly below an entry withan RDN of ″cn=KEYS″ and with the ″cn=KEYS″ entry residingdirectly below the realm entry.

3 = USERPASSWORDIndicates that the secret key is stored in the userPassword attributeof the entry representing the principal entry.

4 = PROPRIETARYIndicates that the secret key is stored in a proprietary database.

If this attribute is not configured, the default is used.

Note: DCE 3.2 supports only the default setting for this attribute.

SyntaxInteger

Value Single-valued

krbTaggedDataList

Note: DCE 3.2 does not support this attribute.

DescriptionSet of tagged data structures that is associated with a Kerberos principaland that is defined by a Kerberos kadmin application.

SyntaxBinary

Value multi-valued

krbTrustedAdmObjectDescription

A set of forward references to trusted administration tools.

SyntaxDN

Value Multi-valued

EqualityDN match

lastLogonDescription

A value that indicates when the last logon occurred. The value is stored asa large integer that represents the number of seconds elapsed since00:00:00, January 1, 1970. A value of zero (0) means that the last logontime is unknown. Each KDC server maintains its own lastLogon attribute. Toget an accurate value for the user’s last logon in the domain, query thelastLogon attribute of each KDC server in the realm, and use the largestvalue.

SyntaxInterval

Value Single-valued


logTypeDescription

Value defining the type of log. The value 0 indicates a Kerberos type log.

SyntaxInterval

Value Single-valued

maxPwdAge


DescriptionA value indicating the maximum amount of time, in seconds, after which thepassword must be changed by the owner.

SyntaxInterval

Value Single-valued

maxRenewAgeDescription

Value indicating the maximum renewable lifetime, in seconds, of a Kerberosticket.

SyntaxInterval

Value Single-valued

maxTicketAgeDescription

A value indicating the maximum lifetime, in seconds, of a Kerberos ticket.

SyntaxInterval

Value Single-valued

minPwdAge


DescriptionA value indicating the minimum amount of time, in seconds, before thepassword is allowed to be changed.

SyntaxInterval

Value Single-valued

minPwdLength



DescriptionA value indicating the minimum number of characters that must be typed infor a password.

SyntaxInteger

Value Single-valued

passwordDictFilesDescription

A set of password dictionary files.


Value Multi-valued


passwordExpireTimeDescription

Defines, in YYYYMMDDHHMMSS format, the date and time when a userpassword expires.

SyntaxGeneralized Time

Value Single-valued

passwordMaxAgeDescription

Specifies, in seconds, the period of time passwords can be used beforethey expire.

SyntaxInteger

Value Multi-valued with only one value supported.

passwordMinAgeDescription

Specifies, in seconds, the period of time a password must be in effectbefore a user can change it.

SyntaxInteger


passwordMinDiffCharsDescription

Specifies the minimum number of different (unique) characters that arerequired for a user’s password.

SyntaxInteger



passwordMinLengthDescription

Specifies the minimum number of characters that are required for a user’spassword.

SyntaxInteger


pwdHistoryLengthDescription

A value indicating the number of previous passwords saved in the historylist. The user cannot reuse a password that is in the history list.

SyntaxInteger

Value Single-valued

pwdLastSet


DescriptionA value indicating when the user last set the password. The value is storedas a large integer that represents the number of seconds elapsed since00:00:00, January 1, 1970. The system uses the value of this property andthe maxPwdAge property of the domain containing the user object tocalculate the password expiration date (sum of pwdLastSet for the user andmaxPwdAge of the user’s domain).

SyntaxInterval

Value Single-valued

secAcctExpiresDescription

The date when a security account expires.


Value Single-valued

secAcctValidDescription

A boolean value indicating whether a security account is valid.

SyntaxBoolean

Value Single-valued


userAccountControlDescription

A value containing one or more attributes that apply to an account. Eachattribute is set with a flag. Refer to the Microsoft® Active Directorydocumentation for a complete list of flags. The following flags are used inthis KDC LDAP schema:

UF_ACCOUNT_DISABLE = 0x0001UF_DONT_EXPIRE_PASSWD = 0x10000UF_TRUSTED_FOR_DELEGATION = 0x80000UF_USE_DES_KEY_ONLY = 0x200000UF_DONT_REQUIRE_PREAUTH = 0x400000

Note: DCE 3.2 does not use the UF_ACCOUNT_DISABLE flag.

SyntaxInteger

Value Single-valued



Appendix C. Notices

This information was developed for products and services offered in the U.S.A. IBMmight not offer the products, services, or features discussed in this document inother countries. Consult your local IBM representative for information on theproducts and services currently available in your area. Any reference to an IBMproduct, program, or service is not intended to state or imply that only that IBMproduct, program, or service may be used. Any functionally equivalent product,program, or service that does not infringe any IBM intellectual property right may beused instead. However, it is the user’s responsibility to evaluate and verify theoperation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter in thisdocument. The furnishing of this document does not give you any license to thesepatents. You can send license inquiries, in writing, to:

IBM Director of LicensingIBM CorporationNorth Castle DriveArmonk, NY 10504-1785U.S.A.

For license inquiries regarding double-byte (DBCS) information, contact the IBMIntellectual Property Department in your country or send inquiries, in writing, to:

IBM World Trade Asia Corporation Licensing2-31 Roppongi 3-chome, Minato-kuTokyo 106, Japan

The following paragraph does not apply to the United Kingdom or any othercountry where such provisions are inconsistent with local law:INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THISPUBLICATION “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSOR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIESOF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR APARTICULAR PURPOSE. Some states do not allow disclaimer of express orimplied warranties in certain transactions, therefore, this statement may not apply toyou.

This information could include technical inaccuracies or typographical errors.Changes are periodically made to the information herein; these changes will beincorporated in new editions of the information. IBM may make improvementsand/or changes in the product(s) and/or the program(s) described in this informationat any time without notice.

Any references in this information to non-IBM Web sites are provided forconvenience only and do not in any manner serve as an endorsement of thoseWeb sites. The materials at those Web sites are not part of the materials for thisIBM product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it believesappropriate without incurring any obligation to you.

Licensees of this program who wish to have information about it for the purpose ofenabling: (i) the exchange of information between independently created programs


and other programs (including this one) and (ii) the mutual use of the informationwhich has been exchanged, should contact:

IBM CorporationDepartment LZKS11400 Burnet RoadAustin, TX 78758U.S.A.

Such information may be available, subject to appropriate terms and conditions,including in some cases, payment of a fee.

The licensed program described in this document and all licensed material availablefor it are provided by IBM under terms of the IBM Customer Agreement, IBMInternational Program License Agreement, or any equivalent agreement betweenus.

Any performance data contained herein was determined in a controlledenvironment. Therefore, the results obtained in other operating environments mayvary significantly. Some measurements may have been made on development-levelsystems and there is no guarantee that these measurements will be the same ongenerally available systems. Furthermore, some measurement may have beenestimated through extrapolation. Actual results may vary. Users of this documentshould verify the applicable data for their specific environment.

Information concerning non-IBM products was obtained from the suppliers of thoseproducts, their published announcements or other publicly available sources. IBMhas not tested those products and cannot confirm the accuracy of performance,compatibility or any other claims related to non-IBM products. Questions on thecapabilities of non-IBM products should be addressed to the suppliers of thoseproducts.

All statements regarding IBM’s future direction or intent are subject to change orwithdrawal without notice, and represent goals and objectives only.

All IBM prices shown are IBM’s suggested retail prices, are current and are subjectto change without notice. Dealer prices may vary.

This information contains examples of data and reports used in daily businessoperations. To illustrate them as completely as possible, the examples include thenames of individuals, companies, brands, and products. All of these names arefictitious and any similarity to the names and addresses used by an actual businessenterprise is entirely coincidental.

COPYRIGHT LICENSE:

This information contains sample application programs in source language, whichillustrates programming techniques on various operating platforms. You may copy,modify, and distribute these sample programs in any form without payment to IBM,for the purposes of developing, using, marketing or distributing application programsconforming to the application programming interface for the operating platform forwhich the sample programs are written.

These examples have not been thoroughly tested under all conditions. IBM,therefore, cannot guarantee or imply reliability, serviceability, or function of theseprograms. You may copy, modify, and distribute these sample programs in any form


without payment to IBM for the purposes of developing, using, marketing, ordistributing application programs conforming to IBM’s application programminginterfaces.

If you are viewing this information softcopy, the photographs and color illustrationsmay not appear.

TrademarksThe following terms are trademarks of International Business Machines Corporationin the United States, other countries, or both:

AIXDB2IBMSecureWay

Tivoli is trademark of Tivoli Systems Inc. or International Business MachinesCorporation in the United States, other countries, or both.

Microsoft and Windows NT are registered trademarks of Microsoft Corporation inthe United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and othercountries.

Kerberos is a trademark of the Massachusetts Institute of Technology (MIT).

Other company, product or service names may be the trademarks or service marksof others.

Appendix C. Notices 107


Index

Aaccess control

configuring 22entries under referenced sub-tree entries 23entries under the realm entry 23realm entry 23

accounts, reserved 12ACLs

container 6appendix

DCE and Kerberos Schema 61default DCE LDAP tree 57notices 105

attributekrbModifiersName 93krbModifyTimestamp 94logType 100

attributesDCE 67deleting 42Kerberos 87

Bbackup of registry database 44benefits of LDAP integration 1

Ccommands 48

config.dce 49dcecp registry ldapdelete 51dcecp registry migrate 53registry modify 56

config.dce 49configuration 37configuring LDAP security servers 37, 49container ACLs 6

Ddata consistency 13data structure 5

LDAP 5legacy 5

DCE aliases 6DCE attributes 67

dceAclDefRealmName 67dceAclDefRealmUUID 67dceAclEntries 67dceBadOriginIP 67dceBadOriginString 67dceCreateTimestamp 68dceCreatorsUUID 68dceDefaultTktLife 68dceDefDirAclEntries 68dceDefObjAclEntries 69

DCE attributes (continued)dceDirName 69dceDisableTime 69dceDomain 69dceDomainCacheState 69dceFullName 70dceGoodOriginIP 70dceGoodOriginString 70dceGoodSinceDate 70dceGroupName 70dceHintForeignMembershipUUIDs 70dceHintMembershipUUIDs 71dceID 71dceInternalData 71dceIsRequired 71dceJournalID 71dceKeyParts 72dceLastUnixIDGroup 72dceLastUnixIDOrg 72dceLastUnixIDPerson 72dceLowUnixIDGroup 73dceLowUnixIDOrg 73dceLowUnixIDPerson 73dceMaxUnixID 73dceMinTktLife 73dceModifiersUUID 74dceModifyTimestamp 74dcePasswordMaxLength 74dcePolicyFlags 74dcePrimaryGroup 74dceProjlistOK 75dceQuota 75dceReadOnlyReplica 75dceReadVersion 75dceReplicaInfo 75dceReplicaTwrs 76dceRsaCurKeyVersion 76dceRsaKeyOk 76dceSecMapSubtreeGroup 76dceSecMapSubtreeOther 76dceSecMapSubtreePrinc 76dceShadowPwdOK 77dceUnauthenticatedQuota 77dceUnboundTktsOK 77dceUniqueIDCfg 77dceUnixObject 77dceUnixPassword 78dceUUID 78dceWriteVersion 78dceXattrDefn 78dceXattrName 79dceXattrValue 79description 79gecos 79homeDirectory 79ixLastUpdate 80loginShell 80maxFailedLogins 80


DCE attributes (continued)passwordMaxRepeatedChars 80passwordMinOtherChars 81passwordTimeReuse 81secAcctLife 81secPwdAlpha 81secPwdSpaces 81secPwdValid 81timeExpireLockout 81unixID 81unixPwdValid 82unixPwdVersion 82

DCE object classes 61DCEAcl 61DCEDir 61DCEERA 61DCEGroup 62DCELegacyDB 62DCELogExt 62DCEOrg 63DCEPolicy 63DCEPrincipal 64DCERealm 64DCEReplist 65DCEUniqueID 65DCEUnix 66DCEXATTR 66SecMapExt 66

DCE objects 5, 57cn=attrschema 57cn=group 57cn=mkey 58cn=organization 58cn=principal 58cn=replist 59cn=uniqueID 59krbRealmName-v2=<cell_name> 57

DCE security service, overview of 1DCE server entries, configuring 20DCE version required for LDAP 9dcecp registry ldapdelete 51dcecp registry migrate 53deleting LDAP data from DCE 51deleting LDAP security slaves 46designating a new LDAP security master 47diagrams

LDAP migration server 25LDAP security master and LDAP security slave 26legacy security server 3security overview 13

DNs, referencing 41

EERA’s, user-defined 5error messages, LDAP 42

Ffigures

LDAP migration server 25

figures (continued)LDAP security master and LDAP security slave 26legacy security server 3security overview 13

force migration 30

Ggroups, storing in LDAP 11

Iinitialization options, LDAP 41

Jjournal, design in LDAP 5

KKerberos

integration with DCE security data 10planning considerations 10

Kerberos attributes 87accountExpires 87badPasswordTime 88badPwdCount 88krbAdmAclDB 88krbAdmKeyLocation 89krbAdmServiceObject 89krbAliasedObjectName 89krbAttributes 89krbCurKeyVersion 90krbDeleteType 90krbEncTypeSupport 90krbExtraData 91krbHintAliases 91krbKdcServiceName 80krbKdcServiceObject 91krbKeyData 91krbKeyExpires 92krbKeyName 92krbKeyType 93krbKeyVersion 93krbMstrKeyData 94krbMultKeyVersionsOK 95krbNextKeyVersion 95krbPolicyName 95krbPolicyNameRef 95krbPolicyObject 96krbPrincipalDN 96krbPrincipalName 96krbPrincipalType 96krbPrincSubTree 97krbPwdServiceObject 97krbRealmName-v2 97krbRealmName-V2 80krbRedundancyPolicy 97krbSaltTypeSupport 98krbSecretKeyCfg 98


Kerberos attributes (continued)krbTaggedDataList 99krbTrustedAdmObject 99lastLogon 99maxPwdAge 100maxRenewAge 100maxTicketAge 100minPwdAge 100minPwdLength 100passwordDictFiles 101passwordExpireTime 101passwordMaxAge 101passwordMinAge 101passwordMinDiffChars 101passwordMinLength 102pwdHistoryLength 102pwdLastSet 102secAcctExpires 102secAcctValid 102userAccountControl 103

Kerberos object classes 82KrbAlias 82KrbAuthObject 82KrbKey 83, 84KrbLog 84KrbMstrKey 84KrbPolicy 85KrbPrincipal 86KrbRealm-v2 87KrbRealmExt 87

LLDAP

access control 22benefits of integration 1default tree 57error messages 42initialization options 41planning considerations 9security data structure 5supported versions 9

LDAP access controlconfiguring 22entries under referenced sub-tree entries 23entries under the realm entry 23realm entry 23

LDAP bind protocolconfiguring 14SASL CRAM-MD5 bind 17SASL CRAM-MD5 bind with SSL 18SASL SSL bind 19simple bind 15simple bind with SSL 15

LDAP datadeleting from DCE 51

LDAP error messages 42LDAP initialization options 41LDAP master security servers

converting to LDAP security slaves 46creating from LDAP security slaves 45

LDAP master security servers (continued)designating new 47diagram of 26migrating from legacy masters 30migrating from migration servers 31, 35overview of 26recovering 45

LDAP migration serversdiagram of 25migrating from legacy slaves 29, 31migrating to LDAP security masters 31, 35overview of 25

LDAP security serversconfiguring 37integration with Kerberos 10master and slave, diagram of 26migration 26migration servers 25migration servers, diagram of 25overview of 3, 25security 4unconfiguring 38

LDAP slave security serversconfiguring 37converting from an LDAP security master 46converting to LDAP security masters 45diagram of 26forcibly deleting 46migrating from legacy slaves 29, 32overview of 26recovering 46returning to legacy slaves 40

LDIF files 10legacy database, security of 3legacy master security servers

migrating to LDAP security masters 30migrating to migration servers 34unconfiguring 31

legacy security serversdiagram of 3overview of 2

legacy slave security serversmigrating to LDAP security slaves 29, 32migrating to migration servers 29, 31

limitations 6container ACLs 6DCE aliases 6primary names 6renaming principals, groups, and orgs 6sec_admin -s 6using dcecp catalog commands to search multiple

subtrees 6login information 5

Mmaster key, planning considerations 12migration 26, 53

allowed scenarios 27forced 30, 35legacy masters to LDAP security masters 30

Index 111

migration (continued)legacy masters to migration servers 34legacy slaves to LDAP security slaves 29, 32legacy slaves to migration servers 29, 31migration servers to LDAP security masters 31, 35overview of 28prerequisites 28recommended scenario 29

migration serversdiagram of 25migrating from legacy masters 34migrating from legacy slaves 29, 31migrating to LDAP security masters 31, 35overview of 25

Nnotices 105

Oobject classes

KrbModifierInfo 84objects

deleting 42orgs, storing in LDAP 11

Pplanning considerations 9

accounts 12configuring an LDAP access control 22configuring an LDAP bind protocol 14configuring DCE server entries 20configuring realm entries 21data consistency 13DCE version 9Kerberos integration 10LDAP directory considerations 10LDIF files 10master key considerations 12principals 12reserved principals and accounts 12security configuration 13security considerations 24security overview 13storing principals, groups, and orgs 11

primary names, storing in LDAP 6principals

reserved 12storing in LDAP 11

Rream entries, configuring 21recovering LDAP security slaves 46registry database

backing up 44restoring 45

registry modify 56

registry version, raising 29, 36renaming principals, groups, and orgs 6restoring the registry database 45

SSASL CRAM-MD5 bind

configuring 17with SSL 18

SASL CRAM-MD5 bind with SSL, configuring 18SASL SSL bind, configuring 19schema 61

DCE attributes 67DCE object classes 61Kerberos attributes 87Kerberos object classes 82planning considerations 10

searching multiple subtrees 6secuirty configuration

configuring DCE server entries 20configuring LDAP access control 22configuring realm entries 21LDAP bind protocol 14security overview 13

securityLDAP registry 4legacy database 3overview 13

security data, consistency 13security overview

diagram of 13security servers

configuring 37LDAP 3, 25LDAP migration servers 25LDAP security masters 26LDAP slave security servers 26legacy 2migration of 26

security service, overview of 1server entries, configuring 20simple bind

configuring 15with SSL 15

simple bind with SSL 15SSL

SASL SSL bind 19with SASL CRAM-MD5 bind 18with simple bind 15

Ttroubleshooting 43

backing up the registry database 44converting an LDAP security master to an LDAP

security slave 46deleting LDAP security slaves 46designating a new LDAP security master 47recovering LDAP security slaves 46recovering the LDAP security master 45restoring the registry database 45


Uunconfiguration 38UniqueID 5user-defined ERA’s 5

Index 113


��

Printed in the United States of Americaon recycled paper containing 10%recovered post-consumer fiber.