Active Directory BDC/slave role

@fausp i think there is already a comparison between NethsServer and Zentyal, but this is not with the latest versions of both distro’s. 7.5 for Nethserver and 5.1 for Zentyal.
I think it would be great to have a renewed comparison between the 2.

Would you be able to (time/able to/ willing) to compare them (functionality, ease of use, etc)

1 Like

I am afraid I am not able to do it at the moment. I am in education, i want to start studying, next year…

No problem, maybe someone else can pick this up. I currently am quite busy too, but it still would be nice to have an up-to-date comparison between NethServer and Zentyal. (or more extensive and have other distro’s compared too like ClearOS and Univention.

:+1::+1::+1:

That would bè great…

Found this: Zentyal vs NethServer comparison matrix

Zentyal Server - Full technical features

Perhaps we should start a new Thread ?

1 Like

Thank you for the find! And having a look at the google doc, it confirms there is a need for a renewed comparison.
Downloading Zentyal 5.1 development edition, ClearOS7.5 community edition and Univention 4.3-2
This probably will take some time to create a complete comparison… When I am ready I will create a new topic for it.

1 Like

Client and services relying on Active Directory would still work, BUT what about (for instance) a groupware? or a web server with Nextcloud? Does it make sense to work on AD redundancy only?

Back to my question:

This depends on the options you have when setting up an ICT environment. IF there is the option to fully virtualize all servers, I would say: YES
In such a situation I would definately separate the DC role (and gateway role) from all other roles. I even would go with a 2nd DC if possible.
But when you are on a limited budget and you do not have the option to implement a nice Virtualization cluster of 3 or more nodes, and there is no other way than installing everything on a single server…

Another situation would be when there are multiple locations. As soon there is a (relatively) slow WAN connection involved, it would be nice to have a local DC for authentication purposes. And in an ideal world you want to be able to schedule the replication between the 2 sites so you don’t have too much replication traffic when a lot of people are using the bandwidth for work. Only mandatory replication traffic should be allowed, and other changes should be replicated outside “office hours”, or at least at a time chosen by the sysadmin. Also in such cases a dedicated DC (per location) would be the most ideal option.

Now I re-read you question. Is it meant as NethServer as a DC role and something else for other roles or would you choose another flavor as (B)DC, or is it meant as: would you implement a dedicated DC in your network? I took it as the last interpretation since we are NethServer and wouldn’t consider another flavor to have a role in our network… wink wink
To avoid confusion, I would rephrase as:

Would you choose to have a server for just running the (B)DC role?

2 Likes

Yes, that’s the point and I’m asking because I’m not a Windows sysadmin and need some feedback about it to decide how to prioritize the development effort of this feature. Thank you @robb.

1 Like

To be clear: IF there is the option to have a dedicated DC, then yes, but we HAVE to take into consideration that not all sysadmins have the luxury of multiple servers or VM’s to run their ICT environment on and probably most Home and SOHO users only have a single device to install on a server distribution (either NS, Windows, or another all-in-one option).
Yes, in that case there is no need for a 2nd DC either, but IMO we can’t limit the use of the DC role to a single server.

1 Like

A very bad scenario for a windows admin is when users cannot login in the morning because the DC is down and they have nothing to do except of calling in and asking when the problem is solved. This is the reason why admins like a second DC to just have logins working if the first DC fails.
So the little advantage to hotsync in this case is the automatic failover, possible because of the AD structure serving different logon servers.

You are right, it would make much more sense to have a full backup of all services, not only AD DC but it’s a single point of failure affecting all users and windows admins are used to it.

What about combining hotsync with read-only DC or make them work on the same server?

Could the read-only DC be a starting point to an AD migration scenario?

1 Like

Again, please do not talk of “read-only” DC: it’s confusing me :slight_smile: If we go with the Samba wiki sysvol replication method, based on rsync, we need to talk of “master” and “slaves”.

After reading a bit of the Samba-specific “RODC” deployment I understand it is not for us because it can’t do authentication (at the moment).

Apart from that, yes: any DC can be used as starting point to substitute another one. This is another story…

2 Likes

IMO the result of the effort should be to be able to have multiple DC’s in the network and be able to move FSMO roles from the first DC to any other DC. This is not only to have redundant DC functionality, but also a strong point when you have to migrate to other hardware without a HUGE backup/restore effort of your user and devices on your network.

scenario: you have an old server with DC role. You get a new server, also give it DC role by joining the same domain. Then transfer FSMO roles to the new DC. Install all services on the 2nd server that were done by the first server and finally demote the first server as DC. So you can safely remove an old server from the network.

6 Likes

Yes please… :+1:

I guess there is a good chance it happens. In this case, do the slaves take over?

That’s an interesting scenario. Is it doable with this feature @davidep?

Hopefully, yes :slight_smile:

1 Like

The other DCs take over and serve the logins if a DC goes down.

I could be wrong, but IIRC it’s up to the client to choose an alternative DC, by querying the DNS.

1 Like

That’s technically totally right, my version was very reduced.

1 Like