1 / 12

DIRECT: DIrectory REplication CoordinaTion May 2000 < Peter.Valkenburg@surfnet.nl >

DIRECT: DIrectory REplication CoordinaTion May 2000 < Peter.Valkenburg@surfnet.nl >. Why?. Migration X.500 flDSA of various countries to LDAPv3-only No LDAP “root” level server Connectivity loss => islands Internet wide tendency towards LDAP. Goal. Set up LDAPv3 coordination

binta
Télécharger la présentation

DIRECT: DIrectory REplication CoordinaTion May 2000 < Peter.Valkenburg@surfnet.nl >

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. DIRECT: DIrectory REplication CoordinaTion May 2000 <Peter.Valkenburg@surfnet.nl>

  2. Why? • Migration X.500 flDSA of various countries to LDAPv3-only • No LDAP “root” level server • Connectivity loss => islands • Internet wide tendency towards LDAP

  3. Goal • Set up LDAPv3 coordination • Investigate replication scenarios for LDAP servers • Assist in migration X500 => LDAP • Prepare a sustainable service by DANTE

  4. Deliverables • LDIF referral file with referrals to flDSA’s • Investigation into usability of LDIF file in flDSA’s • Documentation

  5. Structure • NameFLOW service holds references to all flDSA’s and produces LDIF referral file • National LDAP flDSA’s absorb LDIF file with scripts • Nameflow provides LDAP access to the root DSA

  6. Structure c=DE c=SE Update by script LDAP gateway ….. LDAP flDSA’s c=NL c=SE ….. Nameflow root server LDIF by script flDSA’s (X.500&LDAP) c=DE …...

  7. LDIF file format dn: c=PT objectClass: top objectClass: country objectClass: domainRelatedObject objectClass: friendlyCountry objectClass: labeledURIObject objectClass: referral countryName: PT friendlyCountryName: Portugal associatedDomain: pt labeledURI: http://s700.uminho.pt/Portugal/all-pt.html WWW servers in Portugal ref: ldap://ldap.nameflow.net:1389/c=PT dn: c=SE objectClass: top objectClass: country objectClass: referral countryName: SE ref: ldap://kybele.umdc.umu.se:389/c=SE

  8. Problems • No standardised replication (IETF LDUP?) • Referrals work the wrong way (IETF LDAPEXT?)

  9. Problems • No standardised replication (IETF LDUP?) • Referrals work the wrong way (IETF LDAPEXT?)

  10. Listing LDAPv3 referrals typical LDAP flDSA LDAPv3 client objectClass: referral ref: ldap://kybele.umdc.umu.se:389/c=SE ….. objectClass: referral ref: ldap://ldap.nameflow.net:1389/c=PT Each referral is followed in a onelevel search!

  11. Fixing LDAPv3 referrals • Should be fixed at protocol level • Now fixed in Innosoft IDDS by server flag so that it only returns referrals when searching below the naming context of the referral • Feature will be kept in IPlanet 5.0 (fusion of Netscape and Innosoft IDDS)

  12. What next? • Look at possible deal with Netscape for NRN flDSA’s • Finish report/documentation • Make scripts available • Create awareness in IETF for referral and replication shortcomings

More Related