KB 2796: MANAGEMENT OF OLFEO PROXY AUTHENTICATION VIA RODC

Published November 28, 2023Modified on December 8, 2023

BACKGROUND

A company with several interconnected geographical 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 set up RODCs (Read-Only Domain Controllers) at remote sites, enabling users at these remote sites to authenticate and access internal resources in complete security, without having to use the central site's Active Directory infrastructure (RWDC).

The aim is to apply this operation to the filtering and authentication of users on remote sites, by implementing an Olfeo device on site interfaced with the RODC on the same site.

Authentication is performed directly by the Olfeo proxy, and must be of the transparent Kerberos AD type. NTLM is not recommended, as it has been deprecated by Microsoft. This protocol also induces a 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 with or without approval relationships, but this is not a constraint for the intended purpose.

ENVIRONMENT

Microsoft Windows AD

Let's take the example of the AGGLO company, whose central site is based in Raismes and one of its remote sites in Escaudain. Each geographical site is represented by a subnetwork:

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

The main 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 geographical site is attached to the corresponding subnet :

Olfeo

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

It should be noted that Olfeo's recommended best practice is to have a master and a slave on the Raismes central site. The master's role would be to centralize parameters and logs, and to process statistics.

Configuring the Olfeo master machine :

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

  • Attached to RWDC PHS-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)

 

PROCEDURE

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

Connection to MS Windows AD domain

The connection must be made to a RWDC, and the latter's address first appears as the LDAP server in the Status field. After a certain delay, Olfeo connects to the RODC of the remote site WS-ESC01.agglo.fr :

Kerberos delegation

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

This operation is performed from the PDC, after which you must wait for the configuration to replicate.

Password replication on the RODC

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

This group must also include all users and client workstations on remote sites and attached to RODCs.

Troubleshooting

Unable to join slave machine to MS Windows AD domain

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

Run a TCP SYN scan + a UDP scan from Olfeo: nmap -sS -sU ip_du_DC

If the junction fails, the administration interface returns an error message with no details. There are no log files to trace the various operations, so we recommend that you go to the command line and manually execute the MS Windows domain join script olfeo-join-ad-domain.py, located in the /opt/olfeo/bin directory:

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

Example:

Once run, you'll need to enter the login 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 parameter server
  2. Connection to MS Windows AD domain
  3. Obtaining a Kerberos ticket using the MS Windows AD domain junction account
  4. Create the keytab file /etc/squid/HTTP.keytab
  5. Adding HTTP SPNs (Service Principal Names)
  6. Changing the privileges and owner of the HTTP.keytab file

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

klist -kt /etc/squid/HTTP.keytab

In the event of an error when executing this script, detailed errors will be displayed directly in the terminal.

After connection to the RWDC, the switchover to the RODC does not take place.

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 to nltest /dsgetdc on an MS Windows client.

This switchover may take some time, and to speed it up you can purge the Olfeo cache:

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

Read the information.

  1. Stop winbind with the command: service winbind stop
  2. Purge Samba's cache using the net cache flush command, without deleting TDB files manually.
  3. Restart winbind with the service winbind start command and list the cache contents again to compare the information.
  4. Check which DC the Olfeo is attached to.