Greetings,
I hope you are well. As I can gather, the only difference between a UCS DC Backup and DC Slave is not all certificates are copied. However is there a way to have a DC Slave synchronise with the DC Master? For example, I wish to deploy DC Slaves to our international branches so workstations can join the domain via the slave and have it synchronise with the master back at HQ. Is this possible?
Regards,
David.
Hey,
that’s exactly what DC Slaves are there for, and it works out of the box. All relevant data for Windows domain operations are already synced to the DC Slaves.
The DC Backup is only needed in case the DC Master suffers a catastrophic outage so that you can convert the DC Backup to be the new DC Master. There are several pieces of information that aren’t required on a DC Slave (e.g. the certificates for other DC Slaves) but that are required on the DC Master (and therefore DC Backup).
Kind regards
mosu
Hi Mosu,
Thanks for the reply. What has got me confused is that in the documentation, it states that “All the domain data are saved as read-only copies on servers with the slave domain controller role”. Is this not the case or am I just reading it incorrectly? Because being read-only means that it won’t synchronise back to the master?
Regards,
David.
Hey,
the situation is somewhat tricky. A UCS domain is made up of OpenLDAP servers with unidirectional synchronisation between them with the DC Master as the sync source and all other UCS DC Backups and UCS DC Slaves as sync destinations. The SSL certificates for all machines are created on the master and copied to the DC Backups & DC Slaves. All changes to information in the LDAP, e.g. accounts, groups etc., is done on the DC Master and synced from there to the other UCS DCs.
In that sense UCS DC Slaves are read-only copies.
However, this is solely the part that isn’t the Active Directory part. That part is provided by Samba with its own LDAP server. You usually install the “AD compatible domain controller” app (which contains Samba) on all relevant DCs. And now things get complicated.
Each Samba AD DC (don’t confuse “AD DC” with “UCS DC” — both are different concepts, e.g. for “UCS DCs” there are three types: Master, Backup, Slave; however, for “AD DCs” thereis basically only one role if you disregard the AD Read-Only-DC) implements a bi-directional sync to all other Samba AD DCs. Therefore changes to the AD portion of the data (e.g. if a user changes her password on her domain-joined Windows workstation) are done on the “nearest” AD DC. The AD DC then synchronizes those changes with the other AD DCs in the domain.
In that sense a UCS DC Slave with the AD DC app installed is not read-only anymore.
But how is the data synced between those two worlds? Well, there’s the “Univention S4 Connector” component which is installed on the DC Master and all DC Backups (but it’s always only running on the DC Master). This component does a bi-directional sync between the OpenLDAP server on the UCS DC Master and the Samba DC DC on the UCS DC Master.
So what happens when you have a branch office with its own UCS DC Slave with the Samba AD DC installed and a user in that branch office changes her password on Windows?
If you change the password not via Windows, but via the web-based “Univention Management Console” (UMC), the flow looks different:
Kind regards,
mosu
There are only copied to the DC Backups.
I was a bit imprecise. All SSL certificates are copied to the DC Backup. Each other server type (DC Slave, Member server) only receives the one SSL certificate dedicated to that server.
Thank you all for your replies, especially Mosu with your in-depth explanation of UCS DC Slave role. I believe I understand how it works now. Thank you for your time and patience Mosu, it is very very much appreciated! Cheers!
You’re quite welcome. Cheers!