Life without the Novell Client

Life Without theNovell Client™

Some ideas to consider . . .

Lothar WegnerSr. Technology Sales SpecialistNovell, [email protected]

Greg WhiteSr. Technology Sales SpecialistNovell, [email protected]

© Novell, Inc. All rights reserved.2

What does the Novell Client™ do?– The Novell Client is one of the key ingredients to maintaining

the NetWare® Core Protocol on your network.> What does NetWare Core Protocol do?

– It is responsible for delivering of NetWare services involving traditional access to Novell Storage Services™, eDirectory™ and ZENworks® for Desktop v/4.x thru v/7.x.

– If you are eliminating the Novell Client, you have to replace these client services with something else.

– Managing services using ConsoleOne® will still require the Novell Client software.

> Of latest version of Novell products, only GroupWise® still requires it.

Overview


Novell Client™

Why would getting rid of Novell Client be a good thing?

– Simplified workstation deployment in a mixed environment

– Reduced administration

– Eliminate end-user complexity in a mixed environment

– Application or service compatibility

– Politics


Novell Client™

Why is getting rid of Novell Client software a “bad idea”?

– It complicates the network setup and mandates the use of CIFS and the LDAP protocol.

– For users of ZENworks® v.4.x thru v.7 it will require the use of a proxy server.

– In some cases without the client, it might slow file access down.

> Traffic now has to go thru LDAP to SAMBA or CIFS to be processed correctly.

– Reduced functionality – IE Salvage


Novell Client™

Things to consider before you decide if getting rid of the Novell Client is good for your environment:

– If the network environment has strong dependencies upon the Novell® login scripts, you might want to reconsider. Without the Novell client there are no eDirectory™ login scripts.

– Purge and salvage no longer work for the client-less user.

– Users also lose the ability to set the delete inhibit and rename inhibit Novell Storage Services™ file system rights.


Removing the Novell Client™

• Novell® CIFS

• Domain Services for Windows

Novell® CIFS in OES 2


Novell® CIFS Conceptual Overview

Novell CIFS runs on the Open Enterprise Server 2 SP2 Linux server, uses Novell eDirectory™ services for user authentication, and allows the Windows SMB client to access the data files on an OES 2 SP2 server


Novell® CIFS Features and Capabilities

CIFS implementation supports the following features on OES 2 SP2 Linux

– Support for Windows 2000, XP, 2003, Vista Enterprise, Vista Business, and Vista Ultimate (32-bit/64-bit), and SLED

– Support for new Novell Windows 7 client– Cross-Protocol File Locking support with AFP, CIFS, and NCP– Auditing support for file access activities– Novell OES 2 Distributed FileSystem (DFS) Support– Support for Novell eDirectory™ Universal Password– Support for NTLMv1 authentication mode and SMB Signing– Supports the Novell Trustee Model for file access– Does not require Linux User Management (LUM) enabling


Novell® CIFS Overview

File Storage ServicesAuthenticationAccess Methods

eDirectory usershave automaticaccess to NovellCIFS file services

OES 2 server

eDirectoryLDAP server

Any CIFS / SMB Client(such as Windows Explorer)

Web Folders(Windows Explorer or

Internet Explorer browser)

CIFS serverprocesses

CIFS

WebDAV


Novell® CIFS and Novell Samba Comparison

Feature Novell CIFS Novell SAMBA

Authentication

Password policy is required to allow cifs

users to authenticate to eDirectory

A Samba-compatible Password Policy is required for compatibility with Windows workgroup authentication.

File system supportNSS is the only file

system supported for this release.

It is recommended (but not required) that you create Samba shares on NSS data volumes. NSS is fully integrated with

eDirectory for easy management and using an NSS volume allows you to take advantage of the rich data security model in NSS. You can use either iManager for the nssmu utility to

create an NSS volume on an OES2 Linux server..

LUM and Samba Enablement

LUM and Samba enablement are not

required.

Users must be enabled for LUM and Samba and assigned to a Samba group.

Username and Password

Must be the same user name and password on both workstation and in

eDirectory

Must be the same username and password on both workstation and in eDirectory


Novell® SAMBA Overview

File Storage ServicesAuthenticationAccess Methods

Samba usersare enabled

for Linux UserManagement

(LUM)

OES 2 server

eDirectoryLDAP server

Any CIFS / SMB Client(such as Windows Explorer)

Web Folders(Windows Explorer or

Internet Explorer browser)

Samba serverprocesses

CIFS

WebDAV


Samba Differences in OES 2 Linux

• The open source Samba software is included as part of SLES 10 which is the base operating system for all OES 2 Linux services

– OES 2 uses this base Samba software, but configures it differently and installs additional software to take advantage of enhanced services available only provided from OES 2 Linux

• The main differences between base Samba and OES 2 Linux are:– Samba OES 2 Linux is configured to exclusively use the Novell® eDirectory™ LDAP server

for secure user authentication> OES 2 Linux does not support Samba running in NT 4 domain mode

– On OES 2 Linux, Samba shares can be created on native OES 2 NSS volumes or on native Linux POSIX file systems configured as OES 2 NCP Volumes that are controlled by the full Novell Trustee Model

– Samba on OES 2 Linux should be managed using the iManager Samba Management plug-in provided with OES 2

– Although Samba can also provide Windows print services, OES 2 print services are provided by Novell iPrint, not by the Samba services


Comparing CIFS on NetWare® and CIFS on OES 2 SP2 Linux

