LDAP/AD Integration
  • 11 Jul 2022
  • 5 Minutes to read
  • Dark
    Light
  • PDF

LDAP/AD Integration

  • Dark
    Light
  • PDF

Inedo products come with their own built-in users and groups, but they can also integrate with an external directory service like Active Directory and other LDAP-based services. This allows you to use the organization's existing users, logins, and groups to secure the product and define the tasks users are permitted to do.

Administrators can also enable Single-Sign On (i.e. Windows Integrated Authentication) so that end-users don't have to enter their username/password to use the product.

Built-in Users & Groups

When an Inedo product is first installed, a default administrator username/password (Admin/Admin) will be created. You should obviously change this password or delete this user once configured the product. You can also disable Built-in User Sign-on completely, which means users will only be able to log-in using their external (i.e. Active Directory/LDAP) credentials.

Restoring Default Admin Account

If you ever get "locked out" of an Inedo product, either due to misconfiguration or a lost password, you can restore the default Admin/Admin account and reenable Built-in User Sign-on. This involves:

  1. Logging into the server that the product is installed on
  2. Running the resetadminpassword command using the service executable
  3. Restarting the service and application pool (if IIS hosted)
  4. Closing open browser windows or clearing cookies
  5. Navigate to root url of product (e.g. https://myproget.company.local/)

HOWTO: Restore ProGet Default Admin Account

This Script will reset the account on Windows, so you can just copy/paste as needed.

"%progamfiles%\ProGet\Service\ProGet.Service.exe resetadminpassword
try { Restart-WebAppPool ProGetAppPool } 
catch { Restart-Service INEDOPROGETWEBSVC } 

Note that the try/catch statement is there to make this work for both IIS Hosted and Integrated Web Server.

Built-in Users/Groups in the Database

The users, logins, and groups you create in the product are called "Built-in Users & Groups", and are stored in the product's database (specifically, the Users, Groups, and UserGroups tables). Note that the passwords themselves are not directly stored; instead, passwords are cryptographically hashed/salted (see OWASP's Password Storage Guidelines).

Importing and Exporting Security Configuration

You can import or export users/groups and task/permissions as JSON documents. This may be helpful for diagnostic purposes, bulk-editing, or migrating instances.

  • To import or export users/groups, navigate to Admin > Manage Security > Built-In Users & Groups, then select either "Export Users & Groups" or "Import Users & Groups".

  • For Tasks / Permissions, navigate to Admin > Manage Security > Tasks / Permissions, then select either "Export Tasks" or "Import Tasks".

This functionality is available starting In ProGet 2022, BuildMaster 2022, and Otter 2022.

Domains & Active Directory/LDAP Integration

Inedo products use a "User Directory" to validate logins and find usernames and user groups in an external directory service. While it's possible to create a custom user directory component using the Inedo.SDK, nearly all users will have one or more of the LDAP/AD User Directory Types configured.

Configuring Multiple Directories / Domains

This functionality describes functionality starting in ProGet 2022, BuildMaster 2022, and Otter 2022. This is is available as a preview feature in ProGet 6.0.8+.

You can configure as many user directories as needed, and enable the ones you wish to search. When there are multiple enabled user directories, they will all be used to search users/groups and validate logins.

For example, if mycompany.corp and trusteddomain.corp are both configured, and the Built-in User Sign-on is Enabled:

  • If you enter jdoe in a search box then you may see:

    • jdoechestor (from the Built-in Users)
    • jdoeson@mycompany.corp
    • jdoe@trusteddomain.corp
    • jdoedawn@trusteddomain.corp
  • When a user logs in with jdoe and hunter42

    • the Built-in Users will be used to validate the login, and if that fails...
    • the mycompany.corp domain will be used, but if that fails...
    • the trusteddomain.corp domain will be used
    • the user will get an "invalid login" error if they all fail

As a result, this behavior may yield to logging of failed logins. The exception to behavior is if the username contains a @ or \ symbol, such as jdoe@mycompany.corp or COMPAN\jdoe. In that case, only the domains that matching that name searched.

Hybrid User Directory

Prior to ProGet 2022, BuildMaster 2022, and Otter 2022, you could create a Hybrid User Directories to approximate this behavior.

Upon upgrade to these versions, the Hybrid User Directory will be removed and the associated directories will be enabled.

Configuration in Earlier Versions

This describes the behavior of ProGet 6.0, BuildMaster 7.0, Otter 3.0, and earlier.

You may only have a single user directory active at a time: either the built-in, or one of the configured LDAP/AD directories) to query.

There are some disadvantages to this approach:

  • Easy to get locked-out; if there is a configuration problem, you need to follow the reset-instructions to fix it
  • Migrating domains is painful; because each of these directories uses its own sets of privileges, if you want to configure a different user directory, you need to recreate all those privileges

LDAP/AD User Directories Versions

Active Directory installions can be very complex, and its not uncommon for users to integrate our products with a decades-old multi-domain forrest with tens of thousands of users. Over the years, we've learned better ways to integrate with a variety of configurations. However, due to the risk of breaking authentication, we implemented major changes as new new type of user directory.

v1: LDAP or Single Domain Active Directory (Legacy)

This worked for most customers that needed to authenticate using LDAP-only, or integrate with a single domain. It allowed for custom mapping of LDAP property names... which in retrospect was unecessary. All directories we've seen in the field follow the same conventions.

v2: Active Directory Domain Forest (Legacy)

This addressed a major flaw in v1: only a single domain was queried, and for organizations that wanted users from multiple domains to log-in, this was a problem. This user directory removed the unecessary field customization, and searched all domains in an Active Directory Forest instead of performing LDAP queries on a domain.

v3: Active Directory / LDAP (Current)

This was a complete rewrite, and effectively combines the concepts of v1 and v2. It can search multiple domains (each with different credentials), and has several AD-specific features like the ability to search gMSA accounts.

v4: Coming soon

This will be largely based on v3, but will add additional LDAP options and filtering (similar to v1). It will also be limited to searching a single domain. While this means that administrators will need to configure one user directory per domain, this will ultimately be simpler --- in practice, automatically attempting mutli-domain queries made troubleshooting very challenging.


Was this article helpful?