Upgrading from Samba Server Version 3

(For more resources related to this topic, see here.)

Distinguishing between Samba Versions 3 and 4

From the Samba Version 4 release notes made by the Samba project, we got information on the addition of the DNS server and NTP protocols that are integrated in the new Samba 4 code, LDAP server and Kerberos Key Distribution Center (KDC)—both accounted within the Active Directory Services, support for SMB Version 2.1 with preliminary support for Version 3.0, and the Python scripting interface—all of which we will highlight as great and bold, new capabilities.

These new features can make the Samba Server Version 4 look appealing from an upgrade perspective for the Samba Server Version 3 users. It can also stimulate new installations, as it can be a strong choice to provide full network services as open source and as a free alternative in comparison to Microsoft Windows Servers.

The classic model (NT4 Domains) is still supported and present in the Samba Server Version 4, but the new version's real gain for users and system administrators is the ability to use all the new features introduced by Microsoft with the development of the Active Directory Domain Controller services. All these are associated with the concepts of delegations, group policies, new security model, and so on.

The fact is that the Samba Server Version 3 is a rock-solid software. The file and print's server code is very stable and has been working for many, many years. Besides this, the Samba Server Version 4 has implemented a new approach and daemons for these services; the new project's software version still has support for the old and bullet proof file/print server daemons and those are the ones that are recommended for production purposes at the time of this writing.

Many users are really happy with the file and print services from Samba Server Version 3. As a great portion of the use cases and base installations of the Samba Server is for the purpose of these services, many users remain with the Version 3 in production, where the scary problem is to support the new Microsoft Windows Operating System versions.

So, for the users who are looking at and exploring the upgrade process, the real difference and the main feature that encourages them to take the upgrade path most of the time, which are the Active Directory services present on Samba 4. The new code has integrated the DNS and LDAP server and KDC. So, many users from the previous versions that could be intimidated by the need to deal with external and complex software combinations (for example, DNS/Bind or OpenLDAP) for small and medium installations can now have a really robust and complete solution for the Samba project's new release.

Key points for consideration before the upgrade

It's never too much to remember that the only guarantee we can have when dealing with technology services and maintenance procedures on production systems is the backup—straight and simple.

The upgrade process from the Samba Server Version 3 to Version 4 will have a phase where the software's rollback can be a very difficult task or maybe not even possible. So, a backup not just of the Samba Servers involved, but of the domain's other important machines is really crucial too. This is to make sure that the environment can be brought back online to a consistent and operational state at any time.

Another important point in the planning phase is to take into consideration the size and complexity of the network services' environment. We need to consider how many clients, servers (directly or indirectly involved), and how much time is needed (and available) for the upgrade procedure. Different environments may require different approaches, and a big network and/or a short maintenance windows may require a staged upgrade.

We will focus, as is the sole objective of this article, on the Samba 4 Server as a complete system to provide all services for which it is intended. In a real scenario, we need take a look at the auxiliary services that we use, instead of Samba or other services that are not involved in the upgrade process directly but can or might get impacted. This is a case-by-case analysis, and the reader needs to pay serious attention to these services, and having a checklist and enumeration of all these services and applications is a mandatory step.

Prepare the upgrade procedure taking into account the time that will be available to execute the whole upgrade process, and remember that the time to validate and test it is a part of the process. Take notes on the number of users, groups, machines, and all configured resources that are relevant for the upgrade process. This information is the key for the validation of the whole procedure. Create a checklist of service names (for example, endpoints) and applications that can be impacted, and schedule the upgrade accordingly. We will use some scripts and command-line examples to extract the information from the system, but it is a good idea to have some kind of checklist with quick access to the global aspects of the environment to facilitate and help spot on any issues.

As the Samba Server Version 3 has no built-in DNS server, we'll cover a Bind9 implementation in the upgrade procedure as an example of the DNS side of the upgrade process and its integration with the ISC-DHCP server it's a very common implementation among users of Samba 3. The reader has a choice to maintain Bind as the DNS server after the upgrade or move the resolution services for the Samba Server Version 4 (in this article, we will implement the latter option). Last but not least, the Samba Server Version 4 software needs to be installed and tested prior to the upgrade process with all needed dependencies in all Samba 3 systems that we will upgrade.

Establishing an upgrade plan

