Todos os guias de estudo

PDAA-001

Certified Expert - PingDirectory

Parte de Certified Expert - PingDirectory

Each voucher code is valid for a single exam attempt only; once redeemed it cannot be reused. Exam covers PingDirectory version 9 or later.

Material de estudo independente, construído a partir do blueprint público da prova. Sem afiliação, autorização ou endosso da ping. Os objetivos são transcritos e mapeados à mão, então esta página pode conter erros ou estar defasada em relação ao material atual do fabricante: objetivos, versões, numeração e disponibilidade mudam sem aviso. Trate o portal de certificação da própria ping como a fonte da verdade e confira nele antes de agendar qualquer coisa.

Objective 1: Advanced Configuration

  • PDAA-001.1.01 Create and/or manage an ACI.

    O que saber:
    • An ACI (access control instruction) is stored on the entry it protects, in the aci operational attribute.
    • Syntax has three parts: target (what), permission and rights (allow or deny, which operations), and bind rule (who, under what conditions).
    • Deny always wins over allow when both match, so build with allows and use denies sparingly.
    • Test with an authenticated search as the affected user rather than reasoning about the rule in the abstract.
    • dsconfig manages server configuration; ACIs live in the data and are managed with LDAP modifications.
  • PDAA-001.1.02 Configure PingDirectoryProxy to balance entries between two instances of PingDirectory.

    O que saber:
    • PingDirectoryProxy sits in front of backend PingDirectory instances and distributes operations across them.
    • Entry balancing partitions the DIT across backend sets so no single set holds all entries.
    • A global index is what lets the proxy know which balancing point holds a given entry.
    • Entry balancing is for scale beyond a single server's capacity; plain load balancing is for availability and throughput.
    • Plan the balancing point carefully, because changing it later requires data movement.
  • PDAA-001.1.03 Configure PingDataSync to migrate data from another directory.

    O que saber:
    • PingDataSync synchronizes entries between a source and a destination, including foreign directories.
    • Sync pipes define source, destination, and the attribute mapping between their schemas.
    • Resync performs a bulk pass; ongoing sync follows the change log.
    • Attribute mappings handle schema differences; transformation is where most migration effort lands.
    • Run in dry-run mode first and inspect what would change before enabling the pipe.
  • PDAA-001.1.04 Update and manage certificates.

    O que saber:
    • Certificates live in the keystore and trust store configured on the connection handlers.
    • manage-certificates is the tool for inspecting, generating, importing, and exporting key material.
    • Replace certificates before expiry and confirm the full chain is present, not just the leaf.
    • Replication and inter-server connections use certificates too; a renewal that misses those breaks the topology quietly.
    • Track expiry dates as an operational task; expired certificates are the most common self-inflicted outage.
  • PDAA-001.1.05 Manage setting up, purging, and restoring soft deletes.

    O que saber:
    • Soft deletes mark an entry deleted while retaining it, so it can be restored.
    • The soft-deleted entry gets a new RDN and is hidden from ordinary searches unless explicitly requested.
    • Purging is time-based and configurable; the retention window is a policy decision with storage consequences.
    • Restoring an entry returns it to its original location; understand what happens if that DN is now occupied.
    • Applications must be aware of soft deletes, because a deleted entry still consumes its unique identifiers.
  • PDAA-001.1.06 Backup and restore data.

    O que saber:
    • backup and restore are the supported tools; file-level copies of an open database are not safe.
    • Backups can be full or incremental, and can be encrypted and signed.
    • Restoring into a replicated topology requires care: a restored server must be re-initialized or it will replay stale changes.
    • Verify backups by restoring them somewhere, not by confirming the job exited zero.
    • Retention and off-host storage of backups are part of the design, not an afterthought.
  • PDAA-001.1.07 Configure and manage replication.

    O que saber:
    • Replication is multi-master: any server accepts writes and propagates them to the others.
    • dsreplication enable, initialize, and status are the core commands.
    • Conflicts are resolved automatically by timestamp and server ID; understand which entry wins and why.
    • Replication uses its own port and credentials; firewalling must permit it or the topology silently diverges.
    • Monitor replication backlog as a first-class health metric.
  • PDAA-001.1.08 Configure a global index.

    O que saber:
    • A global index lets PingDirectoryProxy resolve which entry-balanced backend set holds a given entry.
    • It is populated from the backend data and must be kept current as entries move.
    • Index memory sizing is a capacity planning input for the proxy.
    • Without it, the proxy must broadcast searches to every set, which defeats the point of balancing.
    • Prime the index at startup so the first requests are not slow.
  • PDAA-001.1.09 Use the makeldif command to generate an LDIF file based on a template.

    O que saber:
    • makeldif generates synthetic LDIF from a template for testing and load generation.
    • Templates define branch entries, subordinate templates, and per-attribute value generators.
    • Generated data lets you test index behavior and sizing without production data.
    • Use it to reproduce scale problems safely, which is its main operational value.
    • Keep the template with the test plan so results are reproducible.
  • PDAA-001.1.10 Configure a mirrored subtree.

    O que saber:
    • A mirrored subtree is replicated in full to every server in the topology, typically for configuration or topology data.
    • It uses a master election rather than multi-master conflict resolution.
    • cn=topology holds server registry data as a mirrored subtree.
    • Understand which data belongs here: small, rarely changing, and required consistently by all servers.
    • Placing high-volume user data in a mirrored subtree is a design error.
  • PDAA-001.1.11 Add, initialize, and remove a server in a replication topology.

    O que saber:
    • Adding a server: install, then dsreplication enable against an existing server, then initialize it from a peer.
    • Initialization copies data; enabling only establishes the replication agreement.
    • Removing a server requires disabling replication so the topology forgets it, not just stopping the process.
    • A server removed without being disabled leaves stale entries in the topology registry.
    • Verify with dsreplication status before and after, and confirm the change on every server.

