ENGAGE Device Limitations

ISONAS devices require a bitmask to be set at the device level such that only a single credential format can be used on each device. You can learn more about how Pure Access handles bitmasking here. For credentials being enrolled on ISONAS devices, only the Badge ID is required (this is how the AD Connect integration currently functions). If the bitmask is set correctly, the device then delegates to Pure Access for backfilling data such as the credential facility code or issue level when the badge is scanned for the first time.

In contrast, ENGAGE devices (Schlage RC, NDE, LE) rely on the credential records themselves to specify a specific bit format and all of the data associated with that bit format. You can see the data required for each card format on the Importing Users into Pure Access Cloud page. Because of this distinction, AD Connect does not support integration with ENGAGE devices at this time.

Structures that will NOT work:

  • The AD Connect Tool will not traverse trusts between domains.
    • Users added to a group from a trusted domain will not sync.
  • If existing groups are used and users are in more than one nested group, you may encounter errors.
  • Groups and/or users that have non-alphanumeric characters may cause errors.

Requirements:

  • Active Directory running on Windows Server 2008 R2 or later.
  • PC/Server/VM with Windows OS to run the Isonas AD Connect service.
    • .NET 4.5 framework is required on this system.
  • Pure Access user with the Administrator user role.
    • Only users with Modify privileges for the “Active Directory” role will be able to manage the Active Directory configuration in Pure Access.
  • Active Directory user with Administrator level privileges.
  • A Pure Access tenant with one of the below license types:
    • PA-C-51-100, PA-C-101-250, PA-C-251, PA-MANAGER
  • An active API token with “Read Only” unchecked.

Service Account:

The service account must be able to read the entire directory.

  • You may attempt a less privileged account to see if this can read your directory. If authentication fails, elevate the account to Domain Admin. You may reduce privileges and retest to find the appropriate level for your directory.
  • The service account name should only contain alphabetic characters.
    • Good username: isonasadconnect
    • Bad username: isonas-ad-connect, ison@sadconnect
  • The username as entered will entirely depend on the AD configuration.
    • AD username Possibilities
    • You may need to modify based on your directory.
  • There is not official support for authentication with a .local domain.

Directory Structure and Groups:

  • There should be a dedicated OU that collects all of the user groups that you wish to use. This is a clean way to ensure a successful sync.
  • Groups should not be within groups. It’s cleaner and easier to manage if the groups are not nested.
    • It is recommended to name the groups for their purpose according to MS best practices.
      • i.e. DoorAccess-MainEntrance or DAMainEntrance
  • Users should be collected in a single root OU according to MS best practices.
    • i.e. Community/Office1/User Community/Office2/User
  • Usernames should only contain alphanumeric characters.

AD Connect Software:

  • It is recommended to run the AD Connect software on a Domain Controller.
  • The AD Connect Tool will require internet access in order to communicate with Cloud.
    • If Pure Access Manager is in use, an internet connection is not required, however, the tool will need clear access to the PAM server.

Resources:

Was this helpful?

Yes No
You indicated this topic was not helpful to you ...
Could you please leave a comment telling us why? Thank you!
Thanks for your feedback.