Provisioning Samba 4 as an AD Domain Controller - Implementing Samba 4 (2014)

Implementing Samba 4 (2014)

Chapter 2. Provisioning Samba 4 as an AD Domain Controller

In this chapter, the user will learn about the basic tasks that are required to get a proper Samba 4 Active Directory configured as the Domain Controller for the network. We will cover the following topics in this chapter:

· The minimal planning needed to deploy a Samba 4 Active Directory as the Domain Controller (for example, domain, network topology/addresses, and services required) as well as the basic concepts involved in the Domain Controller service configuration.

· The network topology with which we will work through our example configuration in the book, with basic planning techniques and checklists to show the user how to prepare and have at hand all the information needed for the provisioning setup of Samba 4 at hand.

· The deployment of the Samba 4 Server and the services needed for a proper Samba 4 configuration through explicit command-line examples.

· Other important aspects of any Active Directory Domain Controller network services such as the availability, performance, and replication considerations. We will look at these characteristics in our specific example scenario, explain what our assumptions were, and discuss some general ideas about how you should approach a real-world situation.

· The provisioning of Samba 4 as an AD Domain Controller will be described in detail, and at the end of the chapter, the reader will learn how to perform basic validations of the Samba 4 configuration setup. This is a very important task in order to have a sane environment that the administrators can rely on to have a fully functioning Samba 4 Active Directory Domain Controller.

Highlighting the planning points for an AD service

The most important task that we need to focus on before any other task, when planning for Active Directory Domain Controller, is to our network services' topology. For our Active Directory services to provide a resilient service, we need to be effective in creating a simple (yet descriptive) and scalable architecture that will fit our environment's needs and requirements.

Active Directory Domain Controller can provide us with a centralized management point for our network devices and thus gives us full control over a large number of objects (for example, users and machines). This is the key to achieving a lower cost in administrative tasks, resource control, and security (authentication and authorization) management in a specific network. To organize users and resources in a way that is simple to manage and is scalable (for example, facilitates delegation) is the key. On top of that, there is no reason to have a Domain Controller in our network if the applications are not able to integrate themselves with it. Thus, we cannot use all the features and facilities that an AD/DC can provide. Designing the proper architecture for a specific site is a complex and extensive task and is outside the scope of this book. However, we will discuss some general points and show you an example configuration and topology, so that you can use it as a base for future installations. As in any installation, the administrator needs to think about users, machines, organizational units, domains, forests, and services.

We will present a simple but effective architecture to the user for the EALL.COM.BR domain, with a structure that will help him/her understand important concepts and serve as a starting point for the readers to work upon and evolve to more complex environments. General advice is to focus on your specific topology and requirements, extract the essential concepts, and work similar structures in your design that fit your organization environment. Do not copy some Master Architectural Design from the Internet thinking that it will fit your network out of the box just because it handles all departments or definitions possible in the software. If you do not need that level of complexity, do not use it. I could see many sites that were designed based on general rules that were not intended to be used in that particular case but provide a simple and scalable environment instead; they also create a network environment that is too complex and really inefficient from the most basic administrative perspective. This is the exact opposite of what a well-planned Active Directory Domain controller should be.

One analogy for such an inefficient architecture can be, for example, a file system directory structure. Sometimes, we are compelled to create a really complex directory hierarchy with many subdirectories and a nested, and deep tree that, in the end, just keeps us away from the right file instead of helping us access it in a fast and simple way.

Just because we can create a lot of directories inside one another, it does not mean that we need to do it for every object or create a structure using hundreds of subdirectories that will just add to the complexity. In such situations, we need to think about the following points:

· How many files will we need to handle?

· What we want to achieve—fast placement of files, fast access to the files, (or both)?

· Is it a directory structure that will be used directly by a person or an application?

· Do we have an intelligent name for the files that we will be storing?

· If not, do we have the control to change the name of the files in order for them to have an intelligent name?

· Do we need to manage different/specific users and groups for each directory or file?

· Will the structure help us delegate the administrative task to some directories for specific users and/or departments?

You might think that creating a directory structure is supposed to be a simple thing. However, as you start to think about it and look at the previously discussed questions, you realize that it can be a tricky task and if the answers for the above questions are not the right ones, the simple task can become a big problem in the near future. In my experience, I have come across many solutions with performance or scalability problems (and even security problems) just because the architect of that solution did not think about these questions.

Similar design questions will come up when planning for Active Directory services in your network. The questions about a simple task as a file system directory structure can be eye opening to help us make the right architectural decisions in different design problems. Systems that are well designed share the same principles and are based on the same well-known characteristics of scalability, performance, security, and simple administration.

