This document provides an overview and agenda for Domain Services for Windows (DSfW). DSfW allows users from an eDirectory tree to access resources on an Active Directory forest using a cross-forest trust. The document discusses what DSfW is, prerequisites for implementation, deployment scenarios including a new domain configuration and adding DSfW to an existing eDirectory tree, and a demonstration of deployment. It also covers DSfW in later versions of Open Enterprise Server and support for third-party applications like Citrix.

1. Domain Services for Windows: Best Practices for Windows Interoperability Biswajeet Mahapatra Product Manager [email_address] David Shepherd Senior Technical Specialist [email_address]

2. What is Domain Services for Windows (DSfW)? Prerequisites for Successful Implementation Deployment Scenarios Demonstration DSfW in OES2 SP2 and beyond Third Party Applications Support Agenda

3. What is Domain Services for Windows?

4. What is Domain Services for Windows? Domain Services for Windows (DSfW) is a suite of technologies Provides AD style authentication to users, applications eDirectory ™ users can access AD resources and applications with a cross forest trust in place Access to Open Enterprise Server services like file and print services hosted on Novell Storage Services ™ or POSIX file systems is unchanged

5. DSfW: What Does It Achieve? eDirectory ™ Tree Active Directory Forest DSfW DSfW Cross Forest Trust Resource Access eDirectory User Windows User AD Style Authentication MMC Add/Modify User iManager Clientless Access Applications

6. Benefits of DSfW Access Novell ® Open Enterprise Server (OES) file system without a Novell Client ™ on the workstation Single Identity and single login to access resources from Linux, AD and other services Standardized administration tool in a heterogeneous environment Applications needing AD style Authentication can be seamlessly used with OES deployments Integration of Windows desktops into a Linux environment Leverage existing eDirectory ™ tree to create a AD forest without rip-and-replace.

7. Prerequisites for Successful Implementation

8. Understand What You Are Trying To Achieve with DSfW Client-less authentication and access to Novell ® resources?

9. Access to AD applications? Check if Windows based application is going to work with DSfW Can it be in a DSfW Forest? (NetApp, Citrix)

10. Does it need an AD forest with Trust established (SharePoint)

11. Examine your existing eDirectory ™ structure: eDirectory designs with a hierarchical structure of Organization objects is more suited for DSfW than a flat structure Domain Name: The first DSfW servers DNS Suffix needs to match the AD Domain Name and suffix. For example if your AD domain name is dc=novell,dc=com then the DNS Suffix needs to be novell.com Schema checks: Check your schema in accordance with Novell ® TID 7003431 Partitioning and replication: Check the general tree health and how the existing partitions map to DSfW Planning Considerations

12. Planning Considerations DSfW into an existing tree eDirectory ™ versions need to be up to date.

13. At least one existing eDirectory 8.8 Server should be in the tree with the rest at 8.73.10 or later.

14. Put at least one Open Enterprise Server 2 Linux Server in place to begin with with any NetWare ® 6.5 Servers on SP8

15. Time synchronization is key. Kerberos is also time sensitive

16. Deployment Options

17. New Domain Non-Name Mapped Configuration Characteristics: eDirectory ™ tree is new

18. The AD Forest is created at the Tree Root as a hierarchy of DC objects.

19. The DC objects are actual eDirectory objects

20. User administrator is created in cn=administrator,cn=users,dc=example,dc=com server 1 server 2 server 3 server 4 server 5 dc=example, dc=com Domain Controllers

21. New Domain Non-Name Mapped Configuration Why would this be used? Single Server Tree

22. New Tree just for DSfW. No other Novell ® application considerations

23. The eDirectory ™ Tree Administrator is also the DSfW Administrator. No eDirectory user called admin is created

24. A domain is automatically mapped to the eDirectory container e.g. domain acme.com is mapped to container dc=acme,dc=com

25. Into Existing eDirectory ™ Trees Name-Mapped Configuration Characteristics An existing eDirectory Tree's partitioned container is used to map the DSfW domain The eDirectory Tree Administrator is different from the First Domain Administrator The domain mapping to eDirectory Tree is managed by the eDirectory Tree Administrator

26. Into Existing eDirectory ™ Trees Name-Mapped Configuration Why would this be used ? To add DSfW to an existing eDirectory environment

27. To allow the use of Novell Workstations without the Novell Client ™

28. To preserve use of existing Novell based applications such as GroupWise ® and the Novell Client

29. Microsoft Applications access can be established through an AD style trust

30. Demonstration of Deployment