OpenSUSE support for AD Domain and Forest functional level

Hello All,

We have multiple machines running OpenSUSE 11.3 with Kernel version 2.6.34-12. The existing domain and forest functional level is 2003. We have AD and LINUX integration enabled and these OpenSUSE machines are member of our Active Directory. They use Samba internally to connect to AD. We are planning to upgrade the AD to Windows 2012 R2, so we need to know if the OpenSUSE 11.3 support Domain and Forest functional level of 2008 R2 and above? What newer version of OpenSUSE supports, if 11.3 does not support it.

Any help will be greatly appreciated.


Not based on any reference, but generally speaking based on what I’m familiar with…

Domain Client Machines
That’s a pretty big AD jump, IIRC you’re skipping over at least one if not two(2005, 2008) major AD releases.
AD 2003 was one of the earliest versions of AD (IIRC the earliest was 2000) and in those days it was even deployed often with NT Domain compatibility.

In Linux, we have more or less the same thing…
SAMBA3 is NT Domain (not really AD) architecture, and that was the only SAMBA available for openSUSE 11.3 that worked (SAMBA4 was “in development” for about a decade before it was finally mostly finished).

You’ll want to install SAMBA4 in your new, upgraded Linux.
For that reason, IMO you should disjoin your openSUSE 11.3 machines from the Domain before you upgrade your AD.
Upgrade your openSUSE on their own, logging in with local machine credentials.
Rejoin the Domain. There is a good chance you’ll lose the original machine IDs so you may need to remove the old machine account before you can successfully re-join the Domain, creating a new machine account.

**Domain Member Machines (DC, File Servers, etc)
**The following seems to describe retaining NT4 compatibility which may not be what you’re doing

In general though, you may want to more or less follow what I described for Domain Client machines (remove, upgrade, rejoin)

As always,
Consider consequences to any User apps or Server apps if on a Member Server, particularly those that require Domain authentication. Most apps I’m aware of that use Domain authentication utilize only User IDs, but there may be some like systems apps (eg network firewall clients) that also use machine IDs, but if even those apps are fully integrated into AD, they should pick up <all> relevant ID changes.

And again as always…
Test your upgrade in a test network before you roll out to Production.
Your test upgrade network (virtualized or not) may even become a part of your final upgrade solution.
Backup, backup, backup. And verify. Before you start. Nothing is worse than taking down an entire Domain due to something unexpected and then scrambling for hours or even days to re-build.
If you virtualize, then you’ll have extra options to snapshot, rollback, backup and re-deploy in seconds or minutes instead of minutes to hours.
And, <know> what you’re doing when you do your upgrade. Upgrading an AD (LDAP) is an intricate process of destroying and replacing objects. It’s well worth the money to use a commercial upgrade solution and/or hire an experienced person to do the upgrade for you. I haven’t done an AD upgrade for many years, but it’s one of the most complex things I’ve ever done and experience doing it <several> times was invaluable.

Good Luck,

Windows Server 2012R2 domain requires a minimum SMB level of 2.0, this means anything older than Samba 3.6 is not going to work unless you hack Windows servers to support an older version, which is not adviced.

In essence, anything < Leap 42.1 is not going to cut it and since 42.1 is unsupported, you should look at 42.2 or better, 42.3. Alternatively buy SLED12 (for desktops) or SLES12 (for servers)

Thanks TSU for your reply.
I think I missed adding this in my initial post, that the Active Directory Servers are all Windows 2008 R2, but the domain/forest functional is 2003. And, at this point in time we are only changing the domain/forest functional level to 2008 R2. So, we aren’t migrating the AD servers, just functional level. Does your reply still apply to the context?

Appreciate your help on this.

And to add, we use YaST for domain join. I am not familiar with the LINUX side, so just throwing what we have in our internal documents when these systems were first setup.

You still need to look at your NT compatibility settings for how it will affect your openSUSE, as I described it was commonly enabled in 2003 but has been discouraged with each successive version of AD. But, in general unless you have a reason to retain those old compatibility settings IMO you should take this opportunity of great disruption to update as far as you can throughout(Future Domain Admins will thank you for leaving the old behind. A little more pain now saves immense effort later).