Section L.4.1, Deployment Scenario 1: Complex Mixed Scenario with a Mix of File Access Services
Section L.4.2, Deployment Scenario 2: Mutually /Exclusive Users
Section L.4.4, Modifying User Password Policies after Samba/DSfW Is Installed
Section L.4.5, Adding New User eDirectory Contexts to CIFS after CIFS/DSfW Is Installed.
Section L.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. CIFS cannot 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 CIFS 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 CIFS services as follows:
Use an auto-generated common proxy user for all the services.
Specify the contexts under which to search for the CIFS users.
If the CIFS 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 23.4: 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.
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 CIFS users.
If this NetWare box is migrated to OES and CIFS users should be enabled for Universal Password by having a password policy configured. CIFS users need to log in through NCP (Client for Open Enterprise Server) to synchronize their NDS passwords to the Universal Password.
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, CIFS might be employed, but the users are partitioned in such a way that each user has access to CIFS, 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.
One auto-generated common proxy user per server for all services configured on the server is a good choice.
After a new password policy is assigned to a Samba or DSfW user, rerun the YaST–based configuration and select the new Password policies.
If users from additional or different eDirectory contexts need to be allowed to access CIFS, rerun the YaST–based configuration and modify or add the required eDirectory user contexts.
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.