A company with multiple interconnected geographic sites (via MPLS, VPN, or other) and a Microsoft Active Directory environment for user management.

To avoid consuming the inter-site link, the company has implemented RODCs (Read-Only Domain Controllers) on remote sites, allowing users at these remote sites to authenticate and access internal resources securely without engaging the central site's Active Directory infrastructure (RWDC).

The goal is to apply this functionality to filtering and authenticating users of remote sites by implementing Olfeo equipment on site interfaced with the RODC of that same site.

Authentication is performed directly by the Olfeo proxy and must be of the transparentKerberos AD type. NTLM is not recommended as it has been deprecated by Microsoft. This protocol also causes significant network load between the Olfeo proxy and the authentication server.

This document does not describe the context of an environment with multiple Active Directory domains without trust relationships, but this is not a constraint for the intended purpose.

• Raismes: 10.10.0.0/16 and 10.100.0.0/16
• Escaudain: 10.145.0.0/16

The primary Active Directory roles are installed on the central site (PDC, RWDC), while the remote site has an RODC. In the "Active Directory Sites and Services" console, each geographic site is linked to the corresponding subnet:

The Olfeo domain consists of one master machine installed at the central site in Raismes and one slave machine installed at the remote site in Escaudain.

It should be noted that, according to Olfeo's recommended best practices, it would be preferable to have a master and a slave at the central site in Raismes. The master's sole role would be to centralize settings and logs and to analyze statistics.

Olfeo master machine configuration:

• Host name:OLFEO6V500
• IP address:10.100.50.13
• LDAP, DNS, and NTP server:10.10.41.1

• Attached to RWDCPHS-SUN2k16.agglo.fr/10.10.41.1

Slave machine configuration:

• Host name:OLFEO6V50-ESC
• IP address:10.145.3.2
• DNS and NTP server:10.145.1.1 /WS-ESC01.agglo.fr (site RODC)

Connect to the Microsoft Active Directory domain from the slave machine's administration interface, specifying the RODC's IP address as the specific authentication server.

The connection must be made to an RWDC, and it is the address of the latter that first appears as the LDAP server in theStatus field. After a certain delay, Olfeo connects to the RODC of the remote siteWS-ESC01.agglo.fr:

After connecting the slave Olfeo to the MS Windows domain, you must configure delegation from the properties of the corresponding computer using the Active Directory Users and Computers console:

This operation must be performed from the PDC. After application, you must wait for the configuration to be replicated.

The Olfeo slave machine must be added to the "Replication group with RODC password enabled" user group:

This group must also include all users and client workstations located at remote sites and connected to RODCs.

Unable to join the slave machine to the MS Windows AD domain

Ensure that the ports are open between the slave olfeo and the RWDC located at the central site. Refer to the flow matrix:https://www.olfeo.com/fr/base-de-connaissances/matrice-de-flux

Perform a TCP SYN scan + a UDP scan from Olfeo:nmap -sS -sU ip_of_the_DC

Sometimes the join fails, and the administration interface returns an error message without any details. No log file tracks the various operations, which is why we recommend switching to the command line and manually running the MS Windows domain join scriptolfeo-join-ad-domain.pylocated in the/opt/olfeo/bindirectory:

olfeo-join-ad-domain.py [–timeout=TIMEOUT] [–retry=RETRY] DOMAIN NTP_SERVER

Example:

Once executed, you will need to enter the username and password for the directory account used to connect to the MS Windows AD domain.

This script performs the following operations, in this order:

1. NTP synchronization with the server specified in the parameter
2. Connection to the MS Windows AD domain
3. Obtaining a Kerberos ticket using the junction account to the MS Windows AD domain
4. Creating the keytab file/etc/squid/HTTP.keytab
5. Addition of HTTP SPNs (Service Principal Names)
6. Changing the privileges and owner ofthe HTTP.keytab file

The keytab (Key Table) file is used by Olfeo to provide the Kerberos authentication service. It contains several entries with keys and SPNs. You can read its contents using the following command:

klist –kt /etc/squid/HTTP.keytab

If an error occurs while executing this script, detailed error messages will be displayed directly in the terminal.

After connecting to the RWDC, the switch to the RODC does not occur.

The connection to the RODC can be verified using the following command executed from the Olfeo slave machine:

wbinfo –dsgetdcname=<DOMAIN-NAME>

This command is equivalent tonltest /dsgetdcon an MS Windows client.

This switch may take some time. To speed it up, you can clear Olfeo's cache:

1. In the Olfeo chroot, list the contents of the Samba authentication cache using the command:net cache list

Note down the various pieces of information.

2. Stop winbind using the command:service winbind stop
3. Flush the Samba cache using thenet cache flushcommand without manually deleting the TDB files.
4. Restart winbind using the commandservice winbind startand list the cache contents again to compare the information.
5. Check which DC the Olfeo is connected to.