This scenario comprises of the following tasks. Select an option to display details of the task.
This task verifies the state of the servers to ensure that they are ready for provisioning.
As part of the provisioning precheck activity, a health check is performed in the background to validate the state of the system to avoid a stale state. Not validating the system state can lead to irrecoverable failures in the system. This makes the health check very important.
The health check performs the following actions:
Verifies that the services important for the installation, such as Kerberos, Samba, and NMB services, are running on the remote server.
Verifies that the DNS service is active on the server configured as the DNS server.
Verifies that all the servers that are part of the replica ring are active and that time is synchronized among the servers.
Verifies that the version of eDirectory on the server where installation is done is 8.8 SP2 or later.
In a name-mapped installation scenario, it checks the server to see if it contains any existing DSfW-specific objects.
Triggers a purge on the remote server to clear deleted objects.
This task configures DNS and WINS on the DSfW server. DSfW uses DNS as its location service, enabling computers to find the location of domain controllers. You can also configure a DSfW server as a WINS server. WINS is a name server and service for NetBIOS computer names. It provides NetBIOS name to IP address mapping for the client workstations in different subnets.
As part of DNS configuration, the following actions are performed:
Forward Lookup zones are configured for the domain to resolve queries on domain name lookup.
Reverse Zones are configured for the domain to resolve requests that need to associate a DNS name with an IP address.
Resource records of type NS, SRV, A, PTR are created.
The zone references are added to the DNS Server, DNS Group object, and the DNS Locator object.
Currently, DSfW is tightly coupled with Novell® DNS and needs at least one DNS server to run on a domain controller, but there are future plans to provide support for any DNS server capable of supporting secure DNS updates.
By default, the DNS server is configured on the first domain controller in a forest. For any additional domain controller in the forest, you can either use the existing DNS server in the forest or configure this server as a DNS server. Before configuring any additional domain controller in the domain, ensure that the nameserver entry in /etc/resolv.conf points to the DNS server that the first domain controller of the domain is using.
As part of WINS configuration, the following actions are performed:
The DNS entry in the corresponding zone object is created.
The /etc/samba/smb.conf file is updated with the parameters required for Samba services to act as a WINS server.
The nmb process is restarted.
The post‐check operation for the task checks if the DNS entry and data files corresponding to WINS are created.
This task creates a partition for the domain.
This partition has complete information about all the domain objects. Information about the domain objects is replicated to domain controllers in the same domain.
NOTE:This task is not executed in a name-mapped scenario.
This task adds the replica to the local server.
NOTE:This task is executed for all provisioning scenarios except for non-name-mapped and forest root domain installation.
This task loads the SLAPI plug-ins. The SLAPI plug-ins take care of maintaining the Active Directory information model. This ensures that the SLAPI framework is ready before any domain-specific data is added.
During the configuration process, the following tasks are performed:
Attributes and Classes are mapped between Active Directory and eDirectory schema objects.
The NLDAP server is refreshed and the SLAPI plug-ins are loaded.
The NAD plug-in is checked to see if it is loaded.
This task adds the domain objects that represent the domain-specific information under the domain partition.
The domain partition replicates data only to the domain controllers within its domain. In addition to this, it also creates containers for configuration and schema partitions that are later partitioned.
This task partitions the configuration container (cn=configuration) created as part of the Domain Objects Addition task. This configuration partition contains information on the physical structure and configuration of the forest (such as the site topology).
In case of a child domain installation, the replica of the configuration container is added to the local server.
The configuration partition is forest-specific and by default the first domain controller of every domain receives a replica. The additional domain controller receives the replica of this partition if you select the
option in YaST during installation.This task partitions the schema container (cn=schema) created during the Domain Objects Addition task.
The schema partition contains the definition of object classes and attributes within the forest. If there is a child domain or additional domain controller, the replica of the schema container is added to the local server.
The configuration partition is forest-specific and by default the first domain controller of every domain receives a replica. The additional domain controller receives the replica of this partition if you select the
option in YaST during installation.This task adds the configuration and schema partition objects.
It helps maintain integrity with the Active Directory information model.
This task configures directory-specific access rights for the domain and the domain administrator being provisioned.
The task performs the following activities:
Computes effective ACLs.
Imports NDS® Super rights ACLs and sets rights for the administrator at the container level.
Imports NDS Admin ACLs.
This task partitions the domain controller object (mSDS:Server), which is represented as a container object in eDirectory. This domain controller object is located under cn=Servers,cn=<sitename>,cn=Sites,cn=Configuration,dc=<domain name>
This task performs the following actions:
Pre‐checks the DSfW environment before partitioning of the object.
Partitions the domain controller object.
Post‐checks the DSfW environment after partitioning of the object.
This task restarts services in order of dependence.
The restart is essential for the changes to be committed. The services that are restarted, as part of this task are:
ndsd (eDirectory)
novell-named (DNS)
nscd (Name Server cache daemon)
rpcd (RPC server)
Xad-krb5kdc (Kerberos)
xad-kpasswdd (Kpassword)
xadsd (XAD daemon)
nmb (NMB server, NETBIOS lookup)
winbind (winbind)
smb (Samba)
sshd (SSH)
rsyncd (rsync)
After the services are restarted, your domain is up. However, before it is ready for use, you need to perform a few more tasks.
This task sets the password and kerberizes the administrator, krbgt, and guest accounts.
In DSfW, Kerberos is the primary security protocol for authentication within a domain. The Kerberos authentication mechanism issues tickets for accessing network services.
As part of this task, the krb5.conf file is updated and a ticket is sent to the administrator principal.
These changes trigger a change in the Kerberos Policy files that are stored in sysvol. This change requires a synchronization update to eDirectory, which is done by using the gpo2nmas utility.
A trust is a relationship established between domains that enables users in one domain to be authenticated by a domain controller in the other domain. Authentication between domains occurs through trusts.
This task establishes two-way transitive trust relationships between the domain being provisioned and the parent domain. In a transitive trust, all the domains belonging to the same forest trust each other. If any more new domains are added, an automatic trust relationship is established between the root domain and the new domain.
For example: If domain A trusts domain B and domain B trusts domain C, then users from domain C can access resources in domain A.
This task modifies the configuration of services such as sshd, rsync and krb5. This task configures the sysvol policies, synchronizes the group policies with NMAS and adds a crontab entry for subsequent synchronization of policies.
This task removes files from a partial or failed installation. It also removes the temp directories and checkpoint files created during provisioning.
For trademark and copyright information, see Legal Notices.