NOTE:To know about the provisioning tasks associated with each installation scenario, see Section 8.6, Provisioning Tasks for Name-Mapped and Non-Name-Mapped Scenarios.
The Provisioning Wizard lets you perform the following tasks:
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, 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 on the DSfW server. DSfW uses DNS as its location service, enabling computers to find the location of domain controllers.
As part of this task, 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 OES DNS and needs at least one DNS server to run on a domain controller.
NOTE:As part of DSfW installation, the DNS server is configured in the first domain in the forest. For subsequent child domains, you can either link to the DNS server in the first domain or install a DNS server for the child domain.
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 OES 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.
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 gets a replica. The Additional Domain gets the replica of this partition if you select the Replicate schema and configuration partitions 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, replica of the schema container is added to the local server.
The schema partition is forest-specific and by default the first domain controller of every domain gets a replica. The Additional Domain gets the replica of this partition if you select the Replicate schema and configuration partitions 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 adds the domain controller to the domain.
This task creates additional objects that make your server act as a domain controller. The task is only executed if you have installed DSfW as an additional domain controller in the domain.
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.
The existing user and group objects are extended to receive Active Directory attributes that allow them to be part of the domain being provisioned. Some of the extended attributes are supplementary Credentials, objectSid, and samAccountName.
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)
nmbd (NMB server, NETBIOS lookup)
winbindd
smbd (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 the remaining tasks in the provisioning wizard.
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 removes files from a partial or failed installation. It also removes the temp directories and checkpoint files created during provisioning.