Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Windows Domain Servers

Integrate Active Directory to manage access to Windows domain servers

Active Directory (AD) is Microsoft's directory service for Windows domains, holding the users, groups, and computer accounts that Windows servers authenticate against. Windows grants Remote Desktop access to members of a server's built-in local groups. These local groups can include Active Directory groups.

Through this integration, Apono helps you discover your Windows servers and securely manage access through your Active Directory domain. Apono connects only to a domain controller, never to the servers themselves, so a server that is switched off or unreachable can still be granted.

Prerequisites

Item
Description

Apono Connector

On-prem connection serving as a bridge between an Active Directory domain and Apono:

Windows Server

Windows domain server running Windows Server 2012 or later

Network Access

Access from the connector to one domain controller on the LDAP port:

  • 636 (LDAPS)

  • 389 (LDAP)

NOTE: No other port is required. The connector does not communicate directly with the Windows servers.

Domain Controller Address

Hostname or address of one domain controller that the Apono Connector can reach

You will use this value to configure the LDAP Server URL.

Active Directory Account Access

Active Directory account with permission to create or configure the account used by the Apono Connector and assign it permission to manage groups in one container

NOTE: Domain Admin privileges are not required.

CA Certificate

(Conditional) Certificate of the authority that issued your domain controller's LDAPS certificate, base64-encoded in PEM format

NOTE: This is required whenever that certificate was not issued by a public certificate authority, which is usual for internal domain controllers.

Obtain Active Directory distinguished names

Active Directory uses distinguished names (DNs) to uniquely identify objects and containers within a domain. For this integration, you need the DNs for the organizational unit containing the Windows servers and the container where Apono can create and manage groups.

Distinguished name
Usage
Example

Servers OU

Identifies the organizational unit containing the Windows servers Apono should discover

Use this DN when creating the Apono Group Policy Object and as the Computers Scope when configuring the integration.

OU=Servers,OU=CORP,DC=corp,DC=example,DC=com

Groups container

Identifies the container where Apono can create and manage groups

In a self-managed Active Directory domain, use this DN when delegating permissions to the Apono account. Also use it as the Groups Scope when configuring the integration.

OU=AponoGroups,OU=CORP,DC=corp,DC=example,DC=com

Follow these steps:

  1. Open Active Directory Users and Computers.

  2. Click View > Advanced Features.

  3. Open the organizational unit containing the Windows servers.

  4. On the Attribute Editor tab, locate distinguishedName and copy its value.

  5. Open the container where Apono will create and manage groups.

  6. On the Attribute Editor tab, locate distinguishedName and copy its value.

Create an Active Directory user

You must create a user in your Active Directory domain for the Apono Connector and grant that user permission to manage groups in one container. Apono requires permission to read computer objects in the Servers OU and to create, read, and manage group membership in the Groups container.

Follow these steps:

  1. Create and configure a dedicated Active Directory user for the Apono Connector. Follow the instructions for your Active Directory deployment.

  1. Obtain the directory ID.

This command also returns the domain name and domain controller addresses used later when configuring the integration.

  1. Create the service account. Replace <DIRECTORY-ID> with the directory ID obtained in step 1. The account is created in OU=Users,OU=<NETBOIS> and is initially disabled.

  1. Set the password. Replace <DIRECTORY-ID> with the directory ID obtained in step 1 and <PASSWORD> with a password. Setting the password enables the account.

  1. Grant the account permission to manage groups. Replace <DIRECTORY-ID> with the directory ID obtained in step 1.

  1. Create a dedicated Active Directory account using your organization's standard process.

  2. Delegate group management permissions on the Groups container identified earlier. Replace <GROUPS-CONTAINER-DN> with the Groups container DN identified earlier, <DOMAIN> with your domain, and <ACTIVE-DIRECTORY-USER> with the account you created.

  1. Create a secret using the username and password of the Active Directory user. This enables the Apono Connector to use the secret to authenticate to Active Directory from within your environment. Apono does not store these credentials. Use the following key-value pair structure when generating the secret. Replace <USERNAME> and <PASSWORD> with the account credentials.

lightbulb

You can also input the user credentials directly into the Apono UI during the integration process.

Create the Apono Group Policy Object (GPO)

Windows uses built-in local groups to control access to servers. To support Apono-managed access, use the Apono-provided script to create a GPO that associates Apono-managed Active Directory groups with the appropriate local groups.

This is a one-time configuration performed by an account that can create and link GPO. It applies to every server in the Organizational Unit (OU), including servers added later, without requiring configuration on each server.

lightbulb