The upgrade plan needs to be created focusing on the environment that it will be applied, but we will have some general rules that can be a base for many environments, a generic procedure for the gathering of information, tests, validations, and a practical upgrade example that can be used as a base for a final plan.

In our example case, we will deal with a Microsoft Windows NT4-like domain for one of the EALL Company sites, based in Porto Alegre/RS – Brazil. This site is controlled by one Samba Server Version 3 as the Primary Domain Controller (PDC) for that region (for example, POA), and two Samba Servers Version 3 acting as Domain Member Servers for each Division/Department of the EALL site in Porto Alegre.

The company is very inclined towards Microsoft products, and the three GNU/Linux systems were installed for the POA's network services as a global decision to lower the IT costs. EALL is successful with Samba's adoption, and as the company has other offices in many places around the world, it has resulted in big savings year over year, as dozens of Debian GNU/Linux PDCs and print/file servers do not need license fees.

Another big advantage the company has while implementing Samba 3 to provide the network services is that it has more flexibility to scale as the file servers present performance problems from time to time, so other filers can be easily deployed without incurring additional license costs. This provided us with a big gain in the quality of the services for the users, better architecture (services are decoupled), reducing complexity, and lowering overall downtime in hardware and software maintenance.

Now, the company sees a huge opportunity to evolve its Microsoft Network with the new Samba 4 release and use it as a free and open source pilot for the Active Directory Services (ADS). At some of its other sites, the company is already using ADS on newer versions of the Microsoft Windows operating system.

Our Samba 3 upgrade will be focused on three basic sets of services:

  • Authentication services: These include machines, users, and groups (Samba3)
  • File/print services: These include files and printer shares (Samba3)
  • DNS services: These include the name resolution (Bind9)

Every Samba 3 installation needs to have a combination of the core services listed earlier: at least one name resolution system and one (usually both) set of Samba 3 services (in one or more servers).

The Samba services can be provided completely in just one server or distributed in different servers for performance, architecture decision, company policies, and so on. As we go through this procedure, we will see that it is much easier to manage and deal with a medium to big network complexity, with the services that are decoupled. Also, we can handle the whole upgrade procedure in small and separate steps.

In any case, if your specific environment has just one server providing all the services we have mentioned here, there is no problem, as in the end, the process that will be executed will be focused on the services, and thus will be executed on the server where that service resides. Therefore, if we have a site where we have decentralization of services in different servers or in just one server, then all the services are provided by a standalone server. We should notice that the downtime needed to execute all the upgrade procedures in one server alone, which provides all services, can be bigger and much more complex, though. This is why this upgrade can be a very good opportunity to review the architecture of the Samba services and adjust it as needed.

Another important aspect of handling the process at these three different sets of services is that we have specific procedures for each step. So, the upgrade step for the file and print servers, for example, can be replicated as we have more than two Domain Member Servers that are the exact same way. Then, we can establish priorities, and for bigger and more complex environments, we can execute a staged upgrade.

In our example case, we have the file and print services in specific Domain Member Servers that are dedicated to the departments of our company. So, we can handle them with the different priorities and department's maintenance windows, accordingly.

Here is some general information we need at hand for our network, and soon, we will see how to gather them all:

General system and environment information

Server #1

The Samba Server version



