Welcome • Services • Getting Started • Support and Tools • Documentation  
 
 

Report to e-Architecture Working Group

Updated: 07/25/2001

News (2001-07-25)

  • New staffing: Alex D. plus recruit
  • New hardware ordered: 4 Dells, ~ $25K
  • New (unofficial) web site: http://ldap-project.berkeley.edu/calnet-ad/

CalNet-AD Integration

  1. CalNet ID will be used for Windows desktop login
  2. CalNet Directory public information will be synchronized to AD
  3. DNS namespace for AD will support DDNS for most domains but reverse-lookup data will not be modified

Architectural implications

  1. CalNet ID will be used for Windows desktop login:
    • Kerberos credentials will be accessible to applications on Windows desktops and servers for authentication needs
    • Web and other apps will have another authentication API (SSPI) available for securing applications
    • MIT-based Kerberos-enabled apps can use AD (CalNet) credentials with code allowing access to Windows credentials cache. Carnegie Mellon and other schools have written code to copy the MIT TGT to the standard MIT credentials cache location.
  2. CalNet Directory public information will be synchronized to AD:
    • CalNet Directory information will be accessible to applications on Windows desktops and servers for authorization and other needs
    • Web and other apps will have another API (ADSI) available for authorization and other directory lookups
    • LDAP-based apps will have another source for consistent directory data
  3. DNS namespace for AD will support DDNS for most domains but reverse-lookup data will not be modified:
    • The OS does not require reverse-lookup support, but future apps might do so. This is a potential issue to watch when deploying AD-based apps. Workarounds: servers in forest root domain (berkeley.edu), if that domain will be hosted there; manual PTR resource records in DNS (messy and wouldn't scale)

References

  
Contact Us