If you need to manually configure the GPO, expand the Configure the Group Policy Object manually callout below and follow the steps.

Follow these steps:

  1. Sign in to a domain-joined machine using an account with permission to create and link GPOs.

  2. If needed, install the Group Policy Management tools.

  1. Run the Apono-provided script and specify the Servers OU.

The script creates and links a GPO named Apono RDP Access to the Servers OU. You can safely run the script again. If the configuration is already correct, the script makes no changes.

💡 Configure the Group Policy Object manually

You can also create the GPO manually in Group Policy Management. Create the GPO and link it to the Servers OU, then configure the required Local Users and Groups settings.

The manual configuration must match the values below exactly. If a Local Group item is configured incorrectly, Apono may grant access successfully but Windows will still refuse the sign-in.

Follow these steps for each item in the table below:

  1. In Group Policy Management, open the GPO.

  2. Click Computer Configuration > Preferences > Control Panel Settings > Local Users and Groups.

  3. Add a Local Group item.

  4. Configure the item:

    1. Set Action to Update.

    2. Select the group from the built-in group list. This allows Windows to identify the group by its built-in identifier rather than by its display name, which can differ on localized Windows installations.

    3. Add each corresponding value from the Members to add column exactly as shown. Do not replace %DomainName% or %ComputerName%. Each server substitutes its own domain and computer name when the policy is applied.

    4. Do not select Apply once and do not reapply.

  5. Select OK to save the item.

  6. Repeat steps 3–5 for each group in the following table.

Group name
Members to add

Remote Desktop Users (built-in)

%DomainName%\Apono-555-%ComputerName%

%DomainName%\Apono-544-%ComputerName%

%DomainName%\Apono-551-%ComputerName%

%DomainName%\Apono-547-%ComputerName%

%DomainName%\Apono-580-%ComputerName%

%DomainName%\Apono-573-%ComputerName%

%DomainName%\Apono-558-%ComputerName%

Administrators (built-in)

%DomainName%\Apono-544-%ComputerName%

Backup Operators (built-in)

%DomainName%\Apono-551-%ComputerName%

Power Users (built-in)

%DomainName%\Apono-547-%ComputerName%

Remote Management Users (built-in)

%DomainName%\Apono-580-%ComputerName%

Event Log Readers (built-in)

%DomainName%\Apono-573-%ComputerName%

Performance Monitor Users (built-in)

%DomainName%\Apono-558-%ComputerName%

Remote Desktop Users (built-in) must include all seven Apono-managed groups. Remote Desktop connections require membership in this group regardless of the permission requested. For example, the Apono-547 group is added to both Remote Desktop Users and Power Users so that a user granted Power Users permission can connect to the server.

Integrate Windows Domain Servers

Before completing setup, create and link the Apono Group Policy Object (GPO) to the Servers OU. The GPO is required for requesters to access Windows servers.

lightbulb

You can also use the steps below to integrate with Apono using Terraform.

In step 12, instead of clicking Confirm, follow the Are you integrating with Apono using Terraform? guidance.

Follow these steps to complete the integration:

  1. On the Catalog tab, click Windows Domain Servers. The Connect Integration page appears.

  2. Under Discovery, select one or multiple resource types.

Apono automatically discovers and syncs all the instances in the environment. After syncing, you can manage access flows to these resources.

  1. Click Next. The Apono connector section expands.

  2. From the Select Connector From List dropdown menu, select a connector. Choosing a connector links Apono to all the services available on the account where the connector is located.

