> For the complete documentation index, see [llms.txt](https://docs.amitysolutions.com/ekoai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.amitysolutions.com/ekoai/getting-started/eko/eko-ad-sync/frequently-asked-questions.md).

# Frequently Asked Questions

This article highlights the most common questions our customers ask.

<details>

<summary>Why do we need to set up more than one EkoADC server?</summary>

Key reasons for setting up multiple EkoADC servers include:

* **High Availability for Authentication**: Multiple servers ensure that users can still log in even if one server fails, maintaining business continuity.
* **Load Balancing**: Redundancy allows for the distribution of requests among multiple servers.
* **Complex Use Cases**: Some customers require multiple servers to handle different user types or organizational units.

</details>

<details>

<summary>What are Active/Active or Active/Standby operational states used for?</summary>

The state of the multiple EkoADC servers is differentiated by whether the server is handling User Authentication or User Synchronization.

**State for User Authentication: Active/Active.**

For user authentication, the redundant EkoADC servers often operate in an Active/Active state.

* **Mechanism**: When multiple EkoADC servers are deployed, they can be used for routing user authentication. This routing often employs DNS round-robin.
* **DNS Round-Robin**: This method alternates the order of address records each time a name server is queried, distributing login requests among active servers (e.g., ADC01, ADC02) to balance the load.
* **Use Case**: This approach is deployed explicitly for customers who require AD authentication with a redundant server.

**State for User Synchronization: Active/Standby.**

For user synchronization (provisioning user data to the Eko Cloud), the servers may operate in an Active/Standby configuration.

* Mechanism: In this state, only one server is actively executing the full synchronization job, while the other server(s) are designated as standbys or backups.
* **Example (Use Case 2)**: In an architecture supporting provisioning user profiles and credentials, the system may be set up where ADC01 handles User Sync (Active 01) and ADC02 is the Standby 02 for synchronization.
* **Complex Scenarios**: Some setups involve complex redundancy configurations where one ADC might handle both user profiles and credentials, while the second ADC only handles user profiles.

</details>

<details>

<summary>Can our team (customer) access the EkoADC Web Console?</summary>

Yes, customers can access the EkoADC web console, although this access is typically related to maintenance, troubleshooting, and manual synchronization tasks, rather than core functionality.

</details>

<details>

<summary>Can we have our own account to access the EkoADC Web Console?</summary>

Yes. The EkoADC application is configured by default to support multiple, **predefined** accounts for accessing the web console. This access has to be communicated to the Eko team, as it is defined during the EkoADC initial setup.

The EkoADC predefines three distinct, role-based accounts:

* Main User Account
* Auditor Account
* Operator Account<br>

</details>

<details>

<summary>Can we change the synchronization method from LDAP to FTP?</summary>

Yes, it is possible.

However, while the customer can change the synchronization source to a file (FTP/SFTP), it is crucial to note that file synchronization should generally be used for user profile synchronization only.

* If the primary synchronization source is a file (e.g., from an HR DB), the file must contain a user account (user ID) that can be used for mapping and LDAP binding.
* Directory software that supports LDAP is still required for user authentication, even if user profiles are provisioned from a file.

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.amitysolutions.com/ekoai/getting-started/eko/eko-ad-sync/frequently-asked-questions.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.