My network currently has the following server running Samba 3 as a standalone server to 50 client boxes: Linux a1 2.6.35.7 #3 SMP Samba Version 3.5.6. Currently, no true NT Domain Controller, in Windows speak - it's a Workgroup only.

I have another server that I want to configure to use Samba 4 as an Active Directory Domain Controller and file server: Linux a10 3.7.10-gentoo-r1 #1 SMP Samba Version 4.0.4.

I only have one subnet and cannot disrupt the users, but have read the following concerns on the Samba wiki: Make sure you thoroughly test your conversion and how your clients react before you activate your new server in your production environment! Once a Windows client finds and connects to the new server, it is not possible to go back!

Also, it is necessary to do testing on a separate network so that the old and new domain controllers don't clash. The issues with having both domains 'live' at the same time are:

The databases are not syncronised after the initial migration
Even if no changes are made to the DB, clients which see an AD DC will no longer honour NT4 system policies
The new Samba4 PDC and the old DC will both claim to hold the #1b name as the netbios domain master

The paths to certain files and directories for your Samba3 installation are often distribution specific (for example, /var/lib/samba vs. /etc/samba). Please be sure to verify and if necessary, modify paths used in examples appropriately.

- - - - - -

Has anyone dealt with only having one subnet upon which to configure and test a new Samba 4 server in the presence of a currently active Samba 3 server?

I was thinking maybe the simplest way would be to make an iptables firewall on the Samba 4 server -- allowing connections from only one particular address on the subnet and use that one address for a client box to test on.

Possible iptables rule (allowing one client address, blocking all others on subnet):
iptables -t filter -A INPUT -i eth0 -s 192.168.1.200 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -t filter -A INPUT -i eth0 ! -s 192.168.1.200 -j DROP

The warnings in the documentation are all about environments with NT-style Samba domain controllers.

Installing a Samba 4 DC in a workgroup environment will not disrupt anything. It may or may not add some records to your local DNS zone, depending on your configuration, but that is extremely unlikely to cause a problem.

In order to access resources on the DC, the computers currently in the workgroup will have to join the domain. This is a manual process, you'll have to log on to each workstation with an administrative account and join it to the domain. Until this is done, the Active Directory domain will remain largely inaccessible.

Once the PCs are configured as domain members, users may log on with AD credentials. If they do, they will be presented with a new user profile, and may access the AD DC. If they continue to use their old user accounts, they will keep their old user profile and will not be able to access AD resources.

The Samba 3 server may become inaccessible to AD users if the security mode is "user" ("security = user" in smb.conf) and you've defined users on the Samba 3 server and disabled guest access on shares. This happens simply because the users are now using different accounts. If you've based your workgroup setup around guest access, this will not be a problem. The Samba 3 server will in any case be available to users logging in with their old, local user accounts.

You can join the Samba 3 server to the AD domain as well (security = ads) and make resources like shares and printers available to AD users. Guest access will still work, if configured.

1 members found this post helpful.

Ser Olmy, thank you very much for the thoughtful response.
It appears I will be okay, yes, due to my Standalone configuration.

You bring up another good point that I would like to follow up on.
I will follow this guide to add windows clients to join the Samba-4 AD DC: https://wiki.samba.org/index.php/Con..._client_for_AD

If a win client box has a local user "Charlie" with Administrator rights, can "Charlie" join the Samba 4 AD domain? Or do I have to create a new and different user on the client box to join the S4 AD domain?

Thank you for reading this.

Local users and AD users are completely separate objects.

A PC may have a local user called "Charlie", but that's not the true identity of the user object. "Charlie" is an attribute of an object called something like "S-1-5-90-1947300570-5469872554-32479435-1001". This is the Security Identifier, the true identity of a Security Principal like a user, computer or group. SIDs work like Linux UIDs, except that they are globally unique, cannot be manually specified, and are never reused.

When you create a local user object, a SID is generated. When you log on for the first time, a user profile is created on that particular computer and tied to that SID. That SID only exists on that particular computer.

Joining a PC to Active Directory "outsources" the authentication process to domain controllers. You can now log on using names like "DOMAIN\Charlie" or "charlie@domain.local", which are two ways of referencing a user object that exists in AD rather than on the local system. The "Charlie" from the AD domain has a completely different SID from "Charlie" on the local computer. They are two completely different user objects that happen to share an attribute.

The whole point of joining a PC to an AD domain is to have all user accounts stored in the directory. You do not have to create local users at all, you create users in AD instead. When you log in to any PC in the domain with a particular set of AD credentials for the first time, a local user profile is generated and tied to the SID of that user.[*]

A common scenario is that you have PCs in a workgroup that contain user profiles, and the users want to keep their documents, shortcuts and settings at they move to a domain-based environment. There are tools in Windows that can migrate user profiles from one user and/or PC to another, and these can be used to copy a profile from a local user to a domain user.

[*] There's a setting on every user object in AD that can specify an alternate location for a user profile, such as a network share. This makes it possible to use the same profile on multiple computers. There are also Group Policy settings for redirecting profile folders to network shares, and these work much like having /home/[username] in a centralized location.

This is great info. and I appreciate your guidance.
I'm going to have fun learning how to configure, use, and deploy Active Directory.