Primary Domain Controller (Network Logon Services and

User's profiles)



IPs (eth1), (eth0)

Other services

DHCP Server (ISC), DNS Server (Bind9), NTP, and CUPS


Profiles (/home/POA/)



Server #2

The Samba Server version



Domain Member Server (file and print services)



IPs (eth0)

Other services



ACC Division (/shares/*)

Server #3

The Samba Server version



Domain Member Server (file and print services)



IPs (eth0)

Other services



Devel department (/shares/*)

General Samba network information





Default router

DHCP Server

DNS zone files



Number of users


Number of groups


General Samba network information


Microsoft Windows 2003 and XP

Application servers

Microsoft Windows Server 2003

Maintenance time

2 hours

The preceding information is presented here as a basic example. We will save much of the information in the text files to facilitate the validations after we have concluded the upgrade, but this information is very important to provide quick access to very crucial information; it also works as a formal document that can be attached to the maintenance plan.

After all tests and validations, our upgrade procedure will be executed in a single place for all the Samba Servers. Feel free to add any other information that you think is necessary to the preceding document or attention points to check before and/or after the upgrade. One good example is some consideration about external storage devices, if any (for example, volumes/luns), backing shares. In our example, the EALL Company uses local disks (for example, Direct Attached) to all Samba shares, so there was no need to mention it in the preceding document.

If you followed our Samba 4 installation instruction, the binaries should be compiled with all features needed for the upgrade as we have installed the main dependencies, and the Samba's configuration script should automatically detect and enable them. Don't proceed to the upgrade phase without making sure that all the features that are needed are present on the Samba 4 installation (for example, CUPS and ADS).

Creating tests and validations before the upgrade

Our tests' and environment's validations will start on a clone of the currently installed software—a subset that is representative of our production environment. So, the first task is to establish a small group of machines to clone in a virtual or physical environment to be used to create our tests and validations, and also to exercise our upgrade procedure. After the upgrade, we will execute the same tests described here, and we will know exactly what the expected results are.

The best way to do this is to create a lab in a virtual environment, we will not test any hardware upgrade, and all the device drivers and components needed for the proper execution of the production software are assumed to be in place and in a working condition. So a virtual environment is a perfect fit, and we will execute some checks on it to guarantee that the environment is working as expected and no misconfigurations exist.

In case you use a virtual environment for your tests, create snapshots of all machines in this environment after you have it all set up to be able to go back and forth on the procedure and restart the whole process when necessary.

In software upgrade procedures, it's very common to face problems after the upgrade that actually were present before the upgrade process. This can mislead the result or unhide a latent issue at the wrong time. Thus, we will use this phase and test environment to validate the current system configuration, and if any issues are discovered, they can be fixed prior to the maintenance. On top of that, we can use this procedure until we have a bulletproof process.

So, we will present some commands and scripts that can be used to make sure that Samba 3 is working as expected this is very important for the upgrade process to work.

Do not execute any script directly in the production stage; or, make sure you know what you are doing, because we are not responsible for any disruption or data loss that you may incur while executing scripts and commands in a production network without prior testing.

Let's start with the PDC Server and basic tests, such as listing users and groups. Using a command prompt at the Primary Domain Controller, execute the following command:

root@pdc:/root# wbinfo -u … miwallace bekiddo jocabot jabrown … root@pdc:/root#

The preceding command is wbinfo, a tool to query information from the winbind daemon, and we used the -u option to list all the users in the domain. Now, let's see how many users we have:

root@pdc:/root# wbinfo -u | wc -l 51 root@pdc:/root#

As we can see in our plan, we have 51 users in the domain, which is exactly what we've got as an output from the preceding script (one user is the root account, which is mapped to the administrator on the EALL Samba 3 installation). It's important to note that Debian GNU/Linux has some other personal administrative accounts that are not included on that list as the domain users are totally separated from the host operating system's accounts. EALL's architecture choice is not to authenticate the Debian GNU/Linux host on the Samba 3 PDC itself. Still using the wbinfo utility, execute the following command:

root@pdc:/root# wbinfo -g eall group eall domain users eall domain admins … root@pdc:/root# wbinfo -g | wc -l 9 root@pdc:/root#

In the preceding output, we have two other important points of information about the system that we will upgrade: the list of groups and the total number of groups in the domain. As we did in the users listing, we have omitted the whole list of names in each group for brevity. However, it's a good idea to save both the full listings for future validation:

root@pdc:/root# wbinfo -u | sort > samba3users.txt
&& echo OK OK root@pdc:/root# wbinfo -g | sort > samba3groups.txt && echo OK OK root@pdc:/root#

The preceding two commands have been created in the /root directory, two text files (sorted) with the lists of users, and groups in the domain. Feel free to organize it in a specific directory or send the files to an external server (this is recommended because it's good to have this listing but not on the server on which we will actually execute the upgrade procedure).

Another good test is to use the smbclient utility, and authenticate it against our Samba 3 Server (PDC) and get a good view of the network resources and other important insights about our main Samba 3 Server. Using a test account for the domain (or any other specific account that you know the password), execute the following command:

root@pdc:/root# smbclient -L pdc -U 'frorange%w1ndow$$'
Enter frorange's password:
Domain=[POA] OS=[Unix] Server=[Samba 3.6.6]
Sharename Type Comment
--------- ---- -------
Profiles Disk EALL Roaming Profiles Share
IPC$ IPC IPC Service (EALL Network Services)
Domain=[POA] OS=[Unix] Server=[Samba 3.6.6]
Server Comment
--------- -------
ACCSRV01 ACCDivision Office Server
DEVSRV01 DEV Office Server
PDC EALL Network Services
Workgroup Master
--------- -------

This is one of the most important commands because it gives us a good view of how our services are decoupled. The preceding output tells us some of the following interesting things:

  • We have the main IPC Service for our Samba 3 Server PDC
  • One share (Profiles) for the roaming profiles of our domain
  • Our workgroup name, POA, and the Samba Server Version 3.6.6
  • The PDC server is the master of our domain (Primary Domain Controller)
  • We have two other servers: ACCSRV01 and DEVSRV01

You can use the following syntax to execute the smbclient command that provides the password directly on the command line:

user%password. See the following example: smbclient -L pdc -U ' 'kischultz%w1ndow$$'

So, this server has two important roles on the EALL network: it is the PDC (controls authentication and authorization) and the Profiles' share. To enhance the decoupling of services on this network, a good option would be to create a specific file server to hold the users' profiles (for example, an HA Filer) and to leave the PDC with just one role in this network. This would facilitate the backup and recovery of this server as it is the only PDC, and if we have the backup of the DB and smb.conf files, we can quickly recover from a failure on the main PDC (our most important network service). On top of that, we could focus on an HA solution for the filer that is responsible for the users' Profiles to have a better resilience (for example, a Storage backed Profile share).

The preceding test helped us indirectly validate another important function of our Samba 3 Server—authentication. However, we can use the ntlm_auth command to specifically test it, as exemplified in the following command execution:

root@pdc:~# ntlm_auth --username=jobrittle --domain=POA password: NT_STATUS_LOGON_FAILURE: Logon failure (0xc000006d) root@pdc:~# ntlm_auth --username=jobrittle --domain=POA password: NT_STATUS_OK: Success (0x0)

Remember that it is important to test with the wrong password (as we did earlier). Sometimes, we fail to identify problems in our environment because we just test using the same pattern. It's important to test with wrong pathnames, wrong passwords, and usernames that in fact do not exist, and so on. Many misconfigurations have been a result of a configuration that permits access for any user or any password. Now that's a really bad misconfiguration!

It's recommended that you have your infrastructure automated with recipes and tests. A long time ago, I implemented a system to programmatically provision, test, and validate the infrastructure resources, Battery of Tests and Validations (BTVA) of the environment, and it was a really powerful tool to identify and even fix issues on the operating system configuration. Since then, I have used that model when managing any kind of system.

The system was based on Makefiles and many scripts to test and validate every corner of the environment that was needed to run a specific application. The essential point about this approach is that you just add tests, and over time, the whole environment just gets better coverage. After a test is written, the same error does not happen twice, and after some time, we have a really strong system to validate our environment. Now, with devOps and new approaches to handle and implement these kind of automations, it is highly recommended that you have the tests described here incorporated in your tools and provisioning systems.

Here is an example of how we can quickly create a script to execute a good validation of our user's database (we can save the listing for future reference):

root@pdc:~# for x in `wbinfo -u`; do wbinfo --name-to-sid $x; done … S-1-5-21-1214754503-652539266-1573105461-1023 SID_USER (1) S-1-5-21-1214754503-652539266-1573105461-1028 SID_USER (1) S-1-5-21-1214754503-652539266-1573105461-1044 SID_USER (1) S-1-5-21-1214754503-652539266-1573105461-1008 SID_USER (1) … root@pdc:~#

If we have any user who is not properly mapped in the Samba database, or if we fail to actually translate a SID to a user/group, we'll have problems ahead. So, I just want to make sure that the reader understands that the more tests and automations we do, the better it will be to validate our upgrade. The examples that have been shown here can be enhanced, and if one test is made for one user as an example, it can be simply modified to make the same test for all users as we just did on the example script earlier.

Now it's time to test our two file/print servers: ACCSRV01 and DEVSRV01. We will use the smbclient utility to execute the same test that we performed for PDC as it will show us very detailed information about our two Domain Member Servers. From the command prompt on our PDC Server, execute the following command:

root@pdc:~# smbclient -L accsrv01 -U 'legecko'
Enter legecko's password:
Domain=[POA] OS=[Unix] Server=[Samba 3.6.6]
Sharename Type Comment
--------- ---- -------
--------- ---- -------
IPC$ IPC IPC Service (ACCDivision Office Server)
ACCPRTMM01 Printer 1F Printer MM
ACCPRTLS01 Printer 2F Printer
PRINT$ Disk Drivers for Dep. Printers
ACCPUBLIC Disk Public Share
ACCDIVDOCS Disk Accdivision Prospects
ACCDIVRPTS Disk Accdivision Reports
Domain=[POA] OS=[Unix] Server=[Samba 3.6.6]
Server Comment
--------- -------
--------- -------
ACCSRV01 ACCDivision Office Server
PDC EALL Network Services
Workgroup Master
--------- -------
--------- -------

Again, we could test name resolution and authentication, but on one of our Domain Member Servers this time as this is really important, or users will not be able to access the services from that server. Here is the information we that we got from the preceding test:

  • We have the main IPC Service for our Samba 3 Domain Member Server
  • We have four file shares: ACCDIVRPTS, ACCDIVDOCS, PRINT$, and ACCPUBLIC
  • We have two printers: ACCPRTMM01 and ACCPRTLS01
  • Our workgroup name, POA and Samba Server Version 3.6.6
  • The Primary Domain Controller Server for our Domain: PDC

So, let's take a look at the execution output of this same command, but this time, for our second Domain Member Server:

root@pdc:~# smbclient -L devsrv01 -U ' 'zojarratt'
Enter zojarratt's password:
Domain=[POA] OS=[Unix] Server=[Samba 3.6.6]
Sharename Type Comment
--------- ---- -------
--------- ---- -------
DEVPRT01 Printer General DEV Printer
IPC$ IPC IPC Service (DEV Office Server)
Domain=[POA] OS=[Unix] Server=[Samba 3.6.6]
Server Comment
--------- -------
--------- -------
DEVSRV01 DEV Office Server
PDC EALL Network Services
Workgroup Master
--------- -------
--------- -------

Here is the interpretation of the preceding output:

  • We have the main IPC Service for our Samba 3 Domain Member Server
  • We have two shares: DEVCODDS and DEVSRCAP
  • We have one printer: DEVPRT01
  • Our workgroup name is POA and Samba Server Version 3.6.6
  • The Primary Domain Controller Server for our Domain PDC

In Samba, we need to have the domain groups mapped to our Unix groups on the PDC to provide the same authorization to each share that our Domain Member Server provides to our network. So, based on that mapping, it's a good idea to test some of our users and groups to validate that our associations are working as expected.

For an example, take a look at the Unix group, accdivision, and its members as this group is mapped to the domain group, accdivision:

root@pdc:~# grep accdivision /etc/group accdivision:x:1002:zafalca,cafreeman,qumichael,zisala root@pdc:~#

Executing the following command, we can validate the mapping and save the results:

root@pdc:~# net rpc group members "accdivision group" "| tee >accdivisiongroupmembers.txt Enter root's password: POA\zafalca POA\cafreeman POA\qumichael POA\zisala root@pdc:~#

In all the Member Servers, we need to validate the users/group resolutions. So, let's take a look at the NSS configuration for the DEVSRV01 server as an example:

root@devsrv01:~# id djfox uid=2031(djfox) gid=1513(domain users) grupos=1513(domain users),2051(eall domain users),2053(devel group) root@devsrv01:~# getent passwd djfox djfox:*:2031:1513:djfox:/home/POA/djfox:/bin/false root@devsrv01:~#

Another test that we need to make is to have a Microsoft Windows system test a join into the domain and do some normal activities, such as logon and roaming profiles. We can create one test user and add it to some groups to test the access to the different shares/printers, and after that, we can remove the user. This will test our DHCP Server and its integration with DNS too, helping us guarantee a proper configuration of the whole system. Let's execute some commands to actually test the machine's name resolution on the EALL network:

root@pdc:~# host -t A pdc pdc.poa.msdcbrz.eall.com.br has address root@pdc:~# host domain name pointer pdc.poa.msdcbrz.eall.com.br. root@pdc:~# host -t A windowsxp windowsxp.poa.msdcbrz.eall.com.br has address root@pdc:~# host -t MX poa.msdcbrz.eall.com.br poa.msdcbrz.eall.com.br mail is handled by 10 mail.poa.msdcbrz.eall.com. br. root@pdc:~# host -t SOA poa.msdcbrz.eall.com.br poa.msdcbrz.eall.com.br has SOA record pdc.poa.msdcbrz.eall.com.br. root. poa.msdcbrz.eall.com.br. 2007010408 3600 600 86400 600 root@pdc:~#

Tests and validations are executed, and no misconfigurations were found, and that's good. We have saved files with the user and group listings, and we have a plan with all the information about our upgrade maintenance. Now, we are ready to proceed to the upgrade process in our lab environment so that we can validate each step of the upgrade and have an opportunity to fix the process inconsistencies, if any.

Executing the Samba Server upgrade procedure

We will execute our plan following the three service approaches that we mentioned earlier, and we need to start with the PDC Server that provides the Authentication/Authorization Service. The other two will be executed in a sequence, starting with the DNS Services, and the last one will be the file/print services provided by the ACCSRV01 and DEVSRV01 servers. The file/print servers can be executed in any order, so we have the flexibility to prioritize one over the other based on factors such as the business impact. In this specific example case, there is no priority or preference, so we have chosen to start with the ACCSRV01.

When executing the procedure in the production, remember that we need to have a backup for our PDC and Domain Member Servers, and for any other servers or clients that we know have crucial data and can't be recreated or easily rebuilt. This is because it can be really difficult to fix/remove a Microsoft Windows Machine after it finds the new Active Directory Server in case we need to rollback our upgrade. So, it's advised that you block the network access for the PDC while you think that it is still not ready to provide the full services.

So, let's turn our attention for the procedure on the main element of our Samba 3 implementation, the Primary Domain Controller (PDC). The PDC server is the one with this role at the EALL Network, and it has important auxiliary services, such as NTP, DNS, and DHCP servers too. We will work on this server for the two initial phases, and when we have that done, we should have the main functionality of our POA Domain fully working (for example, users, groups, machines, and name resolution).

First, we need to make sure that we don't have groups with the same name as usernames in our Samba 3 Domain, as in the Active Directory, we cannot have usernames and groups sharing the same name, and in case we have, we will need to rename them. If we make use of these groups in the Samba 3 Domain (for example, for file/print services), then we need to replace any references to them on the smb.conf files of our file/print servers to reflect the new naming.

So, it's important to take note of all groups that we have renamed, and when we start to work on the file/print servers, we can execute the same change as they reference the groups by names. Here are examples of how we have renamed the two groups:

root@pdc:~# export PATH=/usr/local/samba/sbin:\ /usr/local/samba/bin:$PATH root@pdc:~# net rpc group rename "Domain Users" "EALL Domain Users" Enter root's password: root@pdc:~# net rpc group rename "Domain Admins" "EALL Domain Admins" Enter root's password: root@pdc:~#

The preceding export command is very important as it prefixes the newly installed Samba 4 binaries on our PATH, and we will execute all the upgrade procedure commands in this shell. It's a good idea to add this command to our shell startup files (for example, .bashrc and/or .bash_profile ), so we'll always have the new Samba 4 utilities in precedence in our PATH. Before we are able to actually remove the old Samba 3 installation, it is very important to reference the right tools.

As we can see in the preceding command execution, we just needed to provide the administrator's password (for example, root) and the group's name gets changed. Another recommendation is to change the name for other standard groups that come with Samba Server 4 if they are present in our Samba 3 installation for any reason; for example, Domain Guests, Domain Computers, and Domain Controllers. All the mapping between the Unix and Domain groups that we may have should still work without issues after the renaming, as the mapping is made by the GID to SID.

To create default group names with the same name as the newly created user is the default behavior of many GNU/Linux distributions, and I have personally never used this group that is created exclusively for a user to implement anything. I prefer actually to get rid of this on the systems I manage. Thus, every new user is created with the default group assigned to the users, and this group is mapped to the EALL Domain Users group. For example, if you want to do the same, but you don't have more than 1000 users, and your GNU/Linux distribution starts to assign users and groups IDs from 1000 onwards (for example, Debian GNU/Linux), the following script will create a new file with the existing users reassigned the primary group of users (GID 100):

root@pdc:~#sed 's/[0-9]\{4\}::/100::/g' /etc/passwd > >/etc/passwd-`date +%Y%m%d-%T` `&& cd && echo OK OK root@pdc:~#

If the preceding command returned OK, a new file will be created with a name like this: passwd-20130619-13:16:14 (with your execution date and time). Take a closer look at this file and if it is right, you can replace the original /etc/passwd with it. Pay attention to the system users to make sure that they were not impacted, but as the system users have very low UIDs and GIDs, they should not be affected by this script. If everything is good, you can edit the /etc/group file and delete all the groups that have the same names as the users.

Normally, default UMASK for users is to permit them to read/execute for the primary group (usually, the group specifically created for that same user, as it does not have any other members). If you choose to follow this path, make sure that any security policy or applications will not present any issues. After this change, you will need to fix the directories and files that are pointing to GIDs that actually do not exist anymore. Remember that this is not a necessary configuration for the Samba 3 to 4 upgrade, as the only requisite is to not have groups and users with the same name as the ones in the Samba 3 database.

Stopping and disabling Samba and winbind daemons

Now, we will stop the Samba and winbind daemons, and remove the execution bit for the initialization scripts to guarantee that they will not start inadvertently (for example, after a reboot). So, let's execute the following commands at the PDC server:

root@pdc:~# /etc/init.d/samba stop && &&/etc/init.d/winbind stop && chmod -x /etc/init.d/{samba,winbind} }&& echo OK [ ok ] Stopping Samba daemons: nmbd smbd. [ ok ] Stopping the Winbind daemon: winbind. OK root@pdc:~#

After the execution of the preceding script, if the results are OK, we must stop the smbd/nmbd and winbind daemons, and have both the startup scripts disabled. As our PDC server is the default gateway for our private LAN, we have a public interface configured on this server. The Samba script will use and try to configure all the interfaces configured on the server; thus, we will disable the public interface and enable just the interface that has the connection with the Microsoft Windows network that we are interested:

root@pdc:~# ifdown eth0 && echo OK OK root@pdc:~#

As the preceding command returned OK, the interface eth0 (public) is disabled properly, and we can go to the next step. In this stage, we have the environment ready to execute the classicupgrade function of the Samba 4 tool. Just issue the following command as root at a terminal window on the PDC server:

root@pdc:~# samba-tool domain classicupgrade --dbdir=/var/lib/samba/ /--use-xattrs=yes --realm=poa.msdcbrz.eall.com.br /etc/samba/smb.conf && echo "---===--- Upgrade from Samba 3 to Samba 4 OK 4OK---===---" … Fixing provision GUIDs A Kerberos configuration suitable for Samba 4 has been generated at /usr
---===--- Upgrade from Samba 3 to Samba 4 OK
---===---root@pdc:~# cp -pf /usr/local/samba/private/krb5.conf /etc
&& echo OK OK root@pdc:~#

The preceding command should produce a very verbose output with important information about the upgrade process. This information includes the import of users, groups, machines, the creation of new standard groups, and so on. One such information was highlighted earlier, where the script tells us that a Kerberos configuration file was automatically generated and is ready for the utilization of our domain. We received this message: Upgrade from Samba 3 to Samba 4 OK. So, we have copied the Kerberos file to its definitive location.

Editing the Samba 4 configuration file

Now we need to edit the Samba 4 configuration file that was automatically created for us by the samba-tool utility, and add the following lines to the global section:

(/usr/local/samba/etc/smb.conf): interfaces = lo,eth1 bind interfaces only = Yes dns forwarder =

The first two lines of the previous command specify the interfaces in which we want the Samba 4 Server to listen (in our case, the loopback and eth1 interfaces; adapt it accordingly to your needs), and in the last line, we added a DNS forwarder configuration to be used for our internal network (Microsoft Windows clients and servers) to resolve names that are not the responsibility of our local DNS Server (for example, not in poa.msdcbrz.eall.com.br zone ). In a real world, you will need to replace the preceding example's IP address (for example, with the right IP address of the DNS resolver of your network.

We need to make sure that the NTP Server is configured to signed updates, so basically, we need to have the following lines at the end of our /etc/ntp.conf file:

ntpsigndsocket /usr/local/samba/var/lib/ntp_signd/ restrict default mssntp

Let's restart our NTP Server:

root@pdc:~# /etc/init.d/ntp restart [ ok ] Stopping NTP server: ntpd. [ ok ] Starting NTP server: ntpd. root@pdc:~#

We need to copy the scripts that we have on the netlogon standard share to their new location in our Samba 4 installation:

root@pdc:~# cp -pRf /var/lib/samba/netlogon/scripts/* /usr/local/samba/ var/locks/sysvol/poa.msdcbrz.eall.com.br/scripts/ /&& echo OK OK root@pdc:~#

The preceding result OK is the signal that we have finished upgrading Samba 3 from the Primary Domain Controller's perspective, but we have not finished our work on the PDC server just yet as we still have to migrate the DNS Services to the Samba 4 Server. The samba-tool utility should have already created all the needed SRV and other DNS basic records for a proper Active Directory installation, but it does not know about some static contents that we may have on our DNS Services for servers and services such as e-mail, pop, and www. So, we can now stop the Bind9, start the Samba 4 services, and execute the following script just by passing the database file for our DNS Server, and it should populate our Samba 4 internal DNS with the missing entries:

root@pdc:~# /etc/init.d/bind9 stop [....] Stopping domain name service...: bind9 waiting for pid 2220 to die . ok root@pdc:~# chmod -x /etc/init.d/bind9 && echo OK OK root@pdc:~# /usr/local/samba/sbin/samba && echo "Samba 4 Started OK" Samba 4 Started OK root@pdc:~# kinit && echo OK Password for root@POA.MSDCBRZ.EALL.COM.BR: OK root@pdc:~# grep -w 'A\|CNAME' /var/lib/bind/db.poa | |\ awk '{print "samba-tool dns add pdc poa.msdcbrz.eall.com.br", \ $1, $2, $NF}' | /bin/sh Record added successfully … root@pdc:~#

After the confirmation of the initialization of the Samba 4 Server and each successful entry creation on our Samba 4 DNS Server's database, we should have our static CNAME and the records from our BIND9 configuration added to the Samba 4 built-in DNS Server. If some record already exists in the Samba 4 database, it is not an issue as the command will indicate that and will not duplicate it. One last record that needs to be created by hand, if needed, is the MX:

root@pdc:~# samba-tool dns add poa.msdcbrz.eall.com.br @ mx "mail.poa.msdcbrz.eall.com.br 10" Password for [root@POA.MSDCBRZ.EALL.COM.BR]: Record added successfully root@pdc:~#

Configuring the reverse zone

With our DNS main zone configured and populated with the static records, we just need to create and add the records for the reverse zone. For that, we just need to execute the following commands at the pdc server:

root@pdc:~# samba-tool dns zonecreate \ 1.168.192.in-addr.arpa -U Administrator%'w1ndow$$!' Zone 1.168.192.in-addr.arpa created successfully root@pdc:~#

The reverse zone is created, but remember that you will need to replace the network (for example, 1.168.192.in-addr.arpa) with the real network in your environment. Just as an example, if your network is, you would use 2.10.10.in-addr.arpa instead. Now, to create the PTR records for our hosts, we can use the next script to do the dirty work for us. We are providing the password in the script, so all the records are created without an interaction:

root@pdc:~# grep -w 'A' /var/lib/bind/db.poa | |\ awk '{split($3,IP,/\./); print "samba-tool dns add pdc \ 1.168.192.in-addr.arpa",IP[4], ],"PTR",$1".poa.msdcbrz.eall.com.br \ -U \x27Administrator%w1ndow$$!\x27"}' | /bin/sh Record added successfully Record added successfully … root@pdc:~#

Remember the security policies, and as a general rule, it is not a good idea to have passwords in scripts or commands that will be saved on the history file.

Adding the profiles share to the configuration

Now, we can add the Profiles share to our Active Directory Domain Controller, which is the only share our PDC is providing to the network. For this, we only need to edit our /usr/local/samba/etc/smb.conf file and add the following lines (copied from the Samba 3's smb.conf file):

[Profiles] comment = EALL Roaming Profiles Share path = /home/POA read only = No As we have edited our main configuration file, we need to reload it, and
so we can bring back online our eth0 interface: root@pdc:~# smbcontrol all reload-config && echo OK OK root@pdc:~# ifup eth0 && echo OK OK root@pdc:~# Welcome to our brand new Samba 4 Active Directory Domain Controller!


We learned about the main difference between the Samba Server Version 3 and 4, how to plan and execute an upgrade procedure of the Samba Server, and a step-by-step process to test and validate the upgrade as well. Using the command-line examples and scripts, we showed you how to gather important information from the Samba 3 environment and how to use that information to compare it with the upgraded system and be sure that the transition from Samba 3 to 4 was successful.

Resources for Article:

Further resources on this subject:

You've been reading an excerpt of:

Implementing Samba 4

Explore Title