If the desired connector is not listed, click New Connector and follow the instructions for creating a connector (AWS, Azure, GCP, Kubernetes).

  1. Click Next. The Integration Config section expands.

  2. Define the Integration Config settings.

    Setting
    Description

    Integration Name

    Unique, alphanumeric, user-friendly name used to identify this integration when constructing an access flow

    LDAP Server URL

    Domain controller address identified in the Prerequisites

    Enter the address with the protocol and port:

    • ldaps://<HOSTNAME>:636 (LDAPS)

    • ldap://<HOSTNAME>:389 (LDAP).

    Example: ldaps://dc1.corp.example.com:636

    Apono recommends using LDAPS because LDAP sends the account password and group changes across the network in plain text.

    NOTE: If you omit the protocol and port, Apono uses ldaps:// and port 636.

    RDP Port

    Port requesters use to connect to the Windows server

    Default: 3389

    This value appears in the access details provided to requesters. Apono does not connect to this port.

    Computers Scope

    Servers OU DN

    Apono discovers enabled computer objects in this organizational unit and its child organizational units, excluding domain controllers.

    Active Directory does not distinguish servers from workstations, so the organizational unit determines which computers Apono discovers.

    NOTE: You can enter a distinguished name relative to your domain, such as OU=Servers,OU=CORP, or as the full distinguished name, such as OU=Servers,OU=CORP,DC=corp,DC=example,DC=com.

    Groups Scope

    (Optional) Groups container DN where Apono creates and manages the groups used to grant access

    If you leave this setting empty, Apono uses the default Active Directory Users container, CN=Users.

    IMPORTANT: For AWS Managed Microsoft AD, specify a writable container because the default CN=Users container cannot be written to.

    You can enter a distinguished name relative to your domain, such as OU=AponoGroups,OU=CORP, or as the full distinguished name, such as OU=AponoGroups,OU=CORP,DC=corp,DC=example,DC=com.

    User Email Attribute

    (Optional) Active Directory attribute used to match a user to an Apono email address.

    Default: userPrincipalName

    Specify another attribute, such as mail, if your organization stores work email addresses in a different attribute.

    Self-signed Server or CA Certificate

    (Optional) Base64-encoded PEM CA certificate identified in the Prerequisites

    IMPORTANT: Required when the domain controller's LDAPS certificate was not issued by a public certificate authority. Without this certificate, the connector cannot validate the domain controller and the connection fails.

  3. Click Next. The Secret Store section expands.

  4. Associate the secret or credentials.

    If you select the Apono secret manager, enter the values of the Username and Password for the user you created.

  5. Click Next. The Get more with Apono section expands.

  6. Define the Get more with Apono settings.

    Setting
    Description

    Custom Access Details

    (Optional) Instructions explaining how to access this integration's resources Upon accessing an integration, a message with these instructions will be displayed to end users in the User Portal. The message may include up to 400 characters. To view the message as it appears to end users, click Preview.

    Integration Owner

    (Optional) Fallback approver if no resource owner is found Follow these steps to define one or several integration owners:

    1. From the Attribute dropdown menu, select User or Group under the relevant identity provider (IdP) platform.

    2. From the Value dropdown menu, select one or multiple users or groups.

    NOTE: When Resource Owner is defined, an Integration Owner must be defined.

    Resource Owner

    (Optional) Group or role responsible for managing access approvals or rejections for the resource Follow these steps to define one or several resource owners:

    1. Enter a Key name. This value is the name of the tag created in your cloud environment.

    2. From the Attribute dropdown menu, select an attribute under the IdP platform to which the key name is associated. Apono will use the value associated with the key (tag) to identify the resource owner. When you update the membership of the group or role in your IdP platform, this change is also reflected in Apono.

    NOTE: When this setting is defined, an Integration Owner must also be defined.

  7. (Recommended) Click Test Integration to validate the integration.

Test Integration is available after you have entered or selected values for all required integration fields.

During the test, Apono runs the following validation checks:

  • Connectivity: The connector can reach the integration.

  • Configuration: The integration is set up correctly.

  • Authentication: The credentials are valid.

  • Discovery: Resources can be fetched.

The Test Validation checklist shows the result of each check.

If a check fails, Apono identifies the failed check and highlights the fields that need correction.

Test Integration does not validate the Group Policy Object (GPO) or confirm that requesters can connect to Windows servers. Verify that the Apono Group Policy Object (GPO) is correctly linked to the Servers OU before granting access.

  1. Click Confirm.

💡Are you integrating with Apono using Terraform?

If you want to integrate with Apono using Terraform, follow these steps instead of clicking Confirm:

  1. At the top of the screen, click View as Code. A modal appears with the completed Terraform configuration code.

  2. Click to copy the code.

  3. Make any additional edits.

  4. Deploy the code in your Terraform.

Refer to Integration Config Metadata for more details about the schema definition.

Usage

resources in an access flow. This allows requesters to access your Windows servers securely based on your approval and provisioning rules.

If a server has been deleted but Apono has not yet discovered the deletion, access requests for that server do not fail. The associated domain groups remain visible to users and must be deleted manually by an administrator.

Follow the guidance in these articles to define the resource using Windows Domain Servers:

Troubleshooting

Servers are pending Group Policy enrollment.

Apono cannot provision access to a server while Group Policy enrollment is pending.

Admins may see the following warning.

To identify and update the affected servers:

  1. On the Resources tab, filter the resources by the group_policy_pending resource tag with the value of true.

  2. For each affected server, apply the Group Policy by doing one of the following:

    • Restart the server.

    • Run the following command on the server.

PreviousPing Identity SSO
NextIncident Response Integrations

Last updated

Was this helpful?