Redundant DCs: Is it OK, to install the "Active Directory compatible Domain Controller" on a UCS Backup Node, that is supposed to be read-only?

[systemofapwne]

Hello,
I would like to add redundancy to my AD at home by adding secondary fail-over Domain Controllers.

Right now, my setup looks like this.

• DC: Primary Node with “Active Directory compatible Domain Controller”
• DCB: Backup Node with nothing on it yet.

To my knowledge, the Primary Node “DC” is the only instance, that should modify the domain database (See here)
Also, Backup Nodes (and Replica Nodes) are considered read-only, according to the link above.

Now to the question: Is it considered safe, when I also add the “Active Directory compatible Domain Controller” app to my Backup Node DCB, so I can use ad/ldap & kerberos against it?

First test indicate, that adding the “Active Directory compatible Domain Controller” app works and samba and kerberos too.
But to my surprise, I was able to change AD entries on by Backup Node DCB, which replicates to the Primary Node DC.
Even further: When the Primary Node is powered off, I can still change AD entries on my Backup Node DCB (isn’t that node supposed to be read-only?) and when powering the Primary Node back up, the changes were now also reflected on the Primary Node. And this even happens, when I power down the Backup Node DCB after I made changes, then boot up the Primary Node first and then again the Backup Node. So the Backup Node clearly is not ready-only here.

For me, the behavior is exactly how I would like my domain to work.
But I have the suspicion that:

• Either this is considered bad practice: Shouldn`t Backup Nodes should stay read-only? Should one rather use a Replication Node for the “Active Directory compatible Domain Controller” app instead?
• Or am I getting this “Backup Node” role wrong and the sync of data in the AD is an expected feature of the “Active Directory compatible Domain Controller” app and does not mess with the “Backup Node” role?

Can anyone elaborate a bit?

[talleyrand]

Already asked this question a few weeks ago and did not get a reply…

after reading this:
https://docs.software-univention.de/ext-windows/5.0/en/index.html

I wrote this:

UCS and Read only donain controllers RODC

I’m looking at RODC. now according to the manual you do this: ucr set samba4/role=RODC univention-install univention-samba4 univention-run-join-scripts what is the difference between running : ucr set samba4/role=RODC to set the mode of READ ONLY then running “Active Directory-compatible Domain Controller” from the web front end? Secondly if we run the command line options, nothing is shown as being installed in the web front end (really there should be some icon or something) final…

also i have noticed that the system check tools seem to be failing on a RO system even without adding in the DC software.

on your R/O domain controller did you set the R/O flags as per the Univention Admin manual BEFORE setting it up?

I did , but I ALSO found the same problem you saw on a test system, that installing the
“Active Directory compatible Domain Controller”

ALSO started to make writes to the supposedly only R/O setup, so i did nto implement it in production.

[systemofapwne]

Wait, there is a R/O flag somewhere? As per the installation instructions, this is mentioned nowhere. The whole installation of the node also sounds like, selecting “backup directory node” will already mark everything R/O:

This is why I am so confused right now.

To your question: No, I did not set the R/O flag on the backup node before installing the “Active Directory compatible Domain Controller”.

However:
For me, having a secondary DC, that can even be written to and in the worst case, become a primary DC, this is fine. If this is supported by UCS machines configured as a “Backup Node” without the R/O flag set, I am fine.
I don’t even need a real disaster-recovery “Backup” node (in only R/O mode) but rather a fail-over (load-balanced) DC (if my main DC shuts down) and the backup-node role looked most promising to me. (I handle disaster-recovery via ZFS snapshots + replication already for both. If s*** hits the fan, I restore a snapshot of either DCs).

Some other thoughts: At my workplace, our DCs are using bare Samba (no UCS) and they behave similar to my home-setup: “Multiple” DCs, that accept changes and replicated them to the other DCs, if they went offline. So I think, not working R/O on a Backup Node might be ok.
Anyhow, I would like to know, if this is considered bad or “ok” practice for my usecase.

[talleyrand]

yep… its in the super “secret” totally open documentation.
it clearly states it is V5 of the documentation.
its called “ext-windows.pdf”

ext-windows.pdf

but according to this there seems to be a special procedure for R/O domains
(how hard would it be to roll this into the GUI as a check box)!!!

Also if you try to run the inbuilt diagnostic tools, them seem to be broken on R/O DC’s

Having a R/O become primary is very dangerous, not just for the certs…
but also security &
if the R/O is at a branch office, then suddenly all the authentication traffic attempts a redirect…

R/O should be just that RO, it should not allow the univention to install software that’s going to do conversions behind the backs of systems admins…

The issue is not “good” or “bad” practice, the issue is potentially malfunctioning software., then it is always “bad practice”, also there are statements relating to default behavior and being able to change flags to replicate PW & certs…

Also … I think you CANNOT do a rollback snapshot restore of individual DC’s if one goes bad… they are a set…
they have inter dependent Change numbers…
Technically you might be able to shutdown ALL vm, do a cold backup, then restore as a set, but i think if one DC gets trashed and you think you can simply roll out a backup, then you may be in for a surprise…

since the others will have different change numbers, and a strict hierarchy…

[ahrnke]

A few remarks trying to solve the confusions.

First: It is correct that Backup and Replica Directory nodes are Read-Only with regards to changes in the OpenLDAP-based Directory of UCS. While it is possible to apply changes on a Backup with UMC we have to be aware that this changes are directly written to the Primary by using the functions of the Univention Directory Manager.
The “Active Directory compatible Domain Controller” adds another Directory to an UCS domain which is based on Samba. This directory is synchronized to OpenLDAP with a component called “Univention S4 Connector”. This connectory usually runs on a Primary Node.
Domain Controllers in Active Directory are multi-master capable which means that every DC can be used to apply changes. Those changes are synced between DCs by using the “Directory Replication Service/DRS” which is also implemented in Samba. There are some Help articles like Samba 4 Troubleshooting Guide which might give some insights.

This should explain the behaviour that was mentioned in the inital post.

Further on: It is not just OK to install Samba/AD on a Backup or even a Replicy DN. It is a recommend setup to achieve redundancy. And it is a requirement to be able to convert a Backup to Primary in case of emergency.

Running a RODC is a specific requirement and mostly used if one needs AD functionality in scenarios where no changes are wanted or allowed (like hosts in a DMZ).

hth,
Dirk

[systemofapwne]

Thank you very much, this clarifies a lot.

[talleyrand]

can"Active Directory compatible Domain Controller" be added onto a “RODC” ?

Specifically because we operate over links that cannot always be guaranteed to stay connected.

sometimes they may be off for days , but the locations still need to maintain inhouse login & NAS shares.