Feature NetWare 6.5 OES 2 SP2 Linux64 bit Support No Yes

DFS for NSS Yes Yes

OpLocks Yes Yes

Cross Protocol Locks Yes Yes

NSS Support Yes Yes

File and Record Locking Yes Yes

Domain Emulation Yes Future

Multi-Processor / Multi-Core No Yes

Multi File System Support No Future

NTLMv2/Kerberos No Future

Demonstration

Domain Services for Windows in OES2


Removing the Novell Client™ - DSfW

Networking & Management

SUSE® Linux Enterprise Server

XEN Virtualization

File Storage

Interoperability

User & IT Productivity

Av. on NW & SLE kernelsAv. only on SLE kernel

Novell Storage Services (NSS)

Identity Manager 3.5 Bundle Edition

Novell Cluster Services

Business Continuity Cluster

iFolder 3.8

Novell eDirectory (64-bit)

Novell iManager

DNS & DHCP

DFS w/ Junction Support

Dynamic Storage Technology

Domain Services for Windows

Novell Remote Manager

SAMBA & NetAtalk

AFP stack CIFS stack

POSIX

Sentinel ready NSS Auditing

Novell Client

Archive & Versioning

Enhanced Upgrade Utilities

NetStorage

iPrint

Auto YaST Windows Client

3rd PartyLinux Apps


• Had to use the Novell Client™ to get the full benefit of Novell® eDirectory™ and NSS

• Had to manage multiple desktop images. Administrative overhead

• Use different tools to manage Active Directory and eDirectory access rights. MMC to manage AD, iManager to manage eDirectory

• No good way to integrate Active Directory resources and eDirectory resources

Domain Services for Windows Before


Domain Services for Windows After

• Microsoft administrators can now use MMC to manage access to Linux servers

• Anyone that wants file access to Linux servers, no longer need a Novell Client™

• Single desktop image to manage• Lower admin costs (consolidation

of access management overhead)• More quickly update to newer

desktop environments• Easily drop in a Linux server and

integrate with an Active Directory Infrastructure


Component Architecture

Domain Services for Windows is built on the following components

– Novell® eDirectory™ 8.8 SP4– Novell Modular Authentication Service 3.2– MIT Kerberos 1.6– An Active Directory Provisioning Handler (ADPH) built

inside the eDirectory Agent– XAD Framework– RPC Subsystems required by Windows– SAMBA– BIND with GSS extensions– NTP with Net Logon extensions

•


Domain Services for WindowsArchitecture


Domain Services for Windows –eDirectory™

DSfW will only work with eDirectory 8.8 SP4 on Open Enterprise Server 2 SP1 or higher

– ADPH enforces the Security Accounts Manager inside the agent.

> Allocates Security IDs to users and groups

> Validates entries

> Enables existing eDirectory uses to use AD and RFC2307 authorization.

– Configurable interface support for LDAP server.

– Implements Global Catalog search – port 3268 and 3269> Requests will be chained to other domains


Domain Services for Windows –Service listFollowing services constitute Domain Services for Windows

– /etc/init.d/named – BIND

– /etc/init.d/ntpd - Time Service

– /etc/init.d/ndsd - eDirectory™ 8.8 SP4

– /etc/init.d/xad – rpcd, xadsd, krb5kdc etc.

– /etc/init.d/winbindd – winbind daemon

– /etc/init.d/nmbd – name lookup daemon

– /etc/init.d/smb – samba daemon


Domain Services for Windows –Provisioning Tools• Installation

– ndsdcinit tool provisions a new DSfW domain controller in a new or existing domain

– Extends eDirectory™ schema with AD schema

– Will be run from YaST when the DSfW pattern is selected

• Administration– iManager

– MMC Active Directory Users & Computers

– Command line tools

– Existing LDAP and NDAP clients should “just work”


Use Case SceneriosDomain Services for Windows

• Access OES2 file system without a Novell Client™ on the workstation

• Single username and password for accessing resources from Linux, AD and other services

• Standardized administration tool in a heterogeneous environment

• Custom built desktop application that requires an AD backend

• Integration of Windows desktop into a Linux environment (vice versa)


Domain Services for Windows A Summary

• Domain Services for Windows (DSfW) is a suite of technologies in Open Enterprise Server (OES) 2 SP1

• Provides client–less login to and file access for Windows workstations in eDirectory™ trees

• Allows Linux servers to behave as AD servers

• Integrates with existing eDirectory deployments

Demonstration

Unpublished Work of Novell, Inc. All Rights Reserved.This work is an unpublished work and contains confidential, proprietary, and trade secret information of Novell, Inc. Access to this work is restricted to Novell employees who have a need to know to perform tasks within the scope of their assignments. No part of this work may be practiced, performed, copied, distributed, revised, modified, translated, abridged, condensed, expanded, collected, or adapted without the prior written consent of Novell, Inc. Any use or exploitation of this work without authorization could subject the perpetrator to criminal and civil liability.

General DisclaimerThis document is not to be construed as a promise by any participating company to develop, deliver, or market a product. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. Novell, Inc. makes no representations or warranties with respect to the contents of this document, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. The development, release, and timing of features or functionality described for Novell products remains at the sole discretion of Novell. Further, Novell, Inc. reserves the right to revise this document and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. All Novell marks referenced in this presentation are trademarks or registered trademarks of Novell, Inc. in the United States and other countries. All third-party trademarks are the property of their respective owners.

Life without the Novell Client

Documents

Transcript of Life without the Novell Client