Hi иностранец,

A post on how I shifted from Windows 2012R2 systems to Uninvention UCS Core Edition

After years of decent service (including up and downs, I’ve got to be honest), it’s been time to swap my older Windows 2012 R2 AD Domain Controllers.

In fact, I don’t need much out of these – I want LDAPs and Users/Groups to be polled by a 3rd party authentication system, thus mapping remote LDAPs users within local groups/policies and adding a 2FA layer. All the auths are going up to the AD DC’s per LDAPs. That 3rd party auth system is interfaced either through RADIUS or SAML in my setup and is my main authentication system, AD being the users repository. I’m also using AD/LDAPs for further services authentications, like proxy service access and so on. And obviously, I enjoy local to any “sites” DC presence.

To cut a long story short, I did replace my aging Windows DC’s with UCS Nodes. Once the UCS stack had been setup, I did install/add the following available software package; Active Directory-compatible Domain Controller . Overall, the UCS setup and initial configuration has been really flawless aside from a few little details needed here. Items which I’ll list below.

Enabling mschap_v2 on UCS:#

MSCHAP_V2 based authentication weren’t successful on UCS using the default settings, here is what I needed to do on each UCS Node:

root@dc:~# ucr set samba/ntlm/auth=mschapv2-and-ntlmv2-only
Setting samba/ntlm/auth
Multifile: /etc/samba/smb.conf
root@dc:~# 
root@dc:~# ucr get samba/ntlm/auth
mschapv2-and-ntlmv2-only
root@dc:~#

Using External (to the DC’s) DNS systems:#

I did choose to setup UCS Nodes within their own DNS subdomain, which wasn’t the case with Windows systems. You’d find more information’s about this type of setups here. All in all, I think I made a good choice: all the AD domain needed DNS records etc are off my main BIND systems and a simple delegation concerning the UCS subdomain had to be enabled on BIND. Easy really.

AD Takeover:#

I did try to run the Uninvention AD Takeover although the wizard complained about my Windows AD Domain being above Windows 2008R2. As I didn’t had a huge AD database, I chose to rebuild the needed objects semi automatically. Nevertheless, it is possible to lower the current functional level of your Windows systems using these powershell directives (caution: subject to testings and complete understanding of what this does, I clearly didn’t test that):

Set-ADForestMode -Identity "mydom.local" -ForestMode Windows2008R2Forest
Set-ADDomainMode -Identity "mydom.local" -DomainMode Windows2008R2Domain 

After which, a UCS AD Takeover should run without issue.

Certificate management:#

One thing which I thought wasn’t particularly clean nor simple to handle on UCS Nodes is it’s certificate management – I couldn’t find an easy way to add custom certificate/key bundles universally on the platform. There is a KB about this here and another user unanswered question here . I’ll update this post once I could reach local satisfaction.

Final thoughts:#

Finally, I’m very happy about that move, I can now manage these systems from a Web Based console very easily, the CLI and registry operations are easy to understand and I feel my setup as robust. The integration with my 3rd party authentication system has been as easy as formerly with some minor changes needed here and there, fact that made me conduct some needed structural cleanings. The synchronization between the UCS Primary Directory Node and any further UCS Backup Directory Node has been working instantly and effortlessly.

And well yes, that move removed yet another set of closed source systems from within my own labs; move which I foresee as a good security practice going forward.

Some interesting URL’s onto UCS:
A collection of security related best practices
UCS Bugzilla
UCS Documentation
UCS Forums

Hope this helps.
obruno

April 2026 Update:#

Using UCS for regular LDAPs bind was working fine in my setup although I couldn’t use the sAMAccountName user attribute and typically, only the userPrincipalName user attribute (user@domain.suffix ) would allow users to login successfully. After searching for a long time, here is what I did find:

UCS exposes this as a proper UCR variable — do not edit smb.conf directly as it gets overwritten by UCS:

# Check current value
ucr search strong
# samba/ldap/server/require/strong/auth: <empty> (default: yes)

# Set on every UCS node (primary + backup — UCR is per-node, does not replicate)
ucr set samba/ldap/server/require/strong/auth='allow_sasl_without_tls_channel_bindings'
systemctl restart samba-ad-dc
  • Allows simple bind over encrypted TLS connections ✓
  • Plaintext bind still refused ✓
  • UCR managed — survives UCS updates ✓
  • Must be applied on each UCS node individually (primary + all replicas/backup nodes)

Error reference#

Error Code Meaning
52e Invalid credentials — also returned when simple bind is blocked
8 Strong authentication required — plaintext bind refused