Prerequisites for AFP, CIFS, and Samba access are explained in the following sections:
The following are the prerequisites for user access to AFP, CIFS, and Samba services:
The eDirectory context under which users are searched for must be configured during service configuration.
The users need to be governed by Password policies that enable Universal Password for them.
There must be at least one writable replica of NMAS version 3.2 or later having the user object trying to access the AFP or CIFS server. NMAS 3.2 is already present on OES 2 servers, as well as on servers with eDirectory 8.8.2 installed. On OES 1 and NetWare servers with a lone writable replica of a AFP or CIFS user, NMAS should be upgraded by upgrading to the Novell Security Services 2.0.6 on eDirectory 8.7.3 SP10 or eDirectory 8.8.2.
The file access services will provide access/visibility to the users as per the trustee rights they have on the volumes and files.
In addition, Samba (on both DSFW and non-DSFW servers) has the following additional requirements:
The users must be LUM-enabled on the server.
The users must be members of a LUM-enabled group on the server holding the volumes.
Samba users must be created in a container or partition that has a <Samba-qualified password policy> assigned to it.
AFP: Requires that user contexts be specified during the YaST configuration. These are the contexts under which the user objects will be searched for during an authentication. In a name-mapped (existing tree) install, if the context resides in a DSfW domain, the context can be specified either in the domain name format (Active Directory format) or in the X.509 format.
CIFS: The eDirectory contexts of users can be specified either in the domain name format (Active Directory format) or in the X.509 format.
Samba: Depends on LUM to search for the user in eDirectory and therefore doesn’t require an eDirectory context.
Samba: Creates a default password policy, but does not attach this policy to any user.
DSFW: The password policy in a DSfW environment is modeled after Active Directory Password policies. There is a single Password policy at the domain level, and it is configured during provisioning. eDirectory allows you to set policies at the user or container level. However, this is not recommended in a DSfW environment.