we are running an LDAP service based on Oracle Unified Directory (OUD), used as a backend for storing technical connection data (e.g., database connection strings).

The service is consumed in two distinct ways:

1. Application access (non-admin use case):

• LDAP is accessed programmatically by client systems (scripts/applications), not by human users

• These clients use ldapsearch (or equivalent) to retrieve technical data

• Access is typically based on:

  • source IP / DNS

  • and/or shared service accounts (in some cases)

• Operations are strictly read-only (search)

2. Administrative access (less than 10 users):

• Human administrators connect via CLI tools (ldapmodify, ldapadd, etc.)

• They perform write operations (add/modify/delete entries)

• Authentication is currently done via simple bind (DN + password)

Challenge:

Both application traffic and admin access go through the same LDAP endpoints (same host/port), so they cannot be separated at the network level.

We need to enforce a model where:

• Application access remains unchanged (automated read-only queries from known sources)

• Administrative operations are strictly restricted to authorized identities/groups

• Ideally, admin access could be further restricted to specific networks (e.g., VPN/admin subnet)

Questions:

1. What is the recommended way in OUD to:

   • Allow read/search access for application traffic (based on IP or service identity)?

   • Restrict write operations strictly to admin users or groups?

2. Can OUD access control (ACI/ACL) differentiate between:

   • read vs write operations

   • and apply different conditions (e.g., IP-based vs identity-based)?

3. What are best practices for handling mixed access patterns (automated application reads + human admin writes) in OUD?

4. Are there any pitfalls when relying on IP-based access for application traffic?