Objective 2: Basic Configuration

  • PDAA-001.2.01 Create, edit, and delete a schema definition.

    O que saber:
    • Schema is stored as entries under cn=schema and modified with LDAP operations or dsconfig-adjacent tooling.
    • Attribute types define syntax, matching rules, and single or multi-valued behavior; object classes define required and allowed attributes.
    • Custom definitions need a private OID arc and unique names to avoid collision with standard schema.
    • Deleting a definition still in use will fail or orphan data; check usage first.
    • Schema changes replicate, so validate on a test topology before applying in production.
  • PDAA-001.2.02 Create and use a sensitive attribute.

    O que saber:
    • Sensitive attributes restrict how an attribute can be accessed, updated, or returned, beyond what ACIs express.
    • Options include prohibiting return in search results, requiring secure communication, and forbidding modification.
    • This is a server-enforced control that applies regardless of the requester's ACI grants.
    • Typical uses: national identifiers, payment data, and anything with regulatory exposure.
    • Configure per client connection policy where different applications need different treatment.
  • PDAA-001.2.03 Create and use a virtual attribute.

    O que saber:
    • A virtual attribute is computed at request time rather than stored in the entry.
    • Built-in providers cover common cases (entryDN, isMemberOf, password policy state); custom ones handle the rest.
    • isMemberOf is the classic example: group membership presented from the member's perspective without duplicating data.
    • Virtual attributes cost CPU per request; they are not free convenience.
    • They can be indexed in some cases, but check before relying on a search filter that targets one.
  • PDAA-001.2.04 Create and use a JSON attribute.

    O que saber:
    • A JSON attribute stores structured JSON in a single attribute value with server-side awareness of its structure.
    • The server can index and filter on fields inside the JSON object using extensible matching.
    • This avoids inventing dozens of flat attributes for structured application data.
    • Understand how updates work: partial modification of a JSON value has specific semantics.
    • Schema still governs which entries may carry the attribute.
  • PDAA-001.2.05 Apply constraints to a JSON attribute.

    O que saber:
    • Constraints validate the contents of a JSON attribute so malformed or unexpected data is rejected at write time.
    • You can require fields, restrict types, and prohibit unrecognized fields.
    • Rejecting bad data at the directory is cheaper than discovering it in every consuming application.
    • Tightening constraints on existing data can fail; audit before enforcing.
    • Constraint violations surface as LDAP errors, so applications must handle them.
  • PDAA-001.2.06 Create, export, and import encryption settings definitions.

    O que saber:
    • Encryption settings definitions hold the keys used for data encryption at rest.
    • encryption-settings is the tool to create, list, export, and import definitions.
    • All servers in a topology that must read the same encrypted data need the same definition imported.
    • Export the definition and store it securely and separately; losing it means losing the data.
    • Rotating to a new preferred definition re-encrypts new writes; existing data is handled per the documented procedure.
  • PDAA-001.2.07 Use an encrypted LDIF file.

    O que saber:
    • An encrypted LDIF file protects exported data at rest, which matters because exports contain everything.
    • Export with encryption enabled and the appropriate encryption settings definition.
    • Import requires the same definition to be available on the target server.
    • This is the correct way to move data between environments without exposing it in transit or on disk.
    • Verify you can decrypt a test export before relying on the process for a real migration.
  • PDAA-001.2.08 Create a password validator.

    O que saber:
    • Password validators reject weak passwords at the moment they are set.
    • Types include length, character set, dictionary, attribute-value (no password containing the username), repeated characters, and similarity to the previous password.
    • Validators attach to a password policy; several can apply together.
    • Validation runs on the clear-text password during the modify, which is why it must happen at the server.
    • Test the combination, because overly strict stacked validators generate support calls rather than security.
  • PDAA-001.2.09 Create a password policy.

    O que saber:
    • A password policy governs expiration, lockout, history, storage scheme, and which validators apply.
    • Policies can be assigned by default, by subtree, or per entry via the password policy attribute.
    • Storage scheme choice matters: use a modern salted, computationally expensive scheme.
    • Lockout settings trade account security against denial-of-service by deliberate lockout.
    • Password policy state is inspectable per user, which is the starting point for most authentication troubleshooting.
  • PDAA-001.2.10 Create a log retention policy.

    O que saber:
    • A log retention policy decides when old log files are deleted, by count, size, or free disk space.
    • Retention pairs with rotation: rotation creates new files, retention removes old ones.
    • Disk exhaustion from logs is a classic outage; retention is the control that prevents it.
    • Compliance requirements may set a minimum retention that conflicts with disk capacity; resolve explicitly.
    • Different publishers can carry different retention policies.
  • PDAA-001.2.11 Create a log rotation policy.

    O que saber:
    • A log rotation policy decides when to start a new log file: by time, by size, or on a fixed schedule.
    • Rotation makes logs manageable and enables retention to act on whole files.
    • Time-based rotation aligns logs with operational windows, which helps investigation.
    • Size-based rotation protects against a single enormous file during an incident.
    • Policies attach per log publisher, so an access log and an error log can rotate differently.
  • PDAA-001.2.12 Create a basic access log publisher.

    O que saber:
    • The access log records every client operation with result codes and timing.
    • Create a publisher with dsconfig, choosing the log file, rotation, and retention policies.
    • Access logs are the primary evidence for both performance analysis and security investigation.
    • Consider the write cost at high operation rates; asynchronous logging exists for that reason.
    • summarize-access-log turns raw logs into an operational picture, which is why the format matters.
  • PDAA-001.2.13 Create a filtered log publisher.

    O que saber:
    • A filtered log publisher records only operations matching defined criteria.
    • Filtering by result criteria or request criteria keeps a targeted log without the volume of a full access log.
    • Typical uses: log only failures, only operations against a sensitive subtree, or only a specific application's connections.
    • This is how you get durable evidence for one concern without paying the full logging cost.
    • Confirm the criteria match what you intend by testing against known operations.
  • PDAA-001.2.14 Create result criteria.

    O que saber:
    • Result criteria select operations by their outcome: result code, whether entries were returned, processing time.
    • They are referenced by filtered log publishers and by other server components that act on operations.
    • Slow-operation criteria (processing time above a threshold) are the standard way to hunt performance problems.
    • Combine with request criteria for precision.
    • Criteria objects are reusable; define once and reference from multiple publishers.
  • PDAA-001.2.15 Create request criteria.

    O que saber:
    • Request criteria select operations by their inbound characteristics: operation type, target DN, authentication state, client address, controls used.
    • They drive filtered logging, client connection policy restrictions, and other conditional behavior.
    • Matching on unauthenticated operations is a common security use.
    • Criteria are evaluated per operation, so keep them cheap.
    • Name them descriptively, because they are referenced from several places and outlive the person who wrote them.
  • PDAA-001.2.16 Create a client connection policy.

    O que saber:
    • A client connection policy governs what a connection is allowed to do, based on how it connected and who it bound as.
    • Policies can restrict operation types, result set size, and which subtrees are visible.
    • Selection is by connection criteria evaluated at bind time.
    • This is the mechanism for giving an application a constrained view without relying solely on ACIs.
    • Order of policies matters; the first matching policy applies.
  • PDAA-001.2.17 Configure uncached entries and/or attributes.

    O que saber:
    • Uncached attributes and entries keep data out of the database cache to conserve memory for the working set.
    • Large, rarely-read attributes (photos, certificates, blobs) are the usual candidates.
    • The trade is memory saved against additional disk reads when that data is requested.
    • Configure at the backend level with the appropriate criteria.
    • Measure cache hit ratio before and after; this is a tuning decision that should be evidence-driven.
  • PDAA-001.2.18 Configure PingDirectoryProxy as a load balancer.

    O que saber:
    • As a load balancer, PingDirectoryProxy distributes operations across backend servers without partitioning data.
    • Algorithms include failover, round-robin, fewest-operations, and health-weighted variants.
    • Health checks determine backend availability and drive the algorithm's choices.
    • Read operations can be spread while writes go to a preferred server, which matters in a replicated topology.
    • This is the availability and throughput answer; entry balancing is the capacity answer.
  • PDAA-001.2.19 Configure PingDirectoryProxy to transform requested data.

    O que saber:
    • Proxy transformations rewrite requests and responses between client and backend.
    • Attribute mapping and DN mapping let a client see a different namespace than the backend actually stores.
    • Suppression transformations remove attributes from responses.
    • Transformations are how a proxy presents a legacy-compatible view over a modernized directory.
    • Every transformation costs processing per operation, so apply narrowly.

