Section K.4.1, Deployment Scenario 1: Complex Mixed Scenario with a Mix of File Access Services
Section K.4.2, Deployment Scenario 2: Mutually /Exclusive Users
Section K.4.4, Modifying User Password Policies after AFP/CIFS/Samba/DSfW Is Installed
Section K.4.6, Enabling File Access for DSfW Servers Across Domains
Installation is the same as for the Forest Root Domain (FRD). The tree is named as per domain naming standards. Samba is installed as part of DSFW installation. Neither AFP nor Novell CIFS can be installed/configured on this server because they are not compatible with the DSFW server.
In order for users to access NSS volumes on this server through Samba, the users need to fit the following constraints:
They must be LUM-enabled
Cross domain access is necessary for users from outside of the DSFW domain corresponding to this server to access the volumes on this server. This can be achieved by adding those contexts to the LUM context for the LUM workstation object that represents the domain controller.
Winbind translates user principles to UIDs for non-NSS volumes. LUM enabling is not required for non-NSS volume access.
If the first server in the tree is a non-DSFW server, then any combination of AFP, Novell CIFS, or Samba can be installed on this server. Because the tree is being newly created, the users, the proxy users (system users), and the Password policies will not be present. Use the following procedure for installation:
Install and configure the server with eDirectory, NSS, and other core services, but without selecting file access services.
Use auto-created common proxy user in eDirectory configuration for the OES services.
Use iManager to create a system user (proxy user) to be used for the OES services.
Use the Yast install to configure the Novell AFP and Novell CIFS services as follows:
Use an auto-generated common proxy user for all the services.
Specify the contexts under which to search for the AFP or CIFS users.
If the AFP/CIFS/Samba user objects are present on NetWare servers, upgrade Novell Security Services version 2.0.6 in order to upgrade to NMAS 3.2 on NetWare.
Administrators need to decide whether these servers should be installed on a new domain or as additional domain controllers during capacity planning and deployment design. Follow the OES 2 SP3: Domain Services for Windows Administration Guide to deploy S3 and S4 in the tree.
Use an auto-generated common proxy user for all the services.
Use the same procedure as for S5.
Use the same procedure as for S5 and S6.
AFP and CIFS on NetWare don’t require proxy users or password policies for service access.
NMAS needs to be upgraded to 3.2+, if this server hosts the only writable replica for a partition with AFP or CIFS users.
If this NetWare box is migrated to OES2 SP2, the AFP and CIFS users are enabled for Universal Password. They need to either use a plain text authentication method, or log in through NCP (Novell Client) to synchronize their NDS passwords to the Universal Password. AFP can auto-synchronize the Universal Password if the default DHX authentication method is used.
Use the same procedure as for S5.
Either use a common proxy user for all the services (AFP), or allow auto-generation of the proxy user/password for each AFP.
In some trees, AFP, CIFS, and Samba might be employed, but the users are partitioned in such a way that each user has access to AFP, to CIFS or to Samba, but not to all of them.
DSfW servers with Samba. All the users are under dc=blr,dc=widgets,dc=com.
You can use the default Password policy provided by Domain Services for Windows for all the users in this subtree.
You can create and use a single proxy user/password under dc=blr,dc=widgets,dc=com for all the servers providing Samba.
Simple deployments require very little planning.
Auto-generated proxy users by each service might be a good idea.
After a new password policy is assigned to a Samba or DSfW user, rerun the YaST–based configuration and select the new Password policies.
After a new password policy is assigned to a Samba or DSfW user, rerun the YaST–based configuration and select the new Password policies.
DSfW requires that users be LUM-enabled to access NSS file services through Samba. For a user to access a DSfW server in a different domain, the user needs to be a LUM-enabled user on the other server. DSfW provisioning establishes shortcut trust between domains. Users from other domains in the forest can access non-NSS volumes as long as they have rights on the resources.
To achieve this, the context of the partition root for the user object should be added as a search context for LUM. This needs to be done in addition to the trustee rights provided to the user (or the user's group) as part of file system rights.