LDAP StartTLS Certificate Rotation and Multi-Admin Verification Blocking Automation
A six-SVM ONTAP 9.13.1 cluster serves NFSv4.1 with Kerberos (krb5p) and SMB. UNIX identities come from AD-integrated LDAP (RFC 2307); the SVM's LDAP client configuration uses StartTLS and a locally installed server-ca certificate. The identity team enforces LDAP signing, moves the domain controllers to TLS 1.2 only, and rotates the LDAP server certificate. Afterwards, NFSv4.1 users resolved through LDAP get permission denied on volumes they previously accessed, while local ONTAP users and Active Directory users over SMB are unaffected. On the SVM, an LDAP check reports a connection failure and name lookups for LDAP users return nothing. In the same week, the security team enables multi-admin verification. The nightly automation account svc_automation, which uses the admin role and deletes expired Snapshot copies, now fails with access denied on volume snapshot delete.
1. Diagnose and fix the LDAP failure. Which commands do you run, and what role does the server-ca certificate play?
Read the worked answer
Start with the client configuration and the built-in check: vserver services name-service ldap client show -vserver svm_x -instance for server list, port and StartTLS setting, then vserver services name-service ldap check -vserver svm_x -client-config <name>. A failure that begins exactly at certificate rotation points at trust: ONTAP validates the domain controller certificate against installed server-ca certificates, so a new issuing CA or intermediate must be installed with security certificate install -vserver svm_x -type server-ca, pasting the full chain. Confirm with security certificate show -vserver svm_x -type server-ca, then re-run the LDAP check and a name lookup with vserver services name-service getxxbyyy getpwbyname. Check NTP as well, since both Kerberos and certificate validation depend on time. Local users and SMB AD logons do not use the LDAP client configuration, which is why they still succeed.
2. Why does svc_automation now fail on snapshot delete, and what are the realistic ways to resolve it? Include the risk of each.
Read the worked answer
Multi-admin verification does not silently deny; it turns the operation into a pending request. Confirm the rule covers the operation with security multi-admin-verify rule show, and look at the queue with security multi-admin-verify request show. An authorized second administrator approves using security multi-admin-verify request approve -index <id>, after which the requester re-executes or the operation completes. Two practical options: (a) keep snapshot delete protected and build approval into the automation runbook, which preserves two-person control but makes the job dependent on a human and can miss its window; (b) change the control's scope so the service identity is out of scope, or remove snapshot delete from the protected operation list, which restores unattended runs but removes the safeguard on a destructive action. If the ONTAP release supports scoping rules by user or role, a dedicated snapshot-only role is the cleaner middle path. Decide with the security owner rather than bypassing silently.
3. Kerberos NFSv4.1 mounts from one SVM fail intermittently after the LDAP fix. What is your troubleshooting order and why?
Read the worked answer
Work from the outside in. First confirm whether the failure is name resolution or authentication: if getxxbyyy resolves the user but the mount is denied with krb5p, the LDAP path is probably fine and Kerberos is the suspect. Check time sync on the node hosting the data LIF (cluster date show, node-level date), because Kerberos rejects tickets with more than a small clock skew; intermittent failures that follow a LIF's current node point at a drifting node. Then verify the service principal and keytab state for the SVM and that DNS forward and reverse records for the SVM and LIFs are correct, since SPNs are built from names. Only then inspect client-side ticket caches and the export policy rules for the Kerberos security flavor, because an export policy missing krb5p access produces permission denied after successful authentication.