Let's get back to the Active Directory services and their architecture. What we need to have in mind at the highest level are these three basic concepts: forests, domains, and organizational units. Forests are the top level of abstraction on the Active Directory service. They provide us with security boundaries and contain one or more domains inside it.

Domains are divisions (or partitions) inside a forest, and they have one or more Organizational Units (OU) inside them. Organizational Units are entities that group different objects (for example, users and/or machines) to help the administration of these elements in a specific and scalable way (for example, making it easy to delegate the administration).

So, following a general definition from Microsoft Active Directory Documentation, forests are mainly there to implement a security control (boundary) on our Active Directory environment. Domains provide us with an administrative point where we can control the replication, thus establishing trust relationships. Organizational Units are an administrative point to delegate administration, thereby providing us with an invaluable resource to divide administrative responsibilities across the entire organization (source:http://technet.microsoft.com/en-us/library/cc756901(v=ws.10).aspx). This is an important aspect of scalability, as people (for example, administrators) are an essential asset for any company and are the most expensive resource to scale. The architecture needs to take this into consideration from the very beginning.

Our example configuration will use a simple forest model, as it is the simplest model with the lowest administrative overhead and will fit our requirement perfectly. There are situations where you may need to have multiple forest models, so you should plan to design such models instead. However, a single forest model is preferred if your organization does not have complex requirements (for example, totally autonomous divisions).

The forest root domain in our implementation will be MSDCBRZ.EALL.COM.BR, and we will work with just one location (child domain) named POA.MSDCBRZ.EALL.COM.BR. There are a lot of different approaches to organize the organizational units within a site, and many administrators have a different view of the structure as each organization has different needs.

We will start with 10 organizational units, following a model that basically separates the workstations, services, and users. These are the three important objects that we need to maintain on any directory services, and they will make the administration and implementation of specific policies in the future easier.

Tip

Downloading the example code

You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.

The structure will have three top level OUs, which are workstations, services, and users. The workstations' OU has the different type of devices that we plan to manage for our users, such as laptops and desktops. This is a crucial separation as we need to identify and handle the mobility of our users as they have specific security concerns. This depends on whether the users are using our corporate network every time or whether they are using laptops on the go. Our service's OU starts with three services and can actually grow as we install others—terminal servers, print servers, and SQL servers. Remember, if our network services are not integrated and cannot use the directory features, there is no big advantage of having a directory service with a centralized management.

Our last top level OU is for our users (People) and has two organizational units inside it—standard users and power users. This is a simple division and is a good base to leverage our user's administration.

In the following diagram, we can see our Active Directory's structure:

Highlighting the planning points for an AD service

Acquiring information for deploying an AD service

To facilitate the understanding of this concept and help us have at hand all the information that we need to deploy the Active Directory services on our network, we will create a checklist with all the information that we need prior to the deployment of an AD service. Based on our last topic, we know exactly what we need, how we have defined the topology, and how our network will be implemented. So, we are able to create a document with the information we need, and this will help us identify any missing points about our design. In the following table, we can see all the information we need prior to the implementation of Samba 4 Active Directory. This is organized in a table for ease of understanding and referencing during the configuration phase. To have such information at hand, it is vital that we have a clean and straightforward process; feel free to add as much information as you have when planning for your AD services. The following is a table that can be of help as a starting point to organize the data:

Samba 4 Active Directory configuration checklist

Question/Parameter

Answer/Value

Role

Domain Controller

DNS Infrastructure already in-place

( x ) Yes ( ) No

Active Directory IP Address/interface

192.168.1.1 (eth1)

How many Organization Units

10

Locations/Physical Sites

1

How many Domain Controllers

1

Domain

POA.MSDCBRZ.EALL.COM.BR

DNS Resolver Configuration

Forwarding (IP: 8.8.8.8)

DHCP Server IP Address

192.168.1.1

Default Router IP Address

192.168.1.1

How many users

50

As we saw in the first chapter, the Samba 4 Active Directory services rely on some other essential services to be able to fully provide its services. It has already a vital built-in service, DNS, which is well suited for many installations; we will use it as our configuration's base. However, we also need Network Time Protocol (NTP), as the time for all systems on the network needs to be in sync. This is even more important for the authentication of Kerberos. DHCP is another service that is highly necessary to provide the network administrators with a simple way to dynamically set up a new machine on the network (for example, assign it a new IP address) as well as register this new system on the DNS server (essential to the AD services). All the services mentioned in the table are already configured in our Debian 7 server as their configuration was part of our installation procedure for the Samba 4 services.

Availability, performance, and replication for the network service

When planning for any network service, we need to think about its availability and performance from the beginning as a service that does not have any of these two characteristics is useless. This is no different for an Active Directory Domain Controller, as it provides core services to the whole domain underneath it. If the server is not available, the result will be that the users will not be able to connect to the network, servers will not be able to resolve names, and so on. The checklist that we built has high-level information that will help us in getting answers to some important questions regarding availability and performance. This is why it is so important to have a documented plan as it makes things much easier. The sizing and architecture of the Active Directory services to a specific site is outside the scope of this book, and there are many articles on the Internet that discuss different aspects of a scalable, highly available, and high performance design. Some attention points on our checklist that need to be taken into consideration when thinking about performance and replication are as follows:

· The number of users

· The number of domains

· The location/physical sites

These points are just some examples of parameters that will have a huge impact on the load of our Active Directory Server but there are others examples as well. The more information you gather to add to your plan, the easier will it be to plan for the resources that are needed to provide the right performance for your site.

A good example of another kind of information that we can have on our checklist is provided by our Active Directory diagram. The services that we intend to have in our domain and ones that will interact with our AD, will generate load (DNS queries, authentication, and so on), so they too are performance factors that we need to take into account. Our example scenario has a few users and a few services and one server is sufficient to handle the load. We just have one site (location) and one domain, so there are no concerns about the link's performance in order to replicate the AD database. When we talk about availability, there is no small setup and we just cannot afford to not have redundancy (high availability) in our services. In Chapter 4, Replacing a Microsoft Windows Active Directory Server, we will see how we can add redundancy to our setup and how we can have high availability in the Active Directory services.

Setting up Samba 4 as an AD Domain Controller

One important configuration that will make our lives a lot easier is adding the Samba 4 installation path to our bash_profile file so that we have all the Samba tools in our search path and we don't need to work with full (absolute) paths. To do this in a sh or bash shell environment, just run the following command in your prompt:

leal@debian7:~$sudo echo 'export PATH=/usr/local/samba/bin:\

/usr/local/samba/sbin:$PATH' >> /root/.bash_profile && echo OK

The preceding command must give just the OK output. This is the signal that we have configured our bash_profile file in the Samba 4 software's binary path (for example, tools), so for future shell instances, we will have the search path ready.

After we have all the requisites for the Samba 4 environment fulfilled and our software installation validated, setting up a Samba 4 Server as an Active Directory Domain Controller is a simple task. We just need to execute the following command in the command line prompt and we are ready to go:

leal@debian7:~$ sudo samba-tool domain provision --realm=POA.MSDCBRZ.EALL.COM.BR --domain=POA --adminpass='w1ndow$$!' --server-role='domain controller'

The previous samba-tool command can be executed interactively by just passing the domain provision argument and answering the questions one by one (for example, domain, adminpass, and so on). One of the objectives of this book is to provide the readers with as many automated procedures and simple scripts as possible. We invoked the samba-tool command with all the commands and arguments directly in one shot; this will execute the whole Samba 4 Server provisioning without further interaction.

Tip

If you want to re-execute the provisioning command, you will need to remove the smb.conf file prior to the new execution or you will receive an error and the execution will be aborted (for example, sudo rm /usr/local/samba/etc/smb.conf).

So, let's take a look at the previous command line and explain each of the arguments that were used; then, the reader can understand all the options and tweak them as appropriate. The arguments are described as follows:

· samba-tool: This is the main Samba administrative tool.

· domain provision: This is the argument where the domain is the subcommand on samba-tool that handles the domain's management tasks, and provision is the subcommand that actually performs a provision of a domain. This is the main part of our command as it provides us with the provisioning of the domain.

· --realm: This is the realm's name.

· --domain: This is the argument where we set our domain name.

· --adminpass: This is the administrative password, (if we do not provide one, Samba will create a random password), which is an important point in the configuration of Samba 4 as there is a strict policy for passwords in the Active Directory services (Microsoft Windows Password Policies). If we provide a password that is not strong enough, we will receive an error and will need to execute the command again. The password used in this book is a simple password that respects that policy but is not intended to be used in production.

The --server-role argument tells you that you must choose a secret and strong password for your installation. We are provisioning an Active Directory Domain Controller, so we will use domain controller as our server role. However, there are other options such asdc, member server, member, and standalone. The default server-role, if not provided by the user, is dc .

Tip

You can take a look at all available options which issue the samba-tool command without any options, or access the main page (for example, man samba-tool).

Just after we issue the preceding command to set up Samba 4 Server as an Active Directory Domain Controller, we can follow the output to be sure that everything was okay in the execution. We can take a look at an example output in the following command:

Looking up IPv4 addresses

More than one IPv4 address found. Using 192.168.1.1

Looking up IPv6 addresses

No IPv6 address will be assigned

Setting up share.ldb

Setting up secrets.ldb

Setting up the registry

Setting up the privileges database

Setting up idmap db

Setting up SAM db

Setting up sam.ldb partitions and settings

Setting up sam.ldb rootDSE

Pre-loading the Samba 4 and AD schema

Adding DomainDN: DC=poa,DC=msdcbrz,DC=eall,DC=com,DC=br

Adding configuration container

Setting up sam.ldb schema

Setting up sam.ldb configuration data

Setting up display specifiers

Modifying display specifiers

Adding users container

Modifying users container

Adding computers container

Modifying computers container

Setting up sam.ldb data

Setting up well known security principals

Setting up sam.ldb users and groups

Setting up self join

Adding DNS accounts

Creating CN=MicrosoftDNS,CN=System,DC=poa,DC=msdcbrz,DC=eall,\

C=com,DC=br

Creating DomainDnsZones and ForestDnsZones partitions

Populating DomainDnsZones and ForestDnsZones partitions

Setting up sam.ldb rootDSE marking as synchronized

Fixing provision GUIDs

A Kerberos configuration suitable for Samba 4 has been generatedat /usr/local/samba/private/krb5.conf

Once the above files are installed, your Samba 4 server will beready to use

Server Role: active directory domain controller

Hostname: debian7

NetBIOS Domain: POA

DNS Domain: poa.msdcbrz.eall.com.br

DOMAIN SID: S-1-5-21-1069074877-2280341390-3609431641

The output in the preceding command has some information about each step of the provisioning of the Samba 4 Server, so we can see messages about setting up some resources, creating some default containers, users, groups, as well as some DNS setups.

The last lines have some useful information; they give us the Domain Name and SID; they also give us an important hint about the Kerberos configuration file that was automatically generated for us, and we need to use it to finish the Samba 4 Server configuration. We just need to install the kerberos config file in its right directory, and to do that, we just need to issue the following command:

leal@debian7

:~$ su – root

Password:

root@debian7:~# cp -pRf /usr/local/samba/private/krb5.conf /etc/ && echo OK

OK

root@debian7:~# exit

leal@debian7:~$

If the output for the previous command is OK, it means that our Kerberos configuration file is installed in the right location and we are almost there. Now, we need to edit the smb.conf file and configure our DNS server, which Samba will use to forward any Domain Name resolution queries that are outside its authoritative zone. In this example, we will use the Google DNS open servers, but you should use the addresses for your DNS servers. Just take a look at the smb.conf file before editing it as the right DNS forwarded IP address could be configured automatically by the samba-tool script, so you don't need to change anything.

The following script should do that for us:

leal@debian7:~$ sudo cp -pRf /usr/local/samba/etc/smb.conf /usr/local/samba/etc/smb.conf-bkp && sed -e 's/dns forwarder =.*$/dnsforwarder = 8.8.8.8/g' /usr/local/samba/etc/smb.conf >/usr/local/samba/etc/smb.conf-new && mv/usr/local/samba/etc/smb.conf-new /usr/local/samba/etc/smb.conf &&echo OK

OK

leal@debian7:~$ sudo cp -pRf /usr/local/samba/etc/smb.conf \

/usr/local/samba/etc/smb.conf-bkp && \

sed -e 's/dns forwarder =.*$/dns forwarder = 8.8.8.8/g'

/usr/local/samba/etc/smb.conf > /usr/local/samba/etc/smb.conf-new&& \

mv /usr/local/samba/etc/smb.conf-new/usr/local/samba/etc/smb.conf && \

echo OK

OK

leal@debian7:~$

If the output is OK, it means that our smb.conf file was edited fine and we are ready to start the Samba 4 Server. In case we receive any error, we should not change any line of our original Samba configuration file. If any change was made and we received an error that means that the editing was not successful, we will get a backup file that contains the original content of our smb.conf file, as the first command issued in our script created a copy of the Samba configuration file. So, we have a smb.conf-bkp file with our original configurations and we can just restore it.

Now, we will start our Samba 4 Server to have it running in the foreground. It should be single-threaded to be able to identify any errors or warnings the software can raise as in the next topic, we will execute a series of tests and validations to verify that our configuration is ready to enter production. In a terminal window, issue the following command:

leal@debian7:~$ sudo /usr/local/samba/sbin/samba -i -M single

Password:

If everything was fine with our installation and configuration process, we should receive the following output:

samba version 4.0.5 started.

Copyright Andrew Tridgell and the Samba Team 1992-2012

samba: using 'single' process model

Attempting to autogenerate TLS self-signed keys for https forhostname 'DEBIAN7.poa.msdcbrz.eall.com.br'

TLS self-signed keys generated OK

You will notice that the Samba process remains attached to your shell, as it has not forked. The message indicates the 'single' option as our process model, as we started the daemon with the -M single option. This is to make our life easier while debugging and searching for any error messages, as we have just one process to handle our Active Directory services; there's no risk of losing the message involved as we are looking at the right process.

Validating the Samba 4 configuration

Now that we have our Samba 4 Server installed and configured, we execute some basic validations to guarantee us that our environment is ready to go live. These tests will cover DNS queries, Kerberos authentication, and some basic request/response capabilities of our brand new server.

As we stated in the first chapter and will do in others throughout the book, it's always important to have an automated test procedure to validate our environment. So, it's highly recommended that you start creating scripts to test your Samba 4 configuration for future installations, upgrades, or maintaining the database. Creating a battery of tests and validations is the key to help us with any changes in the environment and can identify problems before you go live, providing you with the option to rollback the modifications and go back to the planning board.

Let's start with the DNS tests as the Domain Name resolution is essential for the proper working of Active Directory [13]. If we have any issues with our configuration, we will face trouble ahead. The Active Directory uses the SRV record to locate domain controllers, as this resource record is used to identify servers that provide specific services. Two SRV records need to be created for any Active Directory Domain Controller: _kerberos and _ldap. So, we need to validate that our systems have these records, so clients will be able to communicate and find our services on the network. Issue the following commands on a new shell:

leal@debian7:~$ host -t SRV _kerberos._udp.poa.msdcbrz.eall\

.com.br

_kerberos._udp.poa.msdcbrz.eall.com.br has SRV record 0 100 88 debian7.poa.msdcbrz.eall.com.br.

leal@debian7:~$ host -t SRV _ldap._tcp.poa.msdcbrz.eall.com.br

_ldap._tcp.poa.msdcbrz.eall.com.br has SRV record 0 100 389 debian7.poa.msdcbrz.eall.com.br.

leal@debian7:~$ host -t A poa.msdcbrz.eall.com.br

poa.msdcbrz.eall.com.br has address 192.168.1.1

The output for the preceding commands should be similar in your environment. In case you receive an error stating that the entries were not found, you need to review the configuration process to make sure that every step was properly executed. As we can see from the output for both the preceding commands, our SRV records for _ldap and _kerberos are configured OK .

Another important point about our DNS setup is the forwarding configuration, so the ability to resolve names that our Active Directory is not authoritative. We can test this by trying to check some well-known sites. The steps to test the same are as follows:

1. Execute the following command:

2. leal@debian7:~$ host www.amazon.com

The output should be something like the following command:

www.amazon.com hashas''''''' address 72.21.215.232

3. We can try to resolve the MX record for the amazon.com domain. For that, just issue the following command at one terminal:

4. leal@debian7:~$ host -t mx amazon.com

The output for that command should be something similar to the following command:

amazon.com mail is handled by 5 amazon-smtp.amazon.com.

amazon.com mail is handled by 10 smtp-fw-4101.amazon.com.

amazon.com mail is handled by 10 smtp-fw-9101.amazon.com.

amazon.com mail is handled by 10 smtp-fw-31001.amazon.com.

amazon.com mail is handled by 10 smtp-fw-33001.amazon.com.

amazon.com mail is handled by 15 smtp-fw-2101.amazon.com.

So, with these tests, we are sure that our Active Directory's built-in DNS server is working just fine, resolving DNS names for our domain (poa.msdcbrz.eall.com.br) and forwarding the requests for the other domains. We also validated the _kerberos and _ldapSRV records and are able to proceed to test the Kerberos authentication mechanism.

5. To test the kerberos authentication, we can use the kinit command. Kinit is a utility to obtain and cache the Kerberos ticket-granting ticket (see man kinit). The simplest form to invoke kinit and test our Samba 4 configuration is by executing the following command:

6. leal@debian7:~$ kinit administrator@POA.MSDCBRZ.EALL.COM.BR

7. You should receive the following prompt:

8. Password for administrator@POA.MSDCBRZ.EALL.COM.BR:

9. So, you must enter the administrator password and press Enter. The output should be a warning like the following command:

10.Warning: Your password will expire in 41 days on Sat Jul 13 19:22:46 2013

11. Now, we can use the klist command to verify that we have actually received a ticket and Kerberos is working fine:

12.leal@debian7:~$ klist

13. The output for the klist command in the preceding command should be something like the following command:

14.Ticket cache: FILE:/tmp/krb5cc_1000

15.Default principal: administrator@POA.MSDCBRZ.EALL.COM.BR

16.Valid starting Expires Service principal

17.06/02/13 02:09:59 06/02/13 12:09:59 krbtgt/POA.MSDCBRZ.EALL.\

18.COM.BR@POA.MSDCBRZ.EALL.COM.BR

19.renew until 06/03/13 02:09:54

If you receive an output similar to the klist command execution, it means that the Kerberos authentication mechanism is working fine.

The next validation will be the ldap backend of our Samba 4 Active Directory Domain Controller. We can use the ldapsearch utility to perform queries on our AD and verify that it is working as it should. The first query can be the following command:

leal@debian7:~$ ldapsearch -x -h localhost -s base -Dcn=administrator,cn=Users,dc=poa,dc=msdcbrz,dc=eall,dc=com,dc=br -W

You will be prompted to provide the administrator password and after that, you should receive a verbose output. For brevity, we will reproduce just the last few lines here:

namingContexts: DC=DomainDnsZones,DC=poa,DC=msdcbrz,DC=eall,DC=com,DC=br

namingContexts: DC=ForestDnsZones,DC=poa,DC=msdcbrz,DC=eall,DC=com,DC=br

supportedSASLMechanisms: GSS-SPNEGO

supportedSASLMechanisms: GSSAPI

supportedSASLMechanisms: NTLM

highestCommittedUSN: 3723

domainFunctionality: 2

forestFunctionality: 2

domainControllerFunctionality: 4

isGlobalCatalogReady: TRUE

# search result

search: 2

result: 0 Success

# numResponses: 2

# numEntries: 1

If you have received a similar output in response to the previous ldap search query, it means that our Active Directory ldap backend should be working fine.

The last test is the most important one as we will actually test Microsoft Windows Machine and try to add it to our brand new domain. We will use a Windows Server 2008 R2 operating system, and after the machine has joined the domain, we will use it to create the organizational units on our Active Directory Domain Controller.

Just after the installation of the Microsoft Windows 2008 Server, we can check if our system could get an IP address from our DHCP server; do execute a quick reachability test (for example, ping) just to make sure that everything is fine with our network's setup. Using PowerShell, we can issue the following command to look at our network configurations (IPv4 Address, DNS Servers, Default Gateway, and and so on):

Validating the Samba 4 configuration

We can see from the preceding screenshot that the Windows 2008 Server could get an IP address (192.168.1.11). We have DHCP Server, IPv4 Address, Primary WINS Server, DNS Servers and Default Gateway—all pointing to our Active Directory Domain Controller,192.168.1.1.

To make sure that our system is able to reach our Active Directory (Samba 4 Server), let's execute a quick Ping test:

Validating the Samba 4 configuration

As we can see in the preceding screenshot, no problems are pinging our Active Directory Server (Debian 7), and this test performed an indirect test as it validated our DNS configuration and also tested the ability of this Windows 2008 Server to access our DNS Server (Debian 7) and resolve names.

Before we execute the procedure to actually join the POA.MSDCBRZ.EALL.COM.BR domain, we can do a last check to make sure that the Windows Server clock is right. We can check this by looking at the time shown at the desktop dock (bar at the bottom of the screen) or issuing the date command in the PowerShell prompt. In case we identify that our server's date or time is not right, we need to adjust it before moving on to the next step. To adjust the hour, just double click on the clock at the dock and click on Change date and time settings...:

Validating the Samba 4 configuration

Now that we have finished the preliminary checks to make sure that our Active Directory and Microsoft Windows 2008 server are well configured and are ready to communicate with each other, we can execute the procedure to join the Windows 2008 Server to the Active Directory Domain.

The procedure to join a machine to a domain can be executed in the Windows 2008 Server following a quick and simple procedure. First, we click on the Start button and right-click on Computer. In the context menu, click on Properties.

The following screenshot shows us the procedure:

Validating the Samba 4 configuration

In the next screenshot, we will navigate to Control panel | System and Security | System and will be able to see information about our system. Next to the middle of the screen, we will have information about the computer's name, domain, and workgroup settings. In this section, we will see the Change Settings option, and that is the option we need to click. Take a look at the following screenshot:

Validating the Samba 4 configuration

The screen that we will be presented with will have a button named Change next to this text: To rename this computer or change its domain or workgroup, click Change. We need to click on the button as shown in the following screenshot:

Validating the Samba 4 configuration

The next screenshot will provide us with a selection of an option to join a domain, and we just need to fill it with our domain's name as POA. The following screenshot shows us exactly how we did the configuration for our domain:

Validating the Samba 4 configuration

After filling the name for our domain, we just need to click on the OK button and fill our administration credentials. Here is what the dialog screen looks like:

Validating the Samba 4 configuration

If everything went just fine, after a couple of seconds, we should see the dialogue box with the message Welcome to the POA domain, as shown in the following screenshot:

Validating the Samba 4 configuration

Just after we click on the OK button in the dialog box shown in the preceding screenshot, we will see another dialog box with a message stating that we need to restart the operating system so that the changes take effect. The following screenshot shows the message stating that if you have any open files, make sure you close and save them before restarting your system:

Validating the Samba 4 configuration

Now, we can safely click on OK, and Windows Server 2008 will restart after we click on the button shown in the following screenshot:

Validating the Samba 4 configuration

It's important to take a closer look at the log in screen the next time the server starts. If we do not pay attention to it, it may seem like we have the same options and the default option is to log in as the last user we did last time (which is the local Administrator). In contrast to other Microsoft Windows versions that offer an option to choose a user-friendly domain to log into, we need to use the direct log-in method using the DOMAIN\User option.

In the next screenshot, we see an example of how to log in to the POA domain that we just joined (remember to use the password for the POA domain's administrator):

Validating the Samba 4 configuration

After we press Enter, we should log in to our new domain, and we will see that we have the Microsoft Windows Server 2008 R2 totally configured in the Samba 4 Active Directory POA domain. This is the final test and validation that our configuration is fully functional and our domain controller is ready to go live!

As we have this test machine ready and integrated with our domain, we will use it to create our organizational structure on our Active Directory. In our example, we have 10 OUs to create our structure and have it ready for production. This is an important procedure as we have some default configurations that we can use to test this machine to prepare our environment. We will not discuss many changes in detail, but I do recommend that you use this procedure of any Active Directory configuration to make all the changes you need to set up your environment as closely as possible to your needs.

To remotely manage our Samba 4 Active Directory Domain Controller using our Microsoft Windows 2008 R2 Server, we don't need to install extra software or download anything as in other Microsoft Windows versions, but we do need to configure (that is, enable) some features in the Server Manager that are not enabled by default.

Tip

We can manage our Samba 4 Server using other versions of Microsoft Windows, such as Microsoft Windows 2003, Microsoft Windows XP, and Microsoft Windows 7.

For that, start the Server Manager tool. To do that, you just need to click on the Start menu button, choose Run, type ServerManager.msc in the input field, and press Enter. It's important to note that you actually need to write the extension (.msc). If you do not, the file explorer (Windows | System32 | ServerManager) will be opened instead. Alternatively, we can start the Server Manager by clicking on the link in the Start menu button.

Now, on the Server Manager screen, we need to click on the Features option in the left panel, and in the right panel, we need to click on the Add Features button. Look at the following screenshot where we show the Features option in the left panel highlighted, and the Add Features option on the right panel:

Validating the Samba 4 configuration

There are many Snap-Ins which we can enable in the Add Features menu, many needing the installation of the Microsoft .NET Framework (for example, the Active Directory Administrative Center), but for now, we will add just the following:

AD DS Snap-Ins and Command-Line Tools

AD LDS Snap-Ins and Command-Line Tools

Using both the preceding Snap-Ins should be sufficient to run the dsa.msc tool and so, we can start creating our Domain's OUs. The following screenshot shows what the Add Features Wizard screen looks like:

Validating the Samba 4 configuration

Just click on Next and perform a final check of the right panel to confirm that you have selected the right options. If everything is as it should be, we can go ahead and click on the Install button, as shown in the following screenshot:

Validating the Samba 4 configuration

If you have not enabled the automatic update option on the Windows Server, you will receive a warning informing you that you should turn on Windows Update. Just check whether or not the installation process was completed without any error and the AD, DS, and LDS tools were successfully installed, and we can go on to the next step. Just click on the Close button on the Add Features installation screen, and we can close the Server Manager tool.

Now we can click the Start menu button, choose Run, and execute dsa.msc. After this, we should see a window on our screen like that shown in the following screenshot:

Validating the Samba 4 configuration

In the preceding screenshot, we have just selected our Active Directory domain POA.MSDCBRZ.EALL.COM.BR in the left pane, and to the right, we can see the default objects that are created when we perform the provisioning of a Samba 4 Domain Controller.

With this tool, we can create our OUs and create our structure to accommodate our objects the way we planned. In the following screenshot, we can see how to create the first top-level OU—Workstations (In the following screenshot, behind the first dialog box, we can see that our domain has been selected; this means that our new OU has been created under the domain):

Validating the Samba 4 configuration

In the following screenshot, when we are asked to enter a name for the OU, we just need to enter the name of the new OU, we want to create, in the text field, and click on OK.

Validating the Samba 4 configuration

Now, we can repeat the same procedure to create the remaining nine Organizational Units we planned for our AD. The remaining nine OUs are as follows:

· Desktops

· Laptops

· Services

· Terminal Servers

· Print Servers

· SQL Servers

· People

· Standard Users

· Power Users

When every OU has been created, our Active Directory structure will look as shown in the following screenshot:

Validating the Samba 4 configuration

Once we have our Active Directory structure finished, we can close the dsa.msc tool and log out from our Windows 2008 R2 Server. Now, we go back to our Samba 4 Server where we will create our 50 users (47 Standard Users and 3 Power Users). With the bundle of scripts from the book's repository, we have a tool to create all our users in the appropriate OU and with all the relevant attributes. The initial password will be the same for all users (Standard Users), and in the first log-in, the users will need to register a personal password. For creating a user, just open a terminal shell and execute the following command:

leal@debian7:~$ cd ~/workspace/implementing_samba4/ && ./createusers.sh -h

The previous command's output should be something like the following:

+-------------------------------------------------------------+

| Simple script to create users on the AD/DC (Samba 4 Server) |

| Implementing Samba 4 |

| |

| Copyright(c) 2013 Marcelo Leal |

+-------------------------------------------------------------+

Usage:

"-h" for this help message

"-c" creates users (silently).

"-v" creates users (verbosely),

showing the actual add user commands.

To create the users, the script uses a file named users.txt, which needs to be in the current directory.

Error Codes: (0)OK,

(1)Wrong Options,

(2)At least one user creation error,

(3) Could not open users.txt file.

First, we will create the Standard Users using the names provided in the users.txt file, and the script that we will use is intended to create users in the People/Standard Users OU only.

The file users.txt is very simple and is just a list of users with the name and surname. All the other attributes are handled by the createusers.sh script (for example, username and initials). The following is an excerpt of our users.txt file:

Vincent Vega

Jules Winnfield

Bruce Coolidge

Mia Wallace

Marsellus Wallace

Jimmie Dimmick

Phil Marvin

So next, we need to execute the following command in the Samba 4 Server prompt:

leal@debian7:~$ sudo ./createusers.sh -c

The output will show one line for each user created, indicating whether or not the user was created successfully or we faced any error. The following lines show the execution result for our file users.txt:

User: jajonnes created OK.

User: zojarratt created OK.

User: sahill created OK.

User: qumichael created OK.

User: rojohnson created OK.

User: jabrown created OK.

User: legecko created OK.

--------------------------

Total Users Created..: 47

Total Creation Errors: 0

Total Users Processed: 47

--------------------------

At the end of the preceding output, we can see that we have processed 47 users and no errors were reported. All users were created without any issue, and we should have them all in our Standard Users OU.

Now we can take a look at our Active Directory tree again and see in the graphical user interface, all the users we have just created, as shown in the following screenshot:

Validating the Samba 4 configuration

Summary

In this chapter, we saw in detail how to perform the provisioning of the Samba 4 Server as an Active directory Domain Controller, went through the initial phases of planning the network topology, structured the Active Directory, and created a checklist to help us organize information.

At the end of the chapter, we executed a series of tests and validations of important parts of the Active Directory server and thus, touched upon the subsystems that provide the core functionality of the Samba 4 AD/DC services. The last test was actually for joining a test server (Microsoft Windows 2008 R2 Server) to our POA Domain. We learned how to manage the Samba 4 Server from the Windows 2008 server, using the features that needed to be enabled on this Windows server's version.

Using our test machine, we tested the creation of custom OUs in our Active Directory, and so we could create our planned structure; and with the help of prebuilt scripts, we populated the AD/DC with 47 (nonPower) users.

In the next chapter, we will learn about the tools we can use to manage the Samba 4 Server, the basics of Group Policies management, and we will also cover authentication and authorization among other important GNU/Linux Systems features.