One of the features available in Credential Management for Active Directory Password Management is Kerberos Authentication
Kerberos authentication is very strict in that it requires name resolution as well as a Service Principal Name (SPN) that contains the exact reference of the domain where password is being managed.
One of the usual ways in which Active Directory applications are being configured is to define a device with a given FQDN, then configure in the Target Application the device as a Domain Controller (option "Do not use DNS: target server is a Domain Controller") in the Active Directory tab for the Target Application
Generally speaking, if the Target Application is pointing to a specific Domain Controller (DC) and the device is configured with FQDN as well this will work. For instance, assuming in domain example.com, there is a machine, dc1.example.com, which is a Domain controller, defining a device by the name dc1.example.com, configuring as its IP address dc1.example.com (remember Kerberos requires name resolution) and creating a Target Active Directory application with Kerberos Authentication using the option to "Do not use DNS: target server is a Domain Controller" will work fine.
However, there are cases when the Domain specified does not resolve to a unique DC, but a list of them presented, for instance, in round robin. In these cases, some care must be taken to properly define the Target Application as otherwise Kerberos Password rotation will not work.
This article describes how to set up Kerberos Rotation in such a use case
Let's assume that there is a domain, example.com, which resolves back to two domain controllers of IPs 198.51.100.10 and 198.51.100.20, for instance. So that nslookup to a DNS in the domain alternatively returns one or the other
The following setup will work