Objective 3: Troubleshooting

  • PDAA-001.3.01 Troubleshoot common issues.

    O que saber:
    • Start with the server status and the error log, then the access log for the specific operation.
    • Reproduce with ldapsearch or ldapmodify using the same credentials and controls as the failing client.
    • Isolate layer by layer: network reachability, TLS handshake, bind, then the operation itself.
    • Check replication status early when behavior differs between servers.
    • Collect a support data archive before restarting anything, because restarts destroy the evidence.
  • PDAA-001.3.02 Interpret log entries to resolve a problem.

    O que saber:
    • Access log entries carry the result code, the message, processing time, and the entries returned.
    • LDAP result codes are the vocabulary: 32 no such object, 49 invalid credentials, 50 insufficient access rights, 53 unwilling to perform.
    • Correlate request and response by connection and operation ID.
    • Unindexed search warnings in the log identify the queries that will not scale.
    • summarize-access-log aggregates this into counts and slowest operations, which is the fastest route to the problem.
  • PDAA-001.3.03 Use cn=monitor analysis to troubleshoot a problem.

    O que saber:
    • cn=monitor exposes server state as entries: connection counts, operation rates, cache statistics, replication status, and disk usage.
    • Query it with an ordinary LDAP search, which means monitoring systems can consume it directly.
    • Backend monitors show cache hit ratios; a falling ratio explains rising latency.
    • Replication monitors show backlog and last-change times per server.
    • Establish a baseline while healthy, because these numbers only mean something in comparison.
  • PDAA-001.3.04 Diagnose and resolve a configuration issue.

    O que saber:
    • Configuration problems usually surface as an operation that behaves differently than the documented default.
    • dsconfig can display the effective configuration; compare against a known-good server.
    • The configuration change log records what changed, by whom, and when, which usually answers the question immediately.
    • Configuration is replicated in a mirrored subtree for some components; know which parts are local and which are topology-wide.
    • Revert using the recorded change rather than guessing at the previous value.
  • PDAA-001.3.05 Diagnose and resolve a search issue.

    O que saber:
    • A search problem is almost always an index problem: check for the unindexed-search warning in the log.
    • Index types matter: equality, presence, substring, ordering, and approximate each serve different filters.
    • Leading-wildcard substring filters cannot use an ordinary index, which is a design problem not a tuning one.
    • rebuild-index repairs or creates indexes; it is an offline or degraded-performance operation, so plan it.
    • The index entry limit determines when the server stops maintaining an index for a very common value.
  • PDAA-001.3.06 Diagnose and resolve a schema issue.

    O que saber:
    • A schema problem appears as object class violation or undefined attribute type errors on write.
    • Confirm the definition exists and is spelled exactly as used, including case-insensitive but exact naming.
    • Check that required attributes of every object class on the entry are present.
    • Schema replicates; a mismatch between servers produces failures that follow the client, not the data.
    • Validate LDIF against the schema before a bulk import rather than discovering violations mid-load.
  • PDAA-001.3.07 Diagnose and resolve an ACI issue.

    O que saber:
    • An ACI problem presents as result code 50, insufficient access rights, or as data that is unexpectedly invisible.
    • Remember that absent an explicit allow, access is denied; and any matching deny overrides all allows.
    • Verify which ACIs apply to the target entry, including those inherited from ancestors.
    • Bind rules that reference groups require the membership to be resolvable at evaluation time.
    • Test as the affected identity; testing as an administrator proves nothing about the user's access.
  • PDAA-001.3.08 Diagnose and resolve a replication issue.

    O que saber:
    • Replication problems show as divergence between servers or as a growing backlog.
    • dsreplication status is the first command; it reports missing changes per server.
    • Common causes: network partition, certificate expiry on replication connections, and a server restored from backup without re-initialization.
    • Re-initializing from a healthy peer is the standard repair for a diverged server.
    • Confirm the topology registry reflects reality, because a stale entry for a decommissioned server produces persistent errors.

Fontes públicas, usadas de boa-fé

Estes guias são materiais de estudo independentes, montados a partir de conteúdo publicamente disponível: blueprints de exame publicados, documentação oficial de produto e catálogos de treinamento dos fabricantes. Nomes de produtos, códigos de exame e marcas pertencem a seus titulares e são usados apenas para identificar o assunto ensinado. Este site não é afiliado a nenhum fabricante aqui citado nem endossado por ele. Se você detém direitos sobre material publicado nesta página e entende que ele deve ser removido ou corrigido, envie a URL exata e uma breve nota sobre o problema pela página de contato; os pedidos são analisados com rapidez e boa-fé. Ler o